Editor's Note: This article comes fromPolkaWorld（ID：gh_6c4c2038ddba), reproduced by Odaily with authorization.
Both Polkadot and Ethereum 2.0 are sharded blockchain protocols. That is, they provide scalability by executing transactions in separate shards and providing a protocol for sending messages between shards.
Model
mdnice editor
architecture
architecture
Ethereum 2.0
mdnice editor
Ethereum 2.0
Ethereum 2.0 will only start phase 0 via the beacon chain. In phase 1, it will launch 64 shards in a simple chain to test the finality of the beacon chain. Each shard submits "crosslinks" to the "beacon chain", which contain information identifying the shard's data. Later, in Phase 2, shards will implement the eWasm interface, finally making the system usable. [1]
Polkadot
The network will also have "sidechains" to interact with chains that are not under the finality protocol of Ethereum 2.0.
mdnice editor
In order to interact with chains that want to use their own finality process (such as Bitcoin), Polkadot has bridge parachains to provide two-way compatibility.
consensus
mdnice editor
consensus
Both Ethereum 2.0 and Polkadot use a hybrid consensus model where there are separate protocols for block generation and finality. Finality protocols (Ethereum 2.0's Casper FFG and Polkadot's GRANDPA) are based on GHOST, and both can finalize a batch of blocks in a round. For block generation, both protocols use a slot-based protocol that randomly assigns validators to slots and provides fork selection rules for unfinalized blocks (Ethereum 2.0's RandDAO/LMD and Polkadot the BABE). Ethereum 2.0 finalizes batches of blocks based on time periods called "epochs". The current plan is to have 64 blocks per epoch, all done in one round. The estimated block time is 12 seconds, which means the expected time for finalization is 6 minutes (up to 12 minutes). [2] Polkadot's finality protocol, GRANDPA, finalizes a batch of blocks based on availability and validity checks that occur as the proposed chain grows. The time to finalization varies with the number of checks that need to be performed (reports of invalidity can lead to protocols requiring additional checks). The expected finalization time is 12-60 seconds.
Ethereum 2.0 requires a large number of validators per shard to provide strong validity guarantees. Polkadot is able to provide stronger guarantees with fewer validators per shard. Polkadot achieves this by having validators distribute erasure codes to all validators in the system, allowing anyone (not just a shard's validator) to reconstruct a parachain's blocks and test their validity. Random parachain validator allocation algorithm, and secondary checks by randomly selected validators make it impossible for a small group of validators on each parachain to collude.
mdnice editor
Polkadot can provide strong finality and availability guarantees with fewer validators. Polkadot therefore uses Nominated Proof-of-Stake (NPoS) to select validators from a smaller set, allowing smaller holders to nominate validators to run the infrastructure while still reaping the benefits of the system without running their own node. Polkadot plans to have 1,000 validators in the first year, and each parachain in the network needs about 10 validators.
Fragmentation
mdnice editor
Every shard in Polkadot has an abstract Wasm-based STF. Each shard can expose a custom interface as long as the logic is compiled into Wasm and each shard provides Polkadot validators with the ability to "execute blocks". Polkadot has a Substrate development framework, which has modules that can be configured, combined and extended, and can be combined in all directions to develop the STF of the chain.
messaging
mdnice editor
messaging
Polkadot has an additional protocol called SPREE that provides shared logic for cross-chain messaging. Messages sent using SPREE provide additional guarantees about origin and interpretation to the receiving chain.
governance
mdnice editor
Polkadot uses on-chain governance with multiple systems. There are several paths through which proposals can be passed, such as from the on-chain council, technical committees, or the public. All proposals will eventually go through a referendum, and the result of the referendum is always controlled by the majority of tokens. For low-turnout referendums, Polkadot uses adaptive voting bias to set pass thresholds. Referendums can contain various proposals, including allocating funds from the on-chain treasury. Decisions are made on-chain, binding and autonomous.
upgrade
mdnice editor
Polkadot uses the Wasm meta-protocol to implement chain upgrades and successful proposals without hard forks. All objects in STF, transaction queues, or off-chain workers can be upgraded without forking.
in conclusion
mdnice editor
