Cross-chain interaction and continuous steady state thinking based on the main chain structure of the main sub-chain structure

1. Blockchain expansion puzzle

As the first blockchain to apply and run the most trusted public chain so far, Bitcoin continues to be the focus of the entire chain. In fact, there is no clear block ceiling between the day when Bitcoin appeared on January 4, 2009 and October 1, 2010. According to the data structure of the Bitcoin blockchain block, the data structure can reach up to 32M. capacity. In a commit on October 1, 2010, Nakamoto first explicitly defined the block limit of 1M in the code. On October 3, Jeff Garzik released the block ceiling to 7M. The patch became the first hard fork attempt. Of course, this patch is not used by users, and the average block data volume at that time is only a few tens of k. Nakamoto said at the time that in order to ensure the security and stability of the bitcoin system, it is recommended not to use the release of Jeff Garzik. patch.

As the scale of the Bitcoin network continues to expand, the chain transactions become more active, and the amount of data in the block is gradually increasing, so the trend of 7 transactions per second becomes the bottleneck.

Chart 1 Bitcoin blockchain history size (BitinfoCharts.com)

• "Zombie coin" resurrection, "model" value is difficult to see
• IBM applies for a new blockchain patent to manage autonomous vehicle data and human-car interaction
• The gambler's bitcoin carnival: the world financial situation changes, and bitcoin is a future pass

Since 2015, Jeff Garzik has once again proposed to remove the 1MB limit through the BIP100 and return to the earliest 32MB. At this time, the bitcoin computing power has already broken through the 1P scale boundary, and the stakeholders are more than the average payment users. It is a miner. However, for miners, packaging more transactions means consuming more resources. Therefore, the expansion of the Bitcoin blockchain block has never really reached a consensus, followed by BCH, BSV, etc. Bifurcation. The problem of infinitely amplifying the block capacity limit to solve the transaction processing speed is obviously only a matter of expediency.

A similar problem persists in Ethereum. Although its block size is not limited by a constant like Bitcoin, the balance of gaslimit as the upper limit and the balance of miners' interests also limits the transaction processing speed of Ethereum, so that the second processing speed is about 15 strokes. . Therefore, when the ICO's prevailing 2017 and games like the Ethereum exploded, the entire Ethereum network would be in a state of collapse.

In the process of the main chain expansion is difficult to break, on the one hand, the responsibility for verifying and calculating the main chain blockchain data is only solved by a group of high-performance nodes. The DPoS mechanism of bit shares, EoS, etc. is passed. This way is achieved. Such solutions elect high-performance nodes by simulating the reality of the parliamentary system, which inevitably raises doubts about interest groups and centralization trends. In addition, there are attempts to solve such problems through chain transactions, in which Bitcoin's Lightning Network and Ethereum's lightning network are two typical examples.

Due to the difference between the blockchain model of Bitcoin UTXO and the Ethereum based account balance model, there are differences between the lightning network and the lightning network in the specific protocol design of the chain trading channel. However, there is a common logic between the two, which is to open up trading channels for specific trading objects outside the main chain. That is to say, a specific trading object can be used to settle the transaction within a specific time interval by jointly locking a margin, as long as the two or more trading results do not exceed the margin amount, or there is no timeout, or no party chooses to terminate the transaction. Channels, two-way or multi-party transactions do not need to be confirmed to the entire network broadcast, nor do they need to pay any fees to the blockchain main network. This makes high-frequency small transactions no longer dependent on the size of the block or the block speed of the block.

Of course, in order to achieve as many matching requirements as possible for high-frequency transactions, multiple transit nodes will appear in the lightning network to match the parties to the transaction needs. It is also because the transaction process in the lightning network requires the collection link to be recovered by signature, so the transaction party needs to be online in real time, and from this logic, it seems that the centralized exchange is most suitable for the role of the transit node. This also worries the community, whether it will eventually make high-frequency micro-transactions more central and compromise on security.

Of course, no matter how, the design of lightning network and lightning network has led the solution of the expansion problem to the second layer outside the main chain, layering the network of different needs and the main chain network, and becoming a solution to the problem of scalability. A big trend.

2. The main sub-chain design and fragmentation concept

Fragmentation stems from the concept of database design, which increases the processing efficiency and fault tolerance of the overall database through classification backup and redundancy. In the distributed database, different fragmentation mechanisms are established to meet the different requirements of the business system. The Layer 2 solution for performance extensions in the blockchain also borrows this concept by classifying the different needs of the blockchain for different services and distributing them among different sub-chains. Thereby solving the performance bottleneck of the full chain consensus.

However, the big difference between the blockchain and the distributed database is that the addition, deletion, and calculation of the distributed database and the calculation are from the business system or the centralized data management system. The nodes of the distributed database are only responsible for responding to the data administrator (DBA). The business logic of the blockchain also comes from the fact that each node contains business logic, calculations, and management of at least the book-level data, that is, each node can be a DBA, or it is understood that there is no DBA at all, so It is more complicated in design.

Since the transaction logic of the distributed database is centrally controlled, its fragmentation can be regarded as a simple storage fragmentation. The fragmentation of the blockchain is mainly divided into relatively simple transaction fragments: that is, the full synchronization of the entire network node on the data is still maintained, and the different nodes are only operated by different operations logic; and the more difficult state Fragmentation: It also contains partitions for transactions and storage. In a narrow sense, the most intuitive state shards are actually various forks. Each of the different forks processes their own transactions and stores their own book data. When verifying the validity of the history block, you can choose to go back to the fork. The block before the occurrence, the snapshot is used to confirm the historical transaction. However, this type of fragmentation does not have much practical value because it has no mechanism for subsequent cross-chip interaction.

Then the cross-chip transaction of state fragmentation needs to be solved how to verify the validity of different intra-slice transactions. The effectiveness of intra-slice internal transactions is ensured by the nodes in the shards through the consensus mechanism. Therefore, in the design of a public chain, different shards also have the operating mechanism of the blockchain, so the cross-chip transaction problem The public chain is understood as a cross-chain transaction, and the fragmentation is defined as a sub-chain.

3. Formation of cross-chain transactions

Since cross-sub-chain transactions come from blockchain users whose two book data are inconsistent, a mechanism similar to SPV (Simple Payment Verification) can be realized by constructing an "object" that is not stored as a state in the ledger. The Merkel proof is completed by the block headers synchronized with each other to verify the validity of the information transmitted by the constructed "object". We can call this object a receipt.

Chart 2 Receipt-based cross-chain transaction confirmation (Ethereum wiki)

In the above diagram, a process of transmitting 100 units of assets from the user A in the blockchain X to the user C in the blockchain Y is shown.

(1) This process is initiated by generating a transaction and a receipt numbered 154016 and deducting 100 units of A from the ledger of blockchain X.

(2) After the receipt is sent to the blockchain Y, it can be verified by Merkel that the information contained in the receipt is correct, that is, whether the first transaction has been confirmed in the X blockchain, and whether A has been deducted. 100 units of assets.

(3) After obtaining the confirmation, User C sends a transaction containing the Merkel certificate for the receipt 154016 from the blockchain Y to the blockchain X, which can be regarded as a receipt and added to the C ledger. 100 unit assets.

(4) The blockchain X receives the receipt and destroys the previous receipt. At the same time, the blockchain Y also destroys the receipt 154016 in the subsequent block, and the cross-chain transaction is completed. Of course, the blockchains X and Y can also retain receipts for verifying the persistence of subsequent cross-chain transactions.

In order to ensure the continued effectiveness of the above mechanism, we also need to consider the final problem in cross-chain transactions, or the fork selection mechanism. The blockchain X transaction verified by the blockchain Y must come from the transaction in the block of the blockchain X active chain, rather than from a lone block or a lone chain. Vlad Zamfir proposed a design of a merged block, that is, when two chains need to initiate a cross-chain transaction, two blocks on different chains are merged into the same block, and the respective chains are extended based on the merged block. Block data. But in fact, merging blocks means that the books of the two chains are synchronized, so we don't think it can solve the problem of mutual independence between two shards or two chains. But in cross-chain trading, how to find the correct block of the other chain to complete the receipt of the Merkel proof can be found in the idea of ​​Vlad.

Vlad sorts the two chains that need to implement cross-chain, and divides them into "parent chain" and "sub-chain". The "sub-chain" needs to be the same height as the "parent chain" or higher than the height of the "parent chain". The block is merged with the "parent chain", or in our scenario is the block cross-chain verification on the "parent chain". This ensures that the two chains are consistently consistent across the chain during their respective extensions.

Figure 3 merge block mechanism (Vlad Zamfir)

However, in the above solution, there is a premise that two blockchains need to be synchronized out of the block, because if the transaction of the "parent chain" X is delayed, or is not extended, or the "subchain" Y does not receive the X in time. The extension of the situation, or the "sub-chain" and the "parent chain" are intermittently synchronized, then the subsequent transaction validity of the "sub-chain" Y will also be affected accordingly.

Figure 4 Non-synchronized cross-chain (cross-chip) transactions at the time of fork (Alexander Skidanov)

As can be seen from the above figure, if there are bifurcations in the two slices or chains, if AB in the slice 1 and V'-X'-Y'-Z' in the slice 2 are each confirmed as In the main chain, there is no problem in cross-chain or cross-chip trading, or A'-B'-C'-D' and VX become the main chain, then the cross-chip transaction will be invalid. But assuming the other two cases, there is an atomic failure, that is, the transaction is valid in one slice and the transaction is invalid in the other. This problem arises because of the asynchronous nature of the two shards or chains, which makes it impossible to determine the respective main chain determinities within the two chains when initiating a cross-chain transaction. Therefore, cross-chain transactions between segments or sub-chains require an intermediate consensus mechanism for coordination.

In the design of Ethereum 2.0, the beacon chain was given this function. The beacon chain can be considered as the main chain of all the fragment chains in the Ethereum 2.0 design. This main chain is elected by the Casper consensus mechanism and randomly generates a fragment verifier in each round to coordinate between the fragments. The correctness of the transaction. However, in the Casper consensus mechanism belonging to PoS, since there is no difficulty requirement, nonce, block hash, and the original non-state SPV proof in PoW, it is necessary to verify the validity of the slice chain back to the trusted area. After the block is recalculated, the status of the block after the trusted block is consistent to the current block to complete the verification. This has caused the certifier to increase the workload. Therefore, in the public chain adopting the main sub-chain structure, in order to reduce the workload of the verifier, the role of the beacon chain is completed by the main chain of the PoW.

There is a role of anchoring miners in the main chain. The so-called anchor miners assume three functional roles. 1. Responsible for verifying the validity of the sub-chain state when a sub-chain initiates a cross-chain transaction; 2. Responsible for writing in the main chain The sub-chain transaction is broadcast and confirmed; 3. The cross-chain transaction result intended to be confirmed by the main chain is written into the block of the transaction initiation sub-chain and the transaction reception sub-chain respectively.

Anchoring miners exist as both sub-chain miners and main chain miners in verifying, broadcasting, and delivering cross-chain transactions. However, the number of miners in the main chain will be greater than the number of miners in the sub-chain, so the cost of forging transactions in the sub-chain to the main chain will be much lower than the sub-chain in the main chain forgery transactions. Therefore, a more reasonable anchoring mechanism for anchoring miners is needed.

Figure 5 The probability of being a bad miner in the sub-chain will be higher than the main chain (Alexander Skidanov)

Anchoring miners do not target a long-term existence of a sub-chain, but it takes a long time as a main chain miner. Since the PoW's main chain can allow stateless SPV certification, we will complete the election of anchor miners in a random form in the public chain of the application's main sub-chain structure.

The upper limit of the number of anchor miners verified in a cross-chain transaction = Min [(the number of miners in the whole network / the number of sub-chains) * 3, the number of miners in the whole network]

Since the anchor miners are from the PoW main chain miners, the calculation results are verified by the workload calculated from the small to large main chain miners, and the anchor miners are screened. The smaller the value, the lower the probability that the calculation result is obtained, so the higher the ranking in the anchor miners pre-selected list, the miners who exceed the upper limit of the number of anchor miners do not participate in the current round of transaction verification. sign. The PoW sorting of the anchor miner's election process is synchronized with the PoW of the main chain extension, that is, the main chain miner will not only use the workload proof calculation result to obtain the main chain Token reward, but also obtain the anchor miner reward. The anchor miner rewards the miners' fees paid by the sponsors of the sub-chain cross-link transaction.

In the issue of ensuring the consistency of the main sub-chain, we have adopted n confirmation mechanisms. When a cross-chain transaction is initiated, the block within the sub-chain should first obtain n block-high acknowledgments before it can be anchored by the miner and broadcast to the main chain. After the high-level confirmation of the main chain n, the confirmed transaction status is written into the two sub-chains involved in the cross-link transaction.

The size of n is proportional to the amount of cross-chain transactions and the amount of data, that is, the higher the value of the transaction, the higher the number of confirmations required in the sub-chain and the main chain. In the current design, the main chain confirmation number n follows the constant setting idea of ​​Bitcoin. Since the main chain averages the block time of 12 seconds, the security of the main chain is set to 15 and its security will be close to Bitcoin 6. Confirmed time. The sub-chain confirmation number is dynamically adjusted based on the amount and amount of data of the cross-chain transaction based on the 15 confirmations of the main chain.

4. The economic design of the main sub-chain structure with steady steady state

Figure 6 Main sub-chain structure public chain project economic model

The public chain project based on the main sub-chain structure adopts the micro-inflation mechanism of the main chain digital resources, that is, as the sub-chain increases, the sub-chain activity increases, and the demand for cross-chain transactions increases, the block reward will be in the original A fine adjustment is made based on the attenuation curve (from the green dotted line to the black solid line in the above figure). The result of this fine-tuning is that when the main chain pass is used as a resource and the demand for the sub-chain is increased, the main block e-reward will increase accordingly. Taking the current state as an example, the main-chain ex-gratia reward may be 20 increased to 21.

The purpose of this design is to make the relationship between the sub-chain and the roles on the main chain more stable. The sub-chain's need for the main chain is to coordinate cross-chain transactions through the main chain. The process of a cross-chain transaction is:

(1) The sub-chain user initiates a cross-chain transaction and pays a commission, and the handling fee includes a sub-chain Token (T) and a main chain Token (S);

(2) The sub-chain miner or verification node completes the consensus verification and receives part of the sub-chain Token (t1) as a handling fee;

(3) The elected cross-chain miners collect the remaining sub-chain Token (t2) and all the main chain Token (S) in the handling fee and part of the Token (s2) in the operating pool as a fee to complete the cross-chain anchoring and broadcast;

(4) The general main chain miner charges the main chain transaction fee Token (S') packaged cross-chain transaction;

(5) Another sub-chain anchors the miner to read the cross-chain transactions in the main chain and broadcast them to the target sub-chain.

In the above process, T=t1+t2, however, the main chain miner charges the main chain transaction fee S'=R+k, R is the original main chain block reward, that is, the current 20Token, and k is the micro-inflation adjustment reward.

The concept of the operation pool appears on the above. The so-called operation pool is the startup resource that the node injects into the sub-chain through the form of the mortgage token when the sub-chain is initially created. The Token in the operation pool will be used as a partial reward in the cross-chain transaction. , output to anchor miners.

Suppose that the starting operation pool capacity of a data is 10Token. In the cross-chain process, each time 0.1Token is divided to give a cross-chain mine work as part of the cross-chain miner's reward. After a transaction, the operating pool capacity is reduced to 9.9 Token. At this time, the transaction fee charged by the main chain miner is S'=20+0.01, which is the micro-inflation adjustment reward.

The operation pool can be re-injected into the Token by any of the pass users, or the sub-chain consensus can trigger the lower limit of activity, and the cross-chain miner reward can be changed to make the s2 obtained by the cross-chain miner negative, that is, part of the cross-chain fee is deposited. Chain operation pool. At this point, the micro-inflation adjustment bonus k in the handling fee charged by the main chain miner will be 0 or turn negative. In this case, the sub-chain is going to decline, or the sub-chain and the main chain will gradually break away from each other by reducing mutual incentives.

5. Potential risks and later discussion

The technical risks that may exist in the above model include the problem of the upper limit of the volume of transactions in the main chain, including the cross-chain transactions, and the excessive burden on the main chain caused by the excessive anchoring of the miners.

In terms of economic models, there is the possibility of “damaging others”, that is, by creating an attenuation sub-chain, which affects the interests of the main chain miners and users.

6. R eferences

[1]. BitInforCharts (2019) Bitcoin Block Size historical chart, Available from: https://bitinfocharts.com/comparison/bitcoin-size.html [Accessed on 02/04/2019]

[2]. Buterin. V(2015) On Slow and Fast Block Times, Available from: https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/ [Accessed On 04/04/2019]

[3]. Buterin. V(2019) Merge blocks and synchronous cross-shard state execution, Available from: https://ethresear.ch/t/merge-blocks-and-synchronous-cross-shard-state-execution/1240 [Accessed on 03/04/2019]

[4]. Buterin. V(2019) How can we facilitate cross-shard communication?, Available from: https://github.com/ethereum/wiki/wiki/Sharding-FAQ#what-is-the-train-and -hotel-problem [ Accessed on 03/04/2019]

[5]. Prestwich. J(2019) What to expect when eths expecting, Chinese Version Translated by EthFans , Available from https://ethfans.org/posts/what-to-expect-when-eths-expecting [Accessed on 02 /04/2019]

[6]. Skidanov. A(2019) The authoritative guide to blockchain sharding part 1, Chinese Version Translated by EthFans , Available from: https://ethfans.org/posts/the-authoritative-guide-to-blockchain-sharding- Part-1 [Accessed on 02/04/2019]

[7]. Skidanov. A(2019) The authoritative guide to blockchain sharding part 2: Unsolved problems in blockchain sharding, Chinese Version Translated by EthFans , https://ethfans.org/posts/unsolved-problems-in-blockchain-sharding [Accessed on 02/04/2019]

[8]. Zamir. V(2018) Casper, Ethereum Community Conference on March 8-10,2018 , Available from: https://www.youtube.com/watch?v=GNGbd_RbrzE [Accessed on 03/04/2019]

(Source: Digital Qin Research Institute)

We will continue to update Blocking; if you have any questions or suggestions, please contact us!