Skip to content
This repository has been archived by the owner on Jul 5, 2024. It is now read-only.

Blockchain backend

Simon Siegert edited this page Jun 12, 2018 · 22 revisions

Blockchain backend

Docker structure

For the simulation of a private blockchain we use docker-containers. Each blockchain node is a single docker-container. At the moment we have three blockchain implementations deployed: Ethereum XAIN Multichain

In Ethereum we have three different types of docker-images. The first image is the eth_node, which is started for each blockchain participant. It is mining on the blockchain, sending statistics as Hashrate, Blocktime etc. to the API Server and executes transactions for the scenario.

The second image called bootstrap creates the bootstrap container which is used for initial configuration of the blockchain and to interconnect all participants on the same blockchain.

The third container is the eth_contract_deployer which is used to run the scenarios generated in Scylla. It deploys the smart contract and orchestrates the scenario execution.

In XAIN the docker containers are the same.

The Multichain setup consists only of two different images: master and slaves. The master node is the admin node of the multichain and also takes care of the scenario orchestration (see below). Slave nodes just do transactions.

Blockchain node data retrieval

The blockchain nodes (eth_node, xain_node, multichain_slave) retrieve the following data and send it to our API server:

Chainname, HostID, Target, isMining, Hashrate, Blocktime, Blocksize, Block-difficulty, Transactions

As we send the same data for each blockchain, we generalized the implementation and created the blockchain_statistics_readout package. It makes adding a new blockchain easy, because the only change necessary is to rewrite the data_collection Python script and create an adapter class for the specific blockchain.

Blockchain scenario simulation

As stated above the contract_deployer of each Blockchain is responsible to orchestrate the scenario execution. It has control of all participating nodes on the blockchain and orders them to make a transaction at a given time.

We generalized that, by adding the scenario-orchestration-service package, too. The package defines when transactions are done and who does them, however, it requires a specific implementation of the communication between master node and slave nodes.