Giters

shazow / shazow.net

Home Page:https://shazow.net

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

blockchain-anatomy

shazow opened this issue · comments

commented

Anatomy of a Blockchain

In recent years, as we've gained more understanding about security properties and optimizations of blockchains, we've developed more nuanced mental models for how generalized implementations operate.

Today, we often talk about three moving pieces or "layers" of blockchains: The Consensus, Data Availability, and Execution layers.

As we explore the roles of these different layers, we'll mainly compare how they operate inside Bitcoin and Ethereum, but this anatomy applies to all decentralized blockchains.

Consensus

The consensus layer is the part that decides what is correct. In Bitcoin, this is the few hundred lines of code that implement Proof of Work--a very simple and powerful consensus layer that converts electricity into security claims about each mined block.

In Ethereum 1.0, a similar Proof of Work sytem is used but with some tweaks to make it somewhat ASIC-resistant (yet more optimal for GPUs).

On the road towards Ethereum 2.0, the consensus layer was decoupled into a stand-alone Beacon Chain (operating since December 2020) that operates on Proof of Stake--converting illiquidity of capital into security claims about... itself, until The Merge upgrade happens and Ethereum stops verifying proof of work.

In principal, these consensus layers can make claims about arbitrary data. Imagine a blockchain named Blankcoin which simply takes arbitrary bytes, stores them, and provides periodic consensus security on them. Blankcoin is the extreme of this component.

Data Availability

The data availability layer is half of what our consensus layer is working so hard to secure.

In Bitcoin, the blockchain of transactions is tightly coupled with the consensus security claims made about it. Miners run full nodes and full voluntarily share the blockchain history with any peer who asks for it. When a miner produces a consensus claim, it's the hash of the latest block of transactions that haven't been included yet.

Ethereum works similarly for now, but part of the Ethereum roadmap is to further specialize the data availability component into shards that don't necessarily need to know about each other, but each shard secured by the same Beacon Chain consensus layer. The immediate next step of The Merge will migrate the current single-shard Ethereum blockchain to use the Beacon Chain as a kind of security provider instead of the original Proof of Work algorithm.

The most important job of the data availability layer is to make sure anyone who needs a piece of data that is secured by the consensus layer (to verify or interact with the blockchain) is able to acquire it without risking being blocked by censorship attacks.

Execution

The execution layer is responsible for taking inputs from the data availability layer and producing outputs that go back onto the data availability layer--in a provable and deterministic way that is also secured by the consensus layer. The execution layer is what makes "Smart Contracts" do things.

Bitcoin has an intentionally-rudimentary execution layer called Script, it's a non-Turing-complete programming language that can be used to describe moving bitcoin values from one address output to another address input, and some other more complex functions that enable things like multi-signature restrictions. Every time a miner includes a transaction, they execute these Scripts and confirm that the input state and output state is valid. Every time a full node imports a fresh block from a miner, they perform the same validation which helps prevent miners from changing the rules through hash-power attacks.

Vitalik Buterin's primary innovation in 2013 was to imagine a Turing-complete execution layer. This had made many people very angry and was been widely regarded as a bad move. A common refrain was to point at The Halting Problem of Computer Science: If you give me a Turing-complete program, it's not possible to prove whether it will ever reach a stopped state without executing it.

How can we prevent people from submitting smart contracts that run in an infinite loop and crash the whole network by using up everyone's resources? By assigning a gas cost for every operation and putting limits on the total gas cost, of course!

Ethereum's Turing-complete virtual machine (EVM) allows for arbitrarily-complicated programs to be written, executed, and secured by the Ethereum blockchain. Similar to Bitcoin: A mining node takes the current state of the blockchain, it takes some EVM bytecode from the data layer and some inputs destined for the data layer, executes them in a deterministic way while accounting for gas costs at every step, and either produces a valid resulting state that gets written to the data layer or aborts due to running out of gas.

Before rollups were developed, a key component of the Ethereum 2.0 roadmap was "execution shards"--the idea was similar to data shards, except each shard could run its own virtual machine that is not the EVM. This approach had a lot of challenges, such as composability of programs across shards.

Turns out, rollups give us all of the best parts of execution shards without any of the downsides!

commented

Appendix

Modular Blockchain

TODO: Talk about the newer term "modular blockchain"

Rollups

Let's set some context and make a few assumptions:

  • These points apply to any blockchain that is capable of hosting rollups.
  • Let's define peak "transaction efficiency" as some hypothetical implementation of a virtual machine (VM) designed by an omniscient software engineer who was able to anticipate all desirable usecases. This hypothetical VM is able to perform transactions at the lowest possible resource cost without sacrificing any decentralized security properties.

One of my favourite recent posts from Vitalik is his explainer on rollups, it's extremely informative and it makes an important point very clear: We can use rollups are a method for specializing the smart contract execution onto its own layer that is hosted by a data availability layer and secured by a consensus layer.

TODO: Write the rest of the owl. One-line summary: Rollups decouple the execution environment (like a "guest VM") into modular implementations that can achieve optimal on-chain compression regardless of the host virtual machine.