This EIP offers a standard for building a bit-based permission and role system. Each permission is represented by a single bit. By using an uint256, up to $256$ permissions and $2^{256}$ roles can be defined. We are able to specify the importance of each permission based on the order of the bits.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Note The following specifications use syntax from Solidity 0.8.7 (or above)
Interface of reference is described as followed:
IEIP6617uint256. A permission MUST take only one bit of an uint256 and therefore MUST be a power of 2. Each permission MUST be unique and the 0 MUST be used for none permission.It is RECOMMENDED for compliant contracts to implement the optional extension IEIP6617Meta.
They SHOULD define a name and description for the base permissions and main combinaison.
They SHOULD NOT define a description for every subcombinaison of permissions possible.
Currently permission and access control is performed using a single owner (ERC-173) or with bytes32 roles (ERC-5982).
However, using bitwise and bitmask operations allows for greater gas-efficiency and flexibility.
Bitwise operations are very cheap and fast. For example, doing an AND bitwise operation on a permission bitmask is significantly cheaper than calling any number of LOAD opcodes.
With the 256 bits of the uint256, we can create up to 256 different permissions which leads to $2^{256}$ unique combinations (a.k.a. roles).
(A role is a combination of multiple permissions). Not all roles have to be predefined.
Since permissions are defined as unsigned integers, we can use the binary OR operator to create new role based on multiple permissions.
We can use the most significant bit to represent the most important permission, the comparison between permissions can then be done easily since they all are uint256s.
Compared with access control managed via ERC-5982, this EIP does not provide a direct and simple understanding of the meaning of a permission or role.
To deal with this problem, you can set up the metadata interface, which associates a name and description to each permission or role.
First implementation could be found here:
No security considerations.
Copyright and related rights waived via CC0.