Các thành phần quản trị và mã hóa của dapp, giới thiệu cách thức hoạt động của hệ thống SNS

Windy

17/03/2022 05:53

143

Được tổ chức bởi Yoka và blocpunk của Viện nghiên cứu ICPL.

Tương tự như Hệ thống thần kinh mạng (NNS), một hệ thống quản trị mã hóa mở kiểm soát chuỗi khối máy tính Internet (IC), Hệ thống thần kinh dịch vụ (SNS) là một DAO theo thuật toán cho phép các nhà phát triển tạo hệ thống phi tập trung cho DAPP của họ, dựa trên mã thông báo hệ thống quản trị.

Vào quý 4 năm 2021, Quỹ DFINITY lần đầu tiên đề xuất thiết kế phục vụ hệ thần kinh, nhưng cộng đồng cho rằng đề xuất ban đầu của SNS quá phức tạp và đề xuất mới đã cập nhật rất nhiều nội dung:

SNS bao gồm ba phần: quản trị, mã thông báo và hệ thống
SNS có thể giúp DAPP đạt được quản trị phi tập trung và phát hành mã thông báo
Thiết lập một mạng con dành riêng cho SNS và sử dụng quản trị, mã hóa làm các chức năng cơ bản của hệ thống
Hoạt động linh hoạt hơn, các nhà phát triển có thể xây dựng SNS của riêng họ hoặc sử dụng mạng con SNS

Tổng quan về SNS

NNS & SNS là gì?

Hệ thống thần kinh mạng (NNS) là một hệ thống quản lý mở, quản lý toàn bộ máy tính Internet và tất cả các mạng con và nút của nó. Hệ thống thần kinh dịch vụ (SNS), cũng là một hệ thống quản trị mở, là một khái niệm tương tự. SNS chỉ quản lý một DAPP, không phải toàn bộ IC. Do đó, mỗi DAPP có thể có một SNS.

Tại sao chúng ta cần SNS?

Một số điểm chính cần thiết để triển khai ứng dụng web3:

DAPP thực sự là end-to-end được lưu trữ trên chuỗi (bao gồm cả front-end, v.v.)
DAPP do người dùng sở hữu
DAPP được kiểm soát bởi người dùng

Đối với hai điểm cuối cùng, cần có DAO (Tổ chức tự trị phi tập trung), cái mà chúng tôi gọi là SNS. Do đó, SNS có thể đạt được hai chức năng chính: phân quyền và mã hóa. Đối với phần do người dùng kiểm soát, quyền kiểm soát phi tập trung của dapp, chẳng hạn như quyết định cách nó nên được nâng cấp, có thể được kiểm soát bởi người dùng. Đồng thời, đối với phần do người dùng sở hữu, SNS cũng sẽ giúp mã hóa DAPP, cho phép người dùng có quyền sở hữu mã thông báo trên hệ thống và thiết lập các hệ thống khuyến khích khác nhau.

Các vùng chứa (canisters) có trong SNS

Vùng chứa quản trị, vùng chứa sổ cái và vùng chứa gốc.

Các vùng chứa quản trị

Nó có thể đưa ra một số đề xuất để giúp quyết định của SNS. Về cơ bản, các đề xuất là những gợi ý về cách các dapp sẽ phát triển.
Tương tự như NNS, chủ sở hữu mã thông báo có thể tạo ra các tế bào thần kinh quyết định nơi tham gia quản trị.
Mọi người đều có thể lấy một số token, đặt cược chúng vào một nơ-ron và trở thành người tham gia vào hệ thống quản trị này. Đây thực sự là một hệ thống quản trị không có quyền truy cập.

Hộp đựng sổ cái Ledger

Đầu tiên, mỗi SNS có thể có mã thông báo quản trị riêng. Vùng chứa sổ cái có thể theo dõi hai điều:

Số dư mã thông báo của tài khoản.
Theo dõi giao dịch giữa các tài khoản.

Vùng chứa root (hệ thống)

Để làm được điều này, chúng ta phải hiểu cách thức hoạt động của việc nâng cấp vùng chứa. Có ba phần để nâng cấp: trước tiên bạn phải dừng vùng chứa, sau đó cài đặt mã mới cho vùng chứa và sau đó bạn có thể khởi động lại vùng chứa. Nhưng vấn đề là các container không thể tự mình nâng cấp và cần một hệ thống để điều phối. Ví dụ: vùng chứa quản trị không thể dừng và khởi động lại, vì vậy chúng tôi cần một vùng chứa khác để điều phối việc nâng cấp này. Đây chính xác là những gì mà vùng chứa root thực hiện.

Tất nhiên, logic này cũng có thể được đưa vào sổ cái và cho phép vùng chứa sổ cái nâng cấp thư mục gốc, nhưng điều này sẽ làm cho việc duy trì vùng chứa sổ cái phức tạp hơn. Đặt phần logic này vào một vùng chứa riêng biệt là một giải pháp dễ dàng hơn. Vùng chứa gốc sẽ kế thừa hầu hết mã từ NNS.

Mạng con SNS riêng

Nền tảng sẽ đưa mã vào kho IC nguồn mở. Về cơ bản, điều này mang lại sự linh hoạt nhất vì mọi người đều có thể lấy mã trong github và triển khai vùng chứa vào mạng con của ứng dụng. Tuy nhiên, cách làm này cũng có một số điểm hạn chế. Đầu tiên, bất kỳ nâng cấp nào đối với quản trị, sổ cái hoặc root đều cần được thực hiện bởi cộng đồng SNS, chỉ yêu cầu nhiều công việc chuyên môn phức tạp, điều này đặt ra những thách thức đối với chính quản trị. SNS được triển khai trong mạng NNS như một chức năng hệ thống sẽ được đơn giản hóa hơn bằng cách dựa vào xác thực NNS. Đồng thời, SNS tự triển khai chạy trên mạng con của ứng dụng và các nút trên mạng con của ứng dụng không nhiều bằng mạng con của hệ thống nơi đặt NNS, do đó tính bảo mật yếu hơn.

SNS như một chức năng hệ thống

Tổ chức đề xuất tạo một mạng con SNS mới để chạy SNS độc quyền như một chức năng hệ thống riêng của IC. Đường chấm màu tím trong hình bên dưới đại diện cho ranh giới mạng con, bên trái là mạng con NNS và nút bên phải là mạng con ứng dụng bình thường mà DAPP đã tồn tại.

Khác với các mạng con khác

Mạng con SNS chỉ mang SNS và các vùng chứa khác không thể can thiệp, điều này an toàn hơn
Tổ chức đang xem xét việc tăng dần từ 34 nút so với mạng con của ứng dụng có nhiều nút hơn
Do sự hiện diện của nhiều nút hơn, mạng con này sẽ đắt hơn các mạng con ứng dụng khác

Module

Nếu một mạng con không thể chứa số lượng không giới hạn các vùng chứa, thì nếu mạng con SNS này đã đầy, bạn có thể thêm một mạng con SNS mới, giống như thêm một mạng con ứng dụng mới trên máy tính internet:

Bất kỳ ai cũng có thể đề xuất thêm mạng con mới
Nếu đề xuất này được thông qua, thông tin sẽ được cập nhật trong sổ đăng ký
Và cơ quan đăng ký sẽ tạo một mạng con mới như vậy

Triển khai SNS

Giả sử chúng ta có một người dùng trong mạng con ứng dụng và một DAPP, sẵn sàng triển khai SNS tương ứng trên mạng con ứng dụng:Để làm điều này, trước tiên người dùng có thể lấy một ví chu kỳ, ví không cần phải nằm trong cùng một mạng con của ứng dụng với DAPP
Người dùng có thể khai báo rằng họ muốn triển khai SNS mới và thực hiện yêu cầu đối với vùng chứa mô-đun SNS wasm thông qua ví chu kỳ. Yêu cầu này có một số mục đích: đầu tiên, nó sẽ gửi đủ số chu kỳ để thanh toán gas ban đầu của SNS; sau đó, nó cũng sẽ xác định các thông số ban đầu của SNS, ví dụ: tài khoản ban đầu (trong vùng chứa sổ cái), mã thông báo chứa trong tên DAO, nơ-ron ban đầu cần tồn tại, v.v.
Sau đó, vùng chứa mô-đun SNS wasm sẽ kiểm tra xem các tham số ban đầu này có nhất quán hay không, ví dụ: đối với mỗi nơ-ron có một tài khoản trên sổ cái, v.v. Có một số cách kiểm tra khác, chẳng hạn như kiểm tra xem có còn chỗ cho SNS mới trên mạng con này hay không
Nếu quá trình xác minh vượt qua, thì nó sẽ tạo các vùng chứa mới này: vùng chứa quản trị, vùng chứa sổ cái và vùng chứa gốc
Quỹ cũng có kế hoạch tung ra giao diện người dùng thân thiện hơn, cung cấp SNS như một dịch vụ đuôi dài hơn cho nhiều cộng đồng hơn.

Sử dụng SNS

Các nhà phát triển có thể tạo SNS và thay đổi bộ điều khiển của vùng chứa DAPP thành SNS.

Ngoài ra, các nhà phát triển có thể đặt SNS làm bộ điều khiển DAPP trong vùng chứa SNS, nhưng cũng giữ lại bộ điều khiển trước đó. Sau một khoảng thời gian, nếu các nhà phát triển có đủ tin tưởng rằng SNS quản lý DAPP một cách hợp lý, thì họ có thể tự xóa mình khỏi bộ điều khiển và để SNS kiểm soát hoàn toàn DAPP.

Do đó, trước tiên có thể triển khai SNS mà không cần DAPP, thu được tiền ban đầu thông qua mã hóa SNS hoặc giới thiệu ý chí của cộng đồng ngay từ đầu giải pháp, sau đó phát triển DAPP và giao quyền kiểm soát của nó cho SNS.

Trong SNS, vùng chứa root kiểm soát tất cả các vùng chứa khác, bao gồm vùng chứa DAPP và vùng chứa quản trị kiểm soát vùng chứa root. Các cập nhật cho DAPP được kiểm soát bởi vùng chứa quản trị của SNS.

Ví dụ: nếu chúng ta muốn cập nhật SNS, nếu có một số lỗi trong vùng chứa sổ cái, chúng ta cần vùng chứa root từ NNS để kiểm soát việc cập nhật SNS. Chúng ta phải bắt đầu đề xuất lên NNS. Sau khi đề xuất được thông qua, NNS sẽ sửa đổi vùng chứa hệ thống của riêng mình và đưa ra Yêu cầu nâng cấp SNS (hoặc sửa lỗi).

** SNS * * NÂNG CẤP **

Bây giờ chúng tôi đã triển khai SNS, bao gồm các chức năng như quản trị DAPP và mã thông báo, chúng tôi nên làm gì nếu chúng tôi cần thêm các chức năng mới hoặc đơn giản là sửa lỗi (có thể bị tấn công)? Vì vậy, chúng tôi cần SNS để có thể cập nhật.

Thách thức để nâng cấp

Khả năng tương thích với phiên bản: Không phải tất cả các phiên bản của vùng chứa quản trị, vùng chứa sổ cái và vùng chứa root đều tương thích. Repo này luôn phát triển, vì vậy sẽ có nhiều phiên bản container khác nhau. Ví dụ điển hình nhất, nếu chúng tôi xóa một phương thức API trong vùng chứa quản trị, điều đó có thể khiến vùng chứa sổ cái muốn gọi API này không tương thích với vùng chứa quản trị.
Nâng cấp có thể trở nên không an toàn: Không phải tất cả các nâng cấp đều an toàn. Chúng tôi không thể xác định điều gì sẽ xảy ra trong quá trình nâng cấp. Vì vậy, khi chúng tôi cần nâng cấp từ phiên bản vùng chứa quản trị rất cũ lên một phiên bản rất mới, một số thao tác dọn dẹp sẽ được thực hiện. Tuy nhiên, làm như vậy không đảm bảo an toàn.

Bảo mật nâng cấp được đảm bảo

Mọi SNS phải đảm bảo rằng tất cả các nâng cấp đều an toàn để chúng tôi không bị mất tiền. Điều này rất khó khăn, vì vậy chúng tôi khuyên bạn nên đưa thông tin này vào sổ đăng ký “đang chờ xác minh”.

NNS có thể kiểm tra các bản nâng cấp đang chờ xử lý này, sau đó họ có thể xác minh thông tin này và đưa nó vào sổ đăng ký. Sau đó, cộng đồng sử dụng SNS có thể nâng cấp nội dung đã xác minh với độ tin cậy cao hơn và sự tin tưởng được truyền đi.

Chúng tôi muốn có hai phần thông tin chính trong sổ đăng ký này để xác nhận việc nâng cấp, như một loại đường dẫn triển khai mới:

Đầu tiên là sự kết hợp tương thích của SNS. Ví dụ, trong hình trên, cột đầu tiên cho thấy rằng các vùng chứa quản trị, sổ cái và thư mục gốc tương thích với nhau v0, vì vậy các nhà phát triển có thể triển khai ba vùng chứa này cùng nhau để tạo thành SNS. Trong khi cột thứ hai cho thấy rằng vùng chứa sổ cái v1 tương thích với quản trị và vùng chứa gốc của v0, bạn có thể triển khai SNS theo cách kết hợp như vậy.

Một thông báo khác là thông báo cho cộng đồng nếu có thể nâng cấp. Ví dụ: thông qua thử nghiệm đầy đủ, NNS cho bạn biết rằng bạn có thể nâng cấp vùng chứa sổ cái lên v1 trong SNS, nơi tất cả các vùng chứa đều là v0.

So với phiên bản WASM, xác thực đường dẫn nâng cấp là một giải pháp tốt hơn. Không thể sử dụng đường dẫn để cập nhật phiên bản được chứng nhận mới nhất, điều này sẽ bỏ qua nhiều phiên bản và gây ra sự cố tương thích cho một vùng chứa. Cần phải ghi lại đường dẫn có thể nâng cấp. Cũng có một vấn đề với việc xác thực đường dẫn nâng cấp chỉ cho một trong ba vùng chứa. Bởi vì hệ thống SNS hoạt động cùng nhau, ngoài vấn đề phiên bản wasm, còn có ba vấn đề về khả năng tương thích của vùng chứa. Do đó, kế hoạch nâng cấp của SNS được khuyến nghị nên được triển khai một cách tổng thể.

Cách nâng cấp

Có hai bối cảnh cơ bản có thể có để nâng cấp. Đầu tiên, mọi người có thể chọn biên dịch mã, cài đặt vùng chứa trên bất kỳ mạng con ứng dụng nào để tạo thành SNS, sau đó nâng cấp thủ công lên bất kỳ nơi nào họ muốn, vì vậy tôi sẽ không đi sâu vào chi tiết ở đây.

So với việc triển khai tự phát, SNS cũng được triển khai trong một mạng riêng. Mặt khác, thùng chứa trên vua phụ SNS chuyên dụng cần được nâng cấp liên tục lên phiên bản mới nhất, để người dùng không phải làm thêm.

Để thực hiện nâng cấp tự động mà không cần đầu vào, vùng chứa cần biết nội dung cần nâng cấp lên, vì vậy thông tin này phải có trong chuỗi.

Từ sổ đăng ký NNS, vùng chứa đã biết phiên bản mới nhất được chứng nhận. Nhưng những phiên

bản được chứng nhận này thực tế chỉ chứa hàm băm của wasm, và để nâng cấp vùng chứa cũng phải biết về wasm mới được cài đặt. Cũng cần có bản thân wasm on-chain nếu tất cả điều này được cho là tự động. Tổ chức khuyến nghị sử dụng một vùng chứa mới cho các mô-đun SNS wasm này và triển khai chúng trên mạng con riêng SNS. Đối với mỗi vùng chứa SNS mới được đề xuất, một wasm mới được thêm vào vùng chứa mô-đun SNS wasm này.

Như đã đề cập ở trên, thông tin về phiên bản SNS mới nhất sẽ chạy đều có trong sổ đăng ký và vùng chứa wasm thực tế trên vùng chứa mới này. Nếu chúng tôi muốn thêm phiên bản SNS mới, trước tiên chúng tôi phải cập nhật ở cả hai nơi. Sau đó SNS có thể trích xuất thông tin này và tự nâng cấp, sau đây là quy trình hoạt động.

Tạo một đường dẫn triển khai mới (vùng chứa sổ cái v1): Như trong hình bên dưới, nhà phát triển muốn nâng cấp vùng chứa sổ cái lên v1. Các nhà phát triển phải thực hiện thử nghiệm rộng rãi phiên bản mới trước tiên và đảm bảo rằng quá trình nâng cấp thực sự hoạt động và vùng chứa sổ cái v1 tương thích với vùng chứa quản trị hiện tại và vùng chứa gốc. Một đề xuất sau đó được công bố cho NNS.
Nếu đề xuất được thông qua, hãy cập nhật: Các cử tri NNS sẽ chạy cùng một bài kiểm tra và đảm bảo rằng đề xuất là đúng đắn. Nếu đề xuất được chấp nhận, sổ đăng ký NNS sẽ được cập nhật để cho biết có thể nâng cấp lên phiên bản mới này.
Gửi tệp wasm của vùng chứa sổ cái v1: Bạn cần tải phiên bản cập nhật lên chuỗi và gửi tệp bem của vùng chứa sổ cái v1 này đến vùng chứa mô-đun SNS wasm.
Kiểm tra: Sau đó, thùng chứa mô-đun SNS wasm kiểm tra xem phiên bản mới có phải là phiên bản đã được công nhận trước đó trong sổ đăng ký hay không và chấp nhận tệp wasm mới sau khi xác nhận rằng nó là đúng.
Cập nhật: SNS tương ứng sẽ được cập nhật tự động. Quá trình này được mô tả bên dưới.

Nâng cấp tự động SNS

Kiểm tra các phiên bản mới: Vùng chứa quản trị cho SNS có thể kiểm tra định kỳ sổ đăng ký để tìm các phiên bản mới, so sánh phiên bản trên sổ đăng ký với phiên bản hiện tại của SNS.
Lấy wasm mới và bắt đầu nâng cấp: Nếu có phiên bản mới, nó có thể lấy wasm từ thùng chứa mô-đun wasm SNS và bắt đầu cập nhật.