Streamlette：Streamlet，除了单个决策

我们将 Streamlet 直接转换成一个单次共识算法。

在 Streamlet 中，我们有一个持续增长的 树，其中“足够深埋”的块变为 最终确定。

在 Streamlet 中，共识算法的一个实例的目的是最终决定一个 结论。我们跟踪三种不同消息类型的树

• 提案 具有带“滴答数”的提案。提案必须通过一个 验证函数。
• 请求 指向先前提案或先前请求的哈希。它们也具有“滴答数”。
• 投票 指向请求或提案的哈希。

将 Streamlet 最终化标准转换为，被三个连续编号的、公证的（>2/3 投票）请求埋葬的提案变为最终确定。只有一个这样的提案（正确性），通过类似于 Streamlet 的证明。

测试、模糊测试等

模糊测试共识实现非常重要。Streamlette 必须在以下方面是通用的

• 网络骨干
• 验证函数
• 投票权重函数，并且不会以任何方式与 themelio-stf 和朋友紧密耦合。理想情况下，它应该作为任何需要 BFT 共识的东西的 BFT 共识很有用。

对于模糊测试，我们希望能够确定性地重新生成共识算法的运行。这意味着我们必须能够外部“滴答”每个共识参与者，而不是让它在不后台运行，同时使用确定性 RNG 来模拟不可靠的网络。模糊测试将检查诸如活性和安全性之类的守恒量，并通过确保故意有缺陷的逻辑（例如，使用 50% 阈值而不是 2/3 阈值）确实导致失败来进行合理性检查。

实现架构

• 核心：实现消息树。包含获取和应用差异以及获取任何最终提案的方法。我们使用基于差异的、“拉”方法来传播消息，而不是使用“推”方法，以维护关键属性，即 所有诚实玩家发送的消息最终都会到达所有诚实玩家，即使是在不可靠的八卦网络中。
  • 获取提示：获取消息树的提示哈希
  • 获取差异：给定某人的消息树的“提示”，获取一些后续消息（限制为一定大小）以扩展他们的树，使其更像我们的树
  • 应用差异：将消息插入到树中
• Decider：实现协议，统一在一个单一的 tick() -> Result<Option<Bytes>, Fatal> 函数中。 tick_to_end() 块和驱动 tick() 函数，使用通常的逐渐减慢的时钟。
  • 初始 tick 应该是大约 1 秒以确保快速进展
  • 这样，“真实程序”可以简单地 tick_to_end() -> Result<Bytes, Fatal>，而模糊器以“模拟”配置确定性地调用 tick()。
  • 没有任何 应该跑到后台去。当 Decider 崩溃时，所有资源应同步释放。
• 所有通过 DeciderConfig 特性传递的内容
  • 使用特性和类似的动态分发来避免病毒式泛型
  • 返回有关投票力量、熵种子和公钥列表的信息；一个辅助函数从这个信息中产生正确的提议者
  • 整个网络抽象为 next_diff_req(req) 和 get_diff_from_peer(req)，这两个都必须快速返回，或者在不可能的情况下超时
• 只有 Fatal 的致命错误传播到客户端（下一版本 TODO；目前我们不返回错误，坏东西会导致不良行为）
  • 基本上，不变性没有被维护
  • 表示一个无法恢复的，>1/3 的拜占庭故障
  • 不要本地断言这一点。并不是所有使用 Streamlette 的用户都希望在无法达到共识时崩溃。