Fabric Architecture
The Ion Interoperability Framework is designed to be a platform agnostic protocol. As part of the continued development of the platform we have developed a proof of concept for Ion showcasing potential interoperability between Ethereum and Hyperledger Fabric networks.
Previously in Ion Stage 2 Phase 1 we introduced the concept of continuous execution, where both chains were Ethereum based networks. As Hyperledger Fabric has a different network architecture to Ethereum the Ion framework has been extended to allow interoperability to occur between the two chains.
Hyperledger Fabric is a distributed ledger platform designed principally for enterprise solutions. A Fabric network is formed of many peers grouped into organisations, who then create channels between subsets of the organisations.
For example a network with organisations A, B and C may have two separate channels one between A and B, and another channel between organisations B and C. Each channel would have its own individual ledger and data within channels is kept secret from organisations who are not included within the channel. A channels ledger is a key-value database which peers read and write to depending on the execution of chaincode.
Transactions are created when chaincode functions are executed outputs of which define a state transition of the ledger. Transactions are included in a block if the are endorsed by a set of peers defined by a chaincode endorsement policy.
However, simply receiving a single endorsement is not sufficient for a transaction to be deemed valid. Chaincode is deployed along with an endorsement policy, e.g. 3/5 peers must endorse a transaction, which must be fulfilled before a transaction can be deemed valid.
Endorsement policy is defined upon deployment of the chaincode by peers, then when a peer executes a transaction they pass the output thereof to other peers within their channel. Peers then rerun the chaincode execution of the transaction and verify the outputs, signing the transaction payload and broadcasting it to the orginal peer.
When endorsement policy of the particular chaincode is met the transaction is sent to the network orderer. Once an orderer has created a new block it is returned to all the peers within a network, who then apply the changes to their local ledger from each transaction.
For more details on Hyperledger Fabric please see here.
As described in the section above Fabric has a distinct architecture in comparison to that of Ethereum. As in the Ethereum-Ethereum Ion we use the framework to allow continuous execution to occur across the two chains. However, within a Fabric network ledgers are local to each individual channel. Thus interoperability takes place between an Ethereum network and Fabric channel, invoking chaincode in Fabric that triggers the execution of a function on the Ethereum network.
In order to facilitate this we require:
- Fabric Validation Contract
- Fabric Block Storage Contract
- Fabric Continuous Execution Chaincode
- Ethereum Continuous Execution Contract
The Fabric validation contract should verify that a block submitted to the contract is indeed part of the chain on the channel from which it came. Fabric creates blocks through the use of the orderers who append their signature to blocks which clients add to their local ledgers.
Fabric allows for flexible network topologies to be created thus the generalisation of the validation contract has been ignored for the v0 of this proof of concept.
The Ion framework requires that blocks are available for continuous execution contract to query. Thus block are persisted in a storage contract. Natively on a Fabric network the ledger state changes as the read/write set of transactions are applied with every new block. The model of continuous execution relies on the ability to consume specific events and execute code dependent on the execution. Therefore rather than recreating the channel ledger each block is persisted with its relevant transactions and metadata allowing interoperability to continue through an event-based model.
In the current v0 of the proof of concept Fabric blocks are simplified to include only the necessary data required to use a transaction as a trigger.
Shown below is a generic example of the block encoding scheme proposed for the initial v0 PoC.
{
"channel_id": "ch1",
"blocks": [{
"hash": "...",
"number": 5,
"prev_hash": "...",
"data_hash": "...",
"timestamp_s": ,
"timestamp_nanos": 903695991,
"transactions": [{
"tx_id": "...",
"namespace": "cc1",
"reads": [{
"key": "somekey",
"version": {"blocknum": 1}
},...],
"writes": [{
"key": "somekey",
"is_delete": false,
"value": "{ some json formatted key-value parameters as string }"
}, ...],
"validation_code": 0
}, ...]
}, ...]
}
The Fabric block storage contract will store data in the hierarchy, channel -> block -> transaction -> read/write set.
As part of the model of continuous execution chaincode should be deployed which is able to trigger and event that occurs on an Ethereum network, once the block containing said transaction is passed to the relevant network.
Once blocks are stored in the Fabric block storage contract in the format specified above, continuous execution contracts can be developed to consume transactions held.
Though validation proper has been ignored for the current proof of concept in order to verify that a block held contains a specific transaction the contract must query the following:
- Registered Channel Identity
- Block Hash
- Transaction Hash
- Read and Write Set Content
Once these pieces of data have been successfully verified then the contract can execute other code as per the specific use case.
A generic flow of Ion Ethereum-Fabric interoperability is shown below.
As in the generic Ion Framework