Simperby：协议概述

Simperby: 协议概览

Simperby 是一个区块链引擎，用于运行一个组织，该组织具有：

1. 去中心化
2. 独立、自主且自托管
3. 拥有一组具有权限的成员

它提供：

1. 共识 (Consensus)：一种安全且具有活性的机制，用于最终确定组织的 状态，该机制能够容忍异步网络中的拜占庭故障。
2. 治理 (Governance)：一种民主机制，用于对组织做出决策， 这些决策可以通过共识最终确定。
3. 通信渠道 (Communication Channel)：一种以去中心化、可验证且容错的方式 进行相互通信的机制。

基础知识和术语

本文档的读者应熟悉区块链的基本概念。

• Simperby 是一个可以构建区块链实例的引擎。使用 Simperby 构建的任何 区块链有时被称为 Simperby 链。
• 状态转换的单位称为交易 (transaction)。StoreData、 DelegateGovernanceVotingPower、AddValidator 是示例。
• 一系列交易被称为议程 (agenda)。任何治理投票都在议程和目标区块高度上执行。
• 一个区块 (block) 由头部和单个议程组成。不允许没有议程的区块。
• 此外，一个区块可能包含一些议程外交易 (extra-agenda transactions)， 提案者可以依职权包含这些交易，但严格限制为三种类型。
• 治理的参与者称为成员 (members)。
• 共识的参与者称为验证者 (validators)，它是成员的一个子集。
• 共识领导者 (consensus leader) 或 区块提议者 (block proposer) 是一个 验证者，其为该轮次提出一个区块。
• 轮次 (round) 是一个时间段，在此期间，共识领导者提出一个区块， 并执行共识投票（预投票 (pre-vote)，预提交 (pre-commit)）。有关更多详细信息， 请参阅 Tendermint。
• 如果验证者遵循共识协议，则验证者是诚实的 (honest) 或 非拜占庭式的 (not byzantine)。
• 如果区块提议者履行其职责，则区块提议者是忠实的 (faithful)，如果他们不滥用职权， 则是好的 (good)。否则，他们是懒惰的 (lazy) 和 坏的 (bad)。 责任 和 权力 的概念将在 稍后 解释。

概要

以下是 Simperby 协议的概要版本。

1. 我们希望节点操作 简单且轻量，以实现真正分布式、去中心化和自托管的 组织。
2. 为此，关键假设是大多数节点 很少在线，并且协议 按需 产生新区块。
3. 为了完成这个目标，共识轮次必须非常长。
4. 对于每个区块，成员可以 对议程进行投票或提出议程。议程和 投票会 通过 Gossip 网络相互传播。
5. 同时，成员还可以 传播用于人际沟通的任意聊天信息， 这些信息 由区块提议者排序。
6. 如果网络上存在 治理批准的（多数投票的）议程， 区块提议者应 将其与聊天记录一起包含在区块中，并提交给共识。
7. 因此，区块提议者应大部分时间在线（聊天协调和区块提议），这种 责任应由少数验证者承担，以确保很少在线的假设。
8. 此外，区块提议者的角色具有一些权力（聊天协调和议程包含），如果被滥用， 则无法通过加密方式验证（通常是审查）。
9. 因此，存在 “少数验证者” 大部分时间接管区块提议，但可能会偷懒或对其权力 进行有害的滥用，这些滥用实际上不是拜占庭故障或无效区块。
10. 通常，在普通区块链中，这不是问题，因为轮次很短，并且区块提议者会定期更换。 正如所解释的，我们不是。
11. 因此，我们需要一种特殊的机制来 “否决” 区块提议者，以免在共识层中浪费 较长的轮次。因此，我们引入了一种特殊的 Tendermint 变体，称为 Vetomint。
12. 在 Vetomint 中，验证者可以否决当前的区块提议者，但是， 如果所有诚实的验证者都投票或否决，则轮次仍将继续进行而不会超时（更改区块提议者）。

简单且轻量级的节点操作

Simperby 强烈鼓励每个成员运行其节点，以确保网络是去中心化和分布式的 （因此真正是自托管的）。换句话说，运行 Simperby 链不是由少数人使用 AWS 服务器，而是使用他们的笔记本电脑物理地运行该链。为实现这一目标，重要的是 尽可能保持节点操作简单和轻量。

很少在线的节点

对于 简单 和 轻量级 节点操作而言，最重要的条件之一是节点需要在线的频率。 如果我们希望验证者在他们的笔记本电脑上运行节点，那么假设他们将 24/7 全天候在线是不现实的。

由于 Simperby 的 BFT 共识假定一个部分同步的网络，因此可以轻松地处理很少在线的节点， 因为这只不过是异步的一个典型案例，如果

1. 共识轮次足够长（或已增长到足够长），可以覆盖所有节点的出现。
2. 当有网络广播时，至少有一个节点保持在线，可靠地服务于 Gossip 协议

条件 1 最终会成为后面章节中的一个艰巨挑战，请牢记这一点。

按需区块生成

很少在线的节点意味着很少进展的区块链。（请注意，在任何 BFT 算法中， 必须至少有 2/3 的节点参与共识过程才能生成区块）

这将不可避免地损害区块链的延迟或吞吐量，但这无关紧要，因为 Simperby 不是 用于为公共用户提供服务的一般合约平台， 而是一个为一组具有权限的成员提供服务的治理平台。

Simperby 区块链仅包含经过治理批准的状态转换（有非常 少的例外）。 每个治理议程都必须经过成员的多数投票批准，因此需要时间（几天甚至几周）。 考虑到这一点，自然地，Simperby 的性能受治理过程的约束，而不是受轻量级节点操作 减慢的共识的约束。

多链 DAO

Simperby 的一个值得注意的用例是它可以建立一个 多链 DAO。（有关更多详细信息，请参见 此处） 使用 Simperby 共识的轻客户端将组织扩展到其他现有链（所谓的“殖民链”）非常容易。 由于轻客户端作为合约上传到其他链，因此 Simperby 共识的任何区块进展都需要额外的事务来更新和存储其 Merkle 根。 这可能并不便宜，因为 组织将必须为每个 Simperby 区块支付每个殖民链的 gas 费用。 这是认为按需区块生产合理的另一个原因。

治理

Simperby 的治理是通过 P2P 投票实现的。

• 任何成员都可以提出议程，它将在 P2P 网络上传播。
• 任何成员也可以对议程进行投票（如果他们更喜欢它）。该投票也将 被传播。
• 任何获得超过 50% 选票的议程都 有资格 包含在区块中。
• 只有 包含符合条件的议程的区块 才是 有效 的。换句话说，不允许空区块。
• 决定最终确定哪个符合条件的议程是共识的角色，而不是治理的角色。
• 共识是一种基于领导者和轮次的 BFT 算法。

什么可以成为议程？

• 事务只是 状态转换 的单位，而不是像传统区块链那样签署和广播的单个项目。
• “议程” 定义为 (Proposer, Height, [Transaction(s)])。
• 只有一个 单个议程 可以包含在一个区块中。这是为了防止 复杂的依赖性问题。
  • 如果允许多个议程，则每个议程必须是独立的；否则， 选民无法确定每个议程的排序方式，甚至无法确定它是否包含在最终确定的区块中。 这将对可能的议程项目造成严重限制。
• 因为 Height 是议程的一部分，所以每个议程及其投票都将 过期，因此如果区块高度进展，则会被丢弃，尽管可能会重新提出和重新投票。

聊天

同样，Simperby 是一个区块链引擎，它运行一个 独立的、自主的和自托管的 组织。 因此，组织的通信渠道也应如此。实现这种渠道（而不是 Discord）的唯一方法 是利用现有的 P2P 网络。

• 任何成员都可以广播其消息，并由其公钥签名。
• 每条消息都包含签名者感知到的每条先前消息的哈希列表，形成一个链。
• 像 PoW 一样，最长的聊天链被认为是规范链的候选者。
• 该轮次的共识领导者（区块提议者）扮演着特殊的角色。
  • 领导者也可以广播聊天消息，但是此类聊天消息被认为是 半最终确定的点。
  • 一个 忠实 的领导者会 频繁地 在 （看起来）最长的链上 插入其 ack 聊天消息。
  • 一个 好的 领导者不得提交分叉（半最终确定两个冲突的链）
• 在最近的领导者半最终确定的聊天消息之上，其他成员继续 使用最长链规则进行聊天，直到下一个最终确定点。
• 一旦治理达成符合条件的议程，领导者必须最后一次半最终确定 聊天链，并将其包含在区块中。如果该区块通过共识最终确定，则该区块的聊天记录也将 被最终确定。
• 一个 好的 领导者必须包含最后一个半最终确定的聊天链，该链是 其他成员会认为规范的聊天链。

为什么领导者不只是提供聊天服务器？

领导者仅“半最终确定”聊天链而不是运行完整的聊天服务器的原因是， 它更具抗审查性。

• 与完整的聊天服务器相比，最长链协议具有 较弱的 （由于缺乏网络同步）共识（最长链），即成员之间规范的总聊天排序。
• 因此，如果领导者尝试审查（即，重复对不是其他成员观察到的最长聊天链进行半最终确定）， 则很容易 注意到 这一点，尽管由于网络异步的假设，它在理论上是无法验证的。 （这可能是一个巧合，源于领导者周围可能存在的网络延迟）
• 尽管如此，如果领导者尝试进行更多审查，它将变得更加 可疑。

请注意，如果有恶意成员试图垃圾邮件聊天，则领导者将不会 最终确定垃圾邮件链，并且其他成员会将此类 审查视为 not bad。

共识中会发生什么？

共识领导者（区块提议者；不要与 议程提议者 混淆）在区块中包含符合条件的议程 （如果存在多个符合条件的议程，则领导者只需选择一个），并提出它。 有效区块必须包含符合条件的议程。换句话说，如果没有符合条件的议程， 则区块链中没有区块进展。

除了议程之外，领导者还可以包含 议程外 内容，这些内容不需要治理批准， 但具有其自身的证据表明可以接受。

1. RecordChatLog（该高度的聊天日志）：这不会更改 状态，而是用作议程的治理记录。
2. ReportMisbehavior（共识中的双重投票以及过去共识领导者的聊天最终确定 不当行为）：这将自动导致削减行为不端的验证者的投票权。
3. Delegate/Undelegate：委派或取消委派投票权（用于 共识或治理）给另一名成员。这需要委托人的签名。

这三项事务是议程中没有的唯一例外，并且由提议者依职权直接包含。

共识领导者

你可能会注意到，共识领导者的角色在 Simperby 治理中非常重要。

责任

领导者应 负责。

• 领导者应在整个轮次中在线，提供足够的 聊天链半最终确定频率。
• 如果有任何符合条件的 议程，领导者应尽快提出区块。
• 领导者还应报告不当行为。

同样，Simperby 的关键要求之一是使节点操作尽可能轻量， 尤其是在节点应在线的次数和时长方面。 因此，将担任领导者的负担放在循环赛中，这最终将均匀地涉及到所有验证者，这只会使他们感到筋疲力尽。

为了缓解这个问题，Simperby 支持 稳定领导者 功能。

• 领导者顺序在状态中确定。
• 如果状态中指定的顺序保持不变，则领导者顺序在整个高度上都不会更改。（即， 第一轮的领导者保持不变）
• 对于单个高度，还可以重复前几个领导者 进行几轮。（例如，1->1->1->2->2->3->4->... 而不是 1->2->3->4->...）

稳定领导者的另一个优点是它是 可预测的。每个 验证者都可以非常确定他们应该根据 稳定领导者列表中的顺序打开节点的频率。

只要选择的前几个领导者是诚实的（非拜占庭式的），并且 忠实（履行其职责），网络将保持 活跃。

权力

领导者具有 权力。

• 如果有 多个符合条件的议程，则领导者可以选择将哪个议程包含在区块中。
• 领导者可以选择要半最终确定哪个聊天链。

一个 好的 节点应该对议程客观；他们应该选择第一个 符合条件的议程，而不是等到观察到另一个对自己有利的事情才采取行动。 同样，一个 好的 节点也应该对聊天链半最终确定保持客观。

只要选择的前几个领导者是诚实的、忠实的，甚至很好， 网络不仅会 活跃 而且还会 公平。（请注意，无论领导者的行为如何，它始终是 安全 的；安全性由 BFT 共识保证）

单点故障

总而言之，领导者具有 责任 和 权力。实际上， 这与其他使用基于领导者的 BFT 共识的区块链并没有太大不同。 领导者应在整个轮次中在线，以接收足够数量的交易（在“内存池”中）， 并且领导者选择将哪些交易包含在区块中。唯一的区别是我们没有用户 签名的交易，而是治理签名的议程，并且我们有一个用于聊天最终确定的附加协议。

那么，“其他区块链” 如何处理领导者的责任和 权力？很简单；它们的轮次时间很短（几秒钟）， 并且每隔一个区块就旋转轮次顺序，这样“用户”（对应于 Simperby 中的“成员”）的实际体验 会收敛到验证者群体的平均水平。换句话说，即使某些区块提议者很懒惰（不 忠实）或很坏（尝试审查），用户也不会受到严重影响， 因为直到下一个区块提议者来为他们的交易提供服务之前，时间都不会太长。

这种问题可以被描述为 单点故障 问题，由于长轮次和 稳定领导者条件，我们尤其会受到影响。

解决此问题的唯一方法是：

1. 治理部门批准弹劾领导人的议程，即将其从验证者列表中删除。 这是一个理想的解决方案，因为它会立即更改领导者。
2. 如果领导者未在其区块中包含符合条件的议程，则还有 最后的手段：治理部门不批准任何议程，因此提议者 无法提出任何有效的区块。请记住，空区块是无效的。这将在漫长的轮次超时后 退出该轮次。

共识

到目前为止，我们已经讨论了 Simperby 的治理和人际沟通如何 假设抽象的底层 BFT 共识。它可以很好地工作，但是我们发现 在发生偷懒的情况下，存在严重的时间滞后问题。在糟糕的领导者的情况下，甚至可能存在永久性的审查， 如果在漫长的轮次之后治理部门不批准任何 议程，则仍然可以解决此问题。这可行，但考虑到“漫长” 可能是一个星期或更长时间，因此效率不高。

现在，我们将共识层视为处理此问题的一种选择，但是 不幸的是，理想情况下，无法在共识层中解决此问题。 与可以通过某些加密证据直接验证的拜占庭式或“不诚实”行为（例如，双重 预投票）不同，共识无法处理“不忠实”或“不良”的领导者，因为它未能违反 共识协议。

基于领导者 vs 无领导者

有人可能会认为“无领导者”共识可能是此问题的解决方案。 基本上，可能如此，但是存在一个关键问题：网络复杂性。在 基于领导者的共识中，如果验证者启动其节点两次（即两次广播），则网络可以（在最佳情况下）取得进展。 但是，在无领导者共识中，广播的数量与 验证者的数量成正比。在我们轻量级节点操作的基本假设中，这是永远无法接受的。

TODO：检查它并添加参考

否决轮次

同样，由于偷懒或审查都未违反共识协议，因此无法通过共识层来处理。 但是，如果我们 利用网络异步性，我们可以找到一条绕行之路。 如果验证者得出结论，由于诚实但懒惰或不良的领导者，应退出当前轮次， 则他们可以 假装该轮次已超时。这提供了优于 普通 Tendermint 的非常特殊的功能：否决领导者。

由于 Tendermint 基于轮次，因此存在一种称为 nil-vote 的特殊机制。节点可以在超时后投空票， 以退出当前轮次。这与非空票的情况类似， 因为它需要两个步骤。

在普通 Tendermint 中，如果验证者使用空票来否决提议者， 它只是有效，因为它与仓促超时并没有太大不同，但在分裂的情况下，它可能会停滞不前直到超时。（考虑 6/10 的非空票和 3/10 的空票，1/10 的无响应拜占庭节点） 同样，因为在这种情况下我们使用非常长的轮次，所以等待轮次的超时会浪费大量时间。如果我们遇到 这种不幸的分裂情况，它并不比治理的解决方案（不批准议程）更好。

Vetomint

为了改善这一点，我们提出了 Tendermint 的一种变体，称为 Vetomint， 它在“分裂”的情况下有效。

属性

1. <1/6 BFT
2. 允许（即，被视为非拜占庭行为）在超时之前投空票， 并提供 某种理由。
3. 如果所有诚实的节点都投非空票或空票，则可以保证轮次会进行； 提前终止。
4. 如果所有诚实的节点都投非空票，则可以保证区块 会进行。
5. 如果超过 2/3 的节点投非空票，则区块将以 >0 的概率进行。

它是如何工作的？

在 Vetomint 中，与 Tendermint 不同，如果 超过 5/6 的节点投非空票或空票，则该轮次 始终会立即进行。 特别是当 5/6 的节点投非空票时，可以保证高度会进行。阈值 5/6 足以确保所有节点都观察到至少 2/3（Tendermint 多数）的非空票， 而无论投票的个人到达顺序如何，即使可能存在 1/6 的空票。 请注意，与 Tendermint 不同，由于我们有一个新的“提前终止”条件， 因此“到达顺序”很重要。

详细信息在 官方参考 中解释， 伪代码 在此。

在对原始 Tendermint 进行一些简单的简化之后，可以很容易地证明它是形式上安全且活跃的。

• 原文链接： github.com/postech-dao/s...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～