By Dan Anderson, Intel
Hyperledger Sawtooth is a permissioned enterprise blockchain platform that is built in a modular fashion. The Sawtooth blockchain (essentially an electronic ledger) is immutable (transactions cannot be deleted or modified), highly available, transparent (all transactions are visible), distributed and has several security mechanisms, which I describe below.
By the way, for the record, there is no Sawtoothium, Sawtooth Coin, Sawbucks, STC, or anything like that previously built into the Sawtooth platform. Sawtooth has no digital currency and has no miners. Of course, a Sawtooth application can create and manage digital currency or other assets.
Security for an enterprise blockchain is important because it’s shared among frenemies—mutually distrusting organizations that need to work together. This is the first of three articles on Sawtooth Security:
- Part 1: Sawtooth Consensus Algorithms
- Part 2: Sawtooth Node and Transaction Processor Security
- Part 3: Client Application Security and Network Security
Consensus Algorithms
In Sawtooth, a major task of a consensus algorithm is leader selection, deciding which competing peer node can publish a new block on the blockchain. What are the security implications of a consensus algorithm? A secure consensus algorithm is important to prevent a “rogue” node (bad actor) from “gaming” the system. A bad actor can publish transactions favorable to it or a third-party before or in lieu of transactions from other nodes. In several applications, just having better timing is a big advantage—consider the stock market or real estate or any market with scarce goods at a fluctuating price.
Prelude: Byzantine Generals Problem
Before discussing consensus algorithm details, it’s good to review the Byzantine Generals Problem. The problem was first proposed in 1982 by Leslie Lamport et al. Basically you have n generals deciding whether to attack or retreat. But some generals may be malicious traitors (bad actors) and send the wrong advice. The goal is to agree on a common plan (attack or retreat) that is not influenced by the malicious generals. The classical solution to the Byzantine Generals Problem requires (3m + 1) total generals to safeguard against the votes of m malicious generals.
Byzantine Fault Tolerance (BFT) v. Crash Fault Tolerance (CFT)
In general (not a pun), Byzantine Fault Tolerant (BFT) solutions can withstand malicious (or bad actors) among the nodes. Crash Fault Tolerant (CFT) solutions assume no node is malicious—that is, there are no bad actors. A node can crash or disappear from the network, but it does not misbehave. CFT solutions are usually less expensive than BFT ones.
Types of Consensus Algorithms
A Consensus Algorithm decides which of several competing block candidates from multiple nodes will be added to the blockchain. Consensus algorithms come in two classes: Nakamoto lottery-like consensus and Classical or voting-like consensus
Nakamoto Consensus
Nakamoto-style consensus algorithms all use some kind of lottery-like system to pick a winner. It includes Proof of Work (PoW), the consensus algorithm used in Bitcoin. PoW selects a winner by solving the cryptographic puzzle of finding the most leading 0s in a SHA-256 result. Unfortunately PoW is wasteful—it’s estimated to use about ~2.5 gigawatts/year. As a comparison, Ireland consumes ~3.1 gigawatts/year.
Sawtooth’s Proof of Elapsed Time (PoET) is also a Nakamoto-style consensus algorithm. PoET selects as the winner the node with the first expired randomly generated wait time. More on PoET later.
Another Nakamoto-style consensus algorithm, still in the experimental stage, is Proof of Stake (PoS), where the winner has the most of something (wealth, age, etc.)
All Nakamoto-style consensus algorithms can fork—that is have two competing blockchains with different blocks appended to the end. The forking consensus algorithms have various resolution methods to solve forking.
Classical Consensus
Classical Consensus uses an agreement or voting mechanism to select a leader. Examples include Practical Byzantine Fault Tolerance (PBFT) or Raft.
PBFT uses a state machine and selects a leader by block election. PBFT does not fork. PBFT uses a three-phase, network-intensive algorithm (n^2 messages), so is not scalable to large networks.
Raft consensus elects a leader for an arbitrary term of time. If the leader times out, the leader is replaced. Raft is both fast and CFT, but it is not BFT. Also Raft does not fork.
Sawtooth’s Pluggable Consensus
Sawtooth supports “pluggable” consensus algorithms—that is it is configurable. Not only is the consensus configurable at blockchain genesis (block 0), but the consensus algorithm can be changed at any point after after blockchain creation with an in-chain setting, sawtooth.consensus.algorithm.
Consensus algorithms supported by Sawtooth are:
- DevMode – a simple consensus algorithm for development use only
- PoET CFT – PoET runs without SGX hardware, which is CFT
- PoET SGX – PoET runs with SGX hardware, which is BFT
- RAFT – uses an elected leader and it is faster than PoET. It is only CFT and not BFT
Other consensus algorithms are in the works, such as PBFT. The Sawtooth community encourages contributions of other consensus algorithms by third parties. There are many consensus algorithms, each with advantages and disadvantages, and consensus algorithms in general is an active area of research!
Proof of Elapsed Time (PoET) Consensus
Proof of Elapsed Time (PoET) consensus is one of the consensus algorithms available with Sawtooth. PoET comes in two flavors, both for production use:
- PoET SGX runs with SGX hardware. It is BFT
- PoET CFT (also called PoET Simulator Mode) runs without SGX hardware. It is only CFT
Prelude: Intel® Software Guard Extensions (SGX) Overview
But before we can discuss PoET, we need to review SGX. A TEE (Trusted Execution Environment) runs code in a protected region of memory, called an enclave. Intel’s implementation of a TEE is Software Guard Extensions (SGX), which was first released in 2015. A SGX enclave can be thought of as a “reverse sandbox” or “fort.” The enclave prevents the rest of the system from accessing protected code or data residing inside the enclave. This is implemented with encryption.
Contrast a SGX enclave with a more traditional “sandbox” where the code in the sandbox is prevented from accessing code or data outside the sandbox. A SGX enclave is the reverse—it prevents malicious actors (including rogue operating system or application code) from access inside the enclave. This allows the enclave to safely execute in a hostile outside environment. SGX does not have to trust the OS or other software on a host.
Another important SGX function is its ability to “attest” to code that’s in the enclave—it provides high confidence that code is authentic and not tampered with before it’s been loaded.
SGX allows multiple enclaves on the same host. Separate enclaves would have separate functions and run independent of each other. The code and data should be as small as possible. Limiting enclave size reduces exposure to possible vulnerabilities from outside the enclave. So, for example, hosting a programming language interpreter would be inappropriate for an enclave.
Proof of Elapsed Time – Software Guard Extensions (PoET SGX)
Proof of Elapsed Time (PoET) consensus, as mentioned above, is a Nakamoto-style consensus algorithm. That is, it uses a lottery-based mechanism. Each node generates a random wait time value in a secure SGX enclave, then waits that many seconds. The node with the timer that expires first wins and can add its proposed block to the blockchain. The random wait time value is signed in the enclave, and all other nodes verify the timer signature.
The PoET Timer is implemented to run within a SGX enclave. The SGX enclave securely generates a tamper-proof random wait time value. The enclave then signs a certificate with the wait time value. Outside the enclave, each node waits the required amount of time. After the timer expires, the SGX attestation is sent to the other network nodes. The peer nodes verify the wait time signature generated by the winning node. The winning node gets to publish its proposed block onto the blockchain.
PoET has multiple defense-in-depth tests to prevent cheating by a rogue node. They are:
- Z Test confirms that a block-claiming validator is not winning too frequently
- C Test requires that a new node must wait C blocks after admission before its blocks are accepted. This is to prevent gaming identities and some obscure corner scenario
- K Test restricts a node to publishing at most K blocks before its peers require the node to recertify itself
Proof of Elapsed Time – Crash Fault Tolerant (PoET CFT)
PoET is also available without SGX. It uses the same algorithm and shares the same code as PoET SGX, except that the enclave module is simulated. Because the SGX protections are simulated, PoET CFT is not BFT. Keep in mind that other consensus algorithms, such as Raft or Kafka, are also CFT and not BFT. No special hardware is required for PoET CFT, and it is still a stable algorithm.
Conclusion
This concludes part one of my blog on Hyperledger Sawtooth Security, where I discussed consensus algorithms. As you can see, the choice of consensus algorithm is a trade-off between performance, security (resistance to bad actors), and scalability (number of network nodes). Part two will continue with a discussion on Sawtooth node and transaction processor security.