End of an Era: The Blockchain Trilemma
The triangle is not a law. It is an artifact of one architectural decision made early and copied everywhere.
The trilemma is not a law of nature. It is the symptom of a single architectural decision, made early and copied everywhere, that the industry has mistaken for the thing itself. To accept the trilemma as a tradeoff space is to concede that the underlying design is sound and that the only remaining work is to tune the dials, to argue about which corner of a triangle to stand in. The question that never gets asked is why the triangle exists at all.
The blockchain trilemma claims that a blockchain can optimize for at most two of three properties, scalability, security, and decentralization, and must sacrifice the third. It is presented as a fundamental constraint, a law that any distributed ledger must obey. It is treated as the starting premise of nearly every serious evaluation of the technology. Tradeoffs are familiar, and so the framing is absorbed without resistance, and the rest of the analysis proceeds inside it.
Mistakes Were Made
Strip a blockchain down to its function and you find something the distributed systems field has understood for forty years: a replicated state machine. A set of independent nodes agree on an ordered log of commands, then each node applies those commands in the agreed order to arrive at identical state. This is Lamport and Schneider, formalized in the 1980s, long before Bitcoin and long before anyone attached the word “crypto” to it. The pattern has a name in the literature. It is called order-execute. First the transactions are ordered through consensus, then every node executes every transaction in that order.
The defining choice of nearly every blockchain in production is that ordering and execution are fused into a single global act. The network does not merely agree on the sequence of transactions. It requires every validating node to re-execute every transaction to confirm the resulting state. Agreement is achieved through redundant computation. The same work is done thousands of times across the entire network, and this redundancy is treated as the price of trust minimization.
Lessons in Distributed Systems
In distributed systems design, the separation of ordering from execution is a first principle.
Maurice Herlihy, one of the most decorated theorists in concurrent and distributed computing, wrote a paper in Communications of the ACM in 2019 whose thesis is that much of the blockchain world is a disguised, sometimes distorted, mirror-image of the distributed computing world. This was not a compliment. The field had spent decades establishing what is possible and what is impossible in distributed consensus, and the blockchain industry was re-deriving fragments of that knowledge slowly, painfully, and often incorrectly, while ignoring the body of results that already existed. Consensus protocols had been the focus of decades of research, with a literature full of algorithms and impossibility results across many models of computation. None of this is a secret.
The execution-first lineage, the chains that dominate the discourse and the conference circuit, were built monolithically anyway, because the incentives rewarded the version that was legible to customers over the version that was correct. The property blockchain genuinely offers, the minimization of required trust, is invisible to most of the people tasked with selling it, so it was repackaged as whatever the customer found legible. Composability. Efficiency. Decentralization. Each repackaging severed the claim from the one condition under which it holds.
Separation of Concerns
The insight that dissolves the triangle rather than balancing it is this: A system needs consensus on sequence. It does not need every node on the planet to recompute every result to know what that sequence implies. Furthermore, those responsible for ordering should not do so interpretatively.
Once ordering and execution are understood as distinct, the trilemma stops looking like a law and starts looking like an artifact. A design that establishes order without demanding universal re-execution does not sit at some clever point on the triangle, trading a little decentralization for a little throughput. It is not on the triangle at all.
Verification-First Architecture
Hyperledger Fabric’s architects studied the same distributed-systems principles Herlihy was pointing to, and they drew the right conclusion from it: if execution is a separate concern from ordering, then re-execution is a method for reaching agreement, not a requirement of it. The quintessential job is verification, not execution.
Hyperledger Fabric made that realization years ago, and it was the right one. What capped it is Fabric verifies the entire global key-space: each transaction’s validity is entangled with the whole ledger’s concurrent activity. The check itself is cheap. The surface it runs against is global, and that is what produces a wide staleness window and conflicting-transaction aborts that appear as soon as throughput rises. Fabric softens this by being permissioned, a known endorser set and a known ordering service letting it tolerate a design that would not survive in an open setting.
That is the precise line between Fabric and Zenon’s block-lattice and metaDAG. A block-lattice is a relational data structure in which each account maintains its own chain and the structure as a whole encodes causal ordering rather than artificially forcing every transaction into a serial global sequence. The metaDAG preserves that partial order while providing instant finality and minimalistic consensus ordering required for global coordination. The metaDAG is one of Zenon’s key innovations distinguishing it from the previous generation of DAGs.
The Zenon design enables execution where computation is abundant, at the edge device, rather than execution replay in network core. Computers are everywhere. Monolithic architecture assumes that the world computer looks like thousands of computers charging a premium for scarce computation because execution is conflated with ordering. Zenon’s block-lattice and separation of concerns enables abundant computation and blockspace anywhere, every time.
Meanwhile, block-lattice users only verify what is actually relevant, rather than the entire global state. This is a categorically different verification surface, and the surface is the whole game when it comes to the scalability required for IoT, feeless global payments, and the agentic economy.
This does not abolish the staleness window. Any system in which independent parties act concurrently on shared references has some window where two actions could conflict, because that is what concurrency is. The claim is narrower and more defensible: narrowing the conflict surface is an architectural choice, and the dual-ledger structure narrows it to its minimum, so verification is cheap and local rather than global and redundant.
Monolithic order-execute has the broadest possible conflict surface. Fabric narrowed it but still verifies against a near-global snapshot. Zenon’s block-lattice and metaDAG is the structural optimization for lightweight verification: only verify what you need to execute.
No Limits
The trilemma is the product of a decade-old architectural mistake drawn carefully enough that a generation mistook it for the boundary of what is possible. Separating ordering from execution is the move that erases it, and Zenon’s block-lattice + metaDAG architecture is live and running.