EoAs are now smart contracts. That's all account abstraction is.
Right now, every single transaction in web3 stems from a single private key.
account abstraction means that not only the execution of a transaction can be arbitrarily complex computation logic as specified by the EVM, but also the authorization logic.
Resources:
- A minimal EVM "Smart Wallet" using alt-mempool AA
- We even send a transactoin to the
EntryPoint.sol
- We even send a transactoin to the
- A minimal zkSync "Smart Wallet" using native AA
- zkSync uses native AA, which is slightly different than ERC-4337
- We do send our zkSync transaction to the alt-mempool
- Created a basic Account Abstraction on Ethereum.
- Created a basic Account Abstraction on zkSync.
- Deployed, and sent a userOp / transaction through them.
- Not going to send an AA to Ethereum
- But sent an AA tx to zkSync sepolia
- Anything can validate a transaction whatever we want , all we have to do is code a smart contract that says here is what that signs my transaction.
- Once we deploy this , when we actually wanna send a transaction, we first sign the data and we send to a group of Alt-Mempool nodes.
- These nodes are gonna be the one to combine everything into a single
User Operation
& call thehandleOps
function on theEntryPoint.sol
contract. - This function will do a lot of validation then if it looks good it will call your account contract, then it will execute/call the daap its working with etc.
- This is really fantastic because you can sign and send transactions where you don't pay any gas , if you have set up a
Pay Master
. - The main function is
MinimalAccount::validateUserOp
, instead of sending a regular transaction object to the blockchain , those alt-mempool nodes will send the user operations toEntryPoint.sol
contract, which will callMinimalAccount.sol
contract & execute the custom logic coded for validate user operations.- If the Transaction is valid, and the signature associated to it are also valid, it will then call
MinimalAccount::execute
function.
- If the Transaction is valid, and the signature associated to it are also valid, it will then call
-
Account Abstraction is built directly into ZKSync, On ZKsync you can have a smart contract wallet that acts as an EOA with native account abstraction built in unlike ethereum.
-
Lifecycle of a type 113 (0x71) transaction -
msg.sender
is thebootloader
system contract -
Phase 1 : Validation
- The user sends the transaction to the "zkSync API client" (sort of a "light node").
- The zkSync API client checks to see the nonce is unique by querying the NonceHolder system contract.
- The zkSync API client calls validateTransaction, which MUST update the nonce.
- The zkSync API client checks the nonce is updated.
- The zkSync API client calls payForTransaction, or prepareForPaymaster & validateAndPayForPaymasterTransaction.
- The zkSync API client verifies that the bootloader gets paid.
-
Phase 2 : Execution
- The zkSync API client passes the validated transaction to the main node/sequencer iff it gets validated first by light nodes so we dont get denial of service attack.
- The main node calls executeTransaction.
- If the paymaster was used, the postTransaction is called.
One of the big difference between Native Account Abstraction & EntryPoint based Account Abstraction is that:
- In EntryPoint based AA, the
from
is gonna be whatever node or user who actually created the transaction.- Whereas, On ZKsync with Native AA , the
from
is actually gonna be the smart contract wallet itself.
forge install eth-infinitism/account-abstraction@v0.7.0 --no-commit
forge install openzeppelin/openzeppelin—contracts@v5.0.2 --no-commit
forge install Cyfrin/foundry-devops --no-commit
# For Installing foundry-zksync packages:-
git clone https://github.com/matter-labs/foundry-zksync.git
cd foundry-zksync
./install-foundry-zksync
foundryup-zksync
# Validation Transaction Test for ZKSync
forge test --mt testZkValidateTransaction --zksync --system-mode=true
# deploy on zksync (sepolia)
yarn deploy