Hyperledger Sawtooth — Transaction Flow
The Hyperledger Project was founded by the Linux Foundation to bring blockchain technologies to mainstream commercial adoption. It is a network of open-source developing communities building blockchain frameworks and platforms. Sawtooth is the second blockchain to reach 1.0 through the Linux Foundation, initially developed by Intel.
Sawtooth is an enterprise-grade, modularized blockchain for developing distributed ledger applications and networks. Sawtooth’s core system is separate from the application layer and has pluggable consensus algorithms. Sawtooth also brings the possibility of parallel transaction processing.
There are three ways to deploy a Sawtooth network: Public, Private, and Consortium. In a public network, any client can sign a transaction. However, this would require developing a system to incentivize pro-social behavior, and is outside of the scope of the current design. A consortium network has specified validators but is otherwise open beyond the consensus layer. In a private network, every layer is specifically permissioned.
A validator may have permissions configured off-chain in a local file. Those permissions are only enforced when receiving a batch from a connected client but are not applicable to peers on the network. Permissions may also be configured network-wide through the identity namespace. When using both on and off-chain permissions client transactions must meet the requirements of both.
Sawtooth Transaction Flow
In order to send a transaction to the validator, you will need a private key that can be generated by the SDK’s signing module. This key is proof of your identity, and anyone in possession of it can sign a transaction in your name. Each transaction is composed of a signature, and a binary encoded payload. The encoding is defined by the transaction processor. Transactions may have dependencies that specify other operations that must take place before the current one. Dependencies are useful in cases where transactions require the satisfaction of other transactions unable to go in the same batch.
Once built, one or more transactions are wrapped in a batch and sent to the validator who sends a process request to the transaction processor. Assuming that it satisfies the rules of the transaction family, the batch is validated. A batch is an atomic unit of change in the Sawtooth network. When a batch is approved, it means that every transaction in the batch is valid. Likewise, if a single operation in a batch fails, then the entire batch is not approved. The validator uses a BlockCache to hold a working set of blocks and track processing state. While the BlockStore only holds valid blocks, the BlockCache handles new and invalid blocks as well, facilitating parallel execution.
Next, the transaction batch goes to the Journal which supports pluggable consensus algorithms like Proof of Work, Proof of Elapsed Time and other Practical BFT algorithms. The journal routes both batches and blocks in consideration for appending the ledger. The first stop in the journal is the completer, which ensures that all of its dependencies are satisfied. Batches then continue to the BlockPublisher for validation and inclusion in a block. When a block is full, its routed back to the Completer, which again guarantees that all of its dependencies are fulfilled. Completed blocks then route to the chain controller for validation, and fork resolution. Once validated, and potential forks resolved, the chain controller applies a ChainUpdate via the BlockStore. The BlockStore contains all blocks in the ledger, chronologically linked back to the Genesis blocks.