Jason @0xbbbb_eth
Account Abstraction Developer
MEV Researcher
Core Contributor of @ETHconomicspace
Account Abstraction
SIWE & AA
Two bundlers (@transeptorlabs and @pimlicoHQ) already support EntryPoint v0.7, and the rest are expected to be ready by the end of this month
Everything About Account Abstraction
Last month, Base ranked second for ERC-4337 smart account usage. [Polygon was #1]
81,000+ UserOps were made on Base in March. [UserOps are transactions made by ERC-4337 accounts]
60% of those UserOps were calls to the@Safe 4337Module. This module executes UserOps on behalf of Safe wallets, allowing them to act as 4337 accounts.
87% of those UserOps were bundled by @pimlicoHQ
Coinbase Magic Spend
EIP-5792 Batch Call
Zerodev Kernel v3
First modular account for EntryPoint 0.7
First audited account for ERC-7579
First account with *composable permissions*
Signer (who) is a passkey
Policies (when) specify that the passkey can only spend USDC, can only use Uniswap, and can only be used once a month
Action (what) is the execution logic
EIP-3074
The problem of 7547 and 3074 - HackMD
Inclusion List & 3074
A transaction from address B can change the ETH balance of the account with address A without changing it's nonce.
Case
Proposer of N includes a transaction from address A in the IL.
Builder of N includes a transaction from address B that sweeps out all the ETH from address A.
Builder of N+1 can no longer include the transaction from A as it doesn't have funds to pay for gas.
EIP-3074 reduces the incentive to switch to smart accounts is major cope ?
One bad signature will be able to drain your account on Ethereum after EIP-3074 ?
ERC-4337 & EIP-3074
Posts
EIP-3074 & EIP-5003
The account retains a single master key (the original EOA key) EIP-5003, otherwise known as AUTHUSURP, which allows the original private key to be revoked
https://safe.global/blog/eip-3074-risks-opportunities-for-smart-account-adoption
EIP-3074 sacrifices key rotation. While all AA features mentioned above can be enabled, key rotation becomes slightly elusive because the original private key retains control over the account on all networks that have never been used, even with EIP-5003.
Exploit with **EIP-3074**
Nonce & chainID
https://x.com/haydenzadams/status/1779163248417177919
Invokers don’t increase the nonce. In your scenario with the uniswap invoker, where MᴇᴛᴀMᴀꜱᴋ proposes another invoker, the new signature would not invalidate the uniswap AUTH. The user does not need to re-sign AUTH messages unless they send a tx.
Protocol
This post proposes to extend a similar sort of anti-correlation incentive to more “mundane” failures, such as missing an attestation
https://ethresear.ch/t/analysis-on-correlated-attestation-penalties/19244
Raise gas costs of hash functions - HackMD
Blocks that are heavy with hash function executions take much longer to ZK-SNARK prove than average blocks.
Vanilla validators build 2x less blocks than rsync, but have a 4x higher blob inclusion rate
Network congestion on @Solana
The core issue relates to a QUIC implementation, and the behavior of the Agave validator client on @solana when asked to process a large number of requests.
No mempool
Preconfirmation
To EOF or not to EOF
Others
Insert "printf" into on-chain contracts to replay transactions
Celestia Snark Accounts Design Spec
In this design, each rollup on Celestia has a designated SNARK account that maintains the balance of TIA on the rollup.
Users can deposit TIA on the rollup by sending money to the SNARK account (i.e. bridging to the rollup).
Users can withdraw TIA from the rollup (withdrawing from the rollup) by providing a proof to the SNARK account that there was a valid withdrawal on the rollup corresponding to their claimed withdrawal on Celestia.
"safe under at least one honest member" assumption of DAC is for when data is published and all member receive the data
Reth Design
It's because Geth bakes the trie in the DB whereas Reth does it as a separate process.
Cut the LSM (or the BTree if you’re using another DB), and double down on using the MPT as your db index, observing that the MPT can simply replace the Btree in DB design and give you the verifiable state commitment.
Then you try to lay out the MPT in a nice way on disk, such that you can maximize cache locality on each page fault, so that on each ‘real’ read, you can also read the intermediate trie nodes due to each paged read being 4kb (or 16kb in e.g. newer Apple devices), and reduce the overhead.
Let's verify the whole Bitcoin chain using a STARK proof for $1.5