Hello everyone!
With the recent ACD decision to remove EOF from Fusaka (more details here: Update EIP-7607: Remove EOF from Fusaka by timbeiko ¡ Pull Request #9703 ¡ ethereum/EIPs ¡ GitHub), we made some necessary changes to EIP-7701 to decouple these proposals.
The previous version of EIP-7701 has made EOF containers and code sections a requirement, however most of the Native Account Abstraction design has remained unaffected by its removal.
Here is the list of major changes made in the last update (Update EIP-7701: Removing dependency on EOF (#21) by forshtat ¡ Pull Request #9734 ¡ ethereum/EIPs ¡ GitHub):
- Introduction of the
ACCEPTROLE
opcode
In the previous version, the invoked smart contracts immediately âknewâ what is the âroleâ of the current call by having the EVM call into entirely different sections of their bytecode.
Successfully returning from these code sections indicated the contractsâ approval of the proposed âroleâ (i.e. Paymaster
, Account
, etc).
In a new version, we remove any dependency on AA-specific code sections. Instead, the new ACCEPTROLE
opcode is introduced and the invoked contract has to use it to explicitly accept the proposed âroleâ.
In order to find out which âroleâ is currently executing, the contract must use the TXPARAMLOAD
opcode with an argument current_frame_role
.
The addition of the ACCEPTROLE
opcode eliminated the need for the EVM to provide any kind of function dispatch mechanism, so this is potentially a major simplification of the overall architecture.
- Removal of any proposed modifications to the EOF code container
Regardless of the future of EIP-3540, the combination of the ACCEPTROLE
opcode and the TXPARAMLOAD
opcode removes the need to make the EOF container explicitly aware of Account Abstraction.
Any future modifications of the EVM, or even its potential replacement, will be able to use EIP-7701 transactions using these opcodes or their corresponding system calls.
- Clearly define the limitations applied to the
TXPARAM*
opcodes
Previously the rules of which parameters are available in which frame were not formally defined. The default behaviour was also not clearly stated.
This is now addressed with the introduction of the âallowed txparam_id
â table.
To elaborate a bit further, this is how we expect these opcodes to be used in real-world contracts:
On a bytecode level, the first thing that the Factory
, Paymaster
or Account
contracts do is perform a TXPARAMLOAD(current_frame_role)
, and use the result to dispatch the code to the appropriate function.
In Solidity this dispatching may be a part of Solidity language specification, as an @annotation
, a keyword modifier like payable
, or a special function name like receive
and fallback
.
For the function marked this way the return
keyword is compiled into a ACCEPTROLE(current_frame_role)
sequence instead of the RETURN
opcode to accept the role.
So in terms of how the contractsâ source code will probably look in the future, the EIP-7701 transaction still performs multiple call frames like before - just not using EOF code sections for it.
For example, this is what a Paymaster contract could look like:
contract EIP7701Paymaster {
@PaymasterValidation
function validateTransaction() external {
// perform validation
return;
}
@PaymasterPostOp
function postOp() external {
// perform the post-op action
return;
}
}
In conclusion, we believe that the last two changes represent a significant improvement and simplification over the original proposal, moving EIP-7701 closer to its final form and to being proposed for inclusion in upcoming hard-forks.
All feedback is highly appreciated.