Hi all, I am proposing an EIP-5750 to denote and designate the last parameters method as extra data.
Here is the pull request: EIP-5750: Method with Extra Data by xinbenlv · Pull Request #5750 · ethereum/EIPs · GitHub
To save you a click away, I add a snapshot here
title: Extra Data Parameter in Methods
description: This EIP that defines an extra data parameter in methods.
author: Zainan Victor Zhou (@xinbenlv)
discussions-to: ERC-5750 Extra Data Parameter in Methods
type: Standards Track
This EIP that defines an extra data parameter in methods, denoted as
methodName(... bytes calldata _data). Compliant method of compliant contract
can use the extra data in structural way to introduce extended behaviors.
The general purpose of having a standard for extra data in a method is to allow further extensions for a existing method interface. For example, the
- At the very least, Methods complying with this EIP, such as
votecan add reasons in extra data, just like how GovernorBravo’s improvement over GovernorAlpha
- In addition, existing EIPs that has exported methods compliant with this EIP can be extended for behaviors such as using the extra data for endorsements or salt, nonce, commitments for reveal commit.
- Allowing one method to carry arbitrary calldata for forwarding a function call to another method.
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.
- Any compliant contract’s compliant method MUST have a
bytes(dynamic size) as its
LASTparameter of the method.
function methodName(type1 param1, type2, param2 ... bytes calldata data);
- Having a dynamic sized bytes allow for maximum flexibility for arbitrary additional payload
- Having the bytes specified in the last naturally compatible with the calldata layout of solidity.
Many of the existing EIPs already have compliant method and all compliant contracts of such EIPs are already compliant.
Here are an incomplete list
- In the EIP-721 the following methods are already compliant:
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;is already compliant
- In the 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 the 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;
- In the EIP-2535 the following methods are already compliant
function diamondCut( FacetCut calldata _diamondCut, address _init, bytes calldata _calldata ) external;
- In the EIP-1271 the following methods are already compliant:
function isValidSignature( bytes32 _hash, bytes memory _signature) public view returns (bytes4 magicValue);
- If using the extra data for extended behavior, such as supplying signature for onchain verification, or supplying commitments in a commit-reveal scheme, the security best practice shall be followed for that particular extended behaviors.
- Compliant contract shall also take into consideration the information of extra data will be shared in public and circulate around mempool, so specific caution shall be paid for replay-attack, front-run/back-run/sandwich attacks.
Copyright and related rights waived via CC0.