Making smart contracts safe with Hyperledger Sawtooth
© Shutterstock /marekuliasz
Hyperledger Sawtooth 1.0 is now available — this is the second blockchain framework that has reached production-ready status. We talked with Dan Middleton, Hyperledger Sawtooth Project Maintainer about its differentiating features, the difference between Sawtooth and Fabric and what’s under its hood.
JAXenter: Hyperledger Sawtooth 1.0 has just been released. What’s the star feature of this milestone?
Dan Middleton: Since Hyperledger focuses on enterprise-grade blockchain technologies and is recognized as one of the leaders (rather than focusing on cryptocurrency), this is a major milestone for the Hyperledger technical community. Sawtooth has a number of differentiating features you’ll see listed below. The distinction for a 1.0 release, though, is not features but maturity. See #6 for a fuller description of what that means.
In a nutshell, though it means the code has been rigorously tested and reviewed, the platform has been field tested, and you can build your apps on the API without fear of it changing and breaking your apps — an issue that plagued many companies starting out with other blockchains.
Typically the backend or smart contract part of the application should be written in a performant language, and the client language should be selected for UI or client device considerations. This is not to say you can’t write everything in the same language. Many of our examples use Python on both sides because it’s easy to read. Our intent in providing a variety of SDKs is that not only can you select the right technology, but also you can use the language(s) for which your company has experience and staff.
JAXenter: What’s the difference between Sawtooth and Fabric? Could you name some of the applications for Sawtooth?
There’s a commitment from the Sawtooth maintainers that the 1.0 API won’t change underneath you.
Dan Middleton: Hyperledger Sawtooth 1.0 and Hyperledger Fabric 1.0 are both stable frameworks hosted by Hyperledger. Hyperledger Sawtooth’s design philosophy targets keeping distributed ledgers distributed and making smart contracts safe — particularly for enterprise use. Sawtooth is the first project to release with Byzantine Fault Tolerance options. This is a higher level of robustness than Crash Fault Tolerance.
Sawtooth also uniquely offers “global state agreement,” an assurance that each node has cryptographically identical copies of the blockchain database. Sawtooth also lets you program business logic (smart contracts) in your language of choice. Further Sawtooth can execute transactions in parallel for higher throughput.
So to summarize, Sawtooth 1.0 also differs from Fabric 1.0 in including
- State agreement (cryptographically verifiable databases)
- Byzantine Fault Tolerant Consensus
- Unpluggable consensus
- Multi-language support
- Parallel Transaction execution
JAXenter: Can it integrate with different blockchain technologies?
Dan Middleton: Yes, in August, an initial proof-of-concept integration between the Hyperledger Sawtooth and Hyperledger Burrow projects was completed. As a result of this integration, EVM smart contracts can be deployed to Hyperledger Sawtooth using the “Seth” (Sawtooth Ethereum) Transaction Family.
You can learn more about the integration here.
JAXenter: What is under its hood? How has it evolved since its early days at Intel?
Dan Middleton: Sawtooth started out as a research project that discovered two important innovations (PoET and Transaction Families). Since contributing it to Hyperledger, the code has been used by many companies which helped the emerging Sawtooth community discover and solve new problems. The internals have been completely rewritten from the original research code and now provide a host of new capabilities written to solve challenges exposed during field testing in enterprise environments.
A few of the features included in Hyperledger Sawtooth v1.0 include:
- On-chain governance – Utilize smart contracts to vote on blockchain configuration settings such as the allowed participants and smart contracts.
- Advanced transaction execution engine – Process transactions in parallel to accelerate block creation and validation.
- Support for Ethereum – Run solidity smart contracts and integrate with Ethereum tooling.
- Dynamic consensus – Modify the blockchain consensus protocol on the fly as your network grows, enabling you to integrate more scalable algorithms as they are available.
JAXenter: What should people understand at this point in this project’s maturation?
Our intent in providing a variety of SDKs is that not only can you select the right technology, but also you can use the language(s) for which your company has experience and staff.
Dan Middleton: This Hyperledger Sawtooth 1.0 release is the culmination of work from several companies intent on creating a distributed ledger designed for the enterprise. We would not have the rich features or deployment maturity today without the collaboration and contributions from these and other organizations (alphabetically): Active Ticketing, Amazon Web Services, Bitwise.io, Cloudsoft, Context Labs, Dot BC Media, Ericsson, Hacera, Huawei, IBM, Intel, Microsoft Azure, Monax, Open Music Initiative, PokitDok, R3, T-Mobile, Wind River, and several independent engineers.
Part of the run-up to our 1.0 release involved a strong shift from feature development to stability and stress testing. Each code change works its way through a sophisticated Continuous Integration testing process. Further, each release candidate build goes through an additional multi-day multi-node testnet evaluation. The code has also undergone static analysis and pen testing by 3rd party auditors.
Of course, all projects have bugs, and we will continue to find and fix these in Sawtooth, but the balance of investment and contribution from the community over the last several months has been to harden and mature the platform. Finally, there’s a commitment from the Sawtooth maintainers that the 1.0 API won’t change underneath you. Your company can feel confident building on that API knowing that future enhancements and fixes will be backwards compatible in point releases.