Hyperledger’s Sawtooth Lake Aims at a Thousand Transactions per Second
The Sawtooth Lake is an incubation project within the Hyperledger initiative—designed to enable better scalability and versatility. Its main distinctions are blockchain modularity and elapsed-time consensus.
Intel’s Dan Middleton, a member of Hyperledger’s Technical Steering Commitee, recently led a webinar, highlighting the new features delivered in version 0.8 and how they correlate with the ultimate goal of the project.
Current blockchain limitations
There are areas in blockchain that are still being actively researched and so leave room for improvement. One such area is scalability that is not similar to scalability in the web “where you would add more and more servers to get more and more throughput.”
“When we say scalability, what we’re talking about is the ability to have a lot of nodes in the network so you can have those properties of high availability and resistance to a variety of attacks.”
—Dan Middleton, Intel
There’s also a misconception with security in blockchain. “When we hear security, we think encryption and privacy,” said Dan. “The aspect of security in blockchain are high availability and integrity but encryption isn’t there yet. It doesn’t mean that encryption won’t be there but maybe in six months, two years, or five years from now.”
“Security guarantees in blockchain are with availability where the system cannot be taken down by an attacker. The database can’t be corrupted because you can’t insert a false record. There are controls to prevent you from changing parts of the database that you are not authorized to change.” —Dan Middleton, Intel
Fitting the needs of large blockchains
Keeping in mind the challenges associated with implementing distributed ledger technologies at scale, Dan pointed out how Sawtooth Lake may fit into the picture:
- Smaller networks for Hyperledger Fabric. The Fabric is focused on chaincode (smart contracts) and finding ways to work with the Practical Byzantine Fault Tolerance consensus mechanism.
- Larger networks for Sawtooth Lake. Higher throughput for larger networks. Sawtooth Lake’s approach to transaction logic are the transaction families.
Another issue that was brought up was the work involved in migrating smart contracts from another blockchain like Ethereum to Sawtooth Lake. According to Dan, there are two ways to go about this with a third option available for an Ethereum migration:
- Translate the smart contract into an already existing transaction family.
- Create a transaction family that is specific to the the asset needed, so that you are only creating operations that are required.
- There is already work being put into an Ethereum virtual machine that plugs into a transaction family for Sawtooth Lake.
With a focus on larger blockchain networks, Sawtooth Lake’s throughput was brought into question as “most proper blockchains are operating on the order of tens of transactions per second,” said Dan. “The biggest change we’ve done in a performance perspective so far is we’ve split off the cryptographic portions of validation into its own space that can operate faster.”
“One of the developers showed me a thousand transactions in a batch processed in under a second. That could potentially go up with the parallel scheduler.” —Dan Middleton, Intel
“There’s also the downside, though, once you start propagating those through the network,” said Dan, downplaying Sawtooth Lake’s throughput. “You do have the inter-block time to contend with that will lowers those rates.”
How does it work?
Dan has previously given an overview of Sawtooth Lake’s architecture, pluggable consensus system, and transaction families.
This time, he added more detail as to how the v0.8 architecture worked. According to Dan, the Validator Process Boundary contained all the core elements of a node. The Journal keeps track of changes to the system and sends transactions to the Transaction Executor, which ensures the transactions have the proper parameters to be committed to the database.
The Journal is also responsible for publishing blocks. With a pluggable consensus system, this is done through the Proof-of-Elapsed-Time (PoET) consensus, Dev Mode consensus, or whichever consensus mechanism is deployed in the system.
“In Dev Mode consensus, which we refer to as a dictator consensus, basically one node just gets to be the one that publishes blocks or you can put in something like PBFT.” —Dan Middleton, Intel
Outside the Validator Process Boundary is the Transaction Processor Process Boundary. “This is what enables us to deploy a system that might have a Python core, but might have Java transaction processors or any sort of language,” said Dan.
What’s new in v0.8?
Coming from the previous versions of the incubation, Sawtooth Lake v0.8 included new features:
- Parallel execution. Sawtooth Lake expands on the typical blockchain system that is single-threaded, allowing more than one transaction to happen.
- Multi-language support. Originally written in Python, Sawtooth Lake has good encapsulation throughout the system, allowing transaction families to be written in any language.
- On-chain configuration. Sawtooth Lake’s configuration is a transaction family. This hold true at least for the elements in the configuration that need to be agreed upon by all nodes in the system.
“Most blockchain systems are considered to be single-threaded that is we have to be careful about the ordering in which transactions happen. In a single-threaded system, there’s a limitation for throughput.” —Dan Middleton, Intel
What’s next?
Currently, the stable release for Sawtooth Lake is still v0.6 with the new v0.8 already seeing use. According to Dan, anyone looking to try operating the network should stick with v0.6 “for a more stable codebase.” On the other hand, anyone looking to do development work should move on to v0.8 due to “changes in the semantics of transaction families.”
As for v1.0, no release date were given and before Sawtooth Lake reaches that point, Dan emphasized the need for more public demonstration.
Want details? Watch the webinar recording!
Other Hyperledger Project updates
The general availability of Hyperledger Fabric v1.0 is expected soon—scheduled for March 31, 2017. As per the v1.0 roadmap, the new version is expected to eliminate non-deterministic transactions and improve scalability.
Soramitsu’s Iroha joined the Hyperledger Project incubation late last year. It is a blockchain with an emphasis on mobile application development.
R3 CEV’s Corda went open source last October. They plan on joining the Hyperledger Project and are currently awaiting the approval from the Technical Steering Committee.
Related slides
Related reading
- Hyperledger’s Sawtooth Lake Bets on Modular Blockchains and Elapsed-Time Consensus
- Hyperledger Fabric’s Chaincode, Practical Byzantine Fault Tolerance, and v1.0
- The Iroha Project to Bring Mobility to Blockchain with Simple APIs
- Hyperledger Fabric Approaches v1.0 with Better Scalability and Security