Từ việc lập trình ứng dụng Bitcoin, chi tiết ở hàng nghìn từ về tính có thể lập trình của CKB

Dưới đây là nội dung được sao chép từ diễn đàn Nervos Talk, tác giả Ajian (biên tập viên trang nội dung Bitcoin BTC Study).

Tóm tắt

理解 một hệ thống có tính lập trình đòi hỏi chúng ta nhận biết 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 có ích để chúng ta hiểu cấu trúc cơ bản của ô CKB và mô hình lập trình của nó. Không chỉ vậy, nó cũng có thể phân tách các thành phần 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 có tính lập trình mà mỗi phần mang lại.

一. Giới thiệu

“可编程性 (programmability)” là một khía cạnh thường được sử dụng để so sánh các hệ thống blockchain. Tuy nhiên, cách mô tả về khả năng lập trình này thường có sự khác biệt. Một cách mô tả phổ biến là "Blockchain XX hỗ trợ ngôn ngữ lập trình Turing hoàn thành" hoặc "Blockchain XX hỗ trợ lập trình tổng quát", nhằm chỉ rằng Blockchain XX có khả năng lập trình mạnh mẽ. Những phát ngôn này có một số ý nghĩa ẩn: hệ thống hỗ trợ lập trình Turing hoàn thành thường dễ dàng hơn so với những hệ thống không hỗ trợ. Tuy nhiên, các đặc điểm cấu trúc của hệ thống hợp đồng thông minh có nhiều khía cạnh khác nhau, và câu này chỉ liên quan đến một khía cạnh, do đó, không đủ để có được sự hiểu biết sâu sắc: nhà phát triển không thể dựa vào nó để có hướng dẫn và người dùng thông thường cũng không thể phân biệt lừa đảo dựa trên nó.

Hợp đồng thông minh系统在结构上的特征包括：

• Cơ bản về hình thức biểu thị trạng thái (tài khoản vs đầu ra giao dịch) của hợp đồng
• Có cho phép tính toán bất kỳ lập trình nào không ("Turing hoàn thành" liên quan đến khía cạnh này)?
• Quá trình thực thi có thể tạo ra dữ liệu mới hay chỉ trả về giá trị boolean? (Tính toán vs. Xác minh)
• Có cho phép ghi lại trạng thái bổ sung trong hợp đồng không
• Khi một hợp đồng được thực thi, liệu nó có thể truy cập trạng thái của một hợp đồng khác hay không

所 với, tối thiểu còn bốn khía cạnh khác sẽ ảnh hưởng đến tính có thể lập trình của một hệ thống hợp đồng thông minh, ngoài "có thể lập trình bất kỳ tính toán nào hay không". Thậm chí có thể nói rằng, những đặc điểm khác này quan trọng hơn, vì chúng quyết định sâu hơn về những gì dễ dàng thực hiện, những gì khó thực hiện; cái gì là thực hiện hiệu quả hơn, và cái gì là thực hiện không hiệu quả hơn.

Ví dụ điều này, Ethereum thường được sử dụng làm ví dụ về tính khả năng lập trình tốt, nhưng hình thức cơ bản của việc biểu thị trạng thái trên Ethereum là tài khoản, nó khó để lập trình hợp đồng ngang hàng (ví dụ, kênh thanh toán, hợp đồng đánh cược một cặp) - không hoàn toàn không thể thực hiện, nhưng khá là khó khăn. Hệ sinh thái Ethereum đã từng có nhiều dự án thử nghiệm để triển khai kênh thanh toán / trạng thái, và có nhiều thảo luận lý thuyết, nhưng đến ngày nay, những dự án này dường như không còn hoạt động - điều này rõ ràng không thể đổ lỗi cho nhà phát triển không nỗ lực. Hiện nay, các dự án hoạt động trên Ethereum thường áp dụng mô hình "vốn chung" thay vì mô hình "hợp đồng ngang hàng", và điều này không phải là ngẫu nhiên. Tương tự, có thể nói rằng người ta có thể hài lòng với tính khả năng lập trình của Ethereum hiện tại, nhưng việc triển khai "trừu tượng hóa tài khoản" (cũng có thể hiểu là khái niệm ví tiền) lại có thể nói là thiếu hụt bẩm sinh của mô hình tài khoản.

Tương tự như vậy, để tìm hiểu về tính khả chương trình của CKB, chúng ta cũng cần hiểu về các đặc điểm cấu trúc của hệ thống hợp đồng thông minh CKB trong các khía cạnh này. Chúng ta đã biết rằng CKB cho phép lập trình tính toán bất kỳ, cho phép ghi lại trạng thái bổ sung trong hợp đồng và cho phép một hợp đồng truy cập vào trạng thái của một hợp đồng khác trong quá trình thực thi. Tuy nhiên, hợp đồng của nó có hình thức là đầu ra của giao dịch (gọi là "Cell"), điều này tạo ra sự khác biệt cơ bản so với Ethereum. Do đó, việc hiểu về hệ thống hợp đồng thông minh Ethereum và các ví dụ hợp đồng trong đó không giúp chúng ta hiểu được cách CKB thực hiện các đặc điểm cấu trúc này và không giúp chúng ta nhận thức được tính khả chương trình của CKB.

Rất may mắn, hợp đồng thông minh trên Bitcoin có vẻ cung cấp nền tảng tốt nhất cho chúng ta để hiểu về tính khả vi của CKB. Điều này không chỉ vì hình thức cơ bản của trạng thái Bitcoin cũng là đầu ra của giao dịch (gọi là "UTXO"), mà còn vì chúng ta có thể hiểu được lý do CKB có những đặc tính kiến trúc trên nhờ vào một khái niệm được đề xuất bởi cộng đồng Bitcoin, gọi là "covenants", cho phép chúng ta phân tích kết quả cuối cùng thành một số phần và nhận biết một cách đúng đắn sự gia tăng tính khả vi mà chúng mang lại.

二. CKB v.s. BTC: Những điều gì đã thêm vào?

Cấu trúc cơ bản

作为比特币状态表达的基本形式，比特币的 UTXO（“Đầu ra giao dịch chưa chi tiêu”）有两个字段：

• Số tiền, được biểu thị bằng đơn vị satoshi (Satoshi), đại diện cho giá trị Bitcoin mà UTXO đó sở hữu;
• Khóa công khai kịch bản, còn được gọi là kịch bản khóa, đại diện cho các điều kiện cần được đáp ứng để chi tiêu số tiền này, nghĩa là chương trình hợp đồng thông minh đặt ra các điều kiện để mở khóa số tiền này.

Soạn thảo của Bitcoin được giới hạn khá nhiều so với các hệ thống hợp đồng thông minh xuất hiện sau này.

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

Các ví dụ về việc lập trình kịch bản Bitcoin sẽ được giới thiệu trong phần sau, mặc dù việc lập trình bị giới hạn nhưng không thiếu khả năng tạo ra các ứng dụng đáng kinh ngạc và đó cũng là cơ sở để chúng tôi nghiên cứu khả năng lập trình CKB.

Với điều tương tự, đơn vị trạng thái của CKB được gọi là “Cell”, có bốn trường:

• Capacity, tương tự như số lượng UTXO, biểu thị kích thước không gian mà Cell có thể chiếm dụng, tính bằng đơn vị byte.
• Lock ，tương tự như public key của script UTXO, xác định quyền sở hữu của Cell; chỉ khi dữ liệu được cung cấp có thể thông qua Lock, cell này mới có thể được "cập nhật" (có thể được giải phóng và sử dụng capacity này để đúc ra cell mới);
• Dữ liệu, Dữ liệu tùy ý, với khối lượng dữ liệu bị giới hạn bởi Khả năng.
• Loại ，tùy chọn cho script, được sử dụng để đặt điều kiện cho cập nhật Data.

此外，Lock 和 Type 还可以编程任意计算。你可以编程出任意的签名验证Thuật toán，也可以编程出任意一种哈希Thuật toán的原像检查，等等等等。

Độc giả rất dễ dàng nhận thấy rằng, Cell so với UTXO đã nâng cao tính khả chương trình hóa.

• Cell có thể lập trình bất kỳ tính toán nào, chứ không chỉ có thể lập trình một số tính toán cụ thể; việc xác thực sở hữu của nó sẽ linh hoạt hơn;
• Vì trường dữ liệu Data và Type, Cell có thể ghi lại trạng thái bổ sung; điều này cho phép Cell chứa những gì gọi là "Token người dùng tự xác định".

结合 Cell 本身的 “交易输出” 结构，这两点本身能带来的好处已然非常非常巨大，但是，仅从上面的描述，我们尚不知晓 Cell 是如何实现 “一个合约在运行时访问另一个合约的状态” 的。为此，我们需要借助Bitcoin社区探讨了很长时间的一个概念：“限制条款（covenants）”。

Điều khoản hạn chế và tự xét

限制条款 của ý nghĩa cơ bản là hạn chế một khoản tiền có thể được chi tiêu ở đâu. Trên Bitcoin hiện tại (chưa triển khai bất kỳ đề xuất hạn chế nào), một khi một khoản tiền được mở khóa, nó có thể được chi tiêu ở bất kỳ đâu (có thể thanh toán cho bất kỳ public key script nào). Nhưng ý tưởng của hạn chế là, có thể hạn chế nó chỉ có thể được chi tiêu ở một số nơi cụ thể, ví dụ, một UTXO cụ thể chỉ có thể được chi tiêu trong một giao dịch cụ thể, vì vậy, ngay cả khi có người có thể ký cho UTXO này, nó đã được quyết định sẽ được chi tiêu ở đâu bởi giao dịch đó. Tính năng này có vẻ hơi kỳ lạ, nhưng có thể tạo ra một số ứng dụng thú vị, sẽ có một phần riêng biệt giới thiệu về điều này sau. Quan trọng nhất là, nó là chìa khóa cho sự hiểu biết sâu hơn về tính lập trình của CKB.

Rusty Russell đã chỉ ra một cách chính xác rằng các điều khoản hạn chế có thể được hiểu là khả năng "tự soi" giao dịch, tức là khi một UTXO A được chi tiêu bởi giao dịch B, chương trình tính toán kịch bản có thể đọc một phần (hoặc toàn bộ) của giao dịch B, sau đó kiểm tra xem chúng có khớp với các tham số yêu cầu trước đó của kịch bản hay không. Ví dụ, khóa công khai của đầu ra đầu tiên của giao dịch A có khớp với khóa công khai được yêu cầu của UTXO A hay không (đây là ý nghĩa ban đầu của các điều khoản hạn chế).

Những độc giả nhạy bén sẽ nhận ra rằng nếu có khả năng tự phản ánh hoàn toàn, thì một đầu vào 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, đây là khả năng "truy cập vào trạng thái của một hợp đồng khác trong quá trình chạy" mà chúng ta đã đề cập trước đó. Trên thực tế, CKB Cell được thiết kế như vậy.

基于此，我们又可以将这种完全的内省能力分成四种情形： -> Dựa trên điều này, chúng ta có thể chia khả năng tự quan sát hoàn toàn này thành bốn trường hợp:

• Đọc khóa (đầu vào và đầu ra) của khóa khác.
• Đọc loại (và dữ liệu) khác (đầu vào và đầu ra) của khóa
• Nhập 01928374656574839201 và đầu ra Lock của nó
• Loại 01928374656574839201其它（输入和输出）的 Loại （以及 Data）

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

在 các chương dưới đây, chúng ta sẽ tìm hiểu về việc lập trình script Bitcoin hiện tại (đề xuất không hạn chế), cũng như các tính năng có thể thực hiện theo đề xuất hạn chế, từ đó hiểu cách lập trình và cải thiện CKB Cell cụ thể hơn.

Ba. Lập trình Script Bitcoin

本节将使用 "Lighting Network" và "DLC" như là các ví dụ về lập trình ứng dụng dựa trên kịch bản Bitcoin. Trước khi tiếp tục, chúng ta cần hiểu hai khái niệm này.

OP_IF và "giao dịch cam kết"

Định nghĩa đầu tiên là mã điều khiển quy trình trong tập lệnh Bitcoin, ví dụ: OP_IF, OP_ELSE. Các mã này không khác gì IF trong lập trình máy tính, chúng được sử dụng để thực hiện các lệnh khác nhau dựa trên đầu vào khác nhau. Trong ngữ cảnh của tập lệnh Bitcoin, điều này có nghĩa là chúng ta có thể thiết lập nhiều đường mở khóa cho các quỹ; 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 ta có thể phân phối quyền ưu tiên hành động.

以著名的 “Hợp đồng khóa thời gian (HTLC)” 为例，这种脚本翻译成大白话就是：

要么，Bob 可以揭晓某个哈希值 H 背后的原像，再给出自己的签名，即可花费这笔资金；

Alice có thể chi tiêu số tiền này sau khoảng thời gian T bằng chữ ký của mình.

这种 “01928374656574839201 …… 01928374656574839201 ……” 的效果，就是通过流程控制操作码实现的。

HTLC có ưu điểm nổi bật là có thể kết hợp nhiều giao dịch lại với nhau và thực hiện theo cách nguyên tử. Ví dụ, Alice muốn trao đổi CKB với Bob bằng BTC, sau đó, Bob có thể cung cấp một giá trị hash và tạo một HTLC trên Nervos Network; sau đó, Alice tạo một HTLC trên Bitcoin sử dụng cùng một giá trị hash. Hoặc là, Bob lấy BTC mà Alice trả trên Bitcoin và tiết lộ giá trị ban đầu, cho phép Alice rút CKB trên Nervos Network. Hoặc là, Bob không tiết lộ giá trị ban đầu, cả hai hợp đồng đều hết hạn, Alice và Bob đều có thể rút lại số vốn đã đầu tư của mình.

在 Taproot sau khi kích hoạt hard fork, tính năng đa con đường mở khóa này được tăng cường mạnh mẽ hơn nhờ sự ra đời của MAST (cây cú pháp trừu tượng của Merkle) : chúng ta có thể biến một con đường mở khóa thành một lá trên cây Merkle, mỗi lá đều độc lập, do đó không cần sử dụng mã điều khiển quá trình như vậy nữa; và vì không cần phơi bày các con đường khác khi tiết lộ một con đường, chúng ta có thể thêm nhiều con đường mở khóa cho một đầu ra mà không cần 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, một giao dịch Bitcoin hợp lệ, ngay cả khi nó không được xác nhận trên blockchain, vẫn là thực sự và có hiệu lực."

Ví dụ, Alice và Bob có một UTXO chung, cần chữ ký của cả hai để tiêu thụ UTXO này. Lúc này, Alice tạo một giao dịch để tiêu thụ nó, chuyển 60% giá trị cho Bob và giữ lại phần còn lại cho chính mình; Alice ký giao dịch này và gửi cho Bob. Với Bob, anh ta không cần phải phát sóng giao dịch này lên mạng Bitcoin, cũng không cần đợi giao dịch này được xác nhận trên blockchain, hiệu quả thanh toán của giao dịch này cũng là đáng tin cậy. Bởi vì Alice không thể tiêu thụ UTXO này một mình (vì vậy không thể tiêu thụ lặp lại), và chữ ký mà Alice cung cấp là hợp lệ, Bob có thể bất cứ lúc nào thêm chữ ký của mình và phát sóng giao dịch này để thực hiện thanh toán. Nghĩa là, Alice đã cung cấp cho Bob một "lời hứa đáng tin" thông qua giao dịch này (không đi vào blockchain).

承诺 giao dịch là khái niệm cốt lõi của việc lập trình ứng dụng Bitcoin. Như đã đề cập trước đó, hợp đồng Bitcoin dựa trên việc xác minh, không có 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 theo trạng thái, thì những trạng thái này được lưu trữ ở đâu và làm thế nào để đảm bảo an toàn (thay đổi trạng thái) của hợp đồng? Giao dịch cam kết cung cấp câu trả lời rõ ràng: trạng thái của hợp đồng có thể được biểu diễn dưới dạng giao dịch, từ đó, các bên tham gia hợp đồng có thể tự lưu trữ trạng thái mà không cần trưng bày chúng trên blockchain; vấn đề thay đổi trạng thái của hợp đồng cũng có thể được chuyển đổi thành vấn đề cập nhật 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ề việc nhập cảnh vào một hợp đồng có nguy cơ (ví dụ như nhập cảnh vào một hợp đồng yêu cầu cả hai bên ký tên mới có thể tiêu tốn, sẽ đối mặt với nguy cơ bị hỏng nếu đối tác không phản hồi), thì chỉ cần tạo trước giao dịch cam kết tiêu tốn hợp đồng đó và nhận chữ ký, chúng ta có thể giảm thiểu rủi ro, loại bỏ sự tin tưởng đối với các bên tham gia khác.

Lighting Network và Mạng Lighting

"闪电通道是一种一对一的合约，在这种合约中，双方可以无限次地相互支付，而不必让任何一次支付获得区块链的确认。如你所料，它用到了承诺交易。"

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

Sự giải quyết vấn đề này thông qua kênh Lightning được gọi là "LN-Penalty". Bây giờ, giả sử Alice và Bob mỗi người đều 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ư vậy và gửi cho Bob:

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

Xuất #0,4 BTC: Alice ký đơn

Xuất #1,6 BTC: Hoặc khóa công khai tạm thời Alice-Bob ký đơn hoặc khóa thời gian T1, Bob ký đơn.

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

Nhập #0, 10 BTC: Đầu ra đa chữ ký Alie-Bob 2-of-2 (hay còn gọi là hợp đồng kênh)

Xuất #0,6 BTC: Bob ký đơn

Xuất #1, 4 BTC: Hoặc là chữ ký đơn của khóa công khai tạm thời Bob-Alice #1 hoặc là chữ ký đơn của Alice với khóa thời gian T1.

Cách thức hoạt động ở đây nằm ở "khóa công khai tạm thời chung", nó được tạo ra bằng cách sử dụng một khóa công khai của mình và một khóa công khai của đối tác. Ví dụ, khóa công khai tạm thời của Alice-Bob là kết quả của việc nhân khóa công khai của Alice với một giá trị băm và khóa công khai mà Bob cung cấp, sau đó cộng hai kết quả lại với nhau. Khi khóa công khai này được tạo ra, không ai biết khóa riêng của nó là gì. Tuy nhiên, nếu Bob tiết lộ khóa riêng của khóa công khai mà anh ấy cung cấp cho Alice, Alice có thể tính toán được khóa riêng của khóa công khai tạm thời này. Đây là yếu tố quan trọng để "hủy bỏ" trạng thái cũ trong kênh Lightning.

Khi hai bên cần cập nhật trạng thái kênh (khởi tạo thanh toán) lần tiếp theo, hai bên sẽ trao đổi khóa riêng tạm thời đã trao cho đối tác trong vòng trước. Như vậy, người tham gia sẽ không dám phát sóng giao dịch cam kết đã nhận được: giao dịch cam kết này có hai đường dẫn cho đầu ra phân phối giá trị của mình, trong đó khóa riêng tạm thời đã được đối tác biết; do đó, một khi giao dịch cam kết cũ được phát sóng, đối tác có thể ngay lập tức sử dụng khóa riêng tạm thời liên kết này để lấy toàn bộ số tiền trong đầu ra này. - Đó là ý nghĩa của "LN-Penalty".

Cụ thể, thứ tự tương tác như sau: bên khởi tạo thanh toán đầu 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 giao dịch cam kết mới và giao cho bên kia; bên nhận được giao dịch cam kết tiết lộ khóa riêng của khóa công khai tạm thời mà mình đã cung cấp trong vòng trước. Thứ tự tương tác này đảm bảo rằng người tham gia luôn nhận được giao dịch cam kết mới trước, sau đó mới vô hiệu hóa giao dịch cam kết nhận được trong vòng trước, do đó là miễn cần tin tưởng.

综上，闪电通道的关键设计有：

"Giữa hai bên, giao dịch cam kết luôn được sử dụng để biểu thị trạng thái trong hợp đồng và được biểu thị bằng sự thay đổi số tiền thanh toán;"

Cam kết giao dịch luôn tốn cùng một đầu vào (đầu vào cần chữ ký của cả hai bên), vì vậy tất cả các giao dịch cam kết đều cạnh tranh lẫn nhau, cuối cùng chỉ có một giao dịch có thể nhận được xác nhận từ blockchain;

Hai bên ký tên không phải là giao dịch cam kết cùng một lúc (mặc dù chúng được đôi); và những giao dịch mà họ ký tên luôn luôn có lợi hơn cho chính họ, nghĩa là các bên tham gia luôn nhận được các giao dịch cam kết không có lợi cho mình;

Loại bất lợi này được phản ánh trong việc phân phối giá trị đầu ra cho chính mình với hai con đường mở khóa: một con đường có thể mở khóa bằng chữ ký của chính mình, nhưng cần đợi một khoảng thời gian; và con đường khác sử dụng khóa công khai của đối tác, chỉ khi một khóa riêng tạm thời của chính mình không bị tiết lộ, thì mới được bảo vệ.

Trong mỗi giao dịch thanh toán, hai bên trao đổi khóa riêng tạm thời đã sử dụng trong vòng trước bằng cách thực hiện một giao dịch cam kết mới. Điều này có nghĩa là bên đã trao khóa riêng tạm thời không còn dám phát sóng giao dịch cam kết cũ nữa, vì vậy giao dịch cam kết trước đã "bị thu hồi" và trạng thái hợp đồng được cập nhật. (Thực tế, các giao dịch cam kết này đều là giao dịch hợp lệ và có thể được phát sóng lên chuỗi khối, chỉ là các bên tham gia không dám phát sóng nữa do sợ bị phạt).

Bất kỳ bên nào cũng có thể rút khỏi hợp đồng bằng cách thực hiện giao dịch cam kết mà đối tác đã ký tên; tuy nhiên, nếu cả hai bên muốn hợp tác, họ có thể ký một giao dịch mới để cả hai bên có thể lấy lại tiền của mình ngay lập tức.

Cuối cùng, vì trong giao dịch cam kết cũng có thể chèn HTLC, nên kênh Lightning cũng có thể chuyển tiếp thanh toán. Giả sử Alice có thể tìm ra một đường dẫn được hình thành bởi các kênh Lightning kết nối trước và sau, và đến được Daniel, thì không cần mở kênh với Daniel cũng có thể thực hiện thanh toán đa bước không cần tin tưởng. Đây chính là Lightning Network:

Alice -- HTLC --\u003e Bob -- HTLC --\u003e Carol -- HTLC --\u003e Daniel

Alice \u003c-- ảnh gốc -- Bob \u003c-- ảnh gốc -- Carol \u003c-- ảnh gốc -- Daniel

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

闪电网络 được tạo thành từ các kênh độc lập, mỗi kênh (hợp đồng) đều tồn tại độc lập. Điều này có nghĩa là Alice chỉ cần quan tâm đến những gì diễn ra trên kênh của mình với Bob, không cần quan tâm đến số lần trao đổi trên các kênh khác, không cần biết loại tiền tệ được sử dụng trong giao dịch, thậm chí không cần biết liệu họ có thực sự sử dụng kênh hay không).

Lighting Network không chỉ có khả năng mở rộng trong tốc độ thanh toán bên trong một kênh Lighting mà chỉ bị giới hạn bởi nguồn tài nguyên phần cứng của hai bên, mà còn bởi việc lưu trữ trạng thái phân tán, một nút duy nhất có thể sử dụng đòn bẩy lớn nhất với chi phí thấp nhất.

Hợp đồng nhật ký cẩn thận

Kỷ luật hợp đồng nhật ký thận trọng (DLC) sử dụng một kỹ thuật mật mã gọi là "chữ ký bộ chuyển đổi" để cho phép mã script 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.

Adapter signature allows a signature to become valid only after adding a private key. Taking Schnorr signature as an example, the standard form of Schnorr signature is (R, s), where:

R = r.G # Khóa công khai của nonce để tạo chữ ký r

s = r + Hash(R || m || P) * p # p 即为签名私钥，P 为公钥

Xác minh chữ ký là xác minh s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK

假设我给出了一对数据(R, s')，其中：

R = R1 + R2 = r1.G + r2.G

s' = r1 + Hash(R || m || P) \* p

Rõ ràng, đây không phải là một chữ ký Schnorr hợp lệ, nó không thể vượt qua công thức xác thực, nhưng tôi có thể chứng minh với người xác thực rằng chỉ cần TA biết khóa riêng của R2 là r2, nó có thể trở thành một chữ ký hợp lệ:

s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P

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

假设 Alice và Bob muốn đặt cược vào kết quả trận đấu bóng đá. Alice và Bob đặt cược lần lượt là một mức cược 1 BTC với Green Devils và Arlina chiến thắng. Ngoài ra, trang web đánh giá bóng đá Carol cam kết sẽ phát hành chữ ký cho kết quả bằng một nonce R_c khi kết quả trận đấu được công bố.

可以看出，一共有三种可能的结果（因此 Carol 的签名有 3 种可能）：

• Xanh thắng, Alice nhận được 1 BTC
• Arinna wins, Bob wins 1 BTC.
• Hòa, số tiền của hai người được trả lại theo đúng quy định

为此，两人为每一种结果创建一笔承诺交易。例如，他们为第一种结果创建的承诺交易是这样的：

Nhập #0,2 BTC: Alie-Bob 2-of-2 đầu ra đa chữ ký (tức là hợp đồng cược)

Xuất #0,2 BTC: Alice ký đơn

Nhưng chữ ký mà Alice và Bob tạo ra cho giao dịch này không phải là (R, s) mà là chữ ký của bộ chuyển đổi (R, s'); nghĩa là, chữ ký mà mỗi bên đưa cho đối tác không thể được sử dụng trực tiếp để mở khóa hợp đồng này, mà phải tiết lộ giá trị bí mật. Giá trị bí mật này chính là hình ảnh ban đầu của s_c_1.G, nghĩa là chữ ký của Carol! Vì giá trị nonce của chữ ký của Carol đã được xác định (là R_c), nên s_c_1.G có thể được xây dựng (s_c_1.G = R_c + Hash(R_c || '绿魔胜出' || PK_c) * PK_c).

Khi kết quả được công bố, giả sử mà Man City chiến thắng, Carol sẽ phát hành chữ ký (R_c, s_c_1), sau đó cả Alice và Bob đều có thể hoàn thiện chữ ký của bên kia, kết hợp với chữ ký của mình để tạo thành một giao dịch hợp lệ và phát sóng nó ra mạng, kích hoạt hiệu ứng thanh toán. Nhưng nếu Man City không chiến thắng, Carol sẽ không phát hành s_c_1, giao dịch cam kết này cũng không thể trở thành một giao dịch hợp lệ.

Như vậy, hai giao dịch khác cũng tương tự như vậy. Như vậy, Alice và Bob đã làm cho việc thực hiện hợp đồng này phụ thuộc vào sự kiện bên ngoài (cụ thể là phụ thuộc vào việc máy khẳng định thông báo về sự kiện bên ngoài, dưới dạng một chữ ký), mà không cần tin tưởng đối tác. Các hợp đồng tài chính nhỏ lẻ như hợp đồng tương lai, tùy chọn, cũng có thể được thực hiện theo cách này.

Với sự thực hiện so với các hình thức khác, điểm quan trọng nhất của hợp đồng nhật ký thận trọng là tính riêng tư của nó: (1) Alice và Bob không cần thông báo cho 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) Người quan sát trên chuỗi (bao gồm cả Carol), cũng không thể thông qua giao dịch thực hiện hợp đồng của Alice và Bob mà xác định họ đang sử dụng dịch vụ của trang web nào, thậm chí không thể xác định xem hợp đồng của họ là một hợp đồng cược (thay vì một kênh siêu tốc).

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

OP_CTV và Kiểm soát kẹt xe

Các nhà phát triển trong cộng đồng Bitcoin đã đưa ra nhiều đề xuất có thể được phân loại là các điều khoản hạn chế. Hiện tại, một đề xuất nổi tiếng nhất chính là OP_CHECKTEMPLATEVERIFY (OP_CTV), với khái niệm đơn giản nhưng vẫn giữ được mức độ linh hoạt đáng kể, do đó nó được cộng đồng Bitcoin ưa chuộng vì tính đơn giản. Ý tưởng của OP_CTV là cam kết một giá trị băm trong script để ràng buộc số tiền này chỉ có thể được chi tiêu bởi giao dịch được biểu thị bởi giá trị băm đó; giá trị băm này cam kết đầu ra của giao dịch cũng như 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 số lượng đầu vào.

""拥堵控制" là một ví dụ tốt để thể hiện tính năng OP\_CTV. Cảnh giác ứng dụng cơ bản là giúp một lượng lớn người dùng rời khỏi sàn giao dịch (một môi trường đáng tin cậy) và chuyển đến một hồ tiền; vì hồ tiền này sử dụng OP\_CTV để lập kế hoạch chi tiêu trong tương lai, nên nó đảm bảo người dùng có thể rút tiền ra khỏi hồ tiền này mà không cần phải tin tưởng ai; và vì hồ tiền này chỉ là một UTXO, nên nó tránh được việc phải trả nhiều phí giao dịch khi yêu cầu giao dịch trên chuỗi tăng cao (từ n đầu ra giảm xuống 1 đầu ra; từ n giao dịch giảm xuống 1 giao dịch). Người dùng trong hồ tiền có thể tận dụng cơ hội rút tiền ra khỏi hồ tiền."

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

Bob hoặc Carol muốn rút tiền, cũng như vậy. Khi họ rút tiền, họ chỉ có thể sử dụng giao dịch được kiểm tra bằng OP_CTV tương ứng, có nghĩa là chỉ có thể thanh toán số tiền tương ứng cho chính mình, không thể rút tiền bất kỳ số tiền nào; số tiền còn lại sẽ được chuyển vào một nguồn tiền được khóa bằng OP_CTV, đảm bảo rằng dù thứ tự rút tiền của người dùng là thế nào, người dùng còn lại cũng có thể rút tiền từ nguồn tiền đó một cách không cần tin tưởng.

抽象地说，01928374656574839201 在这里的作用是为合约规划走向合约生命终结的路径，使得这里的资金池合约不论走哪一条路径、走到了哪个状态，都能保持免信任退出的属性。

"OP_CTV này cũng có một ứng dụng rất thú vị khác: 'kênh thanh toán một chiều ẩn danh'. Giả sử Alice tạo ra một nguồn tiền như vậy và đảm bảo rằng tiền có thể rút ra khỏi nó mà không cần sự tin cậy, đến một đầu ra có kịch bản như sau:"

要么， Alice và Bob sẽ cùng chi tiêu nó, hoặc sau một thời gian, Alice có thể chi tiêu một mình

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

OP_Vault và Két sắt

OP_VAULT là một đề xuất điều khoản hạn chế được tạo ra đặc biệt để xây dựng "hợp đồng két sắt (vaults)".

保险柜合约旨在 trở thành một hình thức lưu trữ tự quản an toàn hơn và cao cấp hơn. Mặc dù hợp đồng đa chữ ký hiện tại có thể loại bỏ sự cố điểm đơn lẻ của một khóa riêng, nhưng nếu kẻ tấn công thực sự có được số lượng khóa riêng vượt ngưỡng, chủ sở hữu ví tiền sẽ không có biện pháp phòng vệ. Két an toàn hy vọng có thể áp đặt một giới hạn chi tiêu một lần cho quỹ; đồng thời, khi rút tiền theo đường dẫn thông thường, thao tác rút tiền sẽ bắt buộc thực hiện một thời gian chờ đợi; và trong thời gian chờ đợi, thao tác rút tiền có thể bị ngắt quãng bởi thao tác khôi phục khẩn cấp của ví tiền. Với hợp đồng như vậy, ngay cả khi bị xâm nhập, chủ sở hữu ví tiền cũng có thể tiến hành thao tác phản công (sử dụng chi nhánh phục hồi khẩn cấp).

Lý thuyết, OP_CTV cũng có thể lập trình ra hợp đồng như vậy, nhưng lại có nhiều bất tiện, trong đó một trong số đó là phí giao dịch: cùng với việc cam kết giao dịch, nó cũng cam kết phí giao dịch mà giao dịch đó sẽ trả. Xét đến mục đích của hợp đồng này, thời gian giữa việc thiết lập hợp đồng và rút tiền phải là rất dài, nên gần như không thể dự đoán được phí giao dịch phù hợp. Mặc dù OP_CTV không có giới hạn đầu vào, vì vậy có thể tăng phí giao dịch 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í giao dịch, nên điều đó không thực tế; một cách khác là CPFP, tức là sử dụng tiền đã rút để cung cấp phí giao dịch trong giao dịch mới. Ngoài ra, việc sử dụng OP_CTV cũng có nghĩa là hợp đồng két sắt như vậy không thể rút hàng loạt (đương nhiên cũng không thể khôi phục hàng loạt).

OP_VAULT đề xuất thử nghiệm bằng cách đưa ra các mã hoạt động mới (OP_VAULT và OP_UNVAULT) để giải quyết các vấn đề này. OP_UNVAULT được thiết kế đặc biệt để phục hồi hàng loạt, tuy nhiên chúng tôi tạm thời không đề xuất. Hành động của OP_VAULT như sau: khi chúng ta đặt nó trên một nhánh của cây script, nó có thể được sử dụng để cam kết một mã hoạt động có thể sử dụng (ví dụ OP_CTV) mà không cần thiết lập tham số cụ thể; khi tiêu tốn nhánh này, giao dịch có thể truyền vào các tham số cụ thể, nhưng không thể thay đổi các nhánh khác. Do đó, nó không cần thiết lập phí giao dịch trước, có thể thiết lập phí giao dịch khi tiêu tốn nhánh này; giả sử nhánh này cũng có khóa thời gian, nó sẽ bắt buộc thực hiện một khóa thời gian; cuối cùng, vì chỉ có thể thay đổi nhánh mình đang ở, các nhánh khác trên cây script mới (bao gồm cả nhánh phục hồi khẩn cấp) sẽ không bị thay đổi, do đó cho phép chúng tôi ngừng lại các giao dịch rút tiền như vậy.

此外, còn hai điểm đáng kể: (1) Hành động của mã hoạt động OP_VAULT tương tự như đề xuất một điều khoản hạn chế khác: OP_TLUV; Jeremy Rubin đã đúng khi chỉ ra rằng điều này đã tạo ra một khái niệm "tính toán" trong một mức độ nhất định: OP_TLUV/OP_VAULT đã cam kết một mã hoạt động để cho phép người sử dụng truyền tham số vào mã hoạt động đó qua giao dịch mới, từ đó cập nhật toàn bộ cây script lá; điều này không còn là "xác minh dữ liệu đầu vào dựa trên điều kiện nhất định" nữa mà là "tạo ra dữ liệu mới có ý nghĩa dựa trên dữ liệu đầu vào", mặc dù phạm vi tính toán mà nó có thể kích hoạt khá hạn chế.

完整的 OP_VAULT đề xuất cũng sử dụng một số đề xuất về chính sách giao dịch của bể giao dịch (ví dụ như giao dịch định dạng v3) để đạt được hiệu quả tốt hơn. Điều này nhắc chúng ta rằng ý nghĩa của "lập trình" có thể rộng hơn những gì chúng ta tưởng tượng. (Một ví dụ tương tự là Open Transaction trong Nervos Network.)

Năm. Hiểu về CKB

Trong hai phần trên, chúng tôi đã giới thiệu cách chúng ta có thể sử dụng kịch bản để lập trình các ứng dụng thú vị trên một cấu trúc hạn chế hơn (Bitcoin UTXO) và đã giới thiệu các đề xuất để thêm khả năng tự phản ánh cho cấu trúc này.

UTXO mặc dù có khả năng lập trình các ứng dụng này, nhưng người đọc cũng rất dễ nhận thấy nhược điểm của chúng hoặc các điểm có thể được tối ưu hóa, ví dụ như:

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

实际上，Bitcoin cộng đồng đã đưa ra câu trả lời cho những vấn đề này, và nó liên quan chặt chẽ đến một đề xuất Sighash (BIP-118 AnyPrevOut).

但 nếu chúng ta đang lập trình trên CKB, thì BIP-118 sẽ trở nên khả dụng ngay bây giờ (có thể mô phỏng được nhãn Sighash này bằng khả năng nội suy và xác minh chữ ký hướng đối tượng).

通过 vi学习 Bitcoin vi编程，我们不仅知道了 “交易输出” 这种格式下可以如何编程（CKB 能编程什么），还能知道这些应用的改进方法（如果我们在 CKB 上编程这些应用，可以如何运用 CKB 的能力来改进它们）。对于 CKB 开发者来说，简直可以将基于 Bitcoin 脚本的编程当成一种学习的教材，甚至是捷径。

下面, chúng ta sẽ phân tích từng mô-đun của CKB theo khả năng lập trình. Trước hết, chúng ta sẽ không xem xét khả năng tự kiểm tra.

Khả năng lập trình khóa tính toán tùy ý

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

此外, khả năng tính toán xác minh cho bất kỳ tính toán nào cũng giúp Lock có thể sử dụng nhiều phương tiện xác minh danh tính hơn UTXO, linh hoạt hơn. Ví dụ, chúng ta có thể triển khai một kênh Lightning trên CKB với một bên sử dụng chữ ký ECDSA và bên kia sử dụng chữ ký RSA.

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

此外, Lock cũng có thể thực hiện đề xuất eltoo, từ đó thực hiện kênh Lightning chỉ cần giữ lại giao dịch cam kết mới nhất (thực tế, eltoo có thể đơn giản hóa tất cả các hợp đồng ngang hàng).

Khả năng lập trình loại bất kỳ

Như đã nói ở trên, một trong những ứng dụng quan trọng của Type là lập trình UDT. Kết hợp với Lock, điều này có nghĩa là chúng ta có thể triển khai các kênh thanh toán siêu nhanh dựa trên UDT (và các loại hợp đồng khác).

实际上，Lock 和 Type 的分割可以视为一种安全性升级：Lock 专注于实现保管方法或者合约式协议，而 Type 专注于 UDT 的定义。

此外，nhờ khả năng kiểm tra khởi động dựa trên định nghĩa của UDT, UDT cũng cho phép tham gia hợp đồng một cách tương tự như CKB (UDT là công dân ưu tú).

Ví dụ: Tác giả đã đề xuất một giao thức đảm bảo cho vay NFT không cần tin cậy trên Bitcoin. Giao thức này dựa trên giao dịch cam kết, giá trị đầu vào của nó nhỏ hơn giá trị đầu ra (do đó, nó không được coi là một giao dịch hợp lệ), nhưng một khi có đủ giá trị đầu vào cho giao dịch này, nó sẽ trở thành một giao dịch hợp lệ: Ngay khi người vay có thể thanh toán, người cho vay không thể chiếm đoạt NFT thế chấp. Tuy nhiên, tính không cần tin cậy của giao dịch cam kết này dựa trên việc kiểm tra số tiền đầu vào và đầu ra của cặp giao dịch, vì vậy người vay chỉ có thể thanh toán bằng Bitcoin - ngay cả khi người vay và người cho vay đều đồng ý chấp nhận một loại tiền tệ khác (ví dụ như USDT được phát hành bằng giao thức RGB), giao dịch cam kết của Bitcoin cũng không thể đảm bảo rằng chỉ cần người vay trả đủ USDT thì sẽ nhận lại được NFT của mình, vì giao dịch Bitcoin hoàn toàn không biết về trạng thái của USDT! (Sửa đổi: Nói cách khác, không thể xây dựng một giao dịch cam kết với điều kiện trả lại bằng USDT.)

Nếu chúng ta có thể khởi động kiểm tra dựa trên định nghĩa của UDT, người cho vay sẽ có thể ký một giao dịch cam kết khác, cho phép người vay sử dụng USDT để thanh toán khoản vay. Giao dịch sẽ kiểm tra số lượng USDT đầu vào và số lượng USDT đầu ra, từ đó tạo điều kiện cho việc sử dụng USDT để thanh toán mà không cần tin cậy.

修订：假定这里用作抵押的 NFT 和用于还款的 token 是使用同一套协议（比如 RGB）发行的，那么，这里的问题是能够解决的， 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 để đồng bộ hóa việc chuyển đổi trạng thái của NFT và việc thanh toán (sử dụng giao thức RGB để ràng buộc hai chuyển đổi trạng thái trong một giao dịch). Tuy nhiên, do giao dịch RGB cũng phụ thuộc vào giao dịch Bitcoin, việc xây dựng giao dịch cam kết ở đây sẽ gặp phải một số khó khăn nhất định. Tóm lại, mặc dù vấn đề có thể được giải quyết, nhưng không thể đảm bảo token là công dân ưu tú.

接下来我们再考虑内省能力。

Lock 读取其它 Lock s

Sau khi thực hiện đề xuất các điều khoản hạn chế này, điều này đồng nghĩa với việc mọi khả năng lập trình trên UTXO của Bitcoin sẽ bị hạn chế. Bao gồm cả hợp đồng kho bảo mật đã được đề cập ở trên và các ứng dụng dựa trên OP_CTV (như kiểm soát tắc nghẽn).

XueJie đã đưa ra một ví dụ rất thú vị: Bạn có thể triển khai một tài khoản thu tiền Cell trên CKB. Khi sử dụng Cell này như một đầu vào giao dịch, nếu Cell đầu ra (sử dụng cùng một Lock) có dung lượng lớn hơn, thì đầu vào này không cần cung cấp chữ ký và không ảnh hưởng đến tính hợp lệ của giao dịch. Trên thực tế, nếu không có khả năng tự phân tích, Cell này không thể được triển khai. Tài khoản thu tiền Cell này rất phù hợp cho các tổ chức để thu tiền, vì nó có thể tổng hợp các quỹ lại, nhược điểm là tính riêng tư của nó không tốt.

Khóa 01928374656574839201

Một ứng dụng thú vị của khả năng này là Token chứng quyền sở hữu. Lock sẽ quyết định khả năng sử dụng của chính nó dựa trên số lượng Token trong các đầu vào khác, cũng như khả năng chi tiêu của những khả năng này (yêu cầu khả năng tự suy nghĩ của Lock).

Loại 读取其它 Lock s

不 chắc chắn, nhưng có thể giả định là hữu ích. Ví dụ, có thể kiểm tra Lock s của đầu vào và đầu ra của giao dịch trong Type để đảm bảo 01928374656574839201 không thay đổi.

Đọc các loại Type Scirpt khác (và Data)

集换卡？集齐 n 个 token 可以换取更大的一个 token : )

Sáu. Kết luận

与此前出现的可编程任意计算的智能合约系统（如以太坊）相比，Nervos Network 采取了不同的结构；因此，对以往那些智能合约系统的了解，往往难以成为理解 Nervos Network 的基础。本文从一种比 CKB Cell 更为受限的结构 —— BTC UTXO —— 的应用编程出发，提出了一种理解 CKB Cell 可编程性的方法。并且，运用 “内省” 的概念来理解 Cell 的 “跨合约访问” 的能力，我们可以划分运用内省能力的情形，并为它们确定具体的用途。

"Chỉnh sửa:"

1. Không quan tâm đến khả năng truy cập chéo của Cell (nghĩa là khả năng tự kiểm tra), lock s có thể coi là Bitcoin với trạng thái và khả năng lập trình cực kỳ tinh vi, vì vậy chỉ bằng một điểm này đã đủ để lập trình tất cả các ứng dụng dựa trên Bitcoin.

2. Không xem xét khả năng truy cập chéo của Cell (tức là khả năng tự nội), việc phân biệt lock s và type s có thể coi là một cách nâng cấp tính an toàn: nó phân chia định nghĩa tài sản UDT và phương pháp bảo quản; ngoài ra, việc tiết lộ trạng thái của type s (cũng như Data) thực hiện hiệu quả UDT là công dân hàng đầu.

Trên đây có nghĩa là một cái gì đó mạnh mẽ hơn với cùng một mô hình như "BTC + RGB" nhưng có khả năng lập trình mạnh mẽ hơn;

3. Xét đến khả năng tự suy nghĩ của Cell, Cell có thể có khả năng lập trình mạnh mẽ hơn UTXO BTC sau các điều khoản và thực hiện những điều mà BTC + RGB khó thực hiện (vì BTC không thể đọc trạng thái RGB).

Về những ứng dụng này, bài viết không thể đưa ra nhiều ví dụ cụ thể, nhưng điều này là do sự thiếu hiểu biết của tác giả về hệ sinh thái CKB. Theo thời gian, tôi tin rằng mọi người sẽ đầu tư ngày càng nhiều sự sáng tạo vào đó, tạo ra những ứng dụng khó tưởng tượng ngày nay.

致谢

Cảm ơn Retric, Jan Xie và Xue Jie đã đóng góp phản hồi trong quá trình viết bài. Tất nhiên, tất cả các lỗi trong bài đều do tôi chịu trách nhiệm.

参考文献： -> Tài liệu tham khảo:

5.\_07\_05\_giới\_thiệu\_về\_mô\_hình\_xác\_minh\_lập\_trình\_ckb/

6.（二）Cẩn thận hợp đồng nhật ký (DLC)

13.\_QUESTION/discussions/7