RGB++ và liên kết đẳng cấu: Cách CKB, Cardano và Fuel trao quyền cho hệ sinh thái Bitcoin

Tác giả: Shew, geek web3

Biên tập viên: Faust, đam mê web3

Tóm tắt:***·**Giao thức tài sản RGB++ do nhóm CKB đề xuất đề xuất ý tưởng về **“ràng buộc đẳng hình”. Bản chất của nó là kết hợp CKB với Cardano, Fuel và các chuỗi khối khác dựa trên UTXO Là một lớp mở rộng chức năng mang các “thùng chứa” tài sản RGB. **Ràng buộc đẳng hình này cũng có thể áp dụng cho các giao thức tài sản sinh thái Bitcoin có đặc điểm UTXO như Atomical và Runes, giúp dễ dàng xây dựng lớp hợp đồng thông minh ngoài chuỗi cho Bitcoin.

*******Trong giao thức RGB++, người dùng không cần phải chạy ứng dụng khách để xác minh dữ liệu giao dịch một cách cá nhân mà có thể chuyển giao công việc xác minh tính hợp lệ của tài sản và lưu trữ dữ liệu cho các chuỗi UTXO như CKB và Cardanao. Chỉ cần bạn “lạc quan” và tin rằng tính bảo mật của các chuỗi công khai trên là tương đối đáng tin cậy thì không cần phải tự mình xác minh;

*******Giao thức RGB++ hỗ trợ người dùng chuyển về chế độ xác minh ứng dụng khách, tại thời điểm này, bạn vẫn có thể sử dụng CKB làm lớp lưu trữ dữ liệu/DA mà không cần phải tự giữ dữ liệu. Giao thức RGB++ không yêu cầu tài sản chuỗi chéo và có thể vận hành tài sản trên chuỗi CKB thông qua tài khoản Bitcoin, đồng thời có thể giảm tần suất đưa ra Cam kết đối với chuỗi Bitcoin, điều này cũng có lợi cho việc hỗ trợ các kịch bản Defi;

*******Nếu nằm trong hệ thống hợp đồng EVM, nhiều tính năng của RGB++ không dễ hỗ trợ. Được kết hợp với nhau, lớp mở rộng chức năng/chuỗi công khai phù hợp để thực hiện liên kết đẳng cấu phải có các đặc điểm sau:

**1.**Sử dụng mô hình UTXO hoặc sơ đồ lưu trữ trạng thái tương tự;

2. Nó có khả năng lập trình UTXO đáng kể, cho phép các nhà phát triển viết các tập lệnh mở khóa;

3. Có một không gian trạng thái liên quan đến UTXO có thể lưu trữ trạng thái nội dung;

4. Có thể hỗ trợ chạy các nút ánh sáng Bitcoin thông qua hợp đồng thông minh hoặc các phương tiện khác;

*********Ngoài CKB, Cardano và Fuel cũng có thể hỗ trợ liên kết đẳng cấu **Tuy nhiên, hai cái sau có thể có một số hạn chế về ngôn ngữ hợp đồng thông minh và chi tiết thiết kế hợp đồng. Hiện tại, CKB kém hơn CKB Cả hai đều phù hợp hơn khi làm lớp mở rộng chức năng của các giao thức tài sản Bitcoin bị ràng buộc đẳng cấu.

Văn bản: Trong LightPaper giao thức RGB++, Cipher, người đồng sáng lập Nervos CKB, lần đầu tiên đề xuất ý tưởng sản phẩm về liên kết đẳng cấu. So với các giải pháp Bitcoin Lớp 2 khác, liên kết đẳng hình có thể tương thích tốt hơn với các giao thức tài sản như RGB, Runes và Atomical, đồng thời có thể tránh được các yếu tố như tài sản chuỗi chéo mang lại thêm gánh nặng bảo mật.

Nói một cách đơn giản, liên kết đẳng cấu sử dụng UTXO trên chuỗi CKB và Cardano làm “vùng chứa” để thể hiện các nội dung UTXO như RGB, từ đó bổ sung khả năng lập trình và các kịch bản phức tạp hơn. Trước đây, Geek web3 đã tóm tắt một loạt chuỗi khối hỗ trợ UTXO có thể lập trình trong “Từ BTC đến Sui, ADA và Nervos: Mô hình UTXO và các tiện ích mở rộng liên quan”. Bài viết này sẽ khám phá thêm liệu các chuỗi khối này có thể thích ứng với cùng một sơ đồ liên kết Cấu trúc hay không.

RGB++ và liên kết đẳng cấu

Trước khi phân tích khả năng tương thích của các chuỗi UTXO khác nhau với liên kết đẳng cấu, trước tiên chúng ta phải đưa ra nguyên tắc liên kết đẳng cấu. Liên kết đẳng cấu là một khái niệm được nhóm CKB đề xuất trong giao thức RGB++, vì vậy ở đây chúng tôi sử dụng quy trình làm việc RGB++ để giới thiệu liên kết đẳng cấu dựa trên CKB là gì.

Trước khi giới thiệu giao thức RGB++, chúng ta hãy hiểu ngắn gọn về giao thức RGB. RGB là một giao thức tài sản/mạng P2P chạy trong chuỗi Bitcoin, hơi giống Lightning Network. Ngoài ra, RGB cũng là một giao thức tài sản ký sinh dựa trên Bitcoin UTXO. Cái gọi là ký sinh có nghĩa là máy khách RGB sẽ khai báo theo chuỗi Bitcoin mà UTXO trên chuỗi Bitcoin nhất định bị ràng buộc với một số tài sản RGB. Bạn có UTXO này, Bạn cũng có thể tùy ý sử dụng nội dung RGB gắn liền với nó.

Giao thức RGB và các giao thức tài sản như ERC-20 hoạt động theo những cách rất khác nhau. Hợp đồng ERC-20 trên Ethereum ghi lại trạng thái tài sản của tất cả người dùng và ứng dụng khách nút Ethereum sẽ đồng bộ hóa và xác minh tất cả thông tin chuyển khoản, đồng thời ghi lại các cập nhật trạng thái sau khi chuyển trong hợp đồng tài sản. Điều này thực sự đã được mọi người biết đến từ lâu và không gì khác hơn là dựa vào quy trình đồng thuận của Ethereum để đảm bảo rằng việc thay đổi trạng thái của tài sản diễn ra suôn sẻ. Vì sự đồng thuận của các nút Ethereum rất đáng tin cậy nên người dùng có thể mặc định sử dụng nền tảng lưu ký tài sản dựa trên hợp đồng ERC-20 là “không có vấn đề gì” ngay cả khi họ không chạy ứng dụng khách.

Nhưng giao thức RGB rất lạ, để tăng cường quyền riêng tư, nó chỉ cần xóa sự đồng thuận của nút/máy khách, đây là một điều thông thường trong thế giới blockchain. Người dùng phải tự chạy ứng dụng khách RGB và chỉ nhận và lưu trữ “dữ liệu tài sản liên quan đến mình”. Họ không thể xem những gì người khác đã làm. Không giống như Ethereum và ERC-20, tất cả đều có hồ sơ chuyển nhượng hiển thị trên chuỗi.

Trong trường hợp này, nếu ai đó chuyển một số tài sản RGB cho bạn, bạn sẽ không biết trước số tiền được tạo ra như thế nào và số tiền đó đã được đổi chủ từ ai. Nếu người ở phía bên kia tuyên bố một tài sản bất ngờ và sau đó chuyển một phần tài sản đó cho bạn, bạn sẽ xử lý thế nào với tình huống xấu xa về việc làm giả tiền này?

Giao thức RGB áp dụng ý tưởng này: trước khi mỗi lần chuyển tiền có hiệu lực, trước tiên người nhận sẽ yêu cầu người gửi hiển thị toàn bộ lịch sử của nội dung, chẳng hạn như ai đã phát hành những nội dung này từ giai đoạn tạo đến hiện tại và ai đã chuyển chúng ở giữa ., liệu mọi hoạt động chuyển nhượng tài sản xảy ra giữa những người này có vi phạm chuẩn mực kế toán hay không (một người thêm, một người trừ).

Bằng cách này, bạn có thể biết liệu bên kia có đưa cho bạn “tiền nghi vấn” hay không, vì vậy bản chất của RGB là để các bên tham gia giao dịch chạy ứng dụng khách để xác minh. Dựa trên chế độ xác minh ứng dụng khách, nó tương ứng với người có lý trí Giả thuyết trò chơi. Miễn là Nếu các bên liên quan có lý trí và không có vấn đề gì với phần mềm máy khách, thì có thể đảm bảo rằng việc chuyển giao tài sản được đề cập sẽ không có hiệu lực hoặc bị người khác công nhận.

Điều đáng chú ý là giao thức RGB sẽ nén dữ liệu giao dịch trong chuỗi Bitcoin thành Cam kết (về cơ bản là gốc merkle) và tải nó lên chuỗi Bitcoin, điều này sẽ cho phép các bản ghi chuyển khoản trong chuỗi được kết nối trực tiếp với Bitcoin. mạng chính. Thực hiện kết nối.

Do không có sự đồng thuận giữa các khách hàng RGB nên việc phát hành hợp đồng tài sản RGB không thể được truyền bá “cực kỳ đáng tin cậy” đến tất cả các nút. Nhà xuất bản hợp đồng và người dùng chỉ cần tìm hiểu chi tiết về hợp đồng tài sản RGB một cách tự nhiên thông qua bất kỳ hình thức nào như email hoặc Twitter. , hình thức rất giản dị.

Hình bên dưới hiển thị một kịch bản chuyển nội dung RGB độc hại. Với tư cách là người dùng RGB, chúng ta cần lưu trữ hợp đồng thông minh tương ứng với nội dung RGB cục bộ trên máy khách của mình. Khi người khác chuyển tiền cho chúng tôi, chúng tôi có thể biết liệu giao dịch chuyển tiền hiện tại có vi phạm các quy tắc được xác định trong hợp đồng hay không dựa trên nội dung của hợp đồng tài sản được lưu trữ cục bộ. Dựa trên thông tin nguồn tài sản (hồ sơ lịch sử) do bên kia cung cấp, bạn có thể xác nhận xem có vấn đề gì với nguồn tài sản của bên kia hay không (liệu nó có được khai báo đột ngột hay không).

Xem lại quy trình trên, không khó để thấy rằng dữ liệu được nhận và lưu trữ bởi các máy khách RGB khác nhau thường độc lập và bạn thường không biết người khác có tài sản gì và giá trị bao nhiêu. Đổi lại, về cơ bản, những người khác không biết trạng thái tài sản của bạn.

Đây là một đảo dữ liệu điển hình, tức là dữ liệu được mọi người lưu trữ không nhất quán. Mặc dù về mặt lý thuyết nó có thể cải thiện quyền riêng tư nhưng nó cũng mang lại rất nhiều rắc rối. Bạn phải duy trì dữ liệu nội dung RGB cục bộ trên máy khách của mình. Một khi dữ liệu này bị mất sẽ gây ra hậu quả nghiêm trọng (nội dung sẽ không khả dụng). Nhưng trên thực tế, miễn là bạn duy trì tốt dữ liệu cục bộ, giao thức RGB có thể mang lại cho bạn khả năng bảo mật về cơ bản tương đương với mạng chính Bitcoin.

Ngoài ra, giao thức Bi Frost được sử dụng để liên lạc giữa các máy khách RGB sẽ hỗ trợ người dùng giao tiếp p2p với các máy khách khác. Họ có thể mã hóa dữ liệu tài sản của mình và truyền bá sang các nút khác và yêu cầu bên kia giúp lưu trữ dữ liệu đó (lưu ý rằng nó được mã hóa dữ liệu, ngược lại Không biết văn bản rõ ràng). Miễn là bạn không làm mất chìa khóa, khi dữ liệu cục bộ bị mất, bạn có thể khôi phục dữ liệu tài sản mà bạn sở hữu ban đầu thông qua các nút khác trong mạng.

Tuy nhiên, những thiếu sót của giao thức RGB ban đầu vẫn còn rõ ràng, thứ nhất, mỗi giao dịch yêu cầu hai bên liên lạc nhiều lần, bên nhận trước tiên phải xác minh nguồn tài sản của người gửi, sau đó gửi biên nhận để phê duyệt yêu cầu chuyển tiền của người gửi. Trong quá trình này, ít nhất ba tin nhắn phải được chuyển giữa hai bên. Kiểu “chuyển khoản tương tác” này không phù hợp nghiêm trọng với “chuyển khoản không tương tác” mà hầu hết mọi người vẫn quen sử dụng. Bạn có thể tưởng tượng rằng nếu ai đó muốn chuyển tiền cho bạn, họ phải gửi cho bạn dữ liệu giao dịch để kiểm tra và nhận biên lai của bạn? Quá trình chuyển tiền chỉ có thể được hoàn thành sau khi nhận được tin nhắn phải không? (Biểu đồ dòng chảy có thể được nhìn thấy trong bài viết trước)

Thứ hai, hầu hết các kịch bản Defi đều yêu cầu hợp đồng thông minh với dữ liệu minh bạch và trạng thái có thể xác minh được, nhưng giao thức RGB vốn không hỗ trợ các kịch bản như vậy nên rất không thân thiện với Defi; Ngoài ra, người dùng trong giao thức RGB phải chạy ứng dụng khách Để tự xác minh , nếu vô tình nhận được một tài sản đã đổi chủ cho hàng chục nghìn người, thậm chí bạn sẽ cần phải xác minh hồ sơ hàng chục nghìn lần tài sản đó đã đổi chủ. Rõ ràng, việc để người dùng tự giải quyết mọi việc không có lợi cho việc quảng bá và áp dụng sản phẩm.

Đối với những vấn đề trên, giải pháp của RGB++ là cho phép người dùng tự do chuyển đổi giữa chế độ tự xác minh máy khách và chế độ lưu trữ của bên thứ 3. Người dùng có thể giao gánh nặng xác minh và lưu trữ dữ liệu, lưu trữ hợp đồng thông minh, v.v. cho CKB. Người dùng nên lạc quan và tin tưởng rằng chuỗi công khai POW của CKB là đáng tin cậy; nếu một số người có mục tiêu cao hơn về bảo mật và quyền riêng tư, chẳng hạn như các nhà đầu tư lớn với số lượng tài sản lớn, họ cũng có thể quay lại chế độ RGB ban đầu. Điều cần nhấn mạnh ở đây là RGB++ và giao thức RGB gốc về mặt lý thuyết tương thích với nhau và chúng không loại trừ lẫn nhau.

Trong bài viết trước “Từ RGB đến RGB++: Cách CKB trao quyền cho Giao thức tài sản sinh thái Bitcoin”, chúng tôi đã phổ biến ngắn gọn “ràng buộc đẳng cấu” của RGB++. Sau đây chúng tôi sẽ xem xét nhanh:

CKB có UTXO mở rộng của riêng mình được gọi là Cell, có khả năng lập trình tốt hơn UTXO trên chuỗi BTC. “Liên kết đẳng cấu” là sử dụng Ô trên chuỗi CKB làm “vùng chứa” cho dữ liệu nội dung RGB và ghi các tham số chính của nội dung RGB vào Ô.

Vì có mối quan hệ ràng buộc giữa tài sản RGB và Bitcoin UTXO nên dạng logic của tài sản có các đặc điểm của UTXO. Cell, cũng có các đặc tính UTXO, đương nhiên thích hợp làm “vùng chứa” cho nội dung RGB. Bất cứ khi nào một giao dịch nội dung RGB xảy ra, vùng chứa Ô tương ứng cũng có thể hiển thị các đặc điểm tương tự, giống như mối quan hệ giữa các thực thể và bóng tối. Đây là bản chất của “liên kết đẳng cấu”.

Ví dụ: nếu Alice sở hữu 100 mã thông báo RGB và UTXO A trên chuỗi Bitcoin và có một Ô trên chuỗi CKB thì Ô này được đánh dấu bằng “Số dư mã thông báo RGB: 100” và các điều kiện mở khóa có liên quan đến UTXO A. .

Nếu Alice muốn gửi 30 token cho Bob, trước tiên cô ấy có thể tạo Cam kết. Tuyên bố tương ứng là: chuyển 30 token RGB được liên kết với UTXO A cho Bob và chuyển 70 token sang các UTXO khác mà cô ấy kiểm soát.

Sau đó, Alice sử dụng UTXO A trên chuỗi Bitcoin, xuất bản tuyên bố trên và sau đó bắt đầu giao dịch trên chuỗi CKB để sử dụng vùng chứa Cell mang 100 mã thông báo RGB và tạo ra hai vùng chứa mới, một vùng chứa 30 mã thông báo ( gửi tới Bob), một vùng chứa nắm giữ 70 token (do Alice kiểm soát). Trong quá trình này, nhiệm vụ xác minh tính hợp lệ của tài sản của Alice và tính hợp lệ của báo cáo giao dịch được các nút mạng CKB hoàn thành thông qua sự đồng thuận mà không cần sự can thiệp của Bob. CKB hiện hoạt động như một lớp xác minh và lớp DA trong chuỗi Bitcoin.

Điều này tương tự với thực tế là mỗi khi trạng thái của hợp đồng Ethereum ERC-20 thay đổi, người dùng không bắt buộc phải chạy xác minh ứng dụng khách. Nguyên tắc cũng tương tự. Giao thức đồng thuận và mạng nút thay thế xác minh ứng dụng khách. Hơn nữa, dữ liệu tài sản RGB của mọi người được lưu trữ trên chuỗi CKB, có thể xác minh trên toàn cầu, điều này có lợi cho việc triển khai các kịch bản Defi, chẳng hạn như nhóm thanh khoản và giao thức cầm cố tài sản.

Điều này thực sự đưa ra một giả định tin cậy quan trọng: người dùng có xu hướng lạc quan rằng chuỗi CKB hoặc nền tảng mạng bao gồm một số lượng lớn các nút dựa trên giao thức đồng thuận là đáng tin cậy và không có lỗi. Nếu không tin tưởng CKB, bạn cũng có thể thực hiện theo quy trình xác minh và giao tiếp tương tác trong giao thức RGB gốc và tự chạy ứng dụng khách.

Tất nhiên, nếu ai đó muốn tự mình chạy ứng dụng khách RGB++ và xác minh nguồn lịch sử tài sản của người khác, anh ta có thể trực tiếp xác minh lịch sử liên quan đến ô chứa tài sản RGB trên chuỗi CKB. Miễn là bạn chạy nút ánh sáng CKB và nhận được các tiêu đề khối Merkle Proof và CKB, bạn có thể chắc chắn rằng dữ liệu lịch sử bạn nhận được không bị những kẻ tấn công độc hại trong mạng giả mạo. Có thể nói CKB đóng vai trò là lớp lưu trữ dữ liệu lịch sử tại đây.

Nói một cách đơn giản, liên kết đẳng cấu không chỉ áp dụng cho RGB mà còn cho các giao thức tài sản khác nhau có đặc điểm UTXO như Runes và Atomic. Nó lưu trữ trạng thái tài sản, dữ liệu lịch sử và hợp đồng thông minh tương ứng cục bộ trên máy khách người dùng. đến các chuỗi công khai UTXO như CKB hoặc Cardano để lưu trữ và lưu trữ. Giao thức tài sản loại UTXO được đề cập ở trên có thể sử dụng mô hình UTXO của CKB hoặc Cardano làm “vùng chứa” để hiển thị hình dạng và trạng thái của tài sản thông qua vùng chứa, thuận tiện cho việc khớp các hợp đồng thông minh và các tình huống khác.

Hơn nữa, theo giao thức liên kết đẳng cấu, người dùng có thể trực tiếp sử dụng tài khoản Bitcoin để vận hành vùng chứa tài sản RGB của riêng mình trên các chuỗi UTXO như CKB mà không cần xuyên chuỗi, họ chỉ cần sử dụng các đặc tính UTXO của Cell để đặt điều kiện mở khóa của Cell container. Nó chỉ cần được liên kết với một địa chỉ Bitcoin/Bitcoin UTXO nhất định. Vì chúng tôi đã giải thích các đặc điểm của Cell trong bài viết khoa học phổ biến RGB++ trước đây của Geekweb3 nên chúng tôi sẽ không đi sâu vào chi tiết ở đây.

Nếu cả hai bên tham gia giao dịch tài sản RGB tin tưởng vào tính bảo mật của CKB, họ thậm chí không cần phải thường xuyên xuất bản các Cam kết trên chuỗi Bitcoin. Họ có thể gửi Cam kết tới chuỗi Bitcoin sau khi thực hiện nhiều lần chuyển khoản RGB. Điều này được gọi là "giao dịch gấp " ” Chức năng có thể giảm chi phí sử dụng.

Tuy nhiên, cần lưu ý rằng “container” được sử dụng trong liên kết đẳng cấu thường yêu cầu chuỗi công khai hỗ trợ mô hình UTXO hoặc một infra có đặc điểm tương tự trong bộ lưu trữ trạng thái và chuỗi EVM rõ ràng là không phù hợp và sẽ có các yêu cầu kỹ thuật vấn đề triển khai, gặp nhiều cạm bẫy. Trước hết, như đã đề cập trước đó, RGB++ “có thể vận hành các thùng chứa tài sản trên chuỗi CKB mà không cần chuỗi chéo”, điều này về cơ bản là không thể thực hiện trên chuỗi EVM; ngay cả khi nó bị ép buộc thực hiện, chi phí có thể rất cao;

Hơn nữa, trong giao thức RGB++, nhiều người không cần chạy ứng dụng khách hoặc lưu trữ dữ liệu nội dung cục bộ. Nếu phương pháp ERC-20 được sử dụng để ghi lại số dư tài sản của mọi người trong hợp đồng này, nếu ai đó muốn quay lại chế độ tự xác minh của khách hàng và đề xuất kiểm tra nguồn tài sản của ai đó, lúc này anh ta có thể phải Quét tất cả giao dịch hồ sơ tương tác với hợp đồng tài sản sẽ mang lại áp lực rất lớn.

Nói một cách thẳng thắn, các hợp đồng tài sản như ERC-20 kết hợp và lưu trữ trạng thái tài sản của mọi người, nếu bạn muốn kiểm tra riêng lịch sử thay đổi tài sản của một trong số họ thì sẽ trở nên khó khăn, giống như ở nơi công cộng Trong phòng trò chuyện, nếu muốn biết ai đã gửi tin nhắn cho Vương Cương, bạn phải xem qua bản ghi tin nhắn trong toàn bộ phòng trò chuyện. UTXO giống như một kênh trò chuyện riêng tư 1-1 và rất dễ dàng kiểm tra lịch sử.

Được kết hợp với nhau, lớp mở rộng chức năng/chuỗi công khai phù hợp để thực hiện liên kết đẳng cấu phải có các đặc điểm sau:

1. Sử dụng mô hình UTXO hoặc giải pháp lưu trữ trạng thái tương tự;
2. Nó có khả năng lập trình UTXO đáng kể, cho phép các nhà phát triển viết các tập lệnh mở khóa;
3. Có một không gian trạng thái liên quan đến UTXO có thể lưu trữ trạng thái tài sản;
4. Có cầu nối hoặc nút ánh sáng liên quan đến Bitcoin;

Tất nhiên, chúng tôi cũng hy vọng rằng chuỗi công khai được sử dụng cho liên kết đẳng cấu có tính bảo mật mạnh mẽ. Mặt khác, chúng tôi cũng hy vọng rằng các điều kiện mở khóa UTXO trên chuỗi công khai phải được lập trình để người dùng có thể sử dụng trực tiếp sơ đồ chữ ký của BTC để mở khóa UTXO của bạn bị ràng buộc đồng hình trên các chuỗi công khai khác mà không thay đổi thuật toán chữ ký.

Hiện tại, tập lệnh khóa UTXO trên CKB có thể lập trình được và tập lệnh chính thức cũng tương thích với các sơ đồ chữ ký của các chuỗi công khai khác nhau. Đối với liên kết đẳng hình, mạng **CKB về cơ bản đáp ứng các đặc điểm trên và các đặc điểm dựa trên UTXO khác. dây chuyền? Chúng tôi đã tiến hành kiểm tra sơ bộ Fuel và Cardano và tin rằng về mặt lý thuyết chúng có thể hỗ trợ liên kết đẳng cấu. **

Nhiên liệu: Ethereum OP Rollup dựa trên UTXO

Fuel là một Ethereum OP Rollup dựa trên UTXO và là công ty tiên phong trong việc đưa khái niệm chống gian lận vào hệ sinh thái Ethereum Lớp 2. Để hỗ trợ chức năng UTXO thông thường, Fuel về cơ bản phù hợp với BTC.

Nhiên liệu chia UTXO bên trong thành ba loại sau:

**Tiền đầu vào: **UTXO tiêu chuẩn, được sử dụng để đại diện cho tài sản của người dùng, có khóa thời gian gốc và cho phép người dùng viết vị từ tập lệnh mở khóa;

Hợp đồng đầu vào: UTXO được sử dụng cho lệnh gọi hợp đồng, chứa dữ liệu như gốc trạng thái của hợp đồng và nội dung hợp đồng;

Input Message: UTXO dùng để truyền tải thông tin, chủ yếu bao gồm các trường như người nhận thông tin;

Khi người dùng sử dụng UTXO, kết quả sau sẽ được tạo ra:

Xu ra: Được sử dụng để chuyển tài sản tiêu chuẩn;

Hợp đồng đầu ra: Đầu ra được tạo ra bởi tương tác hợp đồng, chứa gốc trạng thái sau tương tác hợp đồng;

Hợp đồng đầu ra được tạo: Một loại UTXO đặc biệt, là đầu ra được tạo ra khi tạo hợp đồng, chứa ID và trạng thái gốc của hợp đồng;

Không giống như Cell của CKB, chứa tất cả các trạng thái hợp đồng nội bộ, UTXO của Fuel không thực sự chứa tất cả các trạng thái hợp đồng liên quan đến giao dịch. Nhiên liệu chỉ mang Stateroot gốc trạng thái của hợp đồng trong UTXO, là gốc của cây trạng thái. Trạng thái hoàn chỉnh của hợp đồng được lưu trữ bên trong thư viện trạng thái của Fuel và thuộc sở hữu của hợp đồng thông minh.

**Điều đáng nói là để xử lý trạng thái của hợp đồng thông minh, hợp đồng Nhiên liệu và hợp đồng Solidity nhất quán về mặt tư tưởng và thậm chí tương đối gần nhau về hình thức lập trình. **Hình bên dưới hiển thị hợp đồng bộ đếm được viết bằng ngôn ngữ Sway của Fuel. Hợp đồng này chứa bộ đếm. Khi người dùng gọi hàm tăng_counter, bộ đếm được lưu trong hợp đồng sẽ tăng thêm 1.

Chúng ta có thể thấy rằng logic viết của hợp đồng Sway tương tự như logic của hợp đồng Solidity chung. Trước tiên, chúng tôi đưa ra ABI của hợp đồng, sau đó là các biến trạng thái của hợp đồng và sau đó là cách triển khai cụ thể của hợp đồng. Tất cả quy trình viết mã không liên quan đến hệ thống UTXO của Fuel.

Do đó, trải nghiệm lập trình hợp đồng của Fuel khác với các ngôn ngữ lập trình UTXO như CKB và Cardanao. Fuel cung cấp trải nghiệm gần hơn với lập trình và phát triển hợp đồng thông minh EVM. Nhà phát triển cũng có thể sử dụng ngôn ngữ Sway để xây dựng tập lệnh mở khóa nhằm triển khai logic xác minh thuật toán chữ ký đặc biệt hoặc logic mở khóa đa chữ ký phức tạp.

Về cơ bản, việc triển khai liên kết đẳng cấu trong Nhiên liệu là khả thi, nhưng vẫn còn một số vấn đề sau:

Ngôn ngữ lắc lư được Fuel sử dụng gần với chuỗi EVM hơn về thiết kế hợp đồng thông minh so với BTC hoặc CKB và Cardano. Các nhà phát hành tài sản UTXO như RGB và Atomics cần xây dựng một hợp đồng thông minh cụ thể trên Fuel. CKB và các chuỗi khác sử dụng một cái khác, khá phức tạp.

Cardano: chuỗi công khai eUTXO dựa trên POS

Cardaon là một blockchain khác sử dụng mô hình UTXO, nhưng không giống như Fuel, nó là chuỗi công khai Lớp 1. Cardano sử dụng eUTXO (UTXO mở rộng) để chỉ mô hình lập trình UTXO trong hệ thống của mình. So với CKB, eUTXO trong Cardano chứa các cấu trúc sau:

**:**Hợp đồng thông minh, được sử dụng để xác minh xem UTXO có thể được mở khóa và thực hiện chuyển đổi trạng thái hay không;

Người đổi quà: Dữ liệu do người dùng cung cấp để mở khóa UTXO, thường là dữ liệu chữ ký, tương tự như Bitcoin’s Witness;

Dữ liệu: Không gian trạng thái của hợp đồng thông minh, có thể lưu trữ dữ liệu như trạng thái tài sản;

Bối cảnh giao dịch: Dữ liệu ngữ cảnh giao dịch UTXO, chẳng hạn như tham số đầu vào và kết quả của giao dịch (quy trình tính toán giao dịch của chuỗi UTXO được thực hiện trực tiếp ngoài chuỗi và kết quả tính toán được gửi tới chuỗi để xác minh. Nếu họ vượt qua quá trình xác minh, kết quả giao dịch sẽ được tải lên chuỗi. chain)

Các nhà phát triển có thể sử dụng ngôn ngữ PlutusCore để lập trình UTXO trên chuỗi Cardano.Tương tự như CKB, các nhà phát triển có thể viết các tập lệnh mở khóa và một số chức năng để cập nhật trạng thái.

Chúng tôi giới thiệu mô hình lập trình UTXO của Cardano với quy trình đấu giá dựa trên UTXO. Giả sử chúng ta cần triển khai DAPP đấu giá tài sản yêu cầu người dùng đặt giá thầu trước khi cuộc đấu giá kết thúc. Cụ thể, người dùng sử dụng UTXO của riêng mình, ký hợp đồng với UTXO với phiên đấu giá này và sau đó tạo UTXO đấu giá mới. Khi ai đó đưa ra giá thầu cao hơn, ngoài việc tạo UTXO hợp đồng đấu giá mới, UTXO hoàn lại cho người trước đó cũng sẽ được tạo. Quy trình cụ thể như sau:

Để thực hiện quy trình đấu giá trên, một số trạng thái cần được lưu trữ trong UTXO của hợp đồng thông minh đấu giá, chẳng hạn như giá cao nhất của phiên đấu giá hiện tại và người thực hiện giá thầu. Hình bên dưới hiển thị tuyên bố trạng thái bên trong PlutusCore. Chúng ta có thể thấy bBidder và bAmount hiển thị giá thầu đấu giá và địa chỉ ví đã đưa ra giá thầu. Thông số đấu giá chứa thông tin cơ bản của cuộc đấu giá.

Khi người dùng sử dụng UTXO này, chúng tôi có thể cập nhật trạng thái trong hợp đồng. Hình bên dưới hiển thị một số cập nhật trạng thái cụ thể và logic kinh doanh trong hợp đồng đấu giá. Ví dụ: logic xác minh giá thầu của người dùng và xác minh xem phiên đấu giá hiện tại có còn đang diễn ra hay không. Tất nhiên, vì PlutusCore là ngôn ngữ lập trình Haskell, là ngôn ngữ lập trình chức năng thuần túy nên hầu hết các nhà phát triển có thể không hiểu trực tiếp được ý nghĩa của nó. **

**Việc xây dựng liên kết đẳng cấu trên Cardano là khả thi. Chúng tôi có thể sử dụng Datum để lưu trữ trạng thái tài sản và viết các tập lệnh cụ thể để tương thích với các thuật toán chữ ký liên quan đến Bitcoin. Nhưng vấn đề nghiêm trọng là hầu hết các lập trình viên có thể không thích nghi được với việc sử dụng PlutusCore để lập trình theo hợp đồng, và môi trường lập trình của nó khó thiết lập cũng như không thân thiện với các nhà phát triển.

Tóm tắt

Liên kết đẳng cấu yêu cầu chuỗi phải có các thuộc tính sau:

1. Sử dụng mô hình UTXO
2. Có khả năng lập trình UTXO đáng kể, cho phép nhà phát triển viết tập lệnh mở khóa
3. Có một không gian trạng thái liên quan đến UTXO có thể lưu trữ trạng thái tài sản
4. Hỗ trợ hoạt động của các nút nhẹ Bitcoin thông qua hợp đồng thông minh hoặc các phương tiện khác.

Do tính đặc biệt của các ý tưởng lập trình hợp đồng thông minh, Fuel tương thích với liên kết đẳng cấu, nhưng nó vẫn mang lại một số rắc rối; trong khi Cardaon sử dụng ngôn ngữ lập trình Haskell để lập trình hợp đồng, điều này khiến hầu hết các nhà phát triển khó bắt đầu nhanh chóng. Dựa trên những lý do trên, CKB, sử dụng tập lệnh RISC-V và cân bằng hơn về các đặc điểm của lập trình UTXO, có thể là lớp mở rộng chức năng phù hợp hơn cho liên kết đẳng cấu.