Solana之旅2:总体架构

Solana之旅2:总体架构_第1张图片

系统组件

领导者与PoH生成器(Leader, PoH Generator)
  1. 领导者(Leader)就是被选举出来的PoH生成器(PoH Generator)。
  2. 它接收来用户的交易,并输出包含所有交易及其执行状态信息的PoH序列,该序列将确保Solana系统中的这些信息的有序的全球一致性。
  3. 针对一批次的交易,该Leader会针对交易顺序运行的结果而产生的状态,按由若干交易组成的批次进行签名且发布。
  4. 该签名是用Leader的私钥签的。
状态(State)
  1. Solana系统 状态 由Hash表来维护,而且该表是基于用户地址来索引的。
  2. 表中每个条目包含了用户完整的地址,以及计算要用到的信息。
  3. 下面是两个状态表的例子:
  • 交易表
    在这里插入图片描述
    共占用了32个字节。
  • PoS质押表Solana之旅2:总体架构_第2张图片
    共占用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。
  1. 其中PoH生成器是多对一的接收输入,又是一对多地进行输出,因此在PoH Generator这里应会产生网络瓶颈:
    Solana之旅2:总体架构_第3张图片
  2. 要想提高PoH的网络吞吐能力,应当想法在交易的内存访问方式想办法;因此Solana将交易都按序摆放,因为这样可以让错误面降到最低,而全交易让预测先取命中率最高。
  3. 下面是不同数据包的存放格式:
  • 输入包格式
    Solana之旅2:总体架构_第4张图片
    共占用:20 + 8 + 16 + 8 + 32 + 32 + 32 = 148 bytes.

  • 在上面包格式里,增加一个最小的payload(就是一个目标账户),则包的格式变成:
    Solana之旅2:总体架构_第5张图片
    这个包占用空间为:176 bytes

  1. 关于PoH时间流逝包(packet)里面包含了的内容则如下:
  • 当前hash;
  • counter;
  • 在该时间流逝中所有新消息(messages)的hash;
  • 所有消息被处理后的状态签名。
    Solana之旅2:总体架构_第6张图片
    此类包的最小占用存储空间:132 bytes。
    这个包会在每隔N个消息后,广播一次。
  1. 对于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 ∗ 107的写或读。
  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都执行完成,因为它们是一批次的:
    Solana之旅2:总体架构_第7张图片

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

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

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

你可能感兴趣的:(区块链网络系统,区块链,去中心化,智能合约)