Chuyển Tiêu Đề Gốc 'RGB++ và Liên Kết Đồng Cấu Trúc: CKB, Cardano và Fuel Làm Thế Nào Để Tăng Cường Sinh Thái Bitcoin'

Tóm lược:· Giao thức tài sản RGB++ được đề xuất bởi đội ngũ CKBThe bản chất của ý tưởng “ràng buộc đẳng cấp” là sử dụng CKB, Cardano, Fuel và các blockchain khác dựa trên mô hình lập trình UTXO như một lớp mở rộng chức năng chứa “container” tài sản RGB. Ràng buộc đẳng cấp này cũng áp dụng cho các giao thức tài sản sinh thái của Bitcoin với đặc tính UTXO như Atomical và Runes, làm cho việc xây dựng một lớp hợp đồng thông minh ngoại chuỗi cho Bitcoin trở nên dễ dàng.

· Trong giao thức RGB++, người dùng không cần chạy máy khách để xác minh dữ liệu giao dịch cá nhân và có thể giao nhiệm vụ như 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. Miễn là bạn “lạc quan” và tin rằng an ninh của các chuỗi công cộng trên là khá đáng tin cậy, không cần phải xác minh bằng chính mình;

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

· Nếu nó nằm dưới hệ thống hợp đồng EVM, nhiều tính năng của RGB++ không dễ hỗ trợ. Tóm lại, một lớp mở rộng chức năng/ chuỗi công khai phù hợp để thực hiện việc ràng buộc đồng cấu có những đặc điểm sau:

1. Sử dụng mô hình UTXO hoặc hệ thống 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 các kịch bản 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. 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 tiện khác;

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

Trong LightPaper của existRGB++Protocol, vào năm 2017, Cipher, người đồng sáng lập của Nervos CKB, lần đầu tiên đề xuất ý tưởng sản phẩm về kết nối đồng cấu trúc. So với các giải pháp Lớp 2 của Bitcoin khác, kết nối đồng cấu trúc 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, và có thể tránh các yếu tố như tài sản chéo chuỗi mang lại gánh nặng bảo mật bổ sung.

Để nói một cách đơn giản, việc kết nối đồng cấu sử dụng UTXO trên chuỗi CKB và Cardano như “bao bì” để biểu thị tài sản UTXO như RGB, từ đó thêm tính lập trình và các tình huống phức tạp hơn. Trước đây, Geek web3 đã xuất hiện trong “Từ BTC đến Sui, ADA và Nervos: Mô hình UTXO và các phần mở rộng liên quanSau khi tóm tắt một loạt các chuỗi khối hỗ trợ UTXO có thể lập trình, bài viết này sẽ tiếp tục khám phá xem những chuỗi khối này có thể thích nghi với kế hoạch ràng buộc đồng cấu hình hay không.

RGB++ và ràng buộc cùng cấu trúc

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

Trước khi giới thiệu giao thức RGB++, hãy hiểu một cách ngắn gọn về giao thức RGB. RGB là giao thức tài sản/mạng lưới ngang hàng chạy dưới chuỗi Bitcoin, giống như Mạng Lightning một chút. 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 gọi là ký sinh học có nghĩa là máy khách RGB sẽ tuyên bố dưới chuỗi Bitcoin rằng tài sản RGB cụ thể được ràng buộc với UTXO nào trên chuỗi Bitcoin. Khi bạn sở hữu UTXO này, tài sản RGB được ràng buộc với nó cũng sẽ thuộc sở hữu của bạn.

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

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

Trong trường hợp này, nếu ai đó chuyển nhượng một số tài sản RGB cho bạn, bạn không biết trước tiên tiền được tạo ra như thế nào và từ ai nó đã chuyển tay. Nếu người kia khai báo một tài sản từ hư vô và sau đó chuyển giao một phần cho bạn, bạn sẽ xử lý thế nào với kịch bản đội tiền giả mạo này?

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

Như vậy, bạn có thể biết xem số tiền mà bên kia trao cho bạn có phải là “tiền đáng ngờ” hay không, vì vậy bản chất của RGB là để cho các bên tham gia giao dịch chạy client để xác minh. Dựa trên chế độ xác minh của client, tương ứng với giả định trò chơi người hợp lý, miễn là các bên tham gia hợp lý và phần mềm client ổn, có thể đảm bảo rằng việc chuyển tài sản gây vấn đề sẽ không có hiệu lực hoặc được công nhận bởi người khác.

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

(Sơ đồ luồng tương tác giao thức RGB)

Vì không có 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 đạt đến tất cả các nút mạng một cách "rất đáng tin cậy". Những người xuất bản hợp đồng và người dùng đơn giản chỉ học các chi tiết của hợp đồng tài sản RGB một cách tự phát thông qua email hoặc Twitter, và hình thức rất bình thường.

Hình dưới đây cho thấy một kịch bản chuyển tài sản RGB độc hại. 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 tài sản RGB trên máy khách của chúng ta. Khi người khác chuyển tiền cho chúng ta, chúng ta có thể biết liệu việc chuyển giao hiện tại có vi phạm các quy tắc được xác định trong hợp đồng dựa trên nội dung của hợp đồng tài sản được lưu trữ cục bộ. Theo thông tin nguồn tài sản (hồ sơ lịch sử) được cung cấp ở phía đối diện, bạn có thể xác nhận xem có vấn đề gì với nguồn gốc của tài sản của bên kia (nó có được tuyên bố từ không).

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

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

Ngoài ra, giao thức Bifrost được sử dụng để giao tiếp giữa các khách hàng RGB sẽ hỗ trợ người dùng trong giao tiếp p2p với các khách hàng khác. Họ có thể mã hóa dữ liệu tài sản của mình và phân tán nó đến các nút khác, và yêu cầu chúng giúp đỡ lưu trữ nó. (Lưu ý rằng đây là dữ liệu đã được mã hóa, bên kia không biết văn bản gốc). Miễn là bạn không 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 bạn sở hữu ban đầu thông qua các nút khác trong mạng.

Nhưng nhược điểm của giao thức RGB ban đầu vẫn rõ ràng. Đầu tiên, mỗi giao dịch đều yêu cầu nhiều cuộc trao đổi giữa hai bên. Bên nhận trước tiên phải xác minh nguồn gốc của tài sản của người gửi, sau đó gửi một biên nhận để chấp nhận 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 truyền giữa hai bên. Loại “chuyển tiền tương tác” này không tương thích với “chuyển tiền không tương tác” mà phần lớn mọi người đã quen thuộc. Bạn có thể tưởng tượng khi 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. Họ chỉ có thể hoàn tất quá trình chuyển tiền sau khi nhận được tin nhắn biên nhận của bạn. (Biểu đồ quy trình có thể được xem trong bài viết trước đó)

Thứ hai, phần lớn tình huống 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 không hỗ trợ mặc định cho các tình huống như vậy, vì vậy 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 máy khách để thực hiện nhiệm vụ của họ. xác minh,Nếu bạn nhận được một tài sản một cách tình cờ đã chuyển tay giữa hàng chục nghìn người, bạn sẽ phải xác minh hàng chục nghìn lần tài sản đã chuyển tay. Rõ ràng, để người dùng tự giải quyết mọi thứ, đây không phải là điều thuận lợi cho việc quảng cáo và áp dụng sản phẩm.

Về 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ế độ xác minh bản thân của khách hàng và chế độ lưu trữ của bên thứ ba. Người dùng có thể để lại gánh nặng của việc xác minh dữ liệu và lưu trữ, việc lưu trữ hợp đồng thông minh, vv 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ó yêu cầu bảo mật và riêng tư cao hơn, ví dụ như các nhà đầu tư lớn có số lượng tài sản lớn cũng có thể quay trở lại chế độ RGB ban đầu. Điều cần nhấn mạnh ở đây là RGB++ và giao thức RGB ban đầu lý thuyết là tương thích với nhau.

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

trong các bài viết trước“Từ RGB đến RGB++: Làm thế nào CKB giúp sức mạnh cho giao thức tài sản sinh thái của Bitcoin”, chúng tôi đã phổ biến ngắn gọn về việc “ràng buộc đồng cấu” của RGB++. Ở đây chúng tôi sẽ nhanh chóng xem xét lại:

CKB có UTXO mở rộng riêng gọi là Cell, có khả năng lập trình cao hơn UTXO trên chuỗi BTC. "Sự ràng buộc đồng cấu" là sử dụng Cell trên chuỗi CKB như một "bộ chứa" cho dữ liệu tài sản RGB, và ghi các tham số chính của tài sản RGB vào Cell.

Vì có một mối quan hệ ràng buộc giữa tài sản RGB và Bitcoin UTXO, hình thức logic của tài sản có đặc điểm của UTXO. andCell, cũng có các đặc điểm của UTXO, tự nhiên phù hợp như một “container” cho tài sản RGB. Khi giao dịch tài sản RGB xảy ra, container Cell 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 thực thể và bóng. Đây chính là bản chất của “ràng buộc đồ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 Cell trên chuỗi CKB, Cell này được đánh dấu với “Số dư mã thông báo RGB: 100”, và điều kiện mở khóa liên quan đến UTXO A.

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

Sau đó, Alice chi tiêu UTXO A trên chuỗi Bitcoin, công bố tuyên bố trên và sau đó khởi tạo một giao dịch trên chuỗi CKB để tiêu thụ thùng chứa Cell mang 100 mã thông báo RGB và tạo ra hai thùng chứa mới, một cái chứa 30 mã thông báo (đến Bob), một cái chứa 70 mã thông báo (được kiểm soát bởi Alice). 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 tuyên bố giao dịch được hoàn thành bởi các nút mạng CKB thông qua sự đồng thuận, mà không cần sự can thiệp của Bob. CKB hiện đang hoạt động như một lớp xác minh và lớp DA dưới chuỗi Bitcoin.

Điều này tương tự như việc mỗi khi trạng thái của hợp đồng Ethereum ERC-20 thay đổi, người dùng không cần chạy xác minh của khách hàng. Nguyên tắc tương tự. Giao thức đồng thuận và mạng nút thay thế xác minh của khách hàng. 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 toàn cầu, điều này có lợi cho việc triển khai các kịch bản Defi, như hồ bơi thanh khoản và giao protocôl cam kết tài sản.

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

Tất nhiên, nếu ai đó muốn chạy client RGB++ và xác minh nguồn gốc lịch sử của 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 Cell tài sản RGB trên chuỗi CKB. Miễn là bạn chạy một nút nhẹ CKB và nhận Chứng minh Merkle và tiêu đề khối CKB, bạn có thể chắc chắn rằng dữ liệu lịch sử bạn nhận không bị sửa đổi bởi kẻ tấn công độc hại trên mạng. Có thể nói rằng, CKB đóng vai trò là một lớp lưu trữ dữ liệu lịch sử ở đây.

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

Dưới giao thức kết nối cùng cấu trúc, 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 các hộp chứa tài sản RGB của họ trên chuỗi UTXO như CKB mà không cần vượt qua chuỗi. Bạn chỉ cần sử dụng tính năng UTXO của Cell để thiết lập các điều kiện mở khóa của hộp chứa Cell được liên kết với một địa chỉ Bitcoin / Bitcoin UTXO cụ thể. Kể từ khi 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 đó trên Geekweb3, chúng tôi sẽ không đi vào chi tiết ở đây.

Nếu cả hai bên tham gia vào các giao dịch tài sản RGB có thể tin tưởng vào tính bảo mật của CKB, họ thậm chí sẽ không cần phải đưa ra Cam kết thường xuyên trên chuỗi Bitcoin. Sau khi 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 cơ sở hạ tầng có đặc điểm tương tự trong lưu trữ trạng thái và chuỗi EVM rõ ràng là không phù hợp và sẽ có vấn đề triển khai kỹ thuật. Gặp phải 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", về cơ bản là không thể thực hiện trên chuỗi EVM; ngay cả khi bị cưỡng chế 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 client hoặc lưu trữ dữ liệu tài sản 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 client và đề xuất kiểm tra nguồn gốc của tài sản của ai đó, lúc này anh ta có thể phải quét tất cả các giao dịch ghi lại tương tác với các hợp đồng tài sản sẽ mang lại áp lực lớn.

Để nói thẳng, các hợp đồng tài sản như cặp ERC-20 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 lịch sử thay đổi tài sản của một trong số họ một cách riêng lẻ, điều đó sẽ trở nên khó khăn. Giống như trong một phòng trò chuyện công cộng, nếu bạn muốn biết ai đã gửi tin nhắn cho Wang Gang, bạn phải lật qua các 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 một cách một cách một, và dễ dàng kiểm tra lịch sử.

Tóm lại, một chuỗi công khai/lớp mở rộng chức năng phù hợp để thực hiện kết nối đồng cấu nên có những đặc điểm sau:

1. Sử dụng mô hình UTXO hoặc mô hình 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 các kịch bản 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ác cầu nối hoặc nút 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 việc ràng buộc cùng cấu trúc có bảo mật mạnh mẽ. Ngược lại, 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 nên được lập trình, để người dùng có thể Sử dụng trực tiếp hệ thống chữ ký BTC để mở khóa UTXO của bạn một cách cùng cấu trúc 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, kịch bản khóa UTXO trên CKB là có thể lập trình, và cả chính thức cũng tương thích với các hệ thống chữ ký của các chuỗi công cộng khác nhau. Đối với việc ràng buộc đồng cấu trúc, mạng lưới CKB cơ bản đáp ứng các đặc điểm trên. Còn với các chuỗi công cộng khác dựa trên UTXO thì sao? Chúng tôi đã tiến hành một cuộc kiểm tra sơ bộ về Fuel và Cardano và tin rằng họ có thể lý thuyết hỗ trợ việc ràng buộc đồng cấu trúc.

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à một người tiên phong trong việc giới thiệu khái niệm chứng minh gian lận vào hệ sinh thái Ethereum Layer 2. Đối với việc hỗ trợ chức năng UTXO bình thường, Fuel cơ bản là nhất quán với BTC.

Fuel chia các UTXO nội bộ của mình thành ba danh mục sau:

Đầu Vào Coin: UTXO Tiêu Chuẩn, được sử dụng để đại diện cho tài sản người dùng, có khóa thời gian bản địa, và cho phép người dùng viết điều kiện kịch bản mở khóa;

Input Contract：UTXO được sử dụng cho các cuộc gọi hợp đồng chứa dữ liệu như gốc trạng thái của hợp đồng và tài sản hợp đồng;

Thông điệp đầu vào: UTXO được sử dụng để truyền thông tin chủ yếu chứa các trường như người nhận thông tin;

Khi người dùng tiêu thụ một UTXO, đầu ra sau đây được tạo ra:

Đầu ra Coin: Đối với việc 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 bên trong chứa gốc trạng thái sau tương tác hợp đồng;

Đầu ra Hợp đồng Đã Tạo: Một UTXO đặc biệt là đầu ra được tạo ra khi tạo một hợp đồng, chứa ID và state root 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 bên trong, UTXO của Fuel thực sự không chứa tất cả các trạng thái hợp đồng liên quan đến giao dịch. Fuel chỉ chứa Stateroot gốc của trạng thái hợp đồng trong UTXO, đó là gốc của cây trạng thái. Toàn bộ trạng thái 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.

Đáng lưu ý là, Về việc xử lý trạng thái của hợp đồng thông minh, hợp đồng Fuel và hợp đồng solidity có sự nhất quán về tư tưởng và thậm chí gần gũi về hình thức lập trình. Hình dưới đây cho thấy một hợp đồng đếm viết bằng ngôn ngữ Sway của Fuel. Hợp đồng chứa một bộ đếm. Khi người dùng gọi hàm increment_counter, bộ đếm được lưu trữ trong hợp đồng sẽ được tăng thêm 1.

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

Do đó, kinh nghiệm lập trình hợp đồng của Fuel khác biệt so với ngôn ngữ lập trình UTXO như CKB và Cardano. Fuel cung cấp trải nghiệm gần gũi hơn với lập trình và phát triển hợp đồng thông minh EVM. Các nhà phát triển cũng có thể sử dụng ngôn ngữ Sway để xây dựng các script mở khóa để thực hiện 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.

Nó cơ bản là khả thi để triển khai kết nối đồng đẳng trong Fuel, nhưng vẫn còn những vấn đề sau:

Ngôn ngữ sway được sử dụng bởi Fuel gần với chuỗi EVM trong thiết kế hợp đồng thông minh hơn là BTC hoặc CKB và Cardano. Người 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ác với Fuel, nó là một chuỗi công cộng Layer 1. Cardano sử dụng eUTXO (mở rộng UTXO) để chỉ đến 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:

Scripts: 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 các chuyển đổi trạng thái;

Những người khôi phục: Dữ liệu được cung cấp bởi người dùng để mở khóa UTXO thường là dữ liệu chữ ký, tương tự như Witness của Bitcoin;

Dữ liệu: Không gian trạng thái của các 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 cho các giao dịch UTXO, chẳng hạn như thông số đầu vào và kết quả của giao dịch(Quá 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 đến chuỗi để xác minh. Nếu chúng vượt qua xác minh, kết quả giao dịch sẽ được tải lên chuỗi)

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 script 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 một ứng dụng đấu giá tài sản DAPP yêu cầu người dùng đặt giá trước khi đấu giá kết thúc. Cụ thể, người dùng tiêu thụ UTXO của riêng mình, ký quỹ UTXO với đấu giá này, sau đó tạo ra một UTXO mới. Khi ai đó đặt giá cao hơn, ngoài việc tạo ra một UTXO hợp đồng đấu giá mới, cũng sẽ tạo ra một UTXO hoàn trả cho người trước đó. 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 đấu giá hiện tại và người đã ra giá. Hình dưới đây cho thấy tuyên bố trạng thái bên trong PlutusCore. Chúng ta có thể thấy rằng bBidder và bAmount hiển thị đấu giá và địa chỉ ví đã đưa ra giá. Các Tham số Đấu giá chứa thông tin cơ bản của cuộc đấu giá.

Khi người dùng chi tiêu UTXO này, chúng tôi có thể cập nhật trạng thái trong hợp đồng. Hình dưới đây cho thấy 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 các lượt đặt cược của người dùng và xác minh xem đấu giá hiện tại vẫn đang diễn ra. Chắc chắn, Vì PlutusCore là một ngôn ngữ lập trình Haskell, là một ngôn ngữ lập trình hàm thuần túy, nên hầu hết các nhà phát triển có thể không thể hiểu trực tiếp ý nghĩa của nó.

Việc xây dựng các kết nối cùng cấu trúc trên Cardano là khả thi, Chúng ta có thể sử dụng Datum để lưu trữ trạng thái tài sản và viết các scripts 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 ứng với việc sử dụng PlutusCore để lập trình hợp đồng. Hơn nữa, môi trường lập trình của nó khó thiết lập và không thân thiện với các nhà phát triển.

Tóm tắt

Ràng buộc đồ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 các nhà phát triển viết các kịch bản 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. Nó có thể hỗ trợ chạy 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 vì đặc thù của các ý tưởng lập trình hợp đồng thông minh của nó, Fuel tương thích với việc kết nối đồng cấu, nhưng vẫn mang theo một số gánh nặng; trong khi Cardano sử dụng ngôn ngữ lập trình Haskell cho lập trình hợp đồng, điều này khiến cho việc bắt đầu nhanh chóng với hầu hết các nhà phát triển trở nên khó khăn. Dựa trên những lý do trên, CKB, mà áp dụng bộ lệnh RISC-V và cân bằng hơn trong các đặc điểm của lập trình UTXO, có thể là một lớp mở rộng chức năng phù hợp hơn cho kết nối đồng cấu.

Tuyên bố:

1. Bài viết này được sao chép từ [Web3 geek]. Chuyển Tiêu Đề Gốc ‘RGB++ Và Kết Nối Đồng Cấu: CKB, Cardano Và Fuel Làm Thế Nào Để Tăng Cường Hệ Sinh Thái Bitcoin’. Tất Cả Bản Quyền Thuộc Về Tác Giả Gốc [Shew]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ với Gate Họcnhóm và họ sẽ xử lý nhanh chóng.
2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch là không được phép.