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).
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.
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.
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.
- Support for multiple styles of smart contracts including Sabre (WebAssembly smart contracts) and Seth (EVM smart contracts).
Hyperledger Transact provides optional support for smart contract engines implemented for
Hyperledger Sawtooth through the
Transaction context management.
Traits for reading and writing from databases.
Contains components that are used to directly execute a
Traits for handling the execution of a transaction.
Transact structs for batches, transactions and receipts.
Protobuf structs and associated conversion traits.
Sawtooth Compatibility Layer
Batch scheduling with transaction execution APIs
Methods for interacting with State.