Do repost and rate:
Shared security vs. sovereignty: Each node obtains security from the global validator set, or is responsible for its own security.
Heterogeneity vs. Homogeneity: Each of the connected shards is the same as other shards, or the connected chain can have different attributes (for example, different consensus mechanisms or supported programming languages).
Ethereum 2.0
Ethereum 2.0's sharding is based on the simple goal of dividing transaction processing and storage requirements between shards. In the current version of Ethereum, each node needs to verify all transactions and store all historical information of Ethereum.
In practice, this means that a subset of the Proof-of-Stake nodes that act as validators on Ethereum 2.0 is allocated to a shard. A leader will be randomly selected to assume a role similar to that of the winning miner in Bitcoin's proof of work-packing a block, while a committee of other validators proves the validity of the block.
Once the committee proves the validity of a block, it can be included in the "Beacon Chain". This proof will be stored in the Beacon Chain instead of storing the entire transaction history of the shard.
The committee will create a time frame for the shard block, called a "slot". The 32 slots form an "epoch", after which the committee is disbanded and the shard is reorganized with new participants. The first slot of each epoch is a checkpoint, where the previous block can be finalized. The epoch loops every 6.4 minutes.
Splitting the validator seems to create an obvious security problem. For example, if there are 64 shards, the global validator set will be divided into at least 64 committees--maybe with relatively few validators per shard. In addition, the corruption of transaction data on a single shard may have huge consequences. If other shards are built on the basis of fake transactions, the entire system will be destroyed.
The solution is to randomly sample and rotate validators regularly.
Each shard committee must have at least 128 members. If you randomly select validators from around the world, the distribution of the selected ones follows a binomial distribution. For example, if you assume that 150 members are selected from a pool of global contributors (ETH 2.0 token holders), and the honesty is 75%, then the probability that the shard is also honest is 99.999999998%.
Infrequent random sampling will have a new attack method, that is, the verifier knows which shard they are on in a given period of time, and can start bribing other committee members on the same shard. Sampling is costly, because every time a validator is selected for a new shard, they need to download the entire shard's data.
Polkadot
Ethereum 2.0 through shared security, ETH holders verify transactions with the same shards. Polkadot also achieves shared security, but uses different shards, allowing each shard to have its own token and governance rules.
Usually, these sharded or parallel chains are built on Substrate (a blockchain development framework). If a chain decides to connect to the relay chain, the DOT holder will become the security provider of the parachain. If a chain wants to be part of the Polkadot consensus, they must lease a parachain slot through auction.
Polkadot uses a variant called Nominated Proof-of-Stake (NPoS). Nominators are DOT holders and they vote for validators. Currently, the network is expanding the number of validators from 20 to 100 during the startup phase.
Each parachain connected to the relay chain has collators. They run a complete node of the parachain and package their transactions into blocks. These blocks are then submitted to validators on the relay chain, and these validators have been assigned to a given parachain. Similar to Ethereum 2.0, these validators will randomly rotate to new parachains on a regular basis.
How to motivate these verifiers is determined by the parachain--for example, the verifier of a given parachain can be motivated by giving the parachain's native token. Collators provides a Merkle tree of the latest state transitions for verifiers of the parachain--the type summary and unique fingerprint of a given block in the blockchain. Then, the relay chain verifier will check whether the block complies with the state transition rules of the parachain.
It should be noted that Polkadot does not guarantee that the state is valid, but only checks the state transition. In practice, this means that when a parachain joins the Polkadot consensus, its previous state is considered valid.
Once the verifiers assigned to the parachain reach a consensus that the state transition is valid, they will construct a "candidate receipt" and finally include it in the state of the relay chain. On the relay chain, the estimated time for a final block is 12-60 seconds. Polkadot is also working on a cross-chain messaging protocol that allows parallel chains to communicate without passing through a relay chain.
Compared with Ethereum, a difference brought about by giving parachain the right to be responsible for its own token is that the transaction fees on the parachain can be customized. Parachains can choose their own fees in the system, and the security and resources of the relay chain are paid through the auction mechanism.
Cosmos
Compared with Polkadot and Ethereum, Cosmos adopts the "lightest" cross-chain communication method, which separates its own security from the security of the entire system. Cosmos Hubs only verifies messages between connected blockchains.
The Cosmos SDK is a framework for building application-specific blockchains (or regions) that can interoperate with the rest of the Cosmos ecosystem.
The application-specific blockchain connected to Cosmos Hubs (via the IBC protocol) is designed to maintain its full sovereignty. The design goal is that sovereignty increases the decision-making power of token holders on their agreements. If a bug is found or a new feature is needed, it can be introduced without persuading another chain token holder.
For example, if MakerDAO is hacked today, MKR holders will have to persuade ETH owners to fork the blockchain. Compared with MakerDAO, which is its own blockchain, the threshold for doing so is much higher.
The special thing about Cosmos is that it increases the flexibility of developers-they can fully control the virtual machine, consensus mechanism or governance method they want. All Cosmos needs is a light client proof.
However, the Cosmos model requires the market to assume a greater role in dealing with the risk of failure. For example, a fast-confirmed version of the anchor token may have a different price from the slow version of the same token. In essence, security can be priced as an asset, not as a blockchain design.
NEAR Protocol
The sharding design (Nightshade) of the NEAR protocol, like Ethereum 2.0, has core attributes. The NEAR holder is responsible for the security of all shards, which are homogeneous. The main difference between the two is that Near cancels the beacon chain.
NEAR does not have a main chain, but a single chain containing blocks, which carries all transactions that have occurred. However, physically speaking, each verifier only maintains the state corresponding to one shard ("block") of the transaction they verify.
Transactions in a block are allocated in different chunks. The chunk itself only contains these chunks. Unlike Polkadot and Ethereum 2.0 where the main chain and the shard chain have two independent consensus processes running, NEAR has only one consensus process to maintain the chain.
This is achieved by the validators being allocated to block production and some subsets of shards at the same time. In these shards, validators take turns producing blocks. Then, each block producer waits for the block producer to send the erasure coded version of the block to them--then these blocks are used to create the next block.
NEAR maintains fast cross-shard calls between contracts with receiving transactions. When a transaction affects the state of another chunk, a receipt is sent to the blockchain. Each chunk observes the most recent blocks and the receipts assigned to them, and applies these receipts in their own transactions.
The problem is that NEAR must in some way ensure that the receipt is actually applied by each chunk-otherwise, one chunk will execute a transaction and include it in one chunk, but the other chunk will not. This will cause the chunk to destroy other parts of the chain.
In order to combat the generation of invalid chunks, NEAR uses a fisherman system. In this system, there is a challenge period in which anyone can issue a challenge to a chunk. During this period, any honest verifier can provide a proof that a certain chunk is invalid. Then, the proof will be verified by the block producer of the next block, and the NEAR of the dishonest block producer will be partially penalized. In this case, the entire NEAR blockchain will be changed back to the latest valid state.
The trade-off of NEAR is that the current design can handle up to about 200 validators, while Ethereum can allow any user with 32 ETH to act as a validator (millions of validators). This is because of the continuous communication requirements between the Chunk producer and the block producer (the goal is that the block time is between 2-3 seconds).
However, the main advantage of NEAR's sharding design is that it is relatively easy to implement compared to Ethereum 2.0 and Polkadot.
Conclusion
The concern with sharding or similar blockchain ecosystems is that they limit composability. It cannot support the interaction of different contracts and the upgrade of transactions. After weighing, Cosmos' cross-chain transactions may be the slowest, and the shard chain with homogeneous security is the fastest.
Under the premise of limited composability, sharding designs like Ethereum 2.0 do provide potential large-scale scalability. Ethereum 2.0 will be launched in three phases, the final phase of which will enable smart contracts. However, after the second stage, using Ethereum as the data layer, the transaction processing capacity can be increased to 50,000 transactions per second through Optimistic or ZK Rollup.
In general, each of these layer1 structures can be exponentially improved in terms of scalability. However, it is worth noting that they are also very similar.
The meaningful differences between different blockchains may be more time-related--that is, when the project can launch a version that is competitive with Ethereum. Today, most projects are built on Ethereum because it is available and all assets and other developers are there.
Today, Ethereum users pay $10-50 for gas fees for common smart contract interactions, and the race to provide more transaction processing is ongoing, whether it is layer1 or layer2 extended solutions, such as Optimistic and ZK Rollup. The existing high gas fee may be the best opportunity to launch another successful ecosystem. So far, only the Bitcoin and Ethereum chains have seen meaningful impetus.
An interesting exception to the "infinite smart contract capabilities" argument is that purposely restricting these capabilities may be beneficial to the security of the blockchain.
Successful applications can rely on the security of the blockchain, because they can participate in other projects in addition to verifying the profits of the transactions on the chain-for example, by restoring the historical records of the blockchain to make profitable transactions, which will benefit the DEX. Arbitrate. The application-specific blockchain on Cosmos can eliminate the ability to deploy unauthorized code, thereby eliminating this parasitic attack vector.
