想要進一步深入了解互聯網計算機（Internet Computer），網絡神經系統（NNS）和服務神經系統（SNS）的運行原理那你一定不能錯過…
— 導讀（Web3Caff 編輯部注）
作者： ICPL 研究院 Yoka、blocpunk
封面：DFINITY
原用標題：【SNS】DAPP 的代幣化與治理組件，介紹 IC 的 SNS 系統如何運行
網絡神經系統（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 的空間。
- 驗證通過，那麼它將創建這些新容器：治理容器，賬本容器和根容器。
- 要做到這一點，用戶可以首先獲得一個 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 可以提取這些信息併升級自己，以下是操作流程。
1. 創建新的部署路徑（賬本容器 v1）：如下圖，開發者希望通過將賬本容器升級到 v1。開發者得先對新版本進行大量測試，並確保升級的過程確實有效，賬本容器 v1 與當前的治理容器與根容器兼容。然後向 NNS 發布一份提案。
2. 如果提案的通過，進行更新：NNS 的投票人將進行同樣的測試，並確保提案的合理性。如果提案被採納，NNS 的註冊表將被更新，說明可以升級到這個新版本。
3. 發送賬本容器 v1 的 wasm 文件：需要將更新的版本上傳到鏈上，將此賬本容器 v1 的 wasm 發送到 SNS wasm 模塊容器。
4. 檢查：SNS wasm 模塊容器隨後檢查這個新版本是否是之前在註冊表中得到認可的版本，確認無誤後接受這個新的 wasm 文件。
5. 更新：對應的 SNS 會自動更新，流程下面介紹。
SNS 自動升級
1. 檢查是否有新版本：SNS 的治理容器可以定期檢查註冊表中是否有新版本，將註冊表上的版本與 SNS 的當前版本進行比較。
2. 獲取新 wasm 並啟動升級：如果有新版本，它可以從 SNS wasm 模塊容器中獲取該 wasm 並啟動更新。
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。文章內的信息僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
