Architecture of the Solana Validator

Clusters

Overview

Overview of a Solana Cluster

A Solana cluster is a set of validators working together to serve client transactions and maintain the integrity of the ledger. Many clusters may coexist. When two clusters share a common genesis block, they attempt to converge. Otherwise, they simply ignore the existence of the other. Transactions sent to the wrong one are quietly rejected. In this section, we’ll discuss how a cluster is created, how nodes join the cluster, how they share the ledger, how they ensure the ledger is replicated, and how they cope with buggy and malicious nodes.

Solana 集群概述
Solana 集群是一组协同工作的验证器，为客户端交易提供服务并维护账本的完整性。许多集群可能共存。当两个集群共享一个共同的创世块时，它们会尝试聚合。否则，他们就会忽视对方的存在。发送给错误的交易会被悄悄拒绝。在本节中，我们将讨论如何创建集群、节点如何加入集群、如何共享账本、如何确保账本被复制以及如何应对有问题和恶意的节点。

Creating a Cluster​

Before starting any validators, one first needs to create a genesis config. The config references two public keys, a mint and a bootstrap validator. The validator holding the bootstrap validator’s private key is responsible for appending the first entries to the ledger. It initializes its internal state with the mint’s account. That account will hold the number of native tokens defined by the genesis config. The second validator then contacts the bootstrap validator to register as a validator. Additional validators then register with any registered member of the cluster.

A validator receives all entries from the leader and submits votes confirming those entries are valid. After voting, the validator is expected to store those entries. Once the validator observes a sufficient number of copies exist, it deletes its copy.

在启动任何验证器之前，首先需要创建一个创世配置。该配置引用两个公钥，一个铸币厂和一个引导验证器。持有引导验证器私钥的验证器负责将第一个条目附加到分类帐中。它使用铸币厂的帐户初始化其内部状态。该帐户将保存由创世配置定义的本机令牌数量。然后，第二个验证器联系引导验证器以注册为验证器。然后，其他验证者向集群的任何注册成员注册。

验证者接收来自领导者的所有条目，并提交投票以确认这些条目有效。投票后，验证者应存储这些条目。一旦验证器观察到存在足够数量的副本，它就会删除其副本。

Joining a Cluster​

Validators enter the cluster via registration messages sent to its control plane. The control plane is implemented using a gossip protocol, meaning that a node may register with any existing node, and expect its registration to propagate to all nodes in the cluster. The time it takes for all nodes to synchronize is proportional to the square of the number of nodes participating in the cluster. Algorithmically, that’s considered very slow, but in exchange for that time, a node is assured that it eventually has all the same information as every other node, and that information cannot be censored by any one node.

验证器通过发送到其控制平面的注册消息进入集群。控制平面是使用八卦协议实现的，这意味着节点可以向任何现有节点注册，并期望其注册传播到集群中的所有节点。所有节点同步所需的时间与参与集群的节点数的平方成正比。从算法上来说，这被认为是非常慢的，但作为这段时间的交换，节点可以确保它最终拥有与所有其他节点相同的信息，并且该信息不能被任何一个节点审查。

Sending Transactions to a Cluster​

Clients send transactions to any validator’s Transaction Processing Unit (TPU) port. If the node is in the validator role, it forwards the transaction to the designated leader. If in the leader role, the node bundles incoming transactions, timestamps them creating an entry, and pushes them onto the cluster’s data plane. Once on the data plane, the transactions are validated by validator nodes, effectively appending them to the ledger.

客户端将交易发送到任何验证器的交易处理单元（TPU）端口。如果节点处于验证者角色，它将事务转发给指定的领导者。如果处于领导者角色，节点会捆绑传入的事务，为它们添加时间戳以创建条目，并将它们推送到集群的数据平面上。一旦进入数据平面，交易就会由验证器节点进行验证，从而有效地将它们附加到分类账中。

Confirming Transactions​

A Solana cluster is capable of subsecond confirmation for thousands of nodes with plans to scale up to hundreds of thousands of nodes. Confirmation times are expected to increase only with the logarithm of the number of validators, where the logarithm’s base is very high. If the base is one thousand, for example, it means that for the first thousand nodes, confirmation will be the duration of three network hops plus the time it takes the slowest validator of a supermajority to vote. For the next million nodes, confirmation increases by only one network hop.

Solana 集群能够对数千个节点进行亚秒级确认，并计划扩展到数百个节点数千个节点。预计确认时间只会随着验证者数量的对数而增加，其中对数的底数非常高。例如，如果基数为 1000，则意味着对于前 1000 个节点，确认将是三个网络跳的持续时间加上绝大多数验证者中最慢的验证者投票所需的时间。对于接下来的一百万个节点，确认仅增加一个网络跃点。

Solana defines confirmation as the duration of time from when the leader timestamps a new entry to the moment when it recognizes a supermajority of ledger votes.

Scalable confirmation can be achieved using the following combination of techniques:

1. Timestamp transactions with a VDF sample and sign the timestamp.
2. Split the transactions into batches, send each to separate nodes and have each node share its batch with its peers.
3. Repeat the previous step recursively until all nodes have all batches.

Solana 将确认定义为从领导者为新条目添加时间戳到识别绝大多数账本投票那一刻的持续时间。
可扩展确认可以使用以下技术组合来实现：

1. 使用 VDF 样本对事务进行时间戳记并签署时间戳。
2. 将事务拆分为批次，将每个事务发送到单独的节点，并使每个节点与其对等节点共享其批次。
3. 递归地重复上一步，直到所有节点都拥有所有批次。

Solana rotates leaders at fixed intervals, called slots. Each leader may only produce entries during its allotted slot. The leader therefore timestamps transactions so that validators may lookup the public key of the designated leader. The leader then signs the timestamp so that a validator may verify the signature, proving the signer is owner of the designated leader’s public key.

Solana 以固定间隔（称为槽）轮换领导者。每个领导者只能在其分配的时段内产生条目。因此，领导者会为交易添加时间戳，以便验证者可以查找指定领导者的公钥。然后，领导者对时间戳进行签名，以便验证者可以验证签名，证明签名者是指定领导者公钥的所有者。

Next, transactions are broken into batches so that a node can send transactions to multiple parties without making multiple copies. If, for example, the leader needed to send 60 transactions to 6 nodes, it would break that collection of 60 into batches of 10 transactions and send one to each node. This allows the leader to put 60 transactions on the wire, not 60 transactions for each node. Each node then shares its batch with its peers. Once the node has collected all 6 batches, it reconstructs the original set of 60 transactions.

接下来，交易被分成批次，以便节点可以将交易发送给多方，而无需进行多次交易。副本。例如，如果领导者需要向 6 个节点发送 60 个交易，它会将这 60 个交易分成 10 个交易批次，并向每个节点发送一个。这允许领导者在线上放置 60 个交易，而不是每个节点 60 个交易。然后，每个节点与其对等节点共享其批次。一旦节点收集了所有 6 个批次，它就会重建原始的 60 个交易集。

A batch of transactions can only be split so many times before it is so small that header information becomes the primary consumer of network bandwidth. At the time of this writing (December, 2021), the approach is scaling well up to about 1,250 validators. To scale up to hundreds of thousands of validators, each node can apply the same technique as the leader node to another set of nodes of equal size. We call the technique Turbine Block Propagation.

一批交易只能被分割多次，否则它会变得很小，以至于标头信息成为网络带宽的主要消耗者。截至撰写本文时（2021 年 12 月），该方法已扩展到约 1,250 个验证者。为了扩展到数十万个验证器，每个节点可以将与领导节点相同的技术应用于另一组相同大小的节点。我们将该技术称为涡轮块传播。

Solana Clusters

Available Solana Clusters

Solana maintains several different clusters with different purposes.
Before you begin make sure you have first installed the Solana command line tools

Explorers:

http://explorer.solana.com/.
http://solanabeach.io/.

Devnet

Devnet serves as a playground for anyone who wants to take Solana for a test drive, as a user, token holder, app developer, or validator.
Application developers should target Devnet.
Potential validators should first target Devnet.
Key differences between Devnet and Mainnet Beta:
Devnet tokens are not real
Devnet includes a token faucet for airdrops for application testing
Devnet may be subject to ledger resets
Devnet typically runs the same software release branch version as Mainnet Beta, but may run a newer minor release version than Mainnet Beta.
Gossip entrypoint for Devnet: entrypoint.devnet.solana.com:8001
Metrics environment variable for Devnet:

export SOLANA_METRICS_CONFIG="host=https://metrics.solana.com:8086,db=devnet,u=scratch_writer,p=topsecret"

RPC URL for Devnet: https://api.devnet.solana.com

Example solana command-line configuration

solana config set --url https://api.devnet.solana.com

Example solana-validator command-line

$ solana-validator \
    --identity validator-keypair.json \
    --vote-account vote-account-keypair.json \
    --known-validator dv1ZAGvdsz5hHLwWXsVnM94hWf1pjbKVau1QVkaMJ92 \
    --known-validator dv2eQHeP4RFrJZ6UeiZWoc3XTtmtZCUKxxCApCDcRNV \
    --known-validator dv4ACNkpYPcE3aKmYDqZm9G5EB3J4MRoeE7WNDRBVJB \
    --known-validator dv3qDFk1DTF36Z62bNvrCXe9sKATA6xvVy6A798xxAS \
    --only-known-rpc \
    --ledger ledger \
    --rpc-port 8899 \
    --dynamic-port-range 8000-8020 \
    --entrypoint entrypoint.devnet.solana.com:8001 \
    --entrypoint entrypoint2.devnet.solana.com:8001 \
    --entrypoint entrypoint3.devnet.solana.com:8001 \
    --entrypoint entrypoint4.devnet.solana.com:8001 \
    --entrypoint entrypoint5.devnet.solana.com:8001 \
    --expected-genesis-hash EtWTRABZaYq6iMfeYKouRu166VU2xqa1wcaWoxPkrZBG \
    --wal-recovery-mode skip_any_corrupted_record \
    --limit-ledger-size

The --known-validators are operated by Solana Labs

Testnet

Testnet is where the Solana core contributors stress test recent release features on a live cluster, particularly focused on network performance, stability and validator behavior.
Testnet tokens are not real
Testnet may be subject to ledger resets.
Testnet includes a token faucet for airdrops for application testing
Testnet typically runs a newer software release branch than both Devnet and Mainnet Beta
Gossip entrypoint for Testnet: entrypoint.testnet.solana.com:8001
Metrics environment variable for Testnet:

export SOLANA_METRICS_CONFIG="host=https://metrics.solana.com:8086,db=tds,u=testnet_write,p=c4fa841aa918bf8274e3e2a44d77568d9861b3ea"

RPC URL for Testnet: https://api.testnet.solana.com
Example solana command-line configuration

solana config set --url https://api.testnet.solana.com

Example solana-validator command-line

$ solana-validator \
    --identity validator-keypair.json \
    --vote-account vote-account-keypair.json \
    --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \
    --known-validator dDzy5SR3AXdYWVqbDEkVFdvSPCtS9ihF5kJkHCtXoFs \
    --known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \
    --known-validator eoKpUABi59aT4rR9HGS3LcMecfut9x7zJyodWWP43YQ \
    --known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \
    --only-known-rpc \
    --ledger ledger \
    --rpc-port 8899 \
    --dynamic-port-range 8000-8020 \
    --entrypoint entrypoint.testnet.solana.com:8001 \
    --entrypoint entrypoint2.testnet.solana.com:8001 \
    --entrypoint entrypoint3.testnet.solana.com:8001 \
    --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY \
    --wal-recovery-mode skip_any_corrupted_record \
    --limit-ledger-size

The identities of the --known-validators are:

5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on - Solana Labs
dDzy5SR3AXdYWVqbDEkVFdvSPCtS9ihF5kJkHCtXoFs - MonkeDAO
Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN - Certus One
eoKpUABi59aT4rR9HGS3LcMecfut9x7zJyodWWP43YQ - SerGo
9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv - Algo|Stake

Mainnet Beta

A permissionless, persistent cluster for Solana users, builders, validators and token holders.
Tokens that are issued on Mainnet Beta are real SOL
Gossip entrypoint for Mainnet Beta: entrypoint.mainnet-beta.solana.com:8001
Metrics environment variable for Mainnet Beta:

export SOLANA_METRICS_CONFIG="host=https://metrics.solana.com:8086,db=mainnet-beta,u=mainnet-beta_write,p=password"

RPC URL for Mainnet Beta: https://api.mainnet-beta.solana.com
Example solana command-line configuration

solana config set --url https://api.mainnet-beta.solana.com

Example solana-validator command-line

$ solana-validator \
    --identity ~/validator-keypair.json \
    --vote-account ~/vote-account-keypair.json \
    --known-validator 7Np41oeYqPefeNQEHSv1UDhYrehxin3NStELsSKCT4K2 \
    --known-validator GdnSyH3YtwcxFvQrVVJMm1JhTS4QVX7MFsX56uJLUfiZ \
    --known-validator DE1bawNcRJB9rVm3buyMVfr8mBEoyyu73NBovf2oXJsJ \
    --known-validator CakcnaRDHka2gXyfbEd2d3xsvkJkqsLw2akB3zsN1D2S \
    --only-known-rpc \
    --ledger ledger \
    --rpc-port 8899 \
    --private-rpc \
    --dynamic-port-range 8000-8020 \
    --entrypoint entrypoint.mainnet-beta.solana.com:8001 \
    --entrypoint entrypoint2.mainnet-beta.solana.com:8001 \
    --entrypoint entrypoint3.mainnet-beta.solana.com:8001 \
    --entrypoint entrypoint4.mainnet-beta.solana.com:8001 \
    --entrypoint entrypoint5.mainnet-beta.solana.com:8001 \
    --expected-genesis-hash 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d \
    --wal-recovery-mode skip_any_corrupted_record \
    --limit-ledger-size

Benchmark a Cluster

The Solana git repository contains all the scripts you might need to spin up your own local testnet. Depending on what you’re looking to achieve, you may want to run a different variation, as the full-fledged, performance-enhanced multinode testnet is considerably more complex to set up than a Rust-only, singlenode testnode. If you are looking to develop high-level features, such as experimenting with smart contracts, save yourself some setup headaches and stick to the Rust-only singlenode demo. If you’re doing performance optimization of the transaction pipeline, consider the enhanced singlenode demo. If you’re doing consensus work, you’ll need at least a Rust-only multinode demo. If you want to reproduce our TPS metrics, run the enhanced multinode demo.

For all four variations, you’d need the latest Rust toolchain and the Solana source code:

First, setup Rust, Cargo and system packages as described in the Solana README

Now checkout the code from github:

git clone https://github.com/solana-labs/solana.git
cd solana

Solana git 存储库包含启动您自己的本地测试网可能需要的所有脚本。根据您想要实现的目标，您可能需要运行不同的变体，因为成熟的、性能增强的多节点测试网的设置比仅使用 Rust 的单节点测试节点要复杂得多。如果您希望开发高级功能，例如尝试智能合约，请避免一些设置麻烦并坚持使用仅 Rust 的单节点演示。如果您正在对事务管道进行性能优化，请考虑增强的单节点演示。如果您正在进行共识工作，您至少需要一个仅 Rust 的多节点演示。如果您想重现我们的 TPS 指标，请运行增强型多节点演示。
对于所有四种变体，您需要最新的 Rust 工具链和 Solana 源代码：
首先，将 Rust、Cargo 和系统包设置为Solana README 中进行了描述

The demo code is sometimes broken between releases as we add new low-level features, so if this is your first time running the demo, you’ll improve your odds of success if you check out the latest release before proceeding:

当我们添加新的低级功能时，演示代码有时会在版本之间被破坏，因此，如果这是您第一次运行演示，如果您在继续之前查看最新版本，您将提高成功的几率：

TAG=$(git describe --tags $(git rev-list --tags --max-count=1))
git checkout $TAG

Configuration Setup

Ensure important programs such as the vote program are built before any nodes are started. Note that we are using the release build here for good performance. If you want the debug build, use just cargo build and omit the NDEBUG=1 part of the command.

确保在启动任何节点之前构建重要程序（例如投票程序）。请注意，我们在这里使用发布版本以获得良好的性能。如果您想要调试版本，请仅使用货物构建并省略命令的 NDEBUG=1 部分。

Faucet

In order for the validators and clients to work, we’ll need to spin up a faucet to give out some test tokens. The faucet delivers Milton Friedman-style “air drops” (free tokens to requesting clients) to be used in test transactions.

为了使验证器和客户端正常工作，我们需要启动水龙头来发出一些测试令牌。水龙头提供米尔顿·弗里德曼式的“空投”（向请求客户提供免费代币）以用于测试交易。
通过以下方式启动水龙头：

Start the faucet with:

NDEBUG=1 ./multinode-demo/faucet.sh

Singlenode Testnet

Before you start a validator, make sure you know the IP address of the machine you want to be the bootstrap validator for the demo, and make sure that udp ports 8000-10000 are open on all the machines you want to test with.

在启动验证器之前，请确保您知道要用作演示的引导验证器的计算机的 IP 地址，并确保在要测试的所有计算机上打开 udp 端口​​ 8000-10000。
现在在单独的 shell 中启动引导验证器：

Now start the bootstrap validator in a separate shell:

NDEBUG=1 ./multinode-demo/bootstrap-validator.sh

Wait a few seconds for the server to initialize. It will print “leader ready…” when it’s ready to receive transactions. The leader will request some tokens from the faucet if it doesn’t have any. The faucet does not need to be running for subsequent leader starts.

等待几秒钟，让服务器初始化。当它准备好接收交易时，它将打印“leader Ready…”。如果水龙头没有令牌，领导者会向水龙头请求一些令牌。后续领导启动时不需要运行水龙头。

Multinode Testnet

To run a multinode testnet, after starting a leader node, spin up some additional validators in separate shells:

NDEBUG=1 ./multinode-demo/validator-x.sh

To run a performance-enhanced validator on Linux, CUDA 10.0 must be installed on your system:

./fetch-perf-libs.sh
NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/bootstrap-validator.sh
NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/validator.sh

Testnet Client Demo

Now that your singlenode or multinode testnet is up and running let’s send it some transactions!

In a separate shell start the client:

NDEBUG=1 ./multinode-demo/bench-tps.sh # runs against localhost by default

What just happened? The client demo spins up several threads to send 500,000 transactions to the testnet as quickly as it can. The client then pings the testnet periodically to see how many transactions it processed in that time. Take note that the demo intentionally floods the network with UDP packets, such that the network will almost certainly drop a bunch of them. This ensures the testnet has an opportunity to reach 710k TPS. The client demo completes after it has convinced itself the testnet won’t process any additional transactions. You should see several TPS measurements printed to the screen. In the multinode variation, you’ll see TPS measurements for each validator node