> 该仓库仍然以存档形式存在，但维护版本现已迁移至：https://github.com/Mythic-Project/solana-program-library/tree/master/governance

此仓库仍然以存档形式存在，但维护的版本现在已迁移到：https://github.com/Mythic-Project/solana-program-library/tree/master/governance

SPL Governance

SPL Governance 是一个程序，其主要目的是提供核心构建块和原语，以便在 Solana 区块链上创建 去中心化自治组织 (DAOs)。

该程序与 DAO 类型和资产类型无关，可用于构建任何类型的 DAO， 这些 DAO 可以拥有和管理任何类型的资产。

例如，它可以作为 mint、token 帐户和其他形式的访问控制的权限提供者， 我们可能希望投票人群集体投票决定资金的支付。 它还可以通过民主方式控制自身和其他程序的升级。

在最简单的形式中，该程序可以用作对共享钱包（treasury account）的多重签名控制，或者作为 Solana 程序的多重签名升级权限

架构

该程序是模块化的，并使用开放/封闭架构，其中程序的各个部分的 行为可以通过外部插件进行自定义。

例如，该程序的默认实现接受 governance tokens 的存款以换取 投票权，但可以将其与自定义程序实现交换，该实现可以实现任何自定义要求， 如 token 锁定、token escrow、NFT 投票或多 token governance 结构。

这些插件是普通的 Solana 程序，可以使用任何支持技术编写，例如 Anchor 框架。

部署

该程序支持两种部署模型：1) DAO 拥有的实例和 2) 共享实例

1) DAO 拥有的实例

当 DAO 需要完全控制 governance 程序时，建议部署和使用其自己的实例， 并将其置于 DAO governance 之下。 这样，只有 DAO 才能更改和升级它使用的最重要的程序。

注意：使用你自己的实例与 fork 源代码不同。它仅表示部署程序的代码 并将程序的升级权限转移到 DAO。

2) 共享实例

在部署拥有的实例不切实际的情况下，可以使用该程序的共享实例。 有两种实例可供任何人在主网上使用

GovER5Lthms3bLBqWub97yVrMmEogzX7xNjdXpPPCVZw - 默认 spl-governance 实例

GTesTBiEWE32WHXXE2S4XbZvA5CrEc4xs6ZgRe895dP - 可用于设置测试 DAO 的测试实例

Governance UI

有两个 UI 可用，展示了程序的功能：

• Realms Explorer 项目（Oyster monorepo 的一部分）提供基本的和数据 导向的 UI 来创建和管理 DAO：realms-explorer

  对于开发人员来说，这是一个学习该程序并与之交互的良好起点

• Governance UI 项目与 MNGO 团队一起构建：governance-ui

  这是一个高级的、用户友好的和任务导向的 UI，被 Solana 上大多数现有 DAO 使用

Client SDK

@solana/spl-governance

文档和帮助

程序和 UI 文档：spl-governance-docs

Discord 服务器：spl-governance-discord

程序帐户

下图显示了用于通过提案控制多个程序升级时程序帐户的说明性配置

Realm 帐户

Realm 帐户将 Community Token Mint 和可选的 Council Token mint 绑定在一起，为与 token 持有者社区相关的任何 governance 创建一个 realm。 例如，一个交易协议可以发行一个 governance token，并使用它来创建其 governance realm。

一旦创建了一个 realm，投票者可以将 Governing tokens（Community 或 Council）存入 realm，并 使用存款金额作为其投票权重来对该 realm 内的提案进行投票。

Program Governance 帐户

更新程序 governance 的基本构建块是 ProgramGovernance 帐户。 它将受管 Program ID 绑定在一起，并保存定义 governance 规则的配置选项。 受管 Program ID 用作程序派生地址的 seed， 并且此程序派生地址用作你的 Program ID 的 Governance 帐户的地址。

这意味着对于给定的程序，只能有一个 Governance 帐户。 governance 程序在 Governance 帐户的创建时验证，采用 governance 的程序的当前升级权限 是否已签署交易。可选地，CreateProgramGovernance 指令还可以在 Governance 帐户创建时将受管程序的 upgrade_authority 转移到 Governance PDA。

Mint Governance 帐户

mint governance 帐户允许 mint 权限设置对 SPL Mint 帐户的 governance。 governance 程序在创建时验证当前 mint 权限是否已签署交易以 创建 governance，并且可以选择将权限转移到 Governance 帐户。 设置完成后，Mint Governance 允许 governance 参与者创建提案，这些提案执行针对 受管 Mint 的 mint 指令。

Token Governance 帐户

token governance 帐户允许 token 帐户所有者设置对 SPL Token 帐户的 governance。 governance 程序在创建时验证当前所有者是否已签署交易以 创建 governance，并且可以选择将所有者转移到 Governance 帐户。 设置完成后，Token Governance 允许参与者创建提案以执行来自 受管 token 帐户的转账指令。

权限如何运作？

Governance 可以处理任意代码的执行。在程序 governance 的情况下，它可以执行程序升级。 它通过执行 bpf-upgradable-loader 程序的指令来实现这一点。 Bpf-upgradable-loader 允许任何拥有 Buffer 帐户和 Program 帐户本身的升级权限的签名者 使用其升级命令来升级它。 通常，这是创建和部署该程序的开发人员，并且包含 新程序数据的 Buffer 帐户的创建以及使用 Solana 程序部署 cli 命令在后台为你处理的使用新程序数据覆盖现有 Program 帐户数据的操作。 但是，为了使 Governance 有用，Governance 现在需要此权限。

以类似的方式，对于 Mint 和 Token governances，mint 和转移 tokens 的相关权限 将转移到 Governance 帐户。反过来，它允许参与者创建和投票赞成提案， 然后可以执行 受管帐户的 mint 和转账指令。

Proposal 帐户

提案（Proposal）是为投票和执行给定的指令集而创建的 Governance 实例。 它由某人（提案所有者）创建，并与给定的 Governance 帐户 绑定，并且具有一组可执行的指令、一个名称和一个描述。 它经历了各种状态（草稿、投票、执行、...），如果用户拥有相关的 Community 或 Council tokens，他们可以在其上投票。 它的规则由与其绑定的 Governance 帐户确定，并且当它执行时， 它仅有资格使用 Governance 帐户赋予的程序派生地址权限。 因此，例如，Sushi 的提案不能升级 Uniswap 的程序。

当用户创建提案时，该用户将成为提案所有者并获得编辑提案的权限。 有了这种权力，所有者可以编辑提案，向提案添加/删除签署人，并且可以取消提案。 然后，这些签署人可以通过签署提案来表示他们对提案的批准。 一旦所有签署人都签署了提案，该提案将离开草稿状态并进入投票状态。 投票状态的持续时间与 Governance 配置的持续时间相同，在此期间， 持有 Community（或 Council）tokens 的人可以对提案进行投票。 一旦提案被“倾斜”，它将进入失败或成功状态。如果在投票期间无法自动倾斜投票，但仍然达到所需的赞成票阈值，则可以使用 FinalizeVote 指令手动将其转换为成功状态。 一旦所有提案交易都已执行，提案将进入已完成状态。

在执行状态下，在 hold_up_time 期间已经过去后，任何人都可以随时运行指令。

ProposalTransaction

一个提案可以有多个提案交易，每个交易都有多个指令，并且它们彼此独立运行。 这些包含指令的实际数据，以及用户必须等待多长时间才能执行它们。

投票动态

当一个提案被创建并由其签署人签署时，投票者可以使用其投票权重开始对其进行投票， 该权重等于存入到 realm 中的 governing tokens 。一旦投票通过了定义的 vote_threshold 票数， 投票就会被倾斜，并进入成功或失败状态。如果成功，则在 hold_up_time 过去后可以执行提案指令。

用户可以在提案生命周期的任何时间放弃他们的投票，但是一旦提案被决定，他们的投票就无法更改。

Community 和 Councils governing tokens

创建的每个 Governance Realm 都可以选择拥有一个 Council mint。 Council mint 只是一个与 Community mint 分开的 mint。 这意味着用户可以提交与不同的 mint 中的不同投票人群 影响相同 DAO 的提案。此策略的实际应用可能是通过正常的 SOL(例如)来控制 Solana 的主要版本更新的非常庞大的人群， 但是通过 Council tokens 控制热修复，其中可能只有 30 个，并且它们本身可以通过管理人群的提案来 mint 和分发。

另一个重要的用例是将 Council 用于 DAO 的启动。在 DAO 生命的开始， 存在很多风险和未知数。 例如，尚不知道 token 持有者社区是否会参与 DAO 投票。 如果他们参与，那么参与的程度如何。这意味着例如很难确定 提案需要多少票才能成功投票。 这就是为什么为了避免陷阱和潜在的不可逆转的行为，可以将 Council 用作安全网， 以类似于 Multisig 的方式来适度和监督 DAO 启动时的投票过程。 一旦新生的 DAO 通过了几次成功的提案投票并且一切顺利， 就可以通过社区投票从 DAO 中删除 council。

Council 还可以用于尚未启动其 token 的协议和社区。 在这种情况下，可以使用尚未启动的 token 和 Council 设置 DAO， Council 将管理 DAO 直到 token 被分发。

提案工作流程

审计

存储库 README 包含有关程序审计的信息。

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