Jason @0xbbbb_eth
Account Abstraction Developer
MEV Researcher
Core Contributor of Panta Rhei
Chain & Account Abstraction
Native Account Abstraction in Pectra, rollups and beyond: combining EOF, EIP-7702 and RIP-7560
ERC-4337 Shared Mempool: Official Launch on Ethereum Mainnet, Arbitrum and Optimism
ERC-4337 Mempool Stages: A Framework to Assess Bundlers Maturity
biconomy: The past 30 days have been packed with game-changing announcements!
Redefined blockchain transactions
Accelerated chain abstraction
Launched the ultimate Smart Account
Pioneered a new era of AI-driven operations.
Biconomy Modular Execution Environments (MEE)
Meeting the standards of modern blockchain user and developer experience requires an execution environment which elegantly operates across multiple blockchains, multiple virtual machines and multiple execution models (e.g. Intents and UserOps).
In order for developers to send instructions to such an environment, we require an executable model which is much more versatile than the transaction models of today. This new type of transaction needs to be able to contain multiple transactions, on multiple blockchains, intents for execution by solvers and even off-chain actions. Ideally, all of those instructions would be represented by a single transaction hash.
Supertransaction
Modular Execution Environment (MEE)
EIP-7701: Native Account Abstraction with EOF
A variant of RIP-7560 transactions relying on EOF Smart Contract Accounts
In its current form, RIP-7560 transactions use Solidity method selectors in order to achieve this separation. This, however, is far from ideal as this approach “leaks” the concept from a programming language widely used in the EVM into the core design of the Ethereum protocol.
As an alternative, Native Account Abstraction can be implemented in coordination with EIP-3540. Relying on the concept of “code sections” introduced with EIP-3540 appears to be a superior approach.
This version’s difference compared to the original proposal is in relying on features of “EVM Object Format” to distinguish between validation and execution code sections.
Uses Envio as the data layer.
Uses HyperIndex to index module installations and uninstallations, as well as tracking the currently installed modules for each account.
Uses HyperSync to fetch traces to get the installation data (Ethereum only).
Tracers—now live on Base, Odyssey, and EduChain!
Preconf
Enhancing Relay Capabilities with Commitment Filtering
Increase PBS functionalities without introducing additional validator sidecars
Enabe relays to enforce validator preferences through block filtering, maintaining core performance
This is applicable not only to leverage preconfirmations, but also to segment the market based on validator preferences for OFAC compliance and non OFAC compliance, among other sought-after use cases.
Relays can now enforce validator preferences at scale by reading from a smart contract and enabling validators to conform to the rules of new applications by exposing a generalized filtering interface.
Relays can now verify blocks come from registered builders via mev-commit’s provider registry contract ensuring sybil resistance and commitment credibility
This filtering is critical because PBS operates outside Ethereum's core protocol - builders could potentially make commitments under one identity while building blocks under another. For preconfirmations, relays can now verify that blocks come from registered builders for commitment enforceability, mitigating a key sybil resistance problem arising from a lack of builder identity in protocol. By handling filtering at the relay layer, we avoid adding complexity to the PBS pipeline while ensuring commitments remain credible.
MEV
Blob
Economic Implications of a Competitive Blob Market
However, this past week marked a shift: the blob market has consistently exceeded the target blob count, signaling a tipping point toward prolonged competition.
This shift from low competition to a competitive environment not only signals potentially higher fees for builders and providers, but also requires more competitive blob posting strategies to mitigate blob fee slippage. These strategies include increasing priority fees or utilizing preconfirmations to ensure timely blob inclusion.
Protocol
Faster block times -4 seconds
Faster finality - 3 slots
chain snarkification
Only the "state transition function" needs to be snarkified.
The other place that needs heavy use of SNARKs is aggregatable signatures.
quantum security
Resources
Does EIP-1559 reduce wait times?
While on average capacity in the queue is the same, the fact the the 1559 mechanism acts as a shock absorber that can adjust capacity in times of high demand matters a lot in a formal queuing model.
shock absorber & fee controller
Our results showed that the controller portion of the 1559 change actually leads to higher wait times for patient transactions and higher fees for impatient transactions relative to the pre 1559 pure priority fee market when the controller adjusts to fast.
Our data shows that it is not adjusting too slowly. In fact the opposite is true, it's adjusting too fast!
pm-AMM: A Uniform AMM for Prediction Markets
despite prediction market volumes taking off in crypto, most of it uses orderbooks, not AMMs.
One possible reason is that existing automated market makers are a poor fit for outcome tokens (tokens that resolve to $1 if an event occurs and $0 if it does not occur).
The volatility of outcome tokens is dependent on the current probability of the event and the time until the prediction market expires, meaning that the pool provides inconsistent liquidity.
Liquidity providers (LPs) are also essentially guaranteed to lose all of their value once the prediction market expires.
Layer2
Now with Durin, developers will be able to simply deploy subnames to L2.
ERC-7802: Crosschain Token Interface
This ERC introduces a minimal interface for tokens to communicate cross-chain. It allows bridges with mint and burn rights to send and relay token transfers with a standardized API.
Scaling Ethereum Rollups with Helios
Current proposals to make rollups interoperable — such as Optimism’s Superchain and zkSync’s Elastic Chain — will rely on the existence of secure light clients for rollup operators to validate incoming cross-rollup messages scalably. Right now, rollup operators need to run full nodes for every chain with which they interoperate.
Helios is becoming a multichain light client for Ethereum.
We’ve revamped our light client’s internals to make it agnostic to how blocks are verified, and added support for modifying the underlying execution environment to suit differences between rollups.
Taiko has a multitier proof system. You can override lower-tier proof with higher tier proof.
The tiers are defined as follows:
1. SGX Proofs
2. ZkProofs from Risk0
3. ZkProofs from SP1
4. 1/8 Minority Guardian MSig
5. 6/8 Majority Guardian MSig
When you submit a SGX Proof, it can be overriden by any proof from the higher tier. Taiko does not force you to use ZkProofs, when you propose a block you can prove it with SGX
They do force their own prover to prove some small portion of blocks with Zk Proofs, but most of the blocks they are proving have only SGX Proofs for now.
Additionally because each proof (except from the top tier) can be contested, there's a "cooldown" period - similar to fraud proof window in Optimistic Rollups, during which you can contest. Only after the cooldown period, the new L2 state root on L1 "finalizes"
Others
The consequences of a non trivial amount of Solana reorgs /skipped slots
The artificially induced scarcity of Solana block space from skipped blocks is a significant driver of transaction costs on the network.
Looking at epochs 691 + 692 as examples, after 1 or 2 skipped blocks the median fees rose 76% and 108% vs. the epoch median.
parallel building identifies upfront what transactions might conflict and parallel processes them.
rbuilder/crates/rbuilder/src/building/builders/parallel_builder at develop · flashbots/rbuilder
This shift may be attributed to Pyth’s pull-based Oracle model, which only provides data upon request rather than updating it regularly, unlike Chainlink’s push-based model.
Pyth’s approach is optimized for high-frequency applications, such as trading, where real-time data access is critical.
Chainlink: 推送式预言机采用一个简单的机制，它们会在特定的时间间隔或在不同的偏离阈值下定期"推送"价格数据到链上。
Pyth: 不同于“推送式”预言机主动将数据更新到链上，拉取式预言机则要求用户或者所谓的守护者（keepers）首先主动请求（或拉取）价格数据。当用户或者守护者得到这个价格后，他们会在执行某个交易的同时，将这个价格数据发送到去中心化应用（dAPP）