Solana验证节点设备网络要求以及质押奖励处罚机制

　　在 Solana 上运行验证器没有严格的最低 SOL 数量要求。
　　然而，为了参与共识，需要一个具有 0.02685864 SOL 的免租储备的投票账户。投票还需要为验证者同意的每个区块发送投票交易，这可能每天花费高达 1.1 SOL。
　　注意： 默认情况下，您的验证者将没有权益。 这意味着它将没有资格成为领导者。（不质押没有收益或者收益极低。） 硬件建议#中央处理器12 核 / 24 线程，或更多2.8GHz 或更快AVX2 指令支持（使用官方发布的二进制文件，否则自编译）支持 AVX512f 和/或 SHA-NI 指令很有帮助AMD Zen3 系列深受验证者社区的欢迎 内存128GB 或更多建议使用 256GB 容量的主板 磁盘PCIe Gen3 x4 NVME SSD，或更好帐户：500GB 或更大。高 TBW（写入的总字节数）分类帐：1TB 或更大。建议高 TBW操作系统：（可选）500GB 或更大。SATA OK操作系统可能安装在分类帐磁盘上，但测试表明分类帐在其自己的磁盘上具有更好的性能账户和账本 可以 存储在同一个磁盘上，但是由于 IOPS 较高，不建议这样做三星 970 和 980 Pro 系列 SSD 深受验证者社区的欢迎 图形处理器目前不是绝对必要的建议未来增加一个或多个高端 GPU 的主板和电源 RPC 节点建议#
　　如果要将验证器用作 RPC 节点，则应将上述硬 件建议视为最低要求。为了提供完整的功能并提高可靠性，应进行以下调整。 中央处理器16核/32线程，或更多 内存256 GB 或更多 磁盘如果需要更长的交易历史，请考虑使用更大的分类帐磁盘帐户和分类帐不应存储在同一磁盘上 云平台上的虚拟机#
　　虽然您可以在云计算平台上运行验证器，但从长远来看，它可能并不具有成本效益。
　　但是，在 VM 实例上运行非投票 api 节点以供您自己的内部使用可能会很方便。此用例包括基于 Solana 构建的交易所和服务。
　　事实上，该团队运营的 mainnet-beta 验证器目前（2021 年 3 月）运行在n2-standard-32具有 2048 GB SSD 的 GCE（32 个 vCPU，128 GB 内存）实例上，以方便操作。
　　对于其他云平台，请选择具有相似规格的实例类型。
　　另请注意，出口互联网流量使用可能会很高，尤其是在运行质押验证器的情况下。 Docker#
　　不建议在 Docker 内运行实时集群（包括 mainnet-beta）的验证器，通常也不支持。这是由于担心一般 Docker 的容器化开销和导致的性能下降，除非特别配置。
　　我们仅将 Docker 用于开发目的。Docker Hub 包含solanalabs/solana中所有版本的映像。 软件#我们在 Ubuntu 20.04 上构建和运行。 有关当前 Solana 软件版本，请参阅安装 Solana。
　　预构建的二进制文件可用于支持 AVX2 的 CPU 上的 Linux x86_64 （推荐 Ubuntu 20.04 ）。MacOS 或 WSL 用户可以从源代码构建。 网络#
　　互联网服务至少应为 300Mbit/s 对称、商用。1GBit/s 优先 端口转发#
　　对于入站和出站，以下端口需要对 Internet 开放
　　不建议在 NAT 后面运行验证器。选择这样做的操作员应该能够轻松地配置他们的网络设备并自行调试任何遍历问题。 必填#8000-10000 TCP/UDP - P2P 协议（ 八卦、涡轮、维修等）。这可以限制为任何免费的 13 端口范围--dynamic-port-range 可选#
　　出于安全目的，不建议在质押的主网 beta 验证器上向互联网开放以下端口。 8899 TCP - 基于 HTTP 的 JSONRPC。使用 `--rpc-port RPC_PORT` 进行更改 8900 TCP - 基于 Websocket 的 JSONRPC。衍生的。用途RPC_PORT + 1 GPU 要求#
　　需要 CUDA 才能使用系统上的 GPU。提供的 Solana 发行版二进制文件基于 Ubuntu 20.04 和CUDA Toolkit 10.1 update 1构建。如果您的机器使用不同的 CUDA 版本，那么您将需要从源代码重建。
　　提示：solana验证器可以组验证集群。
　　验证器性能测试参考:
　　验证器软件部署到具有 1TB pd-ssd 磁盘和 2 个 Nvidia V100 GPU 的 GCP n1-standard-16 实例。这些部署在 us-west-1 区域。
　　solana-bench-tps 在网络从具有 n1-standard-16 CPU-only 实例的客户端机器收敛后启动，具有以下参数：--tx_count=50000 --thread-batch-sleep 1000
　　TPS 和确认指标是在 bench-tps 传输阶段开始时的平均 5 分钟内从仪表板数字中捕获的。 质押奖励
　　此处概述了权益证明( PoS ) （即使用协议内资产 SOL 来提供安全共识）设计。Solana 为集群中的验证者节点实施权益证明奖励/安全方案。目的有三个： 通过风险中的游戏存款使验证者激励与更大集群的激励保持一致 通过实施旨在促进分叉收敛的削减规则来避免＂没有任何风险＂的分叉投票问题 为验证者奖励提供途径，作为验证者参与集群的功能。
　　虽然目前正在考虑具体实施的许多细节，预计将通过 Solana 测试网上的具体建模研究和参数探索来关注，但我们在此概述我们目前对 PoS 系统主要组件的思考。这种想法大部分基于 Casper FFG 的当前状态，并根据 Solana 的历史证明( PoH )区块链数据结构允许进行优化和修改特定属性。 一般概述#
　　Solana 的账本验证设计基于一个旋转的、权益加权的选定领导者，将 PoH 数据结构中的交易广播到验证节点。这些节点在收到领导者的广播后，有机会通过将交易签署到 PoH 流中来对当前状态和 PoH 高度进行投票。
　　要成为 Solana 验证者，必须在合约中存入/锁定一定数量的 SOL。此 SOL 在特定时间段内无法访问。质押锁定期的确切持续时间尚未确定。但是，我们可以考虑这段时间的三个阶段，其中需要特定参数： 预热期 ：存放了哪些 SOL，节点无法访问，但 PoH 交易验证尚未开始。最有可能是几天到几周的顺序 验证期 ：存入的 SOL 将无法访问的最短持续时间，有被削减的风险（见下文的削减规则）并因验证者参与而获得奖励。可能持续数月至一年。 冷却期 ：提交＂提款＂交易后的一段时间。在此期间，验证责任已被取消，资金仍然无法获得。累积的奖励应在此期间结束时交付，以及初始存款的返还。
　　Solana 的 PoH 数据结构提供的去信任时间感和排序，连同其涡轮机数据广播和传输设计，应该提供亚秒级的交易确认时间，该时间与集群中节点数量的日志成比例。这意味着我们不应该以令人望而却步的＂最低存款＂来限制验证节点的数量，并期望节点能够成为具有名义数量的 SOL 质押的验证者。同时，Solana 对高吞吐量的关注应该会激励验证客户提供高性能和可靠的硬件。结合作为验证客户端加入的潜在最低网络速度阈值，我们预计会出现一个健康的验证委托市场。 处罚#
　　正如经济设计部分所讨论的，年度验证者利率将被指定为已抵押的循环供应的总百分比的函数。集群奖励在线并在整个 验证期间 积极参与验证过程的验证者。对于在此期间下线/未能验证交易的验证者，他们的年度奖励将有效减少。
　　同样，我们可以考虑在验证者离线的情况下通过算法减少验证者的活跃质押量。即，如果验证者由于分区或其他原因在一段时间内处于非活动状态，则其被视为＂活动＂ （有资格获得奖励）的股份数量可能会减少。这种设计的结构将有助于长期存在的分区最终在其各自的链上达到最终性，因为随着时间的推移，无投票权总权益的百分比会减少，直到每个分区中的活跃验证者可以实现绝对多数。同样，在重新参与时，＂活跃＂的质押量将以某个定义的速率重新上线。根据分区/活动集的大小，可以考虑不同的权益减少率。