Simperby：治理母舰
- 4pillars
- 发布于 2023-11-07 10:46
- 阅读 24
Simperby 是由 PDAO 开发的开源区块链引擎，允许 OO（Onchain Organization）创建独立的链来进行治理决策，类似于 Cosmos SDK 创建 Cosmos 应用链。
要点
-
Simperby 是由 PDAO 开发的开源区块链引擎，它允许 OO 为其治理决策创建独立的链。这类似于 Cosmos SDK 如何支持创建 Cosmos 应用链。
-
Simperby 基于 3S 原则：独立（Standalone）、自治（Sovereign）和自托管（Self-hosted）。这使得 OO 可以按照自己想要的方式做出决策和进行治理，而无需依赖其他链或协议。
-
Simperby 是一种治理工具，专门用于支持多链结构，这使其非常适合 OO 想要跨多个链扩展的结构。
感谢 @junha_yang 审阅并提供对本文的反馈。
1. Onchain Organization (OO)（链上组织）
1.1 OO，而非 DAO
就我个人而言，我更喜欢将使用区块链技术的组织统称为 Onchain Organizations (OOs)（链上组织）。我认为将它们都称为 OO，承认 OO 内部的多样性，并从包容的角度看待它们更有建设性，而不是继续争论某个特定的 DAO 是否真的是一个 DAO。毕竟，最终目标是通过区块链技术使人类协作更容易。
OO 内的组织采取许多不同的形式。它们可以是完全去中心化的，我们称之为 DAO，或者它们可以是 BORG，它使用 AI 和智能合约来减少人为错误，同时仍然遵守当前的法规，或者它们可以是简单地将其集体资金作为链上国库管理的一小群人。每个 OO 自然会根据组织成立的目的和背景，决定利用多少区块链技术。
1.2 不同的 OO 工具
如下表所示，OO 工具的种类与 OO 的形式一样多。最常见的 OO 工具是 OO 框架，这些框架使创建和运营 OO 变得容易，例如 Snapshot + SAFE 和 Aragon。
来源: 1kxnetwork
1.2.1 Snapshot + SAFE
Snapshot 是一个链下治理平台，允许 OO 的成员通过他们的钱包对提案进行签名和投票。由于大多数使用 Snapshot 的 OO 在链上管理资金，因此它通常与 SAFE（一种多重签名国库管理解决方案）结合使用。由于 Snapshot 是链下的，而 SAFE 是链上的，因此 Snapshot 的结果不能直接在 SAFE 中执行，并且需要中间人再次介入，这对于某些 OO 来说可能是一个问题。
考虑到这一点，Snapshot 与乐观预言机协议 UMA 合作发布了一个名为 oSnap 的模块。 oSnap 允许任何人提交执行 Snapshot 结果的交易，如果在挑战期间没有发生欺诈证明，它将被应用于 SAFE。因此，oSnap 减少了对多重签名成员的依赖，这是现有 Snapshot + SAFE 组合的一个缺点。此外，Snapshot X 是一个构建在 StarkNet（一个基于 ZK 的 Layer 2）之上的投票框架，它允许 OO 以最小的成本获得与 Layer 1 上的链上投票相似的安全级别。
1.2.2 Aragon
Aragon 是一个致力于通过更通用的框架使创建和管理 OO 变得更容易的项目。 Aragon 由两种类型的服务组成：Aragon OSx 和 Aragon App。
首先，Aragon OSx 是一个模块化堆栈，它允许你使用 OSx 协议的智能合约和治理插件来创建任何可以想象到的 OO 形式，并通过 OSx 协议核心的权限管理系统轻松适应和替换治理插件。这允许基于 Aragon OSx 的 OO 快速轻松地试验不同的治理。另一方面，Aragon App 是一种用户友好的服务，不需要任何代码编写，允许 OO 使用 Aragon App 的界面在几分钟内创建 OO。
1.3 Simperby 是不同的
除了上面介绍的两个项目之外，现有的 OO 工具（如 DAOHaus、Colony 和 Syndicate）都专注于改善创建和运营 OO 的用户体验，并支持各种形式的 OO。这些项目通过提供易于使用的界面、简约、通用的 OO 框架以及允许 OO 根据自己的喜好自定义它们的插件和扩展来实现这一点。
Simperby 有趣的原因在于它与现有的 OO 框架相比，它具有不同的方法、目标和对象。因此，虽然很难说 Simperby 优于现有的 OO 框架，但对于某些 OO 来说，它肯定比其他现有的 OO 框架更具吸引力。
2. 关于 Simperby
2.1 概述
Simperby 是由开源基金会 PDAO 开发的 OO 区块链引擎。 我们可以类比一下，正如 Cosmos SDK 允许你创建 Cosmos 应用链一样，Simperby 允许每个 OO 拥有自己的链来进行治理。通过 Simperby 创建的链仅是用于 OO 决策和共识的链，不支持智能合约，并且由于它仅供授权的 OO 使用，因此没有 token 或 gas 费。
2.1.1 目标
Simperby 最适合具有以下特征或需求的 OO：
Simperby 的目标是需要现有成员同意才能添加新成员的许可型 OO。因此，仅需要 token 即可自由参与治理的 OO 并不适合 Simperby。一般来说，现实世界的组织大多是许可型 OO，而链上原生 OO 大多是无需许可的 OO，但这并非总是如此。以 FWB DAO 为例，它可以说具有许可型 OO 的一些特征，因为它需要委员会成员的同意才能参与，而不仅仅是拥有 $FWB token。
此外，Simperby 最适合优先考虑 3S 价值的 OO。**3S 代表独立（Standalone）、自治（Sovereign）和自托管（Self-hosted）。Simperby 允许 OO 拥有自己的链进行通信和治理，从而允许他们按照自己的意愿做出决策和进行治理，而无需依赖其他链或协议。
就独立（Standalone）和自治（Sovereign）而言，很容易假定这是通过每个 OO 拥有自己的链来实现的。但是，3S 有一个方面可能存在疑问：自托管（Self-hosted）。一般来说，个人不仅难以在区块链上运行节点，而且在成本和资源方面也非常低效，因此几乎不可能要求普通人运行节点。
因此，Simperby 团队添加了许多技术机制，以使公众尽可能轻松简单地操作 Simperby 创建的链中的节点。正如你稍后将看到的，OO 成员可以轻松地从他们的笔记本电脑上运行节点，如果他们不是某个 round 的领导者，则只需偶尔在线即可，并且可以提前轻松预测何时需要在线。 通过减少运行节点的负担，我们使其既可以独立（Standalone）、自治（Sovereign），又可以自托管（Self-hosted）。
2.1.2 术语表
在我们进一步讨论 Simperby 之前，让我们澄清一些可能令人困惑的术语。
-
Simperby 链：通过 Simperby 创建的链，每个 OO 都有自己的 Simperby 链。
-
Agenda（议程）：治理提案，OO 的成员对议程进行投票。
-
Member（成员）：治理过程的参与者。
-
Validators（验证者）：共识过程的参与者。验证者是成员的子集。
-
Settlement chain（结算链）：使用 Simperby 链的 OO 与之交互的另一条链，例如，如果 OO 在 Ethereum 上有一个国库，则 Ethereum 是它的结算链。
2.2 特点
Simperby 链允许 OO 成员进行沟通、对议程进行投票，并就这些结果达成共识。
2.2.1 Chat（聊天）
Simperby 链提供了一个通信渠道，供节点通过 P2P 网络像 discord 一样进行通信。任何人都可以通过使用其公钥对其进行签名来发送消息，并且每条消息都包含前一条消息的哈希值以形成链，我们称之为聊天链。
对于聊天链，规范链由最长链规则确定，并且每个 round 中的区块提议者负责半最终确定聊天链。区块提议者将定期提交一个称为“ack”聊天的检查点到他们视图中的最长链，而其他成员将继续在该链上聊天。
2.2.2 Governance（治理）
治理实际上是 OO 成员一起通过议程的过程。任何人都可以提出议程，然后通过我们之前看到的聊天的点对点网络进行传播。如果成员同意议程，他们将使用其签名进行投票。超过 50% 的所有成员同意的议程有资格包含在区块中，我们称之为合格议程。
2.2.3 Consensus（共识）
共识是 OO 的状态通过将特定议程包含在区块中并确认该区块而在去中心化网络中被确定的过程。区块提议者必须立即提出包含合格议程的区块（只要它出现）。如果有多个合格议程，则区块提议者选择其中一个包含在区块中。一般来说，你会希望包含第一个变为合格的议程。由于议程相关时会出现问题，因此只能在一个区块中包含一个议程。
除了议程之外，区块提议者还可以在区块中包含一些不需要治理投票的信息。
-
区块提议者可以在特定议程变为合格议程的那一刻半最终确定聊天链，并将其包含在区块中。
-
指责前一个 round 的区块提议者的恶意行为，从而导致其验证者被削减。
-
将投票权委托和重新委托给特定成员。这需要成员的签名。
2.2.4 用户流程
总而言之，使用 Simperby 进行治理的用户流程如下：
-
OO 中的某人提出了一个新的议程。
-
成员通过点对点网络聊天并对新议程进行投票。
-
如果议程被足够多的成员接受，它将成为合格议程，并且该 round 的区块提议者将半最终确定聊天链以创建一个检查点。
-
区块提议者提出了一个包含合格议程的新区块。
-
OO 中的验证者通过共识过程达成对区块的共识。
-
根据它包含的议程类型，以不同的方式执行新区块。议程的范围可以从修改 OO 的治理参数，到指责成员的恶意行为，到使用另一个链的国库等等。
3. 共识机制
3.1 动机
如前所述，为了使 Simperby 实现自托管的价值，OO 中的每个人都必须能够运行节点，并且要实现这一点，运行节点必须简单且不占用大量资源。
3.1.1 仅在需要时在线
Simperby 链中的验证者不需要一直在线，而只需要在需要时在线，例如聊天、对议程进行投票或参与共识过程。在普通的区块链中，有必要保持 24/7 的在线时间，因为需要不间断地连续生成区块，但是在 Simperby 链中，由于它仅处理由许可集合提交的治理议程，因此没有必要一直生成区块，而只需要按需生成即可，因此没有问题。**但是，这要求每个 round 的超时时间足够长（例如，2 周），以便允许所有节点在超时之前出现。
3.1.2 谁将提议区块？
与普通验证者不同，区块提议者需要具有相对较高的在线时间，因为他们需要不断监控和半最终确定聊天链，并在创建合格议程时提出包含合格议程的区块。为了可预测地将此负担放在少数几个验证者身上，而不是所有验证者身上，Simperby 使用基于领导者和稳定的领导者方法。
-
基于领导者：与无领导者不同，并非每个人都可以提议区块，并且谁将提议区块以及何时提议区块是确定性的，就像循环赛一样。这种方法的优点是它是一种高效的方法，可以降低通信成本，但缺点是，如果发生 DOS 攻击或区块提议者是恶意的，则性能可能会显着下降。
-
稳定的领导者：除非明确替换区块提议者，否则现有的区块提议者将继续领导。这种方法使少数几个成员承担更多的责任和权力，这反映了并非所有成员都可能适合在现实世界中成为区块提议者的情况。稳定的领导者方法还使每个验证者更容易根据稳定的领导者列表预测他们何时将担任区块提议者的角色。
3.1.3 不良反应
由于 Simperby 使用基于领导者和稳定的领导者方法，因此它需要一种机制来替换当前的区块提议者（当他/她没有诚信地履行其职责和权力时）。 实际上，在普通的 Tendermint 中，你只需等待 round 结束即可，但是在 Simperby 中，round 时间非常长，因此等待 round 结束太不可用了。
在许多情况下，由于区块提议者的恶意行为，也无法进行可编程的削减。例如，故意不在区块中包含某些合格议程，或者不创建区块作为合格议程的一部分，都是无法在线路代码中识别的恶意行为。
为了解决这个问题，Simperby 团队提出了 Vetomint，这是一种独特的共识机制，它是 Tendermint 的变体。Vetomint 的本质是，如果 Simperby 链中的验证者在共识过程中没有诚信地行事，则他们可以投票否决或替换当前的区块提议者。
3.2 Vetomint
如前所述，Vetomint 是现有 Tendermint 针对 Simperby 的专用环境的改编。Vetomint 和 Tendermint 之间的主要区别如下。
3.2.1 空预投票可以在 round 结束前行使。
在 Tendermint 中，如果区块提议者未能及时提出区块，则验证者会投出空预投票。相比之下，Vetomint 允许验证者在 round 的超时时间到期之前投出空预投票。 如果验证者认为当前的领导者行为不当，则可以投出空预投票，而不管区块提议者是否实际提出了区块。与 Tendermint 一样，如果空预投票的数量超过总验证者集合的 2/3，则 Vetomint 将进入到下一个 round，并由新的领导者领导。
3.2.2 提前终止
在 Tendermint 中，如果非空预投票的数量超过总验证者集合的 2/3，则项目将进入预提交阶段。**相比之下，如果预投票超过总验证者集合的 5/6，则 Vetomint 将根据这些表进入预提交阶段，而不管验证者是空还是非空。
这种设计的原因是，在 Simperby 中，每个 round 的超时时间都很长，并且验证者可以主观地投出空预投票。例如，如果所有验证者中有一半投出了非空预投票，而其余验证者投出了空预投票，那么如果我们按原样使用 Tendermint，我们将无法进入预提交阶段，并且必须等待很长的超时时间，因为我们没有超过 2/3 的非空预投票。因此，在 Vetomint 中，如果验证者具有超过 5/6 的总预投票，我们将检查以查看此时的非空预投票是否超过总预投票的 2/3，并且仅在此之后传播非空预提交。
Tendermint 没有与 Vetomint 相同的问题，因为 round 的超时时间很短，并且诚实（非拜占庭）节点在它们是非空预投票还是空预投票方面不能有所不同。
3.2.3 那么为什么要 5/6？
我们将 5/6 称为触发提前终止的阈值，或提前终止阈值。为什么我们将提前终止阈值设置为 5/6？
让我们从为什么不是 2/3 开始。如果提前终止阈值是 2/3，那么在正常情况下，即使一个拜占庭节点故意投出非空预投票，收到它的验证者也无法进入下一步。
如果提前终止阈值是 x，并且拜占庭阈值大于 1-x，那么即使拜占庭节点不进行预投票，它们也可以阻止进展到下一阶段。因此，拜占庭阈值必须小于或等于“1-x”。我们的目标是在有超过 2/3 的非空预投票时进入预提交阶段，而不受拜占庭节点行为的影响。 因此，x 必须满足以下等式。
x - (1-x) ≥ 2/3, x ≥ 5/6
在 x 预投票中，来自拜占庭节点的投票必须小于 1-x，并且来自诚实节点的投票必须至少占总数的 2/3。因此，x 的最小可能值为 5/6。这意味着，就像 Tendermint 一样，当拜占庭节点少于 1/3 时，保证 Vetomint 是安全的，而当拜占庭节点少于 1/6 时，保证 Vetomint 是活跃的。
4. 多链
Simperby 的独立（Standalone）、自治（Sovereign）和自托管（Self-hosted）功能使其成为对于希望扩展到多个链的 OO 来说非常有吸引力的治理工具。
将来，预计大多数 OO 都是多链 OO。一方面，从风险多样化的角度来看，将资金保存在多个链上的国库中比锁定在单个链中要安全得多。对于管理 dApp 的 OO，为了在将其 dApp 扩展到新链时一次性将治理决策应用于多个链，它们不可避免地将拥有一个多链 OO。最突出的例子是 Uniswap V3。Uniswap 向 BNB 链的新扩展要求他们选择一个第三方桥来将治理决策从 Ethereum 链上的 Uniswap DAO 转移到 BNB 链，并且经过漫长的过程，Wormhole 被选中。
Simperby 是一个轻量级客户端，它允许以一种最小信任的方式将消息传递到结算链。Simperby 在结算链中的轻客户端仅在 Simperby 链中实际最终确定新标头时才更新，这通过确保标头具有超过总验证者集合的 2/3 的预提交来验证。此标头中的 merkle 根，以及从完整节点收到的 merkle 证明，允许轻客户端验证特定交易是否实际包含在区块中。
例如，假设一个区块包含来自某个 OO 的 Simperby 链的议程，以从该 OO 的以太坊链上的国库中提取 3 ETH。 在这种情况下，以智能合约形式存在于 Ethereum 链上的轻客户端可以验证 Simperby 链上的验证者的签名，并以一种最小信任的方式执行所需的交易。
来源: Simperby Deck
由于 Simperby 链仅做出与治理相关的决策，并且 OO 的成员仅需要验证结算链指示的内容是否已发生，因此链之间的连接是单向的，从 Simperby 链到结算链。因此，使用 Simperby 的 OO 可以非常自由地随时加入和离开特定链。
5. 基于 Git 的数据存储
虽然 Simperby 是用于治理的区块链，但它也可以像 Google Drive 一样充当分布式文件存储。Simperby 中的所有最终确定数据（议程、聊天、区块）都存储在 Git 存储库的“最终确定”分支中。Simperby 链中的每个节点都维护自己的 git 存储库，并且可以通过 git fetch 读取、验证或同步来自其他节点的数据。
Simperby 和 Git 具有有趣的对应关系。例如，议程与“git commit”相关联，区块提议与“git branch”相关联，区块确认与“git rebase”相关联，等等。这个事实使 Simperby 不仅仅是一个治理工具，它还是 OO 的分布式文件存储库，并且它可以与 Git 生态系统中的现有第三方工具很好地协同工作。
6. 结论
如你所见，Simperby 绝对不同于其他 OO 框架。它为治理创建一个链的事实以及其自己的共识机制供 OO 成员运行他们自己的节点非常酷，但是Simperby 不仅可以用于治理，而且还可以通过 Git 用作分布式数据存储的事实非常有趣。开发 Simperby 的开源基金会 PDAO 已经在 SImperby 上运行，并且将来会有许多大型和小型组织使用它来制定决策。
对于那些习惯于传统链上治理的人来说，Simperby 最初可能有点生疏，但对于现实世界的组织和区块链新手来说，我认为 Simperby 可能是最有吸引力的 OO 框架，因为他们不必担心 gas 成本，也不必知道如何使用像 Ethereum 这样的现有区块链。
7. 参考
感谢 @Kate_ 为本文设计图形。
- 原文链接： 4pillars.io/en/articles/...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
