Back to our Developer Showcase Series to learn what developers in the real world are doing with Hyperledger technologies. Next up is Navil Rodrigues of Coding Bootcamps.
What advice would you offer other technologists or developers interested in getting started working on blockchain?
To the newbies starting out their journey in the blockchain space, I would suggest having a strong grasp on fundamentals like cryptography and data structure like merkle tree to know how blocks are linked with each other. After which I would suggest reading the book “Mastering Bitcoin by Andreas” to enhance your knowledge. Later on you can choose a public or private blockchain that interests you.
Give a bit of background on what you’re working on, and let us know what was it that made you want to get into blockchain?
I am currently working as a full-time blockchain developer at Mckinley Rice. My most of the time goes architecting and implementing smart contracts for Ethereum and sidechains. I also have experience in developing and designing ICO contracts and bridging solutions to connect different chains. The “State of trust,” “Decentralization” and “Immutable data records” made me fall for this technology.
What Hyperledger project(s) are you working on? Any new developments to share? Can you sum up your experience with Hyperledger technologies?
I have worked on a supply chain finance platform built upon Hyperledger Fabric that was developed to provide a common platform for suppliers, anchors and financial institutions. I keep an eye on what’s new in Hyperledger Fabric to stay updated with the latest developments. I would say the community behind the Hyperledger umbrella development is very active and its industry experts.
What are the main differences between developing blockchain applications in Hyperledger Fabric or Ethereum?
There are several differences. For instance, the consensus algorithm or architecture of a popular public blockchain like Ethereum or Polygon is very different from Hyperledger Fabric as they serve different purposes. Likewise, when it comes to NFT assets on a public network like Polygon versus a private network like Hyperledger Fabric, public networks allow integration with cross-chain networks and DeFi. For example, RealBig NFT assets are tied into both crypto exchanges and DeFi platforms for staking.
What do you think is most important for the Hyperledger community to focus on in the next year?
The most important thing Hyperledger can focus on is increasing the number of transactions per second. Also, we like to see Hyperledger tools and libraries that are currently at incubation stage become active.
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?
Hyperledger Transact is a really interesting product. We need methods for quickly creating distributed ledger technology (DLT) applications.
What’s the one issue or problem you hope blockchain can solve?
Blockchain is going to solve many problems. However, I am looking forward to seeing blockchain being adopted and implemented more by private companies.
Where do you hope to see Hyperledger technologies and/or blockchain in 5 years?
We hope to see robust widely accepted Hyperledger DLT applications especially among enterprise companies.
What is the best piece of developer advice you’ve ever received?
Spend more time on architecting a solution thoroughly than developing it.
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.
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.
