Tezos — a self-amending crypto-ledger

The five-minute read

One action, walked through

1. A baker submits a protocol amendment as a proposal hash.
2. In the proposal period, stake-weighted votes select which proposal, if any, proceeds.
3. A ballot period asks voters to accept or reject. The paper's thresholds are part of the design, not a default.
4. A testing period runs the candidate so the network can watch it before it is sovereign.
5. After the delay, the amendment becomes the protocol. Nodes that did not install the code simply stop understanding the chain.

The argument, unpacked

What has to be true

• Most stake that bothers to vote is not captured, and quorum rules are high enough to mean something.
• Voters can obtain and review the protocol code behind a proposal hash. A vote on an unseen blob is only a vote on a blob.
• The testing period is long enough to reveal a broken amendment, and short enough that the network still bothers to wait.
• Client software is updated before adoption. The chain cannot run code the node does not have.

What happened after the paper

Tezos adopted a series of amendments through this procedure, and replaced its original consensus sketch with Tenderbake, a Byzantine fault tolerant finality layer. The 2014 paper predicts the existence of that kind of change. It does not describe Tenderbake.

What to check before you use the idea

• What are the quorum and the supermajority, and who actually cast the last vote?
• How long is the delay between a yes and the code becoming law?
• Can a user see the amendment in source form, or only a hash?
• Which consensus protocol is live now, as opposed to the one sketched in 2014?

Terms

Self-amendment

A protocol rule for replacing the protocol, including the voting rule itself, by an on-chain procedure.

Baker

A delegate who produces blocks and votes with stake assigned to them.

Proposal hash

The identifier of an amendment. The vote is about this identifier. The code is what it points at.

Adoption delay

The waiting period after a successful vote, meant to let dissenters leave before the new rule binds.

The problem the paper names

Forks that change the rules are political events coordinated off to the side. Tezos argues that the procedure for adopting a protocol change should itself be a protocol, so the ledger has a stated way to replace its own code.

What the design proposes

• A shell distinguishes the consensus-relevant protocol from the governance process that can swap it.
• Baking is the block production role. Delegation lets a holder assign rights without transferring ownership.
• Formal specification is part of the pitch: amendments should be arguments about a mathematical object, not only about a client repository.

How the mechanism is specified

• Stakeholders vote through a series of periods. The paper's process and the live governance process should not be assumed identical.
• Security deposits and penalties are how the design makes baking expensive to abuse.
• Self-amendment does not mean every social dispute fits in a vote. It means the rule-change path is explicit.

What this page does not treat as proven

• The 2014 paper is not the current Tezos protocol hash.
• Delegation creates representatives. The paper does not prove that representatives stay aligned with holders.
• Formal methods reduce a class of bugs. They do not replace key management or an honest specification.

Why a venture studio still reads it

A venture that expects to change settlement rules after launch should show the amendment path before the first version, not after the first argument. That is the part worth taking from Tezos.