Public Chain Shardeum: Explore Another Possibility of Fragmentation
Original title: "Why We Invest in Public Chain Shardeum: Another Possibility of Fragmentation"
Original author: Beam, Jsquare Research
2022 On September 15, 2019, Ethereum merged (Merge). This is a historic moment. Ethereum has prepared for it for 5 years and postponed it 6 times. Due to repeated debugging and long-term development, and the highly anticipated halo effect , many people mistakenly think that the merger will naturally bring higher scalability, security and sustainability, in fact it is not - we still use the metaphor of two trains, from PoW (workload proof) to PoS (equity Proof) transition, just changing the track and wheels, it will not directly bring faster speed, larger capacity, lower ticket fees, what can really accomplish the above three points is a complete set of solutions: have The sharding-capable mainnet is paired with a scalable Layer2 solution.
As pointed out by Ethereum founder Vitalik Buterin, sharding is the key to scalability A scaling solution to the trilemma, by dividing the nodes in the network into smaller groups, processing different sets of transactions and achieving parallel processing.By sharing the burden of processing the large amount of data required for summarization across the network, Just like when we check out at Walmart, by opening more checkout channels for shopping, we can intuitively reduce queuing time and improve checkout efficiency.
Figure 1 Simple logic of sharding
This is the logic of sharding, direct and simple, however, the devil is in the details Medium—the principle and direction are correct, but there will always be many problems in implementation. This article wants to draw a map of fragmentation explorers looking up at the stars and down-to-earth by straightening out the direction and dilemma on the road of "sharding". At the same time, by comparing the existing sharding solutions, some common problems are found, and a feasible exploration direction is proposed: Shardeum and dynamic sharding.
1. About "sharding"
In short, consider the impossible triangle Constraints, starting from Ethereum as the origin of the coordinate system (0,0), according to the two ideas of "vertical" and "horizontal", we divide the current blockchain scalability methods into two categories:
< p>Vertical Scaling: It is realized by improving the performance of the existing hardware of the system. Building a decentralized network where every node in the network has supercomputing power, i.e. every node needs "better" hardware - this is a simple and effective way to achieve initial improvements in throughput, especially for It is suitable for high-frequency trading, games and other application scenarios that are sensitive to delay. However, this expansion method will limit the level of decentralization of the network, because the cost of running a verification node or a full node becomes higher. Maintaining a level of decentralization is limited by the approximate growth rate of computing hardware performance (this is the so-called "Moore's Law": the number of transistors on a chip will double every two years, and the cost of computing will be halved).
Horizontal Scaling: Horizontal scaling generally has several ideas. One is to disperse the transaction calculation amount in a certain ecology to multiple independent blockchains in the context of blockchain, and each chain has its own block producers and execution capabilities. The execution layer of each chain can be fully customized, such as node hardware requirements, privacy features, gas fees, virtual machines, and permission settings. Another horizontal expansion solution is a modular blockchain, which divides the blockchain infrastructure into an execution layer, a data availability layer (DA) and a consensus layer. The most mainstream blockchain modularization mechanism is rollup. Another is to divide a blockchain into many pieces and execute them in parallel. Each shard can be regarded as a blockchain, which means that many blockchains can be executed in parallel. Additionally, there is usually a main chain whose only job is to keep all the shards in sync.
It should be pointed out that the above expansion ideas do not exist in isolation, each solution is to find a trade-off point in the impossible triangle, cooperate with The design of the incentive mechanism created by economic forces in the system achieves an effective balance between the macro and micro levels.
In order to discuss "sharding", we need to start from scratch.
Still assuming such a scenario, Walmart shopping checkout, in order to improve checkout efficiency and reduce customer waiting time, we expanded from a single checkout channel to 10 checkouts Window, in order to avoid book errors, we need to formulate uniform rules at this time:
First, if we have 10 cashiers, how to assign them to which windows work?
Second, if we have 1000 customers waiting in line, how do we decide which window each customer goes to check out?
Third, how to summarize the 10 separate ledgers corresponding to these 10 windows?
Fourth, in order to avoid the situation where the accounts do not match, how to prevent the cashier from making mistakes?
These questions actually correspond to several key issues in fragmentation, namely:
How to determine which shard the nodes/validators of the entire network belong to? That is: how to perform Network Sharding;
How to determine which shard each transaction is assigned to? That is: how to carry out transaction sharding (Transaction Sharding);
How to store blockchain data in different shards? That is: how to perform state sharding (State Sharding);
Complexity means risk. On the basis of all the above, how to avoid the split of the entire system security ?
01 Network Sharding
< /p>
If we simply understand the blockchain as a decentralized ledger, whether it is a PoS or PoW consensus mechanism, it is to allow each node to compete for the right to bookkeeping according to certain established rules. Ensure the correctness of the ledger. And network sharding means that another established rule is needed to shard the blockchain network. Under the premise of minimizing mutual communication, each shard handles the transaction on the chain and competes for the right to bookkeeping—that is, the node’s grouping rules.
The problem encountered in this process is that as the internal nodes of the blockchain are divided into different pieces, the difficulty and cost of the attacker will be linear decline. We can reason, assuming that the rules and results of this grouping process are fixed and predictable, then an attacker who wants to control the entire blockchain network only needs to control one of the shards in a targeted manner and buy some nodes in the shard. .
Near founder Alexander Skidanov describes the problem this way: If a single chain with X validators decides to hard fork into a shard chain and With X validators divided into 10 shards, each shard now only has X/10 validators, breaking a shard only requires breaking 5.1% (51% / 10) of the total number of validators. This leads to the second point: who chooses the validators for each shard? Controlling 5.1% of validators is only harmful if all of those 5.1% are in the same shard. If validators cannot choose which shard to validate in, it is extremely unlikely that a participant controlling 5.1% of validators will have all validators in the same shard, greatly reducing their ability to disrupt the system.
Figure 2 The difficulty of attacking a certain fragment is greatly reduced
Sharding systems must develop a mechanism to trust the network not to reverse these transactions from outside shards. Probably the best answer so far is to ensure that the number of validators within a shard is above some minimum threshold, so that the chances of a dishonest validator overwhelming a single shard is low. The most common method is to construct a certain degree of unbiased randomness, relying on mathematical methods to minimize the probability of success of the attacker. For example, in Ethereum, the solution of Ethereum is to randomly select a validator for a shard from all validators, and change the validator every 6.4 minutes (the length of an epoch).
Figure 3 Validator rotation conceived in Ethereum 2.0
To put it simply, the nodes are randomly grouped, and then the work is assigned to each group of nodes for independent verification.
However, it should be pointed out that randomness in the blockchain is a very challenging topic. Logically speaking, the generation process of this random number Should not depend on any particular shard for computation. For this calculation, many existing design ideas are to develop a separate blockchain and maintain the entire network. Such chains are called Beacon chains in Ethereum and Near, Relay chains in PolkaDot, and Cosmos Hubs in Cosmos.
02 Transaction Sharding
Transaction sharding refers to "which "Which shards are the transactions to be allocated to" rules can not only achieve the purpose of parallel processing but also avoid the occurrence of double spending problems. The difference in the ledger model of the blockchain will affect the development of transaction sharding.
There are currently two types of accounting methods in the blockchain network, namely UTXO (Unspent Transaction Outputs, unused transaction output) model and account/balance model. The typical representative of the former is BTC, and the latter such as ETH.
UTXO model: In BTC transactions, each transaction will have one or more outputs. UTXO refers to the output of blockchain transactions that have not yet been spent, which can be used as The input of a new transaction, the transaction output that has already been spent can no longer be spent, similar to the payment and change in the case of banknote transactions, the customer pays one or more banknotes to the store, and the store gives change to the customer with one or more banknotes . Under the UTXO model, transaction sharding requires cross-shard communication. A transaction may include multiple inputs and multiple outputs, there is no concept of account, and there will be no record of balance. One possible way is: put it into a hash function according to an input value of its transaction to process it into a discrete type hash value to determine which shard the data should go to. As follows:
Figure 4 A kind of UTXO Possible Transaction Sharding Ideas
To ensure that entries are consistently placed in the correct shard, the values fed into the hash function should all come from the same List. This column is called the Shard Key. Afterwards, all transactions with a value of 1 are divided into shard 1, and transactions with a value of 2 are divided into shard 2. The disadvantage of this method is that the shards have to communicate to avoid double-spending attacks. Restricting cross-shard transactions will limit the usability of the platform, while allowing cross-shard transactions will have to weigh the cost of cross-shard communication and the benefits of performance improvements.
Account/Balance Model: The system records the balance of each account. When making a transaction, the system checks whether the account has enough balance for payment, similar to bank transfer , the bank will record the balance of each account, and only when the account balance is greater than the required transfer amount, the transaction can be carried out. Under the account/balance model, since a transaction has only one input, as long as the transaction is sharded according to the sender’s address, multiple transactions of the same account can be guaranteed to be processed in the same shard, effectively preventing double spending. Therefore, most blockchains using sharding technology are account book systems like Ethereum.
03 State Sharding
State sharding refers to, in How blockchain data is distributed and stored in different shards.
Still using our Walmart queuing example, each window has an account, how are their accounts recorded? If: Whichever queue the customer comes to, the account will be recorded. For example, if customer A goes to window A, then the customer goes to another checkout window such as window B the next day, and window B does not have the customer's past account information (such as It involves payment methods such as stored value cards), what should I do? Call the customer's account information to window A?
State sharding is the biggest problem of sharding, which is more difficult than the above-mentioned network sharding and transaction sharding. Because under the sharding mechanism, the transaction will be processed in different shards according to the address allocation, that is to say, the state will only be stored in the shard where the address is located. One problem to be faced at this time is that the transaction will not only be in In a shard, it often involves cross-sharding (Cross-Sharding).
Consider a transfer situation, A account transfers 10U to B account, and A's address is allocated in shard 1, and the transaction record will also be stored in shard 1. The address of B is allocated in shard 2, and the transaction records will be stored in shard 2.
Once A wants to transfer money to B, a cross-shard transaction will be formed, and shard 2 will call past transaction records to shard 1 to confirm the transaction Therefore, if A sends coins to B frequently, shard 2 must constantly interact with shard 1, and the transaction processing efficiency will be reduced. However, without downloading and verifying the entire history of a particular shard, participants cannot necessarily be sure that the state of their interactions among them is the result of some valid sequence of blocks, and that such sequence of blocks is indeed the canonical chain in the shard.
Therefore, compared to a single chain without sharding, the new challenge facing the sharding system is that users cannot directly and fully verify the validity and Availability because there is too much data. There must be a maximum trustless and practical indirect way for users to verify which chain is fully available and valid so that they can determine which chain is the canonical chain. In practice, blockchain developers can use techniques such as committees, SNARKs/STARKs, fisherman mechanisms, and proofs of fraud and data availability to solve some of the problems in verification.
There are two ways to solve this problem. One is synchronous cross-sharding (Synchronous), that is, tight coupling (Tight Coupling). When a shard transaction occurs, related blocks containing state transitions all occur at the same time, and nodes on each shard cooperate to execute the transaction. Natural to look at and best to use, the model's most famous design is called Merge Blocks, but achieving this in practice is complicated. To accomplish the above, validators between shards need to communicate with each other synchronously. If the demand for cross-shard transactions is high enough, performance may degrade as more shard workers have to collaborate together to process cross-shard transactions.
Another way is asynchronous cross-sharding (Asynchronous), that is, loose coupling (Loosely Coupling). This idea is adopted more widely, such as NEAR, Ethereum, Cosmos, Kadena, etc. In this process, the most challenging thing is the atomicity of the transaction. According to Jordan Clifford, co-founder of Scalar Capital, if we imagine the concept of a receipt (Receipt), the receiver proves that they will receive the Token from the external shard by providing the Merkle path of the transaction in the source shard. The destination shard consumes the receipt and credits it to the recipient's account. This must be done atomically. The sender's and recipient's accounts are either modified together or not. If there is a gap or one end fails, the sender can trick the recipient into believing they have received funds that they never will.
Here is a life-like metaphor for the term atomicity. If I can't book a hotel, I hope I don't buy a plane ticket, and if I can't book a plane ticket, I don't want to book a hotel either. This is called atomicity - either all succeeds, or none succeeds.
Second, fragmentation exploration and attempt
Let's review the above about fragmentation During the discussion, some key issues mentioned:
One is how to perform state sharding, that is, how to distribute blockchain data in different shards For storage, if cross-shard communication is required, how to ensure the balance of benefits.
The second is how to deal with the atomicity of the transaction. One shard needs to let the other shard know in a timely manner if it modifies the state of common access, otherwise it will prone to confusion.
In the following, we sort out the well-known public chains in the industry and their technical solutions. Part of the context can be glimpsed in it, and on this basis, the cutting-edge and innovative nature of Shardeum can be discussed.
01 Calculation Fragmentation
Zilliqa is one of the earliest smart contract platforms to try fragmentation , is a very beneficial and effective attempt of sharding technology.
It was established in 2017 and promoted by a team of specialized researchers and academics related to the National University of Singapore. Built for compute-intensive tasks. The Zilliqa network is able to process high-throughput transactions across its network through a parallelization process called computational sharding. On a sharded blockchain network, the task of computing transactions is distributed across the shards of the network.
From the sharding process, Zilliqa divides it into two parts. First, directory service (DS) committee nodes are selected, then the sharding process is started and nodes are assigned to each shard. Once a transaction is verified in a shard, it can be verified by the entire network into a global state that combines transactions from all shards into a single verifiable source of truth on the Zilliqa blockchain.
In short, there are three main functions for nodes in the blockchain:
- Package transactions and broadcast to other nodes
- Store the historical ledger of the entire network
Zilliqa uses a simple and effective idea to solve the cross-shard communication and atomicity problems we mentioned, that is, only computing sharding, not network and storage sharding. All nodes in the platform store the full state, and every transaction is received by every node. In order to verify transactions, the network is divided into multiple partitions according to the address space of the account. This is called computational sharding because it divides the work of validating transactions, which is often computationally intensive. Since each node still receives every transaction and updates the state of all accounts, network bandwidth and storage operations remain bottlenecks - the network and storage are not sharded and therefore cannot really scale.
02 Static state sharding
A more general sharding method is to combine the account's The address space is divided into multiple fixed-size regions called shards, and nodes in the network are assigned to different shards. This is called state sharding. Platforms such as Near, Elrond and Harmony are taking this approach. While ethereum initially planned to implement state sharding, the new approach only shards the data to increase accessibility.
2.1 Data fragmentation idea of Ethereum
It should be noted that Ethereum's sharding plans are constantly evolving as more efficient scaling paths are developed. One version of Ethereum’s vision for future sharding is based on “data availability” sharding. Blob" to split the data, while using "data availability sampling" to confirm that all data is available.
Another solution version involves adding additional functions to each shard on the basis of solution 1, making each shard more like today The Ethereum mainnet allows shards to store and execute code and process transactions, as each shard will contain its unique set of smart contracts and account balances, and cross-shard communication will allow transactions between shards. However, this scheme is still under debate in the community, because the data availability of scheme 1 and the coordination of Layer 2 can already provide enough scalability for Ethereum, so the community is still evaluating the economic cost and benefit value of version 2.
2.2 Harmony
Harmony is a The sharding network of PoS adopts a more standard sharding method. The idea of this method is to have multiple small blockchains called shards, each shard is responsible for a part of the state, and a network that coordinates them blockchain, known as the beacon chain in Harmony. Let's follow the previous discussion and see how Harmony solves the problems of network sharding, transaction sharding, and state sharding from bottom to top.
Network sharding: Harmony divides the validator network into different shards, each shard contains a different set of validators, which are closely connected to each other, Run consensus between them.
Transaction Sharding: Harmony's transactions are handled and processed by a single shard. This enables shards to process transactions concurrently, increasing the overall transaction capacity of the blockchain. For transactions, users only need to specify the shard_id field in the signed transaction, indicating the shard to which the transaction belongs.
State Sharding: In Harmony, validators for each shard need to store 1/N of the global state because they maintain their own blockchain and state database (N=number of shards). This alleviates validators' concerns about data availability. Additionally, cross-sharding further improves state consistency between shards.
Harmony mainnet supports thousands of nodes across multiple shards, producing blocks in seconds with instant finality. Centralization is reduced through the arrangement of the pledge mechanism, while supporting pledge delegation, reward compounding, and double-signature reduction. Adopting the effective mortgage mechanism of EPoS (Effective Proof-of-Stake) and the safe random sharding technology (Random Sharding), relying on the provisions of the agreement to break up the Token mortgaged by large households into many small parts, and randomly distribute them to multiple In the shard, so that no one can concentrate his pledged Token in a single shard, so that he cannot attack a single shard.
As for cross-shards, in the case of cross-shard transactions and beacon chain synchronization, validators from different shards cross-shards through a globally connected network tablet to send a message. According to Harmony's official documents, "Kademlia cross-shard routing technology" is adopted to control the network overhead of cross-shard communication, and the "erasure code" is used to optimize the block broadcast process, so that the broadcaster's network pressure is less and avoid The sender's network bottleneck problem, so as to achieve efficient horizontal sharding expansion. Already equipped itself to be the first sharded blockchain to accomplish cross-shard messaging. With an efficient cross-shard messaging protocol and a full-mesh design, shards will be able to communicate seamlessly between each other, and as the team actively works toward this goal, users and developers can look forward to a new release on Harmony later this year. Cross-shard messaging protocol.
This is a major breakthrough for builders and developers on Harmony, as they can data to build. In addition, the consistency of data between shards is also important. These two pursuits will determine the sustainability of this infinite scalability.
2.3 Elrond
Elrond is a high Throughput public blockchain designed to provide security, efficiency, scalability and interoperability. The two most important features that set Elrond apart are adaptive state sharding and a secure proof-of-stake consensus mechanism.
Elrond uses all levels of adaptive state sharding for transactions, data, and networking. A dynamic adaptive sharding mechanism will perform shard merging and shard splitting, taking into account the number of available validators and network usage. Remains highly resilient to malicious attacks due to periodic node shuffling across shards. Every epoch, at most 1/3 of the nodes in each shard are shuffled to other shards to prevent collusion. In terms of randomness, the source of randomness is secured using BLS signatures, which make it unbiased and unpredictable.
For the smart contract on the shard state architecture, the cross-shard execution process is used, and the shard load is balanced. Balancing smart contracts across shards allows Elrond to run multiple smart contracts in parallel.
At the same time, for cross-sharding, Elrond adopts a design they call Meta Chain (Meta Chain), which can quickly determine the cross-sharding within a few seconds Chip transaction (Finality). By studying its technical white paper, we simplify its process as follows: Assume that the Elrond network has only two shards and metachains. Suppose a user generates a transaction from his wallet whose address is in shard 0, and wants to send EGLD to another user whose wallet address is in shard 1, the steps shown in the figure below are required to handle cross-shard piece deal.
The structure of a block is represented by a block header containing information about the block (block nonce, round, proposer, validator timestamp, etc.), as well as an internal List of miniblocks per shard for actual transactions. In our case, for a block in shard 0, there are usually 3 miniblocks:
miniblock 0: includes intra-shard transaction of shard 0 miniblock 1: includes and divides Cross-shard transaction miniblock 2 with sender in shard 0 and destination in shard 1: Contains cross-shard transactions with sender in shard 1 and destination in shard 0. These transactions are already in sender It will be processed in fragment 1 and will be completed after the current fragment processing.
There is no limit to the number of small blocks with the same sender and receiver in one block. This means that multiple miniblocks with the same sender and receiver can appear in the same block. In this process, the atomic processing unit executed across shards is a miniblock: either immediately process all transactions of the miniblock, or not, and the execution of the miniblock will be retried in the next round .
Elrond's cross-shard transaction strategy uses an asynchronous model. Validation and processing is done first in the sender's shard and then in the receiver's shard. Transactions are first dispatched in the sender's shard, since it can fully verify any transaction initiated from an account in that shard. After that, in the receiver's shard, the node only needs the execution proof provided by the meta-chain, performs signature verification and checks for replay attacks, and finally updates the balance for the receiver and adds the transaction amount.
Shard 0 handles intra-shard transactions in miniblock 0 (miniblock 0) and a set of cross-shard transactions whose addresses come from shard 1 As a recipient in miniblock 1. Block headers and miniblocks are sent to the metachain. The metachain notarizes the blocks of shard 0 by creating a new metachain block (metablock) that contains the following information about each miniblock: sender shard ID, receiver shard ID, miniblock hash.
Shard 1 gets the hash of miniblock 1 (miniblock 1) from the meta block, requests the miniblock (miniblock) from shard 0, and parses the transaction list , request the missing transaction (if any), execute the same miniblock 1 (miniblock 1) in shard 1 and send to the metachain result block. After notarization, the set of cross transactions can be considered final. The diagram below shows the number of rounds required to complete a transaction. The rounds are considered from the first included in a miniblock to the last miniblock notarized.
Figure 5 Elrond's cross-shard asynchronous model
2.4 Near
Near is a fully state-sharded, developer-friendly scalable public chain , they proposed a new protocol and solution called Nightshade.
Different from the above two fragmented public chains, its technical architecture is not composed of a beacon chain and multiple fragmented chains, but It is to model the system as a separate blockchain, which is fragmented at the block level, and there are many "segments" in each fragment.
Figure 6 Near abandoned the beacon chain approach and adopted the Nightshade design
Nightshade models the system as a single blockchain, where each block logically contains all transactions for all shards, and changes the overall state of all shards. Physically, no participant downloads the full state or the full logical block. Instead, each participant of the network only maintains state corresponding to the shards they validated transactions on, and the list of all transactions in a block is divided into physical chunks, one block per shard.
Under ideal conditions, each shard of each block contains exactly one block, which roughly corresponds to a model with a chain of shards, where The shard chain produces blocks at the same rate as the beacon chain. However, some blocks may be lost due to network latency, so each shard of each block actually contains one or zero blocks.
There are two roles in Nightshade: block producers and validators. At any time, the system contains w block producers (Block Producer) and wv validators (Validator), in the near model w=100 v = 100, wv = 10,000. The system contains n shards, n = 1000 in the near model. There are no shard chains in Nightshade, instead all block producers and validators are building a single blockchain, called the main chain. The state of the main chain is divided into n shards, and each block producer and verifier only locally downloads the state subset corresponding to a certain subset of the shard at any time, and only processes and verifies the The transaction status of these parts. Maintenance of the network is done in periods, where a period is a period of days.
Block producers and block producers rotate each block according to a fixed schedule. Block producers have an order and repeatedly produce blocks in that order. For example, if there are 100 block producers, the first block producer is responsible for producing blocks 1, 101, 201, etc., and the second block producer is responsible for producing blocks 2, 102, 202, etc.). Since block production is different from block production, state needs to be maintained, and for each shard, only sww/n block producers maintain the state of each shard, correspondingly, only those sww/n block producers rotate to create blocks .
As for cross-sharding, if a transaction needs to affect multiple shards in Near, it needs to be executed consecutively in each shard. The complete transaction is sent to the first affected shard, and once the transaction is included in a block for that shard, and applied after the block is included in a block, it generates a receipt transaction that is routed to the next shard where the transaction needs to be executed. If more steps are required, the execution of the receipt transaction generates a new receipt transaction, and so on. See the picture below for details:
Figure 7 Cross-shard transactions in Near
Third, Shardeum and dynamic state sharding
From the above analysis of Harmony, Elrond and Near, we can see that for Answers to the two questions we raised:
1. The current Layer 1, the most common fragmentation method is to divide the address of the account into multiple It is a fixed-size area for shards and assigns nodes in the network to different shards.
2. In a network with stateful sharding, transactions between contracts in the same shard are fast and easy, while transactions across multiple shards are much slower, but not impossible. If a transaction needs to affect multiple shards, it needs to be executed sequentially in each shard. Because transactions are grouped into blocks and consensus is done at the block level, it is possible for a transaction affecting multiple shards to be confirmed in one shard but rolled back in another. Additionally, transactions affecting multiple shards will require additional processing time proportional to the number of shards they affect.
But at the same time, by analyzing the current exploration and solutions in the market, we have discovered some new problems in the current stage of public chain fragmentation:
< p>1. When transacting across shards, how to avoid continuous execution of shards while ensuring atomic processing of transactions?
2. If the number of nodes less than one shard node is added to the network, how does the network deal with the extra nodes?
As a professional investment company that focuses on promoting the large-scale application of blockchain, reshaping the web3 value paradigm and empowering the future, Jsquare has always been concerned about blockchain While paying attention to the Web3 application layer, we have great confidence in a more decentralized infrastructure, a non-sense blockchain experience, and a secure future based on encryption technology. Even though the concept of sharding is not new, even though people have been exploring on this road for years and years, when we came into contact with Shardeum, we still feel that they have insight into the sharding track and the revolution they have made. Technological improvements are worth our bets on. Corresponding to these two problems, Shardeum proposes two novel solutions.
3.1 Shardeum and transaction-level consensus
Shardeum has formed a unique technology and consensus algorithm that combines Proof of Quorum (PoQ) with Proof of Stake (PoS). The consensus algorithm will help secure the network through trustless voting to collect and verify the pledge of nodes. Each transaction is processed in the order received before being grouped into a block/partition.
Different from the long-established public chain network mentioned above, the consensus on the Shardeum network is at the level of each transaction (Transaction) rather than the block (Block) level Done, allowing transactions to be processed simultaneously across shards, rather than sequentially like Near's block-level consensus. This transaction-level consensus removes the complexity required to ensure Atomic Processing. Therefore, second-level finality and low latency can be achieved, thereby preventing network congestion.
3.2 Shardeum and Linear Scaling
To explain what linear scaling is, we need to imagine the following situation:
Near a shard of 100 nodes on the main network. It is expected that more shards will be added in the future. Harmony has 4 shards, each with 250 nodes, and a total of 1,000 nodes on the main network. All contracts are in the same shard. Elrond has 3 shards and 1 metachain, each shard has 800 nodes, and the main network has a total of 3200 nodes.
If you add 100 nodes to Harmony, which is less than the 250 nodes required in a shard, how does Harmony handle these nodes? Would it be possible to consider dividing this total of 1100 nodes into 11 shards of 100 nodes each?
Sounds better, but due to the static nature of some shards, many additional nodes need to join the network to create new shards. If we want to add some nodes to the above network, if we only add a single node, it is impossible to improve the performance of the entire block, at least the current "minimum shard size" number of nodes (in Near 100 nodes) - because the current shards are static shards and do not support linear expansion, and no production network can actually split and merge static shards.
In addition to "transaction-level consensus", Shardeum's white paper mentions that a unique feature is that it uses dynamic state sharding, which is different from static sharding. All nodes of Shardeum cover the same address range, Shardeum's virtual sharding (that is, dynamic sharding) allows each node to hold a different address range, and there are overlapping nodes between the covered addresses - this has a greater complexity, but the benefit is that it allows true linear scaling.
Through the dynamic change of address space and node correspondence, plus a new data availability proof for cross-shard verification, Shardeum can achieve fitting Or approximately "linear scaling". This method of verification and confirmation according to the "transaction level" may sacrifice the performance of a single chip to a certain extent, but it is a very beneficial expansion for the network as a whole.
Shardeum currently has 10 shards, each with 128 nodes, and a total of 1280 nodes. The main network is expected to be launched in the fourth quarter of 2022. While Shardeum is still under development, the Shardus technology used at the protocol level has been proven to scale linearly. During the update event in Q3 2021, a network of 1000 nodes running on shardus running on AWS t3.medium hardware proved to be able to achieve 5000 TPS for cross-shard transactions.
Figure 8 In the third quarter of 2021, Shardus is proven to be able to achieve cross-shard transactions of 5000 TPS
In August 2022, Shardeum successfully demonstrated the capability of 100TPS through ERC20 Token transfer on the Liberty 2.0 test network with full sharding function. Normally, it takes a blockchain several years to build and reach higher TPS, but Shardeum achieved this in less than 4 months after launching Liberty 1.0. Currently, Shardeum has tested and released Liberty 2.0 with 50 nodes, where each node stores about 1/5 of the total data and executes 1/5 of the total transactions.
Fourth, Conclusion
A true fragmentation and scalable blockchain needs start from scratch. Similarly, a community with a diamond-like consensus also needs to be built from scratch, and community building has never been easier than technological research and breakthroughs. We have seen the number of active testers and the number of test transactions after the Shardeum testnet was launched. We are excited that more people are walking hand in hand on the road of innovation we have discovered. At the same time, we have seen some voices of doubt, but we believe that the road of progress is a spiral And twists and turns, any creativity and exploration are worth a try.
As it is said in "Baopuzi·Ying Xing", "There are six jobs in the state, and a hundred workers belong to one. You can sit and talk about the way, or do it by doing it." There is also a saying that it is better to act instead of talking about it. Jsquare always has an open attitude and hopes that more builders will join in the testing and exploration of decentralization and sharding. On April 26, 2022, Shardeum launched Shardeum alphanet (Liberty) 1.0. Since then, many users have participated in Shardeum testing, more than 100K+ wallets have been created, and 1000+ smart contracts have been deployed, resulting in greater TPS requirements. Just as we believe that only when Web3 is adopted on a large scale, those high-quality, high-performance decentralized public chains will stand out in the market competition, and just as we believe, those who have experienced doubts, accusations, public discussions and repeated Only a community of demonstration can go further and further on the road of decentralization.
Original link< /a>
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
