By Dan Middleton, Sawtooth Lake Maintainer*
When I was asked to post about Sawtooth Lake, an obvious topic was “What is Sawtooth?” Well, Sawtooth Lake is a distributed ledger with novel consensus and transaction handling, incubated under the Hyperledger umbrella.
But maybe a more interesting question is “Why is Sawtooth?” Given the profusion of bitcoin forks and other blockchains why create another system? In a nutshell, there are usages that shouldn’t be contorted on top of a currency or on top of a centralized database – even if it’s replicated.
Originally, Sawtooth Lake was designed to explore scalability, security, and privacy questions prompted by the original distributed ledgers. That mandated a certain modularity that was lacking at the time. Starting from scratch allowed us to employ lessons from those pioneering systems and branch into usages that the original currency ledgers weren’t intended to address. PoET, the new consensus hits scalability, while Transaction Families, our contract logic, narrow the attack surface for contracts while simultaneously broadening the functionality. We also have a keen interest in trusted execution environments and what role that can play in private transactions.
In branching into new business cases, we felt it was important that the system preserve certain tenants of a distributed ledger. That is, in an enterprise deployment, the concept of a distributed ledger shouldn’t collapse into a replicated database. Enterprise participants need autonomy and they have the right to run their own nodes. The set of participants will also be dynamic and the system – particularly consensus – must accommodate that volatility. It is not clear, for example, whether an O(n2) protocol with fixed membership like PBFT can support the scale or volatility of a distributed ledger at production levels. Finally, we observed that, “public” and “private” define a spectrum of authorization policies – not a binary option for a distributed ledger.
Since open sourcing earlier this year, we’ve learned a lot from industry trials. Sawtooth Lake’s pluggable Transaction Families have enabled its use in exploratory projects across several industries, including recent public announcements of a global deployment in finance and as the reference platform for a music industry initiative. Likewise pluggable consensus allows Sawtooth Lake to be used in small tightly held networks or large broadly open networks. If there’s a sweet spot for Sawtooth Lake, though, it’s the Consortium Ledger.
Consortia
Before getting into the novelties of Sawtooth lake, it’s worth motivating the problem space. There are plenty of replicated databases. We want to build a truly distributed ledger. The business models in this space involve tens to hundreds of business entities. That puts some unique demands on the underlying distributed system.
Consortiums fit the bill for Distributed Ledger Technology (DLT) as a collection of related, but not fully trusting organizations, that can benefit from a shared view of data. One of the promises of DLT is that it creates win-win opportunities for organizations to open up silos. Eliminating intermediaries is an often cited benefit, but to me, DLT isn’t just about efficiencies, it’s about unlocking new ways to grow.
Consider a motivating example from supply chain, let’s say you want your product to use only ethically sourced minerals, but your company is several steps removed from mining the raw materials, refining them, etc. A shared ledger recording each transfer from materials harvesting to product assembly would let you trace the provenance and gain confidence that the end product is ethically sourced. To work well, that shared database needs input from a variety of companies. Without a shared ledger, it’s more difficult for any of the suppliers or retailers to advertise and capture the value of the ethical sourcing. While it might be possible to accomplish that with a single, centralized database managed by a governing entity, a DLT offers better and perhaps necessary features.
In too simple of an example, the supply chain has a single chain of relationships or perhaps a radial network with a center – which, importantly, could be served by a traditional, centralized database.
Overly Simplistic Supply Chain.
A real ecosystem, however, has a web of relationships. By looking at only one node in that network, its direct connections form a natural group that suggests it could be supported with a centralized database. But by observing that each of these nodes has a nexus of relationships – it’s own centrality – it’s clear there’s no single, central database that makes sense. Consider also the kinds of data that are relevant and not relevant to each peer.
A DLT is ideal for this kind of scenario where relationships and dependencies are many and varied.
We believe that a truly distributed ledger should provide autonomy to each participant, and that participants should be allowed to run their own nodes. A consortium may develop rules for authorizing participants, but centralizing the nodes and the control defeats the purpose of distribution and fails to satisfy the actual requirements of the participants.
Realistically, participating companies will be dynamic, entering and leaving the system as their business dictate. This mandates a truly distributed system, not just a replicated database.
PoET
Realizing this distributed ledger vision requires technology choices that satisfy requirements for autonomy and dynamic membership. In DLT the choice of consensus has a dramatic effect on the system as a whole. Sawtooth employs an experimental consensus algorithm we call Proof of Elapsed Time, or PoET. It’s a form of random leader election, wherein each validator node waits a random amount of time before trying to claim a block. In other random leader election algorithms like Proof of Work, that randomness is enforced by searching for partial hash collisions. PoET replaces that work with trusted computing.
The benefit of this is a more economical and greener algorithm (as compared to ASIC mining rigs). Rather than chips churning on hash functions, the trusted computing functions allow each node to get on with other work until its timer expires, putting computing cycles into useful operations without wasted electricity. PoET is a return to the Satoshi intent of “one-CPU-one-vote”.
In its original form PoET exists near the unpermissioned end of the policy spectrum. Any host that can provide certain cryptographic proofs about the correctness of its execution can publish a block. The sawtooth-core maintainers have begun adding scaffolding to support the more direct authorization models that consortia may require. The first policies in this new framework include basic requirements of a validator such that it is running the correct version of the consensus algorithm and that it has a verifiably unique identity on the network (an anti-sybil feature of PoET). The network itself validates authorization of each node as it joins the system. Once validated, those nodes and their authorization data are committed to a table on the ledger, called the Validator Registry. Building on these new features, participants in a network can define arbitrarily elaborate (or simple) authorization policies. This authorization framework then lets the underlying PoET consensus algorithm be utilized across a wide swath of the public to private ledger spectrum.
Family Ties
Transaction Families are unique to Sawtooth Lake. Transaction logic is, of course, another area of intense exploration in DLT development. This logic is akin to the stored procedures your grandmother may have written for her old-fashioned steam-powered database. The two most pressing questions about this so called “smart contract” layer are (1) where is the proper architectural divide in data control logic versus application logic, and (2) how expressive should that layer be?
With regard to expressiveness, Bitcoin started with too much power and has pared back over its evolution. Ethereum sought to provide more expressiveness but control it with economics. In both cases the appropriate divide between application logic and data control logic has been unclear and the allowed ledger operations have been exploited.
Transaction Families create a smaller surface tailored for each domain.
Sawtooth Lake’s Transaction Family architecture is meant to address the questions of architectural boundaries and transaction expressiveness. Rather than trying to create a new language or define the perfect set of opcodes for all domains, Transaction Families decompose the logic problem by domain. If we tease apart the logic layer into two layers we get a set of rules for a domain and a composition layer for creating versatile transactions within that domain.
Transaction families are at once more powerful and more restrictive than other approaches of logic. Transaction Family code is deployed natively within the validator. That embedded validator code defines a data model and a set of updates associated with the model. The DApps (Distributed apps) author can then compose new transaction logic out of the available update methods. We intend that this be a more secure approach than providing all logic for all domains as a single interface to the ledger. Transaction families more tightly bound the code that must be vetted allowing for more tractable analysis. Consider if you will, how the complexity of the DAO code led to this summer’s Ethereum problems.
Sawtooth deployed with two transaction families: Trading and Authorization
Returning again to the consortium ledger, the consortium can define the extent of flexibility on the data model for the domain they participate in. Take for instance some recent work where Sawtooth Lake was used to prototype a bond and settlement market. For this prototype, a transaction family was created specifically to execute only the required bond settlement operations, eliminating the possibility of executing, unallowed, unnecessary, and illegal operations. The consortium can vet and approve a family before it is deployed to the network. The consortium participants can then still differentiate and establish competitive contracts with reduced risk that unwanted operations ensue.
Similarly domains often have services important to that domain which might be inappropriate or unnecessary in others. Again, in the case of bonds, a time service is important to address payment terms for maturity. The granularity of that time is probably coarser than a supply chain domain focused on delivery of perishable goods like fish, or where the time source for that perishable good is provided by some external authority.
Finally there is a lot of energy surrounding private transactions. The Sawtooth-Core team is experimenting with private transactions using all the tools available including pure cryptographic techniques such as NIZK as well as trusted computing like Intel® SGX. This is an ill-defined space right now. It’s common to hear explicitly contradictory requirements like, the desire to discover assets on the ledger and settle the transfer of assets between parties while at the same time not listing the assets or parties on the ledger. Proposed solutions include recording only opaque identifiers for transactions but not the transactions or the assets themselves. A database that only has transaction IDs but no transactions or assets probably loses a lot of value. However, it’s possible that more interesting solutions exist using computationally expensive means like zero-knowledge relations or using trusted hardware with private enclaves.
Until next time…
I hope this has been an informative look into Sawtooth Lake. We are making a number of significant improvements at the time of this writing from our persistence mechanism up through transaction family API. Next time I’ll bring an update on those activities. Meanwhile you can find the work in progress in our github repo and docs. We are active on slack and there’s always someone around to help ramp a new contributor.
* Dan Middleton is an employee of IntelⓇ Corporation. The views expressed here are in the context of his role as an open source maintainer of Sawtooth Lake and do not necessarily represent those of IntelⓇ Corporation.
On Tuesday, Oct. 25 from 5:00-5:50pm in Lando, Level 4, Hyperledger Executive Director, Brian Behlendorf, will speak on behalf of the project in a blockchain panel titled, “
