Architecture of Hyperledger Sawtooth : A Comprehensive Overview

• Toshendra Kumar Sharma
• May 09, 2019

What is Hyperledger?

 

Launched in 2016, Hyperledger is a multi-project collaborative effort hosted by the Linux Foundation. It includes leaders from various industries such as supply chain, technology, manufacturing, Internet of Things, finance, and Banking. It creates enterprise-grade, distributed ledger frameworks for supporting business transactions. Hyperledger is an operating system for micro-currencies, data-sharing networks, marketplaces, and decentralized digital communities.

 

What is Hyperledger Sawtooth?

 

Hyperledger Sawtooth is an open-source project under the hyper ledger umbrella. It is a modular enterprise blockchain platform which is used for building distributed ledger networks and applications. The main reason for using distributed ledgers on the Hyperledger platform is to keep smart contracts safe, especially when it comes to enterprise use. It is referred to as modular because it helps enterprises in making policy decisions and its core design allows applications to choose their own consensus algorithms, rules, and permissions in a way that suits and supports their business needs.

 

One defining goal of distributed ledgers like Sawtooth is distributing a ledger among participating nodes. The framework of Hyperledger Sawtooth is being developed by Intel. It is a blockchain framework which focuses on agility. The framework offers basic functions such as communication between network nodes and storing data on the architecture and the blockchain for plugging consensus algorithms and smart contracts.

 

Let’s now have a detailed look at the architectural components of a Hyperledger Sawtooth and the functions of each.

 

 

 

1. Clients

 

 

Hyperledger Sawtooth follows an asynchronous client/server pattern. The pattern is as follows:

 

• Clients connect to the server and send requests.
• For each and every request, the server responds with 0 or more replies.
• Clients can send multiple requests and need not wait for a reply from the server.
• Servers can also send multiple replies and need not wait for new requests.

2. Rest API

 

Hyperledger Sawtooth provides a pragmatic RESTish API for clients to interact with a validator using common JSON/ HTTP standards. It is a separate process which allows for the submission of transactions and reading of blocks with a common language-neutral interface. The REST API mostly treats the validator as a black box for submitting transactions and fetching results. It is comprehensively documented using the OpenAPI specification. It acts as a single source of truth which documents every aspect of API. It is readable by both machines and humans. In order to improve quality, the REST API supports a few common HTTP status codes. Some of the codes are 400, 404, 500, 503, 201, etc. For example, 404 indicates ‘Not Found’ which means the request was well formed but there is no resource.  503 indicates ‘Service Unavailable’ which means REST API is unable to contact the validator.

REST API uses a JSON envelope to send metadata back to clients in an easy and customized manner. If anything goes wrong while processing the request, the REST API sends back a response envelope with one property: “error.” It contains three values such as code, title, and message and these explain the nature of the problem that has occurred. The code is fixed and can’t be altered whereas the title and the message can be reworded. It also supports query parameters to help specify how a request to a validator should be formed. Some parameters have their own specific endpoints and not every endpoint supports every query. The endpoints include RESTful references to resources available in the Sawtooth ledger that may be of interest to clients. These might include blocks, transactions, and RESTish metadata.

3. Transaction Processors

 

Transaction processors handle business logic and they have the authority to allow or decline transactions from being added to the state. When a client interacts with the network by sending a transaction, these validate the transactions, apply the changes, and add them into the next block. Validator nodes make sure if the signature of a transaction is valid.

 

It also allows adding additional logic in the transaction processor to check more specific requirements. For a transaction processor to process transactions, transaction handlers need to be added. Handlers can be summoned in two ways: one is the “apply method” and the other one is the metadata method. Metadata helps connect a handler to the processor. However, the bulk of the handler is made up of apply and its other helper functions.

 

A transaction processor comprises of two top-level components such as :

 

• Processor class: Software Development Kit provides a general-purpose processor class.

 

• Handler class: It is application-dependent. It contains business logic for a specific set of transactions. As the transaction processor is a long running process, it requires an entry point. At the entry point, the transaction processor class is provided with the address to connect with the validator and the handler class.

 

4. Consensus engine

 

The consensus API of Sawtooth has been entirely redesigned. It has been moved to a separate process termed the ‘consensus engine.’ It is an interface which includes the feature of language independence for consensus algorithms. Consensus engines enable more consensus option for Sawtooth. Network deployment tools have been updated. Consensus engine operates on its own separate processes like REST API and transaction processors.

 

There are three processors which run in this component:

 

• Consensus.BlockPublisher– It is equipped only with read-only access and helps extend the chain by creating candidate blocks. The three actions which are taken are initialization, checking, and finalizing.

 

• Consensus.BlockVerifier– It provides block verification functions to the Block Validator. It helps in verifying if the candidate block was published by following consensus rules.

 

• Consensus.ForkResolver– It helps in selecting the next block which can be the chain head.

 

5. Validator

 

In Hyperledger Sawtooth, blocks and batches are validated in a similar way by authorized nodes. The block validation process checks for on-chain transaction permissions to verify the entity who is allowed to issue blocks and batches. Following this, the on-chain block validation rules added through setting proposals are applied to the block. These batches are then sent to the transaction scheduler. The network layer is responsible for communication between the validators of a Sawtooth network. It performs activities such as interconnecting REST API, transaction processors, and clients. Apart from this, it performs the major functions of discovering peers on the network, handling transactions, managing blocks, and working in support of the consensus engines.

 

Sawtooth supports both serial and parallel scheduling of transactions. Transaction handling and execution in Sawtooth efficiently and correctly handles transactions which modify the same state addresses and also transactions within the same block. Sawtooth has no block level restrictions. This helps enhance the performance of transactions and prevents double spending but still allows multiple transactions which alter the same state values to appear in a  single block. The sawtooth validator process has two major components such as:

 

• Chain controller – It maintains a pointer to the last block in the current chain. It determines whether a chain head should be updated. It creates a scheduler to calculate new state for the block being published with a Merkle hash. Merkle hash is compared to the state root of the block header. If they match, the block is considered valid.

 

• Block manager and publisher – It is responsible for creating new candidate blocks. Only valid transactions are added to the next candidate block.

 

Conclusion

In order to know more about Hyperledger and to become an expert in the same, you can enroll in the Certified Hyperledger Expert and the Certified Hyperledger Developer certification courses offered by the Blockchain Council. Blockchain Council comprises of an authoritative group of subject experts with a passion for blockchain technology. It is a private de-facto organization which works individually and proliferates blockchain technology on a global scale. Enrolling in these certifications will provide you with the much-needed knowledge and expertise to assist enterprises to build hyperledger-based blockchain applications.