Protocol Insights #22

Account Abstraction, PBS, Preconfs, MEV, Cryptoeconomics and Protocol

Jason @0xbbbb_eth

Account Abstraction Developer

MEV Researcher

Core Contributor of Panta Rhei

Chain & Account Abstraction

• What does EIP-7702 mean for YOU? Part 1 -- The Adoption Cycle of 7702

  • Standalone wallets (e.g. MetaMask) will implement support for 7702 but require users to opt in.

  • Embedded wallets (e.g. privy/dynamic) will also implement support for 7702, but require developers to opt in.

  • Innovative dapps will implement AA features using 7702-enabled embedded wallets.

  • Adventurous EOA users will try these dapps by turn on 7702 for their standalone wallets.

  • Seeing more users turning on 7702 and more dapps adopting 7702, the slower-moving dapps will start leveraging 7702/AA too.

  • As the number of AA-enabled dapps grow, the slower-moving users will enable 7702 too, in order to not miss out on all the new apps and new experiences.

  • As more and more users enable 7702, the long-tail of wallets who are yet to support 7702 will be forced to add support or risk fading into irrelevancy.

• You can use 7702 right now using "anvil --odyssey" or by deploying to Odyssey testnet.

• EIP-7702 & ERC-4337

  • demo 1 (I, II)

  • demo 2

  • You can designate an ERC-4337 SCA implementation onto an EOA using EIP-7702 with Viem & Odyssey right now.

    

    • It is vulnerable to takeover of the account by frontrunning and invoking initialize with different arguments (STEP 3)

  • Jiffyscan supports Odessey

• EIP-7702: A Win for Smart Accounts in Ethereum’s Pectra Upgrade?

  • The transaction includes data such as the EOA’s nonce, the address of the delegation designator, and the chain ID.

  • This impacts its cross-chain functionality. Users can choose to include a specific chain ID, restricting the transaction's validity to a single chain. Alternatively, they can set the chain ID to zero, making the transaction valid across multiple chains.

  • However, the EOA's nonce must align across chains for this to work. If the nonce differs—due to the EOA conducting varying numbers of transactions on different chains—the transaction will only succeed on one chain.

  • Drawbacks

    • Private Key Remains a Security Risk

    • Multisig Trust Issues

    • Limited Account Recovery

    • Lack of Quantum Resistance

    • Inability to Lock Resources or Act as Escrow

• Resource lock is better than escrow for chain abstraction

• Biconomy Nexus

  • Resource Locking to support Chain Abstraction

    • Modules can have predetermined time locks before they can be uninstalled. This enables instant transaction time for chain abstracted use cases!

    • This is possible because resource locking offers 'credible commitment' that user's funds can't be double spent.

    • Thus, a 3rd party can execute the user's transaction instantly & supply the required funds. With the assurance that funds from the user's account will be received.

• OpenZeppelin will enhance AccountAbstraction via ERC-4337 in our battle-tested OpenZeppelin Contracts library.

• A library to validate the ERC-4337 rules within Foundry

  • It also supports both v0.6 and v0.7 of ERC-4337.

  • This library allows you to validate:

    • Banned opcodes

    • Banned storage locations

    • Disallowed *CALLs

    • Disallowed use of EXT* opcodes

    • Disallowed use CREATE opcode

• ZK Email Email Recovery Audit

Preconf

• Proposer-Commitment Infrastructure in Ethereum

MEV

• Timeboost is worse for DEXes than it first seems.

  • Timeboost is a new transaction ordering policy for Arbitrum chains where participants can bid for the right to get their transactions included slightly faster than anyone else. Importantly, user transactions will still remain private until after they are executed, meaning that no one can frontrun or sandwich users. Timeboost bids are collected by the Arbitrum DAO in either ETH or ARB, depending on DAO approval.

  • block time: 200 ms → 450 ms

  • Arbitrum I love you, but you’re bringing me down.

Blob

• Dynamic Blob Targets for Better Blob Pricing: PID

• Blob EIPs and Minimum Validator Requirements

• On solo staking, local block building and blobs

  • Solo stakers tend to miss more slots compared to professional validators.

  • Solo stakers often build their blocks locally rather than using MEV-Boost.

  • Local block builders don’t benefit from the fast propagation offered by MEV-Boost relays.

  • Relays engage in timing strategies (e.g., relay delays, allowing time to wait for even more profitable blocks).

  • Epoch boundaries contribute to an increase in reorgs.

• The Impact of Increasing Blob Count: Pectra, PeerDAS and Beyond

  • against: Péter Szilágyi (karalabe.eth) on Twitter / X

• Get blobs from the EL's blob pool

  • This PR implements an experimental optimisation to fetch blobs via JSON-RPC from the EL. If a blob has already been seen in the public mempool, then it is often unnecessary to wait for it to arrive on P2P gossip. This PR uses a new JSON-RPC method (engine_getBlobsV1) which allows the CL to load the blobs quickly from the EL's blob pool.

Protocol

• Possible futures of the Ethereum protocol

  • Possible futures of the Ethereum protocol, part 1: The Merge

  • Possible futures of the Ethereum protocol, part 2: The Surge

  • Possible futures of the Ethereum protocol, part 3: The Scourge

  • Possible futures of the Ethereum protocol, part 4: The Verge

  • Possible futures of the Ethereum protocol, part 5: The Purge

  • Possible futures of the Ethereum protocol, part 6: The Splurge

• Pectra 升级

  • EIP-2537（支持 BLS 签名）：通过引入一系列预编译合约（precompiles），为以太坊增加对 BLS12-381 曲线运算的支持，可以实现 BLS 签名验证，并允许多个签名聚合为一个签名，从而减少验证时的复杂度。

  • EIP-2935（在状态中保存历史区块哈希）：通过将最近 8192 个区块哈希存储在系统合约中，以支持无状态客户端（Stateless Clients） 模型，并提供更灵活的历史区块哈希查询功能。

  • EIP-6110（在链上提供验证者存款）：将验证者存款的处理从共识层转移到执行层，在链上进行处理和验证，而不再依赖共识层中的额外投票机制来确认存款信息的有效性。

  • EIP-7002（执行层可触发的退出）：允许持有提款凭证的所有者能够独立发起退出，而无需依赖验证者的活跃密钥（BLS 密钥），增加了用户自主性。

  • EIP-7251（增加质押上限）：增加验证者的最大有效余额，从而允许每个验证者可以持有超过 32 ETH 的质押，而最低质押门槛仍然保持为 32 ETH。

  • EIP-7549（将委员会索引移出证明）：通过将委员会索引字段移出 Attestation（证明）消息，实现更高效的共识投票聚合。

  • EIP-7685（通用执行层请求）：为执行层（EL）定义一个通用框架，用于存储和处理由智能合约触发的请求。

Layer2

• data availability solution cost

• Launching Odyssey Testnet Chapter 1

  • an open-source testnet Layer 2

    • High Performance, Stability, Extensibility through the Reth SDK

    • Features from Ethereum’s Pectra and Fusaka upgrades, today: EOF, EIP-7702, EIP-2537, RIP-7212.

    • Frictionless L2 onboarding, without the user knowing about custom RPCs, bridging ETH, or browser extensions.

  • Odyssey Chapter 1 is live on Sepolia and is built with Reth, the OP Stack, and deployed on Conduit.

• Risk Rosette upgrade for Arbitrum One: Very DAO initiated upgrade will give users a 7 days window to exit before it gets executed, even in the presence of censoring operators.

• Unichain

  • 0xNatalie 🌊 on Twitter / X

• Unichain

  • 0xNatalie 🌊 on Twitter / X

• Introducing Rollup-Boost - Launching on Unichain

  • Rollup-Boost introduces the idea of rollup extensions -- modular components for upgrading rollups in performance, programmability, and decentralization.

    • Flashblcoks

      • How it works?

        

        • Creating and streaming partial blocks every 250ms to other nodes.

        • Providing users with early execution confirmations

        • Allowing nodes to incrementally download and continuously execute transactions rather than wait for new blocks.

        • Calculating the state root and consensus once for multiple partial blocks, amortizing costly parts of block production.

        • Serving early execution state over the existing, unmodified Ethereum JSON-RPC standard, enabling easy wallet and front end integration.

      • 250ms Flashblocks with native revert protection

      • Verifiable priority ordering within each Flashblock

    • supporting features in the future

      

• RIP-7755 POC: Contract standard for cross-L2 calls facilitation

  

Others

• Take tx data and figure out which ERC-20 assets + amounts are needed for the tx (assume `from` does not currently have the assets).

  • Simulate tx (with debug trace from foundry)

  • Look for SLOADS where ERC-20 transfer or transferFrom function selector is on stack

  • grab slot from top of stack, update value based on transfer args

  • resimulate and see if passes, repeat

  • Doesn't work for things like USDC that pack balance info with other storage :(

• If you are using secp256k1-node, be aware of CVE-2024-48930. Attackers can extract private keys if they can control the public key in ECDH.

  

• Temporary Approve（ERC-7674）

  • TSTORE & TLOAD

  • Temporary Approve can be utilized now by smart contract accounts (SCAs) and eventually by EOAs with the inclusion of EIP-7702.

  • 300 gas vs 2500 gas

• Geth ↔︎ Reth style ExEx plugins [close]

  • From a user perspective, execution extensions are essentially plugins that implement a slew of (optional) callbacks so that they might react to chain and EVM events with 0-delay, immediately as they are happening within the node itself.

  • Since Go does not have the capability to dynamically load/unload code, all such code needs to be compiled into Geth for now (and probably forseeable future).

• Solidity recent update (v0.8.28) allows using transient keyword directly