Overview Of Hyperledger Sawtooth APIs

• Toshendra Kumar Sharma
• May 21, 2019

What Is Hyperledger Sawtooth?

 

It is an enterprise blockchain platform which helps develop distributed ledger networks and applications. It is designed on the philosophy of keeping ledgers distributed, thereby helping keep smart contracts safe, especially when used in enterprises. Sawtooth separates the core system from the application domain. This helps simplify blockchain application development. Application developers can specify business rules which are specific to their applications. They can choose the language of their choice and it is not mandatory for them to know the underlying design of the core system. The modular nature of Sawtooth helps enterprises and consortia to make policy decisions. Applications are able to choose their own consensus algorithms, transaction rules, and permissioning to suit their own business needs. It is open source and is a project which falls under the Hyperledger umbrella.

 

It helps developers create smart contracts in various languages such as Python, C++, Javascript, Go, Java, and Ethereum Virtual Machine.

 

What Is An API?

 

API stands for Application Programming Interface. Put simply, it allows two applications to talk to each other. It is a software intermediary which comprises of communication protocols and tools to build software. It specifies the manner in which components must interact with each other. There are different APIs for websites, operating systems, or applications. It is used to program GUI components. GUI stands for Graphical User Interface. It helps develop programs easily by providing all the required building blocks.

 

Some of the key features of Hyperledger Sawtooth are:

 

• The nodes of Sawtooth communicate using messages which are serialized using Google’s Protocol Buffers.
• It supports the RAFT consensus protocol which is an algorithm designed for low latency, high throughput transactions. It is an algorithm which is voting-based and has inbuilt crash fault tolerance.

• It also supports the Proof of Elapsed Time consensus algorithm and PoET-Simulator which forgoes Byzantine Fault Tolerance.

 

 

Hyperledger Sawtooth APIs

 

It provides clients with a pragmatic RESTish API which allows them to interact with a validator using the common HTTP/JSON standards. It is an entirely separate process. Once it starts running, transactions can be submitted and blocks can be read using the common language-neutral interface. When the validator is improved or redesigned, the rest API will grow along with it thereby providing a consistent interface which meets the needs of application developers from a futuristic point of view. A validator supports a web API in accessing transactions, blocks, and state storage. It allows sending transactions to the network. The REST API treats the validator as a black box to submit transactions and fetch results. It is not used as a tool for entire validator communication.

 

Open API Specification

 

Rest API is documented in a comprehensive manner using the open API specification. This documentation acts as a single source of truth which documents each and every implemented aspect of the API. It can be read by both humans and machines. An open API is a standard, language-agnostic interface which allows both humans and computers to discover and understand the capabilities of the service without accessing documentation, source code, or network traffic inspection. If it is properly defined, a customer can understand and interact with the remote service using minimal implementation logic.

 

HTTP Status Codes

 

Rest API, with the goal of improving clarity, supports a limited number of common HTTP status codes. The granularity of passing errors is provided by specific error responses in the JSON response envelope. Some of the common codes are:

 

• 200- This refers to ‘OK.’ It means that the data resources were fetched successfully.
• 202- This refers to ‘Accepted.’ This means that the POSTed resources have been submitted to the validator but are yet to be committed. This also includes a link to check the status of the submitted resources.
• 400- This refers to ‘Bad Request.’ This means that the request couldn’t be completed as it was malformed.

 

 

Data Envelope

 

The REST API makes use of a data envelope which is used to send metadata back to clients in a manner which is easy to customize. Data is returned in an envelope for all successful requests which will have at least one of the four following properties:

 

• Data- It contains the actual resources or resources which are being fetched.
• Head- This helps to know if an explicit head was not set at the time of the original request.
• Link- It provides a link to the resources which were fetched. The head and paging parameters are explicitly set.
• Paging- This contains information on the pagination of resources.

 

Errors

 

In case of any issues when a request is being processed, the REST API sends back a response envelope with one property: ‘error.’ To explain the problem which has occurred, it consists of three values:

 

• Code: Machine-parsable code which is specific to the error.
• Title: This is a short headline which can be read by humans.
• Message:  It is a detailed explanation of the issue.

 

Query Parameters

 

This helps specify the manner in which a request to a validator should be formed. Some of the parameters it includes are:

 

• • Head- This is the id of the block which is used as a chain head. It can be used to request older versions of state.
  • Count- This refers to the number of resources which need to be fetched. The default number is set to 1000.

• Wait- The REST API is instructed to wait until the batches have been committed to the blockchain. This is done before responding to the client. The value of the wait time can be set to a positive integer.

 

 

Endpoints

 

This includes RESTful references to all resources stored in the sawtooth ledger which may be of interest to the clients. This can include RESTish metadata such as batch status or information such as blocks and transactions.

 

Resource Endpoints

 

Various resources routes are provided to fetch resources which are stored on the chain or those which are in the validator’s state. In a typical RESTful API, a GET request may fetch either one or many resources based on whether a particular resource identifier was specified or not. This comprises of:

 

• Blocks- The current blocks in the blockchain which are referenced by id.
• Batches- The stored batches which are referenced by id.
• Transactions- The transactions which are referenced by id.
• State- The state of the ledger which is referenced by leaf addresses.

 

Submission Endpoints

 

To submit validations to a sawtooth validator, they should be wrapped in a batch. Due to the asynchronous nature of blockchains, the status of submitted batches is checked with a corresponding endpoint. The wait query parameter is accepted by both the requests which allow clients to receive a response once the batches are committed.

 

Future Developments

 

To track the performance of the blockchain and the validator, additional endpoints can be implemented for fetching metrics. This can include peer-to-peer communications, system status, block processing, etc. This would require significant design and development within both the core validator and the REST API.

 

Conclusion

 

Considering the features and the APIs and architecture of Hyperledger Sawtooth, it will be of immense value to industries such as retail, healthcare, finance, and banking to provide a decentralized, transparent, tamper-free, secure, and reliable environment for the smooth functioning of the operations of any business.