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

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