RGB++ và liên kết đẳng cấu: CKB, Cardano và Fuel trao quyền cho BTC như thế nào

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. Có khả năng lập trình UTXO đáng kể, cho phép các nhà phát triển viết tập lệnh mở khóa;

3. < /strong>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. Nó có thể hỗ trợ chạy Bitcoin Light thông qua hợp đồng thông minh hoặc các phương tiện khác. p>

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

Trong Giao thức RGB++ LightPaper, người đồng sáng lập Nervos CKB Cipher là người đầu tiên Ý tưởng sản phẩm liên kết đẳng cấu lần đầu tiên được đề xuất. 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, sau đó thêm khả năng lập trình và độ phức tạp hơn cho chúng. Trước đây, Geek web3 đã xuất bản trong "Từ BTC đến Sui, ADA và Nervos: mô hình UTXO và các bản mở rộng liên quan < /a>” đã tóm tắt một loạt chuỗi khối hỗ trợ UTXO có thể lập trình. 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 sơ đồ liên kết đẳng cấu 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 xác định 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à giao thức tài sản/mạng P2P chạy ngoài 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 sở hữu UTXO này và nội dung RGB được liên kết với nó cũng theo ý của bạn.

Giao thức RGB hoạt động hoàn toàn khác với các giao thức nội dung như ERC-20. 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 vấn đề gì" ngay cả khi họ không chạy ứng dụng khách.

NhưngGiao thức RGB rất lạ. Nó là để nâng cao quyền riêng tư, 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 chính họ". Họ không thể xem những gì người khác đã làm. Không giống như Ethereum và ERC-20, mọi thứ đều hiển thị trên chuỗi. Hồ sơ chuyển nhượng.

Trong trường hợp này, nếu ai đó chuyển một số nội dung 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 đối diện bất ngờ tuyên bố một tài sản và sau đó chuyển một phần tài sản đó cho bạn, bạn nên xử lý như thế nào trước tình huống xấu xa về việc làm giả tiền tệ này?

Giao thức RGB áp dụng ý tưởng này: Trước khi mỗi lần chuyển có hiệu lực, trước tiên người nhận sẽ yêu cầu người gửi trình bày toàn bộ lịch sử của nội dung, chẳng hạn như từ Từ giai đoạn hình thành đến nay, ai phát hành, ai thông qua và mỗi lần chuyển nhượng tài sản 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 số tiền bên kia đưa cho bạn có phải là "tiền nghi vấn" hay không, vì vậy bản chất của RGB là để các bên giao dịch tự điều hành khách hàng để xác minh , dựa trên Mô hình xác minh khách hàng,Tương ứng với giả định trò chơi người có lý trí, miễn là các bên liên quan đều hợp lý và phần mềm máy khách vẫn ổn, điều đó có thể đảm bảo rằng việc chuyển giao tài sản có vấn đề không thể có hiệu lực hoặc bị người khác nhận ra .

Đ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, tạo ra các bản ghi chuyển khoản trong chuỗi, liên quan trực tiếp đến mạng chính Bitcoin.

(Biểu đồ luồng tương tác giao thức RGB)

Do thiếu sự đồng thuận giữa các khách hàng RGB, 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ả 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 email hoặc Twitter và biểu mẫu này rất bình thường.

Hình sau đây minh họa 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ữ cục bộ hợp đồng thông minh tương ứng với nội dung RGB 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,có thể xác nhận liệu có bất kỳ vấn đề nào với nguồn tài sản của bên kia hay không (liệu nó có được khai báo bất ngờ hay không).

Nhìn lại quá trình trên, không khó để thấy rằng RGB khác nhau Dữ liệu được khách hàng nhận và lưu trữ 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à chúng có 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 của nội dung RGB cục bộ trên máy khách của mình. Khi những dữ liệu này bị mất, sẽ gây ra hậu quả nghiêm trọng (nội dung không có sẵn). 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 Biblast được sử dụng để liên lạc giữa các máy khách RGB, Nó sẽ hỗ trợ người dùng giao tiếp p2p với các khách hàng khác. Anh ta có thể mã hóa dữ liệu tài sản của mình và truyền bá đến các nút khác và yêu cầu bên kia giúp lưu trữ (lưu ý rằng đó là dữ liệu được mã hóa và bên kia không biết văn bản thô). 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. Đầu tiên, mỗi giao dịch yêu cầu nhiều giao tiếp giữa hai bên. Trước tiên, bên nhận phải xác minh nguồn của người gửi tài sản rồi 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ọ cũng phải gửi cho bạn dữ liệu giao dịch để kiểm tra và bạn nhận được. Quá trình chuyển tiền chỉ có thể được hoàn thành sau khi nhận được tin nhắn biên nhận của bạn phải không? (Có thể xem biểu đồ quy trình ở trên)

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, nhưng giao thức RGB vốn không hỗ trợ các kịch bản như vậy. , nên nó rất không thân thiện với Defi, ngoài ra, trong giao thức RGB, người dùng phải chạy client để tự xác minh. Nếu vô tình nhận được một tài sản được đổi chủ từ hàng chục nghìn người, bạn thậm chí phải xác minh nó Hồ sơ hàng chục ngàn lần tài sản này đã được đổi chủ. Rõ ràng, việc đểtất cả mọi việc cho người dùng tự giải quyết sẽ không có lợi cho việc quảng bá và áp dụng sản phẩm.

Đối với các 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 ứng dụng khách và chế độ lưu trữ của bên thứ ba. Người dùng có thể gánh nặng việc xác minh và lưu trữ dữ liệu, lưu trữ hợp đồng thông minh, v.v. được giao cho CKB. Tất nhiên, người dùng phải lạc quan và tin tưởng rằng CKB, chuỗi công khai POW, 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ư điện thoại di động, Các nhà đầu tư lớn với số lượng tài sản lớn 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.

(Biểu đồ luồng tương tác giao thức RGB++ [phiên bản ngắn])

Trong bài viết trước Trong "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ẽ trình bày nhanh đánh giá:

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 trong tài sản Nó có các đặc điểm của UTXO ở dạng logic. Cell, cũng có các đặc tính UTXO, đương nhiên phù hợp làm "vùng chứa" cho nội dung RGB. Bất cứ khi nào 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.Đâ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". Điều kiện mở khóa là liên quan đến UTXO A.

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

Sau đó, Alice sử dụng UTXO A trên chuỗi Bitcoin, đưa ra 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 theo 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 (đối với Bob) và một mã giữ 70 mã thông báo (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ự như hợp đồng Ethereum ERC-20 mỗi lần Thay đổi trạng thái không yêu cầu người dùng chạy xác minh ứng dụng khách. Nguyên tắc 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óiCKB đó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ư Ngọc và Nguyên tử. trạng thái tài sản cục bộ, dữ liệu lịch sử và hợp đồng thông minh tương ứng trên khách hàng người dùng đều được chuyển sang 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 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" và sử dụng vùng chứa để hiển thị hình dạng và trạng thái của tài sản. Thật thuận tiện khi hợp tác với thông minh hợp đồng và các tình huống khác.

Và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 của mình để vận hành vùng chứa tài sản RGB của riêng họ trên chuỗi UTXO như CKB mà không cần xuyên qua chuỗi. Với sự trợ giúp của Tính năng UTXO của Cell, chỉ cần đặt điều kiện mở khóa của vùng chứa Cell đượ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 đều tin tưởng vào tính bảo mật của CKB, thì họ sẽ tin tưởng thậm chí không cần phải thường xuyên đưa ra Cam kết trên chuỗi Bitcoin. Sau nhiều lần chuyển RGB được thực hiện, một Cam kết có thể được gửi đến chuỗi Bitcoin. Đây được gọi là chức năng "gấp giao dịch", 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 một 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 rất phù hợp, phù hợp thì sẽ có nhiều cạm bẫy trong việc triển khai kỹ thuật. 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" về cơ bản là không thể triển khai 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ố chúng, nó sẽ thay đổi. Điều đó rất khó khăn, giống như đang ở trong một phòng trò chuyện công cộng, 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 sơ đồ lưu trữ trạng thái tương tự;

2. Có khả năng lập trình UTXO đáng kể, cho phép các 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. Có một cầu nối hoặc Light Node 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 chuỗi công khai trên các điều kiện mở khóa UTXO nên có thể lập trình được. Bằng cách này, người dùng có thể trực tiếp sử dụng sơ đồ chữ ký của BTC để mở khóa UTXO bị ràng buộc đẳng hình của họ trên các chuỗi công khai khác mà không cần 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 cấu, mạngCKB về cơ bản tuân thủ các tính năng trên. , còn các chuỗi công khai dựa trên UTXO khác thì sao? 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à Ethereum OP Rollup dựa trên UTXO hoặc khái niệm bằng chứng gian lận A tiên phong trong việc giới thiệu 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 của nó 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;

Thông báo đầu vào:UTXO đã sử dụng được sử dụng để truyền 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ả đầu ra sau sẽ được tạo ra:

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

Hợp đồng đầu ra: Sản lượng đượ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. Nó chứa ID và trạng thái gốc của hợp đồng;

Ô của CKB chứa tất cả trạng thái Hợp đồng là khác nhau. UTXO của Fuel không thực sự mang tất 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àĐối với việc 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 vững chắc 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 dưới đây hiển thị hợp đồng bộ đếm được viết bằng ngôn ngữ Sway của Fuel. Hợp đồng 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 đó đưa ra các biến trạng thái của hợp đồng, rồi đưa ra thực hiện hợp đồng cụ thể. Tất cả quy trình viết mã không liên quan đến hệ thống UTXO của Fuel.

Vì vậy, trải nghiệm lập trình hợp đồng của Fuel khác với lập trình kiểu UTXO như CKB và Cardanao Language, Fuel cung cấp trải nghiệm gần hơn với việc phát triển lập trình 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 Fuel 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 không phù hợp với Mặt khác, ý tưởng này gần với chuỗi EVM hơn là 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 và sử dụng một hợp đồng khác trên các chuỗi như CKB Cái này khá phức tạp.

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

Cardano 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 phần cấu trúc sau:

Script:  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;

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:   < /strong>Dữ liệu ngữ cảnh của các 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 được tải lên chuỗi.chain)

Nhà phát triển có thể sử dụng ngôn ngữ PlutusCore trên chuỗi Cardano Để lập trình UTXO, tương tự như CKB, nhà phát triển có thể viết 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, bạn cần để đấu giá hợp đồng thông minh UTXO Một số trạng thái được lưu trong bộ nhớ, chẳng hạn như mức giá cao nhất của cuộc đấ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ó.

Xây dựng các liên kết đẳng cấu trên Cardano có tính khả thi,< /strong>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 đòi hỏi chuỗi phải có các đặ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 các nhà phát triển viết tập lệnh mở khóa

   < /li>

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. Nó có thể 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 thức khác có nghĩa là

Do tính đặc biệt của ý 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 cho hợp đồng Việc lập trình là điều khó khăn đối với hầu hết các nhà phát triển để 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.