EOS治理：接近不可变的dApp架构

尽管主网上线的时间有限，但迄今为止EOSIO技术和EOS网络已取得了巨大成功。我们在吞吐量，每日活跃用户和增长率方面超过了许多竞争对手。自主网上线以来，我们一直在进行迅速的改进和迭代。这一点是值得庆祝的。

EOS New York的以下提议旨在抛砖引玉。我们应该调整我们在EOS治理上的关注点。只要聚焦在价值创造者（即dApp开发者）身上，eosio有很大机会取代现有区块链系统。为此，我们认为社区应该将开发人员（价值创造者）置为EOS社区话题的中心。

定位

良好的EOS治理意味着一个高效的决策框架，可以减少各方之间的信任需求并且加快增长。（译者按：即dApp的各方通过EOS建立信任，而不需要各方之间的信任。）

以下内容来自EOS电报社区成员（译者按：一位开发人员从自己的视角发出的感慨）

......我们正在讨论[dApp]关于放弃或者推迟我们的EOS路线图的问题。 我们从第1天开始就是非常专业“EOS”，但是作为EOS的dapp开发人员感到很孤独 。说实话，我们所谈论的只是BP，公约，RAM等等，尽管我们在用自己最大的努力为EOS生态做贡献，但是我们依然感觉很孤独。

到目前为止围绕治理的讨论漏掉了开发人员

让我们来转换一下视角

现状

以太坊智能合约默认是不可变的。尽管如此，开发人员还是竭尽全力找到可以改变合约状态的方法。这个原因应该是显而易见的，软件开发不是一件静态的事情，它是持续的。相比之下，EOSIO满足了一定程度的可变性需求，这是可以的。EOSIO软件每周都在更新，因此开发人员必须保持开发状态。但是这种可变状态，特别是对于敏感的智能合约（比如管理dApp代币的合约），不能无限期地保持可变。可变性和不可变性应该在开发周期中过渡。在整个周期中，开发人员应该通过实现完全不变性或渐近接近完全不可变性来增加安全性，同时减少信任需求。

一个解决办法

我们实现这一目标的方法是利用EOS上极其强大的权限系统。以下是Block.One在其开发人员门户网站中编写的“权限”的说明。

以下示例是名为@multisig的虚构帐户的权限。在这种情况下，两个用户被授权为虚构的@multisig帐户的owner权限和active权限，三个用户具有不同权重的自定义发布权限。

在这种情况下，需要权重阈值2来更改owner权限级别。因为各方都只具有权重1，这意味着所有用户都需要签署该交易才能获得完全授权。

为了发送需要active权限的交易，将阈值设置为1.这意味着只需要1个签名即可授权来自active操作权限的操作。

还有一个名为publish的自定义命名权限。本例子中，发布权限用于使用博客dApp将帖子发布到@ multisig的博客。发布权限的阈值为2，@ bob和@stacy的权重均为2，公钥的权重为1.这意味着@bob和@stacy都可以在没有其他签名的情况下发布，而公众密钥需要额外签名才能授权publish权限的操作。

因此，上述权限表意味着作为帐户所有者的@bob和@stacy具有类似于主持人或编辑者的提升权限。虽然这个原始示例在可扩展性方面具有局限性，并且不一定是一个好的设计，但它确实充分展示了EOSIO权限系统的灵活性。

另外，请注意上表中的权限是使用帐户名和密钥设置的。乍一看，这似乎微不足道，但它确实提出了一些额外的灵活性。

观察

@bob和@stacy可以明确标识为此帐户的所有，如果没有来自@bob或@stacy 的附加签名，公钥就无法在publish权限下执行操作，并且@stacy可以在publish权限下执行操作而无需任何其他操作签名。

通过适当地利用该权限系统，开发人员可以共享权限以与一方或多方更新他或她的智能合约代码，消除中心故障点并减少用户信任单个开发人员或开发团队的需要。

EOS42和Chintai 租赁平台的首席开发人员Michael Fletcher 评论了Chintai的权限结构，要求11个节点中的6个签署multi-sig交易才能对代码进行更新。

假设，如果chintai被黑客入侵,除了chintai外没有代码能够将资金转出chintai。 因此，黑客需要上传恶意合约，这个恶意合约需要6/10的BP来确认。

如果黑客能够奇迹般地破解密码，黑客想要控制的97.5％的EOS代币是处于抵押状态，所以他们需要赎这些EOS，这个赎回动作将在30分钟内马上被标记。

再进一步，如果没有人注意到所有的EOS都已经赎回了。 它仍然被提前约定的交易所抵押而延期交易。

节点<>dApp开发者

节点们可以在15/21或者⅔+ 1个节点同意时更新EOS区块链的各个部分，每个区块生产者签署一个交易以访问该eosio.prods帐户的活动权限。15/21签署后，eosio.prods可以授权普通帐户无法执行的操作。在该eosio.prods帐户中，存在三个对此提案至关重要的重要权限。

active

prods.major

prods.minor

eosio.prods的每个权限：active，prods.major和prods.minor，分别需要15,11和8个节点同意后才能被访问。这也可以被视为⅔+ 1，½+ 1和⅓+ 1个节点。

我们所拥有的是一个非常优雅的阶梯式系统。利用它时，可以用来分散权限以更新dApp的敏感智能合约，节点是EOS生态系统中可信赖和负责任的实体。基本上，通过EOSIO的可用功能，我们可以创建一种治理结构，减少对信任的需求，并提高基于EOS构建的dApp的安全性。这种分布式权限的关系不仅限于eosio.prods权限，还可以在任何开发人员和第三方之间。这是EOS的差异化具有竞争力的功能。

这会是什么样子？

如今，许多行业都有许多认证标准。例如，SSL证书可以证明您的身份，SOC和PCI合规性都可以证明您的流程的安全性，ISO认证跨行业的质量标准。根据所执行认证的严格程度，其中大部分将分为多个层级。虽然EOS为其开发人员提供了无限的灵活性，但是普通用户和dApp交互时，无法判断dApp的安全性和其开发人员的身份。

就像其他不同级别和类型的认证一样，EOS可能有一种标准认证，至少表明dApp的不可篡改程度。根据为了更改智能合约代码而必须满足的难度阈值，可以发出不同的徽章标示。它可以通过钱包或dApp浏览器显示，也可以直接在dApp本身的UI上显示。

前面的任务

在2018年12月10日的一周内，一个安全漏洞被披露出来，所有节点都在EOS主网上开发，发布和部署了补丁。显然这个补丁是必要的，但却给许多dApp开发人员及其智能合约带来了问题。如果这些dApp向节点共享了更新代码的权限会怎样？我们面临一系列挑战。

dApp如何得到通知，以及dApp如何通知节点？

dApp如何将更新信息提交给节点以供节点验证？

是否涉及费用？

是否有交流沟通或其他过程的门户？

节点和共享权限的dApp之间是否存在服务级别协议？

这些是重要的问题，其答案决定了最开始EOS治理的基础应该是什么样子。

总结

节点和dApp开发人员之间的服务级别关系对EOS 主网的基础治理框架至关重要。敏感智能合约的不可变架构可以提高安全性和减少各方之间的信任需求，有助于创建一个增长框架。dApp开发人员应该考虑如何处理敏感智能合约的不变性，特别是那些管理其代币的合约。这样他们就可以将自己与不太安全的竞争对手区分开来。节点应该开始设计一个流程，通过这个流程，他们可以用这种方法充分支持开发人员。构建此框架是整个EOS社区的责任。开发这个流程以及如何向前发展的参与规则是至关重要的。EOS纽约并没有明确规定这个过程应该如何形成。然而，我们呼吁社区认识到这一举措的重要性，将把我们的精力集中在重要的事情上。让我们将开发人员放回到关注的中心。我们如何解决这个问题将直接影响EOS主网和EOSIO的增长和治理。