(1/28) zkVMs, Verifiable Compute and the Next Chapter of Blockchain

Everything from cloud computing to the internet itself relies on explicit and implicit trust. But it's 2024, trust is breaking down, and the world is hungry for a trustless solution

A beginners guide to zkVMs

(2/28) Imagine we have a very computationally intense program - one so resource intensive that we wouldn't be able to run it on any personal devices or consumer hardware that we could realistically get our hands on.

Fortunately, we live in 2024; the cloud has us covered!

(3/28) Now let's say this program is responsible for some very high stakes, irreversible decisions. Whatever this program says will have massive consequences on your life.

Are you comfortable executing on someone else's hardware? Do you trust the result?

(4/28) Bottom line: whoever controls the hardware ultimately controls the program. Maybe they can manipulate the execution to influence the result, or maybe they just ignore the result and send you whatever they want you to do.

Distributed computing inherently requires trust.

(5/28) Fortunately, we have a solution: through the magic of zero-knowledge cryptography (ZK), we are able to implement verifiable computing.

ZK allows us to generate proofs that mathematically guarantee that an output resulted from the honest execution of unaltered code.

https://x.com/LogarithmicRex/status/1867243214706721202

(6/28) Think of a verifiable program running in the cloud - ever answer would also come with a proof. 

Once verified, we know with mathematically certainty that the answer was the honest, based on the code we provided. Any manipulation at all, and the proof would not verify.

(7/28) This sounds great, but it's very challenging to implement. The basics of the underlying cryptography is incredibly arcane and difficult... and that's just the start.

In order to create these systems, you need to build a structure specific to each verifiable program.

(8/28) These structures (circuits) are a mathematical representation of the verifiable program. They are very abstract and difficult, and even tiny code changes require brand new circuits.

A major bottleneck to verifiable compute is the time/expertise needed to create circuits.

(9/28) For a long time, the consensus understanding was that in order to make verifiable compute a reality, we needed to drastically reduce the effort it takes to create a circuit. 

But here’s a thought: what if we created a circuit for an entire virtual machine?

(10/28) Let’s take a quick detour to discuss virtual machines (VMs). A VM is a software-based emulation of a physical computer that exists inside a host computing environment.

Imagine running a program that models a Windows-based computer inside of your Macbook (eg @parallels).

https://x.com/LogarithmicRex/status/1574208089661747200

(11/28) The important thing to understand about VMs:

- they are programs that emulate a fully functioning computer 
- like a fully functional computer, they are capable of running other programs 

So here’s the provocation: what if we could use ZK to make a VM verifiable?

(12/28) A verifiable VM eliminates the circuit bottleneck by altering what is being proved. 

When using an application-specific circuit, you are proving the program’s execution. 

When using a VM-specific circuit, you are proving the VM executed whatever program it was given. 

(13/28) Think like this: a verifiable VM generates a proof that gaurentees that the VM is acting honestly. Consequently, whatever program is given to the VM was executed honestly.

If the VM honestly executed the program, then we know the program itself was executed honestly.

(14/28) While this all may feel like trivial word play, the ramifications are huge: if you can build a circuit for a VM, you don’t need to build circuits for specific programs.

In other words, a single circuit can prove every program. 

Bottleneck solved.

(15/28) At first, this paradigm was applied to blockchain-specific VMs, specifically @ethereum’s EVM. 

This is the idea behind zkEVM rollups: prove the validity of every transaction and smart contract by proving the entire EVM. Verification guarantees the rollups validity.

https://x.com/logarithmicrex/status/1569334975614582784?s=46&t=a-_27ks-01Qh0N76AOoudw

(16/28) However, the EVM is… weird. Like all blockchain VMs, it makes very specific design choices that are non-applicable/don’t make sense in regular computing. 

For example, gas is a meaningless concept (with no analogies) when you’re using your iPhone. 

(17/28) What if, instead of using ZK to make a blockchain-specific VM verifiable, we made a generic VM verifiable? What if all programs (blockchain or not) could be proved by executing it within this generic VM?

The answer: we can! We call them zkVMs!

(18/28) A zkVM is a VM designed to execute any/all programs that can run on a regular computer while automatically generating ZK proofs. 

Proof verification gives mathematical certainty that whatever came out of the zkVM would be exactly the same as running the program locally.

(19/28) There are a couple of factors in selecting which VM to use for a zkVM. 

First, it must be generic and support the full spectrum of compute - it must be able to be execute all programs. 

Second, it should be lightweight. More features make circuit design more difficult. 

(20/28) The third is the most nuanced - it must be open source. 

Remember, the ZK proof only gives you certainty that the VM executed the code according to the rules of the VM. If the VM isn’t open source, we don’t know the rules… valid execution may not be fair execution. 

(21/28) Fortunately, we don’t need to design a VM from scratch… the open source community has been working on this exact problem since at least 2010. 

RISC-V is a widely used, open standard that defines how software communicates with hardware. 

https://x.com/LogarithmicRex/status/1875236095459496226

(22/28) RISC-V refers specifically to how software is translated to a language that a CPU can understand, but it’s all we need in order to build a lightweight (but fully expressive) VM. 

And so, if we can create a circuit around RISC-V, we’ve essentially created a generic zkVM. 

(23/28) In fact,  we have multiple working implementations in production... some transforming how blockchain technology is built and works today.

Particularly notable are @RiscZero, SP1 ( @SuccinctLabs ) and Jolt ( @a16zcrypto ) - although many teams are shipping aggressively.

(24/28) Just like all things in life, zkVMs are not just a free lunch - there’s a significant cost vs running the same code in a non-zk VM.

Generating a proof costs time and resources, and a zkVM is generating a proof for EVERYTHING. 

(25/28) Fortunately, we live in the ZK renaissance! ZK tech (specifically performance) is progressing at a rate that has surprised even the most bullish researchers…

…and things are only accelerating.

Soon the overhead of ZK will be unnoticeable and irrelevant. 

(26/28) When ZK is cheap and automatic, all programs can be verified by any computational environment. Verification allows us to effectively project computation; once verified, it's like it was done locally.

The bigger disparity between environments, the more powerful the effect

(27/28) For me, the most exciting application is for blockchain. By nature, blockchains are inherently resource-constrained. ZK/verifiable compute allows us to project any type or scale of computation directly on-chain.

ZK is what will transform Ethereum into the World Computer.

https://x.com/LogarithmicRex/status/1861788897057140780

(28/28) In summary, a zkVM is a general purpose computing platform, capable of executing any program a regular computer can, which automatically generate ZK proofs. 

Proof verification gives mathematical certainty a program was executed honestly - as if it was executed locally.


zkVMs: The Next Chapter of Blockchain

(1/13) A Beginners Guide to RISC-V

There are many standards that define how software and hardware communicate, but one is becoming increasingly central. RISC-V is one of the most important standards in modern computing, offering full functionality with open-source values.

(2/13) There's a time-honored tradition in computer science: when learning a new language the first program you create is "Hello World." All you need to do is get your computer to display the phrase "Hello, World!" on its screen.

Here's an example for python:

(3/13) While languages like python are use for humans to use and understand, they are far too complex for the hardware that underlies all computing.

But a CPU speaks in 0s and 1s - it cannot understand a complicated, abstract command like "print."

(4/13) We solve this through a series of intermediate languages. Code is translated into simpler forms until the same program is expressed into terms the CPU can understand.

Thus, developers can focus on functionality and abstract away the specifics of how a CPU works.

(5/13) An Instruction Set Architecture (ISA) is the interface between software and hardware, defining the machine-level instructions a CPU can execute and how programs are able to accesses them. 

Once complied to an ISA, a program can run on any CPU that uses that same ISA.

https://x.com/LogarithmicRex/status/1870152417029042519

(6/13) There are many different ISAs - some tied to particular hardware, focused on specific functionality, or optimized for power efficiency. 

In practice, there are only a few ISAs in widespread use: x86 (specific to @intel), ARM (used by @apple, @Qualcomm, etc) and RISC-V.

(7/13) Like all ISAs, RISC-V (pronounced "risk-five" defines the instructions that a processor can execute but does not specify the physical design of the processor itself.

If a software system is built to compile to RISC-V, it can run on any CPU that implements RISC-V.

(8/13) Invented in 2010, RISC-V has a distinct feature that sets it apart most ISAs (particularly the widely used ISAs): RISC-V is an open standard.

Similar to open source, an open standard is publicly accessible, freely usable and open to contributions/development by anyone.

(9/13) While there are many nuances and details regarding RISC-V, the reason it has exploded in popularity and is becoming more and more important is because it is an open standard.

An open standard democratizes processor design, lowers costs, and fosters innovation.

(10/13) RISC-V is also becoming more relevant because of virtual computing.

Virtual machines (VMs) are software-based emulations of a physical computer that run inside of a host-system. A VM offers an isolated computing environment that behaves like a real-world computer.

https://x.com/LogarithmicRex/status/1574208089661747200

(11/13) With ISAs, implementing hardware in software isn't particularly challenging. 

You simply build a platform around the ISA (just like a normal computer), and instead of feeding it into a real CPU, you give it to a program that emulates a CPU using the same ISA.

(12/13) Because RISC-V is a generic interface for CPUs, it is perhaps the most popular ISA to form the foundation of a VM. 

And thanks to its open source-nature, RISC-V can be implemented permissionlessly, modified/extended quickly and deployed without paying any royalties. 

(13/13) So here's what you need to know: RISC-V is...

- an ISA, which is the interface between software and hardware (or virtual hardware) 
- an open standard and generally considered the generic interface for hardware
- is growing in popularity, particularly in virtual computing

A Beginner's Guide to RISC-V

(1/14) The Line Between Hardware and Software: Instruction Set Architecture (ISA)

Do CPUs understand Javascript? How does Python run in silicon? Is there a machine language and how does it relate to a language like Rust?

Your guide to the boundary between physical and virtual.

(2/14) A computer processor (CPU) is the like the brain of a computer; it is responsible for performing calculations and executing computation. 

Think of a CPU like the computer's: it processes instructions and instructs the system to enable it to run programs/applications.

(3/14) Let's say you've written a program. You've (probably) written it in a modern language like Python or Rust. These languages offer massive benefits, including being easy for humans to write, review and understand.

The problem: the are MUCH too complex for a CPU.

(4/14) The underlying computer science is pretty intense, but suffice to say that the CPU is manipulating circuits and transistors to make your computer work.

The CPU speaks in the language of electricity - something as illegible to us as programming languages are to CPUs.

(5/14) One of the great magics of computer science is abstraction, a process where solutions are found for simple problems, thereby paving the way for solutions of more complex problems.

Abstraction allows us to hide implementation specifics from the next layer of development.

(6/14) In this process, we use a series of intermediate languages, facilitated by specialized programs called compilers/interpreters.

Here's the appropriate level of abstraction: human written code (eg python) is compiled to machine language, which is then executed by CPUs.

(7/14) Machine language refers to the instructions a processor can execute, and therefore operates within the direct reference to the parts of the CPU.

For example, machine language uses registers - specific pieces of silicon within the CPU.

(8/14) The set of instructions/operations that define the boundary between computer science abstractions and physical hardware is called an Instruction Set Architecture (ISA).

Once code has been compiled to an ISA, it's passed into the CPU and executed as physical changes.

(9/14) ISAs are incredibly low level and not intended for/interpretable by humans. Just take a look at what the (incredibly important) RISC-V architecture looks like.

Even still, the ISAs are an important abstraction as the layer that provides the foundation for computing.

(10/14) There are many different ISAs out there, some far more relevant than others. While it's not too important to categorize them, the main distinction is CISC vs RISC architectures. 

tl;dr CISC implements many specific operations, RISC hyper optimizes a reduced set.

(11/14) So let's return to the magic of abstraction: think about designing the language of the CPU without worrying about the specifics of how the instructions are implemented on the physical chip.

Once we've built that interface, we can implement it virtually.

(12/14) While ISAs are designed for hardware, they can also be implemented to run in software. This allows us to create virtual machines (VMs) - emulations of physical computers.

VMs provide isolated computing environments hosted inside of another computing environment.

https://x.com/LogarithmicRex/status/1574208089661747200

(13/14) Taking a step back, there is an important line in computing between virtual abstraction and real-world hardware. ISAs are the language the mark this boundary.

By virtualizing these ISAs as programs, we can emulate computers in software to create virtual machines.

(14/14) ISAs are not just relevant to how a program is communicated to a physical CPU, but also how a program is communicated to a VM.

Put simply: an ISA defines an instruction set that defines a computational environment, one that can be implemented in silicon or code.

Instruction Set Architecture (ISA)

(1/24) Blockchain Basics: Crypto-Economic Security

Distributed computing requires trust; next-gen is decentralized computing, built with systems designed for the anonymous internet. Systems that replace a trust with a economic rationality.

Unpacking the core of crypto.

(2/24) Trust is the confidence or belief in the reliability, truth, or capability of a person or system to act as expected, even in the absence of complete information or oversight.

We all inherently understand trust - we've been swimming in it since the day we were born.

(3/24) In the real world, trust comes from long-term interpersonal relationships and/or through the threat of consequences, and is built on a foundation accountability.

Accountability is the mechanism that sustains and strengthens trust; without it, trust is impossible.

(4/24) So here's the big question: how can you develop trust between people that are completely anonymous and can effectively disappear at any time, for any reason?

Throughout human history, this question is basically irrelevant... but the Internet changed everything.

(5/24) The internet connects people and servers across the globe, but by its very nature the internet does not enforce identity or provide any mechanism for accountability. 

And so, the inevitable question: how can we create trust on the internet?

(6/24) The first answer was simple: we simply bootstrap off of the trust we have in the real world. Instead of trusting individuals across the internet, we rely on centralized actors that exist (and can be held accountable) in the real world.

Let's quickly look at an example.

(7/24) Say I want to sell something that you want to buy. Instead of figuring out how I can trust you to send me the money after I sent you the object (or vise versa), we both agree to trust a company like @eBay.

The reason we trust eBay: if things get bad, we can sue.

(8/24) The problem: what if the centralized actor isn't really trustworthy? Or what happens if the system used to hold them to account isn't able to hold them to account?

We can point to countless examples, but let's just skip to the big one: the Global Financial Crisis (GFC).

https://x.com/LogarithmicRex/status/1560502871329648641

(9/24) The GFC taught us a harsh but important lesson: sometimes trust just does not cut it. We need systems built on something stronger than trust.

Fortunately, in the very moments when the GFC was unfolding, we were given a path forward. Satoshi Nakamoto gave us @Bitcoin.

(10/24) The conversation around Bitcoin has always been about digital money, going back to the original conversations even before the genesis block.

But the underlying innovation that made Bitcoin so important had nothing to do with money... it had to do with trust.

(11/24) Bitcoin is made up of a network of anonymous, completely untrusted computers which coordinate to share the same internal state.

The system that keeps these computers in sync is called a consensus mechanism. Bitcoin uses Proof of Work (PoW) for its consensus mechanism.

(12/24) PoW relies on a verifiable and computationally expensive process to keep these computers in sync. 

Importantly, PoW guarantees that cheating the system requires significantly more compute power than the entire Bitcoin network and is incredibly expensive.

(13/24) This is the idea behind crypto-economic security: a system is crypto-economically secure if cheating the system costs significantly more than the potential gain from cheating.

PoW achieves this via difficult, power intensive computation, but we have other solutions. 

(14/24) The most prominent consensus mechanism is Proof of Stake (PoS). Developed after PoW, PoS is actually easier to understand and therefore is the best way to illustrate crypto-economic security. 

So let's quickly walk through the specifics of how PoS works.

(15/24) To participate, every party must first put something of economic value into escrow. Once they've "staked" this capital, they are given permission to affect the system.

If a participant cheats, their capital is forfeited, usually destroyed (a process called slashing).

(16/24) In order for a PoS system to be effective, the amount of staked capital (or, more specifically, the amount of capital forfeited) must significantly exceed the total possible proceeds from cheating.

Put another way, it must be economically irrational to cheat.

(17/24) This dynamic is how crypto-economic security changes what trust means for a system secured by a consensus mechanism. 

You never have to trust the other parties to be good actors, you just need to trust them to be rational actors.

(18/24) Let's return to our example from tweet 7 - I want to sell something that you want to buy, over the internet. Before Satoshi, this required a centralized facilitator.

But let's design a system that enables this transaction from peer-to-peer without trust... trustlessly.

(19/24) Our decentralized eBay will implement PoS, meaning we both have to put capital at stake in order to participate.

The item I'm selling costs $100 - decentralized eBay will require both you and I to deposit a greater amount into escrow. Let's say $250.

(20/24) Once our capital is escrowed, I can first send you the item. I don't need to trust you're a good person and going to send me money - I know with certainty that if you don't, you'll lose even more money than you owe me.

Or you can send me the money first - same dynamic.

(21/24) I have no idea who/where you are, but because of the capital we've put at stake, we're able to transact trustlessly over the internet. 

Pulling this all together, crypto-economic security is a concept that helps us build systems that "don't" require trust. 

(22/24) Before we go... you may be asking yourself, "why is it called crypto-economic trust? What's the crypto part?"

The answer: accountability. In order for crypto-economic systems to work, we need to apply punishments (and rewards) to individuals.

(23/24) Cryptography allow us to represent a digital identity that is completely independent from our real-world identity. 

Thus, crypto-economic systems can still do the work needed to replace a trust with a rationality assumption (eg slashing) over the anonymous internet. 

(24/24) In summary: crypto-economic security is a tool deployed to replace trust in an anonymous system. PoW achieves this by maximizing the compute cost, PoS by triggering slashing.

A system is secure when the cost of cheating is higher than the potential profit of cheating.

Crypto-Economic Security

(1/24) Fragmentation on @ethereum

The rollup-centric roadmap is the clear path for upgrading Ethereum into the World Computer, but achieving the vision requires working through issues. The most obvious: rollups create fragmentation.

The problem and a peak into the future.

(2/24) Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer. 

https://x.com/LogarithmicRex/status/1592309373732151296

(3/24) Ethereum is still young and evolving, but the rollup-centric roadmap provides a north star to the endgame.

Rollups - independent, high performance blockchains - settle to Ethereum, borrowing Ethereum's sense of property rights and economic security.

https://x.com/LogarithmicRex/status/1591614638138875905

(4/24) The rollup-centric roadmap was adopted in 2020, and so today we are in the awkward teenaged-years. We're seeing a lot of excitement and promise, and huge amounts of success.

But we're also experiencing a lot of growing pains. 

(5/24) One of the more obvious: today's implementation of the rollup-centric roadmap has created a very fragmented Ethereum. 

For example, even though @base and @arbitrum are both rollups that settle to Ethereum, they are essentially independent from each other. 

(6/24) The first layer of fragmentation: capital that's deposited on one rollup is walled-off from capital that's deployed in another. Liquidity gets siloed by rollups.

Liquidity has very strong network effects - less liquidity leads to worse outcomes and attracts less users.

https://x.com/LogarithmicRex/status/1562577628741046272

(7/24) But the problems don't stop at liquidity, fragmentation materially degrades what's possible on blockchains.All blockchains are shared computing environment; people can build off of anything anyone else has built. 

And fragmentation introduces significant barriers.

(8/24) Let's say I have capital in an LP position on @AerodromeFi (Base), and I notice that a juicy liquidation just became available on @Dolomite_io (Arbitrum).

Ideally, I'd like to withdraw from Aerodrome, liquidate from Dolomite and deposit the proceeds back into Aerodrome.

(9/24) If Ethereum was really the World Computer and rollups were really an extension of Ethereum, you would think that Ethereum would be able to facilitate this multi-step transaction.

Unfortunately, as of today it doesn't. Each rollup is its own walled garden.

(10/24) Achieving our Areodrome-Dolomite example is possible today… but it’s clunky and requires trusting centralized facilitators.

High level: the txn must be broken down into subsets that interact with one chain at a time and a 3rd party handles cross-chain communication.

(11/24) First, we submit a txn on Base to withdraw from Aerodrome.

Then, we use a third party bridge to move funds to Arbitrum.

Next, we submit a txn on Arbitrum to Dolomite.

After that, we use a third party to move funds back to Base.

Finally, we deposit back into Aerodrome.

(12/24) Not only is this very complicated, manual and slow, there is a lot of risk implicit in this flow.

Most obviously, we must trust centralized bridges to move capital around. We just have to send it money and hopefully the bridge fulfills their end of the bargain.

(13/24) More subtle are the risks associated with timing. It takes time for each of these legs to finalize, and the next leg cannot begin until them.

What happens if while we are waiting for our Base->Arbitrum bridge to settle someone else snags the juicy Dolomite liquidation.

(14/24) Let's contrast with an example entirely contained on a single blockchain (Ethereum). Replacing Aerodrome with @CurveFinance and Dolomite with @aave, we want to achieve the same goal.

Withdraw from Curve, liquidate from Aave, return capital to Curve.

(15/24) When all of these actions take place on a single blockchain, we can stitch together all of the legs into a single atomic transaction. 

Atomic implies that it cannot be split; either the entire transaction succeeds or the entire transaction fails.

(16/24) This example illustrates blockchain's superpowers: financial instruments can composed into transactions/structures that are greater than the sum of its parts.

Most of De-Fi and the other apps that drove the last cycle were built on the power of atomic composability.

https://x.com/LogarithmicRex/status/1563228298276065280

(17/24) Which finally brings us to the big question: "if atomic composability was one of the most important features of Ethereum, and the rollup-centric roadmap doesn't support atomic composability, was the rollup-centric roadmap a mistake?"

The answer: of course not!

(18/24) To repeat myself one more time, rollups are still a very new technology and the rollup-centric roadmap is very young. As we progress down the roadmap, rollups will evolve to natively support atomic composability.

Let's spend a few tweets looking into the future! 

(19/24) To address the fragmentation of liquidity, we're building liquidity layers. These layers will aggregate liquidity in a form that allows rollups to maintain sovereignty without siloing capital. 

Want to dig deeper? Check out my interview with @0xPolygon's @_bfarmer!

https://x.com/StrangeH2OPod/status/1759594089883066658

(20/24) Atomic composability requires developing shared sequencers. Sequencers refers to the group responsible for order that transactions are executed on a blockchain.

If a single sequencer is responsible for multiple chains, atomic composability is back on the table.

https://x.com/LogarithmicRex/status/1867594181071556827

(21/24) The easiest approach to shared sequencing is to share a centralized sequencer. This is best illustrated with @Optimism's Superchain, a tech stack that allows anyone to quickly and easily deploy their own rollup.

All Superchain rollups can opt into shared sequencing.

(22/24) But centralized sequencing is not credibly neutral. Aside from the importance for Ethereum, it's also critical to ensure rollups are interested in sharing sequencers.

Solution: decentralize the sequencer!

For more check out my interview with @EspressoSys's @benafisch.

https://x.com/ExpansionPod_/status/1823876473188466691

(23/24) Solutions like Espresso or @AstriaOrg are huge steps forward towards achieving the vision of the rollup-centric roadmap, but they require creating decentralized, credibly neutral networks.

But here's a thought: we already have a decentralized, credibly neutral network...

(24/24) Which brings us to the endgame solution: based rollups. Coined by @drakefjustin, based rollups will deliver decentralized sequencing using the most decentralized node-set in existence: Ethereum's.

Want to learn more? Make sure to follow, based rollup threads are coming!

Fragmentation and the Rollup-Centric Roadmap

(1/20) Rollup Essentials: Pre-Confirmations

Pre-confirmations are a reality of all rollups, although they are well hidden with today's centralized sequencers. But to understand the future of @ethereum, you need to understand this key dynamic.

A beginners guide to pre-confs.

(2/20) Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer. 

https://x.com/LogarithmicRex/status/1592309373732151296

(3/20) Ethereum is still young and evolving, but the rollup-centric roadmap provides a north star to the endgame.

Rollups - independent, high performance blockchains - settle to Ethereum, borrowing Ethereum's sense of property rights and economic security.

https://x.com/LogarithmicRex/status/1591614638138875905

(4/20) As always with such young tech, there is a lot of exciting developments in the world of rollups. One particularly exciting field is the world of sequencers.

Sequencers refers to the group responsible for order that transactions are executed on a blockchain.

https://x.com/LogarithmicRex/status/1867594181071556827

(5/20) Today, the most sequencers are centralized, controlled by the company that created/operate the rollup. For example, @base's sequencer is controlled by @coinbase. 

Think of this phase as training-wheels; centralized sequencers allow us to defer a lot of hard problems.

(6/20) For example, centralized sequencers allows us to ignore Ethereum's time problem.

Like all blockchains, time passes one block at a time. For Ethereum, this means that actions can only be taken once every 12 seconds. For rollups, 12 seconds is an eternity. 

https://x.com/LogarithmicRex/status/1577863907976220672

(7/20) Block times have a huge impact on performance - the faster the blocks, the more transactions per second. Rollups use block times much faster than Ethereum.

The problem: until a rollup's history is posted on-chain, it's not final. What about the time between each block?

(8/20) Once a rollup sends a copy of its history, it settled to Ethereum. At this point whatever happened on the rollup is final; it cannot change without sacrificing billions of dollars of $ETH. 

Before settlement, a transaction on an L2 is just a promise from the sequencer.

(9/20) Below are just a few rollups that are live today (all with centralized sequencers). 

Between Ethereum blocks, you are explicitly trusting the rollups operator to maintain whatever sequence they promised you.

(10/20) We call this promise a pre-confirmation (pre-conf). With most sequencers today, things are simple. The sequencer just issues them, and the users just trust them. 

And, so far, that’s worked great! @OffchainLabs, @coinbase, etc have proven to be trustworthy! 

(11/20) But let’s sketch a scenario that would test the promise of a pre-conf.

Imagine a sequencer pre-confed a trade then ended up going sour 3 blocks later. Maybe the trader offers them $1B to undo it before it settles to Ethereum.

Do you still trust your sequencer?

(12/20) The whole point of blockchain is to replace trust with cryptography and economic guarantees - especially for the World Computer.

By deploying crypto-economic principles, we can remove the trusted aspects of the rollup-centric roadmap. 

Our first stop: Proof of Stake!

(13/20) In order to participate in Proof of Stake (PoS) everyone must place something with economic value into escrow. Cheating is punished by destroying more value in escrow than it’s possible to extract from the system.

No trust needed when cheating results in losing money.

(14/20) PoS originally came to prominence as a method of coordinating blockchain networks, but the idea has been extended (particularly by @sreeramkannan).

The insight behind @eigenlayer is that PoS is generalizable to any centralized problem.

https://x.com/logarithmicrex/status/1572094840619532288?s=46&t=a-_27ks-01Qh0N76AOoudw

(15/20) Here’s how we can apply PoS to pre-confs: in order to become a sequencer, and operator must put capital into escrow. 

If the operator issues a pre-conf but does not settle that transaction to Ethereum, code will automatically destroy some/all of the escrowed capital. 

(16/20) Let’s say an operator places $1B into escrow and it’s all destroyed for even a single instance of breaking the pre-conf promise.

PoS tells us that pre-confs for transactions worth less than $1B are as good as settled. The promise is backed by very real consequence.

(17/20) The big questions behind any pre-conf are “is this pre-conf backed by an economic penalty” and, if so, “how much?”

If the answer to the first is “no,” then the system isn’t credibly neutral and inherently requires you to trust it. 

(18/20) Today, no rollups secure their pre-confs with crypto-economic security; we are still early, and our current solutions serve today’s needs perfectly fine.

But Ethereum is ever going to engulf global finance, we will need to move passed trusted pre-confs.

Pre-Confirmations

(1/27) Sequencing: From the Fundamentals to Based Rollups

Looking to understand sequencing? Hearing that the rollup-centric roadmap was a mistake? Thinking @ethereum's execution-layer might be compromising on centralization?

All about sequencing and where we are headed!

(2/27) Although blockchains come in many different shapes and sizes, (in general) they all have the same goal: decentralized computing.

The objective is to create a single shared computing environment that exists across many/hundreds/thousands of computers simultaneously.

(3/27) Users interact with blockchains via transactions (txns), which contain instructions that tell the blockchain how to update the shared environment.

For example: if I want to buy $COW, I send a txn to @ethereum that instructs Ethereum to trade my $ETH for the $COW token.

(4/27) In traditional computing, if I want my computer to take an action, I send a command and the computer executes it.

Things change, however, in the blockchain world because we have a shared computing environment. One person's txn may affect the results of the next person's.

(5/27) Let's imagine two users: Alice wants to sell 1,000,000 $ETH and Bob wants to sell 1 $ETH. Both submit a txn.

The order of which txn gets executed first is incredibly important, particularly for Bob. If Alice's txn goes first, he will get SIGNIFICANTLY less for his $ETH.

(6/27) Or let's say that both Alice and Bob notice that @TrustlessState put his @cryptopunksnfts up for sale and submit a buy txn at the exact same moment.

There's only one CryptoPunk #1118, so only one txn can be successfully executed; the other will fail. 

(7/27) One more example: let's say Alice wants to buy $REX, a niche token with little liquidity.

If Bob moves quickly, he can sandwich Alice's txn with his own, first buying and then selling $REX. Result: Alice will buy $REX at a worse price, and Bob will extract the delta.

(8/27) The last example is important as it is the prototypical example of Maximum Extractable Value (MEV). 

Though out of scope of this thread, MEV is very important to blockchains because it represents an existential threat. Left unsolved, MEV will render a blockchain worthless.

https://x.com/LogarithmicRex/status/1556448359300227072

(9/27) The point is that the sequence by which pending txns are executed is extremely important in determining their outcome, and ultimately state of the shared computing environment. 

And so, a critical questions for all blockchains is "who controls the sequencing?"

(10/27) There are many approaches, implementations and nuances between the different ways different blockchains approach sequencing. So much so that it is very challenging to speak in broad strokes.

So let's get specific and look at Ethereum.

(11/27) Ethereum is made up of a network of computers (nodes) that each run a local copy of the shared computing environment. These copies are kept perfectly in sync via a process called Proof of Stake (PoS).

Once every 12 secs (slot), a node is selected to progress Ethereum.

https://x.com/LogarithmicRex/status/1579594609855934465

(12/27) This node (called the proposer) is responsible for viewing all of the pending txns and selecting which ones will be executed in which order. 

They bundle up the sequence of txns and package them into a block, which is then sent to and executed locally on all other nodes.

(13/27) [SIDE NOTE] In practice, the proposer isn't usually doing the sequencing. Though they have the option to do it locally, building a block is hard, and so most proposers defer to a third party called a builder.

Even still, proposers are ultimately in charge of sequencing. 

https://x.com/SalomonCrypto/status/1570557757190983680

(14/27) The point: during every slot, the proposer is the only person deciding the sequence of txns. On a per-slot basis, sequencing is centralized to a specific node.

However, the proposer changes every single slot... so over time, sequencing is distributed across all nodes.

(15/27) Therefore, we say that Ethereum has decentralized sequencing; no one party controls the sequencing of transactions.

Decentralized sequencing is one of the cornerstones of Ethereum’s credible neutrality. And credible neutrality is what makes Ethereum valuable. 

https://x.com/logarithmicrex/status/1559920665477595137?s=46&t=a-_27ks-01Qh0N76AOoudw

(16/27) However, decentralized sequencing isn’t the only way to build a blockchain. Take, for example, rollups.

Rollups are high performance blockchains that operate their own computing environments while settling to Ethereum.

Today, most rollups use centralized sequencers.

https://x.com/LogarithmicRex/status/1591614638138875905

(17/27) Rollups are a new technology, and so today are deployed with training wheels. For the most part, rollups exist as protocols that are entirely owned and operated (and profited) by the companies that built them.

The tech is new, the stakes are enormous - it makes sense.

(18/27) Most rollups have explicit intensions/plans to eventually decentralize, achieve credible neutrality and become a true extension of Ethereum, but by their nature decentralization isn't critical.

Regardless, the result is that most rollups have centralized sequencers.

(19/27) This means that every rollup block is sequenced by the same computer, controlled by a single party. They get to decide which txns are included, which are banned and what order they appear in.

It also means that 100% of the fees generated are captured by that same party.

(20/27) Rollups are still a young technology - there are definitely growing pains, but the roadmap is beginning to come together with a lot of huge implications for sequencing.

So let's end this thread with a few hints on what's coming next!

(21/27) First - efforts to progressively decentralize sequencers. Decentralization isn't just a tech problem, it's an ownership/control problem. 

@arbitrum is the biggest rollup leading in this aspect, actively working towards decentralized sequencing.

(22/27) Today's implementation of centralized sequencing has another consequence: isolated sequencing. Each rollup has its own sequencer, so that that means txns can't operate cross-rollup.

This is the underlying cause of Ethereum's current fragmentation problem.

(23/27) Fortunately, there has been an incredible amount of work bringing shared sequencing to life. 

Companies like @AstriaOrg and @EspressoSys have built the complex infrastructure needed to not only operate shared sequencing, but make cross-rollup composability easy. 

(24/27) The big problem with shared sequencing: you need to have people that are willing to share. It always comes down to the same thing: who has control and who is going to capture the value?

If you think about it long enough, you'll realize we already know the answer...

(25/27) The more credibly neutral a shared sequencer, the more rollups will join and the stronger the network effects will be.

There's one blockchain that maximizes for decentralization, that actually achieves credible neutrality...

and it already has decentralized sequencing.

(26/27) Coined and championed by @drakefjustin, based rollups will leverage Ethereum's decentralized node-set to serve as a shared, decentralized, credibly neutral sequencer.

Danksharding was the first upgrade to directly support rollups. Based rollups will be the next.

(27/27) The idea is complicated, but electric. It's far too much for just one thread. Make sure to follow and keep an eye out. I'll be writing much more on based rollups, how they work and how they will change Ethereum.

But I promise you, it's worth it. 

Blockchain Sequencing

(1/20) Verifiable Computing 101

While zero-knowledge cryptography is named for its privacy-preserving properties, it is quickly becoming apparent that it is critically important for so much more.

A guide to verifiable computing & the enabling technologies that make it possible  

(2/20) Imagine a very complicated financial model that analyzes a huge amount of data and provides a recommendation for whatever security/asset the user provides.

Example: ask it "should I buy $BTC?" and the model will crunch billions of datapoints and reply "yes" or "no."

(3/20) Importantly, this hypothetical model is so computationally intense that it requires a high-end server farm. Even if it could fit it on a personal computing device, it would take days/weeks to run.

While you may have access to the model, someone else needs to run it.

(4/20) So here's the scenario... let's say you are contemplating a huge decision, you send a question off to this model and you get back the response "yes."

Do you trust that result? Enough to put your entire financial future on the line?

(5/20) What if the operator wasn't exactly a good faith actor? What if s/he noticed that you asked about a specific asset that they have a large position in... and that encouraging you to buy in would greatly benefit them?

How do you even know the operator ran the model at all?

(6/20) This hypothetical is a very simple example of distributed computing - a field that deals with the use of interconnected computers (nodes) working together to perform a task or solve a problem. 

These computers share computational resources to achieve a common goal.

(7/20) The early days of distributed computing didn't need to address the trust problem. The companies that built distributed infrastructure own the entire network, and the companies that built on them managed trust via contracts and the legal system.

But we are in a new era.

(8/20) In 2008, Satoshi Nakamoto introduced a new paradigm of distributed computing; @Bitcoin was built with the belief that distributed networks can operate without trust entirely, replacing it with cryptography.

The math is verifiable by anyone - no trust needed.

(9/20) Although the field has progressed rapidly since Bitcoin's genesis, the core insight remains unchanged: trustless distributed computing is possible with the use of verifiable cryptography.

So, let's return to our hypothetical and ask "how can cryptography replace trust?"

(10/20) In order to understand the solution, we first need to cover the tools... specifically zero-knowledge cryptography (ZK).

Tl;dr ZK enables one party to prove the truth of a statement to another without revealing any underlying information.

https://x.com/LogarithmicRex/status/1569119846952235008

(11/20) As it was originally understood, ZK was a technology that was specifically applicable to encryption and privacy. But blockchain technology has introduced an entirely new application for ZK - verifiable compute.

More poignantly, ZK enables trustless, verifiable compute.

(12/20) The details get very complicated very fast, but high level we can create programs that automatically generate ZK proofs as they execute.

Once verified, these proofs mathematically guarantee that the program was not manipulated and the result was honestly generated.

(13/20) In distributed computing, the most important property of ZK is succinctness. 

A succinct proof is small (often less than few KBs, regardless of the underlying computation/data) and fast (verification requires much less time/computation than the underlying computation). 

(14/20) Returning to our hypothetical - imagine the financial model generates a ZK proof alongside every result. 

Now when asked “should I buy $BTC,” the model replies with a result and a proof. Verifying the proof gives you mathematical certainty the result came from the model. 

(15/20) Because the ZK proof is succinct, verification is MUCH smaller and faster than actually running the model - well within the capabilities of a personal computer.

And so while maybe you can’t run the model locally, you can prove you would get the same result if you did. 

(16/20) While is very important to understand the concept/power of verifiable compute, you can understand the same paradigm from a different angle…

ZK allows us compress computation, so that low resource environments can leverage big computation as if it was run locally. 

(17/20) Look at our example; our devices cannot run the model themselves, but ZK allows us to import the result with mathematical guarantees that we’d get the same result if it could be run locally.

Thus, the intense computation is projected into our low-resource devices.

(18/20) Unlocking the insight that ZK can compress computation and project it into resource constrained environments is the key to understand the revolution happening in blockchain.

ZK is how resource-constrained @ethereum evolves into the World Computer.

https://x.com/LogarithmicRex/status/1861788897057140780

(19/20) Back in 2008, Satoshi deployed cryptography to replace the trust needed to create an application-distributed system. 

With ZK we can generalize this concept. Any distributed system can be redesigned as trustless by replacing trust with cryptography.

(20/20) In summary, verifiable compute leverages zero-knowledge cryptography to mathematically prove that a specific result was the honest, un-
manipulated result of a specific program. 

With verifiable compute, we can build robust, untrusted distributed systems.

Verifiable Computing

(1/18) @ethereum Upgrades: EIP-2935

Ethereum's road to becoming the World Computer requires achieving statelessness. The path is long and full of incremental steps, but is being worked on with every hard fork. EIP-2935 is one of those upgrades, brining us another step closer.

(2/18) Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer. 

https://x.com/LogarithmicRex/status/1592309373732151296

(3/18) Each node operates two pieces of software:

The execution client operates Ethereum's computing environment - the Ethereum Virtual Machine (EVM). 

The consensus client is responsible for securing Ethereum and keeping all nodes in sync - via Proof of Stake (PoS).

https://x.com/LogarithmicRex/status/1589807499804176384

(4/18) The EVM is a Turing complete virtual machine - any computation that can run on any computer can also happen in the EVM.

But unlike any other computing environment, the EVM is cryptographically secured. At any moment, anyone can mathematically verify the EVM's validity.

(5/18) For example - let's say I want to see exactly how much $ETH has been deposited into @aave. In normal computing, I'd have to request the answer and trust whoever gave it to me.

In Ethereum, not only can I query the result myself, I can cryptographically prove its correct.  

https://x.com/LogarithmicRex/status/1862168230686867611

(6/18) At a very high level, this works by storing the internal state of the EVM in a data structure that allows users to prove individual pieces of data without storing the whole dataset.

The block hash (imagine the block's digital fingerprint) is the anchor for these proofs.

(7/18) If you dive deeper, you'll learn that the EVM stores its state in a Patricia-Merkle Trie. This data structure allows for the efficient storage and verification of a large dataset.

The takeaway: a proof verifies that a piece of data exists by analyzing the root hash.

https://x.com/LogarithmicRex/status/1567638108937801728

(8/18) As a result, in order to cryptographically verify the state of Ethereum, you need to have a copy of the block hash (which is effectively the root hash of the EVM's Merkle trie during that block).

Without the block hash, you cannot verify anything.

(9/18) Ethereum was designed with an implicit assumption: every client has convenient access to all recent block hashes.

Because the only way to access Ethereum (directly) is to run an execution client, this is always true - this data as a natural consequence of operations.

(10/18) Today, everything works fine... but Ethereum is not yet the World Computer. To get there, Ethereum must support stateless clients.

When stateless, you'll be able to directly interact with Ethereum via cryptography - no need to store the EVM locally.

https://x.com/LogarithmicRex/status/1588752629118554112

(11/18) While a stateless Ethereum does allow for direct, trustless access to the World Computer, it will need to be facilitated by 3rd parties.

Specifically, someone will need to provide the proof data (also called witness data) that can be used to prove the state of the EVM.

(12/18) The problem: as of today Ethereum cannot provide you with the most recent block hashes. Again, the implicit assumption is that you already have them.

And so, whoever gives you the witness data must also give you the block hash. 

(13/18) Consider this: let's say I want to prove my own balance in the EVM, but both the witness data and the block hash come from a 3rd party.

The proof guarantees the data exists in the block hash... but it does not guarantee the block hash is a valid state of the EVM. 

(14/18) Which brings us to EIP-2935, a change that stores the most recent block hashes inside of the EVM and then allows users to retrieve them.

If the block hash (the anchor of the proof) comes directly from Ethereum, we know it represents the EVM.

https://eips.ethereum.org/EIPS/eip-2935

(15/18) EIP-2935 will not have implications for the everyday use of Ethereum immediately, but it is an important upgrade on the road to a stateless EVM.

A stateless EVM is not only much more scalable, it is the foundation of a trustless, verifiable World Computer.

(16/18) There are still many changes needed to achieve statelessness. Most significantly, we need to replace the Patricia-Merkle trie with a data structure  that is more efficient.

But we are marching down that path, and EIP-2935 is an important stepping stone to get there.

(17/18) Today, users (generally) interact with Ethereum through an intermediary like @infura_io. We are explicitly trusting Infura to operate on our behalf.

With a stateless World Computer, we will still use these services to gather witness data, but we will verify ourselves.

(18/18) In summary, EIP-2935 stores the most recent block hashes within the EVM and allows users to directly query them.

This upgrade is important in allowing trustless verification of Ethereum and paving the way for statelessness and the endgame of the World Computer.

Ethereum Upgrade: EIP-2935

(1/21) @ethereum Upgrades: EIP-7742

Today, Ethereum hardcodes blob maximum in both the consensus and execution layer, breaking the separation-of-concerns paradigm that defines Ethereum's two-layer architecture. EIP-7742 fixes this and paves the way for the Danksharding future.

(2/21) Ethereum is the World Computer, a single, globally shared computing platform that exists in the space between a network of 1,000s of computers (nodes). 

These nodes are real computers in the real world, communicating directly from peer to peer. 

https://x.com/LogarithmicRex/status/1592309373732151296

(3/21) Unfortunately, it's impossible to build a single shared computer that is both decentralized (the foundation of credible neutrality) and performant enough to service the entire world.

And so, the question is how do we upgrade today's Ethereum into the World Computer?

(4/21) But blockchains are not typical computers... the question isn't "how much computation can Ethereum process," it's "how much value can Ethereum settle."

This is the idea behind the scaling roadmap: move execution off-chain while retaining settlement on-chain.

https://x.com/LogarithmicRex/status/1564316505650524160

(5/21) Rollup-centric roadmap tl;dr: rollups are independent blockchains that execute txns and post the result on Ethereum, which maintains the final record of ownership.

The Danksharding upgrade introduced blobs - abundant, cheap space for rollups to post critical data.

https://x.com/LogarithmicRex/status/1591614638138875905

(6/21) In March 2024, the Dencun hard fork brought the first major upgrade to Ethereum to natively support rollups: EIP-4844 aka Proto-Danksharding.

Fun fact: Danksharding is named after @dankrad; Proto-Danksharding  is named after @protolambda.

https://www.eip4844.com/