Protocol Insights #19

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

Jason @0xbbbb_eth

Account Abstraction Developer

MEV Researcher

Core Contributor of Panta Rhei

Account Abstraction

• backdoor a co-signer module

  • all entities must be trusted

    • the user

    • the proxy contract

    • the smart account implementation

    • the validator module

  • To resource lock via a co-signer module, four things need to be true:

    • UserOp validation integrity

      • In essence, the co-signer must always be used during transaction validation, and the return data must be trustworthy.

    • Known and trusted module upgrade paths

      • A user must not be able to uninstall the co-signer and install a “malicious” validator (malicious in that it enables the user to cheat the system). However, the user must be able to “opt-out” of the system in a non-malicious way.

    • Known and trusted account update paths

      • The user must not be able to upgrade to malicious code via the proxy contract, enabling them to cheat the system.

    • Trusted account implementation

      • The smart account implementation must adhere to standardized functions and behaviors that support credible commitments. For example, the account must not allow delegate calls that can lead to unexpected account behavior.

• Safe Wallet Ecosystem

  

• Skandha is now natively supported as upstream by @ERPC

ePBS

• The Role of the P2P Market in ePBS

  • a two-tier market

    • Large block builders are expected to use the pull-based direct connection market.

      • This market requires the proposer to connect to the builder’s RPC and actively pull bid(s) from it

    • Smaller builders who lack this connectivity with the validator set can use the push-based P2P market

  • Why P2P market

    • it allows anyone to set a floor price for the auction

    • it can be used for MEV-Burn in future protocol upgrades

    • it lowers entry barriers for new entrants or long-tail builders.

    • The ePBS P2P market aims to achieve multiplexing—the ability of proposers to discover builders

      • The ePBS P2P market scores very well on the trustlessness front

        • Neither a proposer nor a builder must trust anyone since bids are broadcast via the P2P network, and the winning bid is committed to on-chain.

      • The P2P market, however, scores poorly on the value reflection front.

        • Since the P2P network must be DOS resistant, it cannot handle too many bids, so bidders will likely not be allowed to bid as often as they could in MEV-Boost, meaning they have to be strategic about when they bid.

• A Note on Equivocation in Slot Auction ePBS

  • In slot auction ePBS, the beacon proposer does not commit to an execution payload hash, unlike in block auction ePBS. Instead, it commits to a specific builder that can submit an execution payload when it is time to reveal.

  • The first problem is that a builder could submit multiple execution payloads. In this note, we will refer to this as a builder equivocation.

    • Proposal 1: Vote for Execution Payload Hash

      • Replace PAYLOAD_PRESENT with execution_payload_hash

      • If no PTC quorum is reached, let the honest next-slot validator use an empty block as its head instead of a full block.

  • Proposal 2: Pretend Payload Absent

    • If the next-slot proposer/attesters observe(s) at least two equivocating payloads, it/they assign(s) no additional fork-choice weight to any empty or full block

  • While the first proposal has a problem with free data availability (Yet the adversary would not have to pay the base fee needed to provide the data on-chain; it only has to pay the proposer to commit to the adversary as the builder.), the second proposal may be more susceptible to builder games, such as reorging its execution payload.

Preconf

• will mev boost be the only wide adopted mechanism for out of protocol proposer commitments

  • validators will make multiple different types of commitments about tx inclusion, pre-confs, and more, in the future.

  • a project called "commit-boost" to standardize and modularize how proposers, aka validators, make these commitments and easily monitor how new commits impact validator performance.

• Preconf Security & Privacy

  • anonymous receiver-updatable broadcast encryption (ARUBE)

    

    • Each bidder can choose a group of providers who will have access to their bids.

    • ARUBE is used to efficiently disseminate bids from bidders to providers of their choice in a privacy-preserving manner

  • dual-phase commitments (DPCOM)

    

    • In a normal run of the protocol the provider opens all its commitments at the end of the L1 slot, however if the provider refuses to open any of its commtiments, the bidder can independently open the commitment without needing assistance from the provider.

    • DPCOM is used to securely commit to those bids and later allow for the opening of such commitments

• Sequencing X CAKE Day ETH CC talks

  • Catch up on the latest in sequencing, preconfs, commitments, & Chain abstraction.

• Multiple concurrent proposer (MCP) IS preconfirmation.

  • preconf buyers in Taiyi share a very similar role with proposers in MCP: They can include transactions in a block, without worrying about being censored.

  • So the outcome for MCP is likely app/account/rollup-specific proposer: One dapp/account only send transactions to one proposer. It mitigates conflicting transactions problem by not creating them at all.

  • It perfectly resembles Taiyi: it’s just like apps and accounts are buying preconf.

• Out-of-Protocol Inclusion Lists via Commit-Boost

  • a Commit-Boost module that allows a proposer of a slot to create a list of transactions that it wants to be included in the block produced for its slot while still outsourcing block construction via MEV-Boost.

MEV Supply Chain

• Private TX market is growing continuously.

  • Builder Performance Analysis

  • Dark Pools are usually 8-10x of public ones.

    

  • 90% of all builders' income comes from private channels.

    

• Guess Which Builder Took $8.2M From the Table During Black Monday?

  • From Aug 3rd to 5th, @beaverbuild raked in 3.9K ETH, a whopping 47% of its July haul in just three days. The beast's income is more than that of @rsyncbuilder and @titanbuilderxyz, adding as 2.6K ETH.

• The MEV Builder That Raked $3.5M on Black Monday

  • Ranked the 2nd regarding builder rewards

    • It’s neither Titan nor Rsync; instead, it is the builder labeled MEV Builder 0x3b, which took 1,448 ETH, worth $3.5M.

  • The craziest liquidation sent 358.7 ETH, worth $802K, to MEV Builder 0x3B in Block 20459000. Although it appears only to generate $87.8 profit, that's not the whole story.

• A high-level framing for Ethereum block construction centered around the design goals of encouraging builder competition, limiting the value of validator sophistication, and preserving the neutrality of block space.

• Super-Builders and MCP

• The Road to PBS: MEV-Boost++, Optimistic Relays, and TEE-Boost

• On Attestations, Block Propagation, and Timing Games

  • timing games cause missed attestations

    • missed/wrong head vote

    • Kiln propose blocks late, resulting in it's blocks getting more reorg

  • the proposers of Kiln cause the biggest problems

    • delaying block proposals to the 3-3.5 second mark within the slot.

    • Over 10% of Kiln attesters attempt to keep the local block on-chain by voting for it. If such strategies are adopted, they might justify the losses from incorrect head votes if they prevent the local block from being reorged.

  • attestation timing varies across Lido, Coinbase, and Kiln

• On Proposer Timing Games and Economies of Scale

  • https://x.com/ethresearchbot/status/1825783181888598199

  • A proposer must gather at least 40% of votes to ensure their block is accepted and not reorganized.

  • Entities with a larger market share can delay their block proposals longer without risking reorganization.

  • For every 1% increase in validator market share, the delay in block proposals can increase by 0.03 seconds.

  • It's much worse, an entity with 30% can delay 10 seconds, not 0.8: no client will reorg a block if the parent wasn't voted by 80% of the committee

• Stakers use different proposal timing strategies.

• Quick reorg update:

  • Nr. of reorgs trending down.

  • Most reorgs happen in the slot following epoch transitions.

  • Nr. of reorgs dropped significantly around the Dencun hardfork (March 2024).

  • Slot indices 22-25 (pre-justification) issues have vanished.

App-specific Sequencing (ASS)

• App-specific sequencing (ASS) refers to applications themselves ordering the transactions touching their state.

  

  • Customizability

    • Giving the app itself control over sequencing opens up for new kinds of apps.

  • Interoperability

    • Users can switch between apps near instantly, w/o bridges or third parties

  • Scale

    • This design pushes every required ordering action to the apps, who together build the dependency DAG

    • Therefore the validators only need to run a super lightweight consensus protocol, allowing apps to consume bandwidth on demand as with AWS (more on this in the future)

  • Customizability 2

    • allow apps to use any programming language and fully customize their execution environment

• why you, as an app developer, should be building with modular infrastructure.

• With @0xFastLane + validators handling MEV to mitigate spam, apps will have enough room for the application-specific sequencer to be an on chain smart contract without sacrificing UX.

  

• App Specific Sequencing Infrastructure Tradeoffs

  

Protocol

• network connection is the real bottleneck

  • stateless nodes can make things worse for they should find a node that can actually produce a witness

  • A somewhat accurate analogy is: existing p2p networks are for text chats, and a real-time blockchain needs video streaming, and we want to get 8k resolution with a standard Internet connection.

  • current situation of network improvement

• A staking pool is naturally incentivized to spread its risk across a larger number of operators. PoS also has elements that punish centralization (hence encourage decentralization) through correlated slashing penalties.

  • A pow mining pool could have thousands or even millions of independent workers (in practice, they don't), but the block is still built by a single party.

  • Staking pools, on the other hand, are more of a protocol for distributing stake (i.e., workers in PoW) across potentially many operators. There are over 200 of them in Lido today.

• 150 Days After Dencun --- Exploring the Economic Impact of Blobs on Ethereum and Rollups

  • EIP-4844 Blobs

  • Many look at charts like this and erroneously conclude that expanding DA capacity was a mistake for Ethereum, but Ethereum exists in a competitive environment with other DA layers offering even cheaper fees.

• EIP-7685: General purpose execution layer requests

  • This proposal defines a general purpose framework for storing contract-triggered requests.

  • alex eth/acc on Twitter / X

  • RocketPool and Lido Frontrunning Bugfix Review

    • Deposit Security Committee manual | Lido Docs

    • Before & After

      

      

  • pools such as Rocket Pool can significantly reduce bonding, as operators won't be able to hold their stake hostages

    • Before & After

      

• Parallel EVM

• Ethereum All Core Developers Execution Call #194 Writeup

• Censorship Insurance Markets for BRAID

  • censorship insurance markets to mitigate the liquidity requirements—a significant UX challenge—of BRAID

Layer2

• OP Succinct — minimal diff to upgrade an OP Stack chain to a full ZK rollup.

• Mega ETH vs Monad (1) (2)

• While L2 usage has soared, the direct benefit to ETH as an asset has been less clear. The ETH burn rate has fallen over the past few months, leading to less value flowing to ETH, despite the L2s seeing a sizable rise in profits.

  • As L2 usage continues to grow, what role will L2 tokens serve? And how much value will be captured by L2 tokens versus ETH?

  • Are rollups benefiting disproportionately relative to Ethereum? Or is this structure ideal to attract more users and developers into the broader Ethereum space?

  • As more L2s launch, how will users and liquidity interoperate across these various networks?

  • With fees now historically low on Ethereum mainnet, will we see developers reconsider deployment directly on the L1, or are L2 environments still more attractive?

• On August 16, OP Mainnet effectively disabled the fault proof system as part of a bug fix.

  • In this specific case, the fault proof system can be disabled by both the OP Foundation multisig and the Security Council with a DeputyGuardian pattern

  • the first can act through the second, but the second can revert back and revoke the permission in case of misbehaviour.

    

  • Because of this and other security mechanisms, OP Labs decided to exclude the fraud proof system from external audits. We disagree with this approach.

• L2 sequencer proving on weak hardware; parallelization and decentralization

Restaking

• Robust Restaking Networks

  • if attack costs always exceed attack profits by 10%, then a sudden loss of .1% of the overall stake cannot result in the ultimate loss of more than 1.1% of the overall stake.

  • The overcollateralization factor of a network (meaning gamma, or 10% in the example above) is a measure of robustness that could be exposed to the participants in a restaking protocol (bigger is better).

  • Final result: the maximum-possible length of a cascade of attacks is also governed by the overcollateralization factor

• How much should you pay for restaking security?

  • smart allocation to AVSs is crucial for security against cascading failures

  • Old paper's insight: If rational stakers *rebalance* between LSTs and DeFi based on yield → risk of cascading slashing events ⬇️

  • do not need to be as overcollateralized if

    • Node operators actively rebalancing (like the sims showed)

    • Attackers face non-trivial profit for attacking multiple services simultaneously

  • smarter LRTs + Poorer Attackers = More Capital Efficiency. So,

    • Incentives: Dynamic fees (or points) direct LRTs to allocate to parts of network that need more security

    • Costly Attacks: Cost of attacking n services ⬆️(e.g. submodularity of profit) localizes attacks

  • main takeaways

    • 𝐋𝐑𝐓𝐬 𝐧𝐞𝐞𝐝 𝐭𝐨 𝐚𝐥𝐥𝐨𝐜𝐚𝐭𝐞 𝐢𝐧𝐭𝐞𝐥𝐥𝐢𝐠𝐞𝐧𝐭𝐥𝐲 𝐟𝐨𝐫 𝐧𝐞𝐭𝐰𝐨𝐫𝐤-𝐰𝐢𝐝𝐞 𝐬𝐞𝐜𝐮𝐫𝐢𝐭𝐲

    • 𝐀𝐕𝐒𝐬 𝐧𝐞𝐞𝐝 𝐭𝐨 𝐜𝐡𝐨𝐨𝐬𝐞 𝐚 𝐦𝐢𝐧𝐢𝐦𝐮𝐦 𝐲𝐢𝐞𝐥𝐝 / 𝐫𝐞𝐰𝐚𝐫𝐝𝐬 𝐭𝐡𝐚𝐭 𝐚𝐯𝐨𝐢𝐝 𝐜𝐚𝐬𝐜𝐚𝐝𝐞 𝐫𝐢𝐬𝐤

    • Restaking risk combines

      • PoS risk (e.g. combinatorial nature, rewards, attackers)

      • DeFi risk (e.g. cascades)

• The Risks Associated with AVS Allocation Decisions

Cross Chain

• In this work, we describe a number of hardly researched problems which developers encounter when building cross-chain products.

  • Wallet: In practice, this means having control of the private key within the software that knows about the protocol semantics, in order to produce the correct signatures.

    • Hot Wallets:

      • Lack of general solutions for expressing arbitrary locking mechanisms

      • Lack of reusable components to safely roll your own wallet

    • Multi-currency Wallets

      • For cross-chain protocols, the problem space grows linearly with the number of chains supported by the protocol.

  • Blockchain monitoring and interaction

    • efficient and trustless monitoring is currently only possible by running a full-node yourself. That, in turn, greatly hinders the on-boarding process of users and is resource-intensive to operate.

  • Fees

    • Timelocks as well as pre-signed transactions share a common characteristic: Both concepts are about transactions that are to be broadcasted some time in the future instead of right away.

    • Given the dynamic nature of a blockchain’s fee market, it is a non-trivial undertaking to reliably get a transaction confirmed within a certain block target starting from some point in the future

• Solving Interoperability for the Superchain and beyond

  • message passing protocol

  • the Superchain token standard

  • interop fault proof

  • a set of interoperable chains

  • Interoperability - OP Stack Specification

• Six levels of trustless interoperability

  

  • 1 Async:
    → Interoperability via manual asset transfer through the L1 that rollups settle to.

  • Atomic Inclusion:
    → A guarantee that either all transactions in a cross-rollup bundle will be included in the next block for each rollup involved in the bundle, or none will.

  • Shared Settlement:
    → Multiple rollups connecting to the L1 via the same bridge contract.

  • Atomic Execution:
    → A guarantee that either all transactions in a cross-rollup bundle will be included and successfully executed in the next block for each rollup involved in the bundle, or none will be executed. Successful execution refers to each transaction being executed without reverting and being reflected in the updated state for each rollup in the bundle.

  • Block-Level Composability:
    → Next block guarantees on cross-rollup bundles that can contain dependent transactions (tx B on rollup B is dependent on the result of tx A on rollup A)

  • Tx-Level Composability:
    → Smart contract level interoperability requiring only one transaction that can cause state changes across many rollups simultaneously (no bundles). Using any protocol across any rollup is logically equivalent to using different smart contracts on one chain. Importantly, this implies that state changes prior to any call can be reverted when it returns.

Developer

• A technique to Automatically Detect Storage Collisions and Vulnerabilities within Solidity Smart Contract

• Minimal Upgradeable Proxies

• Technical Dive: Shadowing factory contracts

  

  • For example, this allows you to make one set of changes to the Uniswap V2 pool factory contract, and have those changes apply to all 300K+ Uniswap V2 pools, instead of shadowing each one individually – a tedious and impractical process.

• Solidity contracts have a B-tree-like function dispatch (each node has 4 elements).

  • If you mine a function name that hashes to 0x00000000, the function call will be at the leftmost part of the tree, which results in the lowest gas when calling it

• Constant Gas Function Dispatchers in the EVM

• How to avoid quadratic memory expansion costs.

  

  • abi.encode will allocate memory, but solc won’t detect that the memory is only used once and thus won’t try to free the memory after use.

AMM

• CoW AMM

  • LPs deposit into protected CoW AMMs, where traders can access the liquidity.

  • Solvers bid to rebalance the pool whenever an arbitrage opportunity arises.

  • The solver that offers the most surplus to the pool wins the right to rebalance the pool.

• Combinatorial Auctions without a Numeraire: The Case of Blockchain Trade-Intent Auctions

  • [research] Beyond batch auctions

  • Andrea Canidio on Twitter / X

  • Solver competition rules | CoW Protocol Documentation

  • batch auctions deliver a higher surplus than individual trade-intent auctions (like dutch auctions) under our model's assumptions. But there’s a fairness issue—batch auctions might benefit one trader more than others, which feels unjust

  • while not all fair combinatorial auctions offer strong fairness guarantees in equilibrium, some do. This insight could help evolve CoW Protocol’s mechanisms to include fairness guarantees within the auction itself, potentially replacing the EBBO test

Others

• First public SUAVE Testnet: Toliman

  • Apps on SUAVE have access to programmable public and private state, multichain capabilities, and leverage TEEs for enhanced security, privacy, and integrity.

  • Feature 1: EIP-712 signature transactions mean users can make transactions on SUAVE without switching their RPC, instead signing EIP-712 signatures that are valid SUAVE transactions no matter their RPC or connected network.

  • Feature 2: SUAVE Kettles provide fast and private compute to applications on the Toliman Testnet, and now they are in the latest generation of performant TEEs, intel TDX!

• Inside Celestia’s Lemongrass Upgrade: Key Features and Enhancements

  • CIP-10: use an on-chain signaling system where validators indicate their readiness instead of a specific block height

  • CIP-14: enabling one chain to control an account on another through IBC

    • Practically, this means that users on Celestia can manage their staking activities on Stride without relying on a centralized entity.

    • For instance, a user could stake TIA on Stride and receive stTIA (staked TIA) while still managing all related actions - such as delegation, rewards collection, and unstaking - directly from their Celestia account.

• Why The Next Bitcoin Upgrade is Important

  • SegWit (2017) - Scaling Bitcoin Block space, Birth of Bitcoin Cash

  

  • Taproot (2021) - Improving Bitcoin's Efficiency and Privacy

    • 

    • the Merkle Abstract Syntax Tree (MAST) allows Taproot to process complex Bitcoin transactions more efficiently. It does this by introducing logic that extracts and verifies only the hash values of required scripts.

  • OP_CAT (aka. BIP-420) - Foundation for the Growth of Bitcoin Ecosystem

    • Current Bitcoin's script is stateless.

    • Combining OP_CAT with Schnorr signatures could allow Bitcoin to enforce specific actions and verify state changes

    • OP_CAT could enable STARK verification

• 分形比特币OP_CAT：限制条款的技术详解