Blockchain Products For Enterprise: Credits SubChain

Card image cap
Wednesday, February 27, 2019

Blockchain Products For Enterprise: Credits SubChain


Today, increasingly more modifications appear in modern ecosystem of blockchain. As a rule, we term these modifications “SubChain”, which literally means a dependent chain.

SubChain is a blockchain. Generally, it’s a separate chain with all of the specific features and principles as well as with its own types of data in its own chain of blocks with dependence on the MainChain. This dependence is represented by an addition of each subchain block hash into a block of main - chain in order to provide additional guarantee of SubChain’s data integrity in case of a vulnerability in SubChain.

Usually, a large public platform proven by time (such as Credits) is chosen as a MainChain. There are also additional requirements to a SubChain such as high performance and low fees. Moreover, SubChain can run on a relatively small number of nodes. These additional requirements can lead to an increase in levels of potential vulnerabilities in data integrity. It is compensated by an additional functionality, called anchoring: hash of the whole system is recorded to the public blockchain periodically. If blockchain data is altered, the system’s hash won’t match the one stored in the public chain, which will be a signal that the data integrity was compromised.


For better understanding we’d like to use the following terminology:

MainChain – a public blockchain which is used to record a set of data from private blockchain.
SubChain – a private blockchain that is connected to and synchronized with a public blockchain.

Prerequisites to create a SubChain

A need to combine private blockchain with public one for an additional layer of data protection is a prerequisite for SubChain’s creation.

Since public blockchain implies public storage of data, it’s not always appropriate to use it when there’s a need to restrict data access for third parties. In this case, a private blockchain deployed on the servers of interacting parties is utilized. However, there’s a number of cases, when confirmation of data integrity in a private blockchain occurs via its recording to the public blockchain in an encrypted form. For example, private chain hashes its full data (e.g. passport data) and the calculated hash is recorded to the public blockchain. It’s also possible to store other data of a private blockchain in a public one (time, day, location and etc.). Thus, the status of a private blockchain is being recorded into the public, which confirms the validity of its data.

Mechanism of interaction

In order to provide such a combination of blockchains, a mechanism of interaction, described below, was implemented.

Thanks to this mechanism synchronization of the chains occurs with preset intervals, which preserves the necessity of data validation by a public blockchain. Synchronization is implemented as an infinite cycle with the ability to stop and continue the synchronization process from the stop-point in case of an error in data validation/forced stop of the private blockchain recording/loss of connection and etc.

Blockchains are synchronized as follows:

1. SubChain sends a request for synchronization to MainChain. In addition, it sends the following set of data along with the request:

a) Identifier of the synchronized block of a SubChain (h13).

b) Identifier of the block, which was synchronized in the last iteration (previous block) (h11). In case, this is the first synchronization cycle, only the identifier of a genesis-block is sent (first block of the chain) (h01).

c) In case, the MainChain synchronizes with several SubChains, an identifier of the genesis-block is always sent with the request in order to determine the SubChain that is requesting the synchronization.

2. Once MainChain obtains the data, it verifies it by means of comparing it with the previously synchronized data. In order to do that, MainChain can request full blockchain data from a SubChain and compare it with the data, stored in the last successfully synchronized block of MainChain, which contains the data from SubChain.

3. Once the data is successfully verified, MainChain sends the information containing the identifier of the block, in which the data from SubChain was recorded, to that SubChain.

Figure 1 shows the synchronization process

For the correct system performance, there’s a need for the modification of its transactions by means of including the transaction fields, related to storing of the data, which is exchanged between public blockchain and a private one.

  • Field for information about the block in MainChain, which recorded previously synchronized SubChain’s block
  • Field for information about the block in Subchain, which requires synchronization
  • Field for information, which will be recorded in the MainChain.

It should be noted that the division of the blockchains into a MainChain and SubChain is conditional and made in order to simplify the description of the solution. In fact, public chain and private chains connected to the public one in represented way are separate systems for storage of records and can freely function without synchronization. Thus, the solution describes the method, designed to synchronize two or more blockchains, which should be considered, while you are preparing the description and formula of the invention.


Technical result of this mechanism is an automatization of two or more blockchain systems’  processes of synchronization with each other and the process’ acceleration by means of excluding the necessity of recording full blockchain of a SubChain into MainChain.


twitter logo facebook logo reddit logo linkedin logo

This site uses cookies in order to improve your user experience and to provide content tailored specifically to your interests. Detailed information on the use of cookies on this website is provided in our Privacy Policy. By using this website, you consent to the use of cookies. You can always deactivate cookies in commonly used browsers.