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 Bitcoin Script 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òn chia nhỏ các thành phần lập trình của CKB thành các phần phù hợp và giúp chúng ta hiểu được 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 thực hiện khi so sánh các hệ thống blockchain. Tuy nhiên, thường có sự 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à "XX blockchain hỗ trợ các ngôn ngữ lập trình hoàn chỉnh Turing", hoặc, "XX blockchain hỗ trợ lập trình mục đích chung", nhằm chỉ ra rằng "XX blockchain" ở đây có khả năng lập trình mạnh. Có một số sự thật về 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 có. Tuy nhiên, có nhiều khía cạnh đối với các đặ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ố chúng, vì vậy không đủ để hiểu đủ sâu vì thực tế là các nhà phát triển không được hướng dẫn bởi nó và người dùng thông thường không thể dựa vào để phân biệt gian lận.
Các tính năng cấu trúc của hệ thống hợp đồng thông minh bao gồm:
Hình thức cơ bản của biểu hiện trạng thái (hợp đồng) (tài khoản so với sản lượng thương mại)
Có hay không tính toán tùy ý được phép được lập trình (đây là những gì thuật ngữ "Turing-complete" nói về)
Quá trình thực hiện có tạo ra dữ liệu mới không, hay nó chỉ truyền ra booleans? (Tính toán so với Xác thực)
Có hoặc không cho phép các trạng thái bổ sung được ghi lại trong hợp đồng
Hợp đồng có quyền truy cập vào trạng thái của hợp đồng khác khi nó được thực hiện hay không
Do đó, ngoài "tính toán tùy ý có thể lập trình", có ít nhất bốn đặc điểm ả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 tính năng khác này quan trọng hơn, bởi vì chúng xác định ở mức độ sâu hơn những gì dễ đạt được và những gì khó đạt được; Thực hiện kinh tế hơn là gì và thực hiện kém hiệu quả hơn là gì.
Ví dụ, Ethereum thường được trích dẫn như một ví dụ về khả năng lập trình tốt, nhưng hình thức biểu hiện trạng thái cơ bản trên Ethereum là một tài khoản, điều này gây khó khăn cho việc lập trình các hợp đồng ngang hàng (ví dụ: cổng thanh toán, hợp đồng cá cược một-một) – không hoàn toàn không thể, chỉ là vô ơn. Không có gì lạ khi hệ sinh thái Ethereum cố gắng triển khai kênh thanh toán / kênh trạng thái và đã có rất nhiều cuộc thảo luận lý thuyết, nhưng các dự án này dường như không còn hoạt động nữa – và điều này rõ ràng không thể đổ lỗi cho sự thiếu nỗ lực từ phía các nhà phát triển. Không phải ngẫu nhiên mà các dự án hoạt động trên Ethereum ngày nay đang ở dạng "nhóm" thay vì "hợp đồng ngang hàng". Tương tự, mọi người có thể hài lòng với khả năng lập trình của Ethereum, nhưng mô hình tài khoản vốn đã thiếu sót trong việc đạt được "trừu tượng hóa tài khoản" (cũng có thể được hiểu là khái quát hóa khái niệm ví).
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 ở các 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 tính toán tùy ý, 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 hợp đồng khác khi được thực hiện. Tuy nhiên, hình thức của hợp đồng là đầu ra của một giao dịch (được gọi là "tế bào"), điều này làm cho nó khác biệt cơ bản với Ethereum. Do đó, sự hiểu biết về hệ thống hợp đồng thông minh Ethereum và các trường hợp hợp đồng bên trong nó 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 được 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 cơ sở tốt nhất để hiểu khả năng lập trình của CKB. Điều này không chỉ bởi vì hình thức cơ bản của đại diện trạng thái của Bitcoin cũng là đầu ra của các giao dịch (được gọi là "UTXOs"), mà còn bởi vì, với sự trợ giúp của một khái niệm được đề xuất bởi cộng đồng Bitcoin được gọi là "giao ước", chúng ta có thể hiểu tại sao CKB có những đặc điểm cấu trúc này và chia nhỏ hiệu ứng cuối cùng thành nhiều phần một cách thích hợp, xác định mức tăng khả năng lập trình mà mỗi phần mang lại.
II. CKB v.s. BTC: Còn gì nữa?
(1) Cấu trúc cơ bản
Là hình thức cơ bản của đại diện trạng thái của Bitcoin, UTXO của Bitcoin ("Đầu ra giao dịch chưa sử dụng") có hai trường:
Số tiền, bằng Satoshi, cho biết giá trị của Bitcoin mà UTXO sở hữu;
Khóa công khai tập lệnh, còn được gọi là tập lệnh khóa, đại diện cho các điều kiện cần đáp ứng để chi tiêu tiền, nghĩa 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 xuất hiện sau này, Bitcoin Script khá hạn chế:
Nó không cho phép lập trình các tính toán tùy ý; Chỉ có một vài tính toán thực tế có thể được sử dụng để xác minh (kiểm tra chữ ký, kiểm tra trước khi băm, kiểm tra thời gian)
Nó không cho phép các trạng thái bổ sung được ghi lại trong hợp đồng; (Ví dụ: bạn không thể sử dụng tập lệnh để giới hạn số tiền tương ứng/tối đa được chi tiêu tại một thời điểm; Cũng không có cách nào để ẩ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 tại thời điểm thực hiện (mỗi tập lệnh là một vũ trụ riêng biệt và không phụ thuộc vào nhau).
Loại kịch bản này, mặc dù bị hạn chế, nhưng không thiếu khả năng lập trình các ứng dụng tuyệt vời và đó là nền tảng cho việc khám phá khả năng lập trình CKB của chúng tôi. Sẽ có một phần sau đó sẽ giới thiệu hai ví dụ về lập trình Bitcoin Script.
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, thể hiện lượng không gian mà ô có thể chiếm, được đo bằng byte.
Khóa, tương tự như khóa công khai tập lệnh UTXO, xác định quyền sở hữu ô; Chỉ khi dữ liệu được cung cấp có thể đi qua khóa, ô mới có thể được "cập nhật" (hoặc ô có thể được giải phóng và dung lượng có thể được sử dụng để đúc các ô mới);
Dữ liệu, dữ liệu, dữ liệu tùy ý, khối lượng bị giới hạn bởi Dung lượng;
Loại, một tập lệnh tùy chọn đặt điều kiện để cập nhật Dữ liệu.
Ngoài ra, Khóa và Loại có thể được lập trình để tính toán 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ó thể lập trình bất kỳ thuật toán băm nào để kiểm tra trước hình ảnh, v.v.
Thật dễ dàng cho người đọc để xem khả năng lập trình Cell cải thiện như thế nào so với UTXOs:
Các ô có thể được lập trình với các tính toán tùy ý, thay vì chỉ một vài tính toán cụ thể; Xác minh quyền sở hữu của nó sẽ linh hoạt hơn;
Do các trường Dữ liệu và Loại, ô có thể ghi lại các trạng thái bổ sung; Điều này cho phép ô mang cái được 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 ô, lợi ích của hai điểm này là rất, rất đáng kể, nhưng chỉ từ mô tả ở trên, chúng tôi không biết làm thế nào ô đạt được "một hợp đồng truy cập trạng thái của một hợp đồng khác trong thời gian chạy". Để làm điều này, chúng ta cần rút ra một khái niệm đã được thảo luận trong một thời gian dài trong cộng đồng Bitcoin: "giao ước".
(2) Hạn chế và nội tâm
Mục đích ban đầu của một điều khoản hạn chế là giới hạn nơi một khoản tiền có thể được chi tiêu. Trên Bitcoin hiện tại (nơi không có hạn chế nào được đề xuất), một số tiền duy nhất, sau khi mở khóa, có thể được chi tiêu ở bất cứ đâu (nó có thể được trả cho một khóa công khai tập lệnh tùy ý). Nhưng ý tưởng của điều khoản hạn chế là nó có thể được chi tiêu theo cách giới hạn nó ở một số nơi nhất định, ví dụ, một UTXO nhất định sẽ chỉ được chi tiêu bởi một giao dịch nhất định, do đó, ngay cả khi ai đó có thể cung cấp chữ ký cho UTXO, nơi nó có thể được chi tiêu đã được xác định bởi giao dịch đó. Điều này có vẻ hơi lạ, nhưng nó có thể dẫn đến một số ứng dụng thú vị, sẽ được đề cập trong phần sau. Điều quan trọng, nó là chìa khóa để chúng ta hiểu thêm về khả năng lập trình CKB.
Rusty Russell đã chỉ ra một cách đúng đắn rằng hạn chế có thể được hiểu là khả năng giao dịch "nội tâm", tức là khi UTXO A được chi tiêu bởi giao dịch B, nhà điều hành tập lệnh có thể đọc một số (hoặc tất cả) giao dịch B và sau đó kiểm tra xem chúng có khớp với các tham số được yêu cầu trước bởi tập lệnh hay không. Ví dụ: liệu khóa công khai tập lệnh cho đầu ra đầu tiên của giao dịch A có khớp với những gì được yêu cầu bởi khóa công khai tập lệnh của UTXO A hay không (đây là ý nghĩa của hạn chế ban đầu).
Người đọc sắc sảo sẽ nhận ra rằng với sự xem xét nội tâm hoàn toàn, đầ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, cho phép khả năng của một hợp đồng truy cập vào trạng thái của một hợp đồng khác trong thời gian chạy. Trên thực tế, đó chính xác là cách CKB Cell được thiết kế.
Dựa trên điều này, chúng ta có thể chia năng lực nội tâm hoàn chỉnh này thành bốn kịch bản:
Khóa đọc các khóa khác (đầu vào và đầu ra)
Khóa đọc Loại (cũng như Dữ liệu) của cái khác (đầu vào và đầu ra)
Loại đọc các khóa khác (đầu vào và đầu ra)
Loại đọc Loại (và Dữ liệu) của loại khác (đầu vào và đầu ra)
Điều này cho phép chúng tôi phân tích vai trò của các khả năng nội tâm của mỗi phần trong các trường hợp sử dụng khác nhau theo các giả định nhất định (phân chia chức năng giữa Khóa và Loại), tức là khả năng lập trình đạt được mà mỗi phần mang lại cho chúng tôi.
Trong hai phần tiếp theo, chúng ta sẽ xem xét lập trình hiện tại (và chưa được đề xuất) của Bitcoin Script và chức năng có thể xảy ra mà hạn chế được đề xuất dự kiến sẽ đạt được, để đưa ra sự hiểu biết cụ thể về cách CKB Cell có thể được lập trình và thực hiện tốt hơn.
III. Lập trình tập lệnh Bitcoin
Trong phần này, chúng tôi sẽ sử dụng "Lightning Channel / Lightning Network" và "Caution Journal Contract (DLC)" làm ví dụ về lập trình ứng dụng dựa trên Bitcoin Script. Trước khi chúng ta đi vào vấn đề đó, chúng ta hãy đưa hai điều vào đó.
(1) OP \ _IF và "Ưu đãi cam kết"
Khái niệm đầu tiên là opcode kiểm soát luồng trong Bitcoin Script, 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 và mục đích 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 bối cảnh của Bitcoin Script, điều này có nghĩa là chúng ta có thể thiết lập nhiều đường dẫn 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ể gán 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ụ, dịch sang tiếng địa phương:
Ngoài ra, Bob có thể tiết lộ hình ảnh đằng sau hàm băm H và đưa ra chữ ký của riêng mình, điều này sẽ tốn tiền
Hoặc, Alice có thể tiêu tiền bằng chữ ký của chính mình sau một thời gian nhất định của T
Cái này "hay là... hay là..." Hiệu quả đạt được thông qua opcode kiểm soát quá trình.
Ưu điểm nổi bật nhất của > HTLC là nó có thể gói nhiều hoạt động lại với nhau và nguyên tử hóa chúng. Ví dụ: nếu Alice muốn đổi BTC lấy CKB với Bob, thì trước tiên Bob có thể đưa ra giá trị băm và tạo HTLC trên Mạng Nervos. Alice sau đó tạo một HTLC trên Bitcoin sử dụng cùng một hàm băm. Ngoài ra, Bob lấy BTC do Alice thanh toán bằng Bitcoin, đồng thời tiết lộ hình ảnh trước, cho phép Alice rút CKB trên Mạng Nervos. Dù bằng cách nào, 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 đường dẫn đa mở khóa này được tăng cường hơn nữa bằng sự ra đời của MAST (Merkle Abstract Syntax Tree): chúng ta có thể biến một đường dẫn mở khóa thành một chiếc lá trên cây Merkle, mỗi lá là độc lập, do đó không còn cần phải sử dụng opcode điều khiển luồng như vậy nữa; Ngoài ra, vì một con đường được tiết lộ mà không làm lộ những con đường khác, chúng ta có thể thêm một 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ề kinh tế.
Khái niệm thứ hai là "cam kết giao dịch". Ý tưởng của một 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 bởi blockchain, cũng có thật và ràng buộc.
Ví dụ: Alice và Bob chia sẻ UTXO yêu cầu cả hai phải ký hợp đồng chi tiêu. Tại thời điểm này, Alice xây dựng một giao dịch để chi tiêu nó, chuyển 60% giá trị của nó cho Bob và phần còn lại cho chính mình; Alice cung cấp chữ ký của riêng mình cho giao dịch, sau đó được gửi cho Bob. Chà, đối với Bob, nó không cần phải được phát tới mạng Bitcoin và nó không cần phải được xác nhận bởi blockchain, và hiệu quả thanh toán của giao dịch này cũng có thật và đáng tin cậy. Bởi vì Alice không thể tự chi tiêu UTXO (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ệ, Bob luôn có thể thêm chữ ký của mình và phát sóng giao dịch để tôn trọng khoả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ệ (ngoài chuỗi) này.
Giao dịch cam kết là một khái niệm cốt lõi của 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 có các tiểu bang, các trạng thái đó được lưu trữ ở đâu và làm thế nào hợp đồng có thể tiến lên một cách an toàn (thay đổi trạng thái)? Các giao dịch cam kết đưa ra một câu trả lời đơn giả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ự cứu trạng thái mà không cần phải hiển thị nó trên blockchain; Vấn đề thay đổi trạng thái của hợp đồng cũng có thể được chuyển thành vấn đề làm thế nào để cập nhật an toàn giao dịch đã cam kết; Ngoài ra, nếu chúng tôi lo ngại về sự nguy hiểm của việc ký kết hợp đồng (ví dụ: ký hợp đồng yêu cầu cả hai bên ký để chi tiêu và có nguy cơ bên kia sẽ không phản hồi và bị mắc kẹt), thì chỉ cần tạo ra một giao dịch cam kết chi phí hợp đồng trước và nhận được chữ ký có thể giảm thiểu rủi ro và loại bỏ niềm tin vào những người tham gia khác.
(2) Kênh sét và mạng sét
Kênh sét là một hợp đồng một-một, trong đó hai bên có thể thanh toán cho nhau số lần không giới hạ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 giao dịch cam kết.
Trong phần giải thích "Giao dịch đã cam kết", chúng tôi đã giới thiệu một kênh thanh toán. Tuy nhiên, loại hợp đồng này, chỉ tận dụng 2-of-2 multisig, chỉ có thể cho phép thanh toán một chiều. Đó là, Alice luôn trả tiền cho Bob, hoặc Bob luôn trả tiền cho Alice cho đến khi anh ta sử dụng hết số dư của mình trong hợp đồng. Nếu đó là thanh toán hai chiều, điều đó có nghĩa là sau khi cập nhật trạng thái, một bên có thể có số dư ít hơn trước, nhưng TA có giao dịch cam kết cuối cùng được ký bởi bên kia - có thể làm gì để ngăn TA phát sóng lời hứa cũ và TA chỉ từ giao dịch cam kết gần đây nhất?
Giải pháp cho vấn đề này với kênh sét được gọi là "LN-Penalty". Bây giờ, giả sử 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ý giao dịch đã hứa và gửi nó cho Bob:
Nhập #0 và 10 BTC:
Đầu ra đa chữ ký Alie-Bob 2-of-2 (tức là hợp đồng kênh)
Đầu ra #0 , 4 BTC:
Alice chữ ký đơn
Đầu ra #1 , 6 BTC:
hoặc
Khóa công khai tạm thời liên kết Alice-Bob #1 chữ ký đơn
hoặc
Khóa thời gian T 1, Bob ký tên đơn
Bob cũng ký một cam kết (tương ứng với giao dịch trên) và gửi nó cho Alice:
Nhập #0 và 10 BTC:
Đầu ra đa chữ ký Alie-Bob 2-of-2 (tức là hợp đồng kênh)
Đầu ra #0 , 6 BTC:
Bob ký tên đơn
Đầu ra #1, 4 BTC:
hoặc
Khóa công khai tạm thời liên kết Bob-Alice #1 chữ ký đơn
hoặc
Khóa thời gian T 1, Alice ký một chữ ký
Bí quyết ở đây nằm ở "khóa công khai tạm thời chung" này, được tạo bằng một trong các khóa công khai của riêng cô ấy và khóa công khai do bên kia cung cấp, ví dụ: khóa công khai tạm thời chung Alice-Bob, được Alice thu được bằng cách sử dụng một trong các khóa công khai của riêng cô ấy và khóa công khai do Bob cung cấp, nhân mỗi khóa với một giá trị băm. Khi một khóa công khai 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 nói với Alice khóa riêng của khóa công khai mà anh ta cung cấp, Alice có thể tính toán khóa riêng của khóa công khai tạm thời được liên kết. - Đây là chìa khóa cho thực tế là Lightning Channel có thể "hoàn tác" trạng thái cũ.
Lần tới khi hai bên muốn cập nhật trạng thái kênh (bắt đầu thanh toán), hai bên trao đổi khóa riêng của khóa công khai tạm thời được cấp cho nhau ở vòng trước. Bằng cách này, người tham gia không còn dám phát sóng giao dịch đã hứa cuối cùng mà họ nhận được: đầu ra của giao dịch hứa hẹn này gán giá trị cho bên của 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 đến; Vì vậy, một 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 tất cả tiền trong đầu ra này. - Đâ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 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 giao dịch cam kết mới và trao cho bên kia; Bên nhận được giao dịch đã hứa đã tiết lộ cho bên kia khóa riêng của khóa công khai tạm thời mà anh ta đã đưa ra trong vòng trước. Chuỗi 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 khi vô hiệu hóa giao dịch cam kết mà họ đã nhận được ở vòng trước và do đó không đáng 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 giao dịch cam kết để thể hiện trạng thái trong hợp đồng, thay đổi số tiền để thể hiện việc thanh toán;
Các giao dịch cam kết luôn có chi phí đầu vào giống nhau (đầu vào yêu cầu cả hai bên cung cấp chữ ký cùng một lúc), vì vậy tất cả các giao dịch cam kết đều cạnh tranh với nhau và chỉ có một giao dịch có thể được xác nhận bởi blockchain.
Hai bên tham gia không ký kết cùng một giao dịch cam kết (mặc dù họ được ghép nối); Và những gì họ ký luôn là một giao dịch có lợi hơn cho bản thân, nói cách khác, giao dịch đã hứa mà người tham gia nhận được luôn bất lợi cho chính họ;
Nhược điểm của việc này là đầu ra gán giá trị cho chính nó có hai đường dẫn mở khóa: một đường dẫn có thể được mở khóa bằng chữ ký riêng của nó, nhưng nó cần đợi một lúc; Đường dẫn khác sử dụng khóa công khai của bên kia, khóa này chỉ được bảo vệ nếu một trong các khóa riêng tạm thời của nó không bị lộ.
Trong mỗi lần thanh toán, hai bên trao đổi khóa riêng tạm thời mà bên kia đã sử dụng ở vòng trước với một giao dịch cam kết mới, để bên bàn giao 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ên "hủy" giao dịch cam kết trước đó và cập nhật tình trạng hợp đồng; (Trên thực tế, các giao dịch được hứa hẹn 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 bị trừng phạt và không dám phát sóng nữa)
Một trong hai bên có thể rút khỏi hợp đồng bất cứ lúc nào với cam kết do bên kia ký; Tuy nhiên, nếu cả hai bên đều sẵn sàng hợp tác, họ có thể ký một thỏa thuận mới để cả hai bên có thể lấy lại tiền ngay lập tức.
Cuối cùng, vì HTLC cũng có thể được đặt trong một giao dịch đã cam kết, 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 con đường bao gồm các kênh sét kết nối trước và sau để tiếp cận Daniel, thì có thể đạt được các khoản thanh toán đa bước không cần tin cậy mà không cần mở kênh với Daniel. Đây là Lightning Network:
Alice -- HTLC --> Bob -- HTLC --> Carol -- HTLC --> Daniel
Alice < -- Preimage -- Bob < -- Preimage -- Carol < -- Preimage -- Daniel
Khi Alice tìm thấy một con đường như vậy và muốn trả tiền cho Daniel, cô ấy yêu cầu Daniel cho một hàm băm để xây dựng một HTLC cho Bob, và nhắc Bob chuyển tiếp một tin nhắn cho Carol và cung cấp cùng một HTLC; Tin nhắn nhắc Carol chuyển tiếp tin nhắn cho Daniel và cung cấp cùng một HTLC. Khi tin tức đến tay Daniel, anh ta tiết lộ hình ảnh trước cho Carol, điều này mang lại cho anh ta giá trị của HTLC và cập nhật trạng thái của hợp đồng. Carol cũng làm như vậy, được Bob trả tiền và cập nhật trạng thái kênh; Cuối cùng, Bob tiết lộ hình ảnh trước cho Alice và cập nhật trạng thái. Do bản chất của HTLC, chuỗi thanh toán này thành công hoặc thất bại cùng nhau, và như vậy, nó không đáng tin cậy.
Lightning Network được tạo thành từ hết kênh này đến kênh khác, mỗi kênh độc lập với nhau. Điều này có nghĩa là Alice chỉ cần biết những gì đang xảy ra trong kênh của cô ấy với Bob, bất kể có bao nhiêu tương tác đã diễn ra trong kênh của người khác, loại tiền tệ mà các tương tác đó sử dụng hoặc thậm chí liệu họ có thực sự sử dụng kênh hay không.
Khả năng mở rộng của Lightning Network không chỉ được phản ánh ở chỗ tốc độ thanh toán trong Lightning Channel chỉ bị giới hạn bởi sự đầu tư tài nguyên phần cứng của cả hai bên, mà còn do lưu trữ trạng thái phi tập trung, một nút duy nhất có thể tận dụng đòn bẩy tối đa với chi phí thấp nhất.
(3) Hãy thận trọng với các hợp đồng tạp chí
Hợp đồng ghi nhật ký cảnh báo (DLC) sử dụng một kỹ thuật mật mã được gọi là "chữ ký chuyển đổi" cho phép Bitcoin Script 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ý bộ điều hợp cho phép chữ ký trở thành chữ ký hợp lệ chỉ sau khi khóa riêng được thêm vào. Lấy ví dụ về chữ ký Schnorr, trong đó dạng tiêu chuẩn của chữ ký Schnorr là (R, s), trong đó:
R = r.G
Giá trị nonce r được sử dụng cho chữ ký được nhân với điểm tạo đường cong elip, cũng có thể nói là khóa công khai của r
s = r + Băm (R || m || P) * p
p là khóa riêng ký và P là khóa công khai
验证签名即验证 s.G = r.G + Hash(R || m || P) * p.G = R + Băm (R || m || P) * PK
Giả sử tôi cung 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 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 minh rằng nó có thể là chữ ký hợp lệ bằng cách chỉ cần biết khóa riêng của R 2, r 2:
s '. G + R 2 = R 1 + Băm (R || m || P) * P + R 2 = R + Băm (R || m || P) * P
Chữ ký bộ điều hợp làm cho tính hợp lệ của chữ ký phụ thuộc vào dữ liệu bí mật và có thể xác minh đượ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 đặt cược vào Green Goblin và Alina để giành chiến thắng tương ứng, với mức cược là 1 BTC. Ngoài ra, Carol, một trang web đánh giá bóng đá, hứa sẽ sử dụng một nonce R_c để đăng một s_c_i có chữ ký của kết quả khi kết quả của trận đấu được công bố.
Có thể thấy, có ba kết quả có thể xảy ra (vì vậy có 3 khả năng cho chữ ký của Carol):
Green Goblin thắng, Alice thắng 1 BTC
Alina thắng và Bob thắng 1 BTC
Hòa, tiền của hai người trở về như cũ
Để làm điều này, cả hai tạo ra một thỏa thuận cam kết cho mỗi kết quả. Ví dụ: giao dịch cam kết mà họ tạo cho kết quả đầu tiên sẽ trông như thế này:
Nhập #0, 2 BTC:
Alie-Bob 2-of-2 đầu ra đa chữ ký (tức là hợp đồng đặt cược)
Đầu ra #0 , 2 BTC:
Alice chữ ký đơn
Tuy nhiên, thay vì (R, s), chữ ký Alice và Bob được tạo cho giao dịch này là chữ ký bộ chuyển đổi (R, s '); Nói cách khác, chữ ký do cả hai bên trao cho nhau không thể được sử dụng trực tiếp để mở khóa hợp đồng, mà phải tiết lộ giá trị bí mật. Giá trị bí mật này là hình ảnh trước của s \ _c \ 1.G, là chữ ký của Carol! Vì giá trị nonce chữ ký của Carol đã được xác định (R_c), s_c_ 1.G có thể được xây dựng (s_c_ 1.G = R_c + Hash(R_c ||). 'Green Goblin chiến thắng' || PK_c) * PK_c)。
Khi kết quả được tiết lộ, giả sử Green Goblin thắng, Carol sẽ cấp chữ ký (R_c, s_c_ 1), để Alice hoặc Bob có thể hoàn thành chữ ký adapter của đối thủ và thêm chữ ký của riêng họ để biến giao dịch trên thành giao dịch hợp lệ và phát nó lên mạng để kích hoạt hiệu ứng thanh toán. Nhưng nếu Green Goblin không thắng, Carol sẽ không đăng s_c__ 1, và thỏa thuận cam kết sẽ không phải là một thỏa thuận hợp lệ.
Và như vậy, cũng như hai giao dịch khác. Bằng cách này, Alice và Bob làm cho việc thực hiện hợp đồng phụ thuộc vào các sự kiện bên ngoài (chính xác là vào việc phát sóng 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 cần phải tin tưởng đố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, có thể được thực hiện theo cách này.
So với các hình thức thực hiện khác, tính năng quan trọng 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 phải 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) Các nhà quan sát on-chain (bao gồm cả Carol) sẽ không thể xác định trang web nào họ đang sử dụng thông qua việc thực hiện hợp đồng của Alice và Bob, hoặc thậm chí hợp đồng của họ là hợp đồng cá cược (không phải là kênh sét).
IV. Giới thiệu về việc áp dụng các hạn chế
(a) OP \ _CTV và kiểm soát tắc nghẽn
Các nhà phát triển của cộng đồng Bitcoin đã đưa ra một số đề 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 trong những đề xuất nổi tiếng nhất là OP \ _CHECKTEMPLATEVERIFY (OP \ _CTV), phổ biến với cộng đồng Bitcoin vì sự đơn giản nhưng linh hoạt với khái niệm đơn giản của nó. Ý tưởng của OP \ _CTV là cam kết một hàm băm trong tập lệnh để hạn chế rằng tiền chỉ có thể được chi tiêu bởi các giao dịch được đại diện bởi hàm băm này; Hàm băm này hứa hẹn đầu ra của giao dịch và hầu hết các trường, nhưng không phải là đầu vào của giao dịch, chỉ có 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ách OP \ _CTV có thể được chứng minh. Trường hợp sử dụng cơ bản của nó là giúp một số lượng lớn người dùng thoát khỏi sàn giao dịch (một môi trường đòi hỏi sự tin tưởng) vào một nhóm; Vì nhóm này sử dụng OP \ _CTV để lập kế hoạch chi tiêu như thế nào trong tương lai, nó đảm bảo rằng người dùng có thể thoát khỏi nhóm một cách đáng tin cậy mà không cần sự trợ giúp của bất kỳ ai; Và bởi vì nhóm này chỉ hoạt động như một UTXO, nó tránh phải trả nhiều phí khi nhu cầu giao dịch trên chuỗi cao (từ n đầu ra đến 1 đầu ra; cũng giảm từ n giao dịch xuống còn 1 giao dịch). Người dùng trong hồ bơi có thể chờ cơ hội thoá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 khỏi 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 chi nhánh 1; Giao dịch được đại diện bởi giá trị 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ỉ rút 3 BTC và gửi 2 BTC còn lại cho Carol.
Điều tương tự cũng xảy ra nếu Bob hoặc Carol muốn rút tiền. Khi rút tiền, họ sẽ chỉ có thể sử dụng các giao dịch có thể vượt qua kiểm tra OP \ _CTV tương ứng, tức là họ sẽ chỉ có thể thanh toán số tiền tương ứng cho mình và sẽ không thể rút tiền tùy tiện; Số tiền còn lại sẽ được đưa vào một nhóm có khóa OP \ _CTV, do đó đảm bảo rằng những người dùng còn lại có thể được đưa ra khỏi nhóm một cách đáng tin cậy, bất kể thứ tự rút tiền.
Trong tóm tắt, vai trò của OP \ _CTV ở đây là lập kế hoạch cho con đường kết thúc vòng đời của hợp đồng cho hợp đồng, để hợp đồng nhóm ở đây có thể duy trì thuộc tính thoát không tin cậy bất kể nó đi theo con đường nào hoặc trạng thái nào.
Ngoài ra còn có một cách sử dụng rất thú vị của OP \ _CTV này: "kênh thanh toán một chiều được ẩn nhưng không được tiết lộ". Giả sử Alice hình thành một nhóm quỹ như vậy và đảm bảo rằng các khoản tiền có thể được rút một cách đáng tin cậy vào một đầu ra với kịch bản sau:
hoặc, Alice và Bob dành nó cùng nhau
hoặc, sau một thời gian, Alice có thể tự chi tiêu
Nếu Alice không tiết lộ nó cho Bob, Bob sẽ không biết rằng một kết quả như vậy tồn tại; Khi Alice tiết lộ nó cho Bob, Bob có thể sử dụng đầu ra như một kênh thanh toán một chiều, nhạy cảm về thời gian mà Alice có thể sử dụng để thanh toán cho Bob ngay lập tức mà không cần phải chờ xác nhận từ blockchain. Bob chỉ đơn giản yêu cầu Alice đưa giao dịch cam kết của mình vào chuỗi trước khi Alice có thể tự chi tiêu.
(b) OP \ _Vault và an toàn
OP \ _VAULT là một đề xuất cho một điều khoản 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ự lưu ký an toà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 một điểm thất bại duy nhất cho một khóa riêng, nhưng nếu kẻ tấn công có được số lượng khóa riêng ngưỡng, chủ sở hữu của ví sẽ bất lực. Vault muốn áp đặt một giới hạn chi tiêu duy nhất cho tiền của bạn; Đồng thời, khi rút tiền từ nó bằng cách sử dụng tuyến đường thông thường, hoạt động rút tiền sẽ thực thi thời gian chờ đợi; Và trong thời gian chờ đợi, hoạt động rút tiền có thể bị gián đoạn bởi hoạt động khôi phục khẩn cấp của ví. Ngay cả khi hợp đồng như vậy bị vi phạm, chủ sở hữu ví có thể bắt đầu hoạt động đối phó (sử dụng chi 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à hoa hồng: trong khi cam kết giao dịch, nó cũng hứa hẹn mức phí mà giao dịch sẽ trả. Với mục đích của hợp đồng này, khoảng thời gian giữa việc thiết lập hợp đồng và rút tiền phải rất dài, vì vậy gần như không thể dự đoán hoa hồng thích hợp. Mặc dù OP \ _CTV không giới hạn đầu vào, vì vậy phí có thể được tăng lên bằng cách tăng đầu vào, nhưng đầu vào được cung cấp đều sẽ trở thành hoa hồng, vì vậy nó không thực tế; Một cách khác là CPFP, đó là cung cấp hoa hồng cho các giao dịch mới bằng cách chi tiêu số tiền đã rút. Ngoài ra, việc sử dụng OP \ _CTV có nghĩa là hợp đồng Vault như vậy không thể được rút hàng loạt (và chắc chắn không thể khôi phục hàng loạ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ế cho khả năng phục hồi hàng loạt, vì vậy chúng tôi sẽ không đề cập đến nó ngay bây giờ. OP \ _VAULT hoạt độ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 để cam kết với một opcode có thể sử dụng được (ví dụ: OP \ _CTV) mà không có các tham số cụ thể; Khi chi tiêu chi nhánh này, các giao dịch có thể được thông qua trong các thông số cụ thể, nhưng không phải các chi nhánh khác. Do đó, nó không phải đặt phí đặt trước và nó có thể được đặt khi chi nhánh được chi tiêu; Giả sử rằng chi nhánh cũng có khóa thời gian, thì nó sẽ thực thi khóa thời gian; Cuối cùng, vì bạn chỉ có thể thay đổi nhánh bạn đang sử dụng và không có nhánh nào khác của cây tập lệnh mới (bao gồm cả nhánh khôi phục khẩn cấp) sẽ bị thay đổi, chúng tôi được phép làm gián đoạn việc rút tiền đó.
Ngoài ra, 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 đúng đắn 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 đầu tiên hứa hẹn một opcode để cho phép người tiêu dùng cập nhật toàn bộ lá cây tập lệnh bằng cách chuyển các tham số đến opcode với một giao dịch mới; Nó không còn là về việc "xác thực dữ liệu đến dựa trên các tiêu chí nhất định", mà là về việc "tạo ra dữ liệu có ý nghĩa mới dựa trên dữ liệu đến", mặc dù tính toán mà nó có thể kích hoạt bị hạn chế.
(2) Đề xuất OP \ _VAULT đầy đủ cũng sử dụng một số đề xuất về chính sách mempool (ví dụ: giao dịch v3) để đạt được kết quả tốt hơn. Điều này nhắc nhở chúng ta rằng ý nghĩa của "lập trình" có thể rộng hơn chúng ta nghĩ. (Một ví dụ tương tự là Giao dịch mở trong Mạng Nervos.) ）
V. Hiểu về CKB
Trong hai phần trên, chúng tôi mô tả cách chúng tôi có thể viết kịch bản các ứng dụng thú vị trên một cấu trúc hạn chế hơn (Bitcoin UTXO); Các đề xuất để cố gắng thêm nội tâm vào một cấu trúc như vậy cũng đã được trình bày.
Mặc dù UTXOs có khả năng lập trình các ứng dụng này, nhưng người đọc dễ dàng phát hiện ra những thiếu sót hoặc lĩnh vực có thể được tối ưu hóa, chẳng hạn như:
Trong LN-Punishment, 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ủ, tạo thành gánh nặng lưu trữ. Nếu có một cơ chế đảm bảo rằng chỉ có giao dịch cam kết gần đây nhất mới có hiệu lực, và giao dịch cam kết cũ thì không, nó có thể loại bỏ gánh nặng này, và nó cũng có thể loại bỏ vấn đề các nút vô tình bị phạt vì nhầm lẫn đặt một giao dịch cam kết cũ hơn trên chuỗi.
Trong DLC, người ta cho rằng có nhiều kết quả có thể xảy ra của sự kiện, và có nhiều chữ ký mà cả hai bên phải tạo ra và bàn giao cho nhau trước, đâ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 bị ràng buộc trực tiếp với khóa công khai, vì vậy vị trí của nó không dễ chuyển nhượng, có cách nào để chuyển vị trí của 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 lập trình trên CKB, BIP-118 sẽ có sẵn ngay bây giờ (các thẻ Sighash như vậy có thể được mô phỏng với khả năng xác minh chữ ký một cách nội tâm và có chủ đích).
Bằng cách học lập trình Bitcoin, chúng ta không chỉ biết cách chúng có thể được lập trình theo định dạng "Đầu ra giao dịch" (những gì có thể được lập trình trong CKB), mà còn biết cách cải thiện các ứng dụng này (và cách chúng ta có thể sử dụng các khả năng của CKB để cải thiện chúng nếu chúng ta lập trình chúng trên CKB). Đối với các nhà phát triển CKB, lập trình dựa trên Bitcoin Script có thể được sử dụng như một tài liệu học tập, hoặc thậm chí là một phím tắt.
Dưới đây, chúng ta hãy phân tích khả năng lập trình của từng mô-đun lập trình CKB từng cái một. Bây giờ chúng ta đừng xem xét nội tâm.
(1) Khóa được tính toán tùy ý có thể lập trình
Như đã đề cập ở trên, UTXO không thể được lập trình để tính toán tùy ý. Mặt khác, Khóa có nghĩa là Khóa có thể lập trình mọi thứ (trước khi triển khai hạn chế) dựa trên UTXO, bao gồm nhưng không giới hạn ở Lightning Channel và DLC được đề cập ở trên.
Ngoài ra, khả năng xác minh tính toán tùy ý này cũng giúp Lock linh hoạt hơn UTXO về phương thức xác thực. Ví dụ: chúng ta có thể triển khai kênh sét trên CKB trong đó một bên ký ECDSA và bên kia sử dụng RSA.
Trên thực tế, đây là một trong những lĩnh vực đầu tiên mà mọi người bắt đầu khám phá tại CKB: sử dụng khả năng xác thực linh hoạt này trong quyền tự lưu ký của người dùng để kích hoạt cái được gọi là "trừu tượng hóa tài khoản" - ủy quyền hợp lệ giao dịch và 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 chi nhánh" và "phương thức xác thực tùy ý". Ví dụ về việc triển khai là: ví joyid, UniPass.
Ngoài ra, Lock có thể thực hiện các đề xuất eltoo, cho phép một kênh sét chỉ cần giữ 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 ngang hàng).
(2) Loại được tính toán tùy ý có thể lập trình
Như đã đề cập ở trên, một trong những ứng dụng lớn của Type là lập trình UDT. Kết hợp với Khóa, điều này có nghĩa là chúng tôi có thể triển khai các kênh sét dựa trên UDT (và các loại hợp đồng khác).
Trên thực tế, sự phân chia giữa Khóa và Loại có thể được coi là một bản nâng cấp bảo mật: Khóa tập trung vào việc thực hiện các phương pháp lưu ký hoặc thỏa thuận hợp đồng, trong khi Type tập trung vào việc xác định 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 để thực hiện cho vay được hỗ trợ NFT không tin cậy trên Bitcoin. Chìa khóa của một giao thức như vậy là một giao dịch được cam kết trong đó giá trị của đầu vào nhỏ hơn giá trị của đầu ra (vì vậy nó chưa phải là một giao dịch hợp lệ), nhưng một khi có thể cung cấp đủ đầu vào cho giao dịch, đó là một giao dịch hợp lệ: một khi người cho vay có thể trả nợ, người cho vay không thể lấy NFT đã đặt cọc cho chính mình. Tuy nhiên, sự không tin cậy của giao dịch cam kết này dựa trên việc giao dịch kiểm tra lượng đầu vào và đầu ra, vì vậy người cho vay chỉ có thể sử dụng Bitcoin để trả nợ - 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ư USDT được phát hành theo giao thức RGB), giao dịch cam kết Bitcoin không đảm bảo rằng người cho vay sẽ nhận lại NFT của họ miễn là người cho vay trả lại toàn bộ số tiền USDT, vì giao dịch Bitcoin 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 một 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, chúng tôi sẽ có thể yêu cầu người cho vay ký một giao dịch cam kết khác cho phép người cho vay sử dụng USDT để hoàn trả khoản vay. Giao dịch sẽ kiểm tra số lượng USDT đã nhập và số lượng USDT đã ra, giúp người dùng hoàn trả không cần 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 và chúng tôi có thể xây dựng một giao dịch cam kết theo giao thức RGB, để quá trình chuyển đổi trạng thái và hoàn trả NFT có thể diễn ra đồng thời (hai lần chuyển đổi trạng thái bị ràng buộc với các giao dịch trong giao thức RGB). Tuy nhiên, do các giao dịch RGB cũng dựa vào giao dịch Bitcoin nên việc xây dựng các giao dịch cam kết tại đây sẽ có phần khó khăn. Nói chung, mặc dù vấn đề có thể được giải quyết, nhưng nó không thể được thực hiện Token là công dân hạng nhất.
Tiếp theo, chúng ta hãy xem xét nội tâm.
(3) Khóa đọc các ổ khóa khác
Điều này có nghĩa là có đầy đủ các khả năng lập trình trên Bitcoin UTXOs sau khi hạn chế được đề xuất được thực hiện. Điều này bao gồm các hợp đồng Vault được đề cập ở trên, cũng như các ứng dụng dựa trên OP \ _CTV (ví dụ: 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 một ô tài khoản thu thập trên CKB, khi sử dụng loại ô này làm đầu vào của giao dịch, nếu ô đầu ra (ô sử dụng cùng một khóa) có dung lượng lớn hơn, thì đầu vào 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ế, loại tế bào này sẽ không thể thực hiện được nếu không có khả năng hướng nội. Ô tài khoản thu tiền này lý tưởng như một phương thức nhận tiền của tổ chức vì nó tập hợp tiền và có nhược điểm là không có ý thức tốt về quyền riêng tư.
(4) Khóa đọc các loại khác (và dữ liệu)
Một ứng dụng thú vị của khả năng này là stake token. Khóa sẽ quyết đị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 mã thông báo trong các đầu vào khác và nơi nó có thể được sử dụng (yêu cầu khả năng kiểm tra nội tâm khóa).
(5) Loại đọc các ổ khóa khác
Không chắc chắn, nhưng nó có thể được giả định hữu ích. Ví dụ: bạn có thể kiểm tra Nhập để đảm bảo rằng Khóa của đầu vào và đầu ra của giao dịch vẫn không thay đổi.
(6) Loại Scirpt đọc các loại khác (và dữ liệu)
Thẻ giao dịch? Thu thập n mã thông báo để đổi lấy mã thông báo lớn hơn :)
VI. Kết luận
So với các hệ thống hợp đồng thông minh trước đây có thể được lập trình với tính toán tùy ý, chẳng hạn như Ethereum, Nervos Network có cấu trúc khác; Do đó, thường rất khó để hiểu Mạng Nervos dựa trên kiến thức về các hệ thống hợp đồng thông minh trong quá khứ. Bài viết này đề xuất một phương pháp để hiểu khả năng lập trình của CKB Cell, 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à, sử dụng khái niệm "hướng nội" để hiểu khả năng "truy cập hợp đồng chéo" của các tế bào, chúng ta có thể phân chia các tình huống trong đó các khả năng nội tâm được sử dụng và xác định cách sử dụng cụ thể của chúng.
Recension:
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), khóa có thể được coi là Bitcoin với khả năng lập trình và trạng thái đã đạt đến cực điểm, để tất cả các ứng dụng dựa trên Bitcoin có thể được lập trình trên cơ sở này;
Bất kể khả năng truy cập chéo (tức là khả năng xem xét nội tâm) của tế bào, sự khác biệt giữa khóa và loại có thể được coi là nâng cấp bảo mật: nó tách biệt định nghĩa tài sản và phương pháp lưu ký của UDT; Ngoài ra, các loại s (và dữ liệu) của trạng thái có thể phơi bày đạt được hiệu quả của UDT là công dân hạng nhất.
Hai điểm trên có nghĩa là một cái gì đó có cùng mô hình với "BTC + RGB" nhưng có nhiều khả năng lập trình hơn;
Xem xét khả năng nội tâm của Cell, Cell có thể có được khả năng lập trình mạnh hơn so với BTC UTXO sau giao ước và thực hiện điều khó đạt được với BTC + RGB (vì BTC không thể đọc trạng thái của RGB)
Không có nhiều ví dụ cụ thể về những cách sử dụng này, nhưng điều này là do tác giả thiếu hiểu biết về hệ sinh thái của CKB. Theo thời gian, người ta tin rằng ngày càng có nhiều trí tưởng tượng được đầu tư vào nó và các ứng dụng không thể tưởng tượng được ngày nay sẽ được kết hợp với nhau.
Lời cảm ơn
Cảm ơn Retric, Jan Xie và Xue Jie vì phản hồi của họ trong quá trình viết bài báo. Tất nhiên, tôi chịu trách nhiệm cho tất cả các lỗi trong văn bản.
Tham khảo
Tài khoản, danh sách truy cập nghiêm ngặt và UTXO
Hạn chế trong Bitcoin: Phân loại để xem xét
Mô hình tế bào
Tóm tắt Nervos CKB
Khả năng lập trình của Bitcoin
Về trừu tượng tài khoản (2022)
Cây cú pháp trừu tượng Bitcoin Merkelized là gì?
BIP 345: Đề xuất OP_VAULT
Giới thiệu về mã opcode hạn chế TLUV
Các thành phần xây dựng hợp đồng được nâng cấp bằng Bitcoin
Eltoo giải thích
Hợp đồng cho vay có bảo đảm NFT dựa trên các giao dịch đã cam kết · btc-nghiên cứu/OP_QUESTION · Thảo luận #7
Liên kết đến bài viết gốc
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Hiểu khả năng lập trình của CKB từ lập trình ứng dụng Bitcoin
Tác giả gốc: Ajian
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 Bitcoin Script 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òn chia nhỏ các thành phần lập trình của CKB thành các phần phù hợp và giúp chúng ta hiểu được 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 thực hiện khi so sánh các hệ thống blockchain. Tuy nhiên, thường có sự 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à "XX blockchain hỗ trợ các ngôn ngữ lập trình hoàn chỉnh Turing", hoặc, "XX blockchain hỗ trợ lập trình mục đích chung", nhằm chỉ ra rằng "XX blockchain" ở đây có khả năng lập trình mạnh. Có một số sự thật về 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 có. Tuy nhiên, có nhiều khía cạnh đối với các đặ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ố chúng, vì vậy không đủ để hiểu đủ sâu vì thực tế là các nhà phát triển không được hướng dẫn bởi nó và người dùng thông thường không thể dựa vào để phân biệt gian lận.
Các tính năng cấu trúc của hệ thống hợp đồng thông minh bao gồm:
Do đó, ngoài "tính toán tùy ý có thể lập trình", có ít nhất bốn đặc điểm ả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 tính năng khác này quan trọng hơn, bởi vì chúng xác định ở mức độ sâu hơn những gì dễ đạt được và những gì khó đạt được; Thực hiện kinh tế hơn là gì và thực hiện kém hiệu quả hơn là gì.
Ví dụ, Ethereum thường được trích dẫn như một ví dụ về khả năng lập trình tốt, nhưng hình thức biểu hiện trạng thái cơ bản trên Ethereum là một tài khoản, điều này gây khó khăn cho việc lập trình các hợp đồng ngang hàng (ví dụ: cổng thanh toán, hợp đồng cá cược một-một) – không hoàn toàn không thể, chỉ là vô ơn. Không có gì lạ khi hệ sinh thái Ethereum cố gắng triển khai kênh thanh toán / kênh trạng thái và đã có rất nhiều cuộc thảo luận lý thuyết, nhưng các dự án này dường như không còn hoạt động nữa – và điều này rõ ràng không thể đổ lỗi cho sự thiếu nỗ lực từ phía các nhà phát triển. Không phải ngẫu nhiên mà các dự án hoạt động trên Ethereum ngày nay đang ở dạng "nhóm" thay vì "hợp đồng ngang hàng". Tương tự, mọi người có thể hài lòng với khả năng lập trình của Ethereum, nhưng mô hình tài khoản vốn đã thiếu sót trong việc đạt được "trừu tượng hóa tài khoản" (cũng có thể được hiểu là khái quát hóa khái niệm ví).
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 ở các 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 tính toán tùy ý, 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 hợp đồng khác khi được thực hiện. Tuy nhiên, hình thức của hợp đồng là đầu ra của một giao dịch (được gọi là "tế bào"), điều này làm cho nó khác biệt cơ bản với Ethereum. Do đó, sự hiểu biết về hệ thống hợp đồng thông minh Ethereum và các trường hợp hợp đồng bên trong nó 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 được 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 cơ sở tốt nhất để hiểu khả năng lập trình của CKB. Điều này không chỉ bởi vì hình thức cơ bản của đại diện trạng thái của Bitcoin cũng là đầu ra của các giao dịch (được gọi là "UTXOs"), mà còn bởi vì, với sự trợ giúp của một khái niệm được đề xuất bởi cộng đồng Bitcoin được gọi là "giao ước", chúng ta có thể hiểu tại sao CKB có những đặc điểm cấu trúc này và chia nhỏ hiệu ứng cuối cùng thành nhiều phần một cách thích hợp, xác định mức tăng khả năng lập trình mà mỗi phần mang lại.
II. CKB v.s. BTC: Còn gì nữa?
(1) Cấu trúc cơ bản
Là hình thức cơ bản của đại diện trạng thái của Bitcoin, UTXO của Bitcoin ("Đầu ra giao dịch chưa sử dụng") có hai trường:
So với các hệ thống hợp đồng thông minh xuất hiện sau này, Bitcoin Script khá hạn chế:
Loại kịch bản này, mặc dù bị hạn chế, nhưng không thiếu khả năng lập trình các ứng dụng tuyệt vời và đó là nền tảng cho việc khám phá khả năng lập trình CKB của chúng tôi. Sẽ có một phần sau đó sẽ giới thiệu hai ví dụ về lập trình Bitcoin Script.
Ngược lại, đơn vị trạng thái của CKB được gọi là "ô" và có bốn trường:
Ngoài ra, Khóa và Loại có thể được lập trình để tính toán 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ó thể lập trình bất kỳ thuật toán băm nào để kiểm tra trước hình ảnh, v.v.
Thật dễ dàng cho người đọc để xem khả năng lập trình Cell cải thiện như thế nào so với UTXOs:
Kết hợp với cấu trúc "đầu ra giao dịch" của chính ô, lợi ích của hai điểm này là rất, rất đáng kể, nhưng chỉ từ mô tả ở trên, chúng tôi không biết làm thế nào ô đạt được "một hợp đồng truy cập trạng thái của một hợp đồng khác trong thời gian chạy". Để làm điều này, chúng ta cần rút ra một khái niệm đã được thảo luận trong một thời gian dài trong cộng đồng Bitcoin: "giao ước".
(2) Hạn chế và nội tâm
Mục đích ban đầu của một điều khoản hạn chế là giới hạn nơi một khoản tiền có thể được chi tiêu. Trên Bitcoin hiện tại (nơi không có hạn chế nào được đề xuất), một số tiền duy nhất, sau khi mở khóa, có thể được chi tiêu ở bất cứ đâu (nó có thể được trả cho một khóa công khai tập lệnh tùy ý). Nhưng ý tưởng của điều khoản hạn chế là nó có thể được chi tiêu theo cách giới hạn nó ở một số nơi nhất định, ví dụ, một UTXO nhất định sẽ chỉ được chi tiêu bởi một giao dịch nhất định, do đó, ngay cả khi ai đó có thể cung cấp chữ ký cho UTXO, nơi nó có thể được chi tiêu đã được xác định bởi giao dịch đó. Điều này có vẻ hơi lạ, nhưng nó có thể dẫn đến một số ứng dụng thú vị, sẽ được đề cập trong phần sau. Điều quan trọng, nó là chìa khóa để chúng ta hiểu thêm về khả năng lập trình CKB.
Rusty Russell đã chỉ ra một cách đúng đắn rằng hạn chế có thể được hiểu là khả năng giao dịch "nội tâm", tức là khi UTXO A được chi tiêu bởi giao dịch B, nhà điều hành tập lệnh có thể đọc một số (hoặc tất cả) giao dịch B và sau đó kiểm tra xem chúng có khớp với các tham số được yêu cầu trước bởi tập lệnh hay không. Ví dụ: liệu khóa công khai tập lệnh cho đầu ra đầu tiên của giao dịch A có khớp với những gì được yêu cầu bởi khóa công khai tập lệnh của UTXO A hay không (đây là ý nghĩa của hạn chế ban đầu).
Người đọc sắc sảo sẽ nhận ra rằng với sự xem xét nội tâm hoàn toàn, đầ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, cho phép khả năng của một hợp đồng truy cập vào trạng thái của một hợp đồng khác trong thời gian chạy. Trên thực tế, đó chính xác là cách CKB Cell được thiết kế.
Dựa trên điều này, chúng ta có thể chia năng lực nội tâm hoàn chỉnh này thành bốn kịch bản:
Điều này cho phép chúng tôi phân tích vai trò của các khả năng nội tâm của mỗi phần trong các trường hợp sử dụng khác nhau theo các giả định nhất định (phân chia chức năng giữa Khóa và Loại), tức là khả năng lập trình đạt được mà mỗi phần mang lại cho chúng tôi.
Trong hai phần tiếp theo, chúng ta sẽ xem xét lập trình hiện tại (và chưa được đề xuất) của Bitcoin Script và chức năng có thể xảy ra mà hạn chế được đề xuất dự kiến sẽ đạt được, để đưa ra sự hiểu biết cụ thể về cách CKB Cell có thể được lập trình và thực hiện tốt hơn.
III. Lập trình tập lệnh Bitcoin
Trong phần này, chúng tôi sẽ sử dụng "Lightning Channel / Lightning Network" và "Caution Journal Contract (DLC)" làm ví dụ về lập trình ứng dụng dựa trên Bitcoin Script. Trước khi chúng ta đi vào vấn đề đó, chúng ta hãy đưa hai điều vào đó.
(1) OP \ _IF và "Ưu đãi cam kết"
Khái niệm đầu tiên là opcode kiểm soát luồng trong Bitcoin Script, 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 và mục đích 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 bối cảnh của Bitcoin Script, điều này có nghĩa là chúng ta có thể thiết lập nhiều đường dẫn 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ể gán 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ụ, dịch sang tiếng địa phương:
Cái này "hay là... hay là..." Hiệu quả đạt được thông qua opcode kiểm soát quá trình.
Ưu điểm nổi bật nhất của > HTLC là nó có thể gói nhiều hoạt động lại với nhau và nguyên tử hóa chúng. Ví dụ: nếu Alice muốn đổi BTC lấy CKB với Bob, thì trước tiên Bob có thể đưa ra giá trị băm và tạo HTLC trên Mạng Nervos. Alice sau đó tạo một HTLC trên Bitcoin sử dụng cùng một hàm băm. Ngoài ra, Bob lấy BTC do Alice thanh toán bằng Bitcoin, đồng thời tiết lộ hình ảnh trước, cho phép Alice rút CKB trên Mạng Nervos. Dù bằng cách nào, 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 đường dẫn đa mở khóa này được tăng cường hơn nữa bằng sự ra đời của MAST (Merkle Abstract Syntax Tree): chúng ta có thể biến một đường dẫn mở khóa thành một chiếc lá trên cây Merkle, mỗi lá là độc lập, do đó không còn cần phải sử dụng opcode điều khiển luồng như vậy nữa; Ngoài ra, vì một con đường được tiết lộ mà không làm lộ những con đường khác, chúng ta có thể thêm một 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ề kinh tế.
Khái niệm thứ hai là "cam kết giao dịch". Ý tưởng của một 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 bởi blockchain, cũng có thật và ràng buộc.
Ví dụ: Alice và Bob chia sẻ UTXO yêu cầu cả hai phải ký hợp đồng chi tiêu. Tại thời điểm này, Alice xây dựng một giao dịch để chi tiêu nó, chuyển 60% giá trị của nó cho Bob và phần còn lại cho chính mình; Alice cung cấp chữ ký của riêng mình cho giao dịch, sau đó được gửi cho Bob. Chà, đối với Bob, nó không cần phải được phát tới mạng Bitcoin và nó không cần phải được xác nhận bởi blockchain, và hiệu quả thanh toán của giao dịch này cũng có thật và đáng tin cậy. Bởi vì Alice không thể tự chi tiêu UTXO (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ệ, Bob luôn có thể thêm chữ ký của mình và phát sóng giao dịch để tôn trọng khoả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ệ (ngoài chuỗi) này.
Giao dịch cam kết là một khái niệm cốt lõi của 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 có các tiểu bang, các trạng thái đó được lưu trữ ở đâu và làm thế nào hợp đồng có thể tiến lên một cách an toàn (thay đổi trạng thái)? Các giao dịch cam kết đưa ra một câu trả lời đơn giả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ự cứu trạng thái mà không cần phải hiển thị nó trên blockchain; Vấn đề thay đổi trạng thái của hợp đồng cũng có thể được chuyển thành vấn đề làm thế nào để cập nhật an toàn giao dịch đã cam kết; Ngoài ra, nếu chúng tôi lo ngại về sự nguy hiểm của việc ký kết hợp đồng (ví dụ: ký hợp đồng yêu cầu cả hai bên ký để chi tiêu và có nguy cơ bên kia sẽ không phản hồi và bị mắc kẹt), thì chỉ cần tạo ra một giao dịch cam kết chi phí hợp đồng trước và nhận được chữ ký có thể giảm thiểu rủi ro và loại bỏ niềm tin vào những người tham gia khác.
(2) Kênh sét và mạng sét
Kênh sét là một hợp đồng một-một, trong đó hai bên có thể thanh toán cho nhau số lần không giới hạ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 giao dịch cam kết.
Trong phần giải thích "Giao dịch đã cam kết", chúng tôi đã giới thiệu một kênh thanh toán. Tuy nhiên, loại hợp đồng này, chỉ tận dụng 2-of-2 multisig, chỉ có thể cho phép thanh toán một chiều. Đó là, Alice luôn trả tiền cho Bob, hoặc Bob luôn trả tiền cho Alice cho đến khi anh ta sử dụng hết số dư của mình trong hợp đồng. Nếu đó là thanh toán hai chiều, điều đó có nghĩa là sau khi cập nhật trạng thái, một bên có thể có số dư ít hơn trước, nhưng TA có giao dịch cam kết cuối cùng được ký bởi bên kia - có thể làm gì để ngăn TA phát sóng lời hứa cũ và TA chỉ từ giao dịch cam kết gần đây nhất?
Giải pháp cho vấn đề này với kênh sét được gọi là "LN-Penalty". Bây giờ, giả sử 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ý giao dịch đã hứa và gửi nó cho Bob:
Bob cũng ký một cam kết (tương ứng với giao dịch trên) và gửi nó cho Alice:
Bí quyết ở đây nằm ở "khóa công khai tạm thời chung" này, được tạo bằng một trong các khóa công khai của riêng cô ấy và khóa công khai do bên kia cung cấp, ví dụ: khóa công khai tạm thời chung Alice-Bob, được Alice thu được bằng cách sử dụng một trong các khóa công khai của riêng cô ấy và khóa công khai do Bob cung cấp, nhân mỗi khóa với một giá trị băm. Khi một khóa công khai 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 nói với Alice khóa riêng của khóa công khai mà anh ta cung cấp, Alice có thể tính toán khóa riêng của khóa công khai tạm thời được liên kết. - Đây là chìa khóa cho thực tế là Lightning Channel có thể "hoàn tác" trạng thái cũ.
Lần tới khi hai bên muốn cập nhật trạng thái kênh (bắt đầu thanh toán), hai bên trao đổi khóa riêng của khóa công khai tạm thời được cấp cho nhau ở vòng trước. Bằng cách này, người tham gia không còn dám phát sóng giao dịch đã hứa cuối cùng mà họ nhận được: đầu ra của giao dịch hứa hẹn này gán giá trị cho bên của 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 đến; Vì vậy, một 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 tất cả tiền trong đầu ra này. - Đâ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 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 giao dịch cam kết mới và trao cho bên kia; Bên nhận được giao dịch đã hứa đã tiết lộ cho bên kia khóa riêng của khóa công khai tạm thời mà anh ta đã đưa ra trong vòng trước. Chuỗi 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 khi vô hiệu hóa giao dịch cam kết mà họ đã nhận được ở vòng trước và do đó không đáng tin cậy.
Tóm lại, các thiết kế chính của kênh sét là:
Cuối cùng, vì HTLC cũng có thể được đặt trong một giao dịch đã cam kết, 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 con đường bao gồm các kênh sét kết nối trước và sau để tiếp cận Daniel, thì có thể đạt được các khoản thanh toán đa bước không cần tin cậy mà không cần mở kênh với Daniel. Đây là Lightning Network:
Khi Alice tìm thấy một con đường như vậy và muốn trả tiền cho Daniel, cô ấy yêu cầu Daniel cho một hàm băm để xây dựng một HTLC cho Bob, và nhắc Bob chuyển tiếp một tin nhắn cho Carol và cung cấp cùng một HTLC; Tin nhắn nhắc Carol chuyển tiếp tin nhắn cho Daniel và cung cấp cùng một HTLC. Khi tin tức đến tay Daniel, anh ta tiết lộ hình ảnh trước cho Carol, điều này mang lại cho anh ta giá trị của HTLC và cập nhật trạng thái của hợp đồng. Carol cũng làm như vậy, được Bob trả tiền và cập nhật trạng thái kênh; Cuối cùng, Bob tiết lộ hình ảnh trước cho Alice và cập nhật trạng thái. Do bản chất của HTLC, chuỗi thanh toán này thành công hoặc thất bại cùng nhau, và như vậy, nó không đáng tin cậy.
Lightning Network được tạo thành từ hết kênh này đến kênh khác, mỗi kênh độc lập với nhau. Điều này có nghĩa là Alice chỉ cần biết những gì đang xảy ra trong kênh của cô ấy với Bob, bất kể có bao nhiêu tương tác đã diễn ra trong kênh của người khác, loại tiền tệ mà các tương tác đó sử dụng hoặc thậm chí liệu họ có thực sự sử dụng kênh hay không.
Khả năng mở rộng của Lightning Network không chỉ được phản ánh ở chỗ tốc độ thanh toán trong Lightning Channel chỉ bị giới hạn bởi sự đầu tư tài nguyên phần cứng của cả hai bên, mà còn do lưu trữ trạng thái phi tập trung, một nút duy nhất có thể tận dụng đòn bẩy tối đa với chi phí thấp nhất.
(3) Hãy thận trọng với các hợp đồng tạp chí
Hợp đồng ghi nhật ký cảnh báo (DLC) sử dụng một kỹ thuật mật mã được gọi là "chữ ký chuyển đổi" cho phép Bitcoin Script 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ý bộ điều hợp cho phép chữ ký trở thành chữ ký hợp lệ chỉ sau khi khóa riêng được thêm vào. Lấy ví dụ về chữ ký Schnorr, trong đó dạng tiêu chuẩn của chữ ký Schnorr là (R, s), trong đó:
Giả sử tôi cung cấp một cặp dữ liệu (R, s ') trong đó:
Rõ ràng, đây không phải là chữ ký Schnorr hợp lệ và nó không 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 minh rằng nó có thể là chữ ký hợp lệ bằng cách chỉ cần biết khóa riêng của R 2, r 2:
Chữ ký bộ điều hợp làm cho tính hợp lệ của chữ ký phụ thuộc vào dữ liệu bí mật và có thể xác minh đượ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 đặt cược vào Green Goblin và Alina để giành chiến thắng tương ứng, với mức cược là 1 BTC. Ngoài ra, Carol, một trang web đánh giá bóng đá, hứa sẽ sử dụng một nonce R_c để đăng một s_c_i có chữ ký của kết quả khi kết quả của trận đấu được công bố.
Có thể thấy, có ba kết quả có thể xảy ra (vì vậy có 3 khả năng cho chữ ký của Carol):
Green Goblin thắng, Alice thắng 1 BTC
Alina thắng và Bob thắng 1 BTC
Hòa, tiền của hai người trở về như cũ
Để làm điều này, cả hai tạo ra một thỏa thuận cam kết cho mỗi kết quả. Ví dụ: giao dịch cam kết mà họ tạo cho kết quả đầu tiên sẽ trông như thế này:
Tuy nhiên, thay vì (R, s), chữ ký Alice và Bob được tạo cho giao dịch này là chữ ký bộ chuyển đổi (R, s '); Nói cách khác, chữ ký do cả hai bên trao cho nhau không thể được sử dụng trực tiếp để mở khóa hợp đồng, mà phải tiết lộ giá trị bí mật. Giá trị bí mật này là hình ảnh trước của s \ _c \ 1.G, là chữ ký của Carol! Vì giá trị nonce chữ ký của Carol đã được xác định (R_c), s_c_ 1.G có thể được xây dựng (s_c_ 1.G = R_c + Hash(R_c ||). 'Green Goblin chiến thắng' || PK_c) * PK_c)。
Khi kết quả được tiết lộ, giả sử Green Goblin thắng, Carol sẽ cấp chữ ký (R_c, s_c_ 1), để Alice hoặc Bob có thể hoàn thành chữ ký adapter của đối thủ và thêm chữ ký của riêng họ để biến giao dịch trên thành giao dịch hợp lệ và phát nó lên mạng để kích hoạt hiệu ứng thanh toán. Nhưng nếu Green Goblin không thắng, Carol sẽ không đăng s_c__ 1, và thỏa thuận cam kết sẽ không phải là một thỏa thuận hợp lệ.
Và như vậy, cũng như hai giao dịch khác. Bằng cách này, Alice và Bob làm cho việc thực hiện hợp đồng phụ thuộc vào các sự kiện bên ngoài (chính xác là vào việc phát sóng 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 cần phải tin tưởng đố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, có thể được thực hiện theo cách này.
So với các hình thức thực hiện khác, tính năng quan trọng 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 phải 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) Các nhà quan sát on-chain (bao gồm cả Carol) sẽ không thể xác định trang web nào họ đang sử dụng thông qua việc thực hiện hợp đồng của Alice và Bob, hoặc thậm chí hợp đồng của họ là hợp đồng cá cược (không phải là kênh sét).
IV. Giới thiệu về việc áp dụng các hạn chế
(a) OP \ _CTV và kiểm soát tắc nghẽn
Các nhà phát triển của cộng đồng Bitcoin đã đưa ra một số đề 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 trong những đề xuất nổi tiếng nhất là OP \ _CHECKTEMPLATEVERIFY (OP \ _CTV), phổ biến với cộng đồng Bitcoin vì sự đơn giản nhưng linh hoạt với khái niệm đơn giản của nó. Ý tưởng của OP \ _CTV là cam kết một hàm băm trong tập lệnh để hạn chế rằng tiền chỉ có thể được chi tiêu bởi các giao dịch được đại diện bởi hàm băm này; Hàm băm này hứa hẹn đầu ra của giao dịch và hầu hết các trường, nhưng không phải là đầu vào của giao dịch, chỉ có 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ách OP \ _CTV có thể được chứng minh. Trường hợp sử dụng cơ bản của nó là giúp một số lượng lớn người dùng thoát khỏi sàn giao dịch (một môi trường đòi hỏi sự tin tưởng) vào một nhóm; Vì nhóm này sử dụng OP \ _CTV để lập kế hoạch chi tiêu như thế nào trong tương lai, nó đảm bảo rằng người dùng có thể thoát khỏi nhóm một cách đáng tin cậy mà không cần sự trợ giúp của bất kỳ ai; Và bởi vì nhóm này chỉ hoạt động như một UTXO, nó tránh phải trả nhiều phí khi nhu cầu giao dịch trên chuỗi cao (từ n đầu ra đến 1 đầu ra; cũng giảm từ n giao dịch xuống còn 1 giao dịch). Người dùng trong hồ bơi có thể chờ cơ hội thoá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 khỏi 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 chi nhánh 1; Giao dịch được đại diện bởi giá trị 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ỉ rút 3 BTC và gửi 2 BTC còn lại cho Carol.
Điều tương tự cũng xảy ra nếu Bob hoặc Carol muốn rút tiền. Khi rút tiền, họ sẽ chỉ có thể sử dụng các giao dịch có thể vượt qua kiểm tra OP \ _CTV tương ứng, tức là họ sẽ chỉ có thể thanh toán số tiền tương ứng cho mình và sẽ không thể rút tiền tùy tiện; Số tiền còn lại sẽ được đưa vào một nhóm có khóa OP \ _CTV, do đó đảm bảo rằng những người dùng còn lại có thể được đưa ra khỏi nhóm một cách đáng tin cậy, bất kể thứ tự rút tiền.
Trong tóm tắt, vai trò của OP \ _CTV ở đây là lập kế hoạch cho con đường kết thúc vòng đời của hợp đồng cho hợp đồng, để hợp đồng nhóm ở đây có thể duy trì thuộc tính thoát không tin cậy bất kể nó đi theo con đường nào hoặc trạng thái nào.
Ngoài ra còn có một cách sử dụng rất thú vị của OP \ _CTV này: "kênh thanh toán một chiều được ẩn nhưng không được tiết lộ". Giả sử Alice hình thành một nhóm quỹ như vậy và đảm bảo rằng các khoản tiền có thể được rút một cách đáng tin cậy vào một đầu ra với kịch bản sau:
Nếu Alice không tiết lộ nó cho Bob, Bob sẽ không biết rằng một kết quả như vậy tồn tại; Khi Alice tiết lộ nó cho Bob, Bob có thể sử dụng đầu ra như một kênh thanh toán một chiều, nhạy cảm về thời gian mà Alice có thể sử dụng để thanh toán cho Bob ngay lập tức mà không cần phải chờ xác nhận từ blockchain. Bob chỉ đơn giản yêu cầu Alice đưa giao dịch cam kết của mình vào chuỗi trước khi Alice có thể tự chi tiêu.
(b) OP \ _Vault và an toàn
OP \ _VAULT là một đề xuất cho một điều khoản 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ự lưu ký an toà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 một điểm thất bại duy nhất cho một khóa riêng, nhưng nếu kẻ tấn công có được số lượng khóa riêng ngưỡng, chủ sở hữu của ví sẽ bất lực. Vault muốn áp đặt một giới hạn chi tiêu duy nhất cho tiền của bạn; Đồng thời, khi rút tiền từ nó bằng cách sử dụng tuyến đường thông thường, hoạt động rút tiền sẽ thực thi thời gian chờ đợi; Và trong thời gian chờ đợi, hoạt động rút tiền có thể bị gián đoạn bởi hoạt động khôi phục khẩn cấp của ví. Ngay cả khi hợp đồng như vậy bị vi phạm, chủ sở hữu ví có thể bắt đầu hoạt động đối phó (sử dụng chi 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à hoa hồng: trong khi cam kết giao dịch, nó cũng hứa hẹn mức phí mà giao dịch sẽ trả. Với mục đích của hợp đồng này, khoảng thời gian giữa việc thiết lập hợp đồng và rút tiền phải rất dài, vì vậy gần như không thể dự đoán hoa hồng thích hợp. Mặc dù OP \ _CTV không giới hạn đầu vào, vì vậy phí có thể được tăng lên bằng cách tăng đầu vào, nhưng đầu vào được cung cấp đều sẽ trở thành hoa hồng, vì vậy nó không thực tế; Một cách khác là CPFP, đó là cung cấp hoa hồng cho các giao dịch mới bằng cách chi tiêu số tiền đã rút. Ngoài ra, việc sử dụng OP \ _CTV có nghĩa là hợp đồng Vault như vậy không thể được rút hàng loạt (và chắc chắn không thể khôi phục hàng loạ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ế cho khả năng phục hồi hàng loạt, vì vậy chúng tôi sẽ không đề cập đến nó ngay bây giờ. OP \ _VAULT hoạt độ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 để cam kết với một opcode có thể sử dụng được (ví dụ: OP \ _CTV) mà không có các tham số cụ thể; Khi chi tiêu chi nhánh này, các giao dịch có thể được thông qua trong các thông số cụ thể, nhưng không phải các chi nhánh khác. Do đó, nó không phải đặt phí đặt trước và nó có thể được đặt khi chi nhánh được chi tiêu; Giả sử rằng chi nhánh cũng có khóa thời gian, thì nó sẽ thực thi khóa thời gian; Cuối cùng, vì bạn chỉ có thể thay đổi nhánh bạn đang sử dụng và không có nhánh nào khác của cây tập lệnh mới (bao gồm cả nhánh khôi phục khẩn cấp) sẽ bị thay đổi, chúng tôi được phép làm gián đoạn việc rút tiền đó.
Ngoài ra, 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 đúng đắn 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 đầu tiên hứa hẹn một opcode để cho phép người tiêu dùng cập nhật toàn bộ lá cây tập lệnh bằng cách chuyển các tham số đến opcode với một giao dịch mới; Nó không còn là về việc "xác thực dữ liệu đến dựa trên các tiêu chí nhất định", mà là về việc "tạo ra dữ liệu có ý nghĩa mới dựa trên dữ liệu đến", mặc dù tính toán mà nó có thể kích hoạt bị hạn chế.
(2) Đề xuất OP \ _VAULT đầy đủ cũng sử dụng một số đề xuất về chính sách mempool (ví dụ: giao dịch v3) để đạt được kết quả tốt hơn. Điều này nhắc nhở chúng ta rằng ý nghĩa của "lập trình" có thể rộng hơn chúng ta nghĩ. (Một ví dụ tương tự là Giao dịch mở trong Mạng Nervos.) ）
V. Hiểu về CKB
Trong hai phần trên, chúng tôi mô tả cách chúng tôi có thể viết kịch bản các ứng dụng thú vị trên một cấu trúc hạn chế hơn (Bitcoin UTXO); Các đề xuất để cố gắng thêm nội tâm vào một cấu trúc như vậy cũng đã được trình bày.
Mặc dù UTXOs có khả năng lập trình các ứng dụng này, nhưng người đọc dễ dàng phát hiện ra những thiếu sót hoặc lĩnh vực có thể được tối ưu hóa, chẳng hạn như:
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 lập trình trên CKB, BIP-118 sẽ có sẵn ngay bây giờ (các thẻ Sighash như vậy có thể được mô phỏng với khả năng xác minh chữ ký một cách nội tâm và có chủ đích).
Bằng cách học lập trình Bitcoin, chúng ta không chỉ biết cách chúng có thể được lập trình theo định dạng "Đầu ra giao dịch" (những gì có thể được lập trình trong CKB), mà còn biết cách cải thiện các ứng dụng này (và cách chúng ta có thể sử dụng các khả năng của CKB để cải thiện chúng nếu chúng ta lập trình chúng trên CKB). Đối với các nhà phát triển CKB, lập trình dựa trên Bitcoin Script có thể được sử dụng như một tài liệu học tập, hoặc thậm chí là một phím tắt.
Dưới đây, chúng ta hãy phân tích khả năng lập trình của từng mô-đun lập trình CKB từng cái một. Bây giờ chúng ta đừng xem xét nội tâm.
(1) Khóa được tính toán tùy ý có thể lập trình
Như đã đề cập ở trên, UTXO không thể được lập trình để tính toán tùy ý. Mặt khác, Khóa có nghĩa là Khóa có thể lập trình mọi thứ (trước khi triển khai hạn chế) dựa trên UTXO, bao gồm nhưng không giới hạn ở Lightning Channel và DLC được đề cập ở trên.
Ngoài ra, khả năng xác minh tính toán tùy ý này cũng giúp Lock linh hoạt hơn UTXO về phương thức xác thực. Ví dụ: chúng ta có thể triển khai kênh sét trên CKB trong đó một bên ký ECDSA và bên kia sử dụng RSA.
Trên thực tế, đây là một trong những lĩnh vực đầu tiên mà mọi người bắt đầu khám phá tại CKB: sử dụng khả năng xác thực linh hoạt này trong quyền tự lưu ký của người dùng để kích hoạt cái được gọi là "trừu tượng hóa tài khoản" - ủy quyền hợp lệ giao dịch và 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 chi nhánh" và "phương thức xác thực tùy ý". Ví dụ về việc triển khai là: ví joyid, UniPass.
Ngoài ra, Lock có thể thực hiện các đề xuất eltoo, cho phép một kênh sét chỉ cần giữ 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 ngang hàng).
(2) Loại được tính toán tùy ý có thể lập trình
Như đã đề cập ở trên, một trong những ứng dụng lớn của Type là lập trình UDT. Kết hợp với Khóa, điều này có nghĩa là chúng tôi có thể triển khai các kênh sét dựa trên UDT (và các loại hợp đồng khác).
Trên thực tế, sự phân chia giữa Khóa và Loại có thể được coi là một bản nâng cấp bảo mật: Khóa tập trung vào việc thực hiện các phương pháp lưu ký hoặc thỏa thuận hợp đồng, trong khi Type tập trung vào việc xác định 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 để thực hiện cho vay được hỗ trợ NFT không tin cậy trên Bitcoin. Chìa khóa của một giao thức như vậy là một giao dịch được cam kết trong đó giá trị của đầu vào nhỏ hơn giá trị của đầu ra (vì vậy nó chưa phải là một giao dịch hợp lệ), nhưng một khi có thể cung cấp đủ đầu vào cho giao dịch, đó là một giao dịch hợp lệ: một khi người cho vay có thể trả nợ, người cho vay không thể lấy NFT đã đặt cọc cho chính mình. Tuy nhiên, sự không tin cậy của giao dịch cam kết này dựa trên việc giao dịch kiểm tra lượng đầu vào và đầu ra, vì vậy người cho vay chỉ có thể sử dụng Bitcoin để trả nợ - 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ư USDT được phát hành theo giao thức RGB), giao dịch cam kết Bitcoin không đảm bảo rằng người cho vay sẽ nhận lại NFT của họ miễn là người cho vay trả lại toàn bộ số tiền USDT, vì giao dịch Bitcoin 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 một 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, chúng tôi sẽ có thể yêu cầu người cho vay ký một giao dịch cam kết khác cho phép người cho vay sử dụng USDT để hoàn trả khoản vay. Giao dịch sẽ kiểm tra số lượng USDT đã nhập và số lượng USDT đã ra, giúp người dùng hoàn trả không cần 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 và chúng tôi có thể xây dựng một giao dịch cam kết theo giao thức RGB, để quá trình chuyển đổi trạng thái và hoàn trả NFT có thể diễn ra đồng thời (hai lần chuyển đổi trạng thái bị ràng buộc với các giao dịch trong giao thức RGB). Tuy nhiên, do các giao dịch RGB cũng dựa vào giao dịch Bitcoin nên việc xây dựng các giao dịch cam kết tại đây sẽ có phần khó khăn. Nói chung, mặc dù vấn đề có thể được giải quyết, nhưng nó không thể được thực hiện Token là công dân hạng nhất.
Tiếp theo, chúng ta hãy xem xét nội tâm.
(3) Khóa đọc các ổ khóa khác
Điều này có nghĩa là có đầy đủ các khả năng lập trình trên Bitcoin UTXOs sau khi hạn chế được đề xuất được thực hiện. Điều này bao gồm các hợp đồng Vault được đề cập ở trên, cũng như các ứng dụng dựa trên OP \ _CTV (ví dụ: 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 một ô tài khoản thu thập trên CKB, khi sử dụng loại ô này làm đầu vào của giao dịch, nếu ô đầu ra (ô sử dụng cùng một khóa) có dung lượng lớn hơn, thì đầu vào 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ế, loại tế bào này sẽ không thể thực hiện được nếu không có khả năng hướng nội. Ô tài khoản thu tiền này lý tưởng như một phương thức nhận tiền của tổ chức vì nó tập hợp tiền và có nhược điểm là không có ý thức tốt về quyền riêng tư.
(4) Khóa đọc các loại khác (và dữ liệu)
Một ứng dụng thú vị của khả năng này là stake token. Khóa sẽ quyết đị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 mã thông báo trong các đầu vào khác và nơi nó có thể được sử dụng (yêu cầu khả năng kiểm tra nội tâm khóa).
(5) Loại đọc các ổ khóa khác
Không chắc chắn, nhưng nó có thể được giả định hữu ích. Ví dụ: bạn có thể kiểm tra Nhập để đảm bảo rằng Khóa của đầu vào và đầu ra của giao dịch vẫn không thay đổi.
(6) Loại Scirpt đọc các loại khác (và dữ liệu)
Thẻ giao dịch? Thu thập n mã thông báo để đổi lấy mã thông báo lớn hơn :)
VI. Kết luận
So với các hệ thống hợp đồng thông minh trước đây có thể được lập trình với tính toán tùy ý, chẳng hạn như Ethereum, Nervos Network có cấu trúc khác; Do đó, thường rất khó để hiểu Mạng Nervos dựa trên kiến thức về các hệ thống hợp đồng thông minh trong quá khứ. Bài viết này đề xuất một phương pháp để hiểu khả năng lập trình của CKB Cell, 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à, sử dụng khái niệm "hướng nội" để hiểu khả năng "truy cập hợp đồng chéo" của các tế bào, chúng ta có thể phân chia các tình huống trong đó các khả năng nội tâm được sử dụng và xác định cách sử dụng cụ thể của chúng.
Recension:
Hai điểm trên có nghĩa là một cái gì đó có cùng mô hình với "BTC + RGB" nhưng có nhiều khả năng lập trình hơn;
Không có nhiều ví dụ cụ thể về những cách sử dụng này, nhưng điều này là do tác giả thiếu hiểu biết về hệ sinh thái của CKB. Theo thời gian, người ta tin rằng ngày càng có nhiều trí tưởng tượng được đầu tư vào nó và các ứng dụng không thể tưởng tượng được ngày nay sẽ được kết hợp với nhau.
Lời cảm ơn
Cảm ơn Retric, Jan Xie và Xue Jie vì phản hồi của họ trong quá trình viết bài báo. Tất nhiên, tôi chịu trách nhiệm cho tất cả các lỗi trong văn bản.
Tham khảo
Tài khoản, danh sách truy cập nghiêm ngặt và UTXO
Hạn chế trong Bitcoin: Phân loại để xem xét
Mô hình tế bào
Tóm tắt Nervos CKB
Khả năng lập trình của Bitcoin
Về trừu tượng tài khoản (2022)
Cây cú pháp trừu tượng Bitcoin Merkelized là gì?
BIP 345: Đề xuất OP_VAULT
Giới thiệu về mã opcode hạn chế TLUV
Các thành phần xây dựng hợp đồng được nâng cấp bằng Bitcoin
Eltoo giải thích
Hợp đồng cho vay có bảo đảm NFT dựa trên các giao dịch đã cam kết · btc-nghiên cứu/OP_QUESTION · Thảo luận #7
Liên kết đến bài viết gốc