Hiểu khả năng lập trình của CKB từ lập trình ứng dụng Bitcoin

Odaily资深作者

2023-11-03 14:04 (UTC+8)

Bài viết này có khoảng 11786 từ, đọc toàn bộ bài viết mất khoảng 17 phút

Bài viết này bắt đầu từ việc lập trình ứng dụng của BTC UTXO, một cấu trúc bị hạn chế hơn CKB Cell và đề xuất một phương pháp để hiểu khả năng lập trình của CKB Cell.

Tóm tắt AI

Tác giả gốc: Ajian

Bản tóm tắt

Hiểu được khả năng lập trình của một hệ thống đòi hỏi chúng ta phải xác định các đặc điểm cấu trúc của hệ thống. Việc khám phá lập trình ứng dụng dựa trên tập lệnh Bitcoin giúp chúng ta hiểu cấu trúc cơ bản của CKB Cell và mô hình lập trình của nó. Không chỉ vậy, nó có thể chia nhỏ các phần tử lập trình của CKB thành các phần thích hợp và giúp chúng ta hiểu được lợi ích mà khả năng lập trình mà mỗi phần mang lại.

I. Giới thiệu

“Khả năng lập trình” là một khía cạnh mà mọi người thường quan tâm khi so sánh các hệ thống blockchain. Tuy nhiên, thường có những bất đồng về cách mô tả khả năng lập trình. Một biểu thức phổ biến là Blockchain XX hỗ trợ ngôn ngữ lập trình Turing-complete hoặc Blockchain XX hỗ trợ lập trình chung, có nghĩa là Blockchain XX ở đây có khả năng lập trình mạnh mẽ. Có một số sự thật trong hàm ý của những tuyên bố này: các hệ thống hỗ trợ lập trình Turing-complete thường dễ lập trình hơn các hệ thống không hỗ trợ. Tuy nhiên, có nhiều khía cạnh về đặc điểm cấu trúc của hệ thống hợp đồng thông minh và tuyên bố này chỉ đề cập đến một trong số đó, do đó, hiểu biết đủ sâu là chưa đủ: các nhà phát triển không thể nhận được hướng dẫn từ nó và người dùng thông thường không thể phân biệt được nó từ nó Lừa đảo.

Các đặc điểm cấu trúc của hệ thống hợp đồng thông minh bao gồm:

Hình thức biểu hiện trạng thái cơ bản (hợp đồng) (tài khoản so với đầu ra giao dịch)
Có cho phép lập trình các phép tính tùy ý hay không (thuật ngữ Tính hoàn chỉnh của Turing liên quan đến khía cạnh này)
Việc thực thi có tạo ra dữ liệu mới hay nó chỉ truyền các giá trị Boolean? (Tính toán và xác minh)
Có cho phép ghi lại trạng thái bổ sung trong hợp đồng hay không
Liệu một hợp đồng có thể truy cập trạng thái của hợp đồng khác trong quá trình thực hiện hay không

Do đó, ngoài việc “liệu các phép tính tùy ý có thể được lập trình hay không”, còn có ít nhất bốn đặc điểm sẽ ảnh hưởng đến khả năng lập trình của hệ thống hợp đồng thông minh. Thậm chí có thể nói rằng những đặc điểm khác này còn quan trọng hơn, bởi vì chúng xác định ở mức độ sâu hơn đâu là dễ thực hiện và đâu là khó thực hiện; đâu là cách thực hiện tiết kiệm hơn và đâu là cách thực hiện kém hiệu quả hơn.

Ví dụ: mọi người thường lấy Ethereum làm ví dụ về khả năng lập trình tốt, tuy nhiên, hình thức biểu hiện trạng thái cơ bản trong Ethereum là một tài khoản và rất khó để lập trình các hợp đồng ngang hàng (ví dụ: kênh thanh toán, one-to -một hợp đồng cá cược) — — Không hẳn là không thể, chỉ là vô ơn thôi. Không phải là hệ sinh thái Ethereum chưa bao giờ có các dự án cố gắng triển khai các kênh thanh toán/kênh trạng thái và có nhiều cuộc thảo luận về mặt lý thuyết, nhưng những dự án này dường như không hoạt động cho đến ngày nay - điều này rõ ràng không thể quy cho các nhà phát triển không làm việc chăm chỉ. Không phải ngẫu nhiên mà các dự án hoạt động trên Ethereum ngày nay đều mang hình thức “nhóm quỹ” chứ không phải là “hợp đồng điểm-điểm”. Tương tự, mọi người có thể rất hài lòng với khả năng lập trình của Ethereum, nhưng khi nói đến việc đạt được sự trừu tượng hóa tài khoản (cũng có thể hiểu là sự khái quát hóa của khái niệm ví), mô hình tài khoản vốn đã thiếu sót.

Tương tự như vậy, việc khám phá khả năng lập trình của CKB cũng đòi hỏi chúng ta phải hiểu các đặc điểm cấu trúc của hệ thống hợp đồng thông minh CKB ở những khía cạnh này. Những gì chúng ta đã biết là CKB cho phép lập trình các phép tính tùy ý, cho phép ghi lại các trạng thái bổ sung trong hợp đồng và cho phép một hợp đồng truy cập trạng thái của hợp đồng khác trong quá trình thực hiện. Tuy nhiên, hình thức hợp đồng của nó là đầu ra của giao dịch (được gọi là Ô), điều này làm cho nó khác biệt về cơ bản với Ethereum. Do đó, việc hiểu hệ thống hợp đồng thông minh Ethereum và các phiên bản hợp đồng trong đó không giúp chúng tôi hiểu cách CKB triển khai các tính năng cấu trúc này cũng như không giúp chúng tôi hiểu khả năng lập trình của CKB.

May mắn thay, các hợp đồng thông minh trên Bitcoin dường như cung cấp nền tảng tốt nhất để chúng ta hiểu được khả năng lập trình của CKB. Điều này không chỉ bởi vì hình thức biểu hiện trạng thái cơ bản của Bitcoin cũng là đầu ra của một giao dịch (được gọi là “UTXO”), mà còn bởi vì, với sự trợ giúp của khái niệm “giao ước” do cộng đồng Bitcoin đề xuất, chúng ta có thể hiểu rằng CKB có các đặc điểm cấu trúc ở trên và mức tăng khả năng lập trình mang lại bằng cách chia hiệu ứng cuối cùng thành nhiều phần một cách thích hợp và xác định từng phần một.

2. CKB vs BTC: Còn gì nữa?

(1) Cấu trúc cơ bản

Là hình thức cơ bản của biểu thức trạng thái Bitcoin, UTXO của Bitcoin (“Đầu ra giao dịch chưa chi tiêu”) có hai trường:

Số tiền tính bằng Satoshi đại diện cho giá trị Bitcoin của UTXO;
Khóa công khai của tập lệnh, còn được gọi là tập lệnh khóa, thể hiện các điều kiện cần phải đáp ứng để chi tiêu tiền, tức là chương trình hợp đồng thông minh đặt ra các điều kiện để mở khóa tiền.

So với các hệ thống hợp đồng thông minh sau này, tập lệnh Bitcoin khá hạn chế:

Nó không cho phép lập trình các phép tính tùy ý; chỉ có một vài phép tính thực tế có thể được sử dụng để xác minh (kiểm tra chữ ký, kiểm tra tiền băm, kiểm tra thời gian)
Nó không cho phép ghi lại các trạng thái bổ sung trong hợp đồng; (ví dụ: bạn không thể sử dụng tập lệnh để giới hạn tỷ lệ/giới hạn của một lần chi tiêu; bạn cũng không thể ẩn mã thông báo trong đó)
Nó cũng không cho phép truy cập vào trạng thái của hợp đồng khác trong quá trình thực thi (mỗi tập lệnh là một vũ trụ độc lập và không phụ thuộc lẫn nhau).

Mặc dù loại tập lệnh này còn hạn chế nhưng nó không thiếu khả năng lập trình các ứng dụng tuyệt vời và nó cũng là cơ sở để chúng tôi khám phá khả năng lập trình CKB. Sau này sẽ có một phần đặc biệt để giới thiệu hai ví dụ về lập trình tập lệnh Bitcoin.

Ngược lại, đơn vị trạng thái của CKB được gọi là Ô và có bốn trường:

Dung lượng, tương tự như lượng UTXO, biểu thị kích thước không gian mà Ô có thể chiếm, tính bằng byte;
Lock Script, một script public key tương tự như UTXO, xác định quyền sở hữu của Cell; chỉ khi dữ liệu được cung cấp có thể vượt qua Lock Script thì Cell mới có thể được “cập nhật” (cũng có thể nói là giải phóng Cell và sử dụng các Capacities này để đúc các ô mới);
Dữ liệu, dữ liệu, bất kỳ dữ liệu nào, dung lượng của nó bị giới hạn bởi Dung lượng;
Type Script, một script tùy chọn, được sử dụng để đặt điều kiện cho việc cập nhật Dữ liệu.

Ngoài ra Lock Script và Type Script còn có thể lập trình các phép tính tùy ý. Bạn có thể lập trình bất kỳ thuật toán xác minh chữ ký nào, bạn cũng có thể lập trình bất kỳ kiểm tra tiền hình ảnh nào cho bất kỳ thuật toán băm nào, v.v.

Bạn đọc có thể dễ dàng nhận thấy sự cải thiện về khả năng lập trình của Cell so với UTXO:

Cell có thể lập trình các phép tính tùy ý thay vì chỉ một số phép tính nhất định, việc xác minh quyền sở hữu sẽ linh hoạt hơn;
Do các trường Dữ liệu và Tập lệnh Loại, Ô có thể ghi lại trạng thái bổ sung; điều này cho phép Ô mang cái gọi là UDT (Mã thông báo do người dùng xác định).

Kết hợp với cấu trúc “đầu ra giao dịch” của chính Cell, lợi ích mà 2 điểm này có thể mang lại là rất rất lớn, tuy nhiên chỉ từ mô tả trên thì chúng ta vẫn chưa biết Cell thực hiện “một hợp đồng truy cập vào một hợp đồng khác trong thời gian chạy như thế nào”. trạng thái của. Để làm được điều này, chúng ta cần chuyển sang một khái niệm mà cộng đồng Bitcoin đã thảo luận từ lâu: “giao ước”.

(2) Hạn chế và xem xét nội tâm

Mục đích ban đầu của việc hạn chế là giới hạn số tiền có thể được chi tiêu. Trên Bitcoin hiện tại (vẫn chưa triển khai bất kỳ đề xuất ràng buộc nào), khi quỹ được mở khóa, nó có thể được chi tiêu ở bất cứ đâu (có thể trả cho bất kỳ khóa công khai tập lệnh nào). Nhưng ý tưởng của điều khoản hạn chế là nó có thể bị hạn chế theo một cách nào đó để chỉ được chi tiêu ở một số nơi nhất định. Ví dụ: một UTXO nhất định chỉ có thể được chi tiêu bởi một giao dịch nhất định. Sau đó, ngay cả khi ai đó có thể cung cấp chữ ký đối với UTXO này, số tiền có thể chi vào việc gì cũng đã được xác định theo thỏa thuận. Chức năng này có vẻ hơi lạ nhưng nó có thể tạo ra một số ứng dụng thú vị, sẽ được giới thiệu trong phần dành riêng sau. Điều quan trọng là nó là chìa khóa để chúng ta hiểu sâu hơn về khả năng lập trình của CKB.

Rusty Russell đã chỉ ra một cách chính xác rằng điều khoản hạn chế có thể được hiểu là khả năng xem xét nội tâm của giao dịch, tức là khi một UTXO A được giao dịch B sử dụng, người vận hành tập lệnh có thể đọc một phần (hoặc tất cả) của giao dịch B. , rồi kiểm tra xem chúng có khớp với các tham số mà tập lệnh yêu cầu trước hay không. Ví dụ: liệu khóa chung của tập lệnh của đầu ra đầu tiên của giao dịch A có nhất quán với khóa chung của tập lệnh của UTXO A hay không (đây là ý nghĩa ban đầu của mệnh đề hạn chế).

Những độc giả quan tâm sẽ nhận ra rằng nếu có đầy đủ khả năng xem xét nội tâm thì đầu vào của một giao dịch có thể đọc trạng thái của một đầu vào khác của cùng một giao dịch. Điều này hiện thực hóa những gì chúng tôi đã nói trước đó một hợp đồng truy cập vào một đầu vào khác trong thời gian chạy. Trạng thái của hợp đồng khả năng. Trên thực tế, CKB Cell được thiết kế chính xác theo cách này.

Dựa trên điều này, chúng ta có thể chia khả năng xem xét nội tâm hoàn chỉnh này thành bốn tình huống:

Lock Script đọc các Lock Script khác (đầu vào và đầu ra)
Tập lệnh khóa đọc Tập lệnh loại (đầu vào và đầu ra) khác (và Dữ liệu)
Type Script đọc các tập lệnh khóa (đầu vào và đầu ra) khác
Loại Script đọc khác (đầu vào và đầu ra) Loại Script (và Dữ liệu)

Điều này cho phép chúng tôi phân tích vai trò của khả năng xem xét nội tâm của từng bộ phận trong các tình huống ứng dụng khác nhau theo các giả định nhất định (sự phân chia chức năng của Lock Script và Type Script), tức là phân tích những lợi ích về khả năng lập trình mà mỗi bộ phận mang lại cho chúng ta.

Trong hai chương sau, chúng ta sẽ xem xét cách lập trình tập lệnh Bitcoin hiện tại (không có đề xuất hạn chế) và các chức năng mà đề xuất hạn chế dự kiến sẽ triển khai, để hiểu cụ thể cách CKB Cell được lập trình và thực hiện tốt hơn.

3. Lập trình tập lệnh Bitcoin

Phần này sẽ sử dụng Kênh Lightning/Mạng Lightning và Hợp đồng nhật ký kín đáo (DLC) làm ví dụ về lập trình ứng dụng dựa trên tập lệnh Bitcoin. Trước khi tiếp tục, chúng ta cần hiểu hai khái niệm.

(1) OP_IF và giao dịch cam kết

Khái niệm đầu tiên là các opcode kiểm soát quy trình trong các tập lệnh Bitcoin, chẳng hạn như: OP_IF, OP_ELSE. Các opcode này không khác gì IF trong lập trình máy tính, chức năng của chúng là thực thi các câu lệnh khác nhau dựa trên các đầu vào khác nhau. Trong ngữ cảnh của các tập lệnh Bitcoin, điều này có nghĩa là chúng tôi có thể thiết lập nhiều đường dẫn mở khóa để lấy tiền; kết hợp với tính năng khóa thời gian, điều này có nghĩa là chúng tôi có thể chỉ định mức độ ưu tiên cho các hành động.

Lấy Hợp đồng khóa thời gian băm (HTLC) nổi tiếng làm ví dụ, tập lệnh này được dịch sang tiếng địa phương là:

Ngoài ra, Bob có thể tiết lộ hình ảnh gốc đằng sau một giá trị băm H nhất định và sau đó đưa ra chữ ký của mình để chi tiêu số tiền.
Ngoài ra, Alice có thể chi tiêu số tiền bằng chữ ký của mình sau một khoảng thời gian T

Hiệu ứng hoặc... hoặc... này đạt được thông qua các mã điều khiển quá trình.

Ưu điểm nổi bật nhất của HTLC là nó có thể kết hợp nhiều hoạt động lại với nhau và đạt được tính nguyên tử. Ví dụ: nếu Alice muốn trao đổi BTC lấy CKB với Bob, trước tiên Bob có thể đưa ra giá trị băm và tạo HTLC trên Mạng Nervos; sau đó Alice tạo HTLC trên Bitcoin bằng cách sử dụng cùng một giá trị băm. Ngoài ra, Bob lấy BTC do Alice trả bằng Bitcoin và cũng tiết lộ hình ảnh gốc, cho phép Alice lấy CKB trên Mạng Nervos. Hoặc Bob không tiết lộ hình ảnh gốc, cả hai hợp đồng đều hết hạn và cả Alice và Bob đều có thể lấy lại số tiền họ đã đầu tư.

Sau khi kích hoạt soft fork Taproot, tính năng nhiều đường dẫn mở khóa này đã được tăng cường hơn nữa nhờ sự ra đời của MAST (Cây cú pháp trừu tượng Merkle): chúng ta có thể biến đường dẫn mở khóa thành một lá trên cây Merkle, Mỗi lá là độc lập, vì vậy không cần phải sử dụng các mã điều khiển luồng như vậy; và vì việc tiết lộ một đường dẫn không yêu cầu hiển thị các đường dẫn khác, chúng ta có thể thêm số lượng lớn hơn các đường dẫn đã mở khóa vào đầu ra mà không phải lo lắng về vấn đề kinh tế.

Khái niệm thứ hai là “giao dịch cam kết”. Ý tưởng của giao dịch đã cam kết là, trong một số trường hợp nhất định, giao dịch Bitcoin hợp lệ vẫn đúng và có tính ràng buộc ngay cả khi nó không được blockchain xác nhận.

Ví dụ: Alice và Bob cùng sở hữu một UTXO và UTXO này yêu cầu cả hai chữ ký của họ phải được sử dụng. Lúc này, Alice xây dựng một giao dịch để chi tiêu, chuyển 60% giá trị cho Bob và giá trị còn lại cho chính cô ấy; Alice cung cấp chữ ký của chính mình cho giao dịch và gửi cho Bob. Sau đó, đối với Bob, không cần phải phát giao dịch lên mạng Bitcoin cũng như không cần giao dịch được blockchain xác nhận. Hiệu quả thanh toán của giao dịch cũng là có thật và đáng tin cậy. Vì Alice không thể tự mình chi tiêu UTXO này (và do đó không thể chi tiêu nhiều lần) và vì chữ ký do Alice cung cấp là hợp lệ nên Bob có thể thêm chữ ký của chính mình bất kỳ lúc nào và sau đó thực hiện giao dịch để rút tiền thanh toán. Nói cách khác, Alice đã cung cấp cho Bob một cam kết đáng tin cậy thông qua giao dịch hợp lệ (không phải trên chuỗi) này.

Giao dịch cam kết là một khái niệm cốt lõi trong lập trình ứng dụng Bitcoin. Như đã đề cập trước đó, hợp đồng của Bitcoin dựa trên xác minh, không trạng thái và không cho phép truy cập chéo; tuy nhiên, nếu hợp đồng không mang trạng thái thì các trạng thái này được lưu trữ ở đâu và làm cách nào để hợp đồng có thể được nâng cao một cách an toàn (trạng thái đã thay đổi)? Các giao dịch cam kết đưa ra câu trả lời thẳng thắn: trạng thái của hợp đồng có thể được thể hiện dưới dạng giao dịch, để những người tham gia hợp đồng có thể tự lưu các trạng thái mà không cần phải hiển thị chúng trên blockchain; vấn đề thay đổi trạng thái hợp đồng cũng có thể được chuyển đổi thành vấn đề làm thế nào để cập nhật các giao dịch đã cam kết một cách an toàn; ngoài ra, nếu chúng ta lo lắng về nguy cơ khi ký kết hợp đồng (ví dụ: ký hợp đồng yêu cầu hai bên phải ký trước khi chi tiêu thì chúng ta sẽ gặp rủi ro là bên kia không khi đó, chỉ cần tạo và ký các giao dịch cam kết chi tiêu hợp đồng trước thời hạn sẽ loại bỏ rủi ro và mất niềm tin vào những người tham gia khác.

(2) Kênh Lightning và Mạng Lightning

Kênh Lightning là hợp đồng một-một, trong đó hai bên có thể thanh toán cho nhau không giới hạn số lần mà không cần bất kỳ khoản thanh toán nào được xác nhận bởi blockchain. Như bạn có thể mong đợi, nó sử dụng các giao dịch hứa hẹn.

Trong phần giải thích về giao dịch cam kết, chúng tôi đã giới thiệu kênh thanh toán. Tuy nhiên, hợp đồng này chỉ sử dụng 2 trong 2 chữ ký nên chỉ có thể thanh toán một chiều. Nghĩa là, Alice luôn trả tiền cho Bob hoặc Bob trả tiền cho Alice cho đến khi hết số dư trong hợp đồng. Nếu là thanh toán hai chiều, nghĩa là sau một lần cập nhật trạng thái nhất định, số dư của một bên có thể ít hơn trước, nhưng anh ta có giao dịch cam kết cuối cùng được bên kia ký - Có cách nào để ngăn anh ta lại không? phát sóng giao dịch cam kết cũ để TA chỉ phát sóng giao dịch cam kết mới nhất?

Giải pháp của Lightning Channel cho vấn đề này được gọi là “LN-Penalty”. Bây giờ, giả sử rằng Alice và Bob mỗi người có 5 BTC trong một kênh; bây giờ Alice muốn trả cho Bob 1 BTC, vì vậy cô ấy ký một giao dịch cam kết như thế này và gửi nó cho Bob:

Nhập số 0, 10 BTC:
Đầu ra đa chữ ký 2 trên 2 của Alie-Bob (tức là hợp đồng kênh)

Đầu ra số 0, 4 BTC:
Chữ ký đơn của Alice

Đầu ra số 1, 6 BTC:
Hoặc
Khóa công khai tạm thời số 1 chung của Alice-Bob
Hoặc
Khóa thời gian T 1, chữ ký đơn Bob

Bob cũng ký một giao dịch cam kết (tương ứng với giao dịch trên) và gửi cho Alice:

Nhập số 0, 10 BTC:
Đầu ra đa chữ ký 2 trên 2 của Alie-Bob (tức là hợp đồng kênh)

Đầu ra số 0, 6 BTC:
Chữ ký đơn của Bob

Đầu ra số 1, 4 BTC:
Hoặc
Bob-Alice chung khóa công khai tạm thời số 1 chữ ký đơn
Hoặc
Khóa thời gian T 1, chữ ký đơn của Alice

Thủ thuật ở đây là khóa chung tạm thời chung, được tạo bằng khóa chung của chính mình và khóa chung do bên kia cung cấp. Ví dụ: khóa chung tạm thời chung của Alice-Bob là Alice sử dụng một trong các khóa chung của cô ấy . , và một khóa công khai do Bob cung cấp, mỗi khóa được nhân với một giá trị băm rồi cộng lại với nhau. Khi khóa chung như vậy được tạo ra, không ai biết khóa riêng của nó. Tuy nhiên, nếu Bob cho Alice biết khóa riêng của khóa chung mà anh ấy cung cấp, Alice có thể tính khóa riêng của khóa chung tạm thời. ——Đây chính là chìa khóa cho khả năng của Lightning Channel trong việc hoàn tác trạng thái cũ.

Lần tiếp theo khi cả hai bên muốn cập nhật trạng thái kênh (bắt đầu thanh toán), hai bên sẽ trao đổi khóa riêng của khóa chung tạm thời được cấp cho bên kia ở vòng trước. Bằng cách này, những người tham gia không còn dám quảng bá giao dịch cam kết cuối cùng mà họ nhận được: đầu ra của giao dịch cam kết này gán giá trị cho chính họ có hai đường dẫn và khóa riêng của đường dẫn khóa công khai tạm thời đã được bên kia biết; vì vậy Sau khi giao dịch cam kết cũ được phát sóng, bên kia có thể ngay lập tức sử dụng khóa riêng tạm thời chung này để lấy đi tất cả số tiền trong đầu ra này. – Đây chính là ý nghĩa của “LN-Penalty”.

Cụ thể, trình tự tương tác là: bên bắt đầu thanh toán trước tiên yêu cầu khóa công khai tạm thời mới từ bên kia, sau đó xây dựng một giao dịch cam kết mới và giao nó cho bên kia; bên nhận được giao dịch cam kết sẽ tiếp xúc với bên kia đã làm gì ở vòng trước. Khóa riêng của khóa chung tạm thời đã cho. Trình tự tương tác này đảm bảo rằng người tham gia luôn nhận được các giao dịch cam kết mới trước tiên, sau đó vô hiệu hóa các giao dịch cam kết mà họ đã nhận được ở vòng trước, do đó không cần phải tin cậy.

Tóm lại, các thiết kế chính của kênh sét là:

Hai bên luôn sử dụng các giao dịch cam kết để thể hiện tình trạng nội bộ của hợp đồng và sử dụng những thay đổi về số tiền để thể hiện các khoản thanh toán;
Các giao dịch cam kết luôn có cùng chi phí đầu vào (đầu vào yêu cầu cả hai bên cung cấp chữ ký cùng lúc), vì vậy tất cả các giao dịch cam kết đều cạnh tranh với nhau và cuối cùng chỉ có một giao dịch có thể được xác nhận bởi blockchain;
Hai người tham gia không ký cùng một giao dịch cam kết (mặc dù họ được ghép đôi), thay vào đó, họ luôn ký một giao dịch có lợi hơn cho mình, nói cách khác, giao dịch cam kết mà người tham gia nhận được luôn là giao dịch có lợi hơn đối với họ bất lợi cho chính mình;
Nhược điểm này thể hiện ở chỗ đầu ra gán giá trị cho chính nó có hai đường dẫn mở khóa: một đường có thể được mở khóa bằng chữ ký của chính bạn, nhưng bạn cần đợi một lúc; và đường còn lại sử dụng khóa chung của bên kia, chỉ có thể được mở khóa nếu Khóa riêng tạm thời của riêng bạn chỉ được bảo vệ nếu nó không bị lộ;
Trong mỗi lần thanh toán, cả hai bên trao đổi một giao dịch cam kết mới lấy khóa riêng tạm thời được bên kia sử dụng ở vòng trước, do đó, bên đã giao khóa riêng tạm thời không còn dám quảng bá giao dịch cam kết cũ. giao dịch cam kết cuối cùng bị hủy và trạng thái của hợp đồng được cập nhật; (Trên thực tế, các giao dịch đã cam kết này đều là các giao dịch hợp lệ và có thể được phát lên blockchain, nhưng những người tham gia buộc phải trừng phạt chúng. Không dám phát sóng nữa không)
Một trong hai bên có thể thoát khỏi hợp đồng bất cứ lúc nào với giao dịch đã cam kết đã được bên kia ký kết, tuy nhiên, nếu cả hai bên đều sẵn sàng hợp tác thì có thể ký giao dịch mới để hai bên có thể lấy lại tiền ngay.

Cuối cùng, vì HTLC cũng có thể được đưa vào các giao dịch cam kết nên các kênh Lightning cũng có thể chuyển tiếp các khoản thanh toán. Giả sử rằng Alice có thể tìm thấy một đường dẫn bao gồm các kênh sét được kết nối qua lại và tiếp cận Daniel, thì có thể đạt được thanh toán nhiều bước không cần tin cậy mà không cần mở kênh với Daniel. Đây là Mạng Lightning:

Alice -- HTLC --> Bob -- HTLC --> Carol -- HTLC --> Daniel
Alice <-- ảnh gốc-- Bob <-- ảnh gốc-- Carol <- ảnh gốc-- Daniel

Khi Alice phát hiện ra một đường dẫn như vậy và muốn trả tiền cho Daniel, cô ấy yêu cầu một giá trị băm từ Daniel để xây dựng một HTLC cho Bob và nhắc Bob chuyển tiếp tin nhắn đến Carol và cung cấp cùng một HTLC; tin nhắn cũng nhắc Carol chuyển tiếp tin nhắn cho Daniel và cung cấp HTLC tương tự. Khi tin tức đến tai Daniel, anh tiết lộ hình ảnh gốc cho Carol, từ đó nhận được giá trị của HTLC và cập nhật trạng thái hợp đồng; Carol cũng làm như vậy, nhận khoản thanh toán của Bob và cập nhật trạng thái kênh; cuối cùng, Bob tiết lộ hình ảnh gốc và cập nhật trạng thái cho Alice. Do đặc điểm của HTLC, chuỗi thanh toán này cùng thành công hoặc thất bại cùng nhau nên không có sự tin cậy.

Lightning Network bao gồm các kênh lần lượt và mỗi kênh (hợp đồng) độc lập với nhau. Điều này có nghĩa là Alice chỉ cần biết điều gì đã xảy ra trong kênh riêng của cô ấy với Bob và không cần quan tâm đến số lượng tương tác đã xảy ra trong kênh của người khác, cũng như loại tiền tệ mà những tương tác này sử dụng hoặc thậm chí liệu chúng có thật hay không bằng cách sử dụng các kênh) .

Khả năng mở rộng của Lightning Network không chỉ được phản ánh ở chỗ tốc độ thanh toán trong kênh Lightning chỉ bị giới hạn bởi khoản đầu tư tài nguyên phần cứng của cả hai bên mà còn do khả năng lưu trữ phi tập trung của các trạng thái, một nút duy nhất có thể tận dụng đòn bẩy lớn nhất với chi phí thấp nhất.

(3) Hợp đồng nhật ký thận trọng

Hợp đồng nhật ký kín đáo (DLC) sử dụng kỹ thuật mã hóa được gọi là chữ ký bộ chuyển đổi để cho phép các tập lệnh Bitcoin lập trình các hợp đồng tài chính phụ thuộc vào các sự kiện bên ngoài.

Chữ ký của bộ điều hợp cho phép chữ ký chỉ có hiệu lực sau khi thêm khóa riêng. Lấy chữ ký Schnorr làm ví dụ, dạng chuẩn của chữ ký Schnorr là (R, s), trong đó:

R = r.G
# Giá trị nonce r được sử dụng trong chữ ký được nhân với điểm tạo đường cong elip, cũng có thể nói là khóa chung của r
s = r + Hash(R || m || P) * p
# p là khóa riêng của chữ ký, P là khóa chung
Xác minh chữ ký có nghĩa là xác minh sG = rG + Hash(R -- m -- P) * pG = R + Hash(R -- m -- P) * PK

Giả sử tôi được cấp một cặp dữ liệu (R, s) trong đó:

R = R 1 + R 2 = r 1.G + r 2.G
s' = r 1 + Hash(R || m || P) * p

Rõ ràng đây không phải là chữ ký Schnorr hợp lệ và nó không thể vượt qua công thức xác minh chữ ký, tuy nhiên tôi có thể chứng minh cho người xác minh rằng chỉ cần TA biết khóa riêng r 2 của R 2 thì nó có thể biến thành chữ ký hợp lệ . :

s'.G + R 2 = R 1 + Hash(R || m || P) * P + R 2 = R + Hash(R || m || P) * P

Chữ ký bộ điều hợp cho phép tính hợp lệ của chữ ký phụ thuộc vào dữ liệu bí mật và có thể kiểm chứng được. Nhưng điều này có liên quan gì đến hợp đồng tài chính?

Giả sử Alice và Bob muốn đặt cược vào kết quả của một trận bóng đá. Alice và Bob lần lượt đặt cược vào Green Goblin và Alina với mức đặt cược là 1 BTC. Hơn nữa, trang web bình luận bóng đá Carol hứa hẹn sẽ sử dụng nonce R_c để xuất bản chữ ký s_c_i của kết quả khi kết quả trận đấu bóng đá được công bố.

Có thể thấy, có 3 kết quả có thể xảy ra (vì vậy chữ ký của Carol có 3 khả năng):

- Yêu tinh xanh thắng và Alice thắng 1 BTC

- Alina thắng và Bob thắng 1 BTC

- Trong trường hợp hòa, quỹ của hai người sẽ được trả về lộ trình ban đầu.

Để làm điều này, cả hai tạo ra một giao dịch cam kết cho mỗi kết quả. Ví dụ: giao dịch hứa hẹn mà họ đã tạo cho kết quả đầu tiên trông như thế này:

Nhập số 0, 2 BTC:
Đầu ra đa chữ ký 2 trên 2 của Alie-Bob (tức là hợp đồng cá cược)

Đầu ra số 0, 2 BTC:
Chữ ký đơn của Alice

Tuy nhiên, chữ ký do Alice và Bob tạo cho giao dịch này không phải là (R, s), mà là chữ ký của bộ điều hợp (R, s); nghĩa là, chữ ký do cả hai bên cung cấp cho nhau không thể được sử dụng trực tiếp để mở khóa hợp đồng. , và một giá trị bí mật phải được tiết lộ. Giá trị bí mật này chính xác là hình ảnh gốc của s_c_ 1.G, là chữ ký của Carol! Bởi vì giá trị nonce của chữ ký Carol đã được xác định (đó là R_c), s_c_ 1.G có thể được xây dựng (s_c_ 1.G = R_c + Hash(R_c -- The Green Goblin won -- PK_c) * PK_c) .

Khi kết quả được công bố, giả sử Green Goblin thắng, Carol sẽ đưa ra chữ ký (R_c, s_c_ 1), khi đó cả Alice và Bob đều có thể hoàn thiện chữ ký adapter của đối phương và thêm chữ ký của chính mình để biến giao dịch trên thành giao dịch hợp lệ là phát sóng lên mạng và kích hoạt hiệu ứng giải quyết. Nhưng nếu Goblin không thắng, Carol sẽ không phát hành s_c_ 1 và thỏa thuận đã cam kết sẽ không phải là thỏa thuận hợp lệ.

Bằng cách tương tự, điều tương tự cũng đúng với hai giao dịch còn lại. Bằng cách này, Alice và Bob khiến việc thực hiện hợp đồng này phụ thuộc vào các sự kiện bên ngoài (nói chính xác là dựa vào việc phát đi các sự kiện bên ngoài của máy xác nhận dưới dạng chữ ký) mà không tin tưởng vào đối tác. Các hợp đồng tài chính lớn và nhỏ, chẳng hạn như hợp đồng tương lai và quyền chọn, đều có thể được thực hiện theo cách này.

So với các hình thức triển khai khác, đặc điểm lớn nhất của hợp đồng nhật ký thận trọng là quyền riêng tư của nó: (1) Alice và Bob không cần nói với Carol rằng họ đang sử dụng dữ liệu của Carol, điều này hoàn toàn không ảnh hưởng đến việc thực hiện hợp đồng; (2) Quan sát trực tuyến Bất kỳ ai (kể cả Carol) đều không thể xác định dịch vụ của trang web nào họ đang sử dụng bằng cách thực hiện giao dịch thông qua hợp đồng của Alice và Bob hoặc thậm chí xác định rằng hợp đồng của họ là hợp đồng cá cược (chứ không phải là kênh sét).

4. Giới thiệu việc áp dụng điều khoản hạn chế

(1) OP_CTV và kiểm soát tắc nghẽn

Các nhà phát triển trong cộng đồng Bitcoin đã đưa ra nhiều đề xuất khác nhau có thể được coi là hạn chế. Theo quan điểm hiện tại, đề xuất nổi tiếng nhất là OP_CHECKTEMPLATEVERIFY (OP_CTV). Khái niệm của nó tương đối đơn giản nhưng vẫn giữ được tính linh hoạt đáng kể nên được cộng đồng Bitcoin ủng hộ sự đơn giản hoan nghênh. Ý tưởng của OP_CTV là cam kết một giá trị băm trong tập lệnh để hạn chế rằng số tiền chỉ có thể được chi tiêu bởi giao dịch được biểu thị bằng giá trị băm; giá trị băm này cam kết đầu ra của giao dịch và hầu hết các trường, nhưng không cam kết Đầu vào của giao dịch chỉ cam kết về số lượng đầu vào.

Kiểm soát tắc nghẽn là một ví dụ điển hình về các đặc điểm của OP_CTV. Kịch bản ứng dụng cơ bản của nó là giúp một số lượng lớn người dùng rút khỏi sàn giao dịch (môi trường đòi hỏi sự tin cậy) vào nhóm vốn; vì nhóm vốn này sử dụng OP_CTV để lên kế hoạch cho các phương thức chi tiêu trong tương lai, nên nó có thể đảm bảo rằng người dùng có thể thoát khỏi quỹ tín thác này- môi trường tự do. Quỹ quỹ không cần sự giúp đỡ của bất kỳ ai và vì quỹ quỹ này chỉ xuất hiện dưới dạng UTXO nên tránh phải trả một lượng lớn phí xử lý khi nhu cầu giao dịch trên chuỗi cao (giảm từ n đầu ra xuống 1 đầu ra ; cũng từ n giao dịch Giao dịch giảm xuống còn 1 giao dịch). Người dùng trong nhóm có thể chờ cơ hội và sau đó rút khỏi nhóm.

Giả sử Alice, Bob và Carol muốn rút lần lượt 5 BTC, 3 BTC và 2 BTC từ sàn giao dịch. Sau đó, sàn giao dịch có thể tạo đầu ra với 3 nhánh OP_CTV với số lượng 10 BTC. Giả sử Alice muốn rút tiền, cô ấy có thể sử dụng nhánh 1; giao dịch được biểu thị bằng giá trị băm được OP_CTV của nhánh này sử dụng sẽ tạo thành hai đầu ra, một đầu ra là phân bổ 5 BTC cho Alice; đầu ra còn lại là quỹ quỹ, Đồng thời sử dụng OP_CTV để cam kết giao dịch chỉ cho phép Bob rút 3 BTC và gửi 2 BTC còn lại cho Carol.

Điều tương tự cũng áp dụng nếu Bob hoặc Carol muốn rút tiền. Khi họ rút tiền, họ sẽ chỉ có thể sử dụng các giao dịch có thể vượt qua séc OP_CTV tương ứng, nghĩa là họ chỉ có thể tự thanh toán số tiền tương ứng và không thể rút tiền theo ý muốn; số tiền còn lại sẽ vào quỹ quỹ được khóa bằng cách sử dụng OP_CTV, do đó đảm bảo rằng bất kể thứ tự rút tiền của người dùng là gì, những người dùng còn lại đều có thể rút khỏi nhóm một cách đáng tin cậy.

Nói một cách trừu tượng, vai trò của OP_CTV ở đây là lập kế hoạch cho đường đi cho hợp đồng đến hết vòng đời, để hợp đồng vốn ở đây có thể duy trì thuộc tính thoát ra không cần tin cậy bất kể nó đi theo con đường nào hoặc đạt đến trạng thái nào .

Loại OP_CTV này còn có một công dụng rất thú vị: kênh thanh toán ẩn một chiều. Giả sử Alice hình thành một quỹ quỹ như vậy và đảm bảo rằng tiền có thể được rút một cách đáng tin cậy đến đầu ra có tập lệnh sau:

Ngoài ra, Alice và Bob cùng nhau tiêu số tiền đó
Hoặc sau một thời gian, Alice có thể ở một mình

Nếu Alice không tiết lộ nó cho Bob, Bob sẽ không biết rằng đầu ra đó tồn tại; một khi Alice tiết lộ nó cho Bob, Bob có thể sử dụng đầu ra này làm kênh thanh toán một chiều có giới hạn thời gian và Alice có thể ngay lập tức sử dụng tiền để Bob Pay mà không cần phải chờ xác nhận trên blockchain. Bob chỉ cần để Alice thực hiện giao dịch cam kết của anh ấy trên chuỗi trước khi Alice có thể tự mình chi tiêu.

(2) OP_Vault và an toàn

OP_VAULT là một đề xuất hạn chế được thiết kế đặc biệt để xây dựng hầm.

Hợp đồng vault được thiết kế để trở thành một hình thức tự quản lý an toàn hơn và tiên tiến hơn. Mặc dù hợp đồng đa chữ ký hiện tại có thể tránh được điểm lỗi duy nhất của một khóa riêng tư, nhưng nếu kẻ tấn công lấy được số lượng khóa riêng tư ngưỡng, chủ sở hữu ví sẽ không thể làm bất cứ điều gì. Vault hy vọng sẽ áp đặt một giới hạn chi tiêu duy nhất cho số tiền; đồng thời, khi rút tiền bằng các tuyến đường thông thường, hoạt động rút tiền sẽ thực thi một khoảng thời gian chờ đợi; trong thời gian chờ đợi, hoạt động rút tiền có thể bị gián đoạn do ví khẩn cấp hoạt động phục hồi. Ngay cả khi hợp đồng đó bị vi phạm, chủ sở hữu ví có thể bắt đầu các biện pháp đối phó (sử dụng nhánh khôi phục khẩn cấp).

Về mặt lý thuyết, OP_CTV cũng có thể lập trình một hợp đồng như vậy, nhưng có nhiều bất tiện, một trong số đó là phí xử lý: khi cam kết giao dịch, nó cũng cam kết phí xử lý sẽ được thanh toán cho giao dịch. Với mục đích của hợp đồng như vậy, thời gian từ khi thiết lập hợp đồng đến khi rút tiền phải rất dài, khiến việc dự đoán mức phí phù hợp là gần như không thể. Mặc dù OP_CTV không giới hạn đầu vào, do đó bạn có thể tăng phí xử lý bằng cách tăng đầu vào, nhưng tất cả đầu vào được cung cấp sẽ trở thành phí xử lý, vì vậy nó không thực tế; cách khác là CPFP, nghĩa là bằng cách chi tiêu số tiền đã rút, trong Phí được cung cấp cho các giao dịch mới. Ngoài ra, việc sử dụng OP_CTV cũng có nghĩa là hợp đồng an toàn như vậy không thể rút tiền theo đợt (và tất nhiên không thể khôi phục lại theo đợt).

Đề xuất OP_VAULT cố gắng giải quyết những vấn đề này bằng cách đề xuất các mã opcode mới (OP_VAULT và OP_UNVAULT). OP_UNVAULT được thiết kế để khôi phục hàng loạt, vì vậy hiện tại chúng tôi sẽ không đề cập đến nó. Hành động của OP_VAULT giống như thế này: khi chúng ta đặt nó trên một nhánh của cây tập lệnh, nó có thể được sử dụng để hứa hẹn một opcode có thể thực hiện được (chẳng hạn như OP_CTV) mà không cần tham số cụ thể; khi chi tiêu nhánh này, Giao dịch có thể chuyển các tham số cụ thể, nhưng các nhánh khác không thể thay đổi. Do đó, không cần đặt phí xử lý và có thể đặt phí xử lý khi chi tiêu nhánh này; giả sử nhánh này cũng có khóa thời gian thì sẽ thực thi khóa thời gian; cuối cùng, vì nó chỉ có thể thay đổi địa điểm ở vị trí của Chi nhánh, các nhánh khác trên cây tập lệnh mới (bao gồm cả nhánh khôi phục khẩn cấp) sẽ không bị thay đổi, do đó cho phép chúng tôi làm gián đoạn hoạt động rút tiền như vậy.

Ngoài ra, có hai điểm đáng nói: (1) Opcode OP_VAULT hoạt động tương tự như một đề xuất hạn chế khác: OP_TLUV; Jeremy Rubin đã chỉ ra một cách chính xác rằng điều này đã làm nảy sinh khái niệm tính toán ở một mức độ nhất định: OP_TLUV/ OP_VAULT trước tiên hứa hẹn một opcode cho phép người dùng chuyển các tham số tới opcode thông qua một giao dịch mới, từ đó cập nhật toàn bộ lá cây tập lệnh; đây không còn là xác minh dữ liệu đến dựa trên các điều kiện nhất định, thay vào đó, nó tạo ra mới dữ liệu có ý nghĩa dựa trên dữ liệu đến, mặc dù khả năng tính toán mà nó có thể thực hiện tương đối hạn chế.

(2) Đề xuất OP_VAULT hoàn chỉnh cũng sử dụng một số đề xuất về chính sách nhóm giao dịch (chính sách mempool) (chẳng hạn như giao dịch định dạng v3) để đạt được kết quả tốt hơn. Điều này nhắc nhở chúng ta rằng “lập trình” có thể có ý nghĩa rộng hơn chúng ta nghĩ. (Một ví dụ tương tự là Giao dịch mở trong Mạng Nervos.)

5. Hiểu về CKB

Trong hai chương trên, chúng tôi đã giới thiệu cách chúng tôi có thể sử dụng tập lệnh để lập trình các ứng dụng thú vị trên cấu trúc hạn chế hơn (Bitcoin UTXO); chúng tôi cũng giới thiệu một đề xuất nhằm cố gắng bổ sung khả năng xem xét nội tâm cho cấu trúc này.

Mặc dù UTXO có khả năng lập trình các ứng dụng này nhưng người đọc có thể dễ dàng phát hiện ra những thiếu sót hoặc những lĩnh vực có thể tối ưu hóa, chẳng hạn như:

Trong LN-Penalty, những người tham gia kênh phải lưu từng giao dịch cam kết trong quá khứ và giá trị bí mật hình phạt tương ứng để đối phó với hành vi gian lận của đối thủ, điều này tạo thành gánh nặng lưu trữ. Nếu có một cơ chế có thể đảm bảo rằng chỉ giao dịch cam kết mới nhất mới có hiệu lực và giao dịch cam kết cũ sẽ không có hiệu lực thì gánh nặng này có thể được loại bỏ và nó cũng có thể loại bỏ khả năng các nút nhầm lẫn các cam kết cũ do lỗi Vấn đề giao dịch đang diễn ra trên chuỗi và do đó bị trừng phạt bất ngờ.
Trong DLC, người ta cho rằng sự kiện có nhiều kết quả có thể xảy ra và hai bên phải tạo ra nhiều chữ ký trước và gửi cho nhau, đây cũng là một gánh nặng rất lớn; ngoài ra, thu nhập của hợp đồng DLC là rất lớn. bị ràng buộc trực tiếp với khóa chung nên vị trí của nó không dễ chuyển nhượng. Có cách nào để chuyển vị trí hợp đồng không?

Trên thực tế, cộng đồng Bitcoin đã đưa ra câu trả lời cho những câu hỏi này, về cơ bản liên quan đến đề xuất Sighash (BIP-118 AnyPrevOut).

Tuy nhiên, nếu chúng ta đang lập trình trên CKB thì BIP-118 hiện đã có sẵn (thẻ Sighash có thể được mô phỏng với khả năng xem xét nội tâm và xác minh cụ thể các chữ ký).

Học lập trình Bitcoin, chúng ta không chỉ biết lập trình dạng “đầu ra giao dịch” (CKB có thể lập trình những gì) mà còn biết cách cải tiến các ứng dụng này (nếu lập trình các ứng dụng này trên CKB thì làm sao sử dụng khả năng của CKB để cải thiện họ). Đối với các nhà phát triển CKB, việc lập trình dựa trên tập lệnh Bitcoin có thể được coi là một cuốn sách giáo khoa học tập hoặc thậm chí là một lối tắt.

Dưới đây, chúng tôi phân tích từng mô-đun lập trình của từng mô-đun lập trình CKB. Bây giờ chúng ta đừng xem xét khả năng nội tâm.

(1) Tập lệnh khóa có thể lập trình để tính toán tùy ý

Như đã đề cập ở trên, UTXO không thể được lập trình bằng các phép tính tùy ý. Lock Script có thể, có nghĩa là Lock Script có thể lập trình (trước khi các hạn chế được triển khai) mọi thứ dựa trên lập trình UTXO, bao gồm nhưng không giới hạn ở kênh Lightning và DLC được đề cập ở trên.

Ngoài ra, khả năng xác minh bất kỳ phép tính nào này cũng cho phép Lock Script sử dụng nhiều phương thức xác thực hơn và linh hoạt hơn UTXO. Ví dụ: chúng tôi có thể triển khai kênh sét trên CKB trong đó một bên sử dụng chữ ký ECDSA và bên kia sử dụng chữ ký RSA.

Trên thực tế, đây là một trong những lĩnh vực sớm nhất mà mọi người bắt đầu khám phá trên CKB: sử dụng khả năng xác minh danh tính linh hoạt này trong quyền giám sát tự trị của người dùng để đạt được cái gọi là trừu tượng hóa tài khoản - ủy quyền và hiệu lực giao dịch. Khôi phục quyền kiểm soát rất linh hoạt và gần như không giới hạn. Về nguyên tắc, đây là sự kết hợp giữa “nhiều nhánh chi tiêu” và “bất kỳ phương thức xác thực nào”. Ví dụ về việc triển khai bao gồm: ví joyid, UniPass.

Ngoài ra, Lock Script cũng có thể triển khai đề xuất eltoo, cho phép các kênh Lightning chỉ cần giữ lại giao dịch đã cam kết mới nhất (trên thực tế, eltoo có thể đơn giản hóa tất cả các hợp đồng điểm-điểm).

(2) Gõ Script có thể lập trình bất kỳ phép tính nào

Như đã đề cập ở trên, một trong những công dụng tuyệt vời của Type Script là lập trình UDT. Kết hợp với Lock Script, điều này có nghĩa là chúng tôi có thể triển khai các kênh Lightning dựa trên UDT (cũng như các loại hợp đồng khác).

Trên thực tế, việc tách Lock Script và Type Script có thể được coi là một bản nâng cấp bảo mật: Lock Script tập trung vào việc triển khai các phương thức lưu ký hoặc giao thức hợp đồng, trong khi Type Script tập trung vào định nghĩa UDT.

Ngoài ra, khả năng bắt đầu kiểm tra dựa trên định nghĩa UDT cũng cho phép UDT tham gia vào các hợp đồng theo cách tương tự như CKB (UDT là công dân hạng nhất).

Ví dụ: Tác giả đã từng đề xuất một giao thức để triển khai hoạt động cho vay bảo đảm bằng NFT không đáng tin cậy trên Bitcoin. Chìa khóa của giao thức này là một giao dịch cam kết trong đó giá trị của đầu vào nhỏ hơn giá trị của đầu ra (vì vậy đây chưa phải là một giao dịch hợp lệ). Tuy nhiên, khi có thể cung cấp đủ đầu vào cho giao dịch này thì đó là A giao dịch hợp lệ: Sau khi người cho vay có thể hoàn trả, người cho vay không thể giữ NFT đã cam kết làm của riêng mình. Tuy nhiên, bản chất không đáng tin cậy của giao dịch cam kết này dựa trên giao dịch kiểm tra số lượng đầu vào và đầu ra, do đó người cho vay chỉ có thể hoàn trả khoản vay bằng Bitcoin - ngay cả khi cả người cho vay và người cho vay đều sẵn sàng chấp nhận một loại tiền tệ khác (chẳng hạn như tính bằng RGB USDT do giao thức phát hành), giao dịch cam kết của Bitcoin không thể đảm bảo rằng miễn là người cho vay trả lại đủ số USDT thì họ sẽ có thể lấy lại NFT của mình, vì giao dịch Bitcoin hoàn toàn không biết trạng thái của USDT ! (Sửa đổi: Nói cách khác, không thể xây dựng giao dịch cam kết có điều kiện hoàn trả USDT.)

Nếu chúng tôi có thể bắt đầu kiểm tra dựa trên định nghĩa về UDT, thì người cho vay có thể ký một giao dịch cam kết khác, cho phép người cho vay hoàn trả khoản vay bằng USDT. Giao dịch sẽ kiểm tra số lượng USDT đầu vào và số lượng USDT đầu ra, mang lại cho người dùng sự hoàn trả đáng tin cậy bằng USDT.

Sửa đổi: Giả sử rằng NFT được sử dụng làm tài sản thế chấp và mã thông báo được sử dụng để trả nợ được phát hành bằng cùng một giao thức (chẳng hạn như RGB), thì vấn đề ở đây có thể được giải quyết. Chúng ta có thể xây dựng một giao dịch cam kết dựa trên giao thức RGB, để NFT chuyển đổi trạng thái và hoàn trả có thể xảy ra đồng thời (giao dịch được sử dụng để liên kết hai chuyển đổi trạng thái trong giao thức RGB). Tuy nhiên, do giao dịch RGB cũng dựa vào giao dịch Bitcoin nên việc xây dựng giao dịch cam kết ở đây sẽ gặp đôi chút khó khăn. Nói chung, mặc dù vấn đề có thể được giải quyết nhưng token vẫn là công dân hạng nhất.

Tiếp theo chúng ta xem xét khả năng xem xét nội tâm.

(3) Lock Script đọc các Lock Script khác

Điều này có nghĩa là có đầy đủ các khả năng lập trình trên Bitcoin UTXO sau khi các hạn chế được đề xuất được triển khai. Bao gồm hợp đồng an toàn được đề cập ở trên và các ứng dụng dựa trên OP_CTV (chẳng hạn như kiểm soát tắc nghẽn).

XueJie từng đề cập đến một ví dụ rất thú vị: bạn có thể triển khai tài khoản thu thập Cell trên CKB, khi sử dụng Cell này làm đầu vào của một giao dịch, nếu Cell mà nó xuất ra (Ô sử dụng cùng Lock Script) có nhiều Dung lượng hơn thì đầu vào này sẽ làm như vậy. không cần cung cấp chữ ký và sẽ không ảnh hưởng đến hiệu lực của giao dịch. Trên thực tế, Tế bào này không thể được triển khai nếu không có khả năng xem xét nội tâm. Loại tài khoản thu tiền này Cell rất phù hợp làm phương thức thu nợ cho các tổ chức vì nó có thể tập hợp tiền, nhược điểm là tính bảo mật không tốt.

(4) Lock Script đọc các Type Script khác (và Dữ liệu)

Một ứng dụng thú vị của khả năng này là token vốn chủ sở hữu. Lock Script sẽ xác định xem nó có thể sử dụng Dung lượng của chính mình hay không dựa trên số lượng Token trong các đầu vào khác và nơi có thể sử dụng Dung lượng (yêu cầu khả năng xem xét nội tâm của Lock Script).

(5) Type Script đọc các Lock Script khác

Không chắc chắn, nhưng có thể được coi là hữu ích. Ví dụ: Lock Script có thể kiểm tra đầu vào và đầu ra của giao dịch vẫn không thay đổi trong Type Script.

(6) Type Script đọc các Type Script khác (và Dữ liệu)

Trao đổi thẻ? Thu thập n token có thể đổi lấy token lớn hơn :)

6. Kết luận

So với các hệ thống hợp đồng thông minh có thể lập trình trước đây để tính toán tùy ý (chẳng hạn như Ethereum), Mạng Nervos áp dụng một cấu trúc khác; do đó, việc hiểu về các hệ thống hợp đồng thông minh trước đó thường khó tạo cơ sở để hiểu Mạng Nervos. Bài viết này bắt đầu từ việc lập trình ứng dụng của một cấu trúc bị hạn chế hơn CKB Cell - BTC UTXO - và đề xuất một phương pháp để hiểu khả năng lập trình của CKB Cell. Hơn nữa, bằng cách sử dụng khái niệm xem xét nội tâm để hiểu khả năng truy cập hợp đồng chéo của Cell, chúng ta có thể phân chia các tình huống sử dụng khả năng xem xét nội tâm và xác định cách sử dụng cụ thể của chúng.

Ôn tập:

Bất kể khả năng truy cập chéo của Cell (tức là khả năng xem xét nội tâm), các tập lệnh khóa có thể được coi là Bitcoin Script với khả năng lập trình trạng thái và cực đoan. Do đó, tất cả các ứng dụng dựa trên Bitcoin Script đều có thể được lập trình chỉ dựa trên điều này;
Bất kể khả năng truy cập chéo của Cell (nghĩa là khả năng xem xét nội tâm), sự khác biệt giữa tập lệnh khóa và tập lệnh loại có thể được coi là một bản nâng cấp bảo mật: nó tách biệt các phương pháp lưu trữ và định nghĩa nội dung của UDT; ngoài ra, các tập lệnh loại có thể tiết lộ trạng thái (và Data) đạt được hiệu quả rằng UDT là công dân hạng nhất.

Hai điểm trên có ý nghĩa gì đó có mô hình tương tự như “BTC + RGB” nhưng có khả năng lập trình mạnh hơn;

Xem xét khả năng xem xét nội tâm của Cell, Cell có thể có được khả năng lập trình mạnh hơn BTC UTXO sau giao ước và đạt được điều mà BTC + RGB khó đạt được (vì BTC không thể đọc được trạng thái của RGB)

Về những công dụng này, bài viết này không thể đưa ra nhiều ví dụ cụ thể nhưng điều này là do tác giả chưa hiểu rõ về hệ sinh thái của CKB. Thời gian trôi qua, tôi tin rằng mọi người sẽ ngày càng đưa trí tưởng tượng vào đó nhiều hơn và kết hợp những ứng dụng mà ngày nay chúng ta không thể tưởng tượng được.

Sự nhìn nhận

Cảm ơn Retric, Jan Xie và Xue Jie vì những phản hồi của họ trong quá trình viết bài. Tất nhiên mọi sai sót trong bài viết đều do tôi tự chịu trách nhiệm.