了解 Namada 治理

Namada的治理建立在灵活性哲学的基础上。在这篇文章中，我们探讨Namada提供的特点，并阐明了这一哲学。我们探讨了PGF管家、PGF提案、ETH桥提案等内容。

Namada 的治理是基于可塑性的理念而建立的。在本文中，我们探讨了 Namada 提供的功能，并激励他们遵循这一理念。我们探索 PGF 管理员、PGF 提案、ETH 桥接提案等

我们（应该）生活在一个社会中（受到 https://www.eff.org/cyberspace-independence 的启发）

动机

"政府的正当权力来源于被统治者的同意" - 出处

Brian Goetz曾经说过"不可变对象是简单的"。然而，治理并不简单，根据逻辑的演绎规则，治理因此不能是不可变的。由于Namada存在为了持续多年，并培养未来的用户代际，因此它需要随着构成它的人的变化而改变是合理的。

出于这个原因，Namada采用了一种灵活的治理形式，使治理参与者几乎可以完全灵活地改变。本文试图解释Namada治理所提供的功能。

Namada的治理建立在这样的原则上，即它应该足够灵活，以支持协议的变更，而无需进行硬分叉，同时也应该有足够的手段，以充当参与者可以表达对拟议的硬分叉的赞成或反对的地方。

最终，社会治理 - 即人们选择运行哪种软件 - 既是最后也是最重要的协调层。因此，Namada支持离链信号投票，以便让用户能够在链上发布这些决策历史。

大纲

本文旨在概述Namada治理的特点，这些特点赋予了它这种灵活性。

我们首先描述了构成治理的成员。然后，我们描述了治理参与者的投票机制，最后描述了治理可以投票的提案类型。

谁是治理？

我们都有责任

Namada的治理分为两个不同的参与者：

1. Delegators - 那些质押代币但将其投票权授权给其他地址的人。

2. Delegates - 代表代币持有者对治理提案进行投票的人。

治理参与是通过分配质押的本地NAM代币来决定的。质押的NAM代币会根据他们所质押的NAM数量来给予治理参与者相应的投票权。

当非验证器地址质押代币时，他们会将代币质押给一个验证器地址。然后，这个验证器将负责代表该用户投票。

默认情况下，用户将代币质押给的验证器成为该用户的代表。这意味着验证器也能够代表用户投票支持治理提案（现在用户成为了一个委托者）。

然而，委托者的投票权始终优先于代表的投票权。

例如，假设委托者Bob（投票权=1）已将投票权委托给代表Alice（包括Bob的委托，投票权=3）。

然后，如果Alice对提案A投赞成票，然后Bob随后对提案A投反对票，那么投赞成票的总数仅为2。该提案现在还有1票反对。

投票延迟

为了确保委托者始终有权覆盖代表的投票，代表被要求在提案的投票期限内的前32个时代内投票。

如果不设置这个限制，恶意代表会受到激励在提案的最后一刻投票（或更改他们的投票），违背委托者的利益。

共识还是治理？

Voting-power有两个用例。

对于权益证明共识，voting-power影响被选为区块提议者的可能性，以及在签署有效区块时验证者签名相对于其他验证者签名的权重。当非验证账户将 NAM 代币绑定到验证者时，验证者的投票权将与绑定金额成比例增加。

当委托人将绑定的 NAM 代币“委托”给受托人时，受托人的投票权将根据委托金额按比例增加。

提交提案

“提案”旨在定义治理参与者投票的对象，并“提出”对社会共识的特定改变。社会共识的改变通常是对 Namada 协议某些部分的状态改变。

示例包括更改各种协议参数，例如代币供应通胀率、PoS 奖励率、各种资产的白名单等。所有这些更改都很容易被分类帐解释，并且可以与更改这些参数的“有效负载”一起提出保存并一旦更改立即生效。

其他示例可能包括修复代码库中的基本错误、添加一些需要更改架构的功能或升级 Namada 堆栈的某些部分。这可能需要硬分叉并安装新“版本”的 Namada。

对于我们公共测试网的所有参与者，应该充分练习这一点；）。

对提案进行投票

一旦提案发布，所有治理参与者都可以通过提交Yay或Nay通过投票交易对提案进行投票。

提案示例：PGF 管理员选举

Namada的PGF监护人提案是一个很好的例子，可以更好地理解Namada治理提案。Namada的PGF监护人提案提出将PGF监护人添加或移除出Namada的监护人集合。

任何用户都可以提交提案，前提是他们有足够的资金来做到这一点。提交治理提案所需的资金是一个治理参数（相当元，我们知道）。这些资金将被托管，直到提案解决为止。

一旦提出提案，治理参与者（即具有一些绑定权益的验证者或委托者）可以对提案进行投票。

要批准提案，必须提交Yay投票，而Nay表示不同意提案。

如果至少三分之二的总投票权已经对这个提案投票，并且超过50%的选民赞成提案（即已经投票Yay），那么提案就会“通过”，并且将进行监护人更改。

有两种情况：

1. 提案被拒绝

2. 提案被接受

如果提案被拒绝，托管的资金将被“削减”。如果提案被接受，那么资金将退还给提议人，并且状态更改将在宽限时代结束时实施（在这种情况下，新的监护人将被选举或移除）。

提案的经济学

为什么提案需要成本？

出于与我们支付gas费相同的原因，我们为提案支付额外费用。除了争夺有限的区块空间之外，该提案还在争夺有限的“注意力空间”。这种关注是必须付出的，从这个意义上说，它是为治理的关注而支付的费用。如果提案被接受，并且治理从构建提案所付出的努力中受益，治理就会为提案者的努力提供回报。

关于 Namada 的不同提案

Namada 有 3 种（半）类型的治理提案。

Default Proposal

默认是 Namada 上最通用的治理提案类型。默认提案有两种形式：

1. 带有 wasm 有效负载

2. 没有 wasm 有效负载

存在没有 wasm 有效负载的默认提案，以便围绕特定共识进行协调。这可能是硬分叉的形式，但也可能只是各种其他形式的社会共识，例如各种概念的重命名、建议关注 Namada 赠款/错误赏金、搭建桥梁的协议等。

具有wasm 有效负载的默认提案在获得批准后，将执行 wasm 代码以实现链上状态更改。这是为了改变治理参数而设计的。例如，屏蔽池中的激励资产集合和/或补贴规模是可以通过此类治理提案进行更改的参数。

任何 Namada 用户都可以提出默认提案，并且必须托管 NAM 才能这样做。任何治理参与者都可以对该提案进行投票。

要想通过，至少2332​Namada 投票权的成员必须对该提案进行投票，并且这些选票中的多数必须赞成该提案。

定制提案

Namada 上的非默认治理提案称为“自定义提案”。

截至撰写本文时，自定义提案分为三种类型：

1. ETH Proposal

2. PGF Proposal

3. Steward Proposal

ETH Proposal

自从这些坏男孩在 ETH 丹佛揭露以来，这可能是第二酷的 ETH 相关现象

该治理提案是治理提案的一种特殊形式，因为它涉及对管理 ETH-Namada 桥的以太坊智能合约上的函数执行调用的代码。

用我们的 ETH-bridge 工程师 Fraccaman 的话说，转发 ETHBridge 提案的有效负载“非常酷”。一旦提案通过，验证者必须中继对提案中指定的字节进行签名的协议事务。在技​​术层面上，这些字节代表对以太坊智能合约函数的 ABI 编码函数调用。一旦收集到足够的签名，任何用户都可以提交签名集合并调用提案指定的智能合约函数。智能合约包含确保签名有效且充分的逻辑。一旦满足这些条件，智能合约功能就会被执行。

任何 Namada 用户都可以提出 ETH 提案，并且必须托管 NAM 才能这样做。但是，只有验证者才能对这些提案进行投票。

要想通过，至少2332​Namada 投票权的成员必须对该提案进行投票，并且这些选票中的多数必须赞成该提案。

PGF Proposal

PGF 提案是只能由当前当选的 PGF 管理员提出的治理提案。这些提案是一种特殊类型的提案，可以进行追溯公共物品付款（RPGF）或连续公共物品付款（CPGF）。

PGF-Proposal提案默认通过，除非被治理参与者否决。

当且仅当以下情况时，治理参与者才能够否决此类提案：

至少1331​对该提案的总投票权投票，并且大多数票数为Nay。进一步地，如果至少2332​的总投票权已Nay对该提案进行了投票（这意味着严重反对），则 PGF 管理员将从 PGF 管理员集合中删除。

Steward Proposal

其Steward Proposal存在是为了投票选出（或投票淘汰）新的（或旧的）公共物品资金管理者。

这些提案可以由任何用户提出并由治理参与者投票。该提案指定了将被投票加入/投票退出的管理员的地址。该提案的描述旨在包括管理者应被投票加入/投票退出的动机。

PGF 管家当选当且仅当：
至少1331​Namada 投票权的成员必须对该提案进行投票，并且这些选票中的多数必须赞成该提案。

线下提案机制

图片相关

当 Namada 链按预期正常运行时，一切都很棒。当链条停止或遇到其他问题时，我们如何达成共识？

与其他治理模型相比，Namada 的治理功能包括一些新颖的变化。

除了对治理提案引入“关注费”外，Namada 还允许离线和在线提交提案。离线治理提案的存在是为了向 Namada 的治理参与者提供更大的灵活性。

当需要硬分叉来解决某些问题时，此工具特别有用。我想到的例子是链停止，它可能是由于拜占庭攻击或由于错误或类似原因而出现的。

在这种情况下，有一种机制可以将投票提交给某个焦点，例如已经商定的一些（最好是去中心化的）通信服务。然后，用户和验证者可以以与链上相同的方式验证这些投票和签名。

提交离线提案

然后，离线提出的提案将作为表示结构的 JSON 哈希的签名提交到链上：

{
  content: Base64<Vec<u8>>,
  author: Address,
  votingStart: TimeStamp,
  votingEnd: TimeStamp,
  signature: Base64<Vec<u8>>
}

提交离线投票

同样，投票作为 json 结构哈希的签名提交：

{
  content: Base64<Vec<u8>>,
  author: Address,
  votingStart: TimeStamp,
  votingEnd: TimeStamp,
  signature: Base64<Vec<u8>>
}

结束语

Namada的治理系统非常灵活。它旨在通过链上提案容纳大多数更改，并能够使用wasm和ABI有效载荷来实现这一点。它还认识到需要硬分叉，并提供了协调机制来允许这种情况。治理的设置旨在尽可能地使用户拥有协议，因为他们是构成协议的一部分。