Syncing a sidechain
A few years ago, I wrote about how to scale a blockchain by having multiple derived blockchains (sidechains), keeping the sync between the parent blockchain and the derived ones. Read: Connecting Blockchains (7).
I also gave a talk about connecting different blockchains at LaBitConf 2016 (Buenos Aires). Some ideas in my Connecting blockchains post series. The idea of having many sidechains could be read at Multiblockchains.
Today I want to describe a way to keep the synchronicity between a main blockchain and a sidechain, in a strong way. For the sidechain concept read these resources:
- Enabling Blockchain Innovations with Pegged Sidechains
- Drivechains Sidechains and Hybrid 2-way peg Designs
- The Bitcoin News Show #62 — Sidechains, Drivechains and RSK
- Drivechain Info
- The Value Of Sidechains And Leveraging Their Potential (with a good description of BTCRelay use on Ethereum)
I am going to build on the idea already implemented by RSK: having Bitcoin as the main blockchain, and RSK as the sidechain. In the following description, the mainchain is Bitcoin, the sidechain is an Ethereum/RSK-like blockchain, supporting smart contracts.
What does to synchronize mean? The sidechain must have and maintain information about what the blockchain series of the main blockchain is. In the case of Bitcoin and RSK this relationship is strong, because the RSK sidechain takes into account bitcoin transfers that occur in the main blockchain: when a bitcoin user transfers to a special bitcoin account (the account of the RSK federation), those funds they are frozen in Bitcoin world and a corresponding release of RBTC (the currency in RSK) is released in RSK world. That is why it is important for the sidechain to know exactly which are the blocks that compose the main chain in Bitcoin network: to really have a world state COHERENT with the Bitcoin world.
In the current implementation Bitcoin-RSK, that timing is handled by a smart contract, the bridge contract, which runs on RSK. This contract receives information on the Bitcoin blocks that will appear on the main blockchain, validates them, and decides which is the main chain that is being formed. The information of the block headings comes to you in the form of transactions that anyone can send to keep the system decentralized: there are no oracles that are trusted to receive this information, but the block headings are taken and added to the state of the Bridge contract by any interested party.
Based on these ideas, I would like to describe another alternative. First a bit of nomenclature:
BBH: Bitcoin Block Header
BBH (n, a): Bitcoin block header with height n and hash a (different letters, different hashes)
BBH (n, a, p): Bitcoin block header with height n, hash a, and parent block hash p.
Usually, the RSK sidechain receives the Bitcoin blocks, even alternative ones, and at every moment the Bridge contract knows what for him is the best Bitcoin block until then. If new bitcoin blocks appear, alternative or not, they will be informed to the Bridge contract.
In some way, the controller smart contract (bridge in the RSK case) should have a representation of all the mainchain forks:
In my proposal, there will be something similar: a contract in whose state the best Bitcoin block so far is informed, and its previous blocks. I will put:
RB (a): RSK/Sidechain block for which the best Bitcoin block is the one that corresponds to the hash a.
As the relationship between the main blockchain and the sidechain is strong, my proposal makes a tough move: if there is reorganization, alternative blocks, fork, in the main blockchain, that change SHOULD be reflected in the sidechain chain.
So when a new transaction reports a new bitcoin block BBH (n, a, p) it can only be added to an RSK block that belongs to the branch that considers BBH (n-1, p) as the best block. This restriction is enforced by the mining algorithm that builds a new block from transaction pool: it should recognize the transaction informing the new mainchain block header, and then, select a valid parent block that should be compatible with the new information.
In this way, each RSK alternative chain somehow reflects one and only one Bitcoin alternative chain.
But I think those changes are justified due to the STRONG nature of the relationship between the two blockchains. When there is a reorganization in Bitcoin, then there is a reorganization in RSK. This allows the state of the forward chain RSK world to always be in a state consistent with the main Bitcoin chain it contains as a reference.
When an RSK chain is reversed, the transactions of the blocks removed from the main chain return to the pool of pending transactions, so their inclusion will occur in the new alternative chain that just appeared.
A technical nuance: the senders that informs new Bitcoin block headers could have nonce (transaction count, number of transactions emitted) that are incompatible with the new branch selected.
Incidentally, NO BLOCK HEADER could be saved INTO controller smart contract, only some reduced information, useful for other use cases, like Merkle proof of a Bitcoin transaction included in that block. When the controller smart contract received the transaction, the payload HAS the block header, but after validation, it is not needed to save it into storage.