A new Sidechain Proposal by Horizen — Part 2
A promising approach to building on top of existing first-layer protocols — a summary of the whitepaper for readers with a general understanding of blockchain technology.
You can find Part 1 of this article here.
Many people don’t have the necessary time or motivation to work themselves through whitepapers but nonetheless want to stay up to date with current developments in the blockchain sphere and have a general understanding of the technology. For those, I want to provide an overview of what sidechains are, why a number of teams are looking into them (Part 1) and how the sidechain implementation that Horizen is proposing works (Part 2).
TL;DR: The Engineering team at Horizen led by Alberto Garoffolo has proposed a new sidechain construction in a recent whitepaper based on proof-of-stake principles. The main innovation is a new backward transfer protocol, that allows transactions from one of the possibly many sidechains back to the mainchain, without the mainchain having to track the sidechain and without introducing a centralized federation of validators. While a reference implementation of a sidechain consensus protocol will be provided, a wide range of sidechain consensus protocols will be possible.
What Happened Before
In the first part of this article, I talked about why sidechains could be an elegant way to overcome current limitations regarding scalability and governance in the blockchain ecosystem.
Having the ability to deploy sidechains will dramatically enhance the possibilities of building on top of existing public blockchains. One of the first use-cases of a sidechain for the Horizen project will most likely be the Treasury(Whitepaper, Summary), moving the organization a step closer to its goal of becoming a decentralized autonomous organization.
I ended with introducing the two major parts of a sidechain implementation:
- The sidechain consensus protocol — SCP
- The cross-chain transfer protocol or 2-way peg — CCT
Prerequisites
For the second part of this article, I will assume a basic understanding of general blockchain technology concepts such as
- Block structure (Header, Block Hash, Merkle trees…)
- the concept of POW/POS
- the idea of sidechains in general (Part 1 will help)
Nonetheless, I will try to keep it readable for the non-technical audience.
The Sidechain Consensus Protocol
The proposed SCP is based on the Ouroboros Protocol developed by IOHK for the Cardano project with some slight modifications. It is a Proof of Stake based consensus protocol that makes use of the concept of delegation and generally works like this:
- Time is divided into epochs of k slots. It is not specified yet, but let’s assume k will be 8 for the sake of the argument (and matching the graphic below).
- Each slot represents the opportunity to create a sidechain block within a certain period of time. Research suggests 20 seconds to be a reasonable time to allow network synchronization across the globe. During an epoch up to k blocks will be forged.
- For each slot, there is a slot leader, which is authorized to generate a block within this time period.
- Before an epoch begins, there is a Slot Leader Selection Procedure that assigns one slot leader per slot for the next epoch (in our example 8 slot leaders will be selected per selection procedure/epoch).
- If a slot leader misses his time slot to forge a block, the next slot leader will include the transactions that weren’t included previously.
Modifications of the Ouroboros Protocol
The security of software is usually evaluated under certain assumptions. Consensus protocols are no different.
Where POW consensus is based on the assumption of an honest majority in hashing power, the core assumption that the Ouroboros POS protocol security is based on, is a truly random Slot Leader Selection Procedure. No party should be able to predict, who will be the assigned slot leader during a given time period.
To achieve this goal, a source of randomness is needed and creating true randomness is harder than one might think. The original Ouroboros POS protocol introduced a coin-tossing protocol based on verifiable secret sharing to generate randomness. The proposed (modified) solution leverages the POW mainchain for this. It is a simple, yet effective solution.
The randomness is derived from the smallest block hash on the mainchain in a given period of time. For this to work, the set of eligible certifiers will be fixed, before the randomness generation period starts. In order to corrupt this mechanism, a significant share of the hashing power would be needed. Under the assumption of an honest majority in hashing power, this should be infeasible and economically unprofitable. A formal analysis of such an attack will be conducted separately.
Another modification to the original Ouroboros implementation regards references to the mainchain included in the sidechain blocks. I will talk about this in the context of the Cross-Chain Transfer Protocol when introducing the concept of full referencing.
Liveness and Persistence
Garay, Kiayias & Leonardos say that the standard procedure of proving blockchain consensus protocol security requires demonstrating the ability of the protocol to satisfy two fundamental properties of a distributed ledger: liveness and persistence.
“Persistence states that once a transaction goes more than k blocks “deep” into the blockchain of one honest player, then it will be included in every honest player’s blockchain with overwhelming probability, and it will be assigned a permanent position in the ledger.” — Garay, Kiayias & Leonardos, 2014
Persistence is closely related to the property of immutability and might actually be the same, but I’m not quite comfortable making that claim.
“[…]Liveness says that all transactions originating from honest account holders will eventually end up at a depth more than k blocks in an honest player’s blockchain, and hence the adversary cannot perform a selective denial of service attack against honest account holders.” — Garay, Kiayias & Leonardos, 2014
This is closely related to the property of censorship resistance but as before I wouldn’t go as far as claiming they are identical.
(Note that this is a different k from the one describing the number of blocks per epoch.)
Like the overall security of software, properties like liveness and persistence are also proven under a set of assumptions such as an honest majority among participants. An exhaustive list of these assumptions and their definitions can be found in the original Ouroboros paper.
Enabling Different SCP’s
The motivation behind developing the SCP and CCT separately was to enable a variety of possible SCP’s. Although the following description of the Cross-Chain Transfer Protocol takes up on a few concepts of the adapted Ouroboros protocol described above, it can be combined with a number of other consensus mechanisms. Horizen is currently looking into a Block-DAG (Directed Acyclic Graph) structure, which will most likely be deployed as a sidechain. The interoperability between another POW sidechain or a Block-DAG sidechain and the CCT protocol will be subject to additional research.
The Cross-Chain Transfer Protocol
The CCT protocol is the most important part of the sidechain construction since it defines the overall structure of the communications between MC and SC.
Sidechain Whitepaper — Garoffolo, Viglione
In Part 1 I defined the two sub-protocols of the CCT:
The first sub-protocol is dealing with forward transactions, which are transactions from mainchain to sidechain.
The second sub-protocol is dealing with backward transactions, which are transactions from sidechain to mainchain.
Forward Transactions and Full Referencing
It is the goal to enable cross-chain transfers, so there needs to be a form of communication between chains. Firstly, the sidechain needs to be aware of all transactions on the mainchain that are sending assets to an address on the sidechain (forward). Secondly, there needs to be a mechanism for the mainchain to verify incoming backward transactions.
The former function, enabling forward transactions, is achieved by a concept called full referencing. It solves two problems at once: enabling transfers from the main- to the sidechain in a straightforward (pun not intended) fashion and dealing with finality (or lack thereof).
Full referencing implies that the sidechain blocks contain the full chain of the mainchain block references. Even if some block forger missed his opportunity to include a reference to the newly generated MC [mainchain] block, some of the following block forgers will include the missed mainchain reference.
Horizen Sidechain Whitepaper
So how does full referencing achieve the goals mentioned above?
The references can be one of two things:
- If the mainchain block contains no transaction to the sidechain under consideration only the block hash is used as a reference.
- If there are one or more forward transactions in the last block, the entire block header, the forward transaction(s) and the Merkle path off the transaction(s) are used as a reference.
By including the block header and Merkle path of forward transactions, sidechain nodes can easily verify the transfers. You could think of the two ledgers, sidechain and mainchain, as two separate books. Since the sidechain bookkeepers constantly monitor the main(chain) book, they can easily add cross chain transactions to their book. By including the transactions together with their Merkle paths and the corresponding block header, every other entity on the sidechain will be able to verify for herself, if the transaction is valid, without having to check with the mainchain.
Enabling the forward transfer protocol implies making changes to the current mainchain logic. A new type of transaction needs to be introduced, that burns coins and provides a set of metadata which allows the user to claim the same amount (minus the TX fee) of newly created coins on the sidechain. The same goes for backward transactions: coins on the sidechain are burned and an equivalent amount minus TX fees created on the mainchain. A construction with a locking and unlocking procedure might also be feasible.
The other problem that is solved relates to the finality issue with POW chains using Nakamoto consensus. It is possible for a valid forward transaction to be included in a mainchain block at first, but the block containing the transaction to be forked out and becoming orphaned shortly after. This could create the opportunity to double spend (once on the mainchain and once on the sidechain) if the transaction was already added to the sidechain ledger. The binding eliminates such a situation. In case of a fork in the mainchain, the sidechain blocks that refer to the forked out mainchain block will also be reverted.
Backward Transactions and Certifiers
Now let’s get into the interesting part: how can the mainchain verify incoming backward transactions, if it doesn’t keep track of the sidechain(s). Using the bookkeeper analogy from before the following problem has to be solved: the mainchain bookkeepers need to add incoming transactions from the sidechains to their book, but can never look at the other books around them.
Here I would like to go back to the differentiating factor of sidechains and Drivechains that I mentioned earlier. For a pegged sidechain construction there are two operational modes, which concern the execution of backward transactions: synchronous and asynchronous.
The synchronous mode implies that both main and sidechains are aware of each other and can verify transfer transactions directly, while the asynchronous mode relies on validators to process transfers.
Horizen Sidechain Whitepaper
As I mentioned earlier the Horizen team decided on developing the SCP and CCP independently of each other. Since it is a stated goal to enable a variety of different SCP’s, it is not feasible for the mainchain to track every sidechain, for it would have to know each individual consensus protocol. This implies that strictly speaking the proposed implementation qualifies as a drivechain rather than a sidechain, for its operational mode is asynchronous: the mainchain doesn’t keep track of the sidechain(s).
Getting Transaction Data from Side- to Mainchain
From a data point of view, to make all of this work there needs to be a transfer mechanism, initiated on the sidechain, that informs the mainchain of incoming backward transactions. This is done by introducing a new type of data container called Cross-Chain Certificates (CCCert’s).
The CCCert contains basic information, such as the sidechain identifier (SCid)and the CCCert ID as a header. All cross-chain transactions are collected in the Backward Transfer List. The last three data fields concern the certifiers, that fulfill the role of the validators mentioned in the quote above.
The mainchain bookkeepers can’t look at the other books (sidechains) but have to know when something that relates to their book is happening. Somebody needs to tell them and the way they are told needs to be standardized. Certifiers are the ones to tell the mainchain bookkeepers about incoming transactions, and the standardized way they are told is via the Cross-Chain Certificates.
Certifiers register on the mainchain via a special type of transaction, that includes the sidechain ID of the chain that they are registering for and a deposit that gets locked. This stake has a role in preventing fraud, but more about that in a minute. Every stakeholder on the mainchain is eligible to become a certifier. A subset of all certifiers verifies the backward transactions on the sidechain, collects them in the Backward Transfer List, signs the resulting CCCert with an aggregated signature and sends it to the mainchain.
Facilitating backward transactions is a form of work. There needs to be an incentive to do this work. Additionally, the incentive must be designed, so that honest behavior is encouraged and malicious behavior must not be profitable. On of the main objectives was to design the protocol in a way, that would decentralize the process of cross-chain verification.
Certifiers are incentivized through collecting the transaction fees of all transactions they are processing. If they submit fraudulent certificates they will not be able to unlock their stake. A group of certifiers that have a combined deposit X locked up on the mainchain is only allowed to sign a CCCert that has a combined total of 0.5X. This is called the maximum certificate amount (MAX_CERT_AMOUNT).
If the amount per certificate was not capped, it would be possible to lock up a deposit, sign a fraudulent CCCert worth more than the deposit itself, sending it to a self-controlled address on the mainchain and live happily with losing the stake.
Reporting Fraud
Enforcing this measure is based on the assumption of an honest majority. As you might have noticed there is a data field contained within the CCCert named Fraud Reports List. This field would be used the following way in case a fraud was to occur:
- A fraudulent certificate CCCert(i) is created privately and signed by the majority of certifiers in the group(i).
- It is then sent to the mainchain and included into a block(i) because the mainchain is not able to verify the certificate and detect the fraud itself.
- The fraudulent certificate is now synced back into the sidechain (see Full Referencing).
- The next group of certifiers(i+1) verify the previous CCCert(i) on the sidechain, detect the fraud and include a Fraud Report in their certificate CCCert(i+1).
- Ones the mainchain receives CCCert(i+1) containing the fraud report, the group of malicious certifiers(i) will not be able to unlock their deposit.
- If the group(i+1) does not include a fraud report, the group after them(i+2) will and both fraudulent groups from before (i and i+1) will lose their deposit.
By not reporting a detected fraud a group would risk losing their deposit, as well as the originally malicious group. It’s also important to note, that it is not possible by protocol design to have one certifier in a certifier group back-to-back.
The actual inner workings of a backward transfer are a little bit more complex, but if you care to learn about them in more detail I’ll advise you to have a look at the original source. (Whitepaper)
Lastly, to protect the mainchain from inflation should all else go wrong there is a last line of defense. The safeguard is a mechanism on the mainchain, which tracks the total amount of assets that have been transferred to each individual sidechain. It’s impossible to withdraw more coins from a sidechain than the amount that has been moved there in the first place, therefore preventing inflation.
Conclusion
I hope I managed to get the point across, of why sidechains could be an elegant way to overcome current limitations regarding scalability and governance in the blockchain ecosystem. The main contribution of the paper is providing a new backward transfer protocol that does not rely on a centralized group of validators. Every stakeholder is eligible to become a certifier if he likes to, introducing decentralization to the process of cross-chain verification.
From a security perspective, the most important thing is to design the implementation in a way, that no sidechain can possibly harm the mainchain.
Regarding the SCP the truly random assignment of slot leaders, liveness and persistence have to be guaranteed.
Regarding the CCT security is enforced by adding references to the mainchain with every block (full referencing), introducing a cap on the total amount a group of certifiers can sign for (MAX_CERT_AMOUNT) and the safeguard tracking the total amount that has been transferred to a given sidechain and can be withdrawn.
Having the ability to deploy sidechains will dramatically enhance the possibilities of building on top of existing public blockchains. There will be a lot of work from here, to actually having a first sidechain deployed on the Horizen main-net. This includes rigorous security testing and further evaluation of the sidechain consensus protocol.
As I mentioned earlier one of the first use-cases of a sidechain for the Horizen project will most likely be a sidechain facilitating the Treasury, moving the project a step closer to becoming a truly decentralized autonomous organization. If you want to know what the Horizen project is all about you can go check out their website here.
As I am only getting started with writing about technical innovations in the blockchain sphere please feel free to leave any feedback or criticism. If you like what you have found here and would like me to cover another topic that is of interest to you, please leave a comment and maybe even a clap or two. I appreciate every new follower on Medium and Twitter.
I’d like to thank the Coinmonks publication for giving me a platform for increased exposure and the team around Alberto for giving me access to the whitepaper pre-release.
See you guys,
Jonas Rubel
