Inferno Sidechain


Inferno Sidechain is an Ethereum sidechain with a block time of 15 minutes. Every time a 0xBTC block is mined, the submitter is allowed to add a new block to the sidechain. The data structure of the chaindata is a simple Merkle Tree, such that each block has a hash and points to its parent block hash so that a chain is formed. There can be many branches like a tree, and so there are mechanisms used to determine which branch is the ‘canonical branch.’

To a sidechain validator node (such as one that is adding new blocks), the ‘canonical’ branch is simply the longest valid branch. The definition of 'valid in this case is:

  1. The node has all of the transaction data (chain data) for all blocks in the branch
  2. The chain data is all valid such that the transactions are signed properly by their senders (ECDSA) and balances are never going below zero

In this way, when a node adds a new block, it will add it on top of the ‘longest valid branch’ in its own opinion. Nodes should all have the same chaindata as one another, and thus they will all form the same consensus, the same opinion. When a node builds and adds a block, they must give all of the other nodes all of the chaindata for that block or else the other nodes will not build on top of it.

Users can send tokens into the smart contract and then broadcast an ‘import tokens’ tx to the nodes to claim them in the sidechain. Also, users can transfer tokens around with transfer tx. Finally, users can broadcast an ‘export tokens’ tx on the sidechain and then, once it has enough confirmations, prove to the smart contract that the tx was included in a Sidechain block with all of those confirmations and the contract will pay out the tokens.

Now, this describes a working sidechain and it is secured by 51% Proof of Work. However, its possible to do even better. The Ethereum Smart Contract which holds the tokens for the sidechain must be able to know what the ‘longest valid branch’ is. It only knows the block hashes, not the data. Though it is easy for the contract to compute the longest branch, it is impossible for it to compute whether or not a branch is ‘valid’ according to those rules described above. After all, that is based on nodes opinions derived from making sure every tx is properly signed and balances don’t go negative. Too much data to pipe through the EVM.

Therefore the contract can only rely on nodes consensus but if the contract is blindly trusting all transactions which are included in blocks (trusting all blocks) which belong to the longest branch (even if invalid), then a 51% attacker can make the longest branch by themselves, add fake
invalid transactions into fake blocks, and call the smart contract exit method to steal the tokens from the contract- from the sidechain. However, by tracking the ‘block branch depths’ AND tracking the ‘block counts’ the contract can determine that there had been more or less than
a certain % total ‘consensus’ on a particular branch segment. So this means the contract can tell of there is at least , say, 90% or higher consensus on a particular branch segment, instead of just majority.

(Every time a new block is added, it’s depth is equal to it’s distance from the genesis block on its branch. It’s block count is the number of total blocks ever added before it, on any branch. )

In this way, we can require that any exit transaction has 256 confirmations on top of it, and during those confirmations, less than 25 blocks were added to other conflicting branches over that segment period. That way, it would actually require a 90% attack to perform a fake exit and steal tokens out of the sidechain, in a faked block attack, back to mainnet. That’s because if you only had say 60%, the other 40% of ‘good’ nodes would be adding blocks to another branch and would make the attackers block counts increase far too fast compared to their depths.

The downside of this approach is that a single entity with 10% hashpower can stall or prevent exits from occuring by mining conflicting blocks, however they cannot do this indefinitely and gain no economic value from this; they only lose money. Another downside is that it will take approximately 48 hours worth of good confirmations to exit tokens from the sidechain. Fortunately, this still pegs the value of the sidechain tokens to their mainnet values and liquidity pools can be set up which immediately accept a sidechain token and reward a mainnet token in return for a small fee. As long as these nodes can exit tokens from the sidechain to the mainnet on a -relatively- regular schedule (even if only once per month or so) that would be sufficient. Especially since any amount of tokens can be exited at a time.

Note 1. As an extra measure for helping maintain consensus, there is a new method in the contract called ‘burnedTokens.’ This allows any node to burn tokens in the smart contract. Other nodes can set a ‘peerBurnMinimum’ such that other peers must prove that they have burned (staked) a certain amount to connect to the network as a node. Then, nodes can ‘blacklist’ nodes who do too much ‘cheating activity’ and those burned/staked tokens are then blacklisted/useless. The ‘cheating nodes’ must then stake more tokens and use a new address in order to connect again. This allows for a staking/slashing mechanism, all handled at the node level. It is entirely optional.

Deployed Ropsten Contracts

InfernoSidechain - 0x3ac02510ebd1202b6fed07310831e07dc5d36e77

0xBTC - 0x9D2Cc383E677292ed87f63586086CfF62a009010


This is exciting. Thanks for sharing. I guess we’ll get a follow-up post that elaborates on benefits and use cases of the sidechain.


I have nothing intelligent to add to this conversation. Just wanted to post here so in 10 years when people look back, they’ll see me posting here and think “man I wish i knew about this project back then”.