ERC20 token as Hyperledger Fabric Golang chaincode
As well as Ethereum blockchain, Hyperledger Fabric platform (HLF) can be used for token creation, implemented as smart contract (chaincode in HLF terminology), that holds user balances. Unlike Ethereum, HLF chaincodes can’t work with user addresses as a holder key, thus we will use a combination of Membership Service Provider (MSP) Identifier and user certificate identifier. Below is a simple example of how to create a token as Golang chaincode on the Hyperledger Fabric platform using CCKit chaincode library.
What is ERC20 token standard
The ERC20 token standard came about as an attempt to standardize token smart contracts in Ethereum, it describes the functions and events that an Ethereum token contract has to implement. Most of the major tokens on the Ethereum blockchain are ERC20-compliant. ERC-20 has many benefits, including unifying token wallets and the ability for exchanges to list more tokens by providing nothing more than the address of the token’s contract.
ERC20 implementation basics
Essentially, an Ethereum token contract is a smart contract that holds a map of account addresses and their balances. The balance is a value that is defined by the contract creator — it can be fungible physical objects, another monetary value. The unit of this balance is commonly called a token.
ERC20 functions do:
balanceOf: returns the token balance of an owner identifier (account address in case of Ethereum)transfer: transfers an amount to an owner identifier of our choosingapprove: sets an amount of tokens a specified owner identifier is allowed to spend on our behalfallowance: check how much an owner identifier is allowed to spend on our behalftransferFrom: specify an owner identifier to transfer from if we are allowed by that owner identifier to spend some tokens.
Owner identifier in Hyperledger Fabric
In the Hyperledger Fabric network, all actors have an identity known to other participants. The default Membership Service Provider implementation uses X.509 certificates as identities, adopting a traditional Public Key Infrastructure (PKI) hierarchical model.
Using information about the creator of a proposal and asset ownership the chaincode should be able to implement chaincode-level access control mechanisms checking that the actor can initiate transactions that update the asset. The corresponding chaincode logic has to be able to store “ownership” information associated with the asset and evaluate it with respect to the proposal.
As unique owner identifier (token balance holder) in HLF network we can use a combination of MSP Identifier and user identity identifier. Identity identifier — is concatenation of Subject and Issuer parts of a X.509 certificate. This ID is guaranteed to be unique within the MSP.
Client identity chaincode library allows writing chaincode which makes access control decisions based on the identity of the client (i.e. the invoker of the chaincode).
In particular, you may make access control decisions based on either or both of the following associated with the client:
- the client identity’s MSP (Membership Service Provider) ID
- an attribute associated with the client identity
CCkit contains identity package with structures and functions that can be used for implementing access control in chaincode.
Getting started with the example
In our example, we use CCKit router for managing smart contract functions. Before you begin, be sure to get CCkit:
git clone git@github.com:s7techlab/cckit.git
and get dependencies using dep command:
dep ensure -vendor-only
ERC20 example is located in examples/erc20 directory.
Defining token smart contract functions
First, we need to define chaincode functions. In our example we use router package from CCKit, that allows us to define chaincode methods and their parameters in a consistent way. Details about chaincode method routing, middleware, chaincode invocation context were described in previous article.
At first, we define init function (smart contract constructor) with arguments symbol, name and totalSupply. After that we define chaincode methods, implementing ERC20 interface, adopted to HLF owner identifiers (pair of MSP Id and certificate ID). Methods, querying from chaincode state, are prefixed with query, and methods, writing to chaincode state, are prefixed with invoke.
As a result we use default chaincode structure, that delegates Init and Invoke handling to router.
Chaincode initialization (constructor)
Chaincode init function (token constructor) performs the following actions:
- puts to chaincode state information about chaincode owner, using owner extension from CCKit
- puts to chaincode state token configuration — token symbol, name and total supply
- sets chaincode owner balance with total supply
Defining events structure types
We use Id structure from identity package and define structures for Transfer and Approve events:
Implementing token smart contract functions
Querying function is quite simple — it’s just reading the value from chaincode state:
Some of changing state functions are more complicated. For example in function invokeTransfer we do:
- receive function invoker certificate (via tx
GetCreator()function) - check transfer destination
- get current invoker (payer) balance
- check balance to transfer
amountof tokens - get recipient balance
- update payer and recipient balances in chaincode state
Testing
Also, we can quickly test our chaincode via CCKit MockStub.
To start testing we init chaincode via MockStub with test parameters:
After we can check all token operations:
Full example can be found here https://github.com/s7techlab/cckit/tree/master/examples/erc20
More about chaincode unit testing and test driven development you can read here:
Chaincode state schema can be implemented with protobuf code generation, it allows to define data model once and then easily write and read structured data to and from a variety of data sources.
