Hyperledger Sawtooth

Guest post: Ignasi Ribó (@seliestel)

On October 1 2017, Catalan citizens were called to the polls to decide whether they wanted to become an independent Republic or remain a region of Spain. This self-determination referendum had been promoted by the Catalan regional government with the support of civic organizations and a large part of the Catalan population. But there was one problem: the Spanish government was staunchly opposed to its celebration. As the day of the referendum approached, Spanish police and public prosecutors increased their repressive actions against Catalan citizens and institutions, including the seizure of websites, print houses, postal mail, and any other means by which the referendum could be carried out.

In spite of the repression, citizens occupied the polling stations days before the referendum in order to prevent the police from shutting them down. During October 1st, in an exemplary show of self-organization and resilience, thousands of people kept the polling stations open, defending ballot boxes with their bodies as policemen armed with riot gear tried to seize them by force. Hundreds were injured by the batons and rubber balls indiscriminately used by the police against peaceful voters. In spite of coordinated DDoS attacks throughout the day, anonymous citizens managed to sustain the computer systems used for voter registration. At the end, more than 2 million people were able to cast their ballot. But police brutality and the repressive actions of the Spanish state seriously disrupted the polling and managed to put into question the final results.

Inspired by these dramatic events, I began at the end of November 2017 to develop a blockchain application that would allow any concerned group of citizens to organize a referendum and deliver accurate and auditable results without having to rely on a central authority. The project aimed to strengthen grassroots democracy around the world and give people the ability to exercise their right to vote on any question they deemed relevant, whether central institutions and authorities approved the vote or not.

My interest in decentralized, direct democracy was not new. In my book Habitat: The Ecopolitical Nation I had already argued for the need to extend it as much as possible in order to achieve more sustainable and resilient commonwealths. But now I felt it was the time to work on a practical tool that could help to bring this ideal closer to reality.

Developing Bitagora

The first thing I needed to do was to devise a system for voter registration that would guarantee the anonymity of voters while ensuring that everyone casting a ballot was authorized to do so and that no one would be able to vote more than once in the same election. Centralized voting systems solve this problem by using official censuses and polling stations. For obvious reasons, a decentralized system could not rely on this machinery.

Fortunately, modern public-key cryptography offers the necessary tools to build systems that provide both anonymity and verifiability without relying on a central authority. In the Bitagora implementation, voters submit their identification to a fully automatic Certifier script that checks the validity of the information according to the requirements set by the promoters of the poll. If the identification is valid, the Certifier script generates a private key that is deterministically derived from the voter identification using a hashing function that would prevent an attacker from recovering the identification information of the voter even if he got hold of the private key. The Certifier also generates a token that includes the public key derived from the voter private key using the elliptic curve secp256k1 protocol, the same cryptographic cypher underlying Bitcoin. The Certifier signs this token with its own private key and sends the signature and the voter key back to the voter. With this key, the voter can then cast a ballot in the poll.

Enter Hyperledger Sawtooth

Once I had set up the registration system and a user interface (both mobile and web) that voters could use to register and cast their ballots, I still needed to develop the core functionality of the decentralized network of validators that had to sustain the trustless voting system (i.e., a blockchain).

One very attractive possibility was to build the voting system as a DApp running on the Ethereum Virtual Machine. But that would have required voters to interact with the network using a cryptocurrency. Without owning some amount of Ether, or some other fungible token, voters would not be able to pay for the transaction costs involved in executing the Bitagora smart contract. This didn’t look like a scalable, or even fair way of setting up a voting system that could be used by a large number of voters in a real election.

So I quickly discarded relying on any existing blockchain and opted instead for building my system using a private blockchain that would be sustained by volunteers and be completely free for voters. After reviewing several of the frameworks currently available to build such a system, I chose Hyperledger Sawtooth.

Unlike other frameworks, Hyperledger Sawtooth was meticulously documented, with exhaustive explanations and a wide range of examples and applications that worked right away without a flaw. It also provided a complete SDK in Javascript, the language I was already using to code my system. Moreover, the different modules were packaged in Docker containers, which greatly facilitated the installation and fit perfectly well in my strategy to make the Bitagora validator software easily deployable by a large number of nodes in various operating systems without having to go through messy installations.

As I started to work on developing the validator software using the Hyperledger Sawtooth framework, I also found that there was a very active community of engineers and developers exchanging information, ideas and support on the Hyperledger chat. Whenever I had a question I could not solve on my own, I would post it there and quickly receive valuable suggestions and advice from the Sawtooth team or from developers working on other projects. On some occasions, this chat was a lifesaver!

An open project

At the beginning of August, after months of development, I finally distributed the code of the different Bitagora modules through Github under an Apache 2 license. With the help of the Catalan Pirate Party, I had previously conducted several tests and the system performed really well, thanks in particular to the robust consensus mechanism employed by the Hyperledger Sawtooth network layer. The platform is now ready for anyone to set up and use in all sorts of elections.

Since I am not a professional developer, I don’t have the time or resources to sustain this project on my own beyond its current state. But I would be happy to work with other people interested in expanding and improving Bitagora in order to turn it into a fully functional and open-source tool that can enhance direct democracy and empower voters around the world.

If you’re interested in learning more about the project, you can do so at https://bitagora.cc. You can also help contribute code by visiting: https://github.com/bitagora/bitagora-core

Guest post: Jonatan Alava

Hyperledger Sawtooth 1.0 has been widely available since January 2018. This is the second Hyperledger product to get to 1.0 and become widely available. The project in its current iteration employs a more familiar DLT implementation when contrasted with Hyperledger Fabric for developers that have worked on some of the other popular blockchain projects. Its simple architecture not only enables a very small learning curve, but makes it real easy to setup a network and implement custom applications. It’s also great that the product comes with a rich SDK and documentation as well as boasts an active community that will help you answer questions on Hyperledger chat or live calls setup to support all developers working with Sawtooth. Let’s dig a bit deeper into the modularity and flexibility of the product while at the same time provide a simple introduction to Sawtooth development.

Separation of concerns redux — Application vs. Core System

Before digging into code, let’s cover what we have found to be the cornerstone behind Sawtooth’s design, a clear separation of concerns. This makes Sawtooth an easy to use framework. Any use case can be implemented without having to touch core network elements. Transaction families can be developed to process any logic needed within the network and multiple families can be deployed on the same network. Here we cover two extremes in a sample spectrum of transaction families to display the flexible range of implementations while at the same time show the practicality of the framework for solutions with real uses.

To read more about its architecture & design details please see the docs here.

Games Hyperledger Plays

As part of robust documentation, Sawtooth comes packed with a set of pre-defined transaction families. The one that caught my attention right away was the XO family.

The XO transaction family enables your DLT network to support games of Tic Tac Toe between two registered users. All those users need are valid credentials and access to the network.

Tic Tac Toe

The “thrill” of playing Tic Tac Toe on a robust DLT powered network alone is worth some level of analysis. The XO transaction family includes a very specific set of functions, which are great for demystifying the capabilities of Hyperledger Sawtooth. All the business logic is implemented within the TransactionHandler and its apply method. Below I’ll go over some highlights of the transaction family implementation using the Javascript SDK.

Let’s start by how simple the file structure is:

Each one of those .js files implements one of the key components of a transaction family; A transaction handler (xo_handler.js), the family’s state (xo_state.js) and the payload (xo_payload.js) to be obfuscated simply to avoid shallow inspection.

Creating a game simply checks for uniqueness by name and then defines a new Game containing, Name, Players, State and Board. The code in JS is as simple as its description:

if (game !== undefined) {
throw new InvalidTransaction(‘Invalid Action: Game already exists.’)
}
let createdGame = {
name: payload.name,
board: ‘ — — — — -’,
state: ‘P1-NEXT’,
player1: ‘’,
player2: ‘’


And once that object is created, it just gets saved to State.

return xoState.setGame(payload.name, createdGame)

Similar to Create, there is a Delete game action. This simply looks up a game by name and if found deletes it from state. As a side note, if you are wondering what it truly means to fetch a game from State, it is also implemented within the transaction family specification. An XOState includes all games serialized, and in order to fetch a particular game by name, the list gets deserialized and a simple search is applied on the list.

return this._loadGames(name).then((games) => games.get(name))

Finally, the most interesting action is Take. Take is called by game participants taking their turn. It starts by fetching a game by name, then validating a valid position on the board being taken and ensuring the right user is taking this turn. Once the turn is taken, the action checks for a winner.

if (_isWin(game.board, ‘X’)) {
game.state = ‘P1-WIN’
} else if (_isWin(game.board, ‘O’)) {
game.state = ‘P2-WIN’
else if (game.board.search(‘-’) === -1) {
game.state = ‘TIE’
}

The _isWin function is very simple to read, since it hard codes all permutations a player can win on Tic Tac Toe and iterates through them. In case you are wondering, this is what those winning positions look like:

let wins = [
[1, 2, 3],
[4, 5, 6],
[7, 8, 9],
[1, 4, 7],
[2, 5, 8],
[3, 6, 9],
[1, 5, 9],
[3, 5, 7] ]

Setting up an XO DLT

As described earlier; documentation is also very robust and easy to follow in order to set up your own test or development network. Using the docker compose file provided you can stand up your development network right away. Validators and transaction processors are part of the default configuration and transaction processors will have all sample families pre-loaded. If the right transaction family is not loaded you can run the following:

sawset proposal create — url http://rest-api:8008
— key /root/.sawtooth/keys/my_key.priv
sawtooth.validator.transaction_families=’[{“family”: “xo”, “version”: “1.0”},
{“family”:”sawtooth_settings”, “version”:”1.0"}]’

Once you start up your network and ensure your transaction processors have the XO family included all you have to do is register users and start playing. As explained on the transaction family overview, the game can be played through the CLI without having to write any extra lines of code and simply using the pre-defined operations.

Is this the future?

Running this example does not feel like an accomplishment at all, but it is one of the best ways to clearly explain DLT to a friend that has never heard about Blockchain. (Similar article here) The immediate question after this is; how powerful and transformative can DLT be right now? After all, we just ran through a command line controlled example of Tic Tac Toe. It’s hard to see this as a game changer.

So, let’s go back to the basics of software development. The game changer is the ability to so easily implement Tic Tac Toe as a DLT application without needing to architect the underlying network. The built in separation of concerns allows a single file Tic Tac Toe implementation to run on such a powerful infrastructure and to leverage all the core features of DLT. This is what makes this Hyperledger project so powerful.

Hyperledger Sawtooth solves asset transfers

We started with Tic Tac Toe; other solutions can only get better and the community aspects of Hyperledger inspire collaboration. A company called Pokitdok defined a more interesting transaction family and shared its overall design with the world. You can read about it here. To quickly summarize, they have defined a new transaction family which supports their in-ledger asset and created it as an integral component of their operation by batching transactions from their application specific families with coin transactions. You can read more specifics about cross family transaction batching here.

What is interesting is the fact that this solution allows an existing network, to add accounting and asset transfers on a DLT without changing any of its core structure. Just like with our initial example, the power of Sawtooth lies in its clear separation of concerns.

Setting up a DLT to move assets around

We keep mentioning how great this separation of concerns is, but how different do two DLT applications need to really be and how much should the underlying network change to support these two extremes in a complexity spectrum? Setup is exactly the same for these two implementations. You could even use the development ready docker composer files provided by the Sawtooth team. The only change that will need to be applied is to run a new transaction family create command to add the newly defined asset management transaction family. It would look something like this:

sawset proposal create — url http://rest-api:8008 
— key /root/.sawtooth/keys/my_key.priv
sawtooth.validator.transaction_families=’[{“family”: “assets”, “version”: “1.0”},
{“family”:”sawtooth_settings”, “version”:”1.0"}]’

Now this is more like it; with all the talk of DLT and how it’s going to change the face of software forever, it’s refreshing to see how simple it can be to run a full fledged crypto asset management network.

Putting it all together

These examples were not meant to prove the validity of DLT, rather to illustrate the simplicity and practicality of Hyperledger Sawtooth. To demystify the utility and complexity of DLT powered solutions and create a simple path towards more meaningful implementations and uses of the technology. The Hyperledger Sawtooth framework allows you to easily implement your application’s logic as a transaction family and have it running on a scalable DLT network within minutes.

Sawtooth is built for performance and decent scalability and as mentioned earlier has a simple network structure that allows for very large deployments without a lot of specialized software components. At its core, its focus on separation of concerns empowers developers to create any transaction family you can think of. The asset management example also allows us to see how incredibly powerful composition through reuse could become.

The project also shows great promise for extensibility for larger & open, not just permissioned solutions. Finally, the addition of yet another really powerful transaction family called SETH extends Sawtooth to process Ethereum smart contracts. With some minor changes, any Sawtooth network that includes SETH would be able to run any solidity contract. Our team is currently working on migrating one of our Ethereum powered solutions into our own Sawtooth network and hopefully soon we will share it on another blog post.