Solana之旅2：总体架构

系统组件

领导者与PoH生成器(Leader, PoH Generator)

1. 领导者(Leader)就是被选举出来的PoH生成器(PoH Generator)。
2. 它接收来用户的交易，并输出包含所有交易及其执行状态信息的PoH序列，该序列将确保Solana系统中的这些信息的有序的全球一致性。
3. 针对一批次的交易，该Leader会针对交易顺序运行的结果而产生的状态，按由若干交易组成的批次进行签名且发布。
4. 该签名是用Leader的私钥签的。

状态(State)

1. Solana系统 状态 由Hash表来维护，而且该表是基于用户地址来索引的。
2. 表中每个条目包含了用户完整的地址，以及计算要用到的信息。
3. 下面是两个状态表的例子：

• 交易表
  
  共占用了32个字节。
• PoS质押表
  共占用64个字节。

复制者与状态复制(Verifier, PoRep)

1. Verifier节点用来复制Solana链的状态，并确保该链状态的高可用性。
2. 节点要复制的内容或目标(target)，是由共识算法决定的；共识算法中的Validators会基于链下定义好的准则，选择并通过投票来确定PoRep节点(执行创建复制证明的任务)。
3. Solana网络配置了最少的PoS质押数额；并且一个复制身份( replicator identity)只能有一个质押账户(也就是不允许一个身份多次质押，进而多次去制造复制证明，并多次参与Solana链相关工作或状态的共识)。

验证者(Validators)

1. 这些节点是虚拟节点，跑在Verifiers或Leader所在的机器上，或者独立的机器上。
2. 它们专门用来执行Solana配置的共识算法。
3. 当机器扮演Leader角色时，这些Validators是不运行的；而扮演Verifiers的角色时，它们是会运行的。

网络限制(Network Limits)考量

1. Leader被期望执行以下任务：

• 接收所有用户发来的请求包；
• 将用户请求包以最高效率排好序；
• 将排好序的请求包，编排进PoH时间流逝；
• 将编排好的时间流逝发布给下游的Verifiers。

2. 其中PoH生成器是多对一的接收输入，又是一对多地进行输出，因此在PoH Generator这里应会产生网络瓶颈：
   
3. 要想提高PoH的网络吞吐能力，应当想法在交易的内存访问方式想办法；因此Solana将交易都按序摆放，因为这样可以让错误面降到最低，而全交易让预测先取命中率最高。
4. 下面是不同数据包的存放格式：

• 输入包格式
  
  共占用：20 + 8 + 16 + 8 + 32 + 32 + 32 = 148 bytes.

• 在上面包格式里，增加一个最小的payload(就是一个目标账户)，则包的格式变成：
  
  这个包占用空间为：176 bytes

5. 关于PoH时间流逝包(packet)里面包含了的内容则如下：

• 当前hash；
• counter;
• 在该时间流逝中所有新消息(messages)的hash；
• 所有消息被处理后的状态签名。
  
  此类包的最小占用存储空间：132 bytes。
  这个包会在每隔N个消息后，广播一次。

6. 对于1gbps的网络连接下的吞吐限制：

• 最大的TPS = 1gbps / 176 bytes = 710k；
• 考虑到以太网帧协议部分，会带来网络带宽1~4%的损耗；
• 真正网络的有效带宽，还应考虑Reed-Solomon等编码（此类编码可以增加网络传输的可用性）的引入，也会有所降低；
• PoH应有诸如Reed-Solomon纠删码将原始报文进行FEC，再把数据包传给下游的Verifiers。

综合下来，对于1gbps的网络带宽可支持的TPS会小于710k，但也不会小太多，应该处于这个吞吐量级。

算力限制( Computational Limits)

1. Solana针对每个交易请求都要进行摘要的核验。
2. 这个核验操作不会用到消息体自身之外的交易消息，所以可以并发的执行；因此这个计算的吞吐，主要受限于系统中可用的处理器的核的数量。
3. 基于ECDSA核验服务器的GPU实验下来的结果是：900kops(operations per second)。

综合下来，当前的服务器的算力，对于网络吞吐来讲，它不会成为瓶颈。

内存限制

1. 理论上，如果每个账户占用32字节，如果hash表空间50%被占用了，那么存放100亿个这样的账户，要占用640GB的内存空间。
2. 对这处表的随机访问，每秒可以承接1.1 ∗ 10⁷的写或读。
3. 基于每个交易会有2次读和2次写，那内存的吞吐量可支持每秒2.75百万次交易。
4. 以上的指标是基于Amazon的 1TB x1.16xlarge Web服务用的云服务器测得。

综合下来，内存方面也不会成Solana交易响应的瓶颈。

高性能的智能合约

1. 交易的一般形态是智能合约；它们是运行在每个节点上的程序；这些程序的运行将修改Solana系统的状态。

2. Solana设计中利用了扩展版的Berkeley Packet Filter字节码，以便可以尽可能又简单又快速地分析智能合约语言转换而来的JIT字节码。

3. Solana智能拿给拥有的最大优点之一是：实现不用花钱的外部函数接口；这些接口会用到调用Intrinsics(系统的内在函数集合)。

4. Intrinsics是一种由平台直接实现的函数，可以被智能合约程序调用。

5. 对Intrinsics的调用，会将主调程序挂起，并在一个高性能的服务器GPU上装载该Intrinsics函数体，并进行执行。

6. Intrinsics是按批次放在一起的，由GPU中并发执行；下图显示了两个不同的用户程序调用了同样的 intrinsic，但每个用户程序都要挂起，直到两个Intrinsics都执行完成，因为它们是一批次的：
   

7. intrinsic典型例子就是ECDSA核验；对此类intrinsic的调用会打包成一批次，在GPU上同时执行；此种方式可以将此类计算的吞吐，提高几千倍。

8. 这种蹦床式的调用，不会导致本地OS的线程上下文的切换；因为BPF字节码(Berkeley Packet Filter)已经处理好这种调用所会用到的内存，完全定义好了上下文。

9. 从2015年开始，LLVM已引入了关于eBPF的支持，因此任何LLVM的前端语言都可以用来写Solana的智能合约；BPF第一代版本在1992年就有了，并在2015年Linus就把它缺省集成进Linux了。