这次一定好好学 Solana (1) : PoH 共识简介

  • dgu
  • 发布于 20小时前
  • 阅读 249

参加了Tiny熊老师的Solana全栈开发的课程针对第一课中的共识部分,结合官网和Grok提问总结了笔记,然后将散乱的笔记给Grok再次整理,得到了这个比较通俗易懂的满意版本你的笔记已经涵盖了Solana共识机制和PoH的核心内容,虽然有些地方稍微零散,但知识点都很到位

参加了Tiny 熊老师的Solana全栈开发 的课程 针对第一课中的共识部分, 结合官网和 Grok 提问总结了笔记, 然后将散乱的笔记给 Grok 再次整理, 得到了这个比较通俗易懂的满意版本

你的笔记已经涵盖了 Solana 共识机制和 PoH 的核心内容,虽然有些地方稍微零散,但知识点都很到位。我帮你整理成一个更结构化的版本,按照主题分块,逻辑更清晰,同时修正一些小错误或模糊表述。以下是整理后的笔记:


Solana 共识机制与 PoH 笔记

1. 基本概念

  • Epoch:\ 纪元:

    • 持续时间:约 2 天。
    • 包含:432,000 个 slot。
  • Slot:\ 插槽:

    • 时长:目标 400 毫秒(实际可能因网络条件略有波动)。
    • 作用:每个 slot 由一个 Leader 产生一个 block。

2. 领导者调度(Leader Schedule)

  • 如何预先确定 Leader:

    • 在每个 epoch 开始时,所有验证者根据 PoH 和当前的质押分布计算整个 epoch 的领导者调度表。
    • 这是一个伪随机算法,依赖 PoH 的种子和质押权重。
  • 简化的算法步骤:(跟 web2 中的分库分表方案类似)

    1. 获取总质押:

      • 统计 epoch 开始时快照中的总质押 SOL 数量。
    2. 生成随机值:

      • 使用 PoH 提供的种子(epoch 开始时的哈希值),通过伪随机算法为每个 slot 生成一个值。
      • 将该值映射到总质押范围(例如求模总质押量)。
    3. 分配 Leader:

      • 根据验证者的质押权重,将随机值映射到对应的验证者,确定每个 slot 的 Leader。
  • 例子:

    • 总质押 1000 SOL,验证者 A(400 SOL)、B(300 SOL)、C(300 SOL)。
    • 随机值 0-399 分配给 A,400-699 给 B,700-999 给 C。

3. Proof of History (PoH)\

  • 定义:

    • 一个全局一致的哈希链(hash chain),提供时间戳和种子。
    • 通过本地计算减少传统区块链(如比特币、以太坊)的网络通信开销,提高吞吐量。
  • 哈希链原理:

    • 基本公式:next_hash = SHA-256(prev_hash || data)。\ 基本公式:next_hash = SHA-256(prev_hash || data)。
    • 如果有交易(tx):next_hash = SHA-256(prev_hash || tx)。\ 如果有交易(tx):next_hash = SHA-256(prev_hash || tx)。
    • 如果无交易(时间推进):next_hash = SHA-256(prev_hash)。
  • 作用:

    • 在调度中:提供种子生成领导者调度表。
    • 在出块中:记录交易顺序和时间。

4. 出块过程(Block Production)

  • Leader 的操作:

    1. 收集网络中的交易(tx)。

    2. 将交易按顺序输入本地 PoH 哈希链:

      • 计算 next_hash = SHA-256(prev_hash || tx)。\ 计算 next_hash = SHA-256(prev_hash || tx)。
      • 无交易时,持续计算 next_hash = SHA-256(prev_hash)。
    3. 打包 PoH 链和交易,生成区块并广播。

  • 特点:

    • PoH 确保交易顺序可验证,时间一致。

5. 验证过程(Validation)

  • PoH 验证:

    • 验证者使用交易信息(tx)重新计算 PoH 哈希链:

    • 检查 hashn = SHA-256(hash\{n-1} || tx) 是否匹配。

    • 验证哈希链连续性和交易顺序。

    • 不执行交易:仅验证哈希,不重新运行交易逻辑。

  • 状态更新:

    • PoH 验证成功后,验证者等待 Tower BFT 共识确认。
    • 确认后,根据区块的状态更新本地数据库(例如账户余额)。

6. Tower BFT 共识

  • 投票机制:

    • 验证者对区块的 PoH 最终哈希投票。
    • 投票通过 gossip 协议传播。
  • 2/3 确认:

    • 根据质押权重计算:

    • 例子:总质押 1000 SOL,2/3 阈值 = 667 SOL。

    • 如果收到投票质押总和 > 667 SOL,则达到 2/3。

    • 验证者监听投票消息,统计本地收到的质押权重。

  • 时间:

    • 已确认(Confirmed):

    • 乐观情况下,1-2 个 slot(400-800 毫秒)收集到 2/3 投票。

    • 已最终化(Finalized):

    • 等待 32 个 slot(约 12.8 秒),确保分叉被淘汰。

  • 分叉处理:

    • 如果出现分叉,Tower BFT 通过投票权重选择最重链。

7. Proof of Stake (PoS)\ 7. 权益证明 (PoS)

  • 质押机制:

    • 验证者需质押 SOL 参与网络。
    • 质押越多,被选为 Leader 的概率越大(影响调度表)。
  • 激励与惩罚:

    • 正确行为获奖励,恶意行为(如双重投票)被削减质押(slashing)。

8. 与传统区块链的对比

  • 传统(如比特币、以太坊):

    • 依赖节点间通信达成时间共识,效率较低。
  • Solana 的 PoH:

    • 本地验证交易时间顺序,减少通信开销,提升吞吐量。

点赞 5
收藏 2
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
dgu
dgu
江湖只有他的大名,没有他的介绍。