【Dapp治理】SNS治理容器的最新设计更新
文章来自于｜DFINITY社区对话活动
投稿、转载请联系｜DfinitySZ小助手
社区对话主题：SNS的开放治理容器
提出者：Lara schmid/DFINITY NNS 研究员
活动主持人：Liz yang/DFINITY成长团队
针对对象 ：为DAPP建立 DAO & Token 基础设施
官方介绍&讨论视频 ：
https://www.youtube.com/watch?v=Ku4p67W0JjU&t=1717s
论坛讨论：
https://forum.dfinity.org/t/open-governance-canister-for-sns-design-proposal/10224
社区对话回顾
在互联网计算机上一共拥有两种治理系统，第一种是用于IC网络治理的NNS系统如上图所述它一共由三组容器（Canisters）组成，每组容器承载不同的功能：Governance（治理）、 Ledger（账本）、 Registry（登记配置）。
而第二种是应用于IC Dapp的治理系统SNS，与NNS不同SNS只有两组容器组成，分别是Governance（治理）和Ledger（账本）容器。
SNS存在的意义
为端到端托管在链上的Dapp提供去中心化治理系统
Dapps是用户拥有的
Dapps由用户控制（提案链上执行）
在IC上所有应用都是端对端的提供Web交互内容， 这意味着IC上的整个应用包括前端、后端等都完全托管于链上，而SNS意义在于可以为IC Dapp在链上带来去中心化治理，所有的治理流程都在链上完成。
SNS的用例
获得投资
通过奖励早期参与来吸引更多用户
代币所有权作为网络效应的驱动力
SNS的两个关键特性是标记化和权利下放，综上所述，SNS治理系统拥有Ledger容器支持为Dapp提供Token化的功能，例如，Token化带来Dapp获得投资的资金支持通道、奖励早期用户来吸引更多的用户、赋予Tokne治理权的形式将Dapp治理分散化。
SNS的抗审查化
防止服务停止
开放式无任务治理，可根据社区需求进行dapp升级
在IC上所有Dapp由单个或多个智能合约容器组成，它们相互通信协作，而对于容器来说，它们拥有一个控制器列表，该控制器列表主要为开发者提供更新迭代Dapp的功能，如果该控制器被有心人利用可能会进一步造成损失，而SNS系统有效消除了此类风险，在Dapp将SNS系统配置成功后，所有对容器进行的升级都需要经过SNS治理系统投票受理，此外SNS还为社区提供了针对Dapp的发展需求的提案类型。
SNS系统的设计更新
在2021年10月份，DFINITY基金会推出了初版SNS设计后，经过了多次社区对活动和讨论，社区对初版SNS设计的反馈是：
初版设计较为复杂
不够灵活
仅需要其中一部分的用例
SNS初版设计：深入探讨SNS系统如何为Dapp带来去中心化治理
在得到这些社区反馈之后，DFINITY官方重新推出了新SNS设计，并提出以下新方法：
分多个阶段发布不同的构建块，以便社区可以在中间交付物（例如，单个SNS容器）准备好后立即使用它
发展这些单一的构建块以达到无需工程工作即可使用的具体实现
使具体实现模块化和单个组件可配置，以便每个SNS都可以配置为适合其管理的 dapp
更具体的来说，官方提出了以下初始阶段：
优化NNS Ledger容器，使其也兼容除ICP以外的Token；
实施部署SNS治理容器
由多个容器组成用于部署和升级SNS的工具，包括上述的SNS Ledger容器和SNS治理容器（设计将在未来几周内在单独的论坛主题中展示）
允许SNS 获得更多支持，包括前端支持、对初始Token分发的支持等（这取决于上述步骤实现和SNS新设计反馈）
注解：据官方解释SNS的前端支持类似于提供一个NNS Dapp里的投票页面选项卡前端，或者提供一个库，开发者可根据接口实现自定义投票前端。
SNS治理容器新设计
如上图所示，在SNS的新版本的治理容器设计中，仅仅重用了NNS治理容器中关于治理概念的一些代码，在未来为SNS治理容器将会提供一个新的库。
更具体的来说SNS仅重用NNS治理概念中的：
神经元/促进基于权益的投票
作为SNS的提案允许用户发起提议
与 NNS 治理一样，SNS治理容器与其关联的Ledger容器将一起部署，与某些配置只能通过容器升级更改的 NNS 相比，在SNS治理容器中，大多数配置可通过提案更改参数，这意味着允许每个开发人员或社区可根据需求调整治理规则。
SNS架构
如上图所示，SNS分为两大容器：
治理容器组成部分包括用于更新Dapp的提案（Proposals）和用于治理投票的神经元（Neurons）；
Ledger容器用于存储Account账户中的Token余额。
SNS提案
SNS的治理的治理流程：用户向SNS治理（Governance）容器发起一份更新Dapp的提案后，该提案交于治理（Governance）容器中的神经元（Neurons）进行投票，投票通过，提案受理，提案中的自动执行。
用户<>提案<>治理（Governance）容器<>神经元（Neurons）投票<>Dapp更新
SNS提案类型
在NNS治理中，每个提案既有一个类型，也决定了它们将做什么，不同类型的提案都附之一个主题，每个神经元可根据不同主题的提案跟随其他神经元委托投票（如果跟随的神经元参与投票，则该神经元会自动跟随投票）。如下图所示该提案的类型为Motion，而主题为Governance（治理）。
不同类型的提案会在容器中定义成一个方法，如果该提案受理，则容器会自动调用该方法。
这里有一个理解盲区要解释一下，在NNS中一个主题内的提案可能会包含多种提案类型，但是跟随投票只能根据主题跟随，而不能根据提案类型跟随。
Motoin：Motion是一种指导Internet Computer生态系统会发展的战略提案类型
而在未来，SNS将会服务各类Dapp，这使得目前无法预测出应用在未来需要哪些提案主题。官方的建议是在SNS系统中省略提案主题，直接根据提案类型提供委托投票（跟随神经元）的功能，并推出以下三种常用的提案类型，其他特定类型在未来可根据需求添加。
Motion提案类型：探讨社区意见，不立即生效
升级一个容器的提案类型：用于升级Dapp容器
更改SNS参数的提案类型：根据社区需求更改SNS配置
SNS提案生命周期
在了解SNS的提案生命周期之前，我们先了解一下NNS的提案的生命周期，如图1所示，紫神经元向NNS治理容器创建了一份定义为upgrade_dapp方法参数的提案，提案的初始生命周期为4天。
图1
如图2所示，总投票权为500，当>2分之一的投票权投Yes票时，无论投票时间剩余多久，该提案都会被受理。
图2
如图3所示，在总投票权为500的情况下，有250投票权投了No票，无论时间剩下多少，该提案都会被拒绝。
图3
如图4所示，如果提案的投票时间到期，总投票权在500的情况下，投Yes票大于反对票时，并Yes投票权占总投票权的3%时，则该提案被受理。
图4
如图5所示，投票时间在默认4天的周期基础上增加了1天23个小时，这是因为一种特殊的算法导致（quiet algorithm），每当投票趋势发生变化时，它会增加提案的投票周期。
投票趋势指的是如果在投票之前，结果是肯定的，但后来又投了一票，这使得结果变成了否定的结果。
当提案的投票发生了一个趋势性的变化时，提案的投票周期会自动增加，但只允许在一定程度上增加投票时间，即有一个最大的投票上限时间，目前在NNS中的上限是8天。
图5
官方对SNS提案的生命周期设计的建议是使SNS与NNS保持相同，但官方认为SNS还面临两个主要的明显问题 ，即为SNS有哪些东西是可进行配置的，第一个是投票权，在NNS中的投票权由三个取决于三个因素：function of stake（质押Token数量）、age（年龄）、and dissolve delay（溶解延迟函数）。
这里要给大家详细解释一下在NNS中的投票权是如何计算的：
NNS投票权=neuron_stake * dissolve_delay_bonus * age_bonus
NNS投票权=神经元质押ICP数量*溶解延迟奖金值*年龄奖金值
溶解延迟奖金值是一个介于1到2之间的值，而这个值的多少取决于神经元溶解延迟的时间，在溶解延迟时间达到8年时，溶解延迟奖金值可达到2的值。
年龄奖金值是一个介于1到1.25的值，而这个值的多少取决于神经元老化的时间，这个老化可以理解为神经元不开启溶解且锁定状态的时间，在老化时间为四年时，年龄奖金值可达到1.25的值。
对于SNS投票权方面，官方给出的建议是为影响投票权的三个因素增加灵活性，即为每个SNS可以决定赋予这三个因素什么权重，并根据每个SNS选择的函数计算投票权。
SNS神经元属性
在SNS中的神经元属性方面官方提出的建议是与NNS神经元保持相同，但删除一些NNS神经元中的特定属性。
在NNS中，每一个神经元都有一个状态，并指向一个Ledger Account ID标记存储。另外，神经元还有一个唯一标识的神经元id，官方的建议是在SNS神经元中仅重用Ledger Account作为标识符id。
此外，在NNS中有一个controller /Principal ID（控制器）和Hotkey/Principal ID列表的概念，而在SNS新设计中官方提出了更灵活的方法，通过提供一个访问控制列表，指定哪些Principal可以执行哪些神经元的操作权限。
对于SNS第一版本，将从两个密钥的简单逻辑开始，这类似于 NNS 治理容器中controller（控制器）和Hotkeys的概念。在这之后，官方还表示将提供允许治理容器定义有效访问控制列表的方法，并允许神经元持有者在这些有效选项中更改单个神经元的访问控制。
上述控制器指的是控制神经元的Principal，Principal必须确定一个公钥对后，它充当“主密钥”， 一个Principal可能控制许多神经元。
上述Hotkey指的是可执行具有权限操作（例如投票）的密钥列表。
在SNS神经元其它机制上，官方的建议是与NNS神经元保持不变，包括：
（如在 NNS 中）质押的治理Token的数量。
（如在 NNS 中）创建神经元的时间。
（如在 NNS 中）神经元的溶解状态指定神经元是否正在溶解，即为在神经元质押的Token在未来多长时间内可以解锁。神经元的age（年龄）指定了神经元处于非溶解状态的时间。
（如在 NNS 中）一个神经元可以跟随神经元将他们的投票委托给其他神经元。
（如在 NNS 中）一个神经元的成熟度（maturity）对应其参与治理投票获得的奖励。
注解：在NNS，一个神经元质押的Tokne*成熟度=参与治理获得投票奖励
SNS神经元的操作命令
对于管理SNS神经元操作命令，官方提出了与NNS神经元操作的相同的子集命令：
索取神经元（Claim neuron）/在治理系统中质押Tokens创建神经元；
清算神经元（Disburse neuron）/将神经元参与治理投票获得的奖励清算；
充值神经元（Top up a neuron）/为神经元充值更多的质押Tokens，增加投票权；
发起提案（Make Proposal）/在创建神经元后，任何人都可发起提案；
参与治理投票（Vote）/在创建神经元后，每一个神经元都会获得投票权，用于提案投票；
更改跟委托投票配置（Change following）/在设置委托投票的跟随神经元后，可随时更改配置，例如添加更多跟随的神经元、删除跟随神经元等。
更改溶解状态（Change dissolve state）/在神经元设置溶解延迟时间后可选择开启神经元的溶解状态或者在开启溶解状态后暂停溶解进入锁定状态增加年龄（age）；
增加溶解延迟时间（Change dissolve delay）/在一个神经元创建设置初始溶解延迟时间后，其可通过增加溶解延迟时间来增加投票权。
产出成熟度（Spawn matyrity）/在NNS中如果成熟度奖励超过1个ICP，会开启一个Spawn neuron的按钮，点击该按钮，会将成熟度奖励以生成一个新的神经元的方式分发，新神经元有7天的溶解延迟时间。据官方表示在SNS中产出成熟度（Spawn matyrity）的方式与NNS中相同，但新神经元溶解延迟时间还未表明。
合并成熟度（Merge maturity）/在神经元每次参与治理投票后都会增加其神经元中的成熟度，每一位神经元用户都可以通过合并成熟度（Merge maturity）将成熟度奖励增加到神经元质押Token中的方式，增加神经元投票权。
SNS神经元的可配置性
为了使SNS更加灵活，官方的建议是将与神经元相关因素设置为可配置，例如：
每个SNS可设置神经元的最小权益为多少；
神经元可设置的最大溶解延迟；
关于治理奖励分发，官方的建议是在第一版本中保持分发治理奖励的机制，在后续版本中SNS社区可自定义。
SNS治理容器新设计提案
目前SNS治理容器新设计提案已提交于NNS，通过下方链接进行投票：
SNS治理容器新设计提案：
https://dashboard.internetcomputer.org/proposal/42626
SNS治理容器新设计讨论：
https://forum.dfinity.org/t/open-governance-canister-for-sns-design-proposal/10224
必看周刊
生态精选
寻宝回顾
精彩活动
联系我们
t.me/DfinitySZ
dfisz.com
twitter.com/DfinitySZ
twitter.com/DfinitySZCN
reddit.com/user/DfinityShenZhen