All Posts By

Logan Seeley, Bitwise IO

Sawtooth PBFT, Part 2: Extensions and Changes

By | Blog, Hyperledger Sawtooth

The upcoming release of Hyperledger Sawtooth 1.2 includes Sawtooth PBFT—a new, Cargill-sponsored, production-ready consensus algorithm. Sawtooth PBFT is much more than a basic implementation of the PBFT consensus algorithm that was originally defined in 1999. Sawtooth PBFT has all the core features of the original definition—it provides the same safety and liveness guarantees—but we have adapted the algorithm to take advantage of features unique to blockchains, and extended it to provide more flexibility and robust guarantees.

In two earlier blog posts, Making Dynamic Consensus More Dynamic and Introduction to Sawtooth PBFT, we introduced Sawtooth’s dynamic consensus interface and explained how the PBFT consensus algorithm works from a high level. In this post, I’ll describe the adaptations and enhancements that helped us bring a robust PBFT consensus algorithm to Hyperledger Sawtooth:

  • Sequence number simplications (no more watermarks)
  • An idle timeout to guarantee more liveness
  • Regular view changes for fairness
  • A consensus seal as proof of commit
  • No checkpoints for garbage collection
  • A catch-up procedure for slow and new nodes
  • Membership changes

Sequence Number == Block Number

In traditional PBFT, the primary node assigns a sequence number for each request when it broadcasts a pre-prepare message for the request. In Sawtooth PBFT, the “requests” are actually blocks that are created by a Sawtooth validator. Blocks in Sawtooth are ordered; we can take advantage of this ordering to simplify the sequence numbering in PBFT. Instead of assigning a sequence number for each block, the primary node will just use the block number as the sequence number.

This simplification makes the algorithm easier to understand. It also means that secondary nodes don’t need to check that the primary node picks reasonable sequence numbers. Originally, nodes would have to make sure that the sequence number was between a low and high watermark, in case the primary node picked a number that was so high that it exhausted all of the possible sequence numbers. Now that the sequence number is automatically determined by the block number, a secondary node only needs to check the pre-prepare message to make sure that the sequence number matches the block number of the block in the message. It’s as simple as that!

More Liveness with an Idle Timeout

One liveness problem that traditional PBFT does not solve is the “silent leader” problem. The leader is responsible for building and sharing blocks with the rest of the network to start a new round of consensus. Even if transactions are being submitted to the network, the leader could stay silent by never sharing a block with the network; this “silent leadership” would allow the leader to halt progress indefinitely.

To solve this problem, we implemented an idle timeout as a new way to trigger a view change. After a block is committed, each node starts its idle timer. The primary node must publish the next block and broadcast a pre-prepare message for the block before the timer expires. Otherwise, a secondary node will initiate a view change.

The idle timeout provides more robust liveness by ensuring that a faulty primary node can’t stall the network indefinitely. This timeout can lead to unnecessary view changes, though; if the network really is idle (no transactions are being submitted), then the primary node isn’t faulty when it doesn’t publish a block, since the Sawtooth validator does not publish a block when there are no transactions. The cost of these extra view changes is negligible, however; when the network is idle, a view change will not hinder the performance of the network.

Pseudo-Fairness with Regular View Changes

Determining if a leader is acting fairly is a very complex and challenging problem; there is still a lot of research being done to solve it.

To get us a step closer to fairness, we introduced a regular view change mechanism to Sawtooth PBFT. This mechanism is fairly simple: after every nth block is committed, the network will “force” a view change by incrementing its view by one. The number of blocks between forced view changes is called the forced view change interval, which is a configurable setting.

Regular view changes reduce unfairness by not allowing any node to control block publishing for too long; instead, every node gets a chance to be the leader for a period of time. While this doesn’t completely solve the fairness problem, it limits unfairness in a way similar to Tendermint and lottery-style consensus algorithms. This solution is also inexpensive: since the view change is “forced” (the view number is directly incremented) at a consistent point across the network, we don’t need the expensive view changing procedure.

Consensus Seal

The original PBFT algorithm does not define a reliable way to check if a block was committed validly (that is, when 2f + 1 nodes agreed to commit the block). The only way to check this would be to request each node’s commit messages and count them. The problem with this approach is that old messages might be unavailable if the messages were removed (garbage collected) or if a node is no longer part of the network.

To overcome this limitation, we implemented a consensus seal for each block that is committed. The consensus seal is a signed data structure that contains a block ID and 2f signed commit messages for that block ID. This seal proves that the network agreed to commit the block and that the block was committed validly.

The seal is stored on the blockchain itself, which means that the seal is immutable and can be checked at a later point. A seal can’t be inserted directly into the block that the seal is for, however, due to the way blocks are constructed by the Sawtooth validator. Instead, the seal is added to the next block that is committed to the blockchain; thus, each block contains the consensus seal for the previous block. This approach has a limitation—the most recently committed block can’t be validated using a consensus seal, since there isn’t a subsequent block yet. However, all previous blocks in the chain can be validated to ensure that they were committed validly, which is a useful guarantee.

Catching Up

In the real world, distributed networks face failures, segmentations, dropped messages, and many other hiccups. When these issues arise, nodes may fall behind, so they need a way to catch up to the rest of the network.

Sawtooth PBFT uses a special catch-up procedure that takes advantage of the consensus seal extension. The catch-up procedure is best illustrated by an example.

Let’s say the network as a whole has committed block 100, but a node has fallen behind and has only committed blocks up to block 90. When the slow node eventually gets block 91, it waits for a pre-prepare message from the primary node. Because the network has already moved past this block, though, the node never gets this old pre-prepare message. Instead, the slow node gets block 92, which contains a consensus seal for block 91. The node examines the seal from block 92 to make sure it’s valid, then commits block 91. Our node knows that it can skip the usual consensus procedure because the consensus seal in block 92 proves that the network agreed to commit block 91.

The node follows this procedure until it commits block 99. At this point, it needs to do something different. Because there is no block 101 yet, the node doesn’t have a seal for block 100. So the node broadcasts a request to the rest of the network for a consensus seal for block 100. If another node has already committed block 100, that node builds the seal and sends it directly to the node that requested it. When the node receives the seal, it will verify the seal and commit block 100. The node that fell behind is now up to date!

Who Needs Checkpoints?

As originally defined, PBFT uses a checkpoint procedure to perform garbage collection for each node’s log of consensus messages. In this procedure, the nodes exchange messages to come to consensus on the current version of state. When the nodes have agreed on the current state, they save these messages as proof of the agreement, then discard all previous consensus messages.

Sawtooth PBFT does not need this checkpoint procedure. Because each block contains a consensus seal that provides proof of the validity of the previous block, and each block is immutable and permanent by nature of a blockchain, every block contains a checkpoint that will be kept forever. This means that the nodes can clean up old log messages any time they wish, while the state can still be verified using the consensus seal.

Membership Changes

Another fact of the real world is that network membership can change. This happens for a variety of reasons: a node may need to be replaced or a new company might want to join a consortium’s network. The original PBFT algorithm does not define a procedure to change membership of a PBFT network, so we implemented our own.

In Sawtooth PBFT, membership in the network is determined by an on-chain Sawtooth setting, sawtooth.consensus.pbft.members, which is a list of the public keys of all nodes in the network. Since this list is on the blockchain itself, it’s shared and agreed on by the whole network, which makes changing membership easy.

An administrator can update the on-chain setting to add, remove, and reorder nodes by submitting the change as a transaction. Each time a block gets committed, all PBFT nodes check this setting to see if it changed because of a transaction in that block, then update their local state if necessary.

Like forced view changes, a membership change is done at a consistent point across the network: when a block is committed. This consistency makes the local view of membership on each node easy to update in an atomic way. This approach to membership also makes it easy to check the historical membership throughout the life of a Sawtooth blockchain managed by PBFT consensus.

Summary

Sawtooth PBFT has a lot to offer. It not only includes all the functionality you would expect from PBFT, but it adds features and optimizations for real-world use. We’ve developed new solutions to overcome limitations of traditional PBFT. Plus, we’ve been able to take advantage of the properties of a blockchain, such as immutability and ordering, to make the algorithm more efficient and robust.

Want to Learn More?

These features are all new to PBFT, and some of the implementations are unique among published consensus algorithms. If you’re interested in learning more about our PBFT extensions, read the regular view changes RFC, consensus seal RFC, and PBFT catch up RFC. Also, check out the Sawtooth PBFT documentation and source code on GitHub.

Do you have questions? Do you have comments or concerns about how the extensions work? Let us know in the #sawtooth-consensus-dev channel on Hyperledger Chat!

Stay tuned for more news and info about the upcoming Sawtooth PBFT 1.0 release.


About the Author

Logan Seeley is a Software Engineer at Bitwise IO. He has been a part of the Hyperledger Sawtooth community since May 2018,


Making Dynamic Consensus More Dynamic

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

(6.26.18) Enterprisers Project: How to explain blockchain in plain English

By | News

For all of the hype around blockchain, most businesses are barely tinkering with it right now – if they’re doing anything at all. A recent Gartner survey of CIOs found that 43 percent of respondents said blockchain was on their radar but they had no concrete plans in the works, while 34 percent said they simply weren’t interested. A scant one percent of CIOs reported any kind of blockchain adoption in their organization.

More here.

(1.30.17) Cyptocoinsews.com: American Express Wants “Full Advantage of Blockchain”, Joins Open-Source Hyperledger Project

By | Finance, News

Credit card giant American Express has joined the Linux Foundation-led open-source cross-industry blockchain working group, the Hyperledger Project.

In yet another noted example of the traditional financial services industry turning to Fintech’s poster child in blockchain technology, American Express has joined the Hyperledger Project as a ‘Premier’ member.

More here.

Hyperledger Wraps up 2016 By Welcoming Eight New Members

By | Announcements

Diverse set of new members joins fastest growing open blockchain initiative

SAN FRANCISCO, CA – (December 28, 2016) – Hyperledger Project, a collaborative cross-industry effort created to advance blockchain technology, announced today that eight new members have joined the project to help create an open standard for distributed ledgers for a new generation of transactional applications. Last month, Hyperledger announced it reached 100 active members in less than one year, a huge milestone for the open source project, hosted by The Linux Foundation.

“This year has been full of growth for the project,” said Brian Behlendorf, Executive Director, Hyperledger. “Not only did we exceed 100 members, Hyperledger met significant development milestones thanks to the community’s hard work. As 2016 was a year of exploration, R&D and prototyping, we’re excited for 2017 to be the year we start to see case studies of the technology in production environments.”

Hyperledger aims to enable organizations to build robust, industry-specific applications, platforms and hardware systems to support their individual business transactions by creating an enterprise grade, open source distributed ledger framework and code base. The latest members include: CA Technologies, Factom Foundation, Hashed Health, Koscom, LedgerDomain, Lykke, Sovrin Foundation and Swisscom.

New Member Quotes:

CA Technologies

“To compete today, every company needs to foster innovation that delivers real business value. Blockchain has the potential to disrupt the way many of CA’s customers do business,” said Otto Berkes, chief technology officer, CA Technologies. “We’re honored to be a part of Hyperledger and look forward to collaborating with other members to help shape open standards for blockchain. It’s an exciting time for this because blockchain is not just about Bitcoin anymore, and the range of potential applications with it is vast for of our customers. This partnership will help us influence what that future looks like for both CA and our customers as they embark on their digital transformation journey.”

Factom Foundation

“We are honored to have been selected to join the Hyperledger Project,” said Paul Snow, Founder, Factom Foundation. “We are looking forward to helping build the open source framework for securing data and systems with our blockchain solution.”

Hashed Health

“Hashed Health is a healthcare technology innovation company focused on accelerating the commercialization of meaningful new blockchain and distributed ledger-based technologies,” said John Bass, Hashed Health CEO. “Hashed is proud to be a member of the Hyperledger Project, sharing its commitment to creating the foundation for scalable, reliable blockchain solutions.”

Koscom

“We consider blockchain technology as the next generation infrastructure in the Korean capital market. As an industry leader with 40 years’ experience in the financial IT field, we are looking to leverage this industry disruptive technology,” said Chung Youn Dae, CEO, Koscom. “We will constantly explore the ways to contribute to the blockchain ecosystem, as we collaborate with the Hyperledger community. We also hope to better serve out customers in a more secure and efficient way by integrating blockchain technology and our own Fintech platform.”

LedgerDomain

“LedgerDomain delivers next generation supply chain solutions, harnessing permissioned blockchains to assure supply chain integrity and finished product authenticity through to the consumer for the benefit of all. This highly transparent, trustworthy approach is built upon an industrial-strength Hyperledger Fabric backbone,” said Dr. Victor Dods, LedgerDomain. “We’re proud to be a part of Hyperledger and its growing community.”

Lykke

“We’re looking forward to being part of the Hyperledger project,” said Richard Olsen, Lykke founder and CEO. “Our company is building a digital asset exchange. Right now, we’re implemented on the Bitcoin blockchain settlement layer, with Ethereum to come within the next few months, but our involvement with Hyperledger isn’t just the next step forward. Providing decentralized settlement on the Hyperledger blockchain with multisignature wallets and atomic swap transactions will benefit both of our user communities.”

Swisscom

“We are very proud to be Switzerland’s first connection to Hyperledger,” said Johannes Höhener, VP, Swisscom’s Fintech Cluster. “We look forward to working with a highly professional community on cutting-edge blockchain developments. Our membership and participation will shape our capabilities to develop blockchain solutions – for our clients and Switzerland.”

The success of Hyperledger is due to the support of the developer community and member companies. Learn how your organization can contribute to the project here: https://www.hyperledger.org/about/join

About Hyperledger

The Hyperledger project is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration including leaders in finance, banking, Internet of Things, supply chains, manufacturing and Technology. The Linux Foundation hosts Hyperledger as a Collaborative Project under the foundation. To learn more, visit: www.hyperledger.org

Hyperledger Welcomes Iroha

By | 网志, Hyperledger Iroha

iroha_3

We’re pleased to announce that the distributed ledger project, Iroha, has been accepted into incubation status under Hyperledger. Originally developed by Hyperledger member company, Soramitsu, Iroha was inspired by the Fabric architecture and aims to provide a development environment where C++, web, and mobile application developers can contribute to the Hyperledger Project.

What is Iroha?

Iroha seeks to complement Fabric, Sawtooth Lake, and other potential projects, by creating reusable components in C++ that can be called from languages such as Go. In this way, Iroha is additive to existing projects and the long term goal is to realize a robust library of reusable components that can be selected and used freely by those running distributed ledgers on Hyperledger technology.

“Iroha allows even more developers to interact with Hyperledger to build infrastructural projects and applications requiring distributed ledger technology,” said Brian Behlendorf, Executive Director of Hyperledger. “It is encouraging to see member companies actively contributing to a diverse and sustainable open source blockchain ecosystem built on cooperation.”

The design and architecture of Iroha is greatly inspired by Fabric, in that blockchain and chaincode services form the overall architecture. Where possible, APIs were made to be similar to Fabric and, rather than competing with Fabric, the goals of Iroha are to:

  1. Provide an environment for C++ developers to contribute to Hyperledger
  2. Provide infrastructure for mobile and web application support
  3. Provide a framework to experiment with new APIs and consensus algorithms that could potentially be incorporated into Fabric in the future.

Why Iroha?

Currently, the Hyperledger Project lacks an infrastructure project written in C++, thus limiting the potential developers who can contribute. Also, there is not currently a strong focus on user interaction or mobile applications, though both are necessary for the realization of the widespread use of distributed ledger technology. Iroha aims to rectify both of these points, bringing in more developers while providing libraries for mobile user interface development.

Iroha is a distributed ledger project that was designed to be simple and easy to incorporate into infrastructural projects requiring distributed ledger technology. Iroha features:

  1. Simple construction
  2. Modern, domain-driven C++ design
  3. Emphasis on mobile application development
  4. New, chain-based Byzantine fault tolerant consensus algorithm, called Sumeragi

Although turing complete smart contracts are available via chaincode in Java (running a sandboxed JVM), users do not need to write chaincode in order to define digital assets in Iroha. Common use cases, such as deploying new currencies and sending text messages, are available as part of the core framework. Iroha is composed of the following:

  • Iroha core
  • Iroha Native iOS Library
  • Iroha JavaScript Library
  • Iroha Native Android Library

Iroha core provides the distributed ledger infrastructure comprising the data membership services, consensus algorithm, peer-to-peer network transmission, data validation, and chaincode infrastructure. The iOS, Android, and JavaScript libraries provide convenience functions for performing common operations, such as digitally signing transactions. Future work will expand these common functions to interoperate with the Fabric ledger.

Who will work on Iroha?

Soramitsu has committed several full time engineers to the project. Makoto Takemiya of Soramitsu is the initial project maintainer, along with six other engineers at Soramitsu. Besides Soramitsu, the co-sponsors of the proposal and other Hyperledger members are considering committing resources to work on Iroha including Toshiya Cho of Hitachi, Takahiro Inaba of NTT Data, and Mark Smargon of Colu.

Soramitsu is also doing collaborative research with The University of Tokyo, The University of Aizu, and Center for Global Communications (GLOCOM, below) of International University of Japan. From the University of Tokyo, Hideyuki Tanaka will consider economics use cases with Iroha. From The University of Aizu, Yasushi Fujii will explore business use cases with Iroha. From GLOCOM, Soichiro Takagi will consider economics and scientific research using Iroha.

“We’re pleased that Iroha has been accepted for incubation into  Hyperledger,” said Makoto Takemiya at Soramitsu. “By creating C++, mobile, and web development environments for Hyperledger, new developers can join the project and help contribute not only to Iroha, but to other sub projects, such as Fabric and Sawtooth Lake.”

Learn more about Iroha

Working with community members and use case partners, we would like to continue to improve upon Iroha and have it reach and active project stage in the future. The end goal is to realize a suite of components that can be freely interoperable with other Hyperledger projects.

The following repositories on github have been created to manage Iroha resources:

  • https://github.com/hyperledger/iroha
  • https://github.com/hyperledger/iroha-ios
  • https://github.com/hyperledger/iroha-android
  • https://github.com/hyperledger/iroha-javascript

You can learn more about Iroha in this whitepaper or other incubation projects under Hyperledger here. Iroha documentation can be found at http://docs.iroha.tech. For those interested in additional information, please reach out to: info@hyperledger.org