Protocol Insights #16
Account Abstraction, PBS, Preconfs, MEV, Cryptoeconomics and Protocol
Jason @0xbbbb_eth
Account Abstraction Developer
MEV Researcher
Core Contributor of Panta Rhei
Account Abstraction
Great summary of the evolving EIP-7702 spec
EIPs/EIPS/eip-7702.md at master · ethereum/EIPs
SET_CODE_TX_TYPE→0xef0100 || address
In-Protocol Revocation: If an EOA delegates to a buggy or malicious contract, they can now delegate to a new implementation, or if they want to return to being a pure EOA, they can simply delegate to the zero address or their own address.
DoS Attack Resistance: This attack can be mitigated by lowering the maximum number of pending EIP-7702 transactions in the mempool to 1. This would guarantee that hybrid EOAs could have at most 1 transaction invalidated per block.
Shared Storage Mitigation: There are mitigations for this issue that can be implemented at the application layer, i.e. using external storage contracts, always (re-)writing state variables at the time of delegation, etc. This is the most practical solution and wouldn’t require any major changes to the VM.
User-friendly Security Model: The current version of EIP-7702 hits the functionality-and-security sweet spot. It makes it clear that EOAs are able to delegate to smart contracts for as long as they want, but always remain traditional EOAs at their core.
Viem introduces the Account Abstraction extension: slim & compact primitives for ERC-4337
Interface to Bundlers & Paymasters
Smart Accounts (+ Passkey/WebAuthn primitives)
First-class APIs for User Operations
Enabling standardized on chain executions through Modular Accounts
Users issue on chain merklized Verifiable Credentials (VCs) through a contract identifier operated by an issuer. These credentials are stored in the user’s identity wallet (EOA)
Users generate and validate ZK proofs derived from their VCs through a contract verifier to access service apps and compile User Operation objects.
Smart Contract Account entry point perform canonical verification loop according ERC 4337.
The validation module verifies the zk proofs against the VCs in the execution loop and upon successful validation, the module calls the isValidSignature function as defined by ERC 1271 to authorize entry point to executeUserOps.
Smart contract Account entry point executes onchain operations and distributes the fees to the Bundler address.
Bento Batch: a open batch transaction strategy marketplace
Currently only support Smart Wallets like Blocto Wallet, and we're also in the process of integrating other smart wallets (OKX AA wallet, etc). Additionally, we plan to support EOA wallets after the EIP-3074 upgrade!
Blockspace Auction
Who Wins Ethereum Block Building Auctions and Why?
block market share positively correlates with order flow diversity
profitability correlates with access to order flow from Exclusive Providers, such as integrated searchers and external providers with exclusivity deals.
a positive correlation between market share and profit margin among the top ten builders, with features such as exclusive signal, non-atomic arbitrages, and Telegram bot flow strongly correlating with both metrics
This highlights a "chicken-and-egg" problem where builders need differentiated order flow to profit, but only receive such flow if they have a significant market share.
Strategic Bidding Wars in On-chain Auctions
Our results demonstrate the importance of latency on the effectiveness of builders' strategies and the overall auction outcome from the proposer's perspective.
The Blockspace Network for Sustainable Rollup Revenue
rollup currently uses first come first server model
block space network to help rollup to generate profit
rollup important features
resistance (encrypted mempool, better performance)
liveness（raft living consensus + eigenlayer）
safety (use based sequencing concept)
Enshrined Harberger Lease for Execution Tickets
prevent multi-block MEV ↔︎ allocative efficiency
Execution Tickets: prevent multi-block MEV
Execution Autions: allocative efficiency
Execution Tickets with Harberger Lease: prevent multi-block MEV & allocative efficiency
Builder Bidding Behaviors in ePBS
MEV-Boost market space
Push + pull-based: The builders push bids to the relay, and the proposer pulls the bids from the relay.
ePBS market spaces
P2P market space
Push-based. The builder pushes the bid to the p2p network.
Builder RPC market space
Pull-based. The proposer pulls the bids from the builder RPC end points.
Preconfs
From Self-sequencing to Preconfirmation
Self-sequenced dapps now have a problem: the higher value its bundle has, the stronger certainty it requires on inclusion. Such a problem can only be solved by preconfirmation.
Proposers are already facing a dropping revenue with frontend MEV. And they can’t do much about it.
One thing they CAN do is to provide inclusion certainty which dapps value so much that they are willing to pay a premium.
Protocol
Who will be creating blocks in 5 years and what will be the barrier of entry into doing it?
Who will be storing the state in 5 years and what will be the barrier of entry into doing it?
What will *I* as a user be able to do in 5 years *without* a 3rd party operator?
How will those validators get the 32MB worth of blob transactions every 12 secs?
The current design of Verkle trees does not delete any slots (I raised this concern maybe 4 years ago). So if MPT is switched out, your current numbers are meaningless.
Sending transactions and constructing blocks requires 1. access to the state and 2. access to transactions. Currently MEV, flashbots, relays and whatnots are all the rage on the tx side and we've often were told that "we should drop txpool and just delegate to block builders". On the state side stateless is all the rage and we're told "validation doesn't even need an EL" and the aim it to have validators only run proofs but not hold state. Both those statements are from EF research.
Other Discussions
2D Reed-Solomon codes with KZG commitments are excellent for distributed erasure code computation
preserve decentralization of validator set
enable MEV burn
Latency Bottlenecks
Block Time and Confirmation Latency
Blockchain Synchronization (Consensus)
Throughput Bottlenecks
Single-Threaded Execution
Wasteful Execution, like u256
State Management
Gas Metering Overhead
Node Capacity Limits
State Growth
State diffs provide a macro view of the changes on the Ethereum blockchain
Storage diffs offer a micro view of changes within the storage of a specific smart contract.
Pros:
Appendable SC removes overhead of LSM/Binary trie database. Makes binary format easier to use.
Append of data to binary files are a lot faster that random inserts.
Removal/invalidation is faster in binary form that removal in database.
Cons:
It is faster on data that was previously changed, not on new data insert.
Appendable Trie gets fragmented. Defragmentation algo needs to be run.
Requires new Included trie, that takes more disk space.
Rollup
Secure transactions from censorship and harmful MEV: Using delay encryption and zero-knowledge proofs (ZKPs) for encrypted mempools.
Fast Finality: based sequencing
Seamless Interoperability: achieving atomic execution with shared sequencers
Others
LRTs, despite starting off with ETH deposits, earn AVS tokens as additional yield to the native ETH yield.
This makes their backing collateral composed of multiple different tokens (this also turns their overall naming scheme of {prefix}ETH a slight misnomer).
LRTs might choose to stake these AVS tokens to earn additional yield (just like Lido compounds all ETH rewards).
Diffs in risk and liquidity
LRT represents ETH + AVS tokens
LRT protocol not likely to sell AVS tokens