ERC-5750: General Extensibility for Method Behaviors
Designating last param of dynamically sized bytes to be used for behavior extensions of methods.
Abstract
This EIP standardizes the passing of unstructured call data to functions to enable future extensibility.
Motivation
The purpose of having extra data in a method is to allow further extensions to existing method interfaces.
It is it useful to make methods extendable. Any methods complying with this EIP, such as overloaded transfer
and vote
could use string reasons as the extra data. Existing EIPs that have exported methods compliant with this EIP can be extended for behaviors such as using the extra data to prove endorsement, as a salt, as a nonce, or as a commitment for a reveal/commit scheme. Finally, data can be passed forward to callbacks.
There are two ways to achieve extensibility for existing functions. Each comes with their set of challenges:
- Add a new method
- What will the method name be?
- What will the parameters be?
- How many use-cases does a given method signature support?
- Does this support off-chain signatures?
- Use one or more existing parameters, or add one or more new ones
- Should existing parameters be repurposed, or should more be added?
- How many parameters should be used?
- What are their sizes and types?
Standardizing how methods can be extended helps to answer these questions.
Finally, this EIP aims to achieve maximum backward and future compatibility. Many EIPs already partially support this EIP, such as EIP-721 and EIP-1155. This EIP supports many use cases, from commit-reveal schemes (EIP-5732), to adding digital signatures alongside with a method call. Other implementers and EIPs should be able to depend on the compatibility granted by this EIP so that all compliant method interfaces are eligible for future new behaviors.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.
When used in this EIP, the term bytes
MUST be interpreted as the dynamically-sized byte array in Solidity data types.
-
Unlike many other ERCs which is compliant at the
contract
level, this ERC's specification specify compliance atmethod
level. -
Any method with a bytes as this method's last parameter is an eligible method. It looks like this
function methodName(type1 value1, type2 value2, ... bytes data)
. -
A compliant method MUST be an eligible method and MUST also designate that last
bytes
field in its method parameter for behaviors extensions. -
If an eligible method has an overloaded sibling method that has the exact same method name and exact same preceding parameters except for not having the last
bytes
parameter, the behavior of the compliant method MUST be identical to its overloaded sibling method when lastbytes
is an empty array.
Examples of compliant and non-compliant methods
- Here is a compliant method
methodName1
in aFoo
contract
- Here is a compliant method
methodName2
in aBar
contract which is an overloaded method for anothermethodName2
.
- Here is a non-compliant method
methodName1
because it do not allow extending behavior
- Here is a non-compliant method
methodName2(uint256 _param1, address _param2, bytes calldata _data);
because it behaves differently to its overloaded sibling methodmethodName2(uint256 _param1, address _param2);
when_data
is empty array.
Rationale
- Using the dynamically-sized
bytes
type allows for maximum flexibility by enabling payloads of arbitrary types. - Having the bytes specified as the last parameter makes this EIP compatible with the calldata layout of solidity.
Backwards Compatibility
Many existing EIPs already have compliant methods as part of their specification. All contracts compliant with those EIPs are either fully or partially compliant with this EIP.
Here is an incomplete list:
- In EIP-721, the following method is already compliant:
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
is already compliant
- In EIP-1155, the following methods are already compliant
function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;
function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;
- In EIP-777, the following methods are already compliant
function burn(uint256 amount, bytes calldata data) external;
function send(address to, uint256 amount, bytes calldata data) external;
However, not all functions that have a bytes
as the last parameter are compliant. The following functions are not compliant without an overload since their last parameter is involved in functionality:
- In EIP-2535, the following methods is not compliant:
function diamondCut(FacetCut[] calldata _diamondCut, address _init, bytes calldata _calldata) external;
- Either of the following can be done to create a compliance.
- An overload MUST be created:
function diamondCut(FacetCut[] calldata _diamondCut, address _init, bytes calldata _calldata, bytes calldata _data) external;
which adds a new_data
after all parameters of original method. - The use of
bytes memory _calldata
MUST be relaxed to allow for extending behaviors.
- An overload MUST be created:
- In EIP-1271, the following method is not compliant:
function isValidSignature(bytes32 _hash, bytes memory _signature) public view returns (bytes4 magicValue);
- Either of the following can be done to create a compliance:
- An new overload MUST be created:
function isValidSignature(bytes32 _hash, bytes memory _signature, bytes calldata _data) public view returns (bytes4 magicValue);
which adds a new_data
after all parameters of original method. - The use of
bytes memory _signature
MUST be relaxed to allow for extending behaviors.
- An new overload MUST be created:
Security Considerations
- If using the extra data for extended behavior, such as supplying signature for onchain verification, or supplying commitments in a commit-reveal scheme, best practices should be followed for those particular extended behaviors.
- Compliant contracts must also take into consideration that the data parameter will be publicly revealed when submitted into the mempool or included in a block, so one must consider the risk of replay and transaction ordering attacks. Unencrypted personally identifiable information must never be included in the data parameter.
Copyright
Copyright and related rights waived via CC0.