header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Scan to Download the APP

Post-merge: The Rebirth of Ethereum's New Consensus

Read this article in 56 Minutes
The merger is just the beginning of a new era for Ethereum.
原文标题:《 Post-Merge 时代:以太坊新共识的破局重生 》
Original article by Frank Fan, 0xCryptolee, Arcane Labs


Ethereum has undergone a historic upgrade and entered a new stage of development. After the merger, Ethereum will continue to move in the direction of expansion and decentralization. The Merge is only The first step in The PoS era. Ethereum is still facing huge challenges. Problems such as group centralization of verifier, capacity expansion and Lazy Validator Problem still restrict The explosion of applications and The security expansion of Ethereum. The consensus algorithm adopted by POS is analyzed step by step, focusing on exploring the use of DVT technology to solve the problem of single point risk of the verifier, and analyzing the problems and future development opportunities of Ethereum together with practitioners. Readers with certain Ethereum foundation are recommended to read this article.


image


A: The Merge


1.1 background


The Merge is Ethereum's largest technology upgrade ever, with The merger of The Execution Layer and Consensus Layer on September 15, 2022. Its biggest change is switching Ethereum's PoW Consensus to PoS Consensus.


Figure 1: The Merge


In addition, Ethereum's energy consumption is reduced by nearly 99.95% after the merger, and according to Vitalik Buterin's tweet, the Ethereum merger will reduce global electricity consumption by 0.2%.


Figure 2: Vitalik's perspective on the energy consumption of Ethereum after the merger


1.2 Changes brought about by merger


Token 增发: PoW 时代的 ETH Token 增发停止,新的 ETH 仅通过 PoS 共识出块产生,以太坊的通胀率降低,当 base fee 超过 15gwei 的时候,以太坊甚至进入通缩。



image
Figure 3: Combined Burn Total


Pledge Revenue: Revenue from GAS fees and MEV is distributed to Validator, and the prover's pledge currency standard revenue reaches 5-7%.



image
Figure 4: Rocket Pool pledge yield


Withdraw: After the merger, the pledged ETH cannot immediately Withdraw. It needs to be upgraded in Shanghai to release the limit. Moreover, when withdrawing money, users cannot Withdraw directly. There won't be a lot of withdrawals and selling. Detailed information is available the EIP - 4895: Beacon chain push withdrawals as operations



Data structure changes: The Consensus Block will contain the Hash value of the Execution Block, and POW-related parameters in the Execution Block will no longer take effect. The mixHash field records Ethereum's native RANDAO random number for EVM invocation, and Ethereum developers can directly use this random number in smart contract development.



Figure 5: Data structure changes after Merge


Consensus replacement: PoW Consensus is replaced by PoS, and the original miner responsibility is replaced by verifier. There are two chains at the same time, and two Client nodes need to be run simultaneously, Execution Layer Client (EL) and Consensus Layer Client (CL).



Figure 6: Merged Ethereum client


After switching to PoS consensus, the algorithm of Ethereum is converted from Ethash to Casper FFG (Gasper). Compared with the previous algorithm, Gasper is more energy saving, and it does not need to calculate the difficulty value by special mining machine, but to produce blocks in a random way. Let's move on to explore Ethereum's consensus algorithm and block approach!


2: Gasper


At present, 13,830,378 ETH are pledged on the beacon chain, and the number of active verifiers is 432,203 (as of September 23, 2022). According to the characteristics of PBFT, the number of verifiers in beacon chain is large, and the amount of network communication data is large. Simple PBFT is no longer applicable to the Ethereum network, so Ethereum adopts the idea of PBFT to improve and design the network architecture, and uses Gasper algorithm.


Gasper is a finality gadget in the Beacon chain protocol, which is used to determine which blocks should be considered as determined and unchangeable by participants, and to determine which fork chain is the main chain during the fork. Gasper's Finality generalizes the concept in the paper Casper Friendly Finality Gadget (Casper FFG).


Figure 7: Pledge and verifier situation


    2.1 & have spent concept


Figure 8: Epoch and Slot diagrams


Slot: When combined, a Slot is a block, and a committee is responsible for generating the Slot within 12S.


Epoch: Every 32 slots constitute an Epoch, and the time of an Epoch is 384S, that is, 6.4 minutes.


Committee (Verifier Committee) : A minimum of 128 validators will be assigned to each verifier committee, verifiers will Attestation their slots, and one Validator on the committee will be randomly selected as a Proposer to make blocks.


Attestation (Vote signature) : The Validator in the committee corresponding to each Slot needs to vote and sign for the last Epoch to ensure that it approves the transactions in the last Epoch.


Validator: Due to The switch of consensus algorithm to POS after Ethereum The Merge, The original miner was replaced by Validator, who became Validator by pledging 32ETH assets to participate in slot block out and signature work in each Epoch.


A Proposer: A Proposer comes from a Validator in the Committee and is selected based on a random number generated by RANDAO and is selected to package a block in Slot.


Beacon chain (Beacon chain) : Used to replace PoW consensus PoS blockchain, Beacon chain node is used to mount the transaction type of Data Blobs, providing more storage space for Rollup.


2.2 process


At the beginning of an Epoch, a Committee (verifier Committee) is assigned to each Slot through RANDAO to Attestation (signature vote) the previous Epoch.


Allocate multiple aggregators for the 32 slots of the current Epoch. After aggregating the Attestation of the last Epoch by the Committee, record the aggregators into the Slot block.


RANDAO determines a Proposer to make blocks by generating random numbers.


Figure 9: Committee blocks out


In the current Epoch, the committee is Attestation the checkpoint of the last Epoch when the Slot is in the block. The last checkpoint is Finalised after two ATtestations. Until all 32 slots in turn Attestation the checkpoint, the Epoch ends. When the first Slot of the post-epoch starts, the pre-epoch reaches the consensus of finality, that is, the post-epoch has experienced the pre-epoch and the current Epoch, a total of two rounds of epochs (because beyond the checkpoints of the two ATtestations, If there is a conflict in the checkpoint, 1/3 of the verticators must be evil, for example, in the height of 32, 64 and 96 blocks, the checkpoint may not be reached in the height of 64 and it is only reached in the height of 96, at this time the height of 32 is Finalised), the time is 12.8Min. The transaction is settled on the chain, which is called finality.


2.3 features


RANDAO assigns random numbers to the chain. The random number generated by RANDAO will be put into the Execution Layer Block, and the smart contract can use the random number directly. After having the native random number on the chain, DeFi may have new applications. For example, DeFi applications like gambling can directly trust and use random numbers generated by RANDAO.


Figure 10: RANDAO


2.4 Latest Message Driven GHOST (LMD-Ghost, GHOST Driven by the Latest news)


In the new POS consensus mechanism of Ethereum, LDD-Ghost is used as the fork selection rule. When a fork occurs, GHOST will select the subtree with more message support. The idea behind it is to reduce the amount of computation required to run GHOST by considering only the most recent votes of each verifier, rather than any votes generated in the past, when calculating the chain head.


Want to learn more can refer to: https://eprint.iacr.org/2013/881.pdf


2.5 Attendant problems


Increased communication and verification costs: Is more verifiers better? In fact, although the increase in the number of verifiers is beneficial to data availability sampling (DAS) and decentralization, the increase in the number of verifiers means that the number of verifiers in a single Slot will also increase, which will increase the communication burden between Aggregator and verifier when collecting signatures from each verifier. In addition, The verification cost of aggregate signature will also increase, which will increase the burden of the verifier node.


Long-range attack: After Withdraw pledges the ETH in the beacon chain, a verifier can use the old private key to perform a malicious fork in a previously signed block, since it has no pledged assets in the chain. Then it quickly generates empty blocks to the current block height to attack the network. This is also a possible attack in the future. Ethereum is designed to vote on pre-epoch checkpoints, which are designed to push the initial state forward and avoid possible attacks.


Three: Ethereum pledge mining


3.1 S taking


Pledge threshold: the verifier needs to pledge 32ETH as a margin asset in order to perform its duties and participate in the consensus.


Responsibility of the verifier: To produce the block and ATTEstation at the time specified in the Agreement.


3.1.1 Staking way


Solo Staking: Solo staking is supposed to allow the pledger, who wants to invest 32 ETH as the authenticator, to run the authenticator node on a cloud server, or at home to run the Ethereum node on a cloud server. The difference is that nodes running on cloud services are more stable. When participating in the network consensus, it can avoid and reduce the sabotage penalty caused by power failure and network reasons. The advantage of building nodes at home is that the cost of hardware and network services is lower than that of cloud server. Here, the pledgor can choose which hosting scheme to adopt by himself.


Staking Pool: Since 32 ETH is a large amount of money for ordinary people, and the pledgers of ordinary small funds want to participate in the network consensus but cannot run the nodes themselves, the pledge pool solution has emerged, among which the perishable semi-decentralized pledge solution Lido is the main project, which has absorbed a large amount of capital. Being an in-race head solution, followed by more decentralised solutions such as Rocket Pool and Swell, and an aggregation solution such as Unamano to aid and grow the Ethereum Staking space, on top of existing pledges Pool solutions.


In terms of node operation, Lido chooses to designate some professional operators to run network nodes, which is also its relative centralization. Operators hold the signature private key, and users' assets partly trust Lido and operators. As for the withdrawal private key, before July 2021, the withdrawal address is a 6/11 multi-sign address. The multi-sign private key is held by the OG in the industry, and after July 2021, the withdrawal address points to an upgradeable contract address, which is managed by the DAO. Rocket Pool has chosen to be more decentralized in terms of nodes. Anyone can run a node as a carrier by providing only 16 ETH and the corresponding hardware and software. While lowering the threshold for carriers, Rocket Pool has introduced $RPL pledge to reduce the risk of operators doing evil.


Staking Pool 的方案使得普通的用户可以将小额的 ETH 存入合约来获得以太坊的挖矿奖励,同时返还生息 Token 如 stETH 和 rETH 来释放质押资产的流动性,进一步增强了以太坊的去中心化程度和资金使用效率,是社区最为看好的方向。


CEX, centralized custodian: Besides Solo Staking and Staking Pool, centralized trading platform and the information institutions are the main participants in the pledge of the etheric fang, such as Ann Coinbase and currency are also launched its own pledge, by absorbing the etheric fang ETH small to participate in the low risk pledge to dig. The three schemes have their own advantages and disadvantages in terms of decentralization degree and security, which depends on the trust object of the pledgee. But there is no doubt that the three schemes have captured the corresponding funds and users, and jointly maintain the security and decentralization of Ethereum.


3.1.2 Risks and Hidden Dangers


Is it really all right after the merger? I don't think so. The chart below gives us a glimpse of what would happen if the beacon chain withdrawal restrictions were lifted.


Figure 11: Where the pledged ETH goes after the merger


Currently, Staking is mostly in Lido, Coinbase, and Solo Staking, while Staking is largely in other relatively centralized institutions and agreements such as Lido and Coinbase. After the withdrawal restrictions are lifted, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking, Staking I think the original pledged Ethereum will be redistributed to Lido and Coinbase. As time goes by, Lido and Coinbase will control more and more Ethereum verifier and pledge volume, which will eventually bring a serious threat to the decentralization of Ethereum. When they control Ethereum, For transactions that want to re-break this situation, they will be rejected by large mining pools like Lido or Coinbase, because the transaction you want to pledge ETH to Ethereum will be up to them, and the new ETH will be concentrated in the hands of more ETH people, Since they have a large amount of ETH in their hands at the time of pledge, this will undoubtedly be a new challenge to the decentralization of Ethereum, and we can expect the community and core developers to work together to solve this problem.


3.1.3 Reward types


Attestation reward: Each slot's committee attestations the previous Epoch history block checkpoint. Successful ATTEstations are rewarded with Attestation as part of the Validator's income. (High probability, low reward)



Figure 12: Attestation rewards


Block Rewards: Each Slot will have a Validator to package blocks as a proposer, and a proposer selected as a proposer will get a block reward. (Low probability, high reward)


Figure 13: Proposal award


MEV (Extractable Value for Miners) Income: In addition to gas fees, MEV also earned revenue from sandwich attacks. According to EigenPhi, the Volume of sandwich attacks in the past 7 days was above 100 meters, and the highest Volume was close to 400 meters. The income of MEV becomes one of the important income components of the verifier.


Figure 14: Combined MEV


3.1.4 Penalty types


Sabotage penalty: Failure to produce blocks as expected by consensus: Failure to Attestation blocks at the expected time.


Malicious behavior leads to slash: producing two blocks in a single Slot or making two attestations; Error block proposed in violation of the Casper FFG consensus rule.


3.2 & have spent The private key type


Signature private key: signature private key is used to validate signed in to perform the duties of the message, including attesting and proposing blocks, each 6.4 min, namely each Epoch, the key will be used once.


Withdrawal private key: The key used to extract the pledged asset and block reward, which needs to be stored offline. After Shanghai fork, the withdrawal private key can be used to extract the pledged ETH and reward.


3.3 & have spent ETH2 Pledge risk


Private KEY stolen: ETH2's signature/withdrawal private key stolen.


Single Point of Failure/Verifier effectiveness: Currently, verifiers exist and perform their duties as a single machine or node. Strict rules forbid common form of redundancy, such as multiple nodes run the same validation, doing so may cause the verifier to "punish" (slashed). If a pledge service is used, the key resides on a cloud server (such as AWS). If any component fails, the verifier stops validation and is penalized.


4. Distributed Verifier Technology (DVT)


In pledge level, although we have a pledge of decentralized solution to reduce the threshold and improve the service pledge pledge of decentralization, but in the Validator level, there is still risk of single point, now a single validation runs a network of multiple clients, if because the network reason or power outages and other physical factors can cause slowdowns punishment, Slot cannot collect valid signatures, we won't be able to run the same in a number of places by means of redundancy verifier node, because it will cause confusion among the signature, is considered to the network attack, but our signature private key can be split, with DVT technology to reduce the risk of a single point of failure, in the implementation of the upgrade, It also provides upgrade space for nodes, and will not cause large areas of offline nodes due to network upgrade. For specific analysis, please let us go on to explore!


4.1 concept


Operator: The person or entity that runs one (or more) nodes.


Operator Node: refers to a piece of hardware and software that performs the tasks of the Ethereum verifier. These tasks can be done by the node alone or in conjunction with other nodes using the DVT tool.


Distributed verifier technology: Distributed verifier technology is a technology that allocates the work of a single Ethereum verifier to a set of decentralized nodes. Distributed verifier technology can provide more secure and decentralized services than a verifier client running on a single machine.


Figure 15: The relationship between Validator, Nodes, Committees, and Operators


4.2 The Distributed verifier node needs to run


Ethereum executive-layer client


Ethereum consensus layer client


Ethereum distributed verifier client


Ethereum verifier client


4.3 & have spent How does DV prevent ETH2 pledge risk


The private key is stolen


The risk of private key theft can be prevented using threshold signature technique (M-OF-N)


A complete verifier key is split into smaller keys


Small pieces of the split key are aggregated to produce the signature of the full key


    image

    Figure 16: Key split and aggregate signature


The node is down


Crash Faults:

Reasons: due to power failure, disconnection, hardware failure, software error caused by the crash;

Preventive measures: Run the redundancy backup scheme of the same node in multiple places to prevent node disconnection.


Byzantine Faults:

Reasons: Caused by software bugs and network attacks;

Preventive measures: Multiple participating nodes decide by consensus, and a single node cannot make a decision.


4.4 Overall Architecture


image

Figure 17: Overall DVT architecture

Distributed verifiers use private key fragments to remotely sign messages


In the distributed verifier client, the signatures of the distributed verifier are aggregated by the aggregation signature technology. When the threshold is reached, the block is signed.


4.5 Two paths to realize DVT technology


An Approach to DVT using SSS: In this Scheme, entities pledging 32 ETH create the signing private key (SK, PK) and withdrawal private key, and run a Secret Sharing Scheme program to securely distribute the share of SK key among the committee nodes.


  An Approach to DVT using a DKG protocol: In the scheme of DKG, there is no single entity to distribute a share of the signature private key to the verifier, but instead a group of verifier committee nodes run the DKG protocol together. Thus, a secret key and a public key (SK, PK), and the n shares SK_1 of SK,... , sk_n is created, I =1,... The ith node of n has the share sk_i.


image

Figure 18: DKG Protocol

4.6 Threshold Signature Schemes (TSS)


When the verifier reaches a consensus on the block and needs to sign, the BLS threshold signature scheme is used to implement the signature. It allows N verifiers to co-sign the data, and it can be used in t+1 (0< t< N) Complete signature is achieved when all verifiers sign correctly. Through the TSS scheme, it not only realizes that every verifier cannot obtain the complete signature private key, but also ensures the smooth generation of the complete signature.

 

Five: DVT from mainstream projects

 

5.1 SSV


On the surface, SSVS provide robust, decentralized access to the Ethereum Staking ecosystem. Going a little deeper, the SSV is a complex multi-sign wallet with a consensus layer. The SSV acts as a buffer between the beacon chain node and the verifier client.


5.1.1 Components of the configuration


Distributed Key Generation: Operator calculates a shared public and private Key set by running the SSV program. Each operator owns only a single part of the private key, ensuring that no one operator can influence or control the entire private key to make unilateral decisions.


Shamir Secret Sharing: This mechanism is used to reconstruct the verifier key using a predefined KeyShares threshold. A single KeyShared cannot be used to sign a message.

SSV can use BLS technology to aggregate signatures and create the full key signature of the verifier. By combining Shamir and BLS, the signature private key of the verifier is sliced and shared and aggregated and reconstituted when a signature is required.


Multi - Party Computation: Applying secure multi-party computation (MPC) to Secret Sharing allows SSV KeyShares to be securely distributed among operators and perform decentralized computation of verifier responsibilities without having to rebuild the verifier key on a single device.


Istanbul Byzantine Fault Tolerance Consensus: What ties it all together is the Consensus layer of SSV, based on the Istanbul Byzantine Fault Tolerance (IBFT) algorithm. The algorithm randomly selects a verifier node (KeyShare) that is responsible for blocking proposals and sharing information with other participants. Once the block is considered valid by a predetermined KeyShares threshold, it is added to the chain. Thus, a consensus can be reached even if some operators (reach the threshold) have problems or are not currently online.


image

Figure 19: SSV V2 network topology

5.1.2 Three types of participants in SSV ecology


Stakers: Trading platforms, service providers or individual ETH holders that leverage SSV/DVT technology to achieve optimal effectiveness, security and decentralization for their verifiers. Stakers pay Operators a fee for SSV tokens to manage their validators.


Operators:operators 提供硬件基础设施,运行 SSV 协议,并负责维护验证者和 ssv. 网络的整体健康。operator 以 SSV Token 确定其服务费用,并向验证者收取运营和维护验证器的费用。


DAO (SSV token holders) :ssv.network DAO 分散了 ssv.network 协议和资金的所有权和治理权,SSV 是网络的原生 Token 。任何拥有 SSV Token 的人都可以参与 DAO,对提案和其他需要投票的项目进行投票。拥有的 SSV Token 的数量决定了对影响网络的决策的投票权。


5.1.3 SSv.net Work DAO is responsible for the following work:


Operator scoring:  Ssv.net Work relies on Operators and a decentralized and transparent score of 0-100% for their quality, experience, and services provided. The DAO is also responsible for reviewing the "Verified Operators" (VOs) and maintaining a list of VOs. Stakers can view and use these rankings to select Operators that manage their verifiers


Network Fees: In order to use SSv.net Work, Stakers are required to pay Network fees. The network fee is a fixed fee charged to each verifier and is added to the operators fee. Network fees flow directly into the DAO Treasury and can be used to fund further development of the SSV ecosystem and activities through the DAO voting process.


Treasury:stakers 支付的网络费用为 DAO 国库提供资金,它被用于发展 SSV 协议和生态系统的项目。可能包括协议开发和网络增长的赠款,与 SSV Token 持有人直接分享收入,营销和社区激励, Token 交换以实现国库的多样化,以及战略合作伙伴的投资以换取 SSV Token 。


Voting:提交给 DAO 的拨款请求和其他需要投票通过的提案。任何持有 SSV Token 的人都可以对影响 DAO 的决定进行投票,例如拨款请求、成为验证运营商的请求以及提交给 DAO 考虑的其他想法或请求。


5.2 Obol


Obol is a protocol that facilitates trust minimization through multi-operator staking, which can be used as the core module of a variety of Web3 products to obtain Ethereum pledge benefits at a low trust cost.


5.2.1 Four core public goods of Obol:


Distributed Validator Launchpad: The CLI tool and dApp that guides Distributed validators


Charon: Charon is a distributed verifier client for the Obol Network and is the first step in enabling trust-minimization authentication. Charon supports fault-tolerant, high-availability verification, enabling a group of people to run a verifier together on multiple machines rather than on a single machine.


image

Figure 20: Charon internals

Obol Managers: A set of reliable smart contracts for forming distributed validators


Obol Testnets: an ongoing set of common incentive Testnets that enable operators of any size to test their deployments before servicing Obol mainnet networks.


5.2.2 Key Concepts:


Distributed Validator: Distributed Validator is a proof of ownership Validator for Ethereum running on multiple nodes/machines. This is achieved using Distributed validator technology (DVT). The distributed verifier technique avoids the single point of failure problem, if the DVT cluster & LT; 33% of participating nodes are offline, the remaining active nodes can still agree on signing, and a valid signature is generated for the verifier in Staking. This is active redundancy, a common pattern used to minimize mission-critical system downtime.


Distributed Validator Node: A Distributed Validator Node is a set of clients that the operator needs to configure and run to perform the duties of the Distributed Validator operator. The operator can run redundant execution and consensus clients on the same hardware, run execution-layer Repeaters (such as MEV-Boost), and other detection services to ensure optimal performance. In the example above, the client stack includes Geth, Lighthouse, Charon, and Teku.


image

Figure 21: Example of an Obol client

The Execution Client (formerly known as the Eth1 Client) is dedicated to running the EVM and managing the trading pool on the Ethereum network.


Executive-layer clients include: Go-Ethereum, Nethermind, Erigon.


Consensus Cilent: The responsibility of the Consensus client is to run Ethereum's proof-of-interest Consensus layer, commonly referred to as the beacon chain. Consensus layer clients include: Prysm, Teku, Lighthouse, Nimbus, Lodestra.


Distributed the Validator Client:


The distributed verifier client intercepts the flow of information to the verifier client consensus layer client through a standardized REST API and focuses on two core responsibilities:


Agree on candidate responsibilities signed by all verifiers


The signatures of all verifiers are combined into a distributed verifier signature


Validator Client: A Validator Client is a piece of code that runs one or more Ethereum validators.


The verifier client includes Vouch, Prysm, Teku, Lighthouse


Distributed Validator Cluster: A Distributed Validator Cluster is a collection of Distributed Validator nodes connected together.


image

Figure 22: Obol DVT network topology

Distributed Validator Key: Distributed Validator Key is a set of BLS private keys that together serve as the threshold Key for participating in the proof-of-interest consensus.


Distributed Validator Key Share: A copy of the Distributed Validator's private Key.


Distributed Validator Key Generation Ceremony: In order to achieve fault tolerance in the Distributed Validator, each private Key share is generated together. Rather than having a trusted reseller produce a private key, split it up and distribute it, it is better to have each operator in a distributed verifier cluster participate in what is known as a distributed key generation ceremony, with the benefit that a full private key is never built at any time. Distributed verifier key generation ceremony is a type of DKG ceremony. The validator that ceremonically generates the signature stores and exits the data, as well as all the validator key shares and their associated metadata.

 

Six: Summary and prospect

 

6.1 summarize


Style throughout, from The Merge opens, combined The etheric fang used and Casper FFG algorithm, familiar with The way combined block and some new technology concept, and then speak to The etheric fang new way of mining as well as The existing Staking scheme, After learning about the single point of failure problem of the verifier, I went deeper into DVT technology, and briefly described how DVT solved this problem through two project cases. The whole article described in accordance with the idea of decentralization, providing certain reference for readers to understand the consensus algorithm of Ethereum and the development direction of decentralization.


6.2 looking


After The Merge, Ethereum will gradually realize Danksharding. Firstly, The gas cost of CallData is reduced from 16Gwei to 3Gwei through EIP-4488, which provides strong support for The speed expansion of Rollup. The next step is to introduce the transaction type of Blobs in Proto-Danksharding, so that Ethereum can provide more storage space for Rollup, reduce D/A cost, and gradually realize Danksharding.


In order to realize the ideas of data availability sampling (DAS) and block proposer/builder separation (PBS) described in Danksharding, it is necessary to ensure that the Ethereum network has enough nodes and enough decentralization for data availability sampling to be implemented. In other words, it is necessary to ensure expansion and low-cost D/A. The decentralization of Ethereum is the most important link, because the decentralized pledge scheme and DVT and other technologies are crucial to the subsequent development of Ethereum.


The original link


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

举报 Correction/Report
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit