This glossary defines Hyperledger Sawtooth terms and concepts.
- Group of related transactions. In Sawtooth, a batch is the atomic unit of state change for the blockchain. A batch can contain one or more transactions. For a batch with multiple transactions, if one transaction fails, all transactions in that batch fail. (The client application is responsible for handling failure appropriately.) For more information, see Transactions and Batches.
- Distributed ledger that records transactions, in chronological order, shared by all participants in a Sawtooth network. Each block on the blockchain is linked by a cryptographic hash to the previous block.
- Process of reaching agreement among a group of participants (nodes on a Sawtooth network), some of which could be faulty or malicious. Sawtooth supports many types of consensus algorithms. See also Dynamic consensus.
- Consensus API
- Interface that allows a consensus engine to interact with the validator in order to handle consensus functionality in a separate process. The Sawtooth consensus API supports a wide variety of consensus algorithms on a Sawtooth network.
- Consensus engine
- Sawtooth component that provides consensus-specific functionality for a Sawtooth node. The consensus engine runs as a separate process on the node and communicates with the validator through the consensus API.
- See Sawtooth core.
- Dev mode consensus
- Simple random-leader consensus algorithm that can be used to test a transaction processor on a single Sawtooth node. (Dev mode is short for “developer mode”.) Dev mode is not recommended for a multiple-node network; it should not be used for production.
- Distributed ledger
- See Blockchain.
- Dynamic consensus
- Sawtooth feature that allows a variety of consensus algorithms (formerly called “pluggable consensus”). Dynamic consensus allows each Sawtooth network to choose the best consensus for its purposes, as specified by on-chain settings in the genesis block. Sawtooth supports the ability to change the consensus algorithm on a running network by submitting a transaction. For more information, see Dynamic Consensus Algorithms.
- Genesis block
- First block on the blockchain. The genesis block initializes the Sawtooth network.
- Global state
- Database that stores a local (validator-specific) record of transactions for the blockchain. Sawtooth represents state in a single instance of a Merkle-Radix tree on each validator node. For more information, see Global State.
- Sample transaction family that handles on-chain permissions (settings stored on the blockchain) for transactor and validator keys. This transaction family demonstrates how to streamline managing identities for lists of public keys. For more information, see Identity Transaction Family.
- Sample transaction family with only three operations (set, increment, and decrement) that can be used to test deployed ledgers. IntegerKey is called intkey. For more information, see IntegerKey Transaction Family.
- Group of Sawtooth core processes that are responsible for maintaining and extending the blockchain for the validator. For more information, see Journal.
- Merkle-Radix tree
- Addressable data structure that stores state data. A Merkle-Radix tree combines the benefits of a Merkle tree (also called a “hash tree”), which stores successive node hashes from leaf-to-root upon any changes to the tree, and a Radix tree, which has addresses that uniquely identify the paths to leaf nodes where information is stored. For more information, see Merkle-Radix Tree Overview.
- Participant in Sawtooth network. Each node runs a single validator, a REST API, and one or more transaction processors.
- Off-chain setting
- Setting or value that is stored locally, rather than on the blockchain.
- On-chain setting
- Setting or value that is stored on the blockchain (also referred to as “in state”) so that all participants on the network can access that information.
- Practical Byzantine Fault Tolerance, a voting-based consensus algorithm with Byzantine fault tolerance (BFT) that has finality (does not fork). Sawtooth PBFT extends the original PBFT algorithm with features such as dynamic network membership, regular view changes, and a block catch-up procedure.
- Permissioned network
Restricted network of Sawtooth nodes. A permissioned network typically includes multiple parties with a mutual interest but without the mutual trust found in a network controlled by a single company or entity.
The blockchain stores the settings that specify permissions, such as roles and identities, so that all participants in the network can access this information.
Proof of Elapsed Time, a Nakamoto-style consensus algorithm that is designed to support large networks. PoET does not have finality (can fork).
Sawtooth offers two version of PoET consensus:
- PoET-SGX relies on a Trusted Execution Environment (TEE), such as Intel® Software Guard Extensions (SGX), to implement a leader-election lottery system. PoET-SGX is sometimes called PoET/BFT because it is Byzantine fault tolerant.
- PoET simulator provides the same consensus algorithm on a system without a Trusted Execution Environment. PoET simulator is also called PoET/CFT because it is crash fault tolerant, not Byzantine fault tolerant.
- Leader-based consensus algorithm that is designed for small networks with a restricted membership. Raft is crash fault tolerant, not Byzantine fault tolerant, and has finality (does not fork). For more information, see Raft (computer science) on Wikipedia and the Sawtooth Raft documentation.
- REST API
- In Sawtooth, a core component that adapts communication with a validator to HTTP/JSON standards. Sawtooth includes a REST API that is used by clients such as the Sawtooth CLI commands. Developers can use this REST API or develop custom APIs for client-validator communication. For more information, see REST API.
- Sawtooth core
- Central Sawtooth software that is responsible for message handling, block validation and publishing, consensus, and global state management. The Sawtooth architecture separates these core functions from application-specific business logic, which is is handled by transaction families.
- Sawtooth network
- Peer-to-peer network of nodes running a validator (and associated components) that are working on the same blockchain.
- Sample transaction family that provides a reference implementation for storing on-chain configuration settings. For more information, see Settings Transaction Family.
- See Global state.
- State delta
- Result of a single change for a specific address in global state.
- State delta subscriber
- Client framework that subscribes to a validator for state deltas (changes) for a specific set of transaction families. Usually, an application subscribes to state deltas for the purpose of off-chain storage or action, such as handling the failure of a transaction appropriately.
- Function that changes the state of the blockchain. Each transaction is put into a Batch, either alone or with other related transactions, then sent to the validator for processing. For more information, see Transactions and Batches.
- Transaction family
Application-specific business logic that defines a set of operations or transaction types that are allowed on the blockchain. Sawtooth transaction families separate the transaction rules and content from the Sawtooth core functionality.
A transaction family implements a data model and transaction language for an application. Sawtooth includes example transaction families in several languages, such as Python, Go, and Java. For more information, see Sample Transaction Families.
- Transaction processor
- Validates transactions and updates state based on the rules defined by the
associated transaction family. Sawtooth includes transaction processors for
the sample transaction families, such as
identity-tpfor the Identity transaction family. For more information, see Transaction Family Specifications.
- Component responsible for validating batches of transactions, combining them into blocks, maintaining consensus with the Sawtooth network, and coordinating communication between clients, transaction processors, and other validator nodes.
- Sample transaction family that demonstrates basic transactions by playing tic-tac-toe on the blockchain. For more information, see XO Transaction Family.