Category

Hyperledger Sawtooth

Making Dynamic Consensus More Dynamic

By | Blog, Hyperledger Sawtooth

In October 2017, the Hyperledger Sawtooth team started to implement a new consensus algorithm for Hyperledger Sawtooth. We wanted a voting-based algorithm with finality, which is very different from the Proof of Elapsed Time (PoET) consensus algorithm that has been closely associated with Hyperledger Sawtooth since its start. This project presented a number of challenges and opportunities.

The greatest challenge in implementing this new consensus algorithm with Sawtooth was in breaking apart an architecture that has been heavily influenced by a lottery-based consensus algorithm with forking. A lot of refactoring and architectural work went into making both voting-based and lottery-based algorithms work well with Sawtooth.

However, the opportunities that we discovered from this effort made overcoming these challenges more than worth it. We designed a new consensus API that simplifies the process of adding new consensus algorithms while continuing to support the existing PoET and Dev mode consensus algorithms. We completed the first prototype validator with consensus API support in July 2018. Since then, we have been able to implement two new voting-based consensus algorithms for the Hyperledger Sawtooth platform: Raft and PBFT.

We are pleased to announce that the Sawtooth 1.1 release supports the new consensus API. This release also includes consensus SDKs to make it easier to implement new consensus algorithms.

Consensus as a Process

The new consensus architecture moves consensus functionality to a separate process, called a consensus engine, and provides an API for each consensus engine to interact with the validator.

Moving the consensus functionality to a separate process allows consensus engines to be implemented in a variety of languages. Currently, SDKs are available for Python and Rust and have been used to create the consensus engines for PoET, PBFT, and Raft.

Multi-language support is important beyond providing a choice for implementing a new consensus engine. This support makes it much easier to reuse existing implementations of consensus algorithms. For example, the Sawtooth Raft consensus engine is built on the pingcap/raft-rs library. We were able to easily integrate this well-regarded Raft library, which is itself a port from the widely-used etcd Raft library.

As SDKs for additional languages are built on top of the consensus API, it will be possible to add more and more consensus algorithms into Hyperledger Sawtooth. For example, a consensus SDK for Go would bring existing implementations such as Hyperledger Labs’ MinBFT one step closer to being compatible with Sawtooth.

Driving the Blockchain with a Consensus Engine

The consensus API is centered around a new consensus engine abstraction that handles consensus-specific functionality. A consensus engine is a separate process that interacts with the validator through the consensus API using protobuf messages and ZMQ.

The role of a consensus engine is to advance the blockchain by creating new blocks and deciding which blocks should be committed. Specifically, a consensus engine must accomplish the following tasks:

  • Determine consensus-related messages to send to peers
  • Send commands to progress the blockchain
  • React to updates from the validator

The validator continues to handle the mechanics of validation, communication, and storage for blocks, batches, and transactions. The validator must perform these tasks:

  • Validate the integrity of blocks, batches, and transactions
  • Validate the signatures for blocks, batches, transactions, and messages
  • Gossip blocks, batches, and transactions
  • Handle the mechanics of block creation and storage
  • Manage the chain head directly

New Consensus API and SDKs

The validator exposes the API for consensus engines as a set of protobuf messages sent over a network interface. This API is split into two types of interactions:

  • Service: A pair of (request, response) messages that allow a consensus engine to send commands to the validator and receive information back. For example, a consensus engine can instruct the validator to commit a block or request an on-chain setting from a specific block. Services are synchronous and on-demand.
  • Updates: Information that the validator sends to a consensus engine, such as the arrival of a new block or receipt of a new consensus message from a peer. Updates are sent asynchronously as they occur.

Although you could use the API directly to implement a new consensus engine, the recommended interface is a consensus SDK. The SDK provides several useful classes that make it easier to implement a consensus engine. Sawtooth currently provides consensus SDKs for Python and Rust. We have used these SDKs to create the consensus engines for the PoET engine (Python), PBFT engine (Rust), and Raft engine (Rust).

These SDKs have a consistent design with an abstract Engine class, an engine Driver, and a validator Service. The abstract Engine class provides a clear starting point for new consensus engine implementations. If you plan to write your own consensus SDK, we recommend conforming to this design.

Try it Today!

One of the most important decisions for a distributed ledger application is the choice of consensus. By opening up this interface, we hope that each application built on Hyperledger Sawtooth can select the consensus algorithm that suits it best.

Hyperledger Sawtooth Blockchain Security (Part Three)

By | Blog, Hyperledger Sawtooth

This is the conclusion of my three-part series on Hyperledger Sawtooth Security. I started with Sawtooth consensus algorithms in part one, then continued with Sawtooth node and transaction processor security in part two. Here I will conclude by discussing Sawtooth application security and Sawtooth network security.

Client Application Security

The client part of a Sawtooth application is written by the application developer. The Sawtooth client communicates with a Sawtooth node by REST API requests, including signed transactions and batches. The signing is performed with a private key and, as such, key management and security is important. With Bitcoins, for example, poor key management has resulted in stolen Bitcoins and a “graveyard of Bitcoins” that are inaccessible forever. Key management is the responsibility of the client application as keys are not managed by Sawtooth software.

A keystore is where you securely store your keys. The public key for a keypair, used for signature verification, can be and should be distributed to anyone. The private key portion, used for signing, must be safeguarded from access by others. Here are some keystore methods, ordered from low to high security:

  • The minimum security used should restrict access to the private key. That is either restrict access to the machine holding the key or restrict read access to the private key file to the signer or (better yet) both
  • Better protection would be the use of software-encrypted keystore. This would be a private keystore accessible by a PIN
  • The best protection is from a Hardware Security Module (HSM) keystore or a network-accessible key manager, accessed using the Key Management Interoperability Protocol (KMIP)

Client Authentication

A Sawtooth client may take external user input. In which case, it is important to authenticate that the user is who they say they are. Authentication methods are usually categorized, from low to high security, into:

  • Single-factor Authentication (SFA). SFA is something you know. It could be something like a PIN, password, passphrase, or one-time password (OTP). The main disadvantage with SFA is it could be weak or hard to remember
  • Two-factor Authentication (2FA). 2FA is SFA plus something you have. It could be a security key, such as a U2F token (e.g., YubiKey). The main disadvantage with 2FA is it can be lost or stolen

  • Three-factor Authentication (3FA). 3FA is 1FA and 2FA plus something you are (biometrics). Examples include fingerprints, face recognition, or retina scan. The main disadvantages with 3FA is it can be forged and cannot be easily changed

With 2FA and 3FA, the idea is defense-in-depth (i.e., multiple hurdles to authenticate).

Network Security

Blockchains are subject to Distributed Denial of Service (DDoS) attacks. That is, an attack that attempts to overload blockchain nodes by flooding the targeted nodes with bogus messages. Classical public, unpermissioned blockchain networks avoid DDoS attacks because transactions require spending digital currency (such as Bitcoin), making attacks costly. Also, public blockchain networks are highly distributed—with thousands of nodes—making a DDoS attack on the entire network impractical.

Private or permissioned blockchains, such as Sawtooth, are not designed to run on a public network. As such, they do not require digital currency and “mining.”

Sawtooth network can and should be mitigated against DDoS attacks as follows:

  • Back pressure, a flow-control technique to reject unusually frequent client submissions. If the validator is overwhelmed, it will stop accepting new batches until it can handle more work. The number of batches the validator can accept is based on a multiplier (currently two) of a rolling average of the number of published batches.
  • Sawtooth communication uses the Zero Message Queue (ZMQ or 0MQ) message library. Sawtooth optionally enables encryption with ZMQ when the network_public_key and network_private_key settings are defined in validator.toml. For production, generate your own key pair instead of using a predefined key that may be present.
  • REST API input is validated to avoid buffer corruption or overflow attacks.
  • TCP port 4004, used for communication between internal validator node components, should be closed to outside access in any firewall configuration,
  • TCP port 5050, used to communicate between the validator node and the consensus engine, should be closed to outside access in any firewall configuration.
  • TCP port 8008, used for the REST API, should be closed to outside access in a firewall configuration providing all application clients accessing the REST API come from the local host.
  • If you use the Seth TP (for WASM smart contracts), TCP port 3030, used for Seth RPC, should be closed to outside access in a firewall configuration, providing all RPC requests come from the local host.
  • TCP port 8800, used to communicate between validator nodes, must be open to outside access in any firewall configuration.

Sawtooth validator nodes should be deployed on a VPN or other private network to prevent any outside access to Sawtooth TCP ports.

Basically, best practices dictate closing as many network ports as possible, encrypting network communications, and deploying in a protected network environment (such as a VPN).

Further Information

Announcing Hyperledger Sawtooth 1.1

By | Blog, Hyperledger Sawtooth

It is with great excitement that we would like to announce the release of Sawtooth version 1.1. Earlier this year we released Sawtooth 1.0, marking the production ready status of the platform. Since then the community has been hard at work adding new features, improving the privacy and performance of the platform, and growing the ecosystem.

The Sawtooth development team has been focused on two major new features for the Sawtooth 1.1 release, an improved consensus interface and support for WebAssembly smart contracts. For a full list of new features and improvements see the Sawtooth 1.1 Release Notes.

Improved consensus interface and new consensus options

While Sawtooth has always enabled ‘pluggable’ consensus and multiple consensus algorithms, recent experiences indicated that the existing consensus interface could be improved. Sawtooth has always aspired to be a modular platform that would enable lean experimentation and rapid adoption of new technologies, in particular, with regards to consensus. After analyzing a number of consensus algorithms that are available today, both Nakamoto (PoW/PoET) and classical (Raft/PBFT), the team decided to re-architect the consensus interface to improve the ease of integration. As a result of this new interface, the team has been able to port the existing Sawtooth consensus options, as well as add two new classical consensus options. Below is the state of these consensus options today:

    • Developer Mode (stable)
    • PoET-Simulator (Crash Fault Tolerant) (stable)
    • PoET-SGX (under development)
    • Raft (alpha)
    • PBFT (under development)

If you are interested in learning more about the new consensus interface, or writing your own, please see the detailed documentation.

Support for WebAssembly smart contracts (Sawtooth Sabre)

Sawtooth Sabre is a new smart contract engine for Sawtooth that enables the execution of WebAssembly-based smart contracts. WebAssembly (WASM) is a new web standard developed at the W3C with participation from major corporations like Apple, Google, and Microsoft. The Sawtooth Sabre project leverages an existing open source WASM interpreter from the broader blockchain community. This on-chain interpreter enables developers to write their code in a variety of languages, compile it down to WebAssembly, and then deploy it directly to the Sawtooth blockchain.

In addition to new feature development, the Sawtooth developer team has continued research and development on improving the privacy and performance of the Sawtooth platform.

Privacy:

On the privacy front, a new Hyperledger Lab called ‘Private Data Objects (PDO)’ has been created. PDO enables smart contracts to execute off-chain with confidentiality and integrity through the use of trusted execution environments. For more information, take a look at this video or read the paper. Private data objects are just one way of addressing blockchain confidentiality, but expect to see more techniques available to Sawtooth over the coming months.

Performance:

On the performance front, much of the effort has been spent porting core Sawtooth components from Python to Rust. While Python was a great language to start with, and enabled the team to rapidly iterate and define the appropriate modularity in the architecture, it is not the most performant language. The 1.0 release stabilized many of the Sawtooth APIs, and as we began tuning the system, we identified bottlenecks arising from the design of the Python programing language. The speed and type safety of the Rust programming language made it a natural fit for the evolution of Sawtooth. As of today, roughly 40% of the Sawtooth validator components have been ported to Rust, a number that we expect will continue to increase over time.

Finally, in addition to adding new features and improving the robustness of the Sawtooth platform, we have also seen an explosion of activity in the community, with dozens of new developers and a variety of tools and applications being openly built on top the Sawtooth infrastructure. Notable new projects in the Sawtooth ecosystem include:

Applications:

  • Sawtooth Supply Chain – A platform focused on supply train traceability with contributors from Bitwise IO and Cargill.
  • Sawtooth Next-Directory – An application focused on role-based access control with contributors from T-Mobile.

Tools:

  • Truffle integration with Sawtooth-Seth – A new integration that allows you to deploy Ethereum smart contracts to Sawtooth using the leading Ethereum development tool, Truffle. Built in collaboration with the Truffle team.
  • Caliper support for Sawtooth – Benchmark Sawtooth in a variety of configurations with Hyperledger Caliper.
  • Sawooth Explorer – A blockchain explorer built for Sawtooth by the team at PokitDok.
  • Grafana monitoring – A set of tools for data collection and visualization for live Sawtooth deployments.

Part of a Grafana dashboard for a Sawtooth Testnet running Raft

The Sawtooth ecosystem and functionality is rapidly expanding, which wouldn’t be possible without the community behind it. I’d like to thank all of the developers who have put in time building tools and applications, or providing support, for their effort, including, but not limited to:

Adam Gering, Adam Ludvik, Adam Parker, Al Hulaton, Amol Kulkarni, Andrea Gunderson, Andrew Backer, Andrew Donald Kennedy, Anne Chenette, Arthur Greef, Ashish Kumar Mishra, Benoit Razet, Boyd Johnson, Bridger Herman, Chris Spanton, Dan Anderson, Dan Middleton, Darian Plumb, Eloá Franca Verona, Gini Harrison, Griffin Howlett, James Mitchell, Joel Dudley, Jonathan Langlois, Kelly Olson, Keith Bloomfield Kenneth Koski, Kevin O’Donnell, Kevin Solorio, Logan Seeley, Manoj Gopalakrishnan, Michael Nguyen, Mike Zaccardo, Nick Drozd, Pankaj Goyal, PGobz, Patrick BUI, Peter Schwarz, Rajeev Ranjan, Richard Berg, Ry Jones, Ryan Banks, Ryan Beck-Buysse, Serge Koba, Shawn T. Amundson, Sutrannu, Tom Barnes, Tomislav Markovski, Yunhang Chen, Zac Delventhal, devsatishm, feihujiang, joewright, kidrecursive, mithunshashidhara, and ruffsl.

If you’d like to join the community or learn more, you can find more information here:

Chat: #Sawtooth in Hyperledger RocketChat

Docs: Sawtooth 1.1 Documentation

Code: Sawtooth-core Github

Website: Hyperledger Sawtooth Homepage

Thanks for reading and look forward to more posts detailing new Sawtooth 1.1 features and improvements. We encourage developers to try these new feature out and give us feedback!

 

All Are Welcome Here

By | Blog, Hyperledger Burrow, Hyperledger Fabric, Hyperledger Indy, Hyperledger Iroha, Hyperledger Sawtooth

A Minneapolis coffee shop that has fueled or at least caffeinated a lot of Hyperledger commits.

One of the first things people learn when coming to Hyperledger is that Hyperledger isn’t, like it’s name may imply, a ledger. It is a collection of blockchain technology projects. When we started out it was clear almost immediately that a single project could not satisfy the broad range of uses nor explore enough creative and useful approaches to fit those needs. Having a portfolio of projects, though, enables us to have the variety of ideas and contributors to become a strong open source community. Back in January of 2016 Sawtooth and Fabric were both on the horizon followed shortly by Iroha, but we wouldn’t have predicted that we would have Hyperledger Burrow and Hyperledger Indy – two projects that bear no resemblance to each other. Burrow is a permissioned Ethereum-based platform and Indy is a distributed identity ledger. Burrow is written in Go, and Indy was created in Python and is porting to Rust.

Both of these platforms are interesting in their own rights, but Hyperledger is even more interesting for the combination of these projects with the others. Both Sawtooth and Fabric have already integrated with Burrow’s EVM. Now Hyperledger has a set of offerings that can simultaneously satisfy diverse requirements for smart contract language, permissioning, and consensus. Likewise Sawtooth and Indy have been working together at our last several hackfests. The results of that may unlock new use cases and deployment architectures for distributed identity. So it’s not that our multiplicity of projects has given us strength through numbers, but rather strength through diversity.

Hyperledger Hackfest – December 2017 at The Underground Lisboa

The hackfests that we mentioned are one of the rare times that we get together face to face. Most of our collaboration is over mail list, chat, and pull-requests. When we do get together though it’s always in a new city with new faces. One of our most recent projects was hatched inside one of those buses. It wasn’t the most ergonomic meeting I’ve ever had but there was room for everyone on that bus.

Hyperledger Hackfest in Chicago

Our hackfest in Chicago was in a lot more conventional surroundings (still a very cool shared creative space .. lots of lab equipment and benches out of view on the other side of the wall to the right). Looking back at this photo is fun for me. I can see a lot of separate conversations happening at each table… people sharing different ideas, helping ramp new contributors, working on advancing new concepts with existing contributors. I can see a lot of similarity but also a little variety. It’s a busy room but there’s still open chairs and room for more variety.

Our next hackfest won’t be until March 2019 (Hyperledger is hosting Hyperledger Global Forum in December in Basel though). The March hackfest will be somewhere in Asia – location to be settled soon. The dates and locations of the other 2019 hackfests aren’t set yet. I don’t know where they will be specifically, but I do know that there will be a seat available and you will be welcome there.

These face to face meetings really are more the exception than the rule at Hyperledger. There are now more than 780 contributors spread all across the globe. 165 of those were just in the last few months. That means that every day we have a new person contributing to Hyperledger. Most of our engagement is through the development process. People contribute bug fixes, write new documentation, develop new features, file bugs, etc. If you’ve never contributed open source code before getting started might be intimidating. We don’t want it to be, though. There are a number of resources to help you get started. You can watch this quick video from Community Architect, Tracy Kuhrt. There’s documentation for each project, mail lists, a chat server, working groups, and some of the projects even host weekly phone calls to help new developers get engaged. Everyone in Hyperledger abides by a Code of Conduct so you can feel comfortable knowing that when you join any of those forums you will be treated respectfully. Anyone who wants to get involved can regardless of “physical appearance, race, ethnic origin, genetic differences, national or social origin, name, religion, gender, sexual orientation, family or health situation, pregnancy, disability, age, education, wealth, domicile, political view, morals, employment, or union activity.” We know that to get the best ideas, best code, best user experience we need your involvement. Please come join our community.

Image created by https://allarewelcomehere.us/ for Hyperledger

As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions: info@hyperledger.org.

Hyperledger Sawtooth Blockchain Security (Part Two)

By | Blog, Hyperledger Sawtooth

Guest Post by Dan  Anderson, Intel

 

This is a continuation of my three-part series on Hyperledger Sawtooth Security. I began with Sawtooth consensus algorithms in part one. Here I will continue this series discussing Sawtooth node and transaction processor security.

Sawtooth Node and Transaction Processor Security

Sawtooth has several mechanisms to restrict and secure access to validator peer nodes. These include the following topics, which I’ll discuss below:

  • Sawtooth Permissioning, Policies and Roles
  • Network Roles
  • Challenge-Response Authorization
  • Sawtooth Encryption
  • Transaction Input/Output lists
  • Observability
  • Internal Security Mechanisms

Sawtooth Permissioning

Prelude: Configuration

Permissioning restricts who may access a Sawtooth validator node. Permissioning is set with Sawtooth configuration, so before we can discuss permissioning, we need to review configuration. After that, we will discuss various types of Sawtooth Permissioning.

Sawtooth configuration is set with on-chain configuration or off-chain configuration. On-chain configuration is configuration settings recorded in the blockchain, with changes or additions made as new blocks added to the blockchain. On-chain configuration applies to the entire Sawtooth network for that blockchain. Off-chain configuration is configuration settings recorded in the local validator.toml file, located by default at /etc/sawtooth/validator.toml, and applies to only to the local validator node. This allows further local restrictions for a site, if desired.

The initial permission values are configured in the genesis node (node 0), or, if not set, assume default values. On-chain settings can be modified any time by adding a transaction to the blockchain using the Settings Transaction Processor (which is the only mandatory TP). The change does not take effect until the next block (never the current block that contains the new setting).

On-chain settings are changed through a voting mechanism. Voters (individual peer nodes) are listed in sawtooth.settings.vote.authorized_keys. The votes are signed by each peer node as a transaction and recorded on-chain. If only one voter is authorized, the change is immediate. If multiple voters are authorized, the change takes effect when the minimum percentage of votes is reached. The Settings TP manages the election results.

Transaction Family Permissioning

Transaction family permissioning controls what TFs are supported by the current Sawtooth network. All nodes in a Sawtooth network must support the same set of TFs and versions. The applicable setting is sawtooth.validator.transaction_families For example,
[{“family”:”sawtooth_settings”, “version”:”1.0″}, {“family”:”xo”, “version”:”1.0″}]
By default, any Transaction Family is supported by a Sawtooth network.

One can also restrict transaction processors to their own namespaces (the 6 hex character TF namespace). When set, the validator prohibits reads and writes outside a TF namespace. For example,

[{“family”:”sawtooth_settings”, “version”:”1.0″}, {“family”:”intkey”, “version”:”1.0″}]
[{“family”:”sawtooth_settings”, “version”:”1.0″}, {“family”:”intkey”, “version”:”1.0″, “namespaces”:[“1cf126”]}]’

Here is an example of setting the transaction family permissions on the command line on-chain:

$ sawset proposal create –url http://localhost:8008 –key /etc/sawtooth/keys/validator.priv sawtooth.validator.transaction_families='[{“family”:”sawtooth_settings”, “version”:”1.0″}, {“family”:”intkey”, “version”:”1.0″}]’

The above settings can also be set off-chain in a configuration file, in which case it applies only to the local node. For example, in validator.toml :

 

[permissions]

“sawtooth.validator.transaction_families” = “[{\”family\”:\”sawtooth_settings\”, \”version\”:\”1.0\”}, {\”family\”:\”intkey\”, \”version\”:\”1.0\”}]”

Policies and Roles

Transaction key permissioning use policies and roles, which are implemented using the Identity Transaction Family. A policy is just a set of PERMIT_KEY and DENY_KEY rules that are evaluated in the order listed. A role is an authorization that grants permission to perform operations and access data. Roles and policies may be stored on-chain, as blockchain transactions, or off-chain, in configuration files, in which case they apply to the local node only. An example of a role is transactor.transaction_signer.intkey, which authorizes who can sign intkey transaction family transactions. An example of a policy is
“PERMIT_KEY 03eb5418588737e1b3982f4d863e01e13fd0da03ee2ac51b090860db3bdbbf39b2” “DENY_KEY *”
which denies access to all but the signer identified by their public key beginning with 03eb.

Before roles and policies can be set, sawtooth.identity.allowed_keys must be set to the key(s) of the authorized signers of Identity Transaction Family transactions. For example, the following allows Alice to make Identity TF transactions:

$ sudo sawset proposal create –key /etc/sawtooth/keys/validator.priv sawtooth.identity.allowed_keys=$(cat ~/.sawtooth/keys/alice.pub)

Before roles can be set to policies, policies must be created. A policy is a sequence of PERMIT_KEY and DENY_KEY keywords followed by an identity, which is the public key of a signer. The public key is 64 hex digits, such as 03305c4911bfdbe36c3be526ba665b0638e4376a920844a351708ec94c89ae70fa . A policy can be set on-chain or off-chain. Here’s an example of an on-chain setting:

 

$ sawtooth identity policy create dans_policy1 \

   “PERMIT_KEY 02a1035d8a6277adf5b92e8f831f647235224fe4dc8660f8bcddf85707156307b5” \

   “PERMIT_KEY 039e4b768b2c8280501fb7b5c56992088b704fb3ef8fd0efced6204ec975d1382f” \

   “DENY_KEY *”

$ sawtooth identity policy list

In the above example, two public keys are permitted and everyone else is denied; For the public key, use a 64 hex character public key from a .pub file.

Off-chain settings, which apply only to a single Sawtooth node, are kept by default in directory /etc/sawtooth/policy/ . For example, file /etc/sawtooth/policy/dans_policy1 may contain

 

PERMIT_KEY 02a1035d8a6277adf5b92e8f831f647235224fe4dc8660f8bcddf85707156307b5

PERMIT_KEY 039e4b768b2c8280501fb7b5c56992088b704fb3ef8fd0efced6204ec975d1382f

DENY_KEY *

Once we establish policies, we can now set roles to specific policies. For example, if we want to use dans_policy1 above to guide who can submit intkey transactions, set the following on-chain role:


$ sawtooth identity role create transactor.transaction_signer.intkey dans_policy1


Or, if we prefer an off-chain role setting, which applies only to the local node, we can add something like the following to file validator.toml :

 

[permissions]

“transactor.transaction_signer.intkey” = “dans_policy1”

 

Note that the key is in quotes, as required by TOML format for dotted keys.

On-chain permissioning is checked with batch submissions from a client and when publishing or validating a block. Off-chain permissioning applies only to batch submissions from a client—not transactions from peer nodes. The latter prevents unnecessary blockchain forks from different permissioning among nodes.

Transaction Key Permissions

Transaction key permissioning controls what clients can submit transactions, based on the signing public key. The relevant permissioning roles are:

  • transactor.transaction_signer.<name of TF> controls what clients can sign transactions for a particular Transaction Family (TF). For example, transactor.transaction_signer.intkey controls what clients can sign intkey TF transactions
  • transactor.transaction_signer controls what clients can sign transactions for any Transaction Family (TF)
  • transactor.batch_signer controls what clients can sign batches (groups of transactions that must be processed atomically—all or none)
  • transactor controls what clients can sign transactions or batches

The most specific role takes precedence over a more general role (for example, for batches, transactor.batch_signer is checked first and transactor is checked only if no rule was found in transactor.batch_signer . By default, anyone can sign a transaction or batch.

Challenge-Response Authorization

When a Sawtooth validator node receives a connection request, it has two authorization modes for the other node—Trust Authorization and Challenge Authorization.

For Trust Authorization, a node trusts connections from other nodes. It checks the public key for role authorizations. This is intended mainly for development and is the default value.

For Challenge Authorization, a connecting node must prove who they are. On a connection request, a node sends a challenge response containing a random nonce. The other node signs the nonce and sends it back to prove they are who they say they are. The node verifies the signed nonce is the same one as it sent, to guard against replay attacks.

To set authorization type, use
$ sawtooth-validator –network-auth {trust|challenge}
on the command line or set network = “trust” or network = “challenge” in configuration file validator.toml .

Sawtooth Encryption

Encryption in Sawtooth is used for

  • Digests for transactions, batches, and blocks
  • Signing transaction and batch headers by the client and blocks by the validator
  • Encrypting data in transit—either between peer nodes or between a components within a node

Sawtooth Transaction and Batch Signing

A Sawtooth node receives transactions from a client in the form of a batch list. A batch list contains one or more batches. A batch contains one or more transactions that must be processed, in order, as one atomic unit. For example, here’s a batch list with two batches containing two transactions and one transaction, respectively:

 

The client creating a transaction calculates the SHA-512 digest and sets it in the transaction header. The digest ensures the payload data in transactions cannot be altered without detection. Each transaction header contains a client-generated nonce value. The nonce makes every transaction unique and prevents anyone from replaying the transaction. The client signs the transaction header and includes the signing public key in the transaction header. The client then signs each batch and includes the batch signer public key in the batch header. The batch signer and transaction signer are usually, but do not have to be, the same. The public key of the batch signer is also in the transaction header to prevent repackaging of the transaction in another batch. The transaction and batch signer public keys in the transaction and batch header, respectively, allows anyone to identify the signers and to verify the signatures.

All Sawtooth signatures, including client-signed transactions and batches, use ECDSA curve secp256k1. This is the same algorithm and curve used by Bitcoin and Ethereum and allows for signature compatibility with these platforms. The 64-byte signature is the concatenation of the “raw” (unencoded) R and S values of a standard ECDSA signature.

Sawtooth Block Signing and Validation

The Sawtooth validator node creates proposed blocks from transactions it receives. These proposed blocks are signed by the validator and transmitted to the peer nodes on the Sawtooth network. The validator node signs blocks with ECDSA curve secp256k1, the same algorithm used for transaction and batch signatures. The peer nodes’ Validator validates candidate blocks proposed by a node, including verifying the block, batch, and transaction signatures. The digests and signatures not only prevent altering the payload data, but also prevents deleting, reordering, or duplicating transactions within a block or blocks within a blockchain.

Sawtooth Communication Encryption

Sawtooth encrypts data-in-motion —that is, communications between Sawtooth nodes and between components within a sawtooth node (such as between Validator, REST API, and Transaction Processor node processes). Sawtooth uses ZeroMQ (ZMQ or 0MQ) for communications. ZMQ encryption and authentication is implemented with CurveZMQ, which uses a 256-bit ECC key with elliptical curve Curve25519.

Transaction Input/Output lists

All Sawtooth transactions (ledger entries) have a list of input addresses and output addresses in the transaction header. These are optional but highly recommended for two reasons:

  • It allows transactions that do not conflict to be processed in parallel
  • It provides a measure of security by restricting the transaction processor from modifying addresses in state that are not listed in the transaction header.

Observability

Observability is the ability to see what the software is doing. This is important not only for debugging code, but for security analysis. One can see during a breach, or with post-mortem forensics, exactly what went wrong. Sawtooth is observable in that its components log time-stamped entries at various verbosity levels. The -v flag means log warning messages, –vv means log information and warning messages, and –vvv means log debug, info, and warning messages.

Additionally, Sawtooth has event subscriptions. The Sawtooth Events API allows an application to subscribe to “block-commit” events (triggered when a block is committed) and “state-delta” events (triggered when data in the blockchain state changes). Events are extensible in that application-defined events may be created and subscribed to by an application. An event handler could look for anomalies (such as too-frequent or over-limit transactions) and take further action to block or warn on these events.

Internal Security Mechanisms

Some security mechanisms are “under the hood” and are not always visible, but they are still important to mention:

Conclusion

This concludes part two of my blog on Hyperledger Sawtooth Security, where I discussed Sawtooth node and transaction processor security. This provides a toolbox to tighten down Sawtooth nodes as your needs require—tightening allowed transaction signers, transaction families, and peer nodes. I also discussed other security mechanisms including node authorization, encryption, observability, and internal security processes. Part three will conclude this series with a discussion on Sawtooth client application security and network security.

 

Bitagora: A Decentralized Voting Platform Built on Hyperledger Sawtooth

By | Blog, 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

Hyperledger Fabric & Sawtooth Certification Exams Coming Soon!

By | Blog, Hyperledger Fabric, Hyperledger Sawtooth

We strongly believe in helping organizations and developers overcome obstacles to blockchain adoption by investing in training and certification courses for Hyperledger. That’s why we’re thrilled to announce that Certified Hyperledger Fabric Administrator and Certified Hyperledger Sawtooth Administrator exams will be released later this year!

Below is more information on the certification exams:

Certified Hyperledger Fabric Administrator

The Certified Hyperledger Fabric Administrator (CHFA) can effectively build a secure Hyperledger Fabric network for commercial deployment. To pass the exam, professionals must demonstrate the ability to install, configure, operate, manage, and troubleshoot the nodes on that network. Completion of LFD271 may help serve as preparation for the CHFA exam, but is not required.

Exam sections will include:

  • Application Lifecycle Management
  • Installing and Configuring the Network
  • Diagnostics and Troubleshooting
  • Membership Service Provision
  • Network Maintenance and Operations

View the full list of domains and competencies for CHFA.

Certified Hyperledger Sawtooth Administrator

The Certified Hyperledger Sawtooth Administrator (CHSA) can effectively build a secure Hyperledger Sawtooth network for commercial deployment. To pass the exam, professionals must demonstrate the ability to install, configure, operate, manage, and troubleshoot the nodes on that network.

Exam sections will include:

  • Installation
  • Configuration
  • Permissioning, Identity Management & Security
  • Lifecycle
  • Troubleshooting

View the full list of domains and competencies for CHSA.

The certification exams were made possible thanks to generous help from the community. Specifically, we’d like to call out and thank the participating individuals for the time they contributed to shape the content for these certifications:

Hyperledger Fabric

  • David Gorman, IBM
  • Dinesh Kumar, Oracle
  • Ernesto Lee, Blockchain Training Alliance
  • Greg Skerry, Altoros
  • Manu Varghese, Greenstream Technology
  • Yaoguo Jiang, Huawei
  • Naresh Thumma and Bhasker Nallapothula, Biarca
  • Ry Jones, Hyperledger,
  • Liz Kline, The Linux Foundation
  • Clyde Seepersad, The Linux Foundation
  • Toki Winter, The Linux Foundation

Hyperledger Sawtooth

  • Dan Middleton, Intel
  • Tom Barnes, Intel
  • Richard Berg, Bitwise IO
  • Ryan Beck-Buysse, Bitwise IO
  • Val Reid, PokitDok
  • Anthony Adkins, PokitDok
  • Gregory Skerry, Altoros
  • Neeraj Srivastava, DLT Labs
  • Jovan Maric, DLT Labs
  • Chris Spanton, T-Mobile
  • Ernesto Lee, Blockchain Training Alliance
  • Tracy Kuhrt, Hyperledger
  • Ry Jones, Hyperledger
  • Wallace Judd, Authentic Testing
  • Toki Winter, The Linux Foundation
  • Liz Kline, The Linux Foundation

Both the CHFA and CHSA exams will be available to take before the end of the year. As with all Linux Foundation certification exams, the exams are completed remotely from virtually any location with a stable internet connection and webcam. Those who fail to pass the exam on their first attempt can retake the exam one additional time at no cost.

But the certifications are not the only thing to be excited about – you can now enroll in a new LFD271 – Hyperledger Fabric Fundamentals training course, which was also announced by The Linux Foundation today. LFD271 is designed for developers. They will learn how business logic is implemented in Hyperledger Fabric through chaincode (Hyperledger Fabric’s smart contracts) and review the various transaction types used to read from and write to the distributed ledger.

The LFD271 course instructor, Jonathan Levi is the founder of HACERA, and one of the early contributors to Hyperledger Fabric. He helped shape the Membership Services (the permissioning layer of Hyperledger Fabric) and was the official release manager of Hyperledger Fabric 1.0. He has built several large-scale mission critical systems that had to be highly available, secure and fault-tolerant.

Be on the lookout for these certifications as well as a beta tester program where we will invite members of the community to take the exams. If someone completes the beta exam with a passing grade, they will become one of the first Certified Hyperledger Fabric or Sawtooth Administrators upon launch of the program.

We hope you join us in contributing to Hyperledger projects. As always, you can keep up with what’s new with Hyperledger on Twitter or email us with any questions: info@hyperledger.org.

From XOs to Crypto Assets

By | Blog, Hyperledger Sawtooth

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.

 

Hyperledger Sawtooth, Seth and Truffle 101

By | Blog, Hyperledger Burrow, Hyperledger Sawtooth

Guest post: Nathan Aw

I develop on both Hyperledger Fabric/Sawtooth and Ethereum (to be specified, Quorum) so I am familiar with the languages available on both platform — chaincode (Go) and smart contract (Solidity). Often I am asked this question: “Which platform is better?” To which I will answer, this question is a false choice as with Hyperledger Sawtooth Seth, you can build your smart contracts in Solidity and deploy the same smart contract in Hyperledger Sawtooth — Pretty cool isn’t it? 😉

Before we get to the technical section, we need to get a handle on the basic terminology first.

What is Hyperledger Sawtooth?

Hyperledger Sawtooth is an enterprise blockchain platform for building distributed ledger applications and networks. The design philosophy targets keeping ledgers distributed and making smart contracts safe, particularly for enterprise use.

Sawtooth simplifies blockchain application development by separating the core system from the application domain. Application developers can specify the business rules appropriate for their application, using the language of their choice, without needing to know the underlying design of the core system.

Sawtooth is also highly modular. This modularity enables enterprises and consortia to make policy decisions that they are best equipped to make. Sawtooth’s core design allows applications to choose the transaction rules, permissioning, and consensus algorithms that support their unique business needs.

What is Hyperledger Sawtooth Seth?

The primary goal of the Sawtooth-Ethereum integration project, which is also known as “Seth” is to add support for running Ethereum Virtual Machine Smart Contracts to the Hyperledger Sawtooth Platform.

Ethereum Virtual Machine (EVM) Smart Contracts can be deployed to Sawtooth using the Seth Transaction family. The Seth Transaction Family enables the creation and execution of smart contracts. It integrates the Hyperledger Burrow implementation of the EVM into the Hyperledger Sawtooth Framework using the Sawtooth Transaction Processor SDK.

For those familiar with Ethereum Geth (Go-Ethereum) client, you will find out that Sawtooth Seth client replicates the Ethereum JSON RPC API.

Seth is composed of three components

  1. Seth Client
  2. Seth-TP Transaction Processor
  3. Seth-RPC Server

For more details on JSON RPC API, check out https://github.com/ethereum/wiki/wiki/JSON-RPC

Do note that Seth is not a complete Ethereum implementation. The Sawtooth platform has made fundamental design decisions that differ from those made by the Ethereum platform. The specified differences can be found under Sources/References

What is Truffle?

Truffle is often considered the most popular Ethereum development framework. Truffle does a lot of things for the developer. It is a development environment, testing framework and asset pipeline for Ethereum, aiming to make life as an Ethereum developer easier. We won’t be going through Truffle. Point of introducing Truffle is to share with you that one can build smart contracts with Solidity and enjoy Truffle and its related capabilities and yet deploy the end product (i.e., your Smart Contract) onto Hyperledger Sawtooth — this to me is pretty awesome! For more information on truffle, please check out https://truffleframework.com/

Step by Step Setup Guide

I am using Ubuntu 16.04. You will need git and Docker installed.  

  1. Do a git clone of sawtooth-seth

2. Build the Sawtooth Seth

This process will take 10 – 15 minutes.

  1. Run Sawtooth Seth

docker run -v $(pwd)/docs:/project/sawtooth-seth/docs seth-build-docs

  1. Verify if the components are running correctly  

curl http://0.0.0.0:8080/blocks

curl http://0.0.0.0:3030 -d ‘{“jsonrpc”: “2.0”, “id”: 1, “method”: “eth_blockNumber”}’ -H “Content-Type: application/json”

  1. Creating an Account. Generating a Key Pair

In order to interact with Seth, we need to create an external account on the network. Creating an account is equivalent to generating a new private key that Seth can understand. Seth accepts secp256k1 private keys

docker exec -it seth bash

openssl ecparam -genkey -name secp256k1 | openssl ec -out mykey.pem -aes128

Now we are ready to set up the account on the network. To do this, we need to use the seth command. From the prompt where you generated the key, run:

seth account import mykey.pem myalias

seth account create myalias –wait

seth show account {address}

  1. Write the Smart Contract

Once you have an account created, you can use it to deploy EVM smart contracts. To demonstrate how to deploy and call contracts, we will be using the following Solidity contract, which is based loosely on the IntegerKey Transaction Family. Solidity is a high-level language for defining contracts that compiles to EVM byte code for deployment. To follow along with this guide, you should create a new file with this contract:

pragma solidity ^0.4.0;

contract intkey {

 mapping (uint => uint) intmap;

 event Set(uint key, uint value);

function set(uint key, uint value) {

   intmap[key] = value;

   Set(key, value);

 }

 function inc(uint key){

   intmap[key] = intmap[key] + 1;

 }

 function dec(uint key){

   intmap[key] = intmap[key] – 1;

 }

 function get(uint key) constant returns (uint retVal) {

   return intmap[key];

 }

}

Save this contract in a file called “contract.sol” in your working directory. If you are working with the development environment described in :doc`./getting_started` you should save this file in the sawtooth-core/ directory on your host so that it is available within the seth container.

Before we can deploy this contract, we have to compile it. The seth client expects that the contract will be passed as a hex-encoded byte array. We can use the Solidity compiler solc to create it. If you followed the Getting Started instructions, this tool is already installed in the seth container we created earlier. Connect to the seth container as explained there. If not, we assume you have it installed locally.

$ solc –bin contract.sol

======= contract.sol:intkey =======

Binary:

…byte array here…

In place of {contract} you should insert the blob of hex that you saved from earlier. This will create a new contract creation transaction and submit it to the validator.

If everything works, a new contract account will be created and the client will print the address of the newly created contract account along with some additional execution information. To confirm the contract was deployed, you can run:

seth show account {address}

  1. Calling Contracts

To call the deployed contract we need the address where the contract is deployed and the input data for the contract call. The address was printed when the contract was deployed. Constructing the input for the contract is a little harder.

Solidity uses an Application Binary Interface or ABI to determine which function in your contract to run and what the function call’s arguments are. There are many tools available for abstracting the creation of the input data for a contract call. One option for generating the input data that is compatible with the seth client is the ethereumjs-abi library. If you are using the development environment described earlier, this is already installed in the seth docker container.

To use this library to call a function in contract, you can use the simpleEncode. The following shows how to call the set() function in the contract we deployed earlier with arguments 19 and 42:

$ node

> var abi = require(‘ethereumjs-abi’)

> abi.simpleEncode(“set(uint,uint)”, “0x13”, “0x2a”).toString(“hex”)

…byte array here…

To call our contract and run set(19,42), run:

seth contract call –wait {address} {input}

In place of {input} you should insert the blob of hex formatted according to the contract’s ABI that we created above. If everything works, the client will state that transaction was succesful and print the transaction id. To verify that the message call was successful, you can do:

seth show receipt {transaction-id}

seth contract create –wait myalias {contract}

Conclusion

Imagine having the best of both worlds — building smart contracts with Solidity, originally intended for EVM — and deploying it onto Hyperledger Sawtooth. Portability is the key differentiator here which explains why I love building smart contracts with Solidity and deploying it onto Sawtooth via Seth.  

I am happy to answer any questions you might have on Hyperledger Sawtooth and Solidity or any blockchain related questions. Drop me a line at nathan.mk.aw@gmail.com and/or connect with me on Linkedin at https://www.linkedin.com/in/awnathan/

Sources/References:

https://github.com/hyperledger/sawtooth-seth/blob/master/docs/Dockerfile

https://sawtooth.hyperledger.org/docs/seth/releases/latest/seth_developers_guide/getting_started.html#getting-seth

https://sawtooth.hyperledger.org/docs/core/releases/latest/introduction.html

https://github.com/trufflesuite/truffle