Bitcoin is the first scenario to apply blockchain technology and is the most trusted public chain so far. The scalability has always been the focus throughout the development of this block chain. In fact, the bitcoin blockchain had no specific size limit between January 4, 2009 (the launch date of bitcoin) and October 1, 2010. During that period, the block size of the bitcoin blockchain was up to 32 MB. However, Satoshi Nakamoto explicitly limited the block size to 1 MB in code committed on October 1, 2010. On the third of October, Jeff Garzik published a patch that expanded the block size to 7 MB, the first attempt to implement a hard fork. This patch, however, was not widely used. At that time, the average block size was only tens of KB. Satoshi Nakamoto also recommended against using the patch released by Jeff Garzik to ensure the security and stability of the bitcoin system.
As the scale of the bitcoin network continues to expand, transactions on the blockchain become more frequent and the data volume in the blockchain also gradually increases. It becomes a more obvious performance bottleneck that only seven transactions are processed per second.
Figure 1: Development history of bitcoin block size (from BitinfoCharts.com)
Starting from 2015, Jeff Garzik proposed the removal of the 1 MB block size limit through BIP100 and changed the size limit back to the original size limit at 32 MB. However, the computing power of bitcoin had long exceeded 1 PB, and the majority of the interested parties were bitcoin miners instead of ordinary payment users. However, for miners, packaging more transactions means higher resource consumption. Therefore, a real consensus in block scaling in the bitcoin blockchain has never been reached. This leads to forks like BCH and BSV. Obviously, it is only an expediency to solve the transaction processing efficiency problem by infinitely increasing the block size.
Ethereum also has a similar problem. Unlike the bitcoin blockchain, the Ethereum block size is not a constant. However, the trade-off between the gaslimit and the interest of miners also limits the transaction processing speed in the Ethereum blockchain, and only about 15 transactions can be processed per second. That is why the entire Ethereum network was paralyzed by the accumulation of large amounts of transactions in 2017 when ICOs and games like CryptoKitties became prevalent.
During the challenging situation of main chain expansion, data validation and computation in main chains are handed over to a small group of high-performance nodes. For example, the DPoS mechanism of Bitshares and EOS is implemented in this manner. Solutions of this kind select high-performance nodes by simulating a parliamentary system in the real world, inevitably causing some conflicts between interested parties and the centralization trend. In addition, some have attempted to solve this kind of problem through off-chain transactions. Two typical solutions are the Bitcoin Lightning Network and the Ethereum Raiden Network.
The differences between the UTXO bitcoin blockchain model and the account-balance-based model in Ethereum lead to different protocol solutions for the off-chain transaction channels: the Lightning Network and the Raiden Network. However, the two different networks have the same common basic logic, that is, creating transaction channels for specific transaction objects outside main chains. That is to say, a deposit is jointly locked across specific transaction objects for transaction settlement in a specific time interval. It is not required to broadcast bilateral or multilateral transactions throughout the network for confirmation and pay any formality fee to the main blockchain network if the bilateral or multilateral transaction amount does not exceed the amount of the deposit, no time out occurs or neither or none of the parties chooses to terminate the transaction channels. This makes frequent and small transactions no longer dependent on block size and the block generation speed.
To meet as many requirements as possible for frequent transactions, the Lightning Network provides multiple intermediary nodes to meet requirements from individual transaction parties. In the Lightning Network, payments are required to be signed during the transaction process. Therefore, transaction parties need to be online in real time. From this perspective, a centralized exchange is most suitable as an intermediary node. However, it causes the community to be concerned about whether this will make frequent and small transactions increasingly centralized and lead to compromised security.
Anyway, the Lightning Network and the Raiden Network have diverted the solution for scalability to the second layer outside the main chain. The layering between networks for different needs and the main chain network becomes a major trend toward solving the scalability problem.
Sharding is a concept derived from the database field. In databases, sharding can improve efficiency and fault tolerance through classified backup and redundancy. In distributed databases, different sharding mechanisms are established to meet different requirements of the business system. The Layer 2 solution proposed to solve the blockchain scalability problem borrows the sharding concept to solve the consensus performance bottlenecks on the whole chain by classifying the different blockchain requirements of different services and assigning requirements into different sub-chains.
However, blockchains and distributed databases have a major difference: Addition, deletion, modification, query, and computing in distributed databases are from the service system or centralized data management systems and individual nodes in distributed databases are only responsible for responding to database administrators (DBAs). The business logic on blockchains also come from individual nodes, which are responsible for business logic and computations as well as the management of data at least at the ledger level. That is to say, each node in a blockchain can be considered a DBA or no DBAs exist in a blockchain at all. Therefore, the blockchain design is more complex.
Because the transaction logic in distributed databases is centralized, a shard can be considered a simple storage shard. Shards in blockchain mainly include relatively simple transactions shards and more difficult state shards. The former shard type ensures that data is still fully synchronized across nodes throughout the network and that only shards are used to have different business logic run on different nodes. The latter type of shards include both transaction shards and storage shards. In a narrow sense, the most typical state shards are forks. Each chain of forks processes its own transactions and stores its own ledger data. When we want to verify the validity of historical blocks, we can backtrack to blocks before the forking happened and confirm historical transactions through snapshots. However, because no cross-shard interaction mechanisms are available for shards of this type, this shard type does not improve much practical significance.
For cross-shard transactions, state shards need to find a solution to verify the validity of transactions in different shards. The validity of transactions in shards is ensured by nodes in shards through the consensus mechanism. Therefore, in SimpleChain, the operation mechanism also exists in different shards. The cross-shard transaction problem is considered a cross-chain transaction in SimpleChain and shards are defined as sub-chains.
Because cross-chain transactions happen between two blockchain users with inconsistent ledger data, we can create an "object" that is stored in the ledger not as a state to implement a mechanism similar to SPV (Simplified Payment Verification), which can verify the validity of the created "object" through a Merkle tree by using mutually synchronized block headers. We can call this object a receipt.
Figure 2: Receipt-based cross-chain transaction verification (from Ethereum wiki)
In the preceding figure, User A in Blockchain X sends 100 units of assets to User C in Blockchain Y.
(1) A transaction and a receipt numbered 154016 are generated first and 100 asset units is deducted from the ledger of User A in Blockchain X.
(2) After the receipt is sent to Blockchain Y, a Merkle tree is used to verify if the information included in that receipt is correct (that is, if the first transaction has been confirmed in Blockchain X and if 100 asset units has been deducted from User A).
(3) After the confirmation, User C sends a transaction that includes information about the Merkle verification on Receipt 154016, and 100 asset units is added to the ledger of User C. This transaction can been seen as the acknowledgement of receipt.
(4) After Blockchain X receives the acknowledgement of receipt, the previous receipt is destroyed and Receipt 154016 is also destroyed in subsequent blocks in Blockchain Y. The cross-chain transaction is completed. Of course, Blockchain X and Blockchain Y can also keep the acknowledgement of receipt to verify the continuity of subsequent cross-chain transactions.
To ensure the continuous effectiveness of the aforementioned mechanism, we also need to consider the finality in cross-chain transactions (or a fork selection mechanism). The transaction from Blockchain X and verified by Blockchain Y must come from a block in a valid chain of Blockchain X rather than an isolated block or isolated chain. Vlad Zamfir once proposed the concept of block merging: Two blocks on two different chains are merged into one block when a transaction is initiated across the two chains, and either chain extends subsequent block data based on this merged block. In fact, merging blocks means the ledger synchronization between the two chains. Therefore, block merging is considered unable to resolve the problem of mutual independence between two shards or chains. However, in cross-chain transaction, from Vlad's ideas we can still find an answer to the question of how to find the correct block on either chain and then complete the Merkle verification on a receipt.
According to Vlad, chains on which cross-chain transactions are needed are divided into main chains and sub-chains by level. For merging a block on a sub-chain with a block on a main chain, the sub-chain must have the same or higher level than that of the main chain. In our scenario, we need to perform cross-chain verification on a main chain. This ensures consistent data in the overlapping chain section even when either chain is extended subsequently.
Figure 3: Block merging (Vlad Zamfir)
However, the preceding solution requires the precondition of synchronous block generation. The validity of transactions on sub-chain Y will be affected if any of the following cases occurs: The transaction from main chain X is not confirmed in a timely manner; the chain is not extended; sub-chain Y has not received information about the extension of X in a timely manner; or intermittent synchronization occurs between the main chain and the sub-chain.
Figure 4: Possible situations during forking in non-synchronous cross-chain (cross-shard) transactions (Alexander Skidanov)
In the preceding figure, we can see that when two shards or chains have forks respectively, if A-B in Shard 1 and V'-X'-Y'-Z' in Shard 2 are identified as main chains respectively, a cross-chain or cross-shard transaction will succeed. If A'-B'-C'-D' and V-X become the main chains, a cross-shard transaction will become invalid. In the other two situations, an atomicity fault happens, that is, a transaction is valid in one shard but invalid in another shard. Due to the asynchronization between two shards or chains, main chains cannot be determined in the two shards or chains respectively when a cross-chain transaction is initiated, eventually causing this problem. Therefore, in cross-chain transactions between shards or sub-chains, an intermediary consensus mechanism is required for coordination.
This is what the beacon chain in Ethereum 2.0 does. The beacon chain is considered the main chain of all shards in Ethereum 2.0. This main chain uses the Casper consensus mechanism for election and randomly generates a shard validator in each round for ensuring the correctness of transactions between shards. However, because difficulty requirement, nonce, and block hashes that are available in PoW to perform stateless SPV are not existent in the Casper POS consensus protocol, to verify the validity of shards and chains, we need to backtrack to trusted blocks, compute the state of blocks after the trusted blocks and synchronize to current blocks. This increases the work of verifiers. Therefore, to reduce the work of verifiers, in SimpleChain, roles like the beacon chain are implemented through the main chain using PoW.
The anchor miner role is existent in the main chain, which is responsible for three things. 1. Verify the state validity of a sub-chain when a cross-chain transaction is initiated from that sub-chain. 2. Write the transaction from the sub-chain into the main chain and broadcast it for confirmation. 3. Write the cross-chain transaction result already confirmed in the main chain into blocks on the sub-chain that started the transaction and on the sub-chain that received the transaction.
The anchor miner acts as the miner both on the sub-chain and the main chain when verifying, broadcasting and transferring cross-chain transactions. The main chain has more miners than the sub-chain. Therefore, forging and transferring transactions in the sub-chain to the main chain is much lower in cost than forging and writing transactions from the main chain to the sub-chain. We need a more reasonable anchor miner election mechanism.
Figure 5: Higher probability of an evil miner in a sub-chain than that in a main chain (Alexander Skidanov)
An anchor miner does exist for a sub-chain for a long time, but is required to serve as a miner on the main chain for a long time. Because main chains using PoW allow the stateless SPV, the anchor miner election in SimpleChain is implemented in a random manner.
The maximum number of anchor miners to be verified in a cross-chain transaction is Min[(number of miners throughout the network/number of sub-chains)×3, number of miners throughout the network].
Because anchor miners come from main-chains using PoW. Therefore, we can sort workload verification results computed by main chains in ascending order and filter anchor miners. The smaller the workload value, the lower the probability of obtaining the calculation results, and the higher the ranking in the pre-selection list of anchor miners. A miner that has a ranking beyond the maximum limit of anchor miners will not sign in the current round of transaction verification. The PoW sorting during the process of anchor miner election and the PoW of the extended main chain are performed synchronously. That is, miners on a main chain will use the workload verification results to obtain both SIPC rewards on the main chain and rewards form the anchor miner. Anchoring miner rewards come from the SIPC miner formality fees paid by a cross-chain transaction initiator.
The N-conformation mechanism is used to ensure consistency between main chains and sub-chains. When a cross-chain transaction is initiated, a block on a sub-chain needs to receive confirmation from N block heights before the anchor miner verification passes and the transaction is broadcast to the main chain. After the confirmation from N block heights on the main chain is received, the confirmed transaction state will be written to the two sub-chains in this cross-chain transactions.
The value of N is directly proportional to the amount of the cross-transaction and the data volume. This means that a transaction of higher value requires more confirmations on the sub-chains and the main chain. Currently, the number of confirmations on the main chain is also a constant as it is in Bitcoin. Because the main chain produces a block every 12 seconds on average, if N is set to 15 on the main chain, the security level is close to that of 6 confirmations in the bitcoin blockchain. The number of confirmations from sub-chains will adjust dynamically based on the 15 confirmations from the main chain as well as the amount of the cross-chain transactions and the data volume.
Figure 6: SIPC model (Simplechain Foundation)
In SimpleChain Whitepaper 1.0, a micro-inflation mechanism was proposed for digital resource SIPC on main chains: With the increase in number of sub-chains, the sub-chain activity, and requirements on cross-chain transactions, block SIPC rewards will be fine-tuned on the basis of the original die-away curve (in the preceding figure, the green dotted line is changed to the black solid line). The result of the fine-tuning is that block rewards on the main chain will increase accordingly when the main chain SIPC is considered a resource and sub-chains require more resources of that kind. Take the current state for example, the block reward on the main chain may increase from 20SIPC to 21SIPC.
This design aims to establish a more stable relationship between roles on main chains and sub-chains. Sub-chains need main chains to coordinate cross-chain transactions. A cross-chain transaction is completed in the following steps:
(1) A user on a sub-chain initiates a cross-chain transaction and pays formality fees including sub-chain tokens (T) and main chain SIPC (S).
(2) Miners or validation nodes on the sub-chain complete the consensus verification and claim Token (T1) as the formality fee.
(3) Elected cross-chain miners claim the remaining Token (T2), all SIPC (S) on the main chain, and a fraction of SIPC (S2) in the operation pool as the formality fees to complete the cross-chain anchor and broadcasting.
(4) Ordinary miners on the main chain charge main chain SIPC (S') to package the cross-chain transaction.
(5) Anchoring miners on the other sub-chain read the cross-chain transaction on the main chain and broadcast it to the target sub-chain.
In the preceding steps, T includes T1 and T2. The formality fee S' charged by ordinary main chain miners is the sum of R and K, where R is the original block reward (20SIPC) and K is the reward of micro-inflation adjustment.
The operation pool is startup resources that nodes created inject into sub-chains by mortgaging SIPC when sub-chains are created. SIPC in the operation pool will be used as partial rewards (S) in cross-chain transactions and sent to anchor miners.
Assume that the capacity of a startup operation pool for a material is 10SIPC. In each cross-chain transaction, 0.1SIPC is assigned to cross-chain miners as a part of their rewards. After one cross-chain transaction, the capacity of the operation pool is reduced to 9.9SIPC. In this case, miners on the main chain generally receive transaction formality fee S' (20+0.01), where 0.01 is the reward for the micro-inflation adjustment.
Any SimpleChain user can choose to inject SIPC into the pool again. Users can also trigger the lower limit of activity degree by using sub-chain consensus and change rewards for cross-chain miners so that S2 of cross-chain miners is a negative value, that is, some of the cross-chain transaction formality fees are saved in the operation tool for sub-chains. At this point, micro-inflation reward K in formality fees charged by ordinary main chain miners is 0 or a negative value. This indicates that sub-chains are in a recession or that sub-chains and main chains become disassociated by reducing mutual stimulus.
The potential risks in the aforementioned mode include the upper limit of cross-chain transactions in blocks on main chains and overload on main chains.
As to the economy model, "lose-lose" attacks are possible: The interest of both miners on main chains and users may be affected by creating attenuation sub-chains.
[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]
Alibaba Open-Source and Lightweight Deep Learning Inference Engine - Mobile Neural Network (MNN)
2,599 posts | 764 followers
Followvic - August 30, 2019
Alibaba Clouder - June 24, 2020
Alibaba Cloud Community - May 30, 2022
Alibaba Developer - March 14, 2022
淘系技术 - April 14, 2020
Alipay Technology - August 21, 2019
2,599 posts | 764 followers
Follow
Blockchain as a Service
BaaS provides an enterprise-level platform service based on leading blockchain technologies, which helps you build a trusted cloud infrastructure.
Learn More
ECS(Elastic Compute Service)
Elastic and secure virtual cloud servers to cater all your cloud hosting needs.
Learn MoreLearn More
More Posts by Alibaba Clouder
