Category

Hyperledger Sawtooth

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 | 网志, 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 | 网志, 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 | 网志, 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 | 网志, 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 | 网志, 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 

(7.3.18) Forbes: Big Blockchain: The 50 Largest Public Companies Exploring Blockchain

By | Hyperledger Fabric, Hyperledger Sawtooth, News

There’s more than one way to gain exposure to blockchain innovation. Beyond buying over-the-counter products or investing directly in blockchain startups some of the largest public companies in the world are already dabbling in the tech. In fact, a closer look at this year’s Forbes Global 2000 list of the largest public companies in the world reveals that not only are all ten of the largest public companies in the world exploring blockchain, but at least 50 of the biggest names on the list have all made their own mark on technology first inspired by bitcoin.

More here.

Developer Showcase Series: Zac Delventhal, Bitwise IO

By | 网志, Hyperledger Sawtooth

Image: Zac Delventhal, software engineer, Bitwise IO

Our Developer Showcase blog series returns! This time, we chatted with Zac Delventhal, a software engineer at Bitwise IO about his interest in blockchain and Hyperledger. A quick reminder that this blog series serves to highlight the work and motivations of developers, users and researchers collaborating on Hyperledger’s incubated projects. Let’s see what Zac had to say!

What advice would you offer other technologists or developers interested in getting started working on blockchain? 

The blockchain space is extremely young. The concept didn’t even exist a decade ago, and we’re only just starting to see stable platforms emerge. Most of us aren’t even exactly sure what blockchains will be used for yet. That’s profoundly exciting on one hand. The field is wide open for people to innovate.

But for a new learner it can be intimidating. There are no authoritative sources on the subject, and toolsets you learn today might be obsolete tomorrow. My best advice would be to start with some fundamentals about how a blockchain works, preferably from two or three sources. Then just dive in and build something on one of the platforms out there like Ethereum or Hyperledger Sawtooth. It will be a mess, but then you’ll have the foundation you need to build the next thing.

What project in Hyperledger are you working on? Any new developments to share? Can you sum up your experience with Hyperledger?

I am one of the maintainers on Hyperledger Sawtooth, working primarily on developer tools like the REST API and SDKs, as well as developing a number of distributed applications on the platform myself. It is actually a pretty exciting time for Sawtooth, as a 1.0 release was announced. The APIs are stable and now we just have a few technical issues to work out. As things have matured, it has allowed me personally to build much more sophisticated proof-of-concepts, so I am really excited to see what the community starts coming up with as we move into this new phase.

As Hyperledger’s incubated projects start maturing and hit 1.0s and beyond, what are the most interesting technologies, apps, or use cases coming out as a result from your perspective?

I am really curious to see what Pokitdok comes up with. They’re working on a distributed healthcare application that will let patients use the blockchain to give doctors and hospitals permission to view their medical records. This is exactly the sort of off-the-wall use I want to see more of as blockchains move past just being used for currency and other assets. There is so much potential to totally upend existing industries and give people more control over fundamental aspects of their lives.

What’s the one issue or problem you hope blockchain can solve?

There isn’t any particular problem I want to throw blockchains at, but I am excited by the potential for the technology to take power away from centralized authorities like big corporations and governments and give it back to individuals. Can we use a blockchain to give consumers more information about what’s in their food?

To give people more control over how their personal data is used by advertisers? Could we use a blockchain to circumvent censorship? I don’t foresee anything revolutionary on the immediate horizon, but as the technology matures the potential for it to be used in novel and disruptive ways is very exciting.

Where do you hope to see Hyperledger and/or blockchain in 5 years?

Established. I hope in five years there are a few major commercial applications built on Hyperledger, a host of Stack Overflow questions answered, and an O’Reilly book or two. I want the technology to be mature enough that junior developers can pick it up easily and play around with the possibilities. They’re the ones who are going to come up the really interesting stuff I would never have thought of.

What is the best piece of developer advice you’ve ever received?

git rebase -i

No. I don’t know. That’s such a tough question. I do use interactive rebases constantly, but I guess some advice that really stuck with me was when one of my mentors explained the difference between a Scribe and a Conjurer. The Scribe has to understand the intricacies of everything they are doing. They will pour over documentation, pull apart source code, and generally make sure they understand how their project works from end to end. The Conjurer on the other hand is clueless. They say some magic words they found on Google and a working application appears. They ask no more questions and move on with their lives.

The reason my mentor explained this concept was to talk me out of being a Scribe all the time. I’m very detail oriented, as I think a lot of engineers are, and I could probably spend weeks working out the absolute perfect way to solve any given problem. But time is precious. Being given permission to sometimes say “screw it, it works, move on” was very powerful for me.

(6.27.18) New York Times: A Guide to Travels in the Blockchain World

By | Hyperledger Fabric, Hyperledger Sawtooth, News

The original blockchain created by Bitcoin has inspired thousands of other attempts to record information in the distinctive fashion the cryptocurrency pioneered.

While there’s a hot debate about how to define a blockchain, most projects using the term try to create a single database that is shared and maintained by a group of people or institutions.

More here.