|另类Solana:不走分片之路( 二 )


有了独立的时间链 , 验证的领导者在收到时间戳后会尽快广播给委员会 。 时间戳有规范顺序 , 不是区块生产者任意确定的顺序 , 这样 , Solana中的验证者可以实时向其他节点发送状态更新 。 节点持续收到新的交易 , 交易有发送者签名过的PoH哈希 , 并将其转发给邻居节点 。
Solana的验证者通过SHA-256顺序哈希的VDF(可验证延迟函数)来解决时钟问题 。 每个Solana的验证者使用VDF来维持其自己的时钟 , 可以为周期(epoch)提前安排领导者 。
通过PoH , Solana的验证领导者可以实现持续轮换 , 且其轮换的决定是异步进行的 。 Solana网络也可以轮换验证者 , 且其轮换可在验证者之间无须相互交谈就可实现 。 而通常的区块链则需要验证者之间进行交谈才能作出轮换决定 。 这种设计给予Solana更大的可扩展性空间 。
除了PoH , Solana在共识机制、区块广播、账本存储等方面也进行了优化 。
Solana的TBFT共识
Solana的共识机制是TBFT共识(Tower BFT) , 类似于PBFT共识 。 不过 , Solana的TBFT将其活性优先于一致性 。 Solana的节点可以计算当前的验证者数量、每个验证者状态、每个验证者提交给网络中任何区块的超时 。 通过这些数据结构 , 节点可以进行投票 , 从而达成共识 。
【|另类Solana:不走分片之路】Solana的Turbine区块广播
Turbine是Solana的区块广播技术 , 借用了BitTorrent的思想 。 一个区块传输时 , 它会分成很多个小数据包 , 然后广播到大量的随机节点 。 按照Solana自身的说法 , 使用其扇出机制 , 如果每个连接为100毫秒 , 对于40,000个节点的网络而言 , 可以在400毫秒内完成复制 , 500毫秒内完成最终性 。
此外 , 由于Solana的共识层不依赖于点对点消息 , 因此可以独立于共识进行区块网络传输的优化 。
Solana的Gulf Stream
在Slolana的结构中 , 每个验证者都知道未来领导者的顺序 , 验证者会提前将交易转发给预期的领导者 。 这可以让验证者提前执行交易 , 减少确认时间 , 减少对验证者的内存压力 。
而像钱包这样的客户端则签署引用特定区块哈希的交易 。 客户端选择被网络完全确认的区块哈希 , 最差的情况下需要32个区块 , 假设区块时间大约800毫秒 , 最多只需要25.6秒完全确认 。
一旦交易转发给任意验证者 , 验证者会转发给未来的领导者 。 客户端可以订阅来自验证者的交易确认 。 客户端知道区块哈希在有限时间内过期或者交易被网络确认 。 它允许客户端签署交易 , 这些交易可以保证执行或失败 。
Solana的sealevel
sealevel是Solana用来构建横向扩展的技术方案 , 是并行交易处理的引擎 。 多数区块链都是单线程的计算机 。 Solana试图在单个分片中支持并行交易执行 。 它借鉴了“scatter-gathter”的操作系统驱动程序技术 。 交易预先指定它们在执行时将读取或写入的状态 。 运行时可以找到一个块中所有非重叠状态转换函数 , 且并行处理 。
sealevel本身是用于安排交易的虚拟机 , 但它并不在虚拟机中执行交易 。 它使用Berkeley Packet Filter(BFT , 为高性能数据包过滤器设计)的字节码 , 将交易在硬件本地执行 。
使用LLVM(针对WASM的相同编译器) , 可为开发者提供一组工具 , 用c/c++和Rust编写高性能的智能合约 。 Solana没有使用WASM , 不过开发者可以在Solana编译器上通过少量更改重新编译C和Rust代码 。 开发者可以从其他WASM链(ETH2.0、Polkadot、EOS等)将应用迁移过来 。 这一点对于开发者来说 , 会有一定的吸引力 。
为保证安全 , Solana的体系结构支持不同模块之间保持严格状态分离 , 同时将资源和脚本作为高级概念引入 。
Solana的Pipelining
Solana网络上的交易验证过程利用了Pipelining的机制(CPU设计中常见的优化) 。 Solana网络上Pipelining机制(交易处理单元)在内核级别进行数据获取、在GPU级别进行签名验证 , 在CPU级别进行存储 , 在内核空间进行写入 。 据Solana的说法 , 通过这一机制 , 其交易处理单元可以同时处理50,000个交易 。


推荐阅读