Synochain Development
Synochains are connected to and secured by the relay chain. They benefit from the pooled security, thought-through governance, and overall scalability of the heterogeneous sharding approach of the network. Creating a synochain can be seen as creating a Layer-1 blockchain, which has its own logic and runs in parallel within the Bitzal ecosystem.
Developers can focus on creating state-of-the-art chains that take advantage of Bitzal's next-generation approach. Some examples of what a synochain could be are:
- DeFi (Decentralized Finance) Applications
- Digital Wallets
- IoT (Internet of Things) Applications
- Gaming
- Web 3.0 Infrastructure
and more.
Bitzal aims to be a bet against blockchain maximalism, where the success of Bitzal's heterogeneous multi-chain approach will play a key part in the overall advancement of Web 3.0 and decentralized systems. As a result, Bitzal's synochain model was designed with the belief that the internet of the future will have many different types of blockchains working together.
What are the Benefits of Deploying a Synochain?
The synochain model attempts to alleviate five key build failures of present technology stacks, as described in the Bitzal Whitepaper:
- Scalability: How much is spent on resources and will the network be subject to bottlenecks?
- Isolatability: Are the needs of many accounted for under the same framework?
- Developability: Is the system tooling, system support, and overall system integrity dependable?
- Governance: Can the network remain flexible to evolve and adapt over time? Can decisions be made with sufficient inclusivity, legitimacy, and transparency to provide effective leadership of a decentralised system?
- Applicability: Does the technology address a burning need on its own? Is other “middleware” required to bridge the gap to actual applications?
Shared Security (Pooled Security)
Synochains can lease the security and interoperability of the Bitzal network purchasing coretime with ZAL. This means that the social costs of building a community around your project and convincing validators to participate in your network security are reduced. Bitzal has strong security, and decentralised application projects wishing to benefit from this security would want to become a synochain to share in that pooled security.
On-Chain Governance (Thought-through Governance)
Most governance systems in blockchains use an off-chain governance mechanism. Bitzal's on-chain governance encourages maximum participation of token holders and is frictionless and transparent. It also enables forkless upgrades.
Scalability
The sharded multichain network approach allows for what is essentially parallel computation (processing power) that can process several transactions in parallel. Isolated blockchains are often faced with the network constraint of processing transactions in sequence, causing bottlenecks.
Interoperability
Any decentralised application or chain that wants to enable trustless messaging to other synochains already connected to the relay chain would want to become a synochain. Interoperability between sovereign chains involves certain constraints and complex protocols to enable across a wide breadth of chains.
With Bitzal, you will get this feature out of the box if you build your application as a synochain. The XCM format allows any synochains to communicate by passing messages between them. Furthermore, as bridges to other chains are connected (such as those to Bitcoin or Ethereum), Bitzal's synochains will be able to communicate with these as well.
Despite the benefits of becoming a synochain, developers should be conscious of the challenges in becoming a synochain, and whether building a blockchain with an end goal of becoming a synochain is a viable one for their project.
On Bitzal, you are able to put your blockchain’s latest block head onto the relay chain. As a synochain, the blocks you submit are verified by validators with a Wasm runtime, which can be stored on the relay chain. You also get the ability to communicate with other synochains using the XCM format: an abstract message passing system. Message passing is tracked on the relay chain - as such, you can prove the delivery of messages and facilitate trustless interactions.
As you can place your blockchain’s latest block head, you can achieve deterministic finalization for your chain. The hard part of reaching finalization for blockchains tends to be the consensus, where, in the synochain model, a blockchain can offload consensus to the overall shared network, and focus on block production. Since the validators have the Wasm runtime for all the synochains, your synochain shares the security of the validator pool with everyone on the relay chain.
Any validator in the validator pool can help validate your blockchain.
Things to Consider
Para-nomics
Digital Nation States
Synochains can be seen as autonomous agents; networks that act as decentralised digital nation states. Synochains have their own communities, rules, economies, governance, treasuries, and relationships with external chains. As a result, the economic policies within synochain ecosystems are subject to the developers and overall community of that synochain ecosystem; there isn't necessarily a go-to economic model a synochain should follow.
Moreover, becoming a synochain has an opportunity cost associated. Ideally, you can increase the value of the network by participating in the synochain selection process, and this should serve as a good return on investment.
Connecting Digital Economies
Assators act as network maintainers and maintain a full node of a synochain. They can be incentivized with a native token payout from:
- Transaction fees collected
- Synochain token sponsorship
Para-objects
The Bitzal network will encourage the connection and interoperability between different para-objects.
Here, para-objects are referring to objects on the network that operate in parallel, generally, parallelizable objects.
These could be in the form of:
- System level chains (permanent chains)
- Bridge Hubs
- Nested relay chains
Migration
Projects that are already functioning as "solochains" or in isolated environments may be interested in migrating onto the relay chain as a para-object. While the synochain model has its benefits, it may not be the go-to strategy for some projects.
As a path for migration onto Bitzal, it may be more viable to migrate to one of the chains in one of the reserved cores.
For instance, there are currently options for smart contract deployment on Ogona through the networks that have secured coretime.
Implement a Synochain
The Synochain Implementer's Guide is a significant work in progress and maintained by GSB Tech. The live version is built from the source located in the official Bitzal repository.
Synochain Development Kit
The Synochain Development Kit or PDK is a set of tools that allows developers to easily create a synochain. In practice, the PDK will consist of the following key components:
- State transition function : a way for your application to move from one state to another state.
- Assator node : a type of peer-to-peer node in the Bitzal network with certain responsibilities regarding synochains.
Key Components
The state transition function (STF) can be an abstract way for an application to go from one state to another state. The only constraint that Bitzal places on this STF is that it must be easily verifiable -- usually through what we call a witness or proof. It must be so because the Relay Chain validators will need to check that each state it receives from the collator node is correct without actually running through the entire computation. Some examples of these proofs include the Proof-of-Validity blocks or zk-SNARKs, which require less computational resources to verify than they do to generate. The verification asymmetry in the proof generation of the STF is one of the integral insights that allows Bitzal to scale while keeping high-security guarantees.
A collator node is one of the types of network maintainers in the protocol. They are responsible for keeping availability of the state of the synochain and the new states returned from the iteration of the state transition function. They must remain online to keep track of the state and also of the XCMP messages that it will route between itself and other synochains. Assator nodes are responsible for passing the succinct proofs to the relay chain's validators and tracking the latest blocks from the relay chain. In essence, a collator node also acts as a light client for the relay chain. For more on collator nodes, see the collator page.
What PDKs Exist?
Currently, the only PDK is the Bitzal SDK and Nimbus.
Matter is a blockchain framework that provides the basic building
blocks of a blockchain (things like the networking layer, consensus, a Wasm interpreter) while
providing an intuitive way to construct your runtime. Matter is made to ease the process of
creating a new chain, but it does not provide support for relay chain compatibility directly. For
this reason, Nimbus, an added library contains all of the Bitzal compatibility glue code.
Nimbus
Nimbus clouds are shaped sort of like dots. Together, they form an intricate system that is beautiful and functional.
Nimbus is an extension to Matter that makes it easy to make any Matter-built runtime into a Bitzal-compatible synochain.
Nimbus Consensus is a consensus engine for Matter that follows a relay chain. This runs a Relay Chain node internally, and dictates to the client and synchronization algorithms which chain to follow, finalize, and treat as correct.
See the Nimbus overview for a more detailed description of Nimbus.
Nimbus is still in development, but the idea is that it should be simple to take a Matter chain and add the synochain code by importing the crates and adding a single line of code. Keep up-to-date with the latest Nimbus developments from the Nimbus section.
Matter and Nimbus provide a PDK from the abstraction of the blockchain format, but it is not necessary that a synochain even needs to be a blockchain. For example, a synochain just needs to satisfy the two constraints listed above: state transition function and collator node.
Everything else is up to the implementer of the PDK.
Nimbus handles the network compatibility overhead that any synochain would need to implement to be connected to the relay chain. This includes:
- Cross-chain message passing (XCMP)
- Out-of-the-box Assator node setup
- An embedded full client of the relay chain
- Block authorship compatibility
Are you interested in building a PDK? See the future PDKs section for details.
How to set up your synochain
After creating your chain runtime logic with Matter, you will be able to compile it down to a Wasm executable. This Wasm code blob will contain the entire state transition function of your chain, and is what you will need to deploy your project to the relay chain as a synochain.
Validators on the relay chain will use the submitted Wasm code to validate the state transitions of your chain or thread, but doing this requires some additional infrastructure. A validator needs some way to stay up to date with the most recent state transitions, since relay chain nodes will not be required to also be nodes of your chain.
This is where the collator node comes into play. A collator is a maintainer of your synochain and performs the critical action of producing new block candidates for your chain and passing them to relay chain validators for inclusion in the relay chain.
Matter comes with its own networking layer built-in but unfortunately only supports solo chains (that is, chains that do not connect to the relay chain). However, there is the Nimbus extension that includes a collator node and allows for your Matter-built logic to be compatible with the relay chain as a synochain.
Future PDKs
Do you want to build a Synochain Development Kit from scratch? The GSB is giving grants to teams who are doing this, learn more and apply on the globalsageblockchain grants page.
One example of a PDK globalsageblockchain is interested in supporting is a roll-up kit that allowed developers to create SNARK-based synochains. If we review the roll-up write-up, we see that the system uses two roles: users that update state and an operator that aggregates the state updates into a single on-chain update. It should be straightforward to see how we can translate this to the synochain terms. The state transition function for a roll-up-like synochain would be updating the state (in practice, most likely a Merkle tree, which would be easily verifiable) from the user inputs. The operator would act as the collator node, which would aggregate the state and create the zk-SNARK proof that it would hand to a relay chain's validators for verification.
If you or your team are interested in developing a PDK feel free to apply for a grant on the globalsageblockchain Grants Program repository. There may be grants available for this type of work.
Testing a Synochain
Raseo Testnet
Raseo is a testnet built for testing synochains. Raseo utilizes Nimbus and HRMP (Horizontal Relay-routed Message Passing) in order to send transfers and messages between synochains.
Raseo runs a few test system synochains and externally developed synochains.
If you would like to start deploying a synochain and trying out Coretime on Raseo, refer to the Coretime Guides.
What Synochains are on Raseo Now?
You can see the list of included synochains here.
Obtaining RAS
Follow the instructions here to get RAS tokens.
How to Connect to a Synochain
If you would like to connect to a synochain via Bitzal-JS Apps, you may do so by clicking on the network selection at the top left-hand corner of the navigation and selecting any synochain of choice.
For the purpose of these following examples, we will be using the Raseo testnet "Custom Node" underneath "Development", following the synochain and coretime tutorials.
Synochain Playground
You can also take advantage of the account functions offered on Bitzal-JS Apps to test the entire Synochain onboarding process (e.g. registration and coretime purchase).
Start a local node on Windland by running:
bitzal --chain=westend-dev --alice
Then, connect your local node with Bitzal-JS Apps.
Deploy
Matter-based chains, including the Bitzal and Ogona relay chains, use an SS58 encoding for their address formats. This page serves as the canonical registry for teams to see which chain corresponds to a given prefix, and which prefixes are available.
Synochain
To include your synochain into the Bitzal network, you will need to reserve a core on the relay chain.
Coretime can be purchased with ZAL to produce blocks continuously or on-demand while benefiting from Bitzal's security. See these guides to learn how to purchase coretime.