GM @frangio thank you for the comment
1. Why “incompatible” events?
There is a “core” interface that is compatible with OpenZeppelin’s
AccessControl , but then the events are incompatible. Why is that?
I assue you are referring to the ones in
event RoleGranted(address indexed grantor, bytes32 indexed role, address indexed grantee, bytes _data);
event RoleRevoked(address indexed revoker, bytes32 indexed role, address indexed revokee, bytes _data);
These events helps indexers and off-chain users to get information about change of Roles.
Please note that the mandate in the specification is
- Compliant contracts MUST implement
- It is RECOMMENDED for compliant contracts to implement the optional extension
Which means OZ’s
AccessControl.sol is considered compliant to this EIP (it complies with the MUST interfaces). It’s ok that a compliant ignore specs that’s marked as “RECOMMENDATION”.
The recommendations are left there so that future clients, e.g. MetaMask and future contracts, and start to implement better features provided by this new EIP
2. Why “bytes” field in methods?
What is the motivation to add
bytes data arguments to each function? This isn’t explained.
Thanks for the comment, I tried to explained that but maybe that’s not obvious enough. These extra
bytes are meant to support EIP-5750 General Extensibility,
EIP-5982 Role-based Access Control
2. The methods in
IERC_ACL_GENERAL conform to EIP-5750 to allow extension.
So they could support future expansions, for example:
- Compared to GovernerAlpha, The new GovernerBravo adds new methods
castVoteWithSig which can be supported without change of method if they have an extra
- Compared to ERC-20’s
transferm, ERC-721 and ERC-1155’s
transferFrom has an extra
bytes to support future extensions.
Example of of possible future extension include:
function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external
And since you () are the author of EIP-1271 and EIP-2612, I am hoping to put these examples hopefully resonate with these areas of your great efforts:
ERC2612.permit, imaging in the future we need multi-sig to do threshold signing, they will need to create new methods. Using EIP-5750, we get the benefit of not needing to create new methods.
Why are behavior of functions not specified?
The behavior of functions isn’t specified. In my opinion this EIP is in a state where it shouldn’t even be accepted as a Draft.
I agree with you we shall provide more details about behavior of functions as an EIP. I will add more details soon.
That said, this snapshot is to go for DRAFT status which is before REVIEW status. Hence we are putting here for early feedback, hopefully the name of these functions are largely self-explanatory. But I think based on the definition of DRAFT status in EIP-1 EIP Process Section, it should be ok for publication as Draft status,
@frangio, I greatly appreciate your feedback and looking for your advices in this EIP draft.