最近在研究solana 的东西，简单做一下总结，很久没有写文章了。写的不对的地方欢迎评论区或者私信。及时改正。
Solana 架构概述
1.0 核心模块
Solana 的架构包括以下核心模块：
- Proof of History (PoH)：通过时间排序机制优化交易排序和共识过程，减少网络同步带来的延迟。
- Leader 和 Validator 节点：Leader 负责生成区块，Validator 节点验证区块并参与投票确认。
- Turbine 数据传播协议：基于分片的树形传播协议，提升了区块数据传输的效率。
- Sealevel 并行执行引擎：分析交易之间的依赖性，实现无锁并行处理。
- Cloudbreak 数据存储系统：通过分片存储账本状态，提高了状态存取的随机读写性能。
2.0 Solana 核心技术详解
2.1 Proof of History (PoH)
PoH 是 Solana 的时间排序核心机制，通过递归哈希生成时间序列，为交易排序提供加密保证。
原理概述
- 连续哈希链：通过一个快速的哈希函数（如 SHA-256）递归计算，生成不可篡改的时间序列。
- 排序优化：验证者只需检查哈希链的完整性即可验证交易发生的顺序，而无需复杂的全网广播和同步。
- 减少等待时间：PoH 的时间戳为每笔交易提供了唯一且确定的时间标记，优化了区块链的排序效率。
2.2 Solana 的数据传输优化
Solana 的高性能网络协议主要依赖以下技术：
2.2.1 UDP 传输
Solana 使用 UDP 代替传统的 TCP 协议作为底层数据传输协议。UDP 的无连接特性适合高性能系统，具备以下优势：
- 低延迟：避免了 TCP 握手和连接建立过程带来的开销。
- 高吞吐量：支持大规模的并发数据传输。
- 自定义控制：Solana 实现了自己的流量控制和错误恢复机制，以补充 UDP 的简单特性。
2.2.2 Reed-Solomon 数据校验
Solana 在数据传输中采用 Reed-Solomon 校验码进行数据完整性校验。它的主要功能是通过冗余数据的引入实现错误检测和恢复：
- 数据完整性保障：即使某些数据包丢失，也能通过校验码进行数据恢复。
- 高效传播：结合 Turbine 分片协议，减少整体网络的重复传输负载。
以下是 Turbine 数据传播的架构图，展示了分片和树形传播的过程：
生成数据分片 1 生成数据分片 2 生成校验码 发送分片 1 发送分片 1 发送分片 2 发送分片 2 校验分片完整性 校验分片完整性 转发分片 1 转发分片 1 转发分片 2 转发分片 2 Leader 节点 Shard 1 Shard 2 Reed-Solomon 校验数据 Validator 1 Validator 2 Validator 3 Validator 4 下一层 Validator 下一层 Validator 下一层 Validator 下一层 Validator
2.3 Turbine 数据传播协议
Turbine 是 Solana 高效的区块数据传播协议，结合了分片和树形传播的理念。
工作流程
- 分片：Leader 节点将区块切分成若干小数据块（Shards），每个分片携带部分原始数据和校验信息。
- 树形传播：每个节点只需将数据发送给部分 Validator，而不是全网广播。通过多层传播，所有节点最终都能收到完整的区块数据。
- 数据恢复：如果某些数据丢失，可以通过 Reed-Solomon 校验码进行恢复，无需重新请求整个区块。
2.4 Sealevel 并行执行引擎
Sealevel 是 Solana 智能合约的执行引擎，通过分析交易的账户依赖性，实现无锁并行处理。
执行优化
- 依赖性分析：通过静态分析每笔交易的账户读写依赖，判断它们是否可以并行执行。
- 批次执行：将互相独立的交易分组，并行执行多个交易组，大幅提升处理能力。
以下是并行化的示意流程：
- 确定交易的依赖关系。
- 划分独立的批次。
- 并行处理批次，减少执行瓶颈。
3.0 Solana 的共识机制
Solana 的共识机制结合了 Proof of Stake (PoS) 和 Proof of History (PoH)，实现了高效且低能耗的区块确认流程。
3.1 Slot 和区块生成
- Slot 时间段：每个 Slot 是一个固定的时间间隔，由指定的 Leader 处理交易并生成区块。
- 区块排序：Leader 使用 PoH 时间戳为交易排序，并生成区块提交给 Validator 节点验证。
在 Solana 的架构中，Slot 和 Epoch 是关键的时间单位，它们直接决定了区块生成的时间安排和 Leader 的轮值。以下详细解析 Slot 的时间定义、Epoch 的周期，以及 Leader 如何确定。
3.1.1 Slot 的持续时间
- Solana 的默认 Slot 持续时间是 400 毫秒。
- 理论上，网络每秒可以生成 2.5 个区块（即每 400 毫秒生成一个区块）。
- 高吞吐量来源：多个 Slot 可以在不同的节点上并行处理，因此 Solana 的吞吐量远远高于传统区块链。
3.1.2 Epoch 的时间定义
- Epoch 是一组连续 Slot 的集合，用于组织 Leader 的轮换和质押奖励的结算。
- 在每个 Epoch 开始时，系统会根据质押分布重新计算 Leader Schedule（即 Slot 到 Leader 的映射）。
- Epoch 持续时间是可配置的，通常为 432,000 Slots（约 2 天）。
- 一个完整的 Epoch 结束后，系统会根据最新的网络状态重新分配下一个 Epoch 的 Leader。
3.2. Leader 是如何确定
3.2.1 基于质押的 Leader 选举机制
Solana 使用 Proof of Stake (PoS) 确定每个 Slot 的 Leader，主要规则如下：
- 质押权重：
- 每个 Validator 根据质押的 Token 数量获得一定的投票权重。
- 权重越高，被选为 Leader 的概率越大。
- 随机性：
- Leader 的分配需要一定的随机性，防止权重高的节点连续当选，造成中心化。
- Solana 使用 Leader Schedule模块来选出leader。
- 确定性：
- 通过计算，系统在 Epoch 开始时预先生成整个 Epoch 的 Leader Schedule。
- 每个 Slot 都会有明确的 Leader，所有 Validator 都能预测当前的 Leader。
- Leader 的切换机制
当 Slot 结束时，系统会切换到下一个 Slot 的 Leader： - 无缝切换：
- 下一个 Slot 的 Leader 会在当前 Slot 结束前做好准备，接收并验证来自前一个 Slot 的交易和区块。
3.2.2 容错机制：
- 如果当前 Slot 的 Leader 无法按时生成区块（例如宕机或延迟过高），Validator 将跳过该 Slot，由下一个 Slot 的 Leader 继续处理交易。
- 这种机制确保了网络的容错性，即使某些节点无法工作，也不会影响整个网络的运行。
Slot 和 Leader 的图示
以下是 Slot 和 Leader 之间的关系图示，展示了多个 Slot 的 Leader 轮换过程：
Epoch Leader 1 Leader 2 Leader 3 Leader 4 Leader 5 Slot 2 Slot 1 Slot 3 Slot 4 Slot 5 Validator A Validator B Validator C Validator A Validator D
- 每个 Slot 分配一个独立的 Leader。
- Validator A 被分配到多个 Slot，但不会连续当选。
Solana 针对质押金额设计了灵活的动态调整机制，确保网络的稳定性和公平性：
- Epoch 切换时更新：
- Solana 每个 Epoch 开始时都会重新生成 Leader Schedule。
- 系统会根据最新的质押状态重新计算每个 Validator 的质押权重。
- Slot 分配调整：
- 如果 Validator 的质押金额减少，在新的 Schedule 中分配到的 Slot 会减少。
- Leader Schedule 动态更新：根据最新质押权重重新分配 Slot，减少低质押节点的影响。
- 投票权重调整：质押减少直接降低节点的共识权重。
- 解锁机制：质押减少需要经历一个周期，防止突发变化影响网络安全。