系统组件
领导者与PoH生成器(Leader, PoH Generator)
- 领导者(Leader)就是被选举出来的PoH生成器(PoH Generator)。
- 它接收来用户的交易，并输出包含所有交易及其执行状态信息的PoH序列，该序列将确保Solana系统中的这些信息的有序的全球一致性。
- 针对一批次的交易，该Leader会针对交易顺序运行的结果而产生的状态，按由若干交易组成的批次进行签名且发布。
- 该签名是用Leader的私钥签的。
状态(State)
- Solana系统 状态 由Hash表来维护，而且该表是基于用户地址来索引的。
- 表中每个条目包含了用户完整的地址，以及计算要用到的信息。
- 下面是两个状态表的例子：
- 交易表
共占用了32个字节。 - PoS质押表
共占用64个字节。
复制者与状态复制(Verifier, PoRep)
- Verifier节点用来复制Solana链的状态，并确保该链状态的高可用性。
- 节点要复制的内容或目标(target)，是由共识算法决定的；共识算法中的Validators会基于链下定义好的准则，选择并通过投票来确定PoRep节点(执行创建复制证明的任务)。
- Solana网络配置了最少的PoS质押数额；并且一个复制身份( replicator identity)只能有一个质押账户(也就是不允许一个身份多次质押，进而多次去制造复制证明，并多次参与Solana链相关工作或状态的共识)。
验证者(Validators)
- 这些节点是虚拟节点，跑在Verifiers或Leader所在的机器上，或者独立的机器上。
- 它们专门用来执行Solana配置的共识算法。
- 当机器扮演Leader角色时，这些Validators是不运行的；而扮演Verifiers的角色时，它们是会运行的。
网络限制(Network Limits)考量
- Leader被期望执行以下任务：
- 接收所有用户发来的请求包；
- 将用户请求包以最高效率排好序；
- 将排好序的请求包，编排进PoH时间流逝；
- 将编排好的时间流逝发布给下游的Verifiers。
- 其中PoH生成器是多对一的接收输入，又是一对多地进行输出，因此在PoH Generator这里应会产生网络瓶颈：
- 要想提高PoH的网络吞吐能力，应当想法在交易的内存访问方式想办法；因此Solana将交易都按序摆放，因为这样可以让错误面降到最低，而全交易让预测先取命中率最高。
- 下面是不同数据包的存放格式：
-
输入包格式
共占用：20 + 8 + 16 + 8 + 32 + 32 + 32 = 148 bytes. -
在上面包格式里，增加一个最小的payload(就是一个目标账户)，则包的格式变成：
这个包占用空间为：176 bytes
- 关于PoH时间流逝包(packet)里面包含了的内容则如下：
- 当前hash；
- counter;
- 在该时间流逝中所有新消息(messages)的hash；
- 所有消息被处理后的状态签名。
此类包的最小占用存储空间：132 bytes。
这个包会在每隔N个消息后，广播一次。
- 对于1gbps的网络连接下的吞吐限制：
- 最大的TPS = 1gbps / 176 bytes = 710k；
- 考虑到以太网帧协议部分，会带来网络带宽1~4%的损耗；
- 真正网络的有效带宽，还应考虑Reed-Solomon等编码（此类编码可以增加网络传输的可用性）的引入，也会有所降低；
- PoH应有诸如Reed-Solomon纠删码将原始报文进行FEC，再把数据包传给下游的Verifiers。
综合下来，对于1gbps的网络带宽可支持的TPS会小于710k，但也不会小太多，应该处于这个吞吐量级。
算力限制( Computational Limits)
- Solana针对每个交易请求都要进行摘要的核验。
- 这个核验操作不会用到消息体自身之外的交易消息，所以可以并发的执行；因此这个计算的吞吐，主要受限于系统中可用的处理器的核的数量。
- 基于ECDSA核验服务器的GPU实验下来的结果是：900kops(operations per second)。
综合下来，当前的服务器的算力，对于网络吞吐来讲，它不会成为瓶颈。
内存限制
- 理论上，如果每个账户占用32字节，如果hash表空间50%被占用了，那么存放100亿个这样的账户，要占用640GB的内存空间。
- 对这处表的随机访问，每秒可以承接1.1 ∗ 107的写或读。
- 基于每个交易会有2次读和2次写，那内存的吞吐量可支持每秒2.75百万次交易。
- 以上的指标是基于Amazon的 1TB x1.16xlarge Web服务用的云服务器测得。
综合下来，内存方面也不会成Solana交易响应的瓶颈。
高性能的智能合约
-
交易的一般形态是智能合约；它们是运行在每个节点上的程序；这些程序的运行将修改Solana系统的状态。
-
Solana设计中利用了扩展版的Berkeley Packet Filter字节码，以便可以尽可能又简单又快速地分析智能合约语言转换而来的JIT字节码。
-
Solana智能拿给拥有的最大优点之一是：实现不用花钱的外部函数接口；这些接口会用到调用Intrinsics(系统的内在函数集合)。
-
Intrinsics是一种由平台直接实现的函数，可以被智能合约程序调用。
-
对Intrinsics的调用，会将主调程序挂起，并在一个高性能的服务器GPU上装载该Intrinsics函数体，并进行执行。
-
Intrinsics是按批次放在一起的，由GPU中并发执行；下图显示了两个不同的用户程序调用了同样的 intrinsic，但每个用户程序都要挂起，直到两个Intrinsics都执行完成，因为它们是一批次的：
-
intrinsic典型例子就是ECDSA核验；对此类intrinsic的调用会打包成一批次，在GPU上同时执行；此种方式可以将此类计算的吞吐，提高几千倍。
-
这种蹦床式的调用，不会导致本地OS的线程上下文的切换；因为BPF字节码(Berkeley Packet Filter)已经处理好这种调用所会用到的内存，完全定义好了上下文。
-
从2015年开始，LLVM已引入了关于eBPF的支持，因此任何LLVM的前端语言都可以用来写Solana的智能合约；BPF第一代版本在1992年就有了，并在2015年Linus就把它缺省集成进Linux了。