Guest post: Swetha Repakula of IBM
At this point, there are few that haven’t heard the word blockchain. Despite all the buzz and hype around the technology, the learning curve is steep. When we meet people new to the technology, we like to break down blockchain into four main parts:
We believe most blockchain technologies can be separated into four parts and that developers/consumers should have the ability to choose at each of those levels. Take Hyperledger Fabric for example:
In the spirit of expanding choices, Hyperledger Fabric now supports Ethereum Virtual Machine (EVM) bytecode smart contracts. Contracts can now be written in languages such as Solidity or Vyper. Along with introducing a new smart contract runtime, Fabric also has a corresponding web3 provider which can be used to develop decentralized applications (DApps) using web3.js. This new feature comes as part of the 1.3 release and is motivated with the goal to enable developers to be able to migrate or create DApps for a permissioned platform.
Before diving into the details of the EVM integration, let’s expand on the concept of a smart contract runtime. In general the runtime refers to what are the languages that are supported by a specific platform. But there are many other considerations that should be weighed in. Due to the nature of blockchain, these runtimes have to be evaluated in a distributed nature. Since many nodes, if not all of them, have to run and store these contracts, the network has to be mindful of the runtimes being supported. Languages affect how computationally intensive an arbitrary contract can be as well as the deterministic nature of them. Though neither is necessarily a limitation, they can place an unfair burden on the contract developer. Another important factor is what languages the contract developers themselves are experienced in. With the emergence of blockchain, there has been an increase in developers that do not have technical backgrounds, so picking up new languages is not always a practical solution. The implications of smart contract runtimes make choosing a blockchain network even more difficult. Through the introduction of an EVM, we hope to make sure that Solidity smart contracts and permissioned networks are not mutually exclusive.
As part of integrating an EVM, we wanted to recreate some of the developer experience of Ethereum. Therefore the integration can be broken into two key pieces, an EVM user chaincode, and a web3 provider Fab3.
The EVM user chaincode is a wrapper around the Hyperledger Burrow EVM. We have also added functionality to enable queries about accounts and contract code. Below are a couple of the key design decisions made as part of the integration.
Ethereum has two types of accounts, a Externally Owned Account (EOA) and Contract accounts. EOAs essentially are an address that is generated from a user’s public key and a balance of ether. As part of this work, Fabric was not introducing ether or any other tokens so EOAs are not explicitly stored. However a user account address is generated on the fly from a user’s public key.
Contract accounts contain the runtime EVM bytecode for a contract. Following Ethereum, the EVM chaincode will be storing these types of accounts on the chain. Smart contract deployment through the EVM will not need a manual step of installing a smart contract like in the Fabric workflow.
Every instruction in the EVM requires a certain amount of gas. For every transaction that is run through the EVM, enough gas must be provided to ensure completion. This makes sure “miners” don’t risk DoS caused by infinite loop, and waste computational resources Essentially if enough gas is not provided for a certain transaction, it will exit before finishing. In its current iteration, the EVM chaincode provides a large hardcoded amount of gas per transaction.
Another key piece we adopted from the Ethereum ecosystem is the Ethereum JSON RPC API. The API defines a systematic way clients can interact with the Ethereum network. However, due to the differences of Ethereum and Fabric, Fab3 does not completely implement the API. It does support enough instructions to allow for DApps written using the web3.js library.
Try out the new feature by following this tutorial.
Our next goals include enabling smart contract events, and expanding the Fab3 support so that clients such as Remix and Truffle can be used to interact with Fabric. We are also looking for other aspects of the Ethereum ecosystem that can be adopted. This new feature is also a topic of one of the workshops at Hyperledger Global Forum in Basel, Switzerland this December. Come join us and bring your EVM smart contracts and DApps to play with.
We encourage developers to try the feature out and give us feedback! To get started with using Hyperledger Fabric and EVM, you can download the 1.3 code today: https://www.hyperledger.org/projects/fabric