Multi-Blockchains in Ethereum/RSK (1)

Next Post

The implementation of a blockchain includes the creation, distribution, and manage of blocks:

A block, in Bitcoin and Ethereum, has:

• An unique hash
• A parent block, identified by hash
• A block number (one plus parent block number)
• A list of transactions

In the case of Ethereum and RSK, a transaction has:

• A sender account
• A receiver account
• A value to transfer
• Additional data (used if the receiver account is a smart contract)

A list of chained valid blocks form a blockchain:

In Ethereum/RSK, a block has also:

• Uncle blocks
• Associated Block Difficulty (difficulty of proof of work plus the sum of uncles difficulties)

So, the presence of uncles contributes to the block difficulty. And this number adds to the TOTAL difficulty of the blockchain. Many nodes in the network, called miners, could generate blocks to be added to the current blockchain, but the consensus algorithm  choose the blockchain with the greater total difficulty:

(in Bitcoin, the longest blockchain wins; in Ethereum/RSK a shorter blockchain could win if it has greater total cummulative associated difficulty).

One problem is to keep the state of all accounts and contracts in the system. Each transaction also has

• State Root Hash

the hash of the world state AFTER the execution of the transaction. This hash is verified by every node in the network, so all the working nodes agrees on the resulting world state. A world state is saved in a trie, that can be identified by such root hash (see my previous work on tries Building a Blockchain (5) Building a Blockchain (12))

The block itself also has a State Root Hash, representing the world state AFTER the execution of the block. It could be different than the last transaction state root hash: the execution of block could assign rewards and alter account balances, if the protocol specifies the changes. This block root is also checked by the running nodes in the network, in order to validate the block state and consensus.

One problem is that the build of a block could be a bottlenect if the system should process many transactions (maybe hunders or thousands per second). This is the principal use case that guides the proposal of this post series. It could be interesting to have MANY blockchains:

Then, one blockchain could be dedicated to the process of a popular token/contract, or other blockchain could be dedicated to the transfer in a particular country. Only in few cases could be needed a transfer between blockchains. And this schema is not limited to TWO blockchains, we could have many blockchains. And the state storage and status could be maintaned by MANY nodes, sometimes, a node is dedicated to keep only ONE or TWO blockchains. So the scale of the operation does not hurt the system.

In the next post, I will describe the modification to apply to Ethereum/RSK so we can  manage multiple blockchains in the network.

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez