Horizen Sidechains White Paper: Decoupled Consensus Between Chains
Horizen’s expansive roadmap requires a scalable solution. Our newest whitepaper outlines the development of Horizen’s secure, decentralized sidechains.
Projects based on Bitcoin’s source code, such as Horizen, inherit some of the Bitcoin protocol’s constraints. Most notably, the Bitcoin protocol has limited throughput, increased latency, and a reduced ability to scale and to introduce new functionalities. Horizen’s source code is based on the Bitcoin protocol, thus Bitcoin’s scaling limitation presents an issue to Horizen because we have an extensive roadmap with a variety of new functionalities, including a treasury system and decentralized node payment network. Implementing these new functionalities directly onto the mainchain may create security risks, slow the system, and would require significant modifications to the core client.
Sidechains are essentially a parallel chain with desired features that supplement the capabilities of the mainchain. For example, a system like Bitcoin that does not natively support smart contracts can be extended to incorporate smart contracts using a sidechain. In fact, any number of sidechains can be deployed with different features and properties, while the main blockchain remains untouched. Horizen’s sidechain model – differently from many others – is designed to be completely decentralized without the need to rely on pre-defined trusted parties.
The major benefits of our sidechain include:
- Scalability: The ability for the sidechain to be completely decoupled from the mainchain, so no modifications of the core client is required (except the initial implementation of the sidechains support that is done only once).
- Safety: Possible security impacts in the case of a faulty implementation of the sidechain functionalities are bounded inside the sidechain and are limited only to the sidechain balance in the mainchain.
- Decentralized: Sidechain can be run by untrusted nodes without the need of a central authority or trusted parties to validate cross chain transfer
- SDK: Unlimited software languages and protocols
Watch our Director of Engineering, Alberto, and Co-founder, Rob, explaining the Horizen sidechain model.
Horizen’s sidechain technology is unique.
We propose a novel sidechain construction tailored to be compatible with the Horizen blockchain and designed for conducting secure and decentralized cross-chain transfers without requiring the mainchain nodes to verify the sidechain.
This is truly novel because unlike other chains, our sidechain allows us to attract developers who wish to write an application in their preferred language or an enterprise business can use to take advantage of the mainchain’s functionality without having to build their own blockchain or coin while taking advantage of Horizen’s 22,000+ node architecture.
Requirements
In order to ensure our system’s integrity, we developed strict requirements for Horizen’s sidechains. The requirements are listed below.
- The mainchain should be agnostic to the sidechains. The mainchain nodes should not be required to track a sidechain.
- Unified cross-chain transfers. All sidechains should employ the same unified cross-chain transfer (CCT) protocol that is known by the mainchain.
- Flexibility to choose sidechain consensus protocol. Sidechain consensus protocol may be different from the one used by the mainchain.
- Parallel sidechains. The Horizen sidechains architecture shouldn’t restrict the number of simultaneously deployed sidechains.
- Fault tolerance. The mainchain should be fault tolerant to any sidechain failure (including malicious behavior).
- Minor changes in the core. The required modifications in the Horizen core should not be too pervasive.
Sidechains SDK. Our roadmap includes the development of out-of-the-box interfaces designed in a way that allows sidechain application developers to focus on application-specific logic, hiding the complexity of sidechains.
To learn more about Horizen’s novel sidechain approach, please download the whitepaper.