服务神经系统（SNS）是一个算法 DAO，允许开发人员为其 DAPP 创建去中心化的、基于代币的治理系统。

原文标题：《【SNS】DAPP 的代币化与治理组件，介绍 IC 的 SNS 系统如何运行》

由 ICPL 研究院 Yoka 与 blocpunk 共同整理

网络神经系统（NNS）是控制互联网计算机区块链（IC）的开放代币化治理系统，与它类似，服务神经系统（SNS）是一个算法 DAO，允许开发人员为其 DAPP 创建去中心化的、基于代币的治理系统。

2021 年的 Q4 DFINITY 基金会首次提出了服务神经系统的设计，但社区认为 SNS 的初案过于复杂的设计，新提案更新了很多内容：

• SNS 包含治理、代币与系统三部分；
• SNS 可以帮助 DAPP 实现去中心化治理、代币发行；
• 建立 SNS 的专用子网，将治理与代币化作为系统底层功能；
• 更灵活性的操作，开发者可以在自建 SNS，也可以使用 SNS 子网；

SNS 概述

什么是 NNS & SNS？

网络神经系统（NNS）是一个开放的管理系统，它管理整个互联网计算机及其所有子网和节点。服务神经系统（SNS）也是一个开放的治理系统，是一个类似的概念。SNS 只管理一个 DAPP，而不是整个 IC。因此，每一个 DAPP 都可以有一个 SNS。

我们为什么需要 SNS?

 实现 web3 应用程序需要的几个关键点：

• DAPP 是真正的端到端托管在链上（包括前端等）；
• DAPP 为用户所有；
• DAPP 由用户控制。

对于最后两点，需要一个 DAO（去中心化自治组织），这正是我们说的 SNS。因此，SNS 可以实现两个关键功能：去中心化和代币化。对于被用户控制部分，对 dapp 的去中心化控制，比如决定它应该如何升级，可以由用户控制。同时对被用户所有部分，SNS 还会帮助 DAPP 代币化，允许用户在该系统上拥有代币所有权，并建立各种激励制度。

SNS 包含的容器

治理容器、账本容器和根容器。

 治理容器

• 它可以提出一些提案，有助于 SNS 的决策。基本上，提案是关于 dapp 应该如何发展的建议。
• 与 NNS 类似，持币人可以创建神经元，决定在哪里参与治理。每个人都可以拿一些代币，把它们押在一个神经元里，然后成为这个治理系统的参与者。这实际上是一个无准入的治理体系。

账本容器

首先，每个 SNS 都可以有自己的治理代币。账本容器可以追溯两件事：

• 帐户的代币余额。
• 跟踪账户之间的交易。

根容器（系统）

为此，我们必须了解容器的升级工作原理。升级分三部分：首先得先停止容器的运行，然后为此容器安装新代码，然后就可以重新启动容器。但问题是，容器无法仅靠自己完成升级，需要一个系统来协调。例如，治理容器无法停止和重新启动，因此，我们需要另一个容器来协调此升级。这正是根容器的作用。

  当然也可以这个逻辑放到账本中，让账本容器升级根目录，但这样会让保持账本容器变得更复杂。将这部分逻辑放在单独的容器中是一种更简便的解决方案。根容器会沿用 NNS 的大部分代码。

SNS 专用子网

基金会会把代码起放入 IC repo 中开源。由于每个人都可以在 github 中获取代码，并将容器部署到应用子网中，这基本上提供了最大的灵活性。然而，这种方法也有一些缺点。首先，治理、分类账或根目录的任何升级都需要 SNS 社区执行，只需要大量复杂的专业化工作，这对治理本身提出了挑战。而部署在 NNS 网络中作为系统功能提供的 SNS，依靠 NNS 的认证，就会更加简化。同时，自部署的 SNS 运行在应用子网上，而应用子网上的节点没有 NNS 所在的系统子网多，因此安全性更弱。

SNS 作为系统功能

基金会建议建立一个新的 SNS 子网，专门运行 SNS，将其作为一个 IC 的原生系统功能。

下图紫色虚线表示子网边界，左边是 NNS 子网，右边的按钮是 DAPP 已经存在的普通应用子网。

与其他子网区别

• SNS 子网只承载 SNS，其他容器无法进行干扰，更安全；
• 相比应用子网更多的节点，基金会正在考虑从 34 个节点开始逐渐增加；
• 由于存在更多节点，该子网手续费应该比其他应用程序子网更昂贵。

模块化

如果一个子网不能容纳无限数量的容器，那么如果这个 SNS 子网已满，可以添加新的 SNS 子网，就像在互联网计算机上添加新的应用子网一样：

• 任何人都可以提出添加新子网的建议；
• 如果这项提议被采纳，那么信息将在注册表中更新；
• 并且注册表将创建这样一个新的子网。

部署 SNS

假设我们有一个用户在某个应用子网里以及有了一个 DAPP，准备在应用子网上部署一个对应的 SNS：

• 要做到这一点，用户可以首先获得一个 cycles 钱包，钱包不必与 DAPP 位于同一应用子网中；
• 用户可以声明想要部署一个新的 SNS，通过这个 cycle 钱包向这个 SNS wasm 模块容器发出一个请求。这个请求有几个目的：首先，它将发送足够的 cycels 来支付 SNS 的初始 gas；然后，它还将定义 SNS 的初始参数，例如，DAO 包含的初始帐户（在账本容器中的）、代币名称、应该存在的初始神经元等等；
• 然后，SNS wasm 模块容器将检查这些初始参数是否一致，例如，对于每个神经元，账本上都有对应一个账户等等。还有一些其他的检查，比如检查这个子网上是否还有新 SNS 的空间。
• 验证通过，那么它将创建这些新容器：治理容器，账本容器和根容器。

基金会还计划推出一个更用户友好的前段，将 SNS 作为更长尾化的服务，提供给更多的社区。

SNS 的使用

开发者可以创建 SNS，并将 DAPP 容器的控制人更改为 SNS。

也可以反过来，开发者可以在 SNS 容器中，把 SNS 设置为 DAPP 的控制人，但也保留早先的控制人。一段时间后，如果开发者有足够的信心相信 SNS 合理的管理 DAPP，那么他们就可以从控制器中移除自己，让 SNS 完全控制 DAPP。

因此，可以在没有 DAPP 的情况下先部署 SNS，通过 SNS 代币化的方式获得初始资金，或者从开始解决就引入社区的意愿，然后再开发 DAPP 并将其控制权分配给 SNS。

在 SNS 中，根容器会控制所有其他容器，包括 DAPP 容器，而治理容器又去控制根容器。对 DAPP 的更新就由 SNS 的治理容器控制。

 而如果要更新 SNS 本身，比如账本容器出现了一些错误，就需要来自 NNS 的根容器来控制 SNS 的更新，我们必须向 NNS 发起一个提案，提案通过后 NNS 会修改他自己的系统容器，并发出请求要求 SNS 升级（或更正错误）。

SNS 的升级

现在我们已经部署了一个 SNS，包含了 DAPP 的治理于代币等功能，如果我们需要加入新的功能，或者单纯的修正错误（可能被攻击了），该怎么办？因此我们需要 SNS 能进行更新。

对升级的挑战

• 版本的兼容性：不是所有版本的治理容器、账本容器和根容器的都能兼容的。这种 repo 总是在不断演变，所以会有不同版本的容器。一个极端的例子是，如果我们在治理容器中删除一个 API 方法，可能会导致一个想要调用这个 API 的账本容器不能与这个治理容器兼容。
• 升级可能会变得不安全：并非所有的升级都是安全的。我们是不可能对升级本身中会发生的状况进行定义。因此，当我们需要从一个非常古老的治理容器版本升级到一个非常新的版本事，应该做一些清理工作。但是，这样做并不能保证安全。

保证升级的安全性

每个 SNS 必须确保所有升级都是安全的，这样我们才不会出现损失。这非常具有挑战性，所以我们建议将这些信息放入「待验证」的注册表中。

NNS 的治理者们可以去测试这些待验证的升级，然后他们可以验证这些信息并将其放入注册表。然后使用 SNS 的社区就可以更放心的对验证过的内容进行升级，信任被传递了。

我们希望在这个验证升级的注册表中有两条主要信息，作为一种新的部署路径：

首先是 SNS 的可兼容组合。例如上图，第一列显示治理、账本和根目录的容器都为 v0 彼此兼容，所以开发者就可以将这三个容器部署在一起组成 SNS。而第二列显示账本容器 v1 与 v0 的治理和根目录容器兼容，你可以按这样的组合部署 SNS。

另一个信息是告知社区是否可以升级。比如通过充分测试，NNS 告诉大家可以将所有容器都是 v0 的 SNS 中将账本容器升级到 v1。

相比对 wasm 的版本本身认证，对升级路径认证是更优的方案。不能采用对最新的已认证版本进行更新的路径，这样会跳过多个版本导致单个容器的兼容出现问题，必须去记录可升级的路径。而只认证三个容器中单独一个容器的升级路径也存在问题。因为 SNS 系统是配合工作的，除去 wasm 版本的问题外，还有三个容器自身兼容性问题。因此 SNS 的升级方案建议进行整体的部署。

如何升级

升级具备有两种基本的可能背景。首先，每个人都可以选择编译代码，在任何应用子网上安装容器组建 SNS，然后手动将其升级到他们想要的任何位置，在此不做赘述。

与自发部署相比，SNS 也会部署在专用网中。而 SNS 专用子王上的容器需要不断升级到最新版本，这样用户就不必做额外的工作。

要做到无需输入的自动升级，容器就需要知道升级到什么，因此这些信息必须在链上。

从 NNS 的注册表中，容器已经可以了解得到被认证的最新版本。但这些被认证的版本实际上只包含 wasm 的哈希，为了升级容器还必须知道新安装的 wasm。如果所有这些都应该是自动化的话，还需要让 wasm 本身在链上。基金会建议使用一个新的容器来容纳这些 SNS wasm 模块，并将其部署在 SNS 专用子网上。对于提出的每一个新的 SNS 容器，都会将新的 wasm 添加到这个 SNS wasm 模块容器中。 

如上所述，关于 SNS 应该运行的最新版本的信息既在注册表中，也在这个新容器上有实际的 wasm 容器。如果我们想添加一个新版本的 SNS，我们必须首先在这两个地方进行更新。然后 SNS 可以提取这些信息并升级自己，以下是操作流程。

创建新的部署路径（账本容器 v1）：如下图，开发者希望通过将账本容器升级到 v1。开发者得先对新版本进行大量测试，并确保升级的过程确实有效，账本容器 v1 与当前的治理容器与根容器兼容。然后向 NNS 发布一份提案。

如果提案的通过，进行更新：NNS 的投票人将进行同样的测试，并确保提案的合理性。如果提案被采纳，NNS 的注册表将被更新，说明可以升级到这个新版本。

发送账本容器 v1 的 wasm 文件：需要将更新的版本上传到链上，将此账本容器 v1 的 wasm 发送到 SNS wasm 模块容器。

检查：SNS wasm 模块容器随后检查这个新版本是否是之前在注册表中得到认可的版本，确认无误后接受这个新的 wasm 文件。

更新：对应的 SNS 会自动更新，流程下面介绍。

SNS 自动升级

检查是否有新版本：SNS 的治理容器可以定期检查注册表中是否有新版本，将注册表上的版本与 SNS 的当前版本进行比较。

获取新 wasm 并启动升级：如果有新版本，它可以从 SNS wasm 模块容器中获取该 wasm 并启动更新。