Jason @0xbbbb_eth
Account Abstraction Developer
MEV Researcher
Core Contributor of Panta Rhei
Account Abstraction
Into the future with EIP-7702 - Part-1
Should the
contract_code
signature also sign over the account’s nonce?Should the
contract_code
signature also sign over the CHAINID?Should the
contract_code
instead be an address? This would save calldata, though only a little bit of calldata because ERC-1167 proxies 12 only take 44 bytes.Should
SSTORE
inside the “temporarily contract-ified EOAs” be prohibited, like it is in EIP-5806?Should we have initcode and not just
contract_code
?Should we just add a flag to NOT set the code back to zero at the end? Thereby making this EIP also supersede EIP-5003.
BundleBear ← data about aa ecosystem
Base has nice weekly active smart accounts
Everything About Account Abstraction: Coinbase Rolls Out Smart W…
Everything About Account Abstraction: Pectra Upgrade Set for Q1 …
PBS
Implicit trust out of protocol turns to explicit trust in protocol.
IL is not part of ePBS as currently specified
Next-slot ILs make low latency block construction+proposal super important, to the detriment of DVs, or they make encrypted block building infeasible.
Also what others said about unintended second order effects.
Preconfs
Commitment Games and Where to Find Them
Synchronous Commitments across chains
Multi Block Mev
Instant Bridges and Solver-Enable Experiences
Preconfirmations & Common Blockspace Demands
Other blockspace demands include commitment games such as Top of block, Bottom of block, Indexed execution, and Partial blocks, which the ecosystem has become increasingly familiar with.
pricing
mev, interactions w/ "classical" JIT block building
censorship resistance
decentralization (easy answer is something like MEV relay to orchestrate, can we do better?)
Proof Construction and Validation: Is there a common standard? - Slashing and Challenge Mechanisms: When a fault occurs, is there an interactive or non-interactive challenge game for slashing the builder or the proposer?
Liveness Fault: How can one slash for liveness faults if the block's release timestamp can't be proven, and what if the builder and proposer are on time but the relay failed to gossip the block?
Under EPBS: The main goal of EPBS is to reduce trust between proposer and the builder. Pre-confirmer requires trusting a 3rd party (ie. preconf gateway), want to understand the latency implication and how much trust is involved here.
MEV
Cryptoeconomics
For any attack & adversary, Cost of corruption > Profit from corruption
→For any attack, Redistributable stake > Harm from corruption to protocol (or protocol user)
Protocol
EIP-7706 fixes the issues of EIP-4844
the BLOB_GASPRICE_UPDATE_FRACTION is not resilient to increases in MAX_BLOB_GAS_PER_BLOCK. It will also have to be increased along w/ max blobs.
when max blob and update fraction are updated, there will be a discontinuity in blob gas prices, possibly greater than +- 12.5%.
This is going to make it difficult to look at historical data and answer "What was the blob gas price for block n?"
blob price or max blobs isn't stored on-chain. It's calculated with off-chain parameters from excess blob gas.
you do still need to know MAX_BLOB_GAS_PER_BLOCK and BLOB_GASPRICE_UPDATE_FRACTION of that block
Blobs, Reorgs, and the Role of MEV-Boost
Builders might have an incentive to not include blobs because of the higher latency they cause.
Non-MEV-Boost users include, on average, more blobs in blocks than MEV-Boost builders.
MEV-Boost users show a significantly lower probability of being reorged than Non-MEV-Boost users (see section MEV-Boost and Reorgs for details).
Rsync-Builder and Flashbots have a lower average number of blobs per block than other builders.
For example, the following chart shows the missed source votes of 21,648 Kraken validators over 1,107 epochs
Layer 2
Developer
Others
Decentralize & Trust Minimize Reth Execution Extensions
Why: We released ExEx a few weeks ago, as part of our roadmap to make Reth a programmable platform, showing a reorg tracker, an indexer and a rollup. But these are just centralized ExExes, running locally.
How: The TL;DR is go multiplayer by peering together ExExes and running a consensus algo over their state transition function.
1. ExExes peer together using Ethereum's P2P network.
2. You run a BFT algo over the ExEx state & P2P net
3. You source the stake weight of each ExEx in the BFT algo from a Symbiotic staking contract.
This automated process simplifies the operational complexity for protocols and users, making chain abstraction truly seamless and cost-effective.
Introducing the Pessimistic Proof for the AggLayer: ZK Security for Cross-chain Interoperability
In short, the AggLayer tracks two numbers, withdrawals and deposits, so that it can get a view of the current balance across all chains.
Using the pessimistic proof, the AggLayer is able to compute how many tokens of each type were withdrawn from each chain. These values are then summed across all chains, leaving a single view of the total balances available for each token on the AggLayer.
If any chain is found to have a negative balance, the AggLayer determines that the chain has attempted to withdraw tokens that were not deposited into it. Not good.
Fault proofs are finally live on @Optimism
https://optimism.mirror.xyz/izdAoJ8ooyhDfwFLFoCcUfB1icPLFn8AImBws4oaqw8
participation in the Fault Proof System is permissionless
Stage 2 decentralization
This framework aims to enable the OP Stack to support multiple proof systems, including zero knowledge proofs, alongside the current system, Cannon. Productionizing redundant proving schemes to secure withdrawals from OP Stack Chains back to Ethereum enables limiting the Security Council's role to only choosing between proofs in the event that they disagree.
Solana Foundation removes certain operators from delegation program over malicious sandwich attacks