[pallet-revive] EIP-7702 (continued)#12229
Conversation
…time_dev --bump patch'
|
/cmd prdoc --audience runtime_dev --bump major |
…time_dev --bump major'
|
/cmd bench --runtime asset-hub-westend --pallet pallet_revive |
|
Command "bench --runtime asset-hub-westend --pallet pallet_revive" has started 🚀 See logs here |
|
Command "bench --runtime asset-hub-westend --pallet pallet_revive" has failed ❌! See logs here |
…k into rve/eip-7702
|
/cmd bench --runtime asset-hub-westend --pallet pallet_revive |
|
Command "bench --runtime asset-hub-westend --pallet pallet_revive" has started 🚀 See logs here |
…t-hub-westend --pallet pallet_revive'
|
Command "bench --runtime asset-hub-westend --pallet pallet_revive" has finished ✅ See logs here DetailsSubweight results:
Command output:✅ Successful benchmarks of runtimes/pallets: |
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
Continuation of #10851.
evm-test-suite PR: paritytech/evm-test-suite#141
This PR implements EIP-7702 ("Set EOA Account Code") for
pallet-revive, enabling Externally Owned Accounts (EOAs) to designate a contract whose code will be executed on their behalf when they are called.What is EIP-7702?
#9569
EIP-7702 lets an EOA sign an authorization that says "when someone calls me, execute contract X's code". When a transaction includes these authorizations, any subsequent calls to the delegated EOA will execute the target contract's code — but using the EOA's own storage and balance. This enables smart account patterns (batching, gas sponsorship, etc.) without requiring account abstraction (ERC-4337) or proxy contracts.
For background:
Changes
Pallet integration
The
eth_calldispatchable now accepts and processes an authorization list before executing the call.The
authorization_listparameter is aBoundedVeccapped atlimits::AUTHORIZATION_LIST_MAX(256). In normal operation the size is already constrained by the gas-validation logic ineth_transact(each entry costs at leastworst_case_delegation_deposit), but theBoundedVecis a defense-in-depth bound for any future call path that might bypass that check. Oversized lists are rejected ininto_callwithInvalidTransaction::Call.Authorization processing
The
Transaction7702type (with itsauthorization_list) was already defined and parsed; this PR adds the actual processing logic.process_authorizationsvalidates each entry (chain ID, signature, nonce, account type), creates the authority account if needed, and sets or clears the delegation. Invalid authorizations are silently skipped per spec.Key semantics:
Revive-specific complexity. In Revive the per-authorization pre-dispatch weight/gas is higher than in EVM because:
Storage changes
A new
AccountType::DelegatedEOAvariant is introduced:delegate_target: Option<H160>— the contract address this EOA delegates to.contract_info: ContractInfo— storage accounting (child trie, base deposit) for delegated EOAs.Key behaviors:
EOAtoDelegatedEOApermanently.delegate_target = Nonebut the account staysDelegatedEOA.Deposit lifecycle. Clearing a delegation refunds the
storage_base_deposit(the code-lockup portion) but preserves the child trie and per-item storage accounting. To recover the per-item deposit, the user must re-delegate to a contract that lets them clear the stored items through the normal storage path.Execution changes
During a call, the runtime resolves delegation:
delegate_target, code is loaded from the target contract but execution uses the EOA's storage.Benchmarks
process_new_account_authorization(n)— worst case: createsnnew accounts with delegations.process_existing_account_authorization(n)— best case: processesnauthorizations for existing accounts (used for weight-refund calculation).RPC integration
eth-rpcsupports submitting and dry-running EIP-7702 transactions.eth_getCodereturns the0xef0100 || addressprefix for delegated EOAs (per EIP-7702 spec).Tests
Test coverage includes:
storage_persists_across_clear_and_redelegate).