Nhìn vào sự quản trị và phát triển của CKB từ Git

Tiêu đề gốc: "CKB, Kiểm soát phiên bản và tiến hóa chuỗi khối"

Tác giả gốc: Jan Xie, Cộng đồng người Trung Quốc Nervos

Tôi là người hâm mộ Linus. Anh ấy đã tạo ra một hệ điều hành nguồn mở có mặt ở khắp mọi nơi, là đồng tác giả của một cuốn sách mà tôi cực kỳ yêu thích và đã xây dựng một hệ thống kiểm soát phiên bản phân tán mà gần như mọi nhà phát triển đều sử dụng hàng ngày.

Tôi bắt đầu sử dụng Git ngay khi nhìn thấy nó và bị thu hút bởi tốc độ và sự tinh tế của nó. Các nhà phát triển sử dụng hệ thống kiểm soát phiên bản để quản lý mã nguồn, nhờ đó họ có thể theo dõi các bản cập nhật mã, chia sẻ các thay đổi với bạn bè và đồng nghiệp, quay lại các phiên bản không có lỗi trước đó khi xảy ra lỗi mới, v.v.  Git khiến cuộc sống trở nên thú vị hơn và tôi hy vọng CKB có thể làm được điều tương tự.

CKB là Git

Quy trình tạo mô hình CKB và Cell của chúng tôi được lấy cảm hứng từ Git. Git xuất hiện từ mong muốn của Linus là làm cho việc phát triển nhân Linux trở nên dễ dàng và nó có thể được sử dụng bất cứ khi nào mọi người muốn sắp xếp thứ gì đó, từ nhận xét, bài đăng trên blog cho đến hình ảnh. Nó là một cơ sở kiến thức được hỗ trợ bởi khả năng theo dõi lịch sử tuyệt vời.

Cơ sở kiến thức Git được gọi là " " Repository" duy trì nội bộ một cơ sở dữ liệu đối tượng bất biến, chỉ bổ sung (bạn có nhớ điều đó không?). Đơn vị lưu trữ cơ bản trong Git là Blob (đối tượng lớn nhị phân), là đối tượng chứa dữ liệu mà mọi người lưu trữ trong kho lưu trữ, giống như Ô trong CKB. Git tạo đối tượng blob cho mỗi phiên bản của mỗi tệp. Bất cứ khi nào một tệp mới được tạo, một đốm màu mới sẽ được tạo. Bất cứ khi nào một tệp hiện có được sửa đổi, một blob sẽ được tạo với nội dung mới mà không sửa đổi blob cũ (nghe có quen không?). Mỗi blob được băm và băm blob được sử dụng làm mã định danh để tham chiếu blob. Sau khi làm việc được vài giờ, bạn tạo một số tệp mới và sửa đổi một số tệp hiện có, chuyển tất cả các thay đổi của bạn vào kho lưu trữ, đồng bộ hóa các cam kết mới với đồng nghiệp của mình và kết thúc ngày làm việc.

Một cam kết là điểm lịch sử cơ bản trong Git và lịch sử kho lưu trữ bao gồm một chuỗi các cam kết từ nguồn gốc của kho lưu trữ đến bản cập nhật gần đây nhất. Cam kết là một phiên bản của kho lưu trữ tại một thời điểm cụ thể và bao gồm siêu dữ liệu của phiên bản như tác giả, dấu thời gian, cam kết trước đó và tham chiếu đến cây blob. Giống như tiêu đề khối chứa siêu dữ liệu cho mỗi lần cập nhật lên chuỗi khối bằng cách ghi lại địa chỉ công cụ khai thác, dấu thời gian, hàm băm khối gốc và gốc của cây merkle giao dịch. Bạn và đồng nghiệp của bạn được trả tiền bằng cách mở rộng lịch sử kho git của mình, giống như những người khai thác nhận được phần thưởng khối bằng cách mở rộng lịch sử của các khối.

Kho lưu trữ Git cũng có thể có Fork. Mọi người làm việc trên các nhánh khác nhau, nhưng nhánh nào là "đúng" do những người bảo trì kho lưu trữ quyết định chứ không phải theo sự đồng thuận. Git là một hệ thống phân tán không có sự đồng thuận dựa trên giao tiếp ngang hàng đặc biệt (chẳng hạn như ssh hoặc email) để trao đổi dữ liệu.

Có những điểm tương đồng giữa Git và blockchain, điều đó cũng có nghĩa là chúng ta nên thận trọng hơn trong việc tích hợp các ý tưởng Git vào blockchain thay vì đưa các lựa chọn thiết kế xung đột vào blockchain để rằng các nhà phát triển blockchain hoặc hợp đồng thông minh có thể tận hưởng một số lợi thế đã được chứng minh của Git. Bên trong CKB thực sự giống như thế này: kho lưu trữ Git quy mô lớn duy nhất có mạng p2p thực sự, sự đồng thuận toàn cầu và các đốm màu nâng cao, được cập nhật liên tục bởi một nhóm những người vô danh.

Đây không phải là blockchain

Đặt tên cho ô theo cách bạn thích

Git và lõi của CKB là các đối tượng dữ liệu (blob/cell) và các tham chiếu băm. Tham chiếu băm là tên vốn có của một đối tượng, một cây đũa thần mà bạn có thể vẫy để trích xuất giá trị của dữ liệu. Nếu bạn biết tên của một đối tượng, bạn có thể tham khảo nó và từ đó có được quyền truy cập vào sức mạnh của nó. Trên CKB, mã của hợp đồng thông minh và dữ liệu người dùng được tách biệt, do đó, tham chiếu băm cho phép bạn đặt tên trực tiếp cho một đoạn mã hoặc dữ liệu người dùng, biến chúng thành đối tượng cấp đầu tiên trong hệ thống 2. Độ chi tiết tốt này tạo ra một mô hình lập trình linh hoạt và mạnh mẽ. Dưới đây là một số ví dụ.

Tái sử dụng mã/dữ liệu

Vì ô là đơn vị lưu trữ được tham chiếu nên rất dễ sử dụng lại mã/dữ liệu trên CKB. Giả sử có một số mã/dữ liệu được chia sẻ được lưu trữ trong ô 0xbeef#1 (đầu ra 1 của giao dịch 0xbeef#1), để sử dụng lại nó, trước tiên bạn cần tải ô 0xbeef#1 làm phụ thuộc giao dịch (cell_deps), sau đó sử dụng   ;ckb_load_cell_data lời gọi hệ thống đọc dữ liệu từ nó, như được hiển thị trong tập lệnh khóa mặc định. Sau khi dữ liệu trong ô 0xbeef#1 được tải vào bộ nhớ VM, dữ liệu đó có thể được sử dụng làm mã hoặc dữ liệu, tùy thuộc vào nhu cầu của bạn. Bằng cách này, CKB hoạt động giống như một thư viện mã và dữ liệu dùng chung để các hợp đồng thông minh chạy trên đó sử dụng. Sẽ thật tuyệt nếu chúng ta có thể xây dựng hợp đồng thông minh 4 bằng cách kết hợp các viên gạch LEGO an toàn hiện có phải không? Thay vì sao chép mã từ đâu đó trên GitHub và triển khai cùng một mã nhiều lần, điều này gây lãng phí thời gian và không gian trên chuỗi. Một phân tích về các hợp đồng Ethereum [5] [6] cho thấy 95% ~ 99% hợp đồng là trùng lặp.

Hợp đồng thông minh được lặp lại nhiều nhất trên Ethereum

Không sợ bị xóa phần phụ thuộc

Trong ví dụ tái sử dụng mã/dữ liệu ở trên , bạn không cần lo lắng về việc ai đó sửa đổi mã/dữ liệu được lưu trữ trong ô phụ thuộc, vì ô này là bất biến, nghĩa là không ai có cách sửa đổi nó. Nhưng điều gì sẽ xảy ra nếu chủ sở hữu của ô phụ thuộc trực tiếp xóa nó khỏi CKB? Điều đó có làm cho hợp đồng thông minh của tôi không thể sử dụng được không?

Đây thực sự là trường hợp của Ethereum . Nếu bạn ở trong không gian này đủ lâu, bạn có thể biết về sự cố năm 2017 liên quan đến sự cố trị giá 280 triệu USD [7]. Toàn bộ thảm kịch được gây ra bởi việc vô tình xóa một hợp đồng thông minh trên Ethereum vốn được nhiều hợp đồng thông minh khác sử dụng. Việc xóa này khiến tất cả các hợp đồng thông minh dựa vào nó trở nên rối loạn chức năng và tất cả tài sản được lưu trữ trong các hợp đồng thông minh này đều bị đóng băng.

Trên CKB, sự cố như vậy sẽ không ảnh hưởng gì, bởi vì bất kỳ ai lưu một bản sao mã (chẳng hạn như những người đang chạy nút đầy đủ hoặc máy khách nhẹ phức tạp) đều có thể triển khai lại cùng một mã trên chuỗi và hàm băm mã sẽ tài liệu tham khảo vẫn hợp lệ. Chúng ta chỉ cần xây dựng giao dịch bằng cách sử dụng ô phụ thuộc mới. Sẽ không có ai phải chịu thiệt hại và mọi thứ sẽ tiếp tục hoạt động bình thường.

Khôi phục sau khi loại bỏ phần phụ thuộc

Trên thực tế, chúng ta thậm chí có thể cố tình sử dụng điều này để đạt được "Sử dụng trước rồi triển khai". Giả sử bạn muốn sử dụng tập lệnh khóa tùy chỉnh mới (hợp đồng thông minh) để bảo vệ các ô của mình. Không giống như quy trình triển khai rồi sử dụng thông thường, bạn có thể sử dụng nó mà không cần triển khai. Bạn chỉ cần đưa mã băm của tập lệnh khóa mới (triển khai mã) vào ô khóa (sử dụng mã), khi đó các ô này sẽ được khóa mới bảo vệ và có hiệu lực ngay lập tức.

Việc triển khai tập lệnh khóa thực tế mã có thể Trì hoãn cho đến khi bạn muốn mở khóa các ô này. Nếu muốn mở khóa, trước tiên bạn cần triển khai mã script trên chuỗi, sau đó gửi một giao dịch khác để mở khóa các ô này như bình thường. Sau khi ô được mở khóa, bạn có thể xóa mã đã triển khai và lấy lại CKByte đã chiếm dụng để giảm chi phí lưu trữ không cần thiết. Lợi ích bổ sung của việc sử dụng khóa trước và triển khai sau là quyền riêng tư tốt hơn: không ai biết logic của khóa mới này là gì cho đến khi bạn mở khóa.

CKB đã phát triển

Sau khi hiểu được những điểm tương đồng giữa CKB và Git cũng như ưu điểm của chúng, hãy khám phá một câu hỏi thú vị hơn:Nếu CKB là một git, chúng ta có thể sử dụng CKB để quản lý mã của CKB không?

Có! Đây là lý do tại sao một số tính năng cốt lõi của CKB như Xác minh chữ ký giao dịch [8] và Nervos DAO  [9] Tất cả đều được thực hiện dưới dạng hợp đồng thông minh. Lấy xác minh chữ ký giao dịch làm ví dụ - đây là tính năng cốt lõi của hầu hết tất cả các chuỗi khối và được mã hóa cứng bằng ngôn ngữ bản địa (ví dụ: C trong Bitcoin, Go trong go-ethereum).

Để nâng cấp blockchain, người ta phải phân phối và triển khai phiên bản phần mềm mới (soft/hard fork) trên phần lớn các nút, đòi hỏi nhiều sự phối hợp . Đối với CKB, xác minh chữ ký giao dịch có thể được nâng cấp giống như các hợp đồng thông minh khác bằng cách triển khai phiên bản mới trên chuỗi. Điều này mang lại cho CKB khả năng mở rộng lâu dài do Tezos đề xuất [10].

Chúng tôi có thể làm tốt hơn. Trên CKB,mỗi người dùng sở hữu dữ liệu của riêng mình, do đó, hợp đồng giống như thỏa thuận hai bên giữa người dùng và CKB và các cá nhân có thể đưa ra lựa chọn độc lập. Nếu bạn sử dụng hợp đồng thông qua băm mã [11], điều đó có nghĩa là "Tôi đồng ý với phiên bản hợp đồng cụ thể này". Bạn không phải lo lắng rằng một ngày nào đó các nhà phát triển sẽ nâng cấp mã hợp đồng, vì mã băm của hợp đồng mới sẽ khác và khóa/loại của bạn sẽ vẫn tham chiếu đến hợp đồng cũ thay vì hợp đồng mới. Sau khi phiên bản mới được triển khai sẽ cùng tồn tại với phiên bản cũ trong hệ thống. Nếu bạn sử dụng hợp đồng hệ thống thông qua mã băm của nó, phiên bản mới sẽ không ảnh hưởng đến bạn và bạn có thể quyết định có nên nâng cấp hay không. Nếu câu trả lời là có thì bạn có thể cập nhật tất cả các ô để sử dụng phiên bản mới. Nếu không thì không cần phải làm gì và bạn tiếp tục sử dụng phiên bản cũ.

Đây là một sự đảm bảo thân thiện dành cho những người nắm giữ không trực tuyến thường xuyên vì họ có thể đảm bảo rằng hợp đồng gắn liền với ô của họ tại thời điểm tạo sẽ không bị thay đổi. Tài sản của mọi người sẽ luôn bị khóa theo cách họ đã chỉ định khi bị khóa. Đây là sự đảm bảo cuối cùng cho người dùng SoV và là điều làm cho tài sản CKB khác biệt với các tài sản khác trên blockchain. Điều này giống như việc Bitcoin cung cấp sự bảo vệ cho người nắm giữ bằng cách "chỉ tuân theo các soft fork". Hạn chế duy nhất là bạn có nguy cơ bị “quá muộn” khi nói đến việc nâng cấp bảo mật. Vì vậy, để thuận tiện, một số người vẫn thích sử dụng phiên bản mới nhất vì họ tin tưởng vào nhóm phát triển và không cần lo lắng về việc xem xét hợp đồng và nâng cấp thủ công, trong trường hợp này họ sẽ sử dụng loại id[12] để tham khảo hợp đồng. Nói một cách đại khái, loại id tương tự như HEAD trong Git, một tham chiếu có thể cập nhật luôn trỏ đến phiên bản hiện tại. Bằng cách cung cấp cả hai tùy chọn (thông qua tham chiếu mã băm và tham chiếu id loại), chúng tôi trao lại quyền cho người dùng để chọn chiến lược nâng cấp phù hợp. Có sự lựa chọn luôn là điều tốt. Chúng ta có thể có những lựa chọn khác nhau và không ai bị buộc phải nâng cấp.

Nâng cấp tập lệnh hệ thống

Về lâu dài, CKB sẽ ngày càng trở nên trừu tượng và mô-đun hơn, đồng thời nhiều chức năng cốt lõi hơn sẽ được trích xuất và triển khai trong các hợp đồng thông minh trên chuỗi. . Ở dạng hoàn chỉnh, chúng ta có thể nâng cấp CKB mà không cần trải qua phân nhánh mềm/cứng. Mối liên kết còn thiếu là, làm thế nào để chúng ta, cộng đồng, quyết định có nên nâng cấp hợp đồng hệ thống hay không, hay mô hình quản trị của CKB là gì? Chính xác hơn, đó là cách chúng tôi quyết định nâng cấp loại id của hợp đồng hệ thống.

Ngày nay, CKB sử dụng mô hình quản trị ngoài chuỗi tương tự như Bitcoin và chúng tôi vẫn dựa vào các nhánh mềm/cứng. Để những người sử dụng tham chiếu id loại của nó kích hoạt phiên bản mới của tập lệnh hệ thống, cần phải có một hard fork để cập nhật tham chiếu id loại để trỏ đến phiên bản mới nhất, vì ô mã bị khóa bằng khóa có thể mở khóa(https://explorer.nervos.org/address/ckb1qgqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqhzeqga, kiểm tra mã băm của nó). Việc không sử dụng khóa đa chữ ký do nhóm cốt lõi kiểm soát là một lựa chọn có chủ ý, vì việc nâng cấp lên tập lệnh hệ thống phải tuân theo các quyết định quản trị do cộng đồng đưa ra.

Như chúng tôi đã nêu trong sách trắng định vị của mình, mặc dù có nhiều đề xuất thú vị nhưng chúng tôi vẫn chưa thấy một mô hình quản trị thực tế. Sau khi tìm được mô hình quản trị phù hợp, chúng tôi có thể thay thế khóa không thể mở khóa bằng "khóa quản trị" và cho phép hợp đồng thông minh của hệ thống tiến hành với sự đồng ý của cộng đồng. , chẳng hạn như kết quả bỏ phiếu. Cho đến lúc đó, chúng tôi sẽ tạm thời tuân theo mô hình quản trị ngoài chuỗi không hoàn hảo, nhưng xương sống của quản trị và phát triển CKB đã tồn tại.

Tham khảo:

[1]:https://en.wikipedia.org/wiki/Version_control

[2]:https://talk.nervos.org/t/first-class-asset/405

[3]:https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/secp256k1_helper.h#L40-L66

[4]:https://talk.nervos.org/t/rfc-swappable-signature-verification-protocol-spec/4802

[5]:https://www.researchgate.net/publication/332799463_Characterizing_Code_Clones_in_the_Ethereum_Smart_Contract_Ecosystem

[6]:https://security.cse.iitk.ac.in/sites/default/files/17111011.pdf

[7]:https://medium.com/hackernoon/what- Caused-the-latest-100-million-ethereum-bug-and-a-Detection-tool-for-similar -bugs-7b80f8ab7279
[8]:https://github.com/nervosnetwork/ckb-system-scripts/blob/master/c/secp256k1_blake160_sighash_all.c
[9]:https://github.com /nervosnetwork/ckb-system-scripts/blob/master/c/dao.c
[10]:https://tezos.com/
[11]:https://github.com/nervosnetwork/ rfcs/blob/master/rfcs/0022-transaction-structure/0022-transaction-structure.md#upgradable-script
[12]:https://docs.ckb.dev/blog/ckbscript-06

Liên kết gốc: https://mp.weixin.qq.com

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia