Hyperledger Sawtooth has earned a formidable reputation as a champion of modularity in the realm of enterprise blockchains. We delve into its components and functionalities, as well as the advantages it offers businesses seeking custom-crafted blockchain solutions.

The cornerstone of Hyperledger Sawtooth’s architecture is its emphasis on modularity. By embracing a modular architecture, it empowers businesses to craft secure, scalable, and custom-designed blockchain solutions. Its inherent flexibility, coupled with its support for a diverse range of consensus algorithms and permissioning models, makes it an ideal platform for enterprises embarking on their blockchain journey. Sawtooth allows businesses to tailor the blockchain to their specific needs, ensuring a perfect fit for their unique requirements.

Unlike monolithic blockchains where core functionalities and applications are intricately interwoven, Sawtooth adopts a decoupled approach. This separation offers a multitude of benefits.

• Unmatched flexibility: Businesses are empowered to select the consensus algorithm, transaction processors, and permissioning mechanisms that perfectly align with their specific use case. This granular control ensures the blockchain solution caters to their unique requirements.
• Enhanced security: By isolating the core ledger system from the application environment, Sawtooth bolsters the overall security posture. This separation minimises the attack surface and safeguards the integrity of the shared ledger.
• Simplified evelopment: Developers can leverage their preferred programming languages when building applications on the periphery of the blockchain. This freedom fosters innovation and streamlines the development process without compromising the core functionalities of the ledger.

Components of Sawtooth nodes

Each node in this Sawtooth network runs a validator, a REST API, a consensus engine, and transaction processors. All the components are depicted in Figure 1.

• Clients: These applications, representing the user interface, interact with the validator nodes using a Representational State Transfer (RESTful) API. This API facilitates the submission of transactions and retrieval of data from the ledger.
• RESTful API: This user-friendly interface acts as a bridge between clients and validators. It provides a language-independent mechanism for applications to communicate with the validators, promoting interoperability and simplifying integration.
• Transaction processors: These intelligent contracts serve as the backbone of business logic enforcement within Sawtooth. They meticulously validate transactions, ensuring adherence to predefined rules before approving their inclusion in the ledger. Transaction processors act as the gatekeepers, safeguarding the integrity of the shared record.
• Validator: This critical component shoulders the responsibility of verifying the validity of both transactions and blocks. Validators meticulously scrutinise each unit of data before committing them to the tamper-proof ledger. By acting as the gatekeeper, validators ensure the consistency and reliability of the shared record.
• Consensus engine: This mechanism serves as the foundation for an agreement among all validators regarding the current state of the ledger. Hyperledger Sawtooth boasts a modular design philosophy that extends to the consensus engine as well. It offers a variety of pluggable consensus algorithms, including Proof of Elapsed Time (PoET) and Practical Byzantine Fault Tolerance (PBFT). Businesses can select the algorithm that best suits their needs in terms of security, scalability, and performance.

Hyperledger Sawtooth has some additional architectural features for enhanced performance.

• Asynchronous client/server pattern: To optimise scalability and performance, Sawtooth employs an asynchronous communication pattern between clients and validators. This approach allows for concurrent processing of requests, improving overall throughput.
• Parallel transaction execution: Sawtooth leverages a technique known as batching, where related transactions are grouped together. This enables efficient parallel processing of multiple transactions simultaneously, further enhancing the platform’s performance.

Sawtooth validator

The validator in Hyperledger Sawtooth plays a pivotal role in the architecture of the blockchain network, acting as the core component responsible for the primary operations and integrity of the distributed ledger. Let’s look at its main functions and characteristics.

Transaction processing

• Validation and execution: Validators are responsible for validating transactions against the network’s consensus rules and executing them accordingly. They ensure that transactions are properly signed, correctly formatted, and adhere to the specific rules of their transaction families.
• Interaction with transaction processors (TPs): Validators communicate with transaction processors, which contain the business logic for different types of transactions. This communication is crucial for executing the transactions as per the defined smart contract logic.

Block management

• Block validation: Validators verify the integrity and validity of each block before it’s added to the blockchain. This includes checking the block’s hash, ensuring all transactions within the block are valid, and confirming that the block adheres to the chosen consensus model’s rules.
• Consensus participation: Validators play a central role in the consensus process, participating in the algorithm (e.g., PoET, Raft) that the network uses to agree on the state of the blockchain. This process ensures that only valid blocks are added to the chain and helps maintain the network’s overall integrity and agreement on the ledger’s state.

State management

• State storage: The state of the blockchain, which includes all balances, contracts, and relevant data, is managed by the validator. It uses a Merkle Radix Tree for efficient storage and querying of the blockchain state, facilitating quick verification and updates.
• State transition: Upon successful validation and execution of transactions, validators apply the changes to the blockchain’s state. This process involves updating the current state based on the outputs of transactions, ensuring the ledger accurately reflects all executed transactions.

Networking and communication

• P2P networking: Validators use a peer-to-peer (P2P) network to communicate with each other, sharing blocks, transactions, and consensus-related messages. This network is fundamental for the distribution and verification of the ledger’s data across all participating nodes.
• Client interaction: Validators expose interfaces (e.g., REST API) for clients to submit transactions, query the blockchain state, and retrieve information about blocks and transactions. This allows users and applications to interact with the blockchain network seamlessly.

Security and integrity

• Cryptography: Validators use cryptographic techniques to ensure the security and integrity of transactions and blocks. This includes verifying digital signatures, generating cryptographic hashes for blocks, and securing communications between nodes.
• Permissions and policies: Validators enforce network policies and permissions, controlling access and actions within the blockchain network. This ensures that only authorised participants can perform certain actions, enhancing the network’s security.

The validator node is illustrated in Figure 2.

Transactions and batches

In Hyperledger Sawtooth, transactions are the fundamental elements through which the state of the blockchain is modified. Transactions are grouped into batches to efficiently process and confirm multiple operations at once. Understanding both concepts is crucial for developing applications on Sawtooth. Here’s an overview.

Transactions

A transaction in Sawtooth represents an atomic change to the state of the ledger. Each transaction is composed of several key components.

• Header: Contains metadata about the transaction, such as the family name (which indicates the transaction processor that should handle the transaction), family version, and the inputs and outputs (addresses in the state that the transaction can read from or write to).
• Header signature: This digital signature is created by signing the header with the transaction creator’s private key. It ensures the integrity and authenticity of the transaction.
• Payload: This is the actual data of the transaction, which is interpreted by the transaction processor. The structure of the payload is determined by the specific transaction family’s requirements.

Transactions are submitted to the Sawtooth network through clients, which construct the transaction payload, wrap it in a transaction envelope (including the header and signature), and send it to the network.

Batches

A batch is a collection of transactions submitted together to the network. Batches allow the grouping of related transactions so that they are all either committed to the state or rejected, ensuring atomicity. Each batch includes:

• Transactions list: An ordered list of transactions that belong to the batch. The transactions are executed in the order they appear in the list.
• Header: Contains metadata about the batch, similar to transactions. It includes the signer’s public key and a list of transaction identifiers (signatures) in the batch.
• Header signature: This digital signature of the batch header is signed with the batch creator’s private key. It ensures the integrity and authenticity of the batch.

BatchHeader

The BatchHeader contains metadata about the batch, including information about the transactions contained within it.

• string signer_public_key: This public key of the entity that signed the batch is used to verify the header_signature.
• Repeated string transaction_ids: A list of identifiers for each transaction included in the batch. This ensures that the transactions can be uniquely identified and referenced.

Transaction

A transaction represents an individual operation or action that is intended to be executed against the ledger. Each transaction within a batch is executed in the order it is listed.

• Bytes header: A binary representation of the TransactionHeader, it encapsulates various details about the transaction.
• string header_signature: A digital signature of the TransactionHeader, serving a similar purpose as the header_signature in the BatchHeader but for individual transactions.
• bytes payload: The actual data or instructions that the transaction is carrying. This is what gets executed against the ledger.

TransactionHeader

The TransactionHeader provides the necessary context and metadata for processing the transaction.

• string batcher_public_key: The public key of the entity responsible for batching this transaction. This might be the same as the signer_public_key if the transaction’s creator also created the batch.
• repeated string dependencies: Identifiers of other transactions that must be executed before this one.
• string family_name and string family_version: Identifiers for the transaction processor that can execute this transaction, allowing for versioning and namespacing of transaction logic.
• repeated string inputs and repeated string outputs: Lists of state addresses that this transaction intends to read from (inputs) and write to (outputs). This is crucial for concurrency control and ensuring transactions do not interfere with each other’s state changes.
• string nonce: A unique value used once to ensure that each transaction’s header is unique, preventing replay attacks.
• string payload_encoding: Specifies how the payload is encoded, ensuring that the transaction processor knows how to interpret it.
• string payload_sha512: A SHA-512 hash of the payload, ensuring integrity and allowing for validation without revealing the payload’s content before necessary.

string signer_public_key: The public key of the individual or entity that signed the transaction, ensuring authenticity and non-repudiation.

The connection between transactions and batches is shown in Figure 3.

Writing transactions and batches

To write transactions and batches in Sawtooth, follow these general steps.

• Define transaction payload: Structure the payload according to the rules of the transaction family your application is interacting with.
• Create transaction: Construct the transaction header with appropriate metadata, including inputs, outputs, and the family name and version. Sign the header with your private key to generate the header signature, and assemble the transaction with the payload and signed header.
• Group transactions into batches: If you have multiple transactions, organise them into batches. Create a batch header with the list of transaction signatures and sign it. Combine the transactions and the signed header to form a batch.
• Submit to the network: Use the Sawtooth REST API or an SDK in your preferred programming language to submit the batches to a Sawtooth validator.

This process involves specific coding practices and interactions with the Sawtooth SDKs, which vary depending on the programming language you’re using (Python, JavaScript, etc). Sawtooth documentation provides detailed guides and examples for creating and submitting transactions and batches using these SDKs.