[Concept] 0xBitchain A layer 2 sidechain that runs natively on 0xbitcoin


Hey all,

I have been contemplating putting together an Ethereum based sidechain that runs natively on 0xBitcoin to pay for transactions for a couple of days now. There has been a considerable amount of work done over the past several months on improved consensus algorithms for Ethereum networks, namely HBBFT, Istanbul BFT, Raft and PoA.

I am putting together test POCs to determine what might be the best fit if the community decides that a consortium driven sidechain would add value to the 0xBitcoin ecosystem. For those of you interested, this is what myself, Mikers and others have been digging up over the last couple of days:

POA network bridged ERC20 platform: This has the most promise in my opinion, because it has all of the components required to set up a sidechain, bridge it to a mainnet ERC20 and have a fully running stack out of box. Sort of feels like a ‘white label ERC20 bridged side chain’. So standing up “0xBitChain” would include all of the shiny Dapps out of box, including the token bridge, consortium management Dapps, a really nice block explorer called Blockscout and considerable documentation and support. I have reached out to the team, and they’ve documented the entire journey that brought DAI onto their own sidechain in the same manner. That’s the good news. The bad news: the setup is pretty complicated and it looks like they only support Azure for the moment. I am not an infra guy, so there was likely a lot of pitfalls there, that are mere bumps in the road to more seasoned devops folks.

Istanbul BFT
@Mikers pointed me to Istanbul BFT, which is really, really cool. It takes a little effort to set things up, but it offers Byzantine Fault Tolerance for a side chain. Great for decentralization, but I was seeing some issues when deploying test contracts. It may simply be my config.
This configuration would provide a great decentralized base layer, but we still require connectivity back to mainnet. POA Network has done a really good job of modularizing their token bridge, so I don’t think it would take that much effort to include it as part of a sidechain.

In a similar vein, the IBFT has been built and supported by MorganStanley to be compatible with their Ethereum instance Quorum. Before you get all up in arms about the philosophical juxtaposition of a bank developing an Ethereum network fork, what they’ve done is actually very comprehensive and impressive. They offer out of box Raft and IBFT consensus, and the speed of going this route is unparalleled. If we are looking for speed and privacy, this seems like a viable solution.

Vanilla Geth Clique
Geth can be quickly and easily configured as a PoA out of box. There are several resources online supporting this. I was able to stand up a testnet very quickly, but again, this would only supply the base layer without bridging as above.

Just this morning I discovered Keleido and have been playing around with it. It’s a cloud hosted solution for creating private Ethereum networks like Ethereum. I wish I would have found this first, because it offers a great place to stand up a consortium, and test out different ethereum protocols including Quorum IBFT, standard PoA, and Quorum Raft. This is probably the best place to go to test out the tech and then go from there. The downside, is that you don’t have access to network parameters of the genesis block, so configuring gasLimit, seeded accounts, and chainIds ( 918, right Mike? :wink: ) is not possible.



For everyone’s benefit, @mikers and I had a chat to further the conversation around bridging 0xbitchain. We would like to use 0xbitcoin’s proof of work to secure these side channels. Normally, with payment channels, you would use a multisig between two parties interacting with the channel. This works, because it is in both parties best interest to maintain and validate the true balances in order to check value back into the mainnet.

When dealing with a single party that is crossing value between chains, a new attack vector is introduced. Since there is only one signatory, they could manipulate the payload and receive more tokens on mainnet than were exported from the sidechain bridge. An obvious solution is to centralize this operation with one or many cosigners of the txn. Of course this is not desirable, since human actors are susceptible to nefarious inconsistencies especially when it comes to financial gain.

It would also be possible to create a decentralized network of cosigners that validate the transactions on both sides of the bridge, however on it’s own this network is susceptible to 51% attacks. This leaves us with Proof of Stake or Proof of Work to de-incentivize attacks on the bridge network. Using Proof of Stake, bridge validators would be required to lock a significant amount of 0xbitcoin into the bridge and be subject to financial disciplinary action when consensus skews from the norm.

To further the idea a trusted data oracle whose sole purpose is to verify transaction state only in the scenario of a dispute, would automatically punish bad actors in the verification network. This, however, adds a central component to an otherwise decentralized network.

Using pure Proof of Work to secure the bridge would also be possible. Merge mining the bridge requests with 0xbitcoin within the contract is possible, but might be a little difficult to produce a fair and accessible decentralized validator network, if the requirement to validate a bridge transaction ( or transaction block ) is to mint a 0xbitcoin block.( currently at difficulty of ~818m ) This can be mitigated and fragmented with pooled verification, as with pool mining. Just as miners submit partial solutions of fractional difficulty to a mining pool to prove their hashing power to a pool, validators could cast validation votes in the form of difficulty, receiving a single vote per difficulty solved per 0xbitcoin block. An added benefit of this architecture would allow bridge verifiers to merge mine with 0xbitcoin offchain, instead of through the bridge contract.

The attack vector of the above scenario involves a 51% attack on the 0xbitcoin network. Given the current relatively small size, it would be possible for a large mining operation to take over 95% of the hashpower of the network for a period of time, thereby controlling the vast majority of the bridge votes. In this scenario, an attacker could submit inaccurate, co-signed withdrawal requests to the mainnet bridge at will.

Again, mitigation for this scenario could be the use of the aforementioned trusted ‘dispute oracle’.


This leaves us with Proof of Stake or Proof of Work to de-incentivize attacks on the bridge network

Actually this is not entirely true. If we chose to dig deeper, we could look at native consensus mechanisms for this middle layer, such as BFT, Raft or honeybadger.


I started to develop a sidechain concept around 0xBitcoin.Exchange (CEX vs. DEX -> a hybrid?), and the idea started to grow. I’m happy to find the momentum around 0xBTC sidechain.


My individual contribution only - happy to discuss!


In my opinion, cost on transactions is bad business logic. It hinders innovation and growth. Instead, with a sidechain and free ETH other revenue models could be developed. In my approach, producing processing capacity (adding nodes) would be rewarded, and that could make 0xBitChain the most robust blockchain in the world!

Profits should be collected from value creation (DApps, services using 0xBTC as a currency) and value transfer (exchange fee) - both of these take place AFTER value creation. Tx cost happens BEFORE value creation, and that’s why I think it is bad logic.

One of the greatest barriers of the Ethereum adoption is gas fee (in addition to slowness); people get innovative to circumvent that and it provides no value whatsoever.


I’m fully on board with securing the gateway somehow. You guys seem to have valid ideas for that.

I have been mostly: “Let’s adopt ChainLink as soon as it gets on production.” And perhaps earning some extra LINKs by running a ChainLink node pool as an integral component of 0xBitChain’s architecture?


@icinsight There is no reason why we could not bridge into ChainLink if there is a need to do so.