The Critical Thinking On The Cross-Chain Interaction And Consistent Status Of SimpleChain Beta
Author: Leo YU, the chief executive of SimpleChain Foundation and co-founder & CEO of Dataqin Tech. Co., Ltd, China.
The Myth On Blockchain Scalability Issues
Bitcoin is the first application of blockchain technology and consistently operated for years. It is one of the most trusted public chains for now, but the scalability issues showed up since it was proposed and still be the main focus through its development process. In fact, there is no such kind of thing called “the block limit” and the block size could be up to 32 MB according to bitcoin’s data structure, until Oct 1st, 2010 Satoshi made the 1MB block size clear in a code of commit. On Oct 3rd, two days after Satochi’s commit, Jeff Garzik published a patch to expand block size to 7MB. It would be the first hard fork if it was accepted by users. At that time, the average block data was only about several dozen KB. Satoshi advised not to use Jeff’s patch to keep bitcoin safe and stable as well. However, the transaction speed of 7 transactions per second has become the limitation of the bitcoin network with the increasing scale of hash rate and transaction data of each block, as well as on-chain transaction, became more active.
Jeff Garzik initiatived to remove the 1MB limitation and went back to 32MB through BIP 100 since 2015 when Bitcoin hash rate had broken through 1P at that time. Block miners are apparently more relevant to the block size: they would cost more computing resources in order to pack more transactions. So it never came to a consensus on the bitcoin scalability issues but resulted in forks such as BCH and BSV. Moreover, the block size cannot be infinitely expanded, so it is not the resolution to transaction speed problem.
Ethereum more or less has a similar issue to Bitcoin. Though the block size is not a constant such as 1MB, the gas limit structure and balance between miners’ benefit are obstacles to the transaction speed, which is 15 transactions per second. That is the reason causes the whole Ethereum network clogged by a huge number of “Crypto-Kitties” transactions together with all the other transactions in 2017, so as the time when ICO was popular.
In the exploration to settle this issue, different solutions were proposed. For example, the DPoS mechanism was put forward by projects such as Bitshares and EoS. The responsibility of data confirming and accounting on the main chain was taken by a group of nodes. It imitates the representative democracy to elect high-performance nodes but also causes the suspect of interest group and centralization. Bitcoin Lightning Network and Ethereum Raiden Network are two typical off- chain transaction solution.
Because Bitcoin uses UTXO while Ethereum based on account balance, it causes different off-chain transaction channel, such as Lightning Network and Raiden Network. But 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, the transaction of specific trading objects can be settled within a period of time by jointly locking a margin. As long as the trading volume does not exceed the margin amount, or there is no timeout, or no party chooses to terminate the transaction, the transaction will not need to be confirmed by the entire network, nor do they need to pay any fees to the blockchain main network. This makes the high-frequency but small scale transactions less depend on the block size or the transaction speed.
Multiple transit nodes will appear in the lightning network in order to match as many matching requirements as possible for high-frequency transactions. It is because lightning network requires the transaction is collected in the process of signature, so the involved parties need to be online in real time. All this seems to show that the centralized exchange is suitable for the role of the transit node. But also worries the community, whether it will eventually make high-frequency small scale transactions more central and compromise on security.
No matter how Lightning Network and Raiden Network has led the solution of the expansion problem to the second layer beside the main chain. Layering the network of different needs and the main chain network has become a trend to the scalability issue.
The Main / Sub Chain Structure & Fragmentation
Data fragmentation, originated from the database structure, increases the efficiency and fault tolerance of the overall database by classifying backups and data redundancy. In a distributed database, different segment mechanisms are established to meet the various requirements of the business system. In the blockchain area, the two-layer solution settles the scalability issue by classifying the different requirements of business and distributing them in different sub chain.
However, there is a significant difference between blockchain and distributed database. The functions such as add, remove, edit and research as well as account data in the distributed database comes from the business system or centralized data managing system. Each node of the distributed database only needs to response data administrator (DBA). On the contrary, nodes in blockchain are responsible for business logic, data account, and data management. That is each node can be seen as DBA or you can say there is no “DBA”, which results in a more complicated design.
Since the transaction of the distributed database is controlled by the central system, the fragmentation is purely for storage. But the fragmentation of the blockchain can be divided into transaction fragments and state fragments. The design of transaction fragments is relatively simple: that is, the network nodes synchronized data while the fragments are only used to allow different nodes to run different arithmetic logic; the more complex state slices are designed to contain both transaction and storage partitions. In a narrow sense, state fragmentation is actually a variety of forks. Different forked chains deal with transactions and store ledger data of their own. These chains can be traced back to the block before the fork occurs, and the history block validity is verified by snapshots. However, this type of fragmentation does not add much real value because there is no mechanism design for cross-chip interaction.
The cross-chip transactions of state fragments will solve the problem to confirm the transaction efficiency between different fragments, which is ensured by nodes in fragments to make a consensus. Therefore, in the design of SimpleChain, the cross-chip trading problem is understood as a problem of cross-chain trading, and the shard is defined as a sub chain.
Forming Cross-chain Transactions
Since cross transactions between sub chain come from users whose ledger 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. That is, the Merkle proof is completed by the blockhead synchronized with each other to verify the validity of the information transmitted by the constructed “object”. We call this object a receipt.
Cross-chain transaction confirmation based on “receipt” (Ethereum wiki)
Above image illustrates the process that user A in blockchain X transmitting 100 unit asset to user C in blockchain Y.
1) This process is started by a transaction and a receipt numbered 154016 formed, while 100 unit assets of A’s account in blockchain X is deducted.
2) Then this receipt is sent to blockchain Y and the information effectiveness contained in this receipt can be confirmed by Merkle proof. That is, whether the first transaction is confirmed in blockchain X and whether 100 unit assets of A’s account is deducted.
3) After the information effectiveness is confirmed, user C from blockchain Y will transmit a transaction containing Merkle proof of receipt numbered 154016 to blockchain X, which can be considered as a return receipt. Meanwhile, the 100 unit assets will be added to C’s account.
4) When obtain this receipt, blockchain X will destroy the previous one. At the same time, the blockchain Y will destroy the receipt 154016 and then the cross-chain transaction is completed. Blockchain X and Y can keep the receipt to confirm the cross-chain transaction later on.
In order to ensure the effectiveness of the above mechanism, we also need to consider the final problem in cross-chain transactions, or the fork selection mechanism. The transaction from blockchain X verified by the blockchain Y must come from the active chain, rather than from an orphan block or an orphan chain. Vlad Zamfir has once proposed a design of merge blocks: when a chain initiates a cross-chain transaction, two blocks on different chains are merged into one, and two chains will extend separately based on this merge block after then. Though merging blocks cannot solve the problem of independence issue between two shards or two chains, because the ledger data of the two chains are synchronized. But it provides the idea of how to find the correct block of the other chain to complete the receipt of the Merkel proof in cross-chain transaction.
In Vlad’s design, the two chains involved in cross-chain transactions need to be ranked first and divided into “parent chain” and “sub chain”. The block height of sub chain should be the same as or higher than parent chain when merging the block or in our case, confirm the cross-chain transaction on parent chain. This will ensure cross-chain data of two blockchain are continually consistent during extensions of their own.
However, the above solution works under the condition that two blockchains generate the block simultaneously. Because if the transaction of parent chain X cannot be confirmed in time or the chain is not expanded, or sub chain Y does not receive the updated data from chain X, or two chains have interrupted synchronization, the efficiency of the future transaction of sub chain Y will be influenced.
The picture above shows the case when two shards or chains both have forks. If A-B chain in shard 1 and V’-X’-Y’-Z’ in shard 2 confirmed to be main chain, then the cross-chain transaction is successfully completed. When A’-B’-C’-D’ in shard 1 and V-X shard 2 become the main chain, then this transaction is invalid. But if two other cases happen, then there is an atomic fault, which means transaction is confirmed in one shard but invalid in another one. The asynchronism of two segments or chains makes it hard to figure out which chain is the main chain when initiating a cross-chain transaction, thus causing such kind of problem. Therefore, cross-chain transactions between slices or sub chain require an intermediator for coordination.
In Ethereum 2.0, Beacon Chain has become the intermediator. Beacon Chain can be considered as the main chain of all the shard chains. This main chain uses the Casper consensus mechanism to randomly generate segment verifiers in each round of elections to ensure the correctness of transactions between shards. However, Casper uses the PoS consensus mechanism, which is different from the PoW mechanism. There are no difficulty requirements, nonce, block hashes that can do SPV certification. Thus verifying the fragmentation chain becomes complicated. It is necessary to go back to the trusted verified block, and then recalculate the block after this block until it is consistent with the current block to complete the verification. Therefore, in SimpleChain, in order to reduce the workload of the verifier, the role of the Beacon chain is done by the main chain using PoW.
The anchor miner in the main chain will accomplish three different functions. They are responsible for verifying the sub chain when it initiates a cross-chain transaction, writing and broadcasting confirmations of sub-chain transactions into the main chain, and make sure that the cross-chain transactions confirmed in the main chain are respectively written into the sub chain that initiated and accepted them.
An anchor miner is both sub chain miner and main chain miner when verify, broadcast, and delivery of cross-chain transactions. However, the number of miners on the main chain is larger than it on sub chain, so the cost of forging transactions in the sub chain and write them to the main chain will be much lower than the main chain forgery transactions. Therefore, a more reasonable mechanism for selecting anchor miners is needed.
Anchor miners will continually be main chain miner rather than be a miner for any particular sub chain. SimpleChain will choose anchor miners through random selection since its main chain bases on PoW and uses stateless SPV proofs.
The upper limit of the number of anchor miners to verify a cross-chain transaction = Min [(the number of miners in the whole network / the number of sub chain) * 3, the number of miners in the whole network]
We can select the anchor miner from main chain miners. Firstly, arranging the value of Proof of Work calculated by the main chain miners from small to large. Because the smaller the value is the lower the probability it has, thus the anchor miner with small value will be ranked high in the list. Those miners ranked higher than the upper limit of the number of anchor miners will not participate in in the current round of transaction verification. The election process of sorting PoW value is synchronized with the main chain extension. So the main chain miners will not only gain SIPC from the main chain but also obtain a reward for anchor miners, which is the transaction fee offered by the cross-chain transaction initiators.
The acknowledgment mechanism needs N blocks to ensure the consistency of the main chain and sub chain. When a cross-chain transaction is initiated, the sub chain should obtain N block height before it is verified by the anchor miner and broadcast to the main chain. After confirming N block height of the main chain, the confirmed transaction will be written into the two sub-chains involved in the cross-chain transaction.
The height of blocks that needs to be confirmed before the verification is proportional to the value of the cross-chain transactions and the data volume. That is, the higher the value of the transaction, the larger of the confirmations required in both the sub chain and the main chain. The confirmation block number N of the main chain is constant just like it is in Bitcoin. Since the average time of a block to generate is 12 seconds, so block height N is set 15 blocks in the main chain and it will be as secure as it is in Bitcoin with 6 confirmation blocks. Sub chain will base on the 15 confirmation blocks of the main chain with confirmation blocks N dynamically adjusted according to the value and data volume of the cross-chain transaction.
Economics Of A Stable Main & Sub Chain Structure
A minor inflation mechanism of original digital asset SIPC is proposed in SimpleChain white-paper version 1.0. It illustrates that with the increasing number and activity of sub chain, as well as the requirement of cross-chain transactions, the block reward will be fine-tuned based on the initial attenuation curve. It is showed in the above figure that the green dotted line shifted to the black solid line. Thus the block reward of the main chain will increase when the requirement of SIPC from sub chain rise. In this case, the block reward might go up from 20 SIPC to 21 SIPC.
This makes the sub chain and the main chain have a solid relationship. A cross-chain transaction process is showed as follow:
(1) Users on sub chain initiate cross-chain transactions and pay the transaction fee which contains both Token (T) of the sub chain and SIPC (S) of the main chain.
(2) Sub chain miners or nodes verify transactions to accomplish the consensus process and charge a part of Token (t1) as transaction fee.
(3) The elected cross-chain miners obtain the left part of Token (t2), the total number of SIPC (S) and part of SIPC in funding pool (s2) as a transaction fee to complete anchoring and broadcasting of cross-chain transactions.
(4) The main chain miner gain SIPC (S’) as the transaction fee when they packing the cross-chain transactions.
(5) Miners on another sub chain read data of cross-chain transactions in the main chain and broadcast them to the target sub-chain.
The sub chain Token T equals to t1 plus t2 in the above process, while the main chain miners usually gain S’ as transaction fee which equals to R plus k. R is the original block reward of the main chain, that is 20 SIPC when k is the reward come from the minor inflation.
The funding pool mentioned above is a resource pool injected into the sub chain by the node in the form of a SIPC mortgage. In a cross-chain transaction, the SIPC in this funding pool will be partially used as a reward and offered to the anchor miners.
Assume that the initial funding pool capacity is 10SIPC and 0.1 SIPC of this pool will be given to cross-chain miner as a reward in each cross-chain process. After a transaction, the funding pool capacity is declined to 9.9 SIPC. At this time, the transaction fee charged by the main chain miner is S’=20+0.01, where 0.01 SIPC is the micro-inflation adjustment award.
The funding pool can get SIPC injection directly from the SimpleChain users or cross-chain fees may also be deposited into this pool. The latter will be triggered by the low activity of sub chain, and the s2 obtained by the cross-chain miners will be negative by changing the cross-chain miner reward. At this time, part of the cross-chain fee is stored in the sub-chain funding pool. The micro-inflation adjustment reward k charged by the main chain miner will be 0 or turn negative. It shows that the sub chain is inactivity and during a downturn, and the sub chain and the main chain will gradually break away from each other by reducing incentives.
Potential Risks And Other Discussion
There are some issues need to be further investigated in the above discussion. For example, the upper limit of the transactions volume involved in cross-chain transactions in the main chain block, and the problem of too many anchor miners may cause excessive load on the main chain.
What’s more, there is a possibility of “dog in the manger”. That is, a user may create an attenuation sub-chain and influence the interests of the main chain miners and users.
References
[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]
