Previously we have learned about Account Abstraction: Introduction. This is second part of the Account Abstraction Series. We will get a complete idea about Role of EIP-86 in Account Abstraction.
This proposal includes changes to abstract out signature verification and nonce checking and allowing users to establish account contracts that conduct any required signature/nonce checks rather than relying on the traditional method. The goal was to prepare an account security abstraction.
Traditional Model V/s New Model
In Traditional Model; ECDSA and the default nonce scheme are the only way to secure an account. In New Model; All accounts are contracts, contracts can pay for gas, and users are free to define their security model.
Example: This code is taken from Github Repository of EIP-86.
# Get signature from tx data
sig_v = ~calldataload(0)
sig_r = ~calldataload(32)
sig_s = ~calldataload(64)
# Get tx arguments
tx_nonce = ~calldataload(96)
tx_to = ~calldataload(128)
tx_value = ~calldataload(160)
tx_gasprice = ~calldataload(192)
tx_data = string(~calldatasize() - 224)
~calldataload(tx_data, 224, ~calldatasize())
# Get signing hash
signing_data = string(~calldatasize() - 64)
~calldataload(signing_data + 32, 96, ~calldatasize() - 96)
signing_hash = sha3(signing_data:str)
# Perform usual checks
prev_nonce = ~sload(-1)
assert tx_nonce == prev_nonce + 1
assert self.balance >= tx_value + tx_gasprice * tx.startgas
assert ~ecrecover(signing_hash, sig_v, sig_r, sig_s) == <pubkey hash here>
# Update nonce
~sstore(-1, prev_nonce + 1)
# Pay for gas
~send(MINER_CONTRACT, tx_gasprice * tx.startgas)
# Make the main call
~call(msg.gas - 50000, tx_to, tx_value, tx_data, len(tx_data), 0, 0)
# Get remaining gas payments back
~call(20000, MINER_CONTRACT, 0, [msg.gas], 32, 0, 0)
Above code is an example forwarding contract. This contract verifies the signature, and if it is valid, it initiates a payment to the miner and then sends a call to the specified address with the given value and data. Forward Contract is a contract between 2 parties to buy or sell an asset at a specified price on a future date.
In this section, we will see the advantages of this proposal.
1.Multisig Wallets: In Traditional Method; Each transaction in a multisig wallet must be approved by all the participants. We can simplify this by combining all participants’ signatures into a single ratification transaction, but it still increases complexity as all participants’ accounts must have ETH. With this EIP, the contract will now be able to hold the ETH, submit a transaction with all signatures to the contract directly, and the contract will be able to pay the fees.
2.Custom Cryptography: In Traditional Method; Users must follow ECDSA, which uses elliptic curve cryptography. With this EIP, Users can upgrade to ed25519 signatures or any other scheme they wish on their terms; they are not required to adopt ECDSA.
We have briefly discussed about Role of EIP-86 in Account Abstraction. In third part of this series, we will understand EIP-2938 proposal for for account abstraction.
Hope you like it.
Hoping for a positive response.
Please Follow My @Medium profile Yash Kamal Chaturvedi
Account Abstraction: EIP-86 was originally published in DataDrivenInvestor on Medium, where people are continuing the conversation by highlighting and responding to this story.