Eliminating 51% Attacks in Proof-of-Work Blockchains
This blog post explains how to build a proof-of-work blockchain without 51% attacks. Bear in mind that this is a pure proof-of-work implementation and not a proof-of-stake hybrid with validators and governance attacks.
We start by noting that majority-hash attacks are possible in blockchains such as Bitcoin because the “work” used to secure the blockchain is locked to particular blocks. When the chain is reorganized all the work that honest nodes have done is rendered useless — the blocks to which their work is tied no longer form part of the longest chain. This problem can be eliminated by moving the proof-of-work component to the transaction level.
Instead of paying fees to miners, users can simply include a proof-of-work hash with their transactions. Nodes in the network gather these hashes while propagating transactions, and are permitted to produce blocks once they have enough cumulative work in their mempool to meet difficulty requirements. For clarity’s sake, we can call this “transaction-embedded proof-of-work” (tPOW) to differentiate it from “block-embedded proof-of-work” (bPOW).
One problem with this approach is that multiple nodes may have enough work to produce blocks at the same time. This can be avoided by having nodes sign transactions as they pass through the network, affixing to each an unforgeable history of the routing path that the transaction has taken on its journey into the network.
A simple implementation should specify that no node can put a transaction into a block unless it is included in the transaction path, and the value of “work” embedded in each transaction should drop with each additional hop that it takes through the network. We should also specify that nodes stop propagating transactions to peers once only a minimal amount of work remains: users who wish faster confirmation (deeper propagation) should attach harder proofs.
With these restrictions, block production will adopt the “round robin” properties of proof-of-stake systems — but without the need to destroy the open-access properties of the network. Centralization pressures in bPOW also disappear since there is zero advantage to nodes in being tightly coupled: the node that produces a block is the least likely to produce the next block. Sybilling also disappears (although the reason why is left as an exercise for the reader). What matters for block production is positioning oneself close to an inbound stream of unique, high-value transactions.
If we return to the topic of 51% attacks, we can see that they are effectively impossible in this system. Malicious nodes can still attack the network, but need to create a lot of work-intensive transactions in order to “crowd out” the honest transactions. Building ASICs can simplify this, but without mining fees to compensate attackers for the cost, doing so offers massive costs and zero benefits. And the amount of hashing required for a successful attack is also hard to predict: users can respond to attacks by increasing the amount of work they attach to their individual transactions, driving up the cost of the attack in real time and helping to bankrupt attackers.
The table below shows the consequences of tPOW on the cost of chain-control attacks. While bPOW networks can be controlled as long as the attacker has a majority of network hashpower, tPOW networks force up the cost of attacks as long as honest nodes have work “building up” that is unavailable to the attacker. Eventually even the richest attacker will have to permit another node to contribute blocks to their blockchain if only to lower the cost of their attempt to dominate block production.
The graph below shows this same information in visual form. The red line represents the cost of continuing to censor the network. It can be seen very quickly that this attack is entirely unsustainable.
There are reasonable objections to this approach. Will nodes be motivated to propagate transactions? How can the network pay for its own survival if we eliminate fees? How can the network be induced to assume an optimal economic structure?
While we could spend several pages outlining concerns and responses to them (i.e. there is no reason nodes cannot include a separate payment for peer-to-peer nodes), we will skip over these details and point interested readers to the Saito whitepaper, which outlines several additional measures that are useful for securing a Saito-class network from tangential attack vectors.
With that said, it is important to highlight a major advantage that Saito-class networks have over other networks that gives them an informational advantage in both scaling and security: the ability to differentiate between honest nodes and attackers.
The inability of other networks to tell the difference is the reason so many developers are playing “whack-a-mole” games that involve “technical trade-offs” in ever-more complicated proof-of-stake structures. But what use is replacing 51% attacks on any chain reorganization mechanism if doing so simply moves the vulnerabilities to the governance mechanism instead?
Unlike any other blockchains, Saito-class networks can tell the difference between attackers and honest nodes. Because all nodes must cryptographically sign transactions as they pass through the network, the network can adjust its routing topology to defend against attacks. Users in the network — the only participants capable of recognizing an attack — can defend the network by routing their transactions away from attackers. This technique increases the “work” available to honest nodes while decreasing the “work” available to attackers.
What message do we hope others take from this blog post? The most important is that combining decentralized work generation with cryptographically-signed routing updates a blockchain into a hardened Saito-class network. This approach eliminates vulnerabilities such as 51% attacks while providing new defensive mechanisms that do not require vulnerable proof-of-stake governance mechanisms.
In closing, while this post has been about proof-of-work, we should mention that we do not believe proof-of-work is the appropriate consensus mechanism for a truly high-throughput blockchain.
With that said, we hope this quick write-up helps illustrate how the techniques invented by Saito can be ported to work together with alternate consensus mechanisms — including proof-of-work. As they come to be understood more broadly, we expect Saito-class solutions to be implemented in most major blockchains over the next few years.
Interested in learning more? Members of the Saito team are routinely in Hong Kong, Singapore and mainland China, and welcome contact from fellow members of the cryptocurrency community. For readers in the United States, Saito’s co-founders, Richard Parris and David Lancashire, will be in the Bay Area during the first week of February. Please feel free to contact us.
