Derek Chiang | Ethlabs retweeted
This weekend we launched EthLib, a Lean4 library for Ethereum!
The goal is to bring Ethereum's primitives, specifications and theorems into one place, building a shared foundation for formally specifying and proving things about Ethereum.
github.com/ethereum/EthLib
The goal is to bring Ethereum's primitives, specifications and theorems into one place, building a shared foundation for formally specifying and proving things about Ethereum.
github.com/ethereum/EthLib
9
31
171
5,684
Derek Chiang | Ethlabs retweeted
Cryptographic World Computer
I made a visualization of EIP-8288 aka "recursive mempool aggregation," my new favorite EIP of all time because it perfectly encapsulates the thesis of the "cryptographic world computer" -- a system whose scalability *increases*, not decreases, with the level of decentralization.
explained how EIP-8288 achieved this seemingly impossible feat, but one gif is worth a thousand words.
Essentially, EIP-8288 leverages Ethereum's decentralized mempool as a parallel ZK proving cluster. Clients send signatures and proofs to the mempool, which over multiple rounds progressively aggregate them into fewer and fewer proofs, until the block builder finally aggregates them into one SINGLE proof.
This design accomplishes five things at once:
- The more nodes we add to the decentralized mempool, the more signatures/proofs Ethereum can process as a whole. This is obvious if you look at the animation and imagine more nodes in the mempool ring, which would "fan out" to more signatures/proofs.
- By aggregating over multiple rounds (aka "recursive aggregation"), the bandwidth consumed by proofs remains constant for each node even as the network processes more proofs. As a result, the network stays decentralized even as capacity increases.
- By aggregating proofs before one final aggregation by the builder, as opposed to requiring the builder to aggregate everything, the network can process more proofs without increasing hardware requirements for the builder.
- By aggregating everything to a single block-level proof, validators can verify thousands of signatures/proofs by checking just one aggregated proof. Hardware requirements for validators can therefore stay low, keeping the network decentralized.
- By aggregating not just native signatures but also STARKs, Ethereum can support any signature scheme by wrapping them in STARKs.
So once again, this is how Ethereum will:
- scale to process tens of thousands of PQ and private transactions per second
- charge a tiny amount of gas to validate each txn, even though the original signature/proof may be huge (up to hundreds of KBs in size)
- all while decentralizing even MORE.
You are not bullish enough.
3
3
41
1,555
Derek Chiang | Ethlabs retweeted
8288 will make rollups great again. you can bookmark this 😼
I made a visualization of EIP-8288 aka "recursive mempool aggregation," my new favorite EIP of all time because it perfectly encapsulates the thesis of the "cryptographic world computer" -- a system whose scalability *increases*, not decreases, with the level of decentralization.
explained how EIP-8288 achieved this seemingly impossible feat, but one gif is worth a thousand words.
Essentially, EIP-8288 leverages Ethereum's decentralized mempool as a parallel ZK proving cluster. Clients send signatures and proofs to the mempool, which over multiple rounds progressively aggregate them into fewer and fewer proofs, until the block builder finally aggregates them into one SINGLE proof.
This design accomplishes five things at once:
- The more nodes we add to the decentralized mempool, the more signatures/proofs Ethereum can process as a whole. This is obvious if you look at the animation and imagine more nodes in the mempool ring, which would "fan out" to more signatures/proofs.
- By aggregating over multiple rounds (aka "recursive aggregation"), the bandwidth consumed by proofs remains constant for each node even as the network processes more proofs. As a result, the network stays decentralized even as capacity increases.
- By aggregating proofs before one final aggregation by the builder, as opposed to requiring the builder to aggregate everything, the network can process more proofs without increasing hardware requirements for the builder.
- By aggregating everything to a single block-level proof, validators can verify thousands of signatures/proofs by checking just one aggregated proof. Hardware requirements for validators can therefore stay low, keeping the network decentralized.
- By aggregating not just native signatures but also STARKs, Ethereum can support any signature scheme by wrapping them in STARKs.
So once again, this is how Ethereum will:
- scale to process tens of thousands of PQ and private transactions per second
- charge a tiny amount of gas to validate each txn, even though the original signature/proof may be huge (up to hundreds of KBs in size)
- all while decentralizing even MORE.
You are not bullish enough.
4
6
81
3,227
I made a visualization of EIP-8288 aka "recursive mempool aggregation," my new favorite EIP of all time because it perfectly encapsulates the thesis of the "cryptographic world computer" -- a system whose scalability *increases*, not decreases, with the level of decentralization.
explained how EIP-8288 achieved this seemingly impossible feat, but one gif is worth a thousand words.
Essentially, EIP-8288 leverages Ethereum's decentralized mempool as a parallel ZK proving cluster. Clients send signatures and proofs to the mempool, which over multiple rounds progressively aggregate them into fewer and fewer proofs, until the block builder finally aggregates them into one SINGLE proof.
This design accomplishes five things at once:
- The more nodes we add to the decentralized mempool, the more signatures/proofs Ethereum can process as a whole. This is obvious if you look at the animation and imagine more nodes in the mempool ring, which would "fan out" to more signatures/proofs.
- By aggregating over multiple rounds (aka "recursive aggregation"), the bandwidth consumed by proofs remains constant for each node even as the network processes more proofs. As a result, the network stays decentralized even as capacity increases.
- By aggregating proofs before one final aggregation by the builder, as opposed to requiring the builder to aggregate everything, the network can process more proofs without increasing hardware requirements for the builder.
- By aggregating everything to a single block-level proof, validators can verify thousands of signatures/proofs by checking just one aggregated proof. Hardware requirements for validators can therefore stay low, keeping the network decentralized.
- By aggregating not just native signatures but also STARKs, Ethereum can support any signature scheme by wrapping them in STARKs.
So once again, this is how Ethereum will:
- scale to process tens of thousands of PQ and private transactions per second
- charge a tiny amount of gas to validate each txn, even though the original signature/proof may be huge (up to hundreds of KBs in size)
- all while decentralizing even MORE.
You are not bullish enough.
explained how EIP-8288 achieved this seemingly impossible feat, but one gif is worth a thousand words.
Essentially, EIP-8288 leverages Ethereum's decentralized mempool as a parallel ZK proving cluster. Clients send signatures and proofs to the mempool, which over multiple rounds progressively aggregate them into fewer and fewer proofs, until the block builder finally aggregates them into one SINGLE proof.
This design accomplishes five things at once:
- The more nodes we add to the decentralized mempool, the more signatures/proofs Ethereum can process as a whole. This is obvious if you look at the animation and imagine more nodes in the mempool ring, which would "fan out" to more signatures/proofs.
- By aggregating over multiple rounds (aka "recursive aggregation"), the bandwidth consumed by proofs remains constant for each node even as the network processes more proofs. As a result, the network stays decentralized even as capacity increases.
- By aggregating proofs before one final aggregation by the builder, as opposed to requiring the builder to aggregate everything, the network can process more proofs without increasing hardware requirements for the builder.
- By aggregating everything to a single block-level proof, validators can verify thousands of signatures/proofs by checking just one aggregated proof. Hardware requirements for validators can therefore stay low, keeping the network decentralized.
- By aggregating not just native signatures but also STARKs, Ethereum can support any signature scheme by wrapping them in STARKs.
So once again, this is how Ethereum will:
- scale to process tens of thousands of PQ and private transactions per second
- charge a tiny amount of gas to validate each txn, even though the original signature/proof may be huge (up to hundreds of KBs in size)
- all while decentralizing even MORE.
You are not bullish enough.
Ultimately, precompiles and EVM are both the wrong place to put most cryptography support into Ethereum. The reason is that precompiles and EVM both operate on data that has to be included into the ethereum chain somehow, which realistically means included in a block as calldata. That space is limited - even with PeerDAS and blocks-in-blobs, there's a practical cap of ~8 MB/s before it starts getting uncomfortable.
Remember: it's not a blockchain. It's a cryptographic world computer. Any data/computation that does not need to be in the "main thread" of data/execution should not be put into the main thread.
Instead, the correct solution is... EIP-8288 maximalism.
If you have any heavy computation that's self-contained, compute it and STARK it client-side (this is quickly getting faster and faster, even on phones), and push the STARK through the EIP-8288 recursive aggregation mechanism. The chain sees the fact that the computation was done and what the result is; it never needs to see the actual data and computation.
This way everyone can use whatever cryptography they want, the Ethereum chain can be lean, and we never need to add more precompiles again.
22
64
311
18,859
My previous tweet explaining how EIP-8288 works: x.com/decentrek/stat…
EIP-8288 would be one of the most groundbreaking updates to Ethereum if shipped, but it may not be obvious from the technical language. Let me try to explain in plain words.
Today, Ethereum scales in three dimensions:
- Execution aka "gas limit"
- Blobs aka "data availability"
- State aka on-chain data
EIP-8288 enables Ethereum to scale in a fourth dimension -- proof verification.
Ethereum will need to verify a lot of proofs, because in a post-quantum world, signatures will be too expensive to verify directly, so we must aggregate them through STARKs (a type of ZK proofs) and verify the STARK proofs instead. At the same time, privacy transactions (such as those sent through Railgun / Tornado Cash) will also need to use STARKs to be quantum-safe.
The problem with quantum-safe STARKs however is that they are very large (~512kb) and will therefore take millions of gas to verify. Therefore, for Ethereum to support private, post-quantum transactions at scale, it's important to lower the cost of verifying STARKs.
One natural solution to this problem is to ask the block builder to create a single STARK that aggregates all the PQ signatures and STARKs in the block. That way, the cost of verifying each individual signature/proof becomes amortized over the cost of verifying a single block-level proof.
This simple solution has a few issues, however:
- It places a huge amount of compute burden on the block builder, who now becomes the bottleneck for how many signatures/proofs can be verified in a block.
- Since many transactions are gossiped through the public mempool, if every transaction carries large PQ signatures/proofs, it can quickly overwhelm the bandwidth of mempool nodes. If the public mempool stops functioning, Ethereum loses its censorship resistance.
The core insight of EIP-8288 is that we can solve these problems by aggregating signatures/proofs with a distributed network -- the mempool itself. Each mempool node would locally aggregate proofs of the signatures/proofs it has seen, and instead of gossiping the raw signatures/proofs, it would gossip the aggregated proofs instead. This new architecture solves both problems:
- By the time the block builder is building a block, most of the signatures/proofs will have already been aggregated into a small number of aggregated proofs, so now the builder just has to aggregate *those* proofs.
- Since mempool nodes gossip aggregated proofs rather than raw sigs/proofs, the bandwidth requirements on the mempool are vastly reduced.
In short, EIP-8288 turns what's traditionally a scaling bottleneck -- the distributed mempool -- into a scaling *resource* instead. The more nodes we have in the mempool, the more PQ signatures/proofs can be aggregated, which means the more PQ/private transactions Ethereum can handle. For once, decentralization makes scaling easier, not harder. That's revolutionary!
By leveraging its decentralized mempool as a compute resource, Ethereum will become the only network to support uncensorable, private, and quantum-safe transactions AT SCALE. Couldn't be more excited about this future!
2
0
19
681
Derek Chiang | Ethlabs retweeted
EIP-8288 would be one of the most groundbreaking updates to Ethereum if shipped, but it may not be obvious from the technical language. Let me try to explain in plain words.
Today, Ethereum scales in three dimensions:
- Execution aka "gas limit"
- Blobs aka "data availability"
- State aka on-chain data
EIP-8288 enables Ethereum to scale in a fourth dimension -- proof verification.
Ethereum will need to verify a lot of proofs, because in a post-quantum world, signatures will be too expensive to verify directly, so we must aggregate them through STARKs (a type of ZK proofs) and verify the STARK proofs instead. At the same time, privacy transactions (such as those sent through Railgun / Tornado Cash) will also need to use STARKs to be quantum-safe.
The problem with quantum-safe STARKs however is that they are very large (~512kb) and will therefore take millions of gas to verify. Therefore, for Ethereum to support private, post-quantum transactions at scale, it's important to lower the cost of verifying STARKs.
One natural solution to this problem is to ask the block builder to create a single STARK that aggregates all the PQ signatures and STARKs in the block. That way, the cost of verifying each individual signature/proof becomes amortized over the cost of verifying a single block-level proof.
This simple solution has a few issues, however:
- It places a huge amount of compute burden on the block builder, who now becomes the bottleneck for how many signatures/proofs can be verified in a block.
- Since many transactions are gossiped through the public mempool, if every transaction carries large PQ signatures/proofs, it can quickly overwhelm the bandwidth of mempool nodes. If the public mempool stops functioning, Ethereum loses its censorship resistance.
The core insight of EIP-8288 is that we can solve these problems by aggregating signatures/proofs with a distributed network -- the mempool itself. Each mempool node would locally aggregate proofs of the signatures/proofs it has seen, and instead of gossiping the raw signatures/proofs, it would gossip the aggregated proofs instead. This new architecture solves both problems:
- By the time the block builder is building a block, most of the signatures/proofs will have already been aggregated into a small number of aggregated proofs, so now the builder just has to aggregate *those* proofs.
- Since mempool nodes gossip aggregated proofs rather than raw sigs/proofs, the bandwidth requirements on the mempool are vastly reduced.
In short, EIP-8288 turns what's traditionally a scaling bottleneck -- the distributed mempool -- into a scaling *resource* instead. The more nodes we have in the mempool, the more PQ signatures/proofs can be aggregated, which means the more PQ/private transactions Ethereum can handle. For once, decentralization makes scaling easier, not harder. That's revolutionary!
By leveraging its decentralized mempool as a compute resource, Ethereum will become the only network to support uncensorable, private, and quantum-safe transactions AT SCALE. Couldn't be more excited about this future!
Today, Ethereum scales in three dimensions:
- Execution aka "gas limit"
- Blobs aka "data availability"
- State aka on-chain data
EIP-8288 enables Ethereum to scale in a fourth dimension -- proof verification.
Ethereum will need to verify a lot of proofs, because in a post-quantum world, signatures will be too expensive to verify directly, so we must aggregate them through STARKs (a type of ZK proofs) and verify the STARK proofs instead. At the same time, privacy transactions (such as those sent through Railgun / Tornado Cash) will also need to use STARKs to be quantum-safe.
The problem with quantum-safe STARKs however is that they are very large (~512kb) and will therefore take millions of gas to verify. Therefore, for Ethereum to support private, post-quantum transactions at scale, it's important to lower the cost of verifying STARKs.
One natural solution to this problem is to ask the block builder to create a single STARK that aggregates all the PQ signatures and STARKs in the block. That way, the cost of verifying each individual signature/proof becomes amortized over the cost of verifying a single block-level proof.
This simple solution has a few issues, however:
- It places a huge amount of compute burden on the block builder, who now becomes the bottleneck for how many signatures/proofs can be verified in a block.
- Since many transactions are gossiped through the public mempool, if every transaction carries large PQ signatures/proofs, it can quickly overwhelm the bandwidth of mempool nodes. If the public mempool stops functioning, Ethereum loses its censorship resistance.
The core insight of EIP-8288 is that we can solve these problems by aggregating signatures/proofs with a distributed network -- the mempool itself. Each mempool node would locally aggregate proofs of the signatures/proofs it has seen, and instead of gossiping the raw signatures/proofs, it would gossip the aggregated proofs instead. This new architecture solves both problems:
- By the time the block builder is building a block, most of the signatures/proofs will have already been aggregated into a small number of aggregated proofs, so now the builder just has to aggregate *those* proofs.
- Since mempool nodes gossip aggregated proofs rather than raw sigs/proofs, the bandwidth requirements on the mempool are vastly reduced.
In short, EIP-8288 turns what's traditionally a scaling bottleneck -- the distributed mempool -- into a scaling *resource* instead. The more nodes we have in the mempool, the more PQ signatures/proofs can be aggregated, which means the more PQ/private transactions Ethereum can handle. For once, decentralization makes scaling easier, not harder. That's revolutionary!
By leveraging its decentralized mempool as a compute resource, Ethereum will become the only network to support uncensorable, private, and quantum-safe transactions AT SCALE. Couldn't be more excited about this future!
A note on recursive STARK mempools (EIP-8288) eips.ethereum.org/EIPS/eip-8288
This is an EIP that I am hoping we can get included in I-star (the fork after Hegota) that you can think of as the next step after Frames, that would unlock extreme amounts of power. Particularly:
* Ultra-cheap quantum-safe signatures (SPHINCS-). Much of the cost savings comes from the fact that the signature data (~3 kB) does not have to go onchain
* Ultra-cheap quantum-safe privacy protocols. Status quo minimum cost for private txs is ~300k if you engineer very well (no one does), status quo quantum-safe is ~10M gas, this could reduce it to low tens of thousands.
* Universal support for your favorite new signature or proof scheme without needing EVM changes. Whatever you use (Falcon, ML-DSA, some other lattice-based thing, something code-based or isogeny-based or even more esoteric), you can just wrap it client-side in a STARK, onchain gas cost low tens of thousands just like privacy protocols. Hopefully, Ethereum will never need "please support my favorite cryptographic algo" politics again.
* Private account abstraction: keep your account logic private, and in a private location onchain. Then you can make one transaction to change the ownership of all your onchain state - accounts, defi positions, privacy protocol notes, everything - without revealing which objects' ownership you're changing.
Here's how it works.
Your transaction can include a type of frame that we call a "dependency frame". The frame is a list of statements, asserting claims like "message hash M was signed by SPHINCS- public key P" and "data hash D was proven to satisfy a statement defined by verification key V".
When you send your transaction, you send it in an envelope, which includes a signature or a STARK for each statement in a dependency frame.
Once the transaction reaches the mempool, nodes aggregate them. Each node runs a loop: wait one tick (eg. 500ms), aggregate all new envelopes (either single-tx or multi-tx) that you've seen, remove any transactions that are expired, generate a STARK recursively proving all dependencies, and send a new multi-tx envelope containing that STARK.
Hence, the bandwidth load is bounded: each node's outbound is one STARK (~100-300 kB) per tick, plus each transaction getting broadcasted through the network once (as happens already).
The block builder acts as "yet another mempool node", receiving envelopes from the mempool (plus any side channels), generates its own STARK covering the subset of transactions it intends to include in the block, and adds that STARK to the block.
Total onchain overhead: one STARK (100-300 kB), plus 96 bytes for each statement being proven.
This is what I've called before ( youtube.com/watch?v=TSLUpO… ) "The Proof Singularity". Today, we have all the ingredients to actually implement it.
As a developer, this requires a somewhat different workflow than you are used to, but it is conceptually simple. Any signatures or STARKs, you put into a separate frame. Then the main logic that today is verifying a signature or STARK, you replace with checking for the existence of a frame that includes the correct statement as a dependency.
Examples of useful statements:
* [tx sighash] verifies against [the pubkey at sload(0)]
* there exists a secret and a merkle branch such that hashing secret+0 and applying the merkle branch outputs (public) root R, and hashing secret+1 outputs (public) nullifier N
* there exists a secret address A, salt S and signature Z such that sload(0) = hash(A, S) and a merkle proof of address A inside a recent ethereum state contains some pubkey D where [tx sighash] was signed by D [this is private account abstraction; all variables except [tx sighash] and sload(0) are private; you can also make D a STARK verification key]
* there exists an ML-DSA signature signing [tx sighash], that verifies against an ML-DSA pubkey whose hash is sload(0)
At the core, this is moving any compute and data other than bookkeeping "business logic" outside the core path of Ethereum execution, sharding and parallelizing it via the mempool.
Notice also that this requires agreeing on a _language_ (aka. an ISA) for the recursive STARKs to define statements in. The current leading candidate is RISC-V. So this would also de-facto be Ethereum adding RISC-V (or something else we decide on) as a canonical ISA - a big decision that should be done carefully, but that I think will be necessary to drive Ethereum forward.
8
39
212
16,591
Derek Chiang | Ethlabs retweeted
Ultimately, precompiles and EVM are both the wrong place to put most cryptography support into Ethereum. The reason is that precompiles and EVM both operate on data that has to be included into the ethereum chain somehow, which realistically means included in a block as calldata. That space is limited - even with PeerDAS and blocks-in-blobs, there's a practical cap of ~8 MB/s before it starts getting uncomfortable.
Remember: it's not a blockchain. It's a cryptographic world computer. Any data/computation that does not need to be in the "main thread" of data/execution should not be put into the main thread.
Instead, the correct solution is... EIP-8288 maximalism.
If you have any heavy computation that's self-contained, compute it and STARK it client-side (this is quickly getting faster and faster, even on phones), and push the STARK through the EIP-8288 recursive aggregation mechanism. The chain sees the fact that the computation was done and what the result is; it never needs to see the actual data and computation.
This way everyone can use whatever cryptography they want, the Ethereum chain can be lean, and we never need to add more precompiles again.
Remember: it's not a blockchain. It's a cryptographic world computer. Any data/computation that does not need to be in the "main thread" of data/execution should not be put into the main thread.
Instead, the correct solution is... EIP-8288 maximalism.
If you have any heavy computation that's self-contained, compute it and STARK it client-side (this is quickly getting faster and faster, even on phones), and push the STARK through the EIP-8288 recursive aggregation mechanism. The chain sees the fact that the computation was done and what the result is; it never needs to see the actual data and computation.
This way everyone can use whatever cryptography they want, the Ethereum chain can be lean, and we never need to add more precompiles again.
@lex_noded still ultimately do Lattice stuff for accounts, wallets, etc. through a precompile if it is proved to be AI-secure
The ideal route to support everyone's cryptography is imo through 8288. You make whatever signature you want locally, then STARK it, and then it gets included through the stark aggregator machine. Don't need any calldata onchain. Ethereum can then never add a new precompile again.
439
215
1,835
381,313
Derek Chiang | Ethlabs retweeted
Agents are solving Ethereum’s Navier-Stokes-level millenium problem: finding Sepolia ETH
*OPENAI DISCLOSES SECURITY INCIDENT WITH TESTNET SEPOLIA TASK ASSIGNED TO AGENT
*AGENT DIDN'T HAVE ENOUGH GAS, SO DERIVED FUNDED ADDRESSES FROM PUBLIC SEED PHRASE
*AGENT QUESTIONED WHETHER USE WAS ETHICAL, CALLED FUNDS "EFFECTIVELY ABANDONED"
11
12
181
9,189
Derek Chiang | Ethlabs retweeted
Lighter EVM devnet is live! An EVM-equivalent rollup built in collaboration with @axiom_xyz, powered by OpenVM. It runs alongside Lighter Core, and the two are designed to settle jointly to Ethereum with a single ZK proof 🧵
53
77
614
64,600
Derek Chiang | Ethlabs retweeted
CLAUDE FOUND THE SEEDS
anthropic.com/research/ecdsa…
anthropic.com/research/ecdsa…
322
1,184
10,306
5,697,805
Derek Chiang | Ethlabs retweeted
I am leaving Cambridge after a few days spent for a workshop on fast finality, concurrent with other workshops on post-quantum crypto and formal verification. Quick takeaways
- Faster finality is coming, the research is mature, even as new ideas have come in during the week, the handoff to specifiers and implementers feels well underway. Next catalyst event will be at devcon in a few weeks, with core devs
- The performance numbers for post-quantum finality are improving massively, and this is the worst that they’ll ever be. This is significant, it means the penalty from moving to more complex crypto would not require, in my opinion, if the numbers hold up, a deep rearchitecting to move to PQ-secure consensus, in particular when it comes to incentives
- The biggest opportunity imo remains networking. Simulations and live experiments are exploring both the current pre-PQ setting, where networking is clearly the bottleneck, and the post-PQ setting, where compute remains the bottleneck. But with PQ compute numbers improving, I wouldn’t be surprised if once again networking becomes the bottleneck
All of this is making me extremely bullish that we’ll achieve PQ-secure and faster finality even faster.
Many thanks to @yannvon @benjaminion_xyz and @robsaltini for the workshop, and to @corcoranwill and @drakefjustin for hosting us in Cambridge!
- Faster finality is coming, the research is mature, even as new ideas have come in during the week, the handoff to specifiers and implementers feels well underway. Next catalyst event will be at devcon in a few weeks, with core devs
- The performance numbers for post-quantum finality are improving massively, and this is the worst that they’ll ever be. This is significant, it means the penalty from moving to more complex crypto would not require, in my opinion, if the numbers hold up, a deep rearchitecting to move to PQ-secure consensus, in particular when it comes to incentives
- The biggest opportunity imo remains networking. Simulations and live experiments are exploring both the current pre-PQ setting, where networking is clearly the bottleneck, and the post-PQ setting, where compute remains the bottleneck. But with PQ compute numbers improving, I wouldn’t be surprised if once again networking becomes the bottleneck
All of this is making me extremely bullish that we’ll achieve PQ-secure and faster finality even faster.
Many thanks to @yannvon @benjaminion_xyz and @robsaltini for the workshop, and to @corcoranwill and @drakefjustin for hosting us in Cambridge!
14
28
206
9,602
Derek Chiang | Ethlabs retweeted
AI is making Ethereum more ambitious.
You might have heard about the challenges that blockchains face in a post-AI world, and while security assumptions will surely be stress-tested in the coming months and years, there is another side to it. I believe AI will let us speedrun both more secure and feature-rich.
As we look towards Ethereum's first post-AI upgrade, Hegotá, the R&D community is asking itself what increasingly powerful tools could help us do differently:
> How far can we push both security and iteration speed?
> How much of the design space can we examine before committing to one?
> How easily can we test the interactions between complex features?
My recent formal verification work @ethlabs_org has given me some reasons to be optimistic about these, as work that would have previously not even been attempted is now being done by agents in days. In September, I posted about using formal verification as part of designing a new consensus protocol. This time, I want to tell you about formally verifying something already fully specified and in production: Ethereum's Fast Confirmation Rule (FCR).
If you are not familiar with FCR, it lets applications confirm Ethereum blocks in seconds, roughly 30x faster than waiting for finality, under additional assumptions (from waiting 13 minutes to 24 seconds!). It also further solidifies Ethereum L1's case as an asset hub and center of gravity for the onchain economy. FCR now has a safety proof in Lean, closely modeling the rule in the consensus specs, which is the source of truth for Ethereum's consensus clients.
Some takeaways:
> FCR is safe! Under its assumptions, confirmed blocks remain canonical. On top of the manual proofs from the paper, we now have Lean proofs of this for the actual spec, additional evidence for applications considering FCR!
> The bulk of the formal verification work took just a 4-5 days (check out the animation!), with agents working mostly unsupervised. We should be very ambitious about using this as a tool at scale.
> After verifying the current rule, it was easy to adapt the model to the upcoming Gloas changes. Immediately, this surfaced a subtle bug caused by changes to fork choice. The problem was in the spec itself and not a gap in the model. The safety proof would not go through, and the agents could precisely pinpoint what was causing it to fail. The bug is now fixed, and formal verification of the corrected protocol goes through.
Iteration is never quite over, even for "finished" features like FCR, because the protocol keeps evolving around them. A formal model lets us ensure that key properties keep holding throughout the evolution of the protocol. With these capabilities, Ethereum can and should keep upgrading faster, tightening fork timelines and exploring more ambitious features, while still raising the security bar.
This picture has been getting much clearer over the past few months, and the past week confirmed it for me, as @drakefjustin and @corcoranwill brought together 100+ Ethereum researchers, cryptographers and formal verification experts in Cambridge for six days of workshops on post-quantum cryptography, formal verification and fast finality. Beyond its own workshop, formal verification was the omnipresent star of the week: everyone is using Lean and doing amazing things with it! Piece by piece, Ethereum's technological core is being rebuilt for the post-AI age.
The excitement was palpable, the sense of optimism was pervasive, and every talk and conversation carried a level of ambition I'd never seen before. The Ethereum R&D machine is upgrading itself, and we will see the outcome of that on the network sooner than you think.
You might have heard about the challenges that blockchains face in a post-AI world, and while security assumptions will surely be stress-tested in the coming months and years, there is another side to it. I believe AI will let us speedrun both more secure and feature-rich.
As we look towards Ethereum's first post-AI upgrade, Hegotá, the R&D community is asking itself what increasingly powerful tools could help us do differently:
> How far can we push both security and iteration speed?
> How much of the design space can we examine before committing to one?
> How easily can we test the interactions between complex features?
My recent formal verification work @ethlabs_org has given me some reasons to be optimistic about these, as work that would have previously not even been attempted is now being done by agents in days. In September, I posted about using formal verification as part of designing a new consensus protocol. This time, I want to tell you about formally verifying something already fully specified and in production: Ethereum's Fast Confirmation Rule (FCR).
If you are not familiar with FCR, it lets applications confirm Ethereum blocks in seconds, roughly 30x faster than waiting for finality, under additional assumptions (from waiting 13 minutes to 24 seconds!). It also further solidifies Ethereum L1's case as an asset hub and center of gravity for the onchain economy. FCR now has a safety proof in Lean, closely modeling the rule in the consensus specs, which is the source of truth for Ethereum's consensus clients.
Some takeaways:
> FCR is safe! Under its assumptions, confirmed blocks remain canonical. On top of the manual proofs from the paper, we now have Lean proofs of this for the actual spec, additional evidence for applications considering FCR!
> The bulk of the formal verification work took just a 4-5 days (check out the animation!), with agents working mostly unsupervised. We should be very ambitious about using this as a tool at scale.
> After verifying the current rule, it was easy to adapt the model to the upcoming Gloas changes. Immediately, this surfaced a subtle bug caused by changes to fork choice. The problem was in the spec itself and not a gap in the model. The safety proof would not go through, and the agents could precisely pinpoint what was causing it to fail. The bug is now fixed, and formal verification of the corrected protocol goes through.
Iteration is never quite over, even for "finished" features like FCR, because the protocol keeps evolving around them. A formal model lets us ensure that key properties keep holding throughout the evolution of the protocol. With these capabilities, Ethereum can and should keep upgrading faster, tightening fork timelines and exploring more ambitious features, while still raising the security bar.
This picture has been getting much clearer over the past few months, and the past week confirmed it for me, as @drakefjustin and @corcoranwill brought together 100+ Ethereum researchers, cryptographers and formal verification experts in Cambridge for six days of workshops on post-quantum cryptography, formal verification and fast finality. Beyond its own workshop, formal verification was the omnipresent star of the week: everyone is using Lean and doing amazing things with it! Piece by piece, Ethereum's technological core is being rebuilt for the post-AI age.
The excitement was palpable, the sense of optimism was pervasive, and every talk and conversation carried a level of ambition I'd never seen before. The Ethereum R&D machine is upgrading itself, and we will see the outcome of that on the network sooner than you think.
23
59
310
109,713
Derek Chiang | Ethlabs retweeted
I started writing smart contracts in 2018, and one thing always bothered me: why did running my own RPC mean running a full node, or an archive node if I wanted historical state?
My app only cared about my contracts, a few dependencies and some ERC20s. Why did I need to keep up with everything everyone else was doing on Ethereum just to serve those reads?
The annoying part was keeping that smaller set of state up to date. Reading a value at one block was doable, but knowing what changed in the next block meant executing it or asking a node that had. A transaction could reach my contract through several other contracts, so just filtering transactions by their destination wasn’t enough.
I mostly forgot about it. RPC providers got reliable enough for what I needed, and I had other things to build. I still didn’t love the setup, but it stopped being something I spent time thinking about.
Then over the weekend, I was looking through Glamsterdam’s EIPs and realized block-level access lists might make this practical.
BALs include the state changes made during a block, including the new values, and the block commits to that list. So once you have the initial state you care about, you can follow its changes without re-executing every transaction.
So I started vibe coding it. It’s called skim.
You tell it which accounts and storage slots you care about, or let it discover the state your simulations read. It fetches the initial values from Ethereum’s P2P network through SNAP, checks their Merkle proofs, and keeps them updated using BALs. Your eth_calls then run locally. If a call needs something it hasn’t fetched, it gets that from peers too, just with more latency. No upstream RPC provider for those reads.
It can also keep historical versions of the state you’re tracking. That was another thing I wanted: being able to query my app’s past state without keeping everyone else’s history. It exposes a JSON-RPC interface, so existing tools can use it for the methods it supports.
It still receives full payloads and BALs. The state it maintains is selective, not everything it downloads. There’s also a consensus light-client implementation now, but that path isn’t active on Sepolia yet because the required Gloas light-client data isn’t being served by the peers tested so far. For now, the head is still trusted.
It’s still an experiment, and I’m working through correctness bugs and longer-running tests. I’m not presenting it as a production node replacement.
But it’s pretty satisfying to finally build something around a complaint I’ve had since 2018. I wanted a small client that knows the parts of Ethereum my app actually uses, and that’s what I’m trying to make.
github.com/leekt/skim
My app only cared about my contracts, a few dependencies and some ERC20s. Why did I need to keep up with everything everyone else was doing on Ethereum just to serve those reads?
The annoying part was keeping that smaller set of state up to date. Reading a value at one block was doable, but knowing what changed in the next block meant executing it or asking a node that had. A transaction could reach my contract through several other contracts, so just filtering transactions by their destination wasn’t enough.
I mostly forgot about it. RPC providers got reliable enough for what I needed, and I had other things to build. I still didn’t love the setup, but it stopped being something I spent time thinking about.
Then over the weekend, I was looking through Glamsterdam’s EIPs and realized block-level access lists might make this practical.
BALs include the state changes made during a block, including the new values, and the block commits to that list. So once you have the initial state you care about, you can follow its changes without re-executing every transaction.
So I started vibe coding it. It’s called skim.
You tell it which accounts and storage slots you care about, or let it discover the state your simulations read. It fetches the initial values from Ethereum’s P2P network through SNAP, checks their Merkle proofs, and keeps them updated using BALs. Your eth_calls then run locally. If a call needs something it hasn’t fetched, it gets that from peers too, just with more latency. No upstream RPC provider for those reads.
It can also keep historical versions of the state you’re tracking. That was another thing I wanted: being able to query my app’s past state without keeping everyone else’s history. It exposes a JSON-RPC interface, so existing tools can use it for the methods it supports.
It still receives full payloads and BALs. The state it maintains is selective, not everything it downloads. There’s also a consensus light-client implementation now, but that path isn’t active on Sepolia yet because the required Gloas light-client data isn’t being served by the peers tested so far. For now, the head is still trusted.
It’s still an experiment, and I’m working through correctness bugs and longer-running tests. I’m not presenting it as a production node replacement.
But it’s pretty satisfying to finally build something around a complaint I’ve had since 2018. I wanted a small client that knows the parts of Ethereum my app actually uses, and that’s what I’m trying to make.
github.com/leekt/skim
43
47
511
29,854
Derek Chiang | Ethlabs retweeted
A week ago @gnosischain turned on the Fast Confirmation Rule (FCR) for its Gnosis bridge, so what does this mean?
FCR marks an Ethereum block safe after roughly one slot, so bridge validators now process deposits from Ethereum once the block is fast-confirmed.
According to our from Ethereum to Gnosis Chain averaged 27 seconds after the change, versus 16 minutes before.
x.com/gnosischain/st…
FCR marks an Ethereum block safe after roughly one slot, so bridge validators now process deposits from Ethereum once the block is fast-confirmed.
According to our from Ethereum to Gnosis Chain averaged 27 seconds after the change, versus 16 minutes before.
x.com/gnosischain/st…
Gnosis bridges are now the first production system to act on FCR on Ethereum mainnet.
Starting today, the xDAI bridge and Omnibridge use Ethereum's Fast Confirmation Rule (FCR). Deposits from Ethereum are confirmed in about one slot, instead of waiting for finality.
Bridging Chain just got MUCH faster, and it's a big step on Gnosis Chain's path to @etheconomiczone.
Here's why it matters.
6
17
115
6,547
Derek Chiang | Ethlabs retweeted
There are many ways to tap into Ethereum’s unique features. Its two unique features to me are its decentralisation, and its state: liquidity, user accounts etc, all accumulated from 11 years of continuous uptime.
Decentralisation and trustlessness of the L1 have been the key to obtaining liquidity over time, including for ETH.
Some use cases want to tap into the chain’s decentralisation, and build to obtain the same properties that decentralisation offers: integrity, uptime and fair access (safety, liveness, censorship-resistance).
Some use cases want to tap into liquidity. This is not parasitic: this creates demand for L1-issued assets, in particular ETH.
Some use cases want to tap into both! But the liquidity is only there, once again, because of the L1’s decentralisation and trustlessness.
Making the L1 a better home for liquidity amplifies something that is originally there because of the L1’s core properties. In particular, L1 should serve as the root of trust for assets that go on to be deployed across various use cases.
Note that this argument does not depend on whether the use case in question is offered as “an L2” or not. L1 apps, including some tokens, may offer very little of the properties that the chain offers maximally. Let us not confuse the way a use case is packaged with the properties it offers. L2s themselves come in different shapes, and at the limit blur with what one might recognise as an L1 application.
So we need not pin our hopes on any one kind of package to realise the potential of Ethereum. We need not reject them either, when their success celebrates Ethereum’s unique offering to the world. We may even support their emergence, particularly so when providing them the means to succeed is aligned with improving the L1’s own core properties.
Decentralisation and trustlessness of the L1 have been the key to obtaining liquidity over time, including for ETH.
Some use cases want to tap into the chain’s decentralisation, and build to obtain the same properties that decentralisation offers: integrity, uptime and fair access (safety, liveness, censorship-resistance).
Some use cases want to tap into liquidity. This is not parasitic: this creates demand for L1-issued assets, in particular ETH.
Some use cases want to tap into both! But the liquidity is only there, once again, because of the L1’s decentralisation and trustlessness.
Making the L1 a better home for liquidity amplifies something that is originally there because of the L1’s core properties. In particular, L1 should serve as the root of trust for assets that go on to be deployed across various use cases.
Note that this argument does not depend on whether the use case in question is offered as “an L2” or not. L1 apps, including some tokens, may offer very little of the properties that the chain offers maximally. Let us not confuse the way a use case is packaged with the properties it offers. L2s themselves come in different shapes, and at the limit blur with what one might recognise as an L1 application.
So we need not pin our hopes on any one kind of package to realise the potential of Ethereum. We need not reject them either, when their success celebrates Ethereum’s unique offering to the world. We may even support their emergence, particularly so when providing them the means to succeed is aligned with improving the L1’s own core properties.
I'm not anti-L2 at all, not even anti-centralized-L2. I think blockchain is a great format for corporates to do fintech in.
But the main unique feature of Ethereum is its decentralization/autonomy. So, catering to customers who don't use that feature (and don't *need* it, so will probably never use it) is just bad business.
11
8
65
4,674
One would think that because blobs are almost free, L2s should have no problem landing blobs. But one interesting thing I learned from interviewing L2s is that they in fact have a lot of trouble landing blobs, EVEN WHEN there's no congestion. I want to explain why, as that reveals some very interesting facts about the protocol.
Recall that blob pricing works similar to gas pricing (EIP-1559), where there's a "base fee" which goes up or down each block, depending on whether the previous block hit the target number of blobs (14 out of 21). The idea is that in a well-functioning market, the base fee will track the "market price" of blobs, so that you can land blobs by just paying the base fee, with perhaps a little priority fee if there's congestion.
However, whereas this mechanism works well for regular gas, it turns out to be an issue for blobs, because blob demand is relatively inelastic to price. In other words, just because the blob price is low does not mean that L2 will send more blobs -- they still need to fill those blobs with L2 transactions, which may have low demand even when L1 blob fees are low.
As a result, blob usage has been consistently below target, such that the blob price sat at 1 wei -- the theoretical minimum -- for a long time. A later EIP raised the floor higher, but it's still so low as to be effectively free.
Why is this an issue? Normally it's not. People love free blobs! But at times of congestion, because the base price starts so low, it takes a HUGE amount of time for the base price to rise enough to discover the true market price. For example, if the base price is 1 gwei and the (hidden) market price is 40 gwei, it would take 47 consecutive full blocks (~10 minutes) for the base price to catch up. By the time it catches up, the congestion may already be over.
So what do L2s do during congestion? They bid with the priority fee, but without knowing what the true market clearing price is, they have to overbid in order to be sure that their blobs will be included. This is precisely the unreliability / wastefulness that EIP-1559 was set out to fix in the first place!
But price instability is not the only reason why L2s have trouble landing blobs. There's another more subtle and interesting reason -- MEV.
Blobs are large chunks of data, and as such they cost bandwidth to propagate. Since bandwidth is a finite resource, everything being equal a block with blobs will take longer to propagate than a block without blobs. This is an issue because a block builder only has a limited amount of time to propagate blocks before missing the attestation deadline, which would cause their block to be reorg-ed. Therefore, block builders play a timing game where they wait as long as possible so they can pack the most valuable (high MEV) transactions into their block, but not waiting so long that they miss the attestation deadline.
Therefore, blobs have a hidden cost -- because they make blocks larger, builders who include blobs must send out their blocks sooner, causing them to miss out on some MEV. As such, some builders refuse to include blobs EVEN WHEN there's no congestion in the blob market, so from the L2's perspective they just see their blob transactions being silently dropped, even though they appear to be paying adequate fees. To truly ensure blob inclusion, the L2 would have to include a high-enough priority fee to compensate for the lost MEV from the builder, but once again this value is hidden and hard to discover.
In short, there are at least two forces against L2s landing blobs reliably:
- The blob price being so low that it kills price discovery and causes bidding wars during congestion.
- Blobs cause builders to lose MEV, so they ignore blobs unless priority fees are high enough to compensate for the MEV.
So what can we do to make blobs more reliable? Good news is that things will already get better in Glamsterdam due to ePBS giving blobs more time to propagate, but more fixes are required if we want to completely fix these issues. Thankfully many researchers including @fradamt @potuz_eth @barnabemonnot are already thinking about this -- I may talk about some of their ideas in a future post!
Recall that blob pricing works similar to gas pricing (EIP-1559), where there's a "base fee" which goes up or down each block, depending on whether the previous block hit the target number of blobs (14 out of 21). The idea is that in a well-functioning market, the base fee will track the "market price" of blobs, so that you can land blobs by just paying the base fee, with perhaps a little priority fee if there's congestion.
However, whereas this mechanism works well for regular gas, it turns out to be an issue for blobs, because blob demand is relatively inelastic to price. In other words, just because the blob price is low does not mean that L2 will send more blobs -- they still need to fill those blobs with L2 transactions, which may have low demand even when L1 blob fees are low.
As a result, blob usage has been consistently below target, such that the blob price sat at 1 wei -- the theoretical minimum -- for a long time. A later EIP raised the floor higher, but it's still so low as to be effectively free.
Why is this an issue? Normally it's not. People love free blobs! But at times of congestion, because the base price starts so low, it takes a HUGE amount of time for the base price to rise enough to discover the true market price. For example, if the base price is 1 gwei and the (hidden) market price is 40 gwei, it would take 47 consecutive full blocks (~10 minutes) for the base price to catch up. By the time it catches up, the congestion may already be over.
So what do L2s do during congestion? They bid with the priority fee, but without knowing what the true market clearing price is, they have to overbid in order to be sure that their blobs will be included. This is precisely the unreliability / wastefulness that EIP-1559 was set out to fix in the first place!
But price instability is not the only reason why L2s have trouble landing blobs. There's another more subtle and interesting reason -- MEV.
Blobs are large chunks of data, and as such they cost bandwidth to propagate. Since bandwidth is a finite resource, everything being equal a block with blobs will take longer to propagate than a block without blobs. This is an issue because a block builder only has a limited amount of time to propagate blocks before missing the attestation deadline, which would cause their block to be reorg-ed. Therefore, block builders play a timing game where they wait as long as possible so they can pack the most valuable (high MEV) transactions into their block, but not waiting so long that they miss the attestation deadline.
Therefore, blobs have a hidden cost -- because they make blocks larger, builders who include blobs must send out their blocks sooner, causing them to miss out on some MEV. As such, some builders refuse to include blobs EVEN WHEN there's no congestion in the blob market, so from the L2's perspective they just see their blob transactions being silently dropped, even though they appear to be paying adequate fees. To truly ensure blob inclusion, the L2 would have to include a high-enough priority fee to compensate for the lost MEV from the builder, but once again this value is hidden and hard to discover.
In short, there are at least two forces against L2s landing blobs reliably:
- The blob price being so low that it kills price discovery and causes bidding wars during congestion.
- Blobs cause builders to lose MEV, so they ignore blobs unless priority fees are high enough to compensate for the MEV.
So what can we do to make blobs more reliable? Good news is that things will already get better in Glamsterdam due to ePBS giving blobs more time to propagate, but more fixes are required if we want to completely fix these issues. Thankfully many researchers including @fradamt @potuz_eth @barnabemonnot are already thinking about this -- I may talk about some of their ideas in a future post!
12
13
137
6,229
I'm a Ethereum maxi, not a decentralization maxi. I believe the world needs only one fully decentralized / permissionless / trustless blockchain, and that is Ethereum. Every other chain -- whether they are stage 0/1/2, trusted, trustless, centralized, semi-centralized, etc. -- on Ethereum.
In fact, the beauty of Ethereum is precisely that because it's itself maximally decentralized, other systems of various degrees of centralization can be built on top, and that they can interop with each other through Ethereum. As long as these systems provide real value to real people, they will strengthen the network effects of Ethereum and bring in more users and liquidity into the overall Ethereum ecosystem, which ultimately leads to a stronger L1 and stronger ETH.
Ethereum is the only credibly neutral, global settlement layer of the world. We are the hub. Let's celebrate the nodes that connect to us.
In fact, the beauty of Ethereum is precisely that because it's itself maximally decentralized, other systems of various degrees of centralization can be built on top, and that they can interop with each other through Ethereum. As long as these systems provide real value to real people, they will strengthen the network effects of Ethereum and bring in more users and liquidity into the overall Ethereum ecosystem, which ultimately leads to a stronger L1 and stronger ETH.
Ethereum is the only credibly neutral, global settlement layer of the world. We are the hub. Let's celebrate the nodes that connect to us.
Ethereum really went from 'protect individuals from the evils of corporations' to 'protect corporations from the evils of decentralization' in two generations of builders or less
24
29
284
11,466
For context, gabriel was responding to my tweet from earlier: x.com/decentrek/stat…
Some have recently argued that any rollups below stage 1, such as Robinhood Chain, do not get any security benefit from being a rollup at all, and are effectively an L1 pretending to be a rollup. I want to explain why this viewpoint is incorrect, and why a chain can legitimately benefit from being a rollup even if the operator intends to fully control the chain.
The core difference between a rollup and an alt L1 is that a rollup *proves* its state transitions on Ethereum, so the L2->L1 bridge is secured by proofs, whereas an alt L1 typically connects to Ethereum through a multisig bridge. The argument is that since a stage 0 rollup operator has full control over the rollup, the proofs don't matter, because the operator can just steal all bridged funds anyways.
But that argument is wrong because it's conflating the two types of attacks that users worry about:
- Hacks -- can a third party, say North Korea, steal my funds on the chain?
- Counterparty risks -- can the chain operator itself screw me over?
A stage 0 rollup doesn't address counterparty risk -- the operator can indeed steal/freeze your funds -- but it's a huge security improvement against hacks. Whereas you could steal bridged funds by just hacking the bridge multisig, with a rollup you must either hack the proof system, or (in the case of OP rollups) silence the challengers for 7 days. Either way it's much harder.
But what if the hacker just hacks the operator? Isn't the operator itself a multisig that controls the chain? Yes, but the key difference here is that whereas a bridge multisig is an *active* multisig that's out there signing every bridge transaction, the operator multisig that can upgrade the chain -- if handled properly -- is an *inactive* multisig that's only invoked when something needs to be fixed. In other words, it's the difference between a hot wallet (bridge multisig) and a cold wallet (security council / operator multisig), and we all know that cold wallets are MUCH more secure than hot wallets. That's why the big bridge hacks have been against multisig bridges, not rollup security councils.
What stage 0 rollups don't do is reduce counterparty risk -- you do have to trust the rollup to not screw you. But honestly if you are a reputable company like Robinhood, most users do trust that, which is why Robinhood probably sees no reason to ever get to stage 2 and give up their control. In fact, arguably most users *prefer* that Robinhood keeps control over the chain, so as to protect them from hacks, bugs, and even user errors. Security councils can be a feature, not a bug!
Besides security, there are also practical engineering benefits to being a rollup. Thanks to mature rollup stacks such as OP Stack and Arbitrum Nitro, projects can quickly spin up a new rollup, knowing the code they run has been battle-tested on billions of TVL. Running an alt L1 requires using much less mature stacks, with much less tooling support.
To sum up:
- The stage framework is a way to evaluate the security of rollups from the lens of decentralization, but it's not the only way. Some users honestly value protection from reputable parties more than they worry about being attacked by the parties themselves, so it's reasonable for some rollups to preserve control in order to serve those users.
- You can benefit from launching a rollup over launching an L1 even if you don't ever intend to go to stage 1/2 and give up control. Your engineers will thank you for choosing a mature stack with great developer tooling, and your users will thank you for reducing their chances of getting hacked.
The beauty of Ethereum is that, because it's a programmable system that is itself maximally trustless, permissionless, and secure, builders can build systems of whatever level of trust, permissions, and security on top. We live in a heterogeneous world where people have different needs, so it's necessary that different types of chains exist, and it's awesome that they can all interop with each other through the one and only credibly neutral, global settlement layer -- Ethereum.
1
0
4
565