基于zookeeper实现rpc注册中心
注册中心中保存的是各服务的节点信息，主要包括ip和端口号，当服务端的节点增减时，服务的调用者能通过注册中心感知到服务端节点的变化。
使用注册中心的优点：如果服务节点部署机器过多，调用者需要配置太多的节点信息，不利于维护；当服务端增减节点时，客户端无需改动重启。
krpc 目前已经增加了zookeeper作为注册中心（如果不配置zk信息，则不使用）。
针对 服务节点意外宕掉的解决方案，zk的临时节点天然的符合这个场景。zk中当创建临时节点的链接断掉，该临时节点会自动删除。
对于客户端主动监听节点信息变化，zk也提供了对应的功能。
krpc中节点的设计如下图所示。
根节点是path固定的krpc，其子节点是所有服务名字，各个服务节点path是 ip:port，每个ip:port节点是临时节点，服务启动时会创建该path的临时节点，宕机后变自动删除。
krpc中 服务端注册实现
客户端订阅/krpc/服务名 下子节点变更，变动后会将当前所有存在path在回掉中list参数传递过来，然后将新的节点信息更新即可。
krpc中 客户端订阅实现
从0 到 1:全面理解 RPC 远程调用
作者 | Python编程时光
责编 | 胡巍巍
什么是RPC呢？百度百科给出的解释是这样的：“RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议”。
这个概念听起来还是比较抽象，没关系，继续往后看，后面概念性的东西，我会讲得足够清楚，让你完全掌握 RPC 的基础内容。
在 OpenStack 里的进程间通信方式主要有两种，一种是基于HTTP协议的RESTFul API方式，另一种则是RPC调用。
那么这两种方式在应用场景上有何区别呢？
有使用经验的人，就会知道：
首先，给你提两个问题，带着这两个问题再往下看：
1、RPC 和 REST 区别是什么？2、为什么要采用RPC呢？
首先，第一个问题：RPC 和 REST 区别是什么？
你一定会觉得这个问题很奇怪，是的，包括我，但是你在网络上一搜，会发现类似对比的文章比比皆是，我在想可能很多初学者由于基础不牢固，才会将不相干的二者拿出来对比吧。既然是这样，那为了让你更加了解陌生的RPC，就从你熟悉得不能再熟悉的 REST 入手吧。
01、所属类别不同
REST，是Representational State Transfer 的简写，中文描述表述性状态传递（是指某个瞬间状态的资源数据的快照，包括资源数据的内容、表述格式(XML、JSON)等信息。）
REST 是一种软件架构风格。这种风格的典型应用，就是HTTP。其因为简单、扩展性强的特点而广受开发者的青睐。
而RPC 呢，是 Remote Procedure Call Protocol 的简写，中文描述是远程过程调用，它可以实现客户端像调用本地服务(方法)一样调用服务器的服务(方法)。
而 RPC 可以基于 TCP/UDP，也可以基于 HTTP 协议进行传输的，按理说它和REST不是一个层面意义上的东西，不应该放在一起讨论，但是谁让REST这么流行呢，它是目前最流行的一套互联网应用程序的API设计标准，某种意义下，我们说 REST 可以其实就是指代 HTTP 协议。
02、使用方式不同
03、面向对象不同
从设计上来看，RPC，所谓的远程过程调用 ，是面向方法的 ，REST：所谓的 Representational state transfer ，是面向资源的，除此之外，还有一种叫做 SOA，所谓的面向服务的架构，它是面向消息的，这个接触不多，就不多说了。
04、序列化协议不同
接口调用通常包含两个部分，序列化和通信协议。
通信协议，上面已经提及了，REST 是 基于 HTTP 协议，而 RPC 可以基于 TCP/UDP，也可以基于 HTTP 协议进行传输的。
常见的序列化协议，有：json、xml、hession、protobuf、thrift、text、bytes等，REST 通常使用的是 JSON或者XML，而 RPC 使用的是 JSON-RPC，或者 XML-RPC。
通过以上几点，我们知道了 REST 和 RPC 之间有很明显的差异。
然后第二个问题：为什么要采用RPC呢？
那到底为何要使用 RPC，单纯的依靠RESTful API不可以吗？为什么要搞这么多复杂的协议，渣渣表示真的学不过来了。
关于这一点，以下几点仅是我的个人猜想，仅供交流哈：
说了这么多，我们该如何选择这两者呢？我总结了如下两点，供你参考：
“远程调用”意思就是：被调用方法的具体实现不在程序运行本地，而是在别的某个地方（分布到各个服务器），调用者只想要函数运算的结果，却不需要实现函数的具体细节。
光说不练嘴把式，接下来，我将分别用三种不同的方式全面地让你搞明白 rpc 远程调用是如何实现的。
01、基于 xml-rpc
Python实现 rpc，可以使用标准库里的 SimpleXMLRPCServer，它是基于XML-RPC 协议的。
有了这个模块，开启一个 rpc server，就变得相当简单了。执行以下代码：
有了 rpc server，接下来就是 rpc client，由于我们上面使用的是 XML-RPC，所以 rpc clinet 需要使用xmlrpclib 这个库。
然后，我们通过 server_proxy 对象就可以远程调用之前的rpc server的函数了。
SimpleXMLRPCServer是一个单线程的服务器。这意味着，如果几个客户端同时发出多个请求，其它的请求就必须等待第一个请求完成以后才能继续。
若非要使用 SimpleXMLRPCServer 实现多线程并发，其实也不难。只要将代码改成如下即可。
02、基于json-rpc
SimpleXMLRPCServer 是基于 xml-rpc 实现的远程调用，上面我们也提到 除了 xml-rpc 之外，还有 json-rpc 协议。
那 python 如何实现基于 json-rpc 协议呢？
答案是很多，很多web框架其自身都自己实现了json-rpc，但我们要独立这些框架之外，要寻求一种较为干净的解决方案，我查找到的选择有两种
第一种是 jsonrpclib
第二种是 python-jsonrpc
先来看第一种 jsonrpclib
它与 Python 标准库的 SimpleXMLRPCServer 很类似（因为它的类名就叫做 SimpleJSONRPCServer ，不明真相的人真以为它们是亲兄弟）。或许可以说，jsonrpclib 就是仿照 SimpleXMLRPCServer 标准库来进行编写的。
它的导入与 SimpleXMLRPCServer 略有不同，因为SimpleJSONRPCServer分布在jsonrpclib库中。
服务端
客户端
再来看第二种python-jsonrpc，写起来貌似有些复杂。
服务端
客户端
调用过程如下
还记得上面我提到过的 zabbix API，因为我有接触过，所以也拎出来讲讲。zabbix API 也是基于 json-rpc 2.0协议实现的。
因为内容较多，这里只带大家打个，zabbix 是如何调用的：直接指明要调用 zabbix server 的哪个方法，要传给这个方法的参数有哪些。
03、基于 zerorpc
以上介绍的两种rpc远程调用方式，如果你足够细心，可以发现他们都是http+rpc 两种协议结合实现的。
接下来，我们要介绍的这种（zerorpc），就不再使用走 http 了。
zerorpc 这个第三方库，它是基于TCP协议、 ZeroMQ 和 MessagePack的，速度相对快，响应时间短，并发高。zerorpc 和 pyjsonrpc 一样，需要额外安装，虽然SimpleXMLRPCServer不需要额外安装，但是SimpleXMLRPCServer性能相对差一些。
调用过程如下
客户端除了可以使用zerorpc框架实现代码调用之外，它还支持使用“命令行”的方式调用。
客户端可以使用命令行，那服务端是不是也可以呢？
是的，通过 Github 上的文档几个 demo 可以体验到这个第三方库做真的是优秀。
比如我们可以用下面这个命令，创建一个rpc server，后面这个 time Python 标准库中的 time 模块，zerorpc 会将 time 注册绑定以供client调用。
经过了上面的学习，我们已经学会了如何使用多种方式实现rpc远程调用。
通过对比，zerorpc 可以说是脱颖而出，一支独秀。
为此，我也做了一番思考：
OpenStack 组件繁多，在一个较大的集群内部每个组件内部通过rpc通信频繁，如果都采用rpc直连调用的方式，连接数会非常地多，开销大，若有些 server 是单线程的模式，超时会非常的严重。
OpenStack 是复杂的分布式集群架构，会有多个 rpc server 同时工作，假设有 server01，server02，server03 三个server，当 rpc client 要发出rpc请求时，发给哪个好呢？这是问题一。
你可能会说轮循或者随机，这样对大家都公平。这样的话还会引出另一个问题，倘若请求刚好发到server01，而server01刚好不凑巧，可能由于机器或者其他因为导致服务没在工作，那这个rpc消息可就直接失败了呀。要知道做为一个集群，高可用是基本要求，如果出现刚刚那样的情况其实是很尴尬的。这是问题二。
集群有可能根据实际需要扩充节点数量，如果使用直接调用，耦合度太高，不利于部署和生产。这是问题三。
引入消息中间件，可以很好的解决这些问题。
解决问题一：消息只有一份，接收者由AMQP的负载算法决定，默认为在所有Receiver中均匀发送(round robin)。
解决问题二：有了消息中间件做缓冲站，client 可以任性随意的发，server 都挂掉了？没有关系，等 server 正常工作后，自己来消息中间件取就行了。
解决问题三：无论有多少节点，它们只要认识消息中间件这一个中介就足够了。
既然讲到了消息队列，如果你之前没有接触过这块内容，最好花几分钟的时间跟我好好过下关于消息队列的几个基础概念。
首先，RPC只是定义了一个通信接口，其底层的实现可以各不相同，可以是 socket，也可以是今天要讲的 AMQP。
AMQP(Advanced Message Queuing Protocol)是一种基于队列的可靠消息服务协议，作为一种通信协议，AMQP同样存在多个实现，如Apache Qpid，RabbitMQ等。
以下是 AMQP 中的几个必知的概念：
Publisher：消息发布者
Queue：用来保存消息的存储空间，消息没有被receiver前，保存在队列中。
Exchange：用来接收Publisher发出的消息，根据Routing key 转发消息到对应的Message Queue中，至于转到哪个队列里，这个路由算法又由exchange type决定的。
Exchange type：主要四种描述exchange的类型。
direct：消息路由到满足此条件的队列中(queue,可以有多个)：routing key = binding key
topic：消息路由到满足此条件的队列中(queue,可以有多个)：routing key 匹配 binding pattern. binding pattern是类似正则表达式的字符串，可以满足复杂的路由条件。
fanout：消息路由到多有绑定到该exchange的队列中。
binding ：binding是用来描述exchange和queue之间的关系的概念，一个exchang可以绑定多个队列，这些关系由binding建立。前面说的binding key /binding pattern也是在binding中给出。
为了让你明白这几者的关系，我画了一张模型图。
关于AMQP，有几下几点值得注意：
前面铺垫了那么久，终于到了讲真实应用的场景。在生产中RPC是如何应用的呢？
其他模型我不太清楚，在 OpenStack 中的应用模型是这样的
至于为什么要如此设计，前面我已经给出了自己的观点。
接下来，就是源码解读 OpenStack ，看看其是如何通过rpc进行远程调用的。如若你对此没有兴趣（我知道很多人对此都没有兴趣，所以不浪费大家时间），可以直接跳过这一节，进入下一节。
目前Openstack中有两种RPC实现，一种是在oslo messaging,一种是在openstack.common.rpc。
openstack.common.rpc是旧的实现，oslo messaging是对openstack.common.rpc的重构。openstack.common.rpc在每个项目中都存在一份拷贝，oslo messaging即将这些公共代码抽取出来，形成一个新的项目。oslo messaging也对RPC API 进行了重新设计，对多种 transport 做了进一步封装，底层也是用到了kombu这个AMQP库。（注：Kombu 是Python中的messaging库。Kombu旨在通过为AMQ协议提供惯用的高级接口，使Python中的消息传递尽可能简单，并为常见的消息传递问题提供经过验证和测试的解决方案。）
关于oslo_messaging库，主要提供了两种独立的API:
因为 notify 实现是太简单了，所以这里我就不多说了，如果有人想要看这方面内容，可以收藏我的博客(http://python-online.cn) ，我会更新补充 notify 的内容。
OpenStack RPC 模块提供了 rpc.call，rpc.cast, rpc.fanout_cast 三种 RPC 调用方法，发送和接收 RPC 请求。
rpc.call 和 .rpc.cast 从实现代码上看，他们的区别很小，就是call调用时候会带有wait_for_reply=True参数，而cast不带。
要了解 rpc 的调用机制呢，首先要知道 oslo_messaging 的几个概念主要方法有四个：
transport：RPC功能的底层实现方法，这里是rabbitmq的消息队列的访问路径
transport 就是定义你如何访连接消息中间件，比如你使用的是 Rabbitmq，那在 nova.conf中应该有一行transport_url的配置，可以很清楚地看出指定了 rabbitmq 为消息中间件，并配置了连接rabbitmq的user，passwd，主机，端口。
target用来表述 RPC 服务器监听topic，server名称和server监听的exchange，是否广播fanout。
rpc server 要获取消息，需要定义target，就像一个门牌号一样。
rpc client 要发送消息，也需要有target，说明消息要发到哪去。
endpoints：是可供别人远程调用的对象
RPC服务器暴露出endpoint，每个 endpoint 包涵一系列的可被远程客户端通过 transport 调用的方法。直观理解，可以参考nova-conductor创建rpc server的代码，这边的endpoints就是 nova/manager.py:ConductorManager
dispatcher：分发器，这是 rpc server 才有的概念
只有通过它 server 端才知道接收到的rpc请求，要交给谁处理，怎么处理？
在client端，是这样指定要调用哪个方法的。
而在server端，是如何知道要执行这个方法的呢？这就是dispatcher 要干的事，它从 endpoint 里找到这个方法，然后执行，最后返回。
Serializer：在 python 对象和message(notification) 之间数据做序列化或是反序列化的基类。
主要方法有四个：
每个notification listener都和一个executor绑定，来控制收到的notification如何分配。默认情况下，使用的是blockquaning executor(具体特性参加executor一节）
模仿是一种很高效的学习方法，我这里根据 OpenStack 的调用方式，抽取出核心内容，写成一个简单的 demo，有对 OpenStack 感兴趣的可以了解一下，大部分人也可以直接跳过这章节。
注意以下代码不能直接运行，你还需要配置 rabbitmq 的连接方式，你可以写在配置文件中，通过 get_transport 从cfg.CONF 中读取，也可以直接将其写成url的格式做成参数，传给 get_transport 。而且还要nova或者其他openstack组件的环境中运行（因为需要有ctxt这个环境变量）
简单的 rpc client
简单的 rpc server
【End】
热 文 推 荐
?Facebook 发币 Libra；谷歌十亿美金为穷人造房；第四代树莓派 Raspberry Pi 4 发布 | 开发者周刊
?WebRTC 将一统实时音视频天下？
?小米崔宝秋：小米 AIoT 深度拥抱开源
?华为在美研发机构 Futurewei 意欲分家？
?老司机教你如何写出没人敢维护的代码！
?Python有哪些技术上的优点？比其他语言好在哪儿？
?上不了北大“图灵”、清华“姚班”，AI专业还能去哪上？
?公链史记 | 从鸿蒙初辟到万物生长的十年激荡……
?边缘计算容器化是否有必要？
?马云曾经偶像，终于把阿里留下的1400亿败光了！
你点的每个“在看”，我都认真当成了喜欢
DApp开发入门
本文仅介绍以太坊系列的DApp开发，其他链原理差不太多。
MetaMask安装完成并运行后，可以在Chrome控制台打印 MetaMask注入的window.ethereum对象
关于ethereum对象，我们只需要关心 ethereum.request 就足够了，MetaMask 使用 ethereum.request(args) 方法 来包装 RPC API。这些 API 基于所有以太坊客户端公开的接口。 简单来说钱包交互的大部分操作都是由 request() 方法实现，通过传入不同的方法名来区分。
?? 即使ethereum对象中提供了chainId，isMetaMask，selectAddress属性，我们也不能完全相信这些属性，他们是不稳定或不标准，不建议使用。我们可以通过上面说的request方法，拿到可靠的数据 。
钱包通过method方法名，进行对应的实现 以获取钱包地址为例
调用 ethereum.request({ method: "eth_requestAccounts" }) ，钱包实现了该方法，那么就可以拿到钱包的地址了。
MetaMask注入的 window.ethereum 就是一个Provider，一个RPC节点也是一个Provider，通过Provider，我们有了访问区块链的能力。 在连接到钱包的情况下，通常使用钱包的Provider就可以了， ethers.providers.Web3Provider(ethereum)
如果只需要查询一些区块链数据，可以使用EtherscanProvider 和 InfuraProvider 连接公开的 第三方节点服务提供商 。JsonRpcProvider 和 IpcProvider 允许连接到我们控制或可以访问的以太坊节点。
获取当前账户余额
获取最新区块号
其他RPC操作，可以通过 JSON-RPC 查看。
通过 ethers.js 可以连接ERC20的合约，合约编译后会生成ABI，合约部署后，会生成合约地址，开发者通过 ABI和合约地址 ，对合约发送消息。
合约中的方法大致分为两种： 视图方法(免费)，非视图方法(消耗Gas) ，可以通过ABI查看方法类型。
?? ERC20需要多加关注的是 Approve() 方法以及 transfer() 和 transferFrom() 的区别 ，授权过的代币，被授权的那一方，可以通过调用 transferFrom() 方法,转走你授权数量内的代币，所以授权是一个很危险的操作，假设你授权了一个不良的合约，那你会面临授权的token被转走的风险，即使你没有泄露私钥助记词。
便利三方库： web3-react use-wallet
文档： doc.metamask.io ethers
rpc的实现机制是什么
RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即无论是调用本地接口/服务的还是远程的接口/服务，本质上编写的调用代码基本相同。
比如两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数或者方法，由于不在一个内存空间，不能直接调用，这时候需要通过就可以应用RPC框架的实现来解决。
RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯）
RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（类似于Http的工作方式）
RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。
二、常见RPC框架
几种比较典型的RPC的实现和调用框架。
（1）RMI实现，利用java.rmi包实现，基于Java远程方法协议(Java Remote Method Protocol)
和java的原生序列化。
（2）Hessian，是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能。 基于HTTP协议，采用二进制编解码。
（3）THRIFT是一种可伸缩的跨语言服务的软件框架。thrift允许你定义一个描述文件，描述数据类型和服务接口。依据该文件，编译器方便地生成RPC客户端和服务器通信代码。
二、RPC框架实现原理
在RPC框架中主要有三个角色：Provider、Consumer和Registry。如下图所示：
RPC框架面试总结-RPC原理及实现
节点角色说明：
* Server: 暴露服务的服务提供方。
* Client: 调用远程服务的服务消费方。
* Registry: 服务注册与发现的注册中心。
三、RPC调用流程
RPC基本流程图：
RPC框架面试总结-RPC原理及实现
一次完整的RPC调用流程（同步调用，异步另说）如下：
1）服务消费方（client）调用以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3）client stub找到服务地址，并将消息发送到服务端；
4）server stub收到消息后进行解码；
5）server stub根据解码结果调用本地的服务；
6）本地服务执行并将结果返回给server stub；
7）server stub将返回结果打包成消息并发送至消费方；
8）client stub接收到消息，并进行解码；
9）服务消费方得到最终结果。
RPC框架的目标就是要2~8这些步骤都封装起来，让用户对这些细节透明。
四、服务注册&发现
RPC框架面试总结-RPC原理及实现
服务提供者启动后主动向注册中心注册机器ip、port以及提供的服务列表；
服务消费者启动时向注册中心获取服务提供方地址列表，可实现软负载均衡和Failover；
五、使用到的技术
1、动态代理
生成 client stub和server stub需要用到 Java 动态代理技术 ，我们可以使用JDK原生的动态代理机制，可以使用一些开源字节码工具框架 如：CgLib、Javassist等。
2、序列化
为了能在网络上传输和接收 Java对象，我们需要对它进行 序列化和反序列化操作。
* 序列化：将Java对象转换成byte[]的过程，也就是编码的过程；
* 反序列化：将byte[]转换成Java对象的过程；
可以使用Java原生的序列化机制，但是效率非常低，推荐使用一些开源的、成熟的序列化技术，例如：protobuf、Thrift、hessian、Kryo、Msgpack
关于序列化工具性能比较可以参考：jvm-serializers
3、NIO
当前很多RPC框架都直接基于netty这一IO通信框架，比如阿里巴巴的HSF、dubbo，Hadoop Avro，推荐使用Netty 作为底层通信框架。
4、服务注册中心
可选技术：
* Redis
* Zookeeper
* Consul
* Etcd
Solana 验证节点设备、网络要求以及质押奖励处罚机制
在 Solana 上运行验证器没有严格的最低 SOL 数量要求。
然而，为了参与共识，需要一个具有 0.02685864 SOL 的免租储备的投票账户。投票还需要为验证者同意的每个区块发送投票交易，这可能每天花费高达 1.1 SOL。
注意： 默认情况下，您的验证者将没有权益。 这意味着它将没有资格成为领导者。（不质押没有收益或者收益极低。）
如果要将验证器用作 RPC 节点，则应将上述硬 件建议视为最低要求。为了提供完整的功能并提高可靠性，应进行以下调整。
虽然您可以在云计算平台上运行验证器，但从长远来看，它可能并不具有成本效益。
但是，在 VM 实例上运行非投票 api 节点以供您自己的内部使用可能会很方便。此用例包括基于 Solana 构建的交易所和服务。
事实上，该团队运营的 mainnet-beta 验证器目前（2021 年 3 月）运行在n2-standard-32具有 2048 GB SSD 的 GCE（32 个 vCPU，128 GB 内存）实例上，以方便操作。
对于其他云平台，请选择具有相似规格的实例类型。
另请注意，出口互联网流量使用可能会很高，尤其是在运行质押验证器的情况下。
不建议在 Docker 内运行实时集群（包括 mainnet-beta）的验证器，通常也不支持。这是由于担心一般 Docker 的容器化开销和导致的性能下降，除非特别配置。
我们仅将 Docker 用于开发目的。Docker Hub 包含solanalabs/solana中所有版本的映像。
预构建的二进制文件可用于支持 AVX2 的 CPU 上的 Linux x86_64 （推荐 Ubuntu 20.04 ）。MacOS 或 WSL 用户可以从源代码构建。
互联网服务至少应为 300Mbit/s 对称、商用。1GBit/s 优先
对于入站和出站，以下端口需要对 Internet 开放
不建议在 NAT 后面运行验证器。选择这样做的操作员应该能够轻松地配置他们的网络设备并自行调试任何遍历问题。
出于安全目的，不建议在质押的主网 beta 验证器上向互联网开放以下端口。
需要 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 在特定时间段内无法访问。质押锁定期的确切持续时间尚未确定。但是，我们可以考虑这段时间的三个阶段，其中需要特定参数：
Solana 的 PoH 数据结构提供的去信任时间感和排序，连同其涡轮机数据广播和传输设计，应该提供亚秒级的交易确认时间，该时间与集群中节点数量的日志成比例。这意味着我们不应该以令人望而却步的“最低存款”来限制验证节点的数量，并期望节点能够成为具有名义数量的 SOL 质押的验证者。同时，Solana 对高吞吐量的关注应该会激励验证客户提供高性能和可靠的硬件。结合作为验证客户端加入的潜在最低网络速度阈值，我们预计会出现一个 健康 的验证委托市场。
正如经济设计部分所讨论的，年度验证者利率将被指定为已抵押的循环供应的总百分比的函数。集群奖励在线并在整个 验证期间 积极参与验证过程的验证者。对于在此期间下线/未能验证交易的验证者，他们的年度奖励将有效减少。
同样，我们可以考虑在验证者离线的情况下通过算法减少验证者的活跃质押量。即，如果验证者由于分区或其他原因在一段时间内处于非活动状态，则其被视为“活动” （有资格获得奖励）的股份数量可能会减少。这种设计的结构将有助于长期存在的分区最终在其各自的链上达到最终性，因为随着时间的推移，无投票权总权益的百分比会减少，直到每个分区中的活跃验证者可以实现绝对多数。同样，在重新参与时，“活跃”的质押量将以某个定义的速率重新上线。根据分区/活动集的大小，可以考虑不同的权益减少率。
