On the Internet, nobody knows you're a dog. eng @commonwarexyz
Brooklyn, NY
- Tweets 322
- Following 0
- Followers 894
- Likes 2,125
Brendan K. Chou retweeted
A million TPS isn’t cool. You know what is? A billion TPS.
Meet Bajillion, @commonwarexyz’s new optimistic clearing protocol for (free) internet-scale payments.
commonware.xyz/blogs/clearin…
13
18
233
20,132
Brendan K. Chou retweeted
Simplex, now running at 200Hz in the @commonwarexyz Library.
Sequence blocks faster than a typical monitor can refresh.
Finalize them across a global network in 300ms.
11
12
122
14,194
Simplex can now produce blocks as fast as its leader can build them.
In a global deployment with 50 validators, it sustained 200 blocks per second with 300ms finality.
One block every 5ms.
commonware.xyz/blogs/pipelin…
6
5
21
1,545
Two ideas make this possible:
Stable Leader keeps one leader for several views in a row.
Optimistic Validation lets validators vote on the next block while earlier blocks are still moving through consensus.
No need to wait for a network round trip between blocks.
2
4
10
943
Super excited to be joining Commonware and to keep working on blockchain data problems.
The throughput a chain built on Commonware can generate is at a different scale from what we think of today as high TPS. We used to put blockchain data on Postgres. The chains grew, the industry started adopting OLAP indexers. Now the state of the art has finally outgrown web2 DBs.
Exoware will be the data backbone that can keep up.
After 8 years (!!!) of finding ways to make blockchains usable at The Graph, I'm excited to share that @leoyvens has joined @commonwarexyz to build out @exowarexyz.
There are only a handful of folks that have been working with blockchain data for longer than Leo (especially in Rust 🦀). We believe a team of folks who have "done it before" is unreasonably productive and after meeting Leo, I immediately knew he'd be just that (and that was before he found a number of bugs in my SQL engine 2 days in).
I look forward to watching him shape Exoware into a product developers can't live without (again).
2
3
22
1,748
Brendan K. Chou retweeted
After 8 years (!!!) of finding ways to make blockchains usable at The Graph, I'm excited to share that @leoyvens has joined @commonwarexyz to build out @exowarexyz.
There are only a handful of folks that have been working with blockchain data for longer than Leo (especially in Rust 🦀). We believe a team of folks who have "done it before" is unreasonably productive and after meeting Leo, I immediately knew he'd be just that (and that was before he found a number of bugs in my SQL engine 2 days in).
I look forward to watching him shape Exoware into a product developers can't live without (again).
10
7
128
11,571
Brendan K. Chou retweeted
Multimmit: The New State-of-the-Art for Global, Fast, and Scalable Consensus
For the first time (including DAGs), the fastest path for finality isn't reserved for the leader (or anchor).
All data broadcast concurrently by validators can finalize in 2δ (optimal for 5f+1).
12
24
119
23,567
Brendan K. Chou retweeted
With the latest @commonwarexyz release, Constantinople now hits:
240k tps + 100MB/s [+3.42x ] (2.5M accts)
200ms views [-30%]
300ms finalization [-25%]
on:
16 vCPU/gp3 storage (20% CPU usage)
50 validators (us-west/east)
(still just inline propose/verify -> no DSMR yet 👀)
11
4
72
9,026
Brendan K. Chou retweeted
70k tps
400ms finalization
browser light client
native passkey wallet
… now available (for free)
24
43
233
64,712
This is not only a huge win in performance, it is also IMO a particularly mathematically beautiful result
It turns out, this trade wasn't necessary.
@roberto_bayardo designed a new tree structure that bounds proof size for active state to only **2 hashes** above the optimal structure (a balanced binary Merkle tree):
1
4
344
Brendan K. Chou retweeted
Excited to share that I’ve joined @commonwarexyz! Looking forward to working with the amazing team to bring advanced cryptography onchain.
First order of business is scaling SNARK verification onchain: we managed to verify over 500K proofs in 0.75s without recursion or external preprocessing!
More details below 👇
22
9
156
12,094
Brendan K. Chou retweeted
One important technical item that I forgot to mention is the proposed switch from Casper FFG to Minimmit as the finality gadget.
To summarize, Casper FFG provides two-round finality: it requires each attester to sign once to "justify" the block, and then again to "finalize" it. Minimmit only requires one round. In exchange, Minimmit's fault tolerance (in our parametrization) drops to 17%, compared to Casper FFG's 33%.
Within Ethereum consensus discussions, I have always been the security assumptions hawk: I've insisted on getting to the theoretical bound of 49% fault tolerance under synchrony, kept pushing for 51% attack recovery gadgets, came up with DAS to make data availability checks dishonest-majority-resistant, etc. But I am fine with Minimmit's properties, in fact even enthusiastic in some respects. In this post, I will explain why.
Let's lay out the exact security properties of both 3SF (not the current beacon chain, which is needlessly weak in many ways, but the ideal 3SF) and Minimmit.
"Synchronous network" means "network latency less than 1/4 slot or so", "asynchronous network" means "potentially very high latency, even some nodes go offline for hours at a time". The percentages ("attacker has <33%") refer to percentages of active staked ETH.
## Properties of 3SF
Synchronous network case:
* Attacker has p < 33%: nothing bad happens
* 33% < p < 50%: attacker can stop finality (at the cost of losing massive funds via inactivity leak), but the chain keeps progressing normally
* 50% < p < 67%: attacker can censor or revert the chain, but cannot revert finality. If an attacker censors, good guys can self-organize, they can stop contributing to a censoring chain, and do a "minority soft fork"
* p > 67%: attacker can finalize things at will, much harder for good guys to do minority soft fork
Asynchronous network case:
* Attacker has p < 33%: cannot revert finality
* p > 33%: can revert finality, at the cost of losing massive funds via slashing
## Properties of Minimmit
Synchronous network case:
* Attacker has p < 17%: nothing bad happens
* 17% < p < 50%: attacker can stop finality (at the cost of losing massive funds via inactivity leak), but the chain keeps progressing normally
* 50% < p < 83%: attacker can censor or revert the chain, but cannot revert finality. If an attacker censors, good guys can self-organize, they can stop contributing to a censoring chain, and do a "minority soft fork"
* p > 83%: attacker can finalize things at will, much harder for good guys to do minority soft fork
Asynchronous network case:
* Attacker has p < 17%: cannot revert finality
* p > 17%: can revert finality, at the cost of losing massive funds via slashing
I actually think that the latter is a better tradeoff. Here's my reasoning why:
* The worst kind of attack is actually not finality reversion, it's censorship. The reason is that finality reversion creates massive publicly available evidence that can be used to immediately cost the attacker millions of ETH (ie. billions of dollars), whereas censorship requires social coordination to get around
* In both of the above, a censorship attack requires 50%
* A censorship attack becomes *much harder* to coordinate around when the censoring attacker can unilaterally finalize (ie. >67% in 3SF, >83% in Minimmit). If they can't, then if the good guys counter-coordinate, you get two non-finalizing chains dueling for a few days, and users can pick on. If they can, then there's no natural schelling point to coordinate soft-forking
* In the case of a client bug, the worst thing that can happen is finalizing something bugged. In 3SF, you only need 67% of clients to share a bug for it to finalize, in Minimmit, you need 83%.
Basicallly, Minimmit maximizes the set of situations that "default to two chains dueling each other", and that is actually a much healthier and much more recoverable outcome than "the wrong thing finalizing".
We want finality to mean final. So in situations of uncertainty (whether attacks or software bugs), we should be more okay with having periods of hours or days where the chain does not finalize, and instead progresses based on the fork choice rule. This gives us time to think and make sure which chain is correct.
Also, I think the "33% slashed to revert finality" of 3SF is overkill. If there is even eg. 15 million ETH staking, then that's 5M ($10B) slashed to revert the chain once. If you had $10B, and you are willing to commit mayhem of a type that violates many countries' computer hacking laws, there are FAR BETTER ways to spend it than to attack a chain. Even if your goal is breaking Ethereum, there are far better attack vectors.
And so if we have the baseline guarantee of >= 17% slashed to revert finality (which Minimmit provides), we should judge the two systems from there based on their other properties - where, for the reasons I described above, I think Minimmit performs better.
Finally, the block building pipeline.
In Glamsterdam, Ethereum is getting ePBS, which lets proposers outsource to a free permissionless market of block builders.
This ensures that block builder centralization does not creep into staking centralization, but it leaves the question: what do we do about block builder centralization? And what are the _other_ problems in the block building pipeline that need to be addressed, and how? This has both in-protocol and extra-protocol components.
## FOCIL
FOCIL is the first step into in-protocol multi-participant block building. FOCIL lets 16 randomly-selected attesters each choose a few transactions, which *must* be included somewhere in the block (the block gets rejected otherwise). This means that even if 100% of block building is taken over by one hostile actor, they cannot prevent transactions from being included, because the FOCILers will push them in.
## "Big FOCIL"
This is more speculative, but has been discussed as a possible next step. The idea is to make the FOCILs bigger, so they can include all of the transactions in the block.
We avoid duplication by having the i'th FOCIL'er by default only include (i) txs whose sender address's first hex char is i, and (ii) txs that were around but not included in the previous slot. So at the cost of one slot delay, only censored txs risk duplication.
Taking this to its logical conclusion, the builder's role could become reduced to ONLY including "MEV-relevant" transactions (eg. DEX arbitrage), and computing the state transition.
## Encrypted mempools
Encrypted mempools are one solution being explored to solve "toxic MEV": attacks such as sandwiching and frontrunning, which are exploitative against users. If a transaction is encrypted until it's included, no one gets the opportunity to "wrap" it in a hostile way.
The technical challenge is: how to guarantee validity in a mempool-friendly and inclusion-friendly way that is efficient, and what technique to use to guarantee that the transaction will actually get decrypted once the block is made (and not before).
## The transaction ingress layer
One thing often ignored in discussions of MEV, privacy, and other issues is the network layer: what happens in between a user sending out a transaction, and that transaction making it into a block? There are many risks if a hostile actor sees a tx "in the clear" inflight:
* If it's a defi trade or otherwise MEV-relevant, they can sandwich it
* In many applications, they can prepend some other action which invalidates it, not stealing money, but "griefing" you, causing you to waste time and gas fees
* If you are sending a sensitive tx through a privacy protocol, even if it's all private onchain, if you send it through an RPC, the RPC can see what you did, if you send it through the public mempool, any analytics agency that runs many nodes will see what you did
There has recently been increasing work on network-layer anonymization for transactions: exploring using Tor for routing transactions, ideas around building a custom ethereum-focused mixnet, non-mixnet designs that are more latency-minimized (but bandwidth-heavier, which is ok for transactions as they are tiny) like Flashnet, etc. This is an open design space, I expect the kohaku initiative @ncsgy will be interested in integrating pluggable support for such protocols, like it is for onchain privacy protocols.
There is also room for doing (benign, pro-user) things to transactions before including them onchain; this is very relevant for defi. Basically, we want ideal order-matching, as a passive feature of the network layer without dependence on servers. Of course enabling good uses of this without enabling sandwiching involves cryptography or other security, some important challenges there.
## Long-term distributed block building
There is a dream, that we can make Ethereum truly like BitTorrent: able to process far more transactions than any single server needs to ever coalesce locally. The challenge with this vision is that Ethereum has (and indeed a core value proposition is) synchronous shared state, so any tx could in principle depend on any other tx. This centralizes block building.
"Big FOCIL" handles this partially, and it could be done extra-protocol too, but you still need one central actor to put everything in order and execute it.
We could come up with designs that address this. One idea is to do the same thing that we want to do for state: acknowledge that >95% of Ethereum's activity doesn't really _need_ full globalness, though the 5% that does is often high-value, and create new categories of txs that are less global, and so friendly to fully distributed building, and make them much cheaper, while leaving the current tx types in place but (relatively) more expensive.
This is also an open and exciting long-term future design space.
firefly.social/post/lens/814…
232
114
849
272,043
Brendan K. Chou retweeted
Today, we're excited to share that a large number of @commonwarexyz primitives are now "stable" (with 93% test coverage and Long-Term Support guarantees):
commonware.xyz/blogs/is-it-r…
8
15
89
10,150
Brendan K. Chou retweeted
Today, I’m excited to (finally) welcome Minimmit to the @commonwarexyz Library.
Implemented independently by both @GTE_XYZ and @vex_0x, Minimmit clobbers our benchmarks:
[USA]: 51ms blocks (-40%) | 87ms final p75 (-35%)
[Global]: 142ms blocks (-30%) | 269ms final p75 (-15%)
21
30
207
68,655
Brendan K. Chou retweeted
I wrote an article explaining Minimmit consensus:
dankradfeist.de/tempo/2025/1…
31
28
224
38,263
On prediction markets with N outcomes, I heard they run a separate YES/NO orderbook for each outcome, and rely on arbitrageurs to "balance" such markets. If this is the case, why? Why are exchanges not doing the implied matching atomically to increase liquidity?
1
3
359
Lastly, this doesn't seem particularly computationally complex for the matching engine. For a single prediction market, it can simply maintain the current sum of the best bids and the current sum of the best asks for each of the N outcomes. This is an O(1) operation on order placement. If the sum of the best bids would go over 1, or the sum of the best asks would go over N-1, then match orders across all outcomes into an implied trade. This is O(N) but you are matching N orders.
1
2
220
I can't currently think of a way to efficiently serve the full "implied orderbook" but at least the touch-price can be served extremely efficiently with minimal overhead. The touch-amount could be served if a min-heap (over order size at the touch) is maintained, though this is less efficient than O(1) per order (could be O(log n))
1
125