Original author: Frank Fan, 0xCryptolee
"As long as you have the courage to make a promise, the world will help you remove insurmountable obstacles. To fulfill your unfulfilled dreams, the universe will never hold back your progress. This is the essence of it."
——The final block message in the PoW era of Ethereum
Ethereum has undergone a historic upgrade, and its development has entered a new stage. After the merger, Ethereum will continue to advance 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 the centralization of the validator group, expansion, and the Lazy Validator Problem still restrict the outbreak of applications and the security expansion of Ethereum. This article will start from The Merge starts, gradually analyzing the consensus algorithm adopted by POS, focusing on exploring the use of DVT technology to solve the problem of single-point risk of verifiers, and analyzing the problems and future development opportunities of Ethereum with practitioners. Readers with a certain foundation in Ethereum are recommended to read this article.
1. The Merge
1.1 Background
The Merge is the largest technical upgrade in the history of Ethereum. On September 15, 2022, the Execution Layer and Consensus Layer were merged. The biggest change is to switch Ethereum's PoW consensus to PoS consensus.
Figure 1: The Merge
In addition, the energy consumption of Ethereum has been reduced by nearly 99.95% after the merger. According to Vitalik Buterin’s tweet, the merger of Ethereum will reduce global electricity consumption by 0.2%.
Figure 2: Vitalik's views on the energy consumption of the merged Ethereum
1.2 Changes brought about by the merger
Token issuance: The issuance of ETH tokens in the PoW era stops, new ETH is only generated through the PoS consensus, and the inflation rate of Ethereum is reduced. When the base fee exceeds 15gwei, Ethereum even enters deflation.
Figure 3: Burn Total after the merger
Pledge income: Gas fees and MEV income are allocated to Validator, and the validator's pledged currency standard income reaches 5-7%.
Figure 4: Rocket Pool Staking Yield
Withdraw: The ETH pledged after the merger cannot be withdrawn immediately, and the withdrawal restriction will be released after the upgrade in Shanghai, and the user cannot withdraw directly when withdrawing funds. In order to avoid large-scale withdrawals, for a single withdrawal There are certain restrictions on the amount and time of deposits, so after the withdrawal is opened, there will not be a large number of withdrawals and sell-offs. For specific information, please refer to EIP-4895: Beacon chain push withdrawals as operations
Data structure change: The Consensus Block will contain the Hash value of the Execution Block, and the parameters related to PoW in the Execution Block will no longer be valid. The mixHash field will record Ethereum's native RANDAO random number for EVM calls. 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's responsibilities are replaced by verifiers. There are two chains at the same time, and two client nodes need to be run at the same time, Execution Layer Client (EL) and Consensus Layer Client (CL).
Figure 6: The merged Ethereum client
After switching to the PoS consensus, the algorithm of Ethereum has been converted from Ethash to Casper FFG (Gasper). block, let us continue to explore the consensus algorithm and block generation method of Ethereum!
2. Gasper
Currently pledged on the beacon chain13,830,378 ETH, the number of active validators is432,203(as of September 23, 2022), according to the characteristics of PBFT, the number of verifiers in the 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 PBFT on the network structure The idea of network architecture has been improved and designed, using the Gasper algorithm.
Gasper is a finality tool (finality gadget) in the beacon chain protocol, which is used to determine which blocks should be recognized by participants as fixed and unchangeable, and is used to determine which forked chain is the main one when forking. chain. Gasper's finality generalizes concepts from the "Casper Friendly Finality Gadget (casper FFG)" paper.
Figure 7: Staking and Validator Situation
2.1 Concept
Figure 8: Illustration of Epoch and Slot
Slot (time slot): After merging, a Slot is a block, and a committee is responsible for generating the Slot within 12S.
Epoch: Every 32 Slots form an Epoch, and the time of one Epoch is 384S, that is, 6.4Min.
Committee: Each validator committee will allocate a minimum of 128 Validators. Validators will perform Attestation operations on the Slots they are responsible for, and one Validator in the committee will be randomly selected as a Proposer to generate blocks.
Attestation (voting signature): The Validator in the committee corresponding to each Slot needs to vote and sign the previous Epoch to ensure that it approves the transaction in the previous Epoch.
Validator (Validator): Since the consensus algorithm of Ethereum The Merge was switched to POS, the original miners were replaced by Validators. Validators become Validators by pledging 32ETH assets, and are responsible for participating in the block generation and signature work of slots in each Epoch.
Proposer (proposer): Proposer comes from the Validator in the committee, selected by the random number generated by RANDAO, and is selected for the packaging of the Slot block.
Beacon chain (beacon chain): The PoS blockchain used to replace the PoW consensus. The beacon chain node is used to mount the transaction type of Data Blobs to provide more storage space for Rollup.
2.2 Process
At the beginning of Epoch, RANDAO assigns a Committee (verifier committee) to each Slot (time slot) to conduct Attestation (signature voting) on the previous Epoch.
Allocate multiple Aggregators for the 32 slots of the current Epoch to aggregate the committee's Attestation of the previous Epoch and record it into the Slot block.
RANDAO determines that Proposer is responsible for generating blocks by generating random numbers.
Figure 9: Committee block generation
In the current Epoch, when each Slot is generating a block, the committee will perform Attestation on the checkpoint of the previous Epoch. After the Attestation of two checkpoints, the last checkpoint is Finalized until all 32 Slots are checked in turn. Attestation is carried out, and this round of Epoch ends. When the first Slot of Post-Epoch started, Pre-Epoch reached a final consensus, that is, Post-Epoch experienced Pre-Epoch and current Epoch, a total of two rounds of Epoch (because of the two Attestation checkpoints, If there are conflicting checkpoints, 1/3 of the verifiers must have done evil. For example, the three block heights of 32 64 96 may not reach the checkpoint at the height of 64, and there will be a checkpoint at the 96th. At this time, the 32nd The height is Finalised), the time is 12.8Min, and the transaction is confirmed on the chain, which is the so-called finality.
2.3 Features
RANDAO gives random numbers on the chain. The random number generated by RANDAO will be put into the Execution Layer Block, and the smart contract can directly use the random number. After having the native random number on the chain, DeFi may have new applications. For example, gambling DeFi applications can directly trust and random numbers generated using RANDAO.
Figure 10: RANDAO
2.4 Latest Message Driven GHOST (LMD-GHOST, GHOST driven by the latest message)
In the new POS consensus mechanism of Ethereum, LMD-GHOST is used as the fork selection rule. When a fork occurs, GHOST will select a subtree that receives more message support. The idea behind it is to reduce the amount of computation required to run GHOST by only considering each validator's most recent vote when calculating the chain head, rather than any votes generated in the past.
Those who want to learn more can refer to:https://eprint.iacr.org/2013/881.pdf
2.5 Consequent problems
Increased communication and verification costs: Is it better to have more verifiers? In fact, although the increase in the number of verifiers is conducive to data availability sampling (DAS) and decentralization, the increase in verifiers means that there will be more verifiers in a single slot, and Aggregator will be added when collecting the signatures of each verifier. In addition, the verification cost of the aggregated signature will also increase, which will increase the burden on the verifier node virtually.
Long-range attack: A long-range attack means that after a validator pledges ETH on the beacon chain in Withdraw, he can use the old private key to maliciously fork in a block that has been signed, because it is currently on the chain There is no longer any pledged assets, and then quickly generate empty blocks to the current block height to attack the network. This is also a possible attack method in the future. Ethereum was designed to vote on the checkpoint of Pre-Epoch, and its design idea is to continuously advance the initial state to avoid possible attacks.
3. Ethereum staking mining
3.1 Staking
Pledge threshold: In order to perform their duties and participate in consensus block generation, verifiers need to pledge 32ETH as a margin asset.
Responsibilities of the verifier: produce blocks and attestation at the time stipulated in the agreement.
3.1.1 Staking method
Solo Staking: The way of solo staking is that the pledger who wants to invest 32 ETH as a validator runs the validator node on the cloud server. In addition to choosing to run the node on the cloud server, you can also choose to place the server in your own home The device runs the Ethereum node. The difference is that the node running on the cloud service is more stable. When participating in the network consensus, it can avoid and reduce the penalty for slowing down due to power outages and network reasons. The advantage of building a node at home lies in the combination of hardware and network services. The cost is lower than that of cloud servers, and here the pledger can choose which hosting solution to use.
Staking Pool: Since 32 ETH is a lot of money for ordinary people, pledgers with ordinary small funds want to participate in the network consensus but cannot run nodes by themselves, so there is a pledge pool solution. The semi-decentralized pledge solution Lido is the main project, which has absorbed a large amount of funds and has become the leading solution in the track, followed by solutions with a higher degree of decentralization such as Rocket Pool and Swell etc. On top of the existing staking pool solutions, aggregation solutions such as Unamano have been created to help and develop the Ethereum Staking field.
In terms of node operation, Lido chooses to designate some professional operators to run network nodes, which is also a point of its relative centralization. The operator holds the signature private key, and the user's assets partly trust Lido and the operator. As for the withdrawal private key, Before July 2021, the withdrawal address is a 6/11 multi-signature address, and the multi-signature private key is kept by OG in the industry. After July 2021, the withdrawal address points to an upgradeable contract address, which is managed by DAO to manage. Rocket Pool chooses to be more decentralized in terms of nodes. Anyone only needs to provide 16 ETH and corresponding hardware and software equipment to run a node as an operator. Although the threshold for operators is lowered, Rocket Pool introduces $RPL pledge to reduce operating The risk of business doing evil.
Staking Pool’s solution enables ordinary users to deposit small amounts of ETH into the contract to obtain Ethereum’s mining rewards, and at the same time return interest-bearing tokens such as stETH and rETH to release the liquidity of pledged assets, which further enhances the Ethereum’s debit The degree of centralization and the efficiency of capital use are the most optimistic directions for the community.
CEX, centralized custodian: In addition to Solo Staking and Staking Pool, centralized exchanges and a number of asset management institutions are the main participants in Ethereum staking. For example, Coinbase and Binance have also launched their own staking services. Participate in low-risk Ethereum pledge mining by absorbing small amounts of ETH. The three schemes have their own advantages and disadvantages in terms of decentralization and security, which depend on the trustees of the pledgers, but there is no doubt that the three schemes have captured the corresponding funds and users, and jointly maintain the ether. Square security and decentralization.
3.1.2 Risks and hidden dangers
Is it really all right after the merger? I don’t think so. From the data in the figure below, we can take a peek at the situation after lifting the withdrawal restrictions on the beacon chain.
Figure 11: The whereabouts of pledged ETH after the merger
At present, the pledge amount of Ethereum is mainly concentrated in Lido, Coinbase and Solo Staking. After the merger, a large number of new Ethereum pledges flow to relatively centralized institutions and agreements such as Lido and Coinbase. After the withdrawal restrictions are lifted, I think The original pledged Ethereum will be redistributed to Lido and Coinbase. As time goes by, Lido and Coinbase will master more and more Ethereum verifiers and pledges, which will eventually bring decentralization to Ethereum. Serious threat, when they control Ethereum, for transactions that want to break this situation again, they will be rejected by large mining pools such as Lido or Coinbase, because the transaction you want to pledge ETH to Ethereum can They have the final say whether to go on the chain or not, and the newly generated ETH will also be concentrated in the hands of people with more ETH, because they have a large amount of ETH when they pledge, which will undoubtedly be beneficial to the decentralization of Ethereum. New challenges, we can expect the community and core developers to work together to solve this problem.
3.1.3 Reward Types
Attestation rewards: Each slot committee must perform Attestation on the previous Epoch historical block checkpoint. After successful Attestation, Attestation rewards will be obtained as one of the Validator's income. (high probability, low reward)
Figure 12: Attestation rewards
Block reward: Each Slot will have a Validator as a proposer to package the block, and the Validator selected as the proposer can get the block reward. (Low probability, more rewards)
Figure 13: Proposal rewards
MEV (miner extractable value) income: In addition to gas fee income, MEV income also includes income from sandwich attacks. According to EigenPhi's data, the volume of sandwich attacks in the past 7 days was above 100M, and the highest volume was close to 400M. MEV The income of the verifier has become one of the important income components of the verifier.
Figure 14: MEV situation after merger
3.1.4 Penalty types
Punishment for slow work: Failure to produce blocks according to consensus expectations: Attestation of blocks was not performed at the expected time.
Malicious behavior leads to slash (slash): two blocks are produced in a single Slot or two Attestations are performed; wrong blocks are proposed in violation of the Casper FFG consensus rules.
3.2 Private key type
Signature private key: The signature private key is used by the verifier to sign messages when performing duties, including attesting and proposing blocks. This key will be used once every 6.4 minutes, that is, every Epoch.
Withdrawal private key: The key used to extract pledged assets and block rewards needs to be stored offline. After the Shanghai fork, the pledged ETH and rewards can be withdrawn with the withdrawal private key.
3.3 ETH2 pledge risk
Stolen private key: ETH2's signing/withdrawal private key was stolen.
Single Point of Failure/Validator Availability: Currently, validators exist and perform their duties as a single machine or node. The protocol's strict rules prohibit common forms of redundancy, such as running the same validator on multiple nodes, which could result in the validator being "slashed". If using a staking service, the keys are located on a cloud server (such as AWS). If any component fails, validators are penalized by stopping validating.
4. Distributed Verifier Technology (DVT)
At the pledge level, although we have a decentralized pledge solution to lower the pledge threshold and improve the decentralization of pledge services, but at the Validator level, there is still a single point of risk. Now a single validator runs multiple clients of the network At the end, if due to network reasons or physical factors such as power outages will cause slowdown penalties, the slot will not be able to collect valid signatures, and we cannot run the same validator node in multiple places in a redundant manner, because this will cause signature The chaos will be considered as an attack on the network, but we can split the signature private key and use DVT technology to reduce the risk of single point of failure. Due to the network upgrade, a large area of nodes are offline. For specific analysis, please let us explore further!
4.1 Concept
operator: A person or entity that runs a node (or nodes).
operator node: Refers to a piece of hardware and software that performs the tasks of an Ethereum validator. These tasks can be done by a node alone or jointly with other nodes using DVT tools.
Distributed validator technology: Distributed validator technology is a technology that distributes the work of a single Ethereum validator to a group of decentralized nodes. Compared with validator clients running on a single machine, distributed validator technology can provide more secure and decentralized services.
Figure 15: Relationship between Validator, Nodes, Committees and Operators
4.2 Distributed validator nodes need to run
Ethereum execution layer client
Ethereum consensus layer client
Ethereum Distributed Validator Client
Ethereum validator client
4.3 How DV prevents ETH2 pledge risk
private key stolen
The use of threshold signature technology (m-of-n) can prevent the risk of private key theft
A full validator key is split into multiple smaller keys
The split keys are aggregated to generate the signature of the full key
Figure 16: Key split and aggregate signature
node down
Crash Faults：
Reasons: crashes caused by power outages, network outages, hardware failures, and software errors;
Preventive measures: prevent node from going offline by running a redundant backup scheme of the same node in multiple places;
Byzantine Faults：
Cause: Caused by software bugs and network attacks;
Preventive measures: multiple participating nodes make decisions through consensus, and a single node cannot make a decision.
4.4 Overall Architecture
Figure 17: DVT overall architecture
Distributed validators remotely sign messages using private key shards
In the distributed verifier client, the signature of the distributed verifier is aggregated through the aggregated signature technology, and the block is signed after reaching the threshold.
4.5 Two paths to realize DVT technology
An approach to DVT using SSS: This scheme creates signature private keys (sk, pk) and withdrawal private keys by entities that pledge 32 ETH, and runs a Secret Sharing Scheme program to securely distribute the share of sk keys among committee nodes .
An approach to DVT using a DKG protocol: In the DKG scheme, there is no one entity to distribute the share of the private signing key to the verifier, but a group of verifier committee nodes to run the DKG protocol together. Therefore, a secret key and public key (sk, pk), and n shares sk_1, ..., sk_n of sk are created, and the ith node of i=1, ...n owns share sk_i.
Figure 18: DKG Protocol
4.6 Threshold Signature Schemes (TSS) (threshold signature scheme)
When the verifier agrees on the block and needs to sign, the BLS threshold signature scheme is used to realize the signature. It allows N verifiers to co-sign data, and a full signature is achieved if t+1(0) verifiers sign correctly. Through the tss scheme, it is realized that each verifier cannot obtain a complete signature private key, and it also ensures the smooth generation of a complete signature.
5. View DVT from mainstream projects
5.1 SSV
On the face of it, SSV provides a robust, decentralized entry into the Ethereum staking ecosystem. Going a little deeper, SSV is a complex multi-signature wallet with a consensus layer, and SSV acts as a buffer between beacon chain nodes and validator clients.
5.1.1 The main components of the configuration
Distributed Key Generation: The operator calculates and generates a shared public and private key set by running the SSV program. Each operator only owns a single portion of the private key, ensuring that no single operator can influence or control the entire private key to make unilateral decisions.
Shamir Secret Sharing: This mechanism is used to reconstruct the authenticator key using a predefined threshold of KeyShares, a single KeyShared cannot be used to sign messages. SSV is able to aggregate signatures using BLS technology to create a verifier's full key signature. By combining Shamir and BLS, the verifier's signature private key is shared by slices and aggregated and reassembled when signatures are required.
Multi-Party Computation: Apply secure multi-party computation (MPC) to secret sharing, allowing SSV's KeyShares to be securely distributed among operators, and decentralized computation to perform verifier responsibilities without rebuilding verifier keys on individual devices .
Istanbul Byzantine Fault Tolerance Consensus: Tying it all together is SSV's consensus layer, based on the Istanbul Byzantine Fault Tolerance (IBFT) algorithm. The algorithm randomly selects a validator node (KeyShare), responsible for block proposals and sharing information with other participants. Once a predetermined threshold of KeyShares deems the block valid, it is added to the chain. Thus, consensus can be reached even if some operators (up to a threshold) are faulty or not currently online.
Figure 19: SSV V2 Network Topology
5.1.2 Three types of participants in SSV ecology
Stakers: Exchanges, facilitators or individual ETH holders utilizing SSV/DVT technology for optimal effectiveness, security and decentralization of their validators. Stakers pay operators in SSV tokens to manage their validators.
Operators: Operators provide the hardware infrastructure, run the SSV protocol, and are responsible for maintaining the overall health of the validator and ssv. network. Operators determine their service fees in SSV tokens and charge validators a fee for operating and maintaining validators.
DAO (SSV token holders): ssv.network DAO decentralizes the ownership and governance of the ssv.network protocol and funds, and SSV is the native token of the network. Anyone with SSV tokens can participate in the DAO, voting on proposals and other items requiring voting. The number of SSV tokens owned determines voting power on decisions affecting the network.
5.1.3 ssv.network DAO is responsible for the following tasks:
Operator scoring: ssv.network relies on operators and a 0-100% decentralized and transparent scoring of their quality, experience, and services provided. The DAO is also responsible for reviewing "Verified Operators" (VOs) and maintaining a list of VOs. Stakers can view and use these rankings to select Operators that manage their validators
Network fees: In order to use ssv.network, Stakers need to pay network fees. The network fee is a flat fee charged per validator that 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: Network fees paid by stakers fund the DAO treasury, which is used for projects that grow the SSV protocol and ecosystem. May include grants for protocol development and network growth, direct revenue sharing with SSV token holders, marketing and community incentives, token swaps to diversify the treasury, and investments from strategic partners in exchange for SSV tokens.
Voting: Grant requests and other proposals submitted to the DAO that require voting. Anyone holding SSV tokens can vote on decisions affecting the DAO, such as grant requests, requests to become a verification operator, and other ideas or requests submitted to the DAO for consideration.
5.2 Obol
Obol is a protocol that promotes the minimization of staking trust through a multi-operator. This protocol can be used as a core module of various web3 products to obtain Ethereum pledge benefits at a low trust cost.
5.2.1 Obol's four core public products:
Distributed Validator Launchpad: CLI tool and dApp to bootstrap Distributed Validator
Charon: Charon is Obol Network's distributed validator client and the first step towards enabling trust-minimized verification. Charon supports fault-tolerant, high-availability validation, enabling a group of people to run validators collectively on multiple machines instead of a single one.
Figure 20: Charon internal architecture
Obol Managers: A set of reliable smart contracts for forming distributed validators
Obol Testnets: A set of ongoing public incentivized testnets enabling operators of any size to test their deployments before serving the Obol mainnet network.
5.2.2 Key concepts:
Distributed Validator: A distributed validator is an Ethereum proof-of-stake validator running on multiple nodes/machines. This functionality is achieved using Distributed Validator Technology (DVT). Distributed validator technology avoids the problem of single point of failure. If <33% of the participating nodes in the DVT cluster go offline, the remaining active nodes can still reach a consensus on signing and generate valid signatures for Staking validators. This is an active redundancy approach, a common pattern used to minimize downtime for mission-critical systems.
Distributed Validator Node: A distributed validator node is a set of clients that an operator needs to configure and run to fulfill the duties of a distributed validator operator. Operators can run redundant execution and consensus clients on the same hardware, run execution layer relayers (such as mev-boost), and other instrumentation services to ensure optimal performance. In the above example, the client stack includes Geth, Lighthouse, Charon, and Teku.
Figure 21: Obol client example
Execution Client: The execution layer client (formerly known as Eth1 client) is responsible for running the EVM and managing the transaction pool of the Ethereum network.
Execution layer clients include: Go-Ethereum, Nethermind, Erigon.
Consensus Cilent: The responsibility of the consensus client is to run Ethereum's proof-of-stake consensus layer, commonly known as the beacon chain. Consensus layer clients include: Prysm, Teku, Lighthouse, Nimbus, Lodestra.
Distributed Validator Client：
The distributed validator client intercepts the information flow of the validator client↔consensus layer client through a standardized REST API, and focuses on two core responsibilities:
Consensus on candidate responsibilities signed by all validators
Combine the signatures of all validators into a distributed validator signature
Validator Client: A validator client is a piece of code that runs one or more Ethereum validators.
Validator clients include: Vouch, Prysm, Teku, Lighthouse
Distributed Validator Cluster: A distributed validator cluster is a collection of distributed validator nodes connected together.
Distributed Validator Key: Distributed Validator Key is a set of BLS private keys, which together serve as threshold keys for participating in the proof-of-stake consensus.
Distributed Validator Key Share: A private key of the distributed validator's private key.
Distributed Validator Key Generation Ceremony: To achieve fault tolerance in a distributed validator, individual private key shares need to be generated together. Rather than having a trusted dealer generate a private key, split it up and distribute it, each operator in a distributed validator cluster participates in a so-called distributed key generation ceremony, which has the advantage that at no time A complete private key is constructed. The distributed validator key generation ceremony is a type of DKG ceremony. The ceremony produces signed validator deposit and exit data, as well as all validator key shares and their associated metadata.
6. Summary and Outlook
6.1 Summary
Throughout the article, starting from The Merge, it describes the Casper FFG algorithm adopted by Ethereum after the merger, familiarizes itself with the block generation method and some new technical concepts after the merger, and then talks about the new mining method of Ethereum and the existing The staking solution, learned about the single point of failure problem of the validator, and then went deep into the DVT technology, and briefly described how DVT solved this problem through the case of two projects. The whole article is described according to the idea of decentralization, for It provides a certain reference for readers to understand the consensus algorithm of Ethereum and the development direction of decentralization.
6.2 Outlook
After The Merge, Ethereum will gradually implement Danksharding. Firstly, EIP-4488 will reduce the gas cost of calldata from 16gwei to 3gwei, which will provide strong support for the speed-up and expansion of rollup. The next step is in Proto-danksharding The introduction of the Blobs transaction type enables Ethereum to provide more storage space for rollup, reduce D/A costs, 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 there are enough nodes in the Ethereum network and decentralization enough for data availability sampling to be implemented. That is to say, to ensure expansion and low-cost D/A, the decentralization of Ethereum is the most important part, because the decentralized pledge scheme and DVT and other technologies are crucial to the subsequent development of Ethereum.
Original link
References
https://www.ethereum.cn/validated-staking-on-eth2-2-two-ghosts-in-a-trench-coat
2.https://www.youtube.com/watch?v=awBX1SrXOhk
3.https://github.com/ObolNetwork/
4.https://www.ethereum.cn/Eth2/distributed-validator-specs
5.https://medium.com/nethermind-eth/sorting-out-distributed-validator-technology-a6f8ca1bbce3
6.https://docs.ssv.network/learn/introduction
8.https://ecn.mirror.xyz/kFzA6fZKF-qIjAOvOkJT03WizNea0Bo2Gx6tUDamFsY
10.https://twitter.com/VitalikButerin/status/1570299062800510976?s=19
15.https://ethos.dev/beacon-chain/
16.https://medium.com/nethermind-eth/sorting-out-distributed-validator-technology-a6f8ca1bbce3
IOS
Android