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.
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 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 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.
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.
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.
The algorithms above diverge from the classical PoW consensus for some reasons:
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.
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.
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:
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:
Learn more →processor.js file;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.
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.
Client-side issues that impact users’ ability to activate and transact in your apps can drastically affect your bottom line. If you’re interested in monitoring UX issues, automatically surfacing JavaScript errors, and tracking slow network requests and component load time, try LogRocket.
LogRocket lets you replay user sessions, eliminating guesswork around why bugs happen by showing exactly what users experienced. It captures console logs, errors, network requests, and pixel-perfect DOM recordings — compatible with all frameworks.
LogRocket's Galileo AI watches sessions for you, instantly identifying and explaining user struggles with automated monitoring of your entire product experience.
Modernize how you debug web and mobile apps — start monitoring for free.
React 19 breaks old third-party integrations. Learn why concurrent rendering exposes brittle SDKs and how to rebuild them with resilient modern patterns.
useEffectEvent: Goodbye to stale closure headachesDiscover why the useEffectEvent Hook is important, how to use it effectively, and how it compares to useRef.
Shadcn CLI 3.0 takes component management to a new level. With namespaced registries, private access, and AI-powered discovery, it’s now faster and smarter to build React UIs.
Zod’s flexibility comes at a cost. This article breaks down why Zod is slower than AOT-compiled validators like Typia, and how to fix it with a build-time optimization that brings production-grade performance.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
