Today we are excited to announce our newest project, Hyperledger Transact. Transact represents the continued evolution at Hyperledger towards greater componentization to allow rapid responsible adoption of new blockchain technologies. Transact provides a platform-agnostic library for executing transactions with smart contracts. It allows us to more rapidly integrate a variety of smart contract technologies such as WebAssembly across the Hyperledger family of projects. Transact is informed from experiences and design in multiple Hyperledger frameworks including Hyperledger Sawtooth and Hyperledger Fabric.
Smart contracts are a fundamental building block of distributed ledgers. In distributed ledger frameworks, a transaction represents an intended change that is submitted by a user. Transactions are interpreted by smart contracts, which update the current state of the system as a result.
Existing solutions for smart contract execution are generally tied to a specific distributed ledger implementation, which limits the code’s reusability. Hyperledger Transact will reduce the development effort for distributed ledger solutions by providing a standard interface for executing smart contracts that is separate from the distributed ledger implementation.
What is Hyperledger Transact?
Hyperledger Transact makes writing distributed ledger software easier by providing a shared software library that handles the execution of smart contracts, including all aspects of scheduling, transaction dispatch, and state management.
Hyperledger framework-level projects and custom distributed ledgers can use Transact’s advanced transaction execution and state management to simplify the transaction execution code in their projects and to take advantage of Transact’s additional features.
More specifically, Transact provides an extensible approach to implementing new smart contract languages called “smart contract engines.” Each smart contract engine implements a virtual machine or interpreter that processes smart contracts. Examples include Seth, which processes Ethereum Virtual Machine (EVM) smart contracts, and Sabre, which handles WebAssembly smart contracts. Transact also provides SDKs for implementing smart contracts and smart contract engines, which makes it easy to write smart contract business logic in a variety of programming languages.
Hyperledger Transact is inspired by Hyperledger Sawtooth and uses architectural elements from Sawtooth’s current transaction execution platform, including the approach to scheduling, transaction isolation, and state management. Transact is further informed by requirements from Hyperledger Fabric to support different database backends and joint experiences between Sawtooth and Fabric for flexible models for execution adapters (e.g., lessons from integrating Hyperledger Burrow).
Diving Deeper
Transact is fundamentally a transaction processing system for state transitions. State data is generally stored in a Merkle-Radix tree, a key-value database, or an SQL database. Given an initial state and a transaction, Transact executes the transaction to produce a new state. These state transitions are considered “pure” because only the initial state and the transaction are used as input. (In contrast, other systems such as Ethereum combine state and block information to produce the new state.) As a result, Transact is agnostic about framework features other than transaction execution and state. Awesome, right?
Transact deliberately omits other features such as consensus, blocks, chaining, and peering. These features are the responsibility of the Hyperledger frameworks (such as Sawtooth and Fabric) and other distributed ledger implementations. The focus on smart contract execution means that Transact can be used for smart contract execution without conflicting with other platform-level architectural design elements.
At a high level, the Transact architecture looks like this:
Transact includes the following components:
- State. The Transact state implementation provides get, set, and delete operations against a database. For the Merkle-Radix tree state implementation, the tree structure is implemented on top of LMDB or an in-memory database.
- Context manager. In Transact, state reads and writes are scoped (sandboxed) to a specific “context” that contains a reference to a state ID (such as a Merkle-Radix state root hash) and one or more previous contexts. The context manager implements the context lifecycle and services the calls that read, write, and delete data from state.
- Scheduler. This component controls the order of transactions to be executed. Concrete implementations include a serial scheduler and a parallel scheduler. Parallel transaction execution is an important innovation for increasing network throughput.
- Executor. The Transact executor obtains transactions from the scheduler and executes them against a specific context. Execution is handled by sending the transaction to specific execution adapters (such as ZMQ or a static in-process adapter) which, in turn, send the transaction to a specific smart contract.
- Smart Contract Engines. These components provide the virtual machine implementations and interpreters that run the smart contracts. Examples of engines include WebAssembly, Ethereum Virtual Machine, Sawtooth Transactions Processors, and Fabric Chain Code.
Transact Features
Hyperledger Transact includes the following current and upcoming features (not a complete list):
- Transaction execution adapters that allow different mechanisms of execution. For example, Transact initially provides adapters that support both in-process and external transaction execution. The in-process adapter allows creation of a single (custom) process that can execute specific types of transactions. The external adapter allows execution to occur in a separate process.
- Serial and parallel transaction scheduling that provides options for flexibility and performance. Serial scheduling executes one transaction at a time, in order. Parallel scheduling executes multiple transactions at a time, possibly out of order, with specific constraints to guarantee a resulting state that matches the in-order execution that would occur with serial scheduling. Parallel scheduling provides a substantial performance benefit.
- Pluggable state backends with initial support for a LMDB-backed Merkle-Radix tree implementation and an in-memory Merkle-Radix tree (primarily useful for testing). Key-value databases and SQL databases will also be supported in the future.
- Transaction receipts, which contain the resulting state changes and other information from transaction execution.
- Events that can be generated by smart contracts. These events are captured and stored in the transaction receipt.
- SDKs for the following languages: Rust, Python, Javascript, Go, Java (including Android), Swift (iOS), C++, and .NET.
- Support for multiple styles of smart contracts including Sabre (WebAssembly smart contracts) and Seth (EVM smart contracts).
Who’s Involved?
Hyperledger Transact’s initial code was developed by Bitwise IO and Cargill, with substantial influence from Intel’s previous contributions to Hyperledger Sawtooth. Design discussions with Fabric, Burrow, and Indy maintainers further rounded out the proposal. Transact aims to encourage interface alignment between the projects. Bitwise IO, Cargill, IBM, and Intel are currently involved in the Transact project.
Maintainers from Hyperledger Sawtooth, Hyperledger Fabric, and Hyperledger Grid have already expressed interest in using Hyperledger Transact in their projects. We believe this is just the beginning. We expect that adoption will grow as the project matures, due to the advantages of using Transact’s standard interface for executing smart contracts.
Want to Learn More?
If you are interested in using Hyperledger Transact in your project, you can see the Rust crate and documentation at https://crates.io/crates/transact.
If you want to chat with us or would like to help build Transact, please visit us on the Hyperledger #transact channel at https://chat.hyperledger.org/channel/transact.
About the Author
Shawn Amundson is Chief Technology Officer at Bitwise IO, a Hyperledger technical ambassador, and a maintainer and architect of Hyperledger Sawtooth, Hyperledger Grid, and Hyperledger Transact.
Thanks to the following people who helped make this blog post a success: Dave Cecchi, Anne Chenette, Emily Fisher, Mark Ford, Andi Gunderson, Dan Middleton, James Mitchell, Peter Schwarz, and Gari Singh.
