Hyperledger Sawtooth: A gentle introduction

Introduction

Hyperledger Sawtooth is an open source project under the Hyperledger umbrella. It works as an enterprise-level blockchain system used for creating and operating distributed ledger applications and networks, particularly for use by enterprises.

Hyperledger Sawtooth is dubbed as an enterprise blockchain-as-a-service platform that can run customized smart contracts and logic without needing to know the underlying design of the core system. It also supports a variety of consensus algorithms, including Practical Byzantine Fault Tolerance (PBFT) and Proof of Elapsed Time (PoET), letting the user craft the performances of the blockchain in the most suitable way depending on the specific requirements.

Hyperledger is a development group sponsored by organizations such as the Linux Project, IBM, Intel, and SAP.

Sawtooth singularities

Sawtooth consensus algorithms

At the very core of the solidity of the blockchain architecture and, in the most general way, public ledgers, there is the consensus algorithm. The most traditional one is the Sakamoto Consensus Algorithm [2] that was designed to overcome the limits of the Byzantine Fault Tolerant (BFT) Consensus. Hyperledger Sawtooth provides three different consensus mechanisms: PoET, PBFT, and Raft.

Sawtooth PoET

Sawtooth Proof of Elapsed Time (PoET) is a Nakamoto-style consensus [2] algorithm that is designed to support large network populations. PoET relies on a “fair lottery” mechanism to select which node will add the next block: each node generates a random wait time during which nodes must sleep. The node with the shortest wait time will wake up first and win the lottery, thus being allowed to commit a new block to the blockchain. PoET is of course more energy efficient because nodes will not waste energy trying to put blocks in.

Sawtooth PBFT

Sawtooth Practical Byzantine Fault Tolerance (PBFT) (modified version with respect to the original PBFT [3]) is a voting-based consensus algorithm that provides Byzantine fault tolerance. It comes with the drawback of an exponentially increasing message count as nodes are added to the set.

Once the leader node proposes a new block to be added, a series of messages exchanged among the nodes starts. The algorithm provides a provable resistance to a percentage of malicious nodes that depends on the implementation.

Sawtooth Raft

Raft is a leader-based consensus algorithm that provides crash fault tolerance (CFT): the keystone of the system is the leader that is assumed to always act honestly. Blocks added by the leader have not been forged and its updates are trustworthy.

The leader has a cohort of nodes that will simply propagate the updates from the leader and, in the case a crash occurs to the leader after a given timeout, a new leader is elected among the followers.

This algorithm has a natural resilience to CFT. For instance, on a network of six nodes, the quorum to elect a new leader is four (one more than half of the six available nodes).

Raft has the advantage of being more efficient (also from an energy point of view) than PBFT and PoET because there is no competition to add blocks among nodes, wasting CPU time; updates are simply propagated as long as the leader is up and running.

Dev mode consensus

Let’s shortly describe the devmode consensus algorithm that is provided by Sawtooth to just let the developers understand how to write a consensus algorithm from scratch.

Dev mode is, as the smartest of you already understood, a consensus algorithm to be used just in development mode: it has no crash tolerance and uses a simple simplified random-leader selection.

Discussion

The algorithms above diverge from the classical PoW consensus for some reasons:

• Sawtooth is designed for a scenario where the collaboration between the blocks committed by nodes are final, unlike lottery-style consensus algorithms such as Proof of Work (PoW) or Proof of Elapsed Time (PoET)
• pBFT is commonly thought of as an algorithm that does not scale. This perception is usually brought on by the notion of a node == server, which should not be the case with pBFT when deployed in an enterprise production environment
• pBFT should be used with a consortium of enterprise organizations, where each organization would represent a node on the network node == organization. Each of these organizational nodes should then have clusters of instances and load balancers behind the node’s endpoint to scale the computational power and ensure a quick response time

A sample application: Deploy a single-node Sawtooth installation

In this paragraph, we will start by deploying a single-node Sawtooth installation starting from a very simple Docker file that, for sake of simplicity, contains just the basic components needed for the demo.

In particular, we will deploy a single validator setting that is running a validator, a REST API, the dev mode consensus engine, and three transaction processors. The environment uses dev mode consensus and parallel transaction processing.

To better understand how different this is from a more powerful setting, let’s compare it with a four validator node setting:

Another simplification, with respect to a more realistic setting, is that we will use the dev mode consensus algorithm described above. I’ll explain how to change this to a more sensible consensus algorithm once the system works.

The repository and setup

We have provided a repository on GitHub for your convenience: you just have to clone from https://github.com/rosdec/single into a directory of your choice. Keep in mind that the suggested setting is under a Linux of choice, but with some more hammering, it will easily work under Windows or Mac OS.

Use Node 12 because some of the libraries are picky about the Node version. Install the dependencies and everything will be ready to run (further and detailed instructions are in the README on the repo).

The sample application has a very simple output and the whole logic behind it is not fancy: it will just store the payload (a string) in a specific address of the blockchain and it will retrieve it to check that everything works as expected.

A closer inspection of the code will help to understand what happens under the hood and will also let us catch the idea behind Sawtooth.

Source code inspection

The core of the sample application can be divided into two pieces: the processor (file processor/processor.js) and the interactions (file interact.js).

The processor is a sample transaction processor that expresses the full potential of Hyperledger Sawtooth: you can define what is a transaction and how it interacts with the blockchain storage.

This is a huge leap with respect to traditional blockchains (e.g., Ethereum and Bitcoin, of course) where transactions have a fixed way of interacting with the storage, mainly moving ethers or bitcoins between two or more accounts.

In Sawtooth, you can write your own processor in any language you prefer. In the sample application, our processor will simply store the transaction payload (a string) in a specific address (line 42). But you can design way more complex interactions, putting more logic at the transaction level instead of, for example, a smart contract.

This is the great advantage of using Sawtooth: it is a framework to write your own flavor of a blockchain, where logic can be pushed right in the transaction and not, necessarily, in smart contracts. As an example of this flexibility, you can check this repository where a transaction processor that will handle a tic-tac-toe game is described.

The interaction with the blockchain has just two methods, write_data and read_data, and both will interact with the blockchain by operating through the REST API (see the block in the diagram above). Reading from the blockchain is pretty straightforward; it is just the invocation of the API /state with the address from which to read.

Writing on the blockchain, on the other hand, consists of a specific sequence of steps. You can follow them in the interact.js file:

1. First, the transaction header is created that, most importantly, will contain the transaction family. That is, the transaction processor that will be invoked to handle our transaction (lines 48–58). Second, the transaction is signed (lines 61–66) by using the private key of the subject who is sending it;
2. Transactions are collected within a batch, a batch can collect transactions coming from different subjects and it is signed itself (lines 69–81);
3. Once the signed batch of transactions is ready, it is encoded (lines 84–86) in order to be safely used in the API invocation (lines 89–93).

Changing the consensus algorithm

After inspecting the source code, let’s have a glimpse at the Docker-composed file named single-node.yaml. It contains exactly the five components depicted above:

1. The transaction processor whose logic is described in the processor.js file;
2. The Sawtooth REST API that will just specify on which port it will be bound;
3. The mandatory settings transaction processor that allows interacting with the settings kept on the blockchain;
4. The validator describes the configuration of the validator node. As you may expect, here it is where the consensus algorithm is specified (line 48). In this version, it is specified that we will use the dev mode algorithm;
5. The devmode engine contains the (few) configurations of this specific algorithm

Changing the consensus algorithm is pretty simple: just modify the configuration of the validator node by choosing the algorithm you intend to use. For sake of clarity, we have used the dev mode engine, which runs comfortably with a single node; more complex algorithms need at least four nodes and, coherently, the docker-compose file is more complex.

As an example, check the GitHub that contains the configurations to use pBFT as a consensus algorithm (line 138) and how such an algorithm is set up for use in this scenario (lines 300–304); pBFT needs at least four nodes to work (because of the leader election), so you will find four validators nodes and, analogously, four pBFT engines, one for each validator.

Conclusion

Hyperledger Sawtooth is capable of accommodating a wide range of different blockchain configurations, allowing us to customize the way and the means of transactions. The consensus algorithm, which is central in the way the blockchain actually behaves, is configurable and, out of the box, an array of options are available in order to carefully select the performance of the blockchain and the resistance to Byzantine attacks.

References

1. Hyperledger Sawtooth ReadTheDocs – https://sawtooth.hyperledger.org/
2. Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto – https://bitcoin.org/bitcoin.pdf
3. Castro, M. and Liskov, B., 1999, February. Practical byzantine fault tolerance. In OsDI (Vol. 99, No. 1999, pp. 173-186). https://pmg.csail.mit.edu/papers/osdi99.pdf
4. “The Byzantine Generals Problem” Leslie Lamport, Robert Shostak, Marshall Pease- ACM Transactions on Programming Languages and Systems | July 1982, pp. 382-401

The post Hyperledger Sawtooth: A gentle introduction appeared first on LogRocket Blog.

from LogRocket Blog https://ift.tt/1jpHuqZ
via Read more