Protocol Insights #17

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

Jason @0xbbbb_eth

Account Abstraction Developer

MEV Researcher

Core Contributor of Panta Rhei

Account Abstraction

• EIP-7702 confuses users

  • case

    • user creates seedphrase in wallet1

    • wallet1 prompts user to setup account recovery by delegating to contract1

    • user imports seedphrase into wallet2

    • wallet2 prompts user to delegate to contract2 to enable batched transactions

    • user + wallet2 have now, completely unknowingly deleted the account recovery setup in wallet1

    • user loses their account and never uses crypto again

  • This is exactly why 7702 smart accounts (just like regular smart accounts) will need to be modular. This means that there is no need to delegate to a new account to enable more features, but simply to install another module.

• Omnichain Smart Accounts with ERC-7579 Modules

  • Smart Account State Sync

    • An ERC-7579 validator module that utilizes Keystore and reads state (using L1SLOAD) from another chain.

      

  • Omnichain Assets Modules (i.e. Resource Lock)

    • Use an ERC-7579 validator with a co-signer.

    • This validator performs a resource lock on the account for the required funds (e.g., 100 USDC) and ensures no other validator can be used during the resource lock period, thereby eliminating double-spend and block reorg risk.

    

• BundleBear 2024 Half-Year Report Reveals Key Insights into ERC-4337 Ecosystem

• Viem 2.19 introduces *experimental* support for EIP-7702.

• Introducing @Candidelabs Social Recovery Module for Safe Smart Accounts

Blockspace Auction

• TEE-Boost

  

  • TEE-Boost lets proposers accept blocks directly from block builders running in TEEs. Builders generate TEE attestations that proposers can use to verify the exact code they’re running. TEEs then prevent builders from tampering with that code (eg. to produce invalid blocks)

  • TEE-Boost has a few nice properties

    • More profit for validators

    • Fewer centralized middlemen in MEV

    • Free optimistic mode for TEE builders

• Block-auction ePBS versus Execution Ticket

• Beyond the Ethereum Protocol: Proposer-Builder-Separation

  • Imgur

Preconfs

• Preconfirmation Bidding Increased Block Values on Holesky

  • Primev | preconf.eth on Twitter / X

• Rollup-Centric Considerations of Based Preconfimations

• Multiple Concurrent Proposers, FOCIL and Preconfirmations

  • execution preconfirmations

    • Both proposals restrict the power of a single proposer over transaction inclusion, but MCP additionally restricts the power over ordering.

    • This means that MCP is fundamentally incompatible with execution preconfirmations, or any other proposer commitments that require a monopoly over ordering.

    • This is not the same with FOCIL, where there is still a leader with monopoly over the non-IL part of the block.

  • inclusion preconfirmations

    • Both proposals are still compatible with inclusion preconfirmations.

    • The presence of multiple preconf providers resembles a leaderless system and could foster competition on preconf pricing.

    • In MCP, you just need a preconfirmation from 1 of them to be safe

    • can we just request an inclusion commitment from any IL committee member? The function that attesters use to determine the validity of the proposed IL is the following:

      

• The Road To Based Applications

Protocol

• Block construction session

• BRAID: multiple concurrent block proposers

  • 吴说区块链 on Twitter / X

  • Charlie Noyes on Twitter / X

• FOCIL vs BRAID

  • thread 1

    • BRAID is nicer in one particular aspect: it doesn't require an additional actor. In most IL designs, whether there's an additional actor like a proposer (EIP-7547) or a committee (FOCIL) to propose the IL.

    • Whatever flexible and yet can be opinionated tx ordering offers can also be done in FOCIL. I also don't think the "last look" problem for FOCIL is relevant under IL constraints.

    • Regarding complexity, FOCIL is simpler than BRAID at this moment and likely will remain so. I'm concerned about BRAID's fork choice complexity and how to scale into multiple proposers.

  • thread 2: FOCIL does not have

    • Priority ordering of txes rather than leader's discretion (allowing inclusion-list transactions to be MEV-relevant)

    • Conditional tips (possibly making non-censorship incentive-compatible)

    • No single assigned leader who is last mover (so at least the potential for no timing advantage)

  • thread 3:

    • FOCIL and ePBS do not immediately tackle the essence of Braid, which is abandoning leader-based block construction.

      • FOCIL uses MCP to build the leader's constraints.

      • ePBS decouples partially consensus and execution, with a gadget to select the leader.

    • Meanwhile, abandoning totally a leader-based model is not consensus, and neither is applying a deterministic ordering rule.

  • thread 4:

    • FOCIL today is the *only* viable path I see towards multi proposers. Overloading the consensus and forkchoice seems a daunting task

  • thread 5:

    • One of the more difficult challenges for BRAID is transaction invalidation.

  • thread 6:

    • Multi proposer has a lot of compelling arguments, but my biggest concern is merging txns with a deterministic rule would lead to spam. Particularly with backruns.

• Inclusion List Timing Constraints

• Unbundling staking: Towards rainbow staking

  • [ZuBerlin Protocol Day] Rainbow staking

• Replace Merkle Patricia state tree (MPT) for stateless client

  • Verkle trees

  • binary trees

  • Binius

MEV

• Layer-2 Arbitrage: An Empirical Analysis of Swap Dynamics and Price Disparities on Rollups

  • We observe significant shifts in trading activity from Ethereum to rollups, with swaps on rollups happening 2-3 times more often, though, with lower trade volume.

  • By examining the price differences between AMMs and centralized exchanges, we discover over 0.5 million unexploited arbitrage opportunities on rollups.

• Affiliated AMMs and permissionless solving for uniform price batch auctions

Others

• Restaking analysis

• Cross-L2 Solutions

  • 3770 (cross-L2 addrs)

  • 7683 (cross-L2 sends via liquidity providers)

  • 3668 (L2 light clients)

  • Cross-L2-replayable account state updates

• OP_CAT

  • OP_CAT is utilized for concatenation. It combines the top two items from the script's stack into one. For example, if "abc" and "123" are at the top of the stack, OP_CAT concatenates them to form "abc123".

  • If I have funds in a bridge, I can withdraw thoes funds to me

  • I don't want an operator to sende me funds and then he refunds himself and it creates sort of liqulidity inefficiency

• The path to general computation on Bitcoin

• Data Distribution with Reed-Solomon Codes for Sharded Storage

  • 

    • N: Total amount of data elements

    • n: Number of nodes in the network

    • k: Minimum number of nodes required to recover the original data

    • b: Blowup factor, defined as b = n/k

    • m: Number of rows in the data table representation

  • It’s crucial to note that we don’t need to apply RS codes to all data together. This is because a node can only go offline as a whole - there can’t be a situation where two nodes lose half of their data each, requiring RS codes to recover the data. A node either loses all its data or provides it entirely.

• A rule for sorting Solidity imports topologically and alphabetically

• Try Catch and all the ways Solidity can revert

• Secure Multi-Party Computation

• A case study for Ephemeral Rollups: Avail Unification Cup

  • We ended up performing a "Squash Fork," where we shut down the rollup and deployed a new instance, taking the latest state but with modified fixtures as the new genesis state.

    • State is copied at a block and used as genesis state for a new chain - The new chain loses history but preserves the last finalized state