The Ting wiki
A blockchain designed to be finished
Most programmable blockchains keep changing their own rules. Ting writes a small set of consensus rules once, pins them down with independent test vectors, and then freezes them. Everything else is an ordinary program that anyone can deploy.
The problem#
On most programmable chains, a new signature scheme, opcode, fee rule or token standard is a protocol upgrade. Every node has to change together, and each change can alter what existing applications do or what they cost. Whatever cryptography is built in stays built in until the next upgrade replaces it.
Over time the base layer collects special cases: built-in accounts, built-in assets, precompiled functions, repriced instructions. The rules that applications depend on are never quite settled.
The approach#
Ting's consensus does four things, and nothing else.
- OrderTransactions are ordered in blocks secured by SHA-256 proof of work.
- ExecutePrograms run deterministically in a small, exactly specified WebAssembly profile.
- CommitEvery block commits to its transactions, their receipts and the resulting state.
- CountFour independent counters bound the compute, state access, data and storage growth of every transaction.
Accounts, signatures, coins, fees, replay protection and upgrades are not on that list. They are programs, deployed and used through ordinary transactions.
What that gives you#
Once the protocol is frozen, every instruction keeps its meaning and its resource charge for as long as the chain runs.
A new signature scheme or hash function is deployed as a program. Applications move to it when they choose, without a protocol change.
There is no native coin, account model or fee asset. The chain does not pick winners among the programs built on it.
Work is counted in logical units, not prices or nanoseconds. Faster hardware does not change what an operation costs.
Miners vote block capacity up or down, slowly, above floors fixed at genesis and with no ceiling. They cannot vote to change the rules.
Implementations may compile, cache or parallelize freely, as long as every result and every counter matches.
Four layers, four speeds of change#
One idea makes the rest of this wiki easier: every rule belongs to exactly one layer.
| Layer | Who can change it | Examples |
|---|---|---|
| Consensus | Nobody, once frozen | Block and transaction formats, instructions, resource charges, the voting rule |
| Capacity | Miners, by work-weighted vote | Block limits for compute, state access, data and growth |
| Node software | Any implementer, at any time | Database, compiler, networking, mempool policy |
| Applications | Anyone, by deploying programs | Accounts, signatures, assets, fees, upgrades |
This wiki is the specification. Its concept pages state the consensus rules exactly; where a description elsewhere differs from an explicit rule on the VM pages, the VM rule governs. Must, must not and should state requirements. The pages under Running a node describe the Rust reference node, which implements the rules and serves this wiki, not consensus.