Jason @0xbbbb_eth
Account Abstraction Developer
MEV Researcher
Core Contributor of Panta Rhei
Chain & Account Abstraction
Problem
Bypassing on-chain policies
Network DOS
Proposal
remove the ability of EOAs to make transactions when the account has code.
Once the account is an SCA, it may return to being an EOA by removing it's own account code using a
CODERESET
opcode.
Stackup gives up bundler & paymaster and turns to a product that streamlines onchain operations
We're excited to empower organizations to master their blockchain operations.
Picture this: role-based transactions, automated recurring payments, and real-time onchain cash flow insights - all in one clear interface. That's what we're creating.
Embedded fee markets and ERC-4337
Zerodev Magic Account(@zerodev_app & @SocketProtocol)
Unified balance across chains
Instantly spend on any chain -- with ZERO bridging latency
No need for native gas tokens
Paymaster ↔︎ Solver
An intuition of how, and why, Magic Account works.
The core insight behind Magic Accounts is that, by using smart accounts, users can *automatically* lock up tokens for solvers, such that solvers are willing to *front* liquidity for users on other networks, knowing that they can come back to the source chain to *reclaim* tokens.
Today, users don't get to spend their tokens until step 4.
With Magic Accounts, users spend their tokens literally in step 1
Users don't have to wait for bridges. (solvers do)
Users don't have to figure out which bridges to use. (solvers do)
Users don't have to incur risks of bridge failures. (solvers do)
Magic Account is a close collab with @SocketProtocol, who first came up with the idea under the name "MagicSpend++", which we improved on and implemented.
Socket's solver network -- Modular Order Flow Auction (MOFA) -- will provide liquidity for Magic Accounts
Smart Sessions <Rhinestone & biconomy>
Smart Sessions is account-agnostic
It is interoperable across all ERC-7579 accounts.
Smart Sessions is fully composable
It separates validators and policies to increase the ease of component reuse
Smart Sessions is Chain Abstracted
enable a session key for multiple sessions and on multiple chains, all with a single user signature
The integration of Smart Sessions into @WalletConnect’s AppKit
ERC-7710: Smart Contract Delegation Interfaces
A Delegator is a smart contract that can create a delegation. It implements the
ERC7710
interface, which implements ERC-1271.A Delegation Manager is a singleton smart contract that is responsible for validating delegation authority and calling on the Delegator to execute an action. It implements the
ER7710Manager
interface.A delegation is an authority given to another address to perform a specific action.
A delegate is a smart contract, smart contract account, or EOA that has authority to redeem a delegation.
A redeemer is a delegate that is using a delegation.
ERC-7715: Grant Permissions from Wallets
We define a new JSON-RPC method
wallet_grantPermissions
for DApp to request a Wallet to grant permissions in order to execute transactions on the user’s behalf. This enables two use cases:Executing transactions for users without a wallet connection.
Executing transactions for users with a wallet connection that is scoped with permissions.
Currently most DApps
It’s impossible to send transactions for users without an active wallet connection. This invalidates use cases such as subscriptions, passive investments, limit orders, and more.
It can get tedious for the user to manually approve every transaction, especially in highly-interactive applications such as games.
ERC-7715
Current cross-chain solutions face big challenges
rely on centralized bridges with serious security risks
use decentralized methods that are overly complex for users
the new version of the @pimlicoHQ ERC-20 paymaster
300+ tokens supported (with plans to add a lot more)
one paymaster address for all tokens
now you can do the token approvals during the execution step of the user operation
Preconf
How to price a preconfirmation
It's a balancing act to avoid overpaying while ensuring your transaction gets included.
we started to explore whether we could create a new single piece of software that validators can run and still specify shapes that must be in the block. This is the main idea behind Commit-Boost.
Commit-Boost is a unifying piece of software that acts as a platform to standardize only how a signature on a shape to be included in a block is provided. With this platform, validators run one piece of software but get to opt into many shapes to be part of the block.
Through unification / standardization, Commit-Boost helps reduce fragmentation risks across Ethereum, but also has tools in the software to provide additional safety checks to validators.
MEV Supply Chain
App-Specific Sequencing (ASS) is not all what you need. There are also some trust assumptions
Self-sequenced dapps are partial block builders.
Inclusion Games
Self-sequenced dApps face a challenge: the higher the bundle value, the greater the need for guaranteed inclusion in the block. (use preconf)
ASS dapps should not hurt their regular users and LPs by extracting MEV.
What if the size of a bundle conflicts with the block size of the underlying chain?
How to ensure that sequencing benefits everyone, and not only one actor, leaving other actors (LPs, users) without extracted value?
Timestamp Ordering in MCP for Timing Games
Consider a scenario in slot
m
where a malicious proposer attempts to front-run or sandwich another transaction. Under the previous deterministic ordering, which was based on auctions and priority fees, such attacks were feasible because proposers could manipulate their position in the ordering by outbidding others or exploiting latency.In PODs, transactions are ordered deterministically based on their timestamps. While this approach necessitates handling cases where multiple transactions share the same timestamp
Timing Games And Why People Play Them
How do you prevent timing games?
A potential solution is coordinating with relays (who receive payloads from builders) to enforce timeliness. Relays can also refuse new bids for blockspace from builders after the slot starts (t = 0).
For context, a relay can opt out of this arrangement and coordinate with validators to play timing games. A validator can also integrate directly with a builder, removing the need for a relay entirely.
Another solution is enforcing missed slot penalties. There's no penalty for missing a slot (beyond missing out on rewards) so timing games are profitable for large pools that can tolerate a few missed rewards.
The main issue w/ missed slot penalties is: timing games look similar to honest validator behavior. For instance, solo stakers propagate blocks slowly (due to lower bandwidth) and miss more slots. Enforcing missed slot penalties would adversely affect this set of validators.
Should the execution ticket supply be fixed?
a fixed supply leads to a ticket monopoly.
a variable supply can lead to a PoS-like oligopoly.
Does multi-block MEV exist? Analysis of 2 years of MEV Data
We looked at proposer-builder data and MEV-Boost payment data since the merge (September 2022) to identify patterns of multi-block MEV.
We observe fewer multi-slot sequences of builders than a random Monte Carlo simulation would predict. The longest observed multi-slot sequence is 25 slots.
Average MEV-Boost payments increase for longer consecutive sequences by the same builder from ~0.05 ETH for single slots to ~0.08 ETH for nine consecutive slots.
In longer sequences, the payment per slot increases slightly with later slots. This indicates that builders bid higher to get longer sequences or the first slot after a longer sequence.
There is a weak positive autocorrelation between subsequent MEV-Boost payments. This contradicts the hypothesis that there are generally periods of low and high MEV.
Comparing builders with periods of low and high base fee volatility shows a low correlation. This indicates that no builder specialization based on base fee volatility has developed yet.
Rough draft of an ASS diagram for some of the generalized solutions and their range on the spectrum.
Brontes: an open-source analytics pipeline that provides comprehensive MEV classification on Ethereum.
Introducing mev-boost-py to query real-time mev-boost bids from flashbots relay in python
Owning two blocks can give you more MEV than the sum of its parts.
Say you can capture x MEV from block t and y MEV from block t+1.
Owning both might allow you to capture >x+y MEV
MMEV can lead to centralization because there are increasing returns to scale with more consecutive blocks owned. If you control block t, you can bid more aggressively for block t+1.
MMEV also (potentially) breaks new MEV capture solutions
It is not widely exploited yet. It may not be exploited now bec the market is not fully mature. This could change in the future.
Sandwich-Mitigating Uniswap V2
Uniswap V2 is minimally modified to enforce on swaps a verifiable sequencing rule, the Greedy Sequencing Rule, which makes sandwich attacks unprofitable.
How does this prevent sandwich attacks?
The proposer (or builder in PBS) includes the swap for the first side of the sandwich attack (a buy order) as T1, to front-run the user's swap.
Then, it includes the user's swap (a buy order) as T2.
The algorithm recognizes that any sell order would have received a better execution than another buy order.
Therefore, the algorithm assumes that the proposer must have run out of sell orders, so the proposer is restricted to only include buy orders for the remainder of the block, starting at T3.
The proposer tries to include the swap for the final side of the sandwich attack (a sell order) as T3, but the transaction reverts.
The order is not a buy order, as restricted by the GSR.
Protocol
Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue
Running an Ethereum validator node means that any minimally sophisticated party can link your IP address to your ETH addresses.
Builders' bidding will look very different in ePBS / EIP-7732. With P2P and RPC marketspaces, one is a single-bid open auction, and the one is a private auction
EIP-7732 Enshrined Proposer-Builder Separation Consensus Spec Notes
An examination of blockchain sharding through the lens of established parallel computing models leading to a better understanding of the potential and limitations of sharding.
There are structural economic reasons why sequencing will always accrue way more value than DA...
The problem is while the sequencer makes a fortune off price discrimination, the DA layer does not participate because it has zero price discrimination power. That super high value arb pays the same for Ethereum DA as the 1 wei spam transaction, because they're settled in a single batch
Because the marginal tx is very low value, you can only get high TPS when the median tx can land on chain at near zero cost. But with DA basically every tx pays the same. A DA layer can either have high throughput or it can have high revenues. But it can't have both.
Block-STM vs. Sealevel: A Comparison of Parallel Execution Engines
Layer2
L2 state validation (frault proof)
re: "running a based rollup isn't a good business model"
based rollups do give up MEV to the L1, but that doesn't mean they can't make money
on @taikoxyz users need to pay both priority/base fees, the latter going to to the DAO
Steps to Achieve Atomic Execution in Rollups
Proposal Block Sequencing: Bundle transactions are included in all rollups’ blocks.
State Execution: The execution of transactions by all rollups is valid.
Finalized Block Sequencing: All rollups have correctly reconstructed the block.
The Finalized Block is reconstructed based on the execution results of the Proposal Block.
It excludes (reverts) all failed transactions, including only those that were successfully executed.
This block inherits the Proposal Block’s resistance to censorship, sandwich, and front running. This phase guarantees Atomic Execution.
They'll send thousand txs that revert for barely any cost to land 1 arb that makes them profitable.
If you don't run an off-chain auction, then your auction will happen on-chain instead. This is a scaling issue, not a revenue maximization problem.
WASM opcodes are much faster than the EVM equivalents, so most Stylus opcodes use < 1 gas
Stylus introduces a new payment unit called ink, which is much smaller in scale.
By default, 1 unit of gas = 10,000 units of ink.
Practical Limitations on Forced Inclusion Mechanisms for Censorship Resistance
we say a transaction is censored if its inclusion depends on non-economic information.
Censors can manipulate state, which can invalidate transactions. They can use this to harm users, while still including their transactions. Forced inclusion cannot prevent this
For example: A sequencer can prevent USDC withdrawals from lending markets by temporarily borrowing all available USDC, or censor an AMM trade by moving the price temporarily
Restaking
The problem: It costs ~$3 to post a DA certificate to Ethereum calldata. If a rollup is posting a DA certificate to Ethereum every 2 minutes this adds up to ~$2200 in daily gas costs!
EigenDA: Revolutionizing Rollup Economics
The rollup sequencer sends a batch of transactions as a blob to the EigenDA disperser sidecar.
The EigenDA disperser sidecar erasure encodes the blob into chunks, generates a KZG commitment and multi-reveal proofs for each chunk, and disperses chunks to EigenDA Operators, receiving signatures certifying storage in return.
After aggregating the received signatures, the disperser registers the blob onchain by sending a transaction to the EigenDA Manager contract with the aggregated signature and blob metadata.
The EigenDA Manager contract verifies the aggregated signature with the help of the EigenDA Registry contract, and stores the result onchain.
Once the blob has been stored offchain and registered onchain, the sequencer posts the EigenDA blob ID to its inbox contract in a transaction. A blob ID is no more than 100 bytes long.
Before accepting the blob ID into the rollup's inbox, the inbox contract consults the EigenDA manager contract on whether blob was certified available. If it was, the blob ID is allowed into the inbox contract. If not, the blob ID is discarded.
Developer
Less Terrible Ethereum Indexing
In practice, Ethereum is a surprisingly challenging system of record.
Building this so that it’s fast and correct is frankly harder than it should be.
How to call an untrusted external callback function from your Solidity code, safely?
How to choose the gas limit?
The Uniswap devs have come with another goodie: compute it as a portion of `block.gaslimit`!
https://github.com/nomad-xyz/ExcessivelySafeCall…
That's not the same, preventing memory expansion from return vs ensuring you can follow up after whatever happened in the external call, the return value from the try catch isn't used.
However, the critical check to ensure that the message is originating from a trusted TokenMessenger address on the source chain was missing as message.Sender is not verified.
This meant that the noble-cctp ReceiveMessage handler was processing BurnMessages from any sender.
Solidity 0.8.27 version released
Accept declarations of state variables with
transient
data location (parser support only, no code generation yet).Make
require(bool, Error)
available when using the legacy pipeline.Yul: Parsing rules for source location comments have been relaxed: Whitespace between the location components as well as single-quoted code snippets are now allowed.
Others
zkTLS stands for "Zero-Knowledge Transport Layer Security." It builds on the TLS protocol.
With zkTLS, users can create proofs of data shown in their web browser. Examples: proving bank balance or purchase history without exposing actual data.
Current challenge: scale. Each website needs a defined "provider" (URL + data location). This process can be time-consuming.
After years of research we finally extracted Intel SGX Fuse Key0, AKA Root Provisioning Key