SPECTRE: A Fast and Scalable Cryptocurrency Protocol

The five-minute read

One action, walked through

1. Users publish transactions. Miners publish blocks that reference every tip they have seen.
2. To compare two blocks, the protocol tallies how the rest of the DAG votes.
3. A merchant accepts a transaction when its block beats all conflicting blocks in that tally.
4. If a later attack narrows the margin, acceptance is withdrawn. The paper is explicit that confirmation is not a one-way door in every case.
5. Non-conflicting transactions do not wait for each other.

The argument, unpacked

What has to be true

• Honest miners publish blocks that reference the honest DAG, not a private fork.
• Conflicts are detectable. A ledger that cannot say when two transactions fight cannot run the vote.
• Merchants choose a risk threshold. The protocol does not ship one true number of confirmations.
• The network delivers the DAG. A vote cannot count a block nobody saw.

What happened after the paper

SPECTRE remained a research protocol. PHANTOM/GHOSTDAG took the DAG idea toward a linear order used later by Kaspa's line. Production smart-contract chains did not adopt pairwise voting. The paper is still the clean statement of what you give up when you refuse a total order.

What to check before you use the idea

• Does the system require a total order of all transactions?
• How is a conflicting pair resolved, and can the resolution stay tied?
• What margin does a merchant demand before treating a payment as accepted?
• Is the implementation SPECTRE, or a later linearisation?

Terms

Pairwise vote

A tally, over the DAG, of which of two blocks the other blocks consider earlier.

Robust acceptance

A lead in that vote large enough that the paper treats a reversal as an attack, not as ordinary delay.

The problem the paper names

Longest-chain confirmation waits because a fast block rate creates forks. SPECTRE treats the DAG as a vote. Honest blocks vote for the block they saw first, recursively.

What the design proposes

• Publish blocks that reference all known tips.
• Between two conflicting blocks, the rest of the DAG votes.
• Accept a payment when its block beats the competitors by a robust margin.

How the mechanism is specified

• The vote is recursive: a block's vote depends on the votes of blocks that follow it.
• Some pairs can remain unordered if the vote is too close. Payments that conflict wait. Payments that do not conflict need not be serialised against each other.
• That last property is the throughput claim and the smart-contract limitation.

What this page does not treat as proven

• Do not cite SPECTRE as a scheduler for an account-based virtual machine.
• The paper is not a deployed network and not PHANTOM's linear order.
• Fast confirmation in the common case is not a proof that a determined attacker cannot stall a particular pair.

Why a venture studio still reads it

If the product needs one global order of every transaction, this is the wrong paper. If it needs to accept payments that do not conflict, the pairwise vote is the idea to test.