Protocol Insights #18
Account Abstraction, PBS, Preconfs, MEV, Cryptoeconomics and Protocol
Jason @0xbbbb_eth
Account Abstraction Developer
MEV Researcher
Core Contributor of Panta Rhei
Account Abstraction
@klaster_io is building Chain Abstraction with @erc7579 to maximize distribution
→ Multiple Safes, deployed on multiple blockchains with the same address
→ They can share gas, while covering gas costs in USDC, USDT, stETH, ETH, MATIC, etc... (including cross-chain gas, e.g paying on OP for a transaction on Base)
→ You can receive funds on any chain and you will be able to access it
→ Ability to sequence interchain transactions - e.g. swap USDC for USDT on Optimism, call LiFi to bridge to Base and then deposit to a staking pool on Base
Blockspace Auction
Bid cancellation does not even makes sense in ePBS
There is no canceling once the bid has been served to the proposer.
the builder will simply not send useless bids to the relay, they will wait for the appropriate time and send their bids accordingly either before the proposer requests or when they are asked by the relay.
Multiple Concurrent Proposers (MCP)
Some MEV strategies may interact suboptimally with Multiple Concurrent Proposers (MCP)
The proposers (or block builders) cannot simulate the outcome of the transactions with 100% accuracy.
With MCP we now have a new concern: proposers attacking other proposers.
the "knapsack rerack"
The MEV is won in the next block's PGA (my specialty).
the 'spoof bids
I'd send my competition fake bids with 9% lower gasprice so that they'd spam filter my real bid.
create a strategy that rhymes with the combination of the above.
The malicious proposer (p') sends honest proposer (p*) a fake tx that uses up all the gas and promises to pay a lot of MEV.
The tx from p' would even simulate MEV payment successfully in the top of the block built by p*, where it'd belong since it would have the highest priority fee.
But p' would overwrite that tx in their own block and then cheaply capture the MEV without needing to share it.
if p' tried to emulate the "low carb crusader" by sending a fake tx to * that was sandwich attackable. p' could then overwrite the "sandwich bait" in their own block and then attack the sandwich attackers.
stop framing mev latency games as a "last mover problem"
→ in what way would actors manipulate your protocol to extract the profit available to make
The ability for each proposer to invalidate the simulations of other proposers is not just a “probabalistic” game but an adversarial one. This is especially true when throughput (block space) is limited. One manifestation is proposers smurf-bidding each other with txs that they overwrote + invalidated in their own blocks to locally internalize MEV.
problems with Braid
introduce timing games between the proposers — seeing others’ blocks before proposing your own is advantageous.
The effects of a transaction can be known only after the full transaction set has been constructed. 2.
The same tx can be included by multiple proposers, preventing linear throughput increase.
Approach (It doesn't provide per-tx censorship resistance)
users can now send their transactions to only one proposer
no duplicate transactions from different proposers, since any given transaction can be submitted to exactly one proposer.
Anyone can spin up a proposer permissionlessly, but will rely on users “joining them” to propose blocks
Users can switch proposers without permission from their current proposer. Note that these properties ensure censorship resistance.
Assume in the following that each proposer submits their own ordered blocks, and that each block explicitly denotes its dependencies. This forms a block dependency graph (a DAG) and a partial order.
no additional ordering is needed: Everyone with the same set of blocks has the same dependency DAG, and this is sufficient to determine the canonical state.
A proposer’s block can be executed immediately once its dependency graph is known, as blocks from different proposers cannot invalidate each other.
Protocol
why geth dropped JIT-EVM in 2018
We check whether there’s a JIT program ready to be run using the hash of the code — H(C) is used as an identifier to identify the program;
if a program was found we run the program and return the result;
if no program was found we run the byte-code and we compile a JIT program in the background.
Maintaining 2 EVM versions and they sometimes went out of sync
disk is the bottleneck
Restaking
Solana
TIL most trading volume on Solana is actually through AMMs and not CLOBs.
Long tail assets without real MMs
Not only long tail assets
In the past 24 hours, Orca (AMM) alone has done $250 million of volume in its two largest SOL/USDC.
Phoenix (CLOB) has done about $14 million in volume between its two major SOL/USD books.
CLOBs on L1s can’t compete with CEXs because of known limitations:
high latency
expensive gas
low throughput
Pyth receiver contract has critical functionality to the Pyth oracle model and receives price feed updates from publishers
let price = price_update.get_price_no_older_than(&Clock::get()?, maximum_age, &feed_id)?;
Others
eRPC is a fault-tolerant EVM RPC proxy and re-org aware permanent caching solution. It is built with read-heavy use-cases in mind such as data indexing and high-load frontend usage.
RIP-7755: Cross-L2-Call Specification
Today, most solutions for Ethereum layer 2s (L2s) have one or more of the following drawbacks.
Reliance on privatized relayers with offchain access and incentives.
Reliance on protocols outside of Ethereum and its rollups.
High-level, intent-based systems that do not allow specifying exact calls to make.
User calls to a facilitator contract with the CrossChainCall and reward funds
Facilitator emits event for fillers to discover
Filler relays CrossChainCall to verifyingContract, including any funds possibly needed to successfully complete the call.
verifyingContract makes the call as specified by CrossChainCall
verifyingContract write to storage the call, the filler, and call outcome
After CrossChainCall.finalityDelaySeconds have elapsed, the filler can submit the proof
If the proof is valid and the call was successfully made, filler is paid reward.
TEEs on dYdX Chain - Research Report
In the case of dYdX chain, we hypothesized that validators could attest to the exact software they were running, and users could encrypt their transactions such that the transaction could only be included in a block proposed by a validator running attested-for software.
The goal of this would be for users to be able to use the chain knowing that validators will not extract value at the expense of the user’s orders.
