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