Tác giả gốc: Faust, Geek web3 BTCEden.org Lianchuang (X: @faustliu1997)

Nguồn chính thức:Web3 đam mê

Với sự phổ biến của việc phát hành RGB++ và các tài sản liên quan, cuộc thảo luận về nguyên tắc của giao thức RGB và RGB++ dần trở thành chủ đề được nhiều người quan tâm hơn. Nhưng mọi người đều nhận ra rằng để hiểu RGB++, trước tiên bạn phải hiểu giao thức RGB.

Giao thức RGB ban đầu hơi mơ hồ về mặt cấu trúc kỹ thuật và các tài liệu tham khảo còn rải rác, cho đến nay không có nhiều tài liệu tham khảo có tính hệ thống và dễ hiểu, mặc dù geek web3 trước đây đã xuất bản hai bài báo giải thích có hệ thống về RGB và RGB++ (Bạn có thể xem lịch sử tài khoản chính thức của chúng tôi), nhưng theo phản hồi từ các thành viên trong cộng đồng, bài viết nói trên quá dài và quá nhức não.

Để giúp nhiều người hiểu giao thức RGB và RGB++ nhanh hơn, tác giả bài viết này đã gấp rút hoàn thành bản diễn giải ngắn gọn bằng tiếng địa phương về RGB và RGB++ trong sự kiện ở Hồng Kông. Nó có thể được đọc trong vài phút và hy vọng sẽ giúp ích Người đọc có thể hiểu rõ hơn và trực quan hơn về RGB và RGB++.

Giao thức RGB: người dùng phải tự xác minh dữ liệu

Giao thức RGB là giao thức tài sản P2P đặc biệt và là hệ thống máy tính ngoài chuỗi Bitcoin, nó giống với kênh thanh toán ở một số khía cạnh: người dùng phải tự chạy ứng dụng khách và xác minh hành vi chuyển tiền của chính họ (Verify by Yourself). Ngay cả khi bạn chỉ là người nhận tài sản, trước tiên bạn phải đảm bảo không có sai sót trong báo cáo chuyển nhượng của người gửi tài sản trước khi báo cáo chuyển nhượng có hiệu lực. Rõ ràng điều này khác hoàn toàn với hình thức gửi và nhận tài sản truyền thống, chúng tôi gọi đó là “chuyển giao tương tác”.

Tại sao cái này rất? Lý do là để đảm bảo quyền riêng tư, giao thức RGB không áp dụng “giao thức đồng thuận” trong các blockchain truyền thống như Bitcoin và Ethereum (một khi dữ liệu đi qua giao thức đồng thuận, nó sẽ được hầu hết tất cả các nút trong mạng quan sát). , và sự riêng tư không được đảm bảo. ). Làm cách nào để đảm bảo rằng các thay đổi về tài sản được an toàn mà không cần có quy trình đồng thuận liên quan đến số lượng lớn nút? Ý tưởng có tên Xác minh khách hàng (Tự xác minh) được sử dụng ở đây, bạn phải tự mình chạy ứng dụng khách và đích thân xác minh những thay đổi tài sản liên quan đến bạn.

Giả sử có một người dùng RGB tên là Bob, người này biết Alice và Alice muốn chuyển 100 mã thông báo TEST cho Bob. Sau khi Alice tạo thông tin chuyển khoản Alice sang Bob, trước tiên cô ấy phải gửi thông tin chuyển khoản và dữ liệu tài sản liên quan cho Bob và để anh ấy tự mình kiểm tra để đảm bảo thông tin đó chính xác trước khi bước vào quy trình tiếp theo, và cuối cùng nó sẽ trở thành chuyển RGB hợp lệ. Do đó, giao thức RGB cho phép người dùng tự mình xác minh tính hợp lệ của dữ liệu, thay thế thuật toán đồng thuận truyền thống.

Nhưng không có sự đồng thuận và dữ liệu được nhận và lưu trữ bởi các máy khách RGB khác nhau không nhất quán. Mọi người chỉ lưu trữ dữ liệu tài sản của riêng mình cục bộ và không biết trạng thái tài sản của người khác. Điều này bảo vệ quyền riêng tư đồng thời hình thành một đảo dữ liệu. Nếu ai đó tuyên bố có 1 triệu token TEST và muốn chuyển 100.000 cho bạn thì làm sao bạn có thể tin được?

Trong mạng RGB, nếu ai đó muốn chuyển tiền cho bạn, trước tiên anh ta phải xuất trình bằng chứng về tài sản, truy tìm nguồn gốc lịch sử của tài sản từ lần phát hành đầu tiên đến nhiều lần thay đổi chủ sở hữu và đảm bảo rằng Mã thông báo sẽ được chuyển cho bạn được thôi. Điều này giống như khi bạn nhận được Khi bạn nhận được những tờ tiền không xác định, bạn yêu cầu bên kia giải thích nguồn gốc lịch sử của những tờ tiền này và liệu chúng có phải do nhà phát hành được chỉ định tạo ra hay không, để tránh tiền giả.

(Nguồn ảnh: Coinex)

Các quy trình trên xảy ra ngoài chuỗi Bitcoin và chỉ riêng các quy trình này không cho phép RGB có kết nối trực tiếp với mạng Bitcoin. Về vấn đề này, giao thức RGB áp dụng một ý tưởng gọi là con dấu sử dụng một lần để liên kết tài sản RGB với UTXO trên chuỗi Bitcoin. Miễn là UTXO Bitcoin không được tiêu thụ gấp đôi thì tài sản RGB bị ràng buộc sẽ không được nhân đôi. rằng mạng Bitcoin có thể được sử dụng để ngăn chặn việc Tổ chức lại tài sản RGB. Tất nhiên, điều này đòi hỏi phải đưa ra Cam kết trên chuỗi Bitcoin và sử dụng opcode OP_Return.

Dưới đây là tóm tắt quy trình làm việc của giao thức RGB:

1. Tài sản RGB bị ràng buộc với Bitcoin UTXO và Bob sở hữu một số UTXO Bitcoin nhất định. Alice muốn chuyển 100 token cho Bob. Trước khi nhận tài sản, Bob cho Alice biết trước nên sử dụng UTXO Bitcoin nào của Bob để liên kết các tài sản RGB này.

(Nguồn hình ảnh: Geek web3/ Geek Web3)

• Alice xây dựng dữ liệu chuyển nội dung RGB Alice sang Bob, cùng với các nguồn lịch sử của những nội dung này và đưa chúng cho Bob để xác minh.

• Sau khi Bob xác nhận tại địa phương rằng dữ liệu vẫn ổn, anh ấy sẽ gửi biên nhận cho Alice, thông báo với cô ấy rằng giao dịch có thể được thực hiện.

• Alice xây dựng dữ liệu chuyển RGB của Alice to Bob thành Cây Merkle và xuất bản Merkle Root lên chuỗi Bitcoin dưới dạng Cam kết. Chúng ta có thể hiểu đơn giản Cam kết là hàm băm của dữ liệu chuyển.

• Nếu ai đó muốn xác nhận trong tương lai rằng việc chuyển Alice sang Bob nêu trên thực sự đã xảy ra, anh ta cần thực hiện hai việc: lấy thông tin chuyển hoàn chỉnh của Alice sang Bob trong chuỗi Bitcoin, sau đó kiểm tra xem liệu có một giao dịch tương ứng trên Cam kết chuỗi Bitcoin (băm dữ liệu chuyển khoản), thế là xong.

Bitcoin ở đây hoạt động như nhật ký lịch sử của mạng RGB, nhưng chỉ có gốc băm/Merkle của dữ liệu giao dịch được ghi lại trong nhật ký chứ không phải chính dữ liệu giao dịch. Do sử dụng xác minh ứng dụng khách và niêm phong một lần, giao thức RGB có độ bảo mật cực cao; vì mạng RGB bao gồm các máy khách người dùng động ở dạng P2P, không đồng thuận, bạn có thể thay đổi đối tác bất cứ lúc nào mà không cần Yêu cầu giao dịch được gửi đến một số lượng nút hạn chế, do đó mạng RGB có khả năng chống kiểm duyệt cực kỳ cao.Hình thức tổ chức này có khả năng chống kiểm duyệt cao hơn các chuỗi công khai lớn như Ethereum.

(Nguồn ảnh: BTCEden.org)

Tất nhiên, cái giá phải trả cho tính bảo mật cực cao, khả năng chống kiểm duyệt và bảo vệ quyền riêng tư cũng rất rõ ràng: người dùng phải chạy client để tự xác minh dữ liệu, nếu bên kia gửi một số tài sản đã đổi chủ hàng chục nghìn lần và có một lịch sử lâu dài, bạn Bạn cũng phải xác minh mọi thứ dưới áp lực;

Ngoài ra, mỗi giao dịch đều yêu cầu hai bên liên lạc nhiều lần, trước tiên bên nhậ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?

Ngoài ra, chúng tôi đã đề cập rằng mạng RGB không có sự đồng thuận và mỗi khách hàng là một hòn đảo, điều này không có lợi cho việc di chuyển các kịch bản hợp đồng thông minh phức tạp trên chuỗi công cộng truyền thống sang mạng RGB vì các giao thức Defi trên Ethereum hoặc Solana đều dựa vào A sổ cái minh bạch và hiển thị trên toàn cầu. Làm thế nào để tối ưu hóa giao thức RGB, cải thiện trải nghiệm người dùng và giải quyết các vấn đề trên? Điều này đã trở thành một vấn đề khó tránh khỏi đối với giao thức RGB.

RGB++: xác thực ứng dụng khách trở thành lưu trữ lạc quan

Giao thức có tên RGB++ đưa ra một ý tưởng mới. Nó kết hợp giao thức RGB với các chuỗi công khai hỗ trợ UTXO như CKB, Cardano và Fuel. Lớp sau đóng vai trò là lớp xác minh và lớp lưu trữ dữ liệu cho nội dung RGB và chuyển đổi dữ liệu được thực hiện ban đầu bởi người dùng Công việc xác minh được bàn giao cho các nền tảng/chuỗi công khai của bên thứ ba như CKB. Điều này tương đương với việc thay thế xác minh khách hàng bằng nền tảng xác minh phi tập trung của bên thứ ba. Miễn là bạn tin tưởng các chuỗi công khai như CKB, Cardano , Nhiên liệu, v.v., nếu bạn không tin tưởng chúng, bạn cũng có thể chuyển về chế độ RGB truyền thống.

RGB++ và giao thức RGB ban đầu tương thích với nhau về mặt lý thuyết.

Để đạt được những hiệu quả nêu trên, bạn cần sử dụng một ý tưởng gọi là liên kết đẳng cấu. Các chuỗi công khai như CKB và Cardano có UTXO mở rộng của riêng họ, 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 UTXO mở rộng trên chuỗi CKB, Cardano và Fuel làm vùng chứa cho dữ liệu nội dung RGB, ghi các tham số của nội dung RGB vào các vùng chứa này và hiển thị chúng trực tiếp trên blockchain. Bất cứ khi nào một giao dịch nội dung RGB xảy ra, vùng chứa nội dung 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 ràng buộc đẳng cấu.

(Nguồn hình ảnh: LightPaper RGB++)

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ũng có UTXO trên chuỗi CKB, thì UTXO 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 UTXO mang 100 mã thông báo RGB và tạo hai vùng chứa mới, một vùng chứa 30 mã thông báo (cho 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 hoàn thành bởi các nút mạng như CKB hoặc Cardano thông qua sự đồng thuận mà không cần sự can thiệp của Bob. Tại thời điểm này, CKB và Cardano đóng vai trò là lớp xác minh và lớp DA trong chuỗi Bitcoin.

(Nguồn hình ảnh: LightPaper RGB++)

Dữ liệu tài sản RGB của mọi người được lưu trữ trên chuỗi CKB hoặc Cardano, có các đặc điểm có thể xác minh trên toàn cầu và 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. Tất nhiên, cách tiếp cận trên cũng hy sinh quyền riêng tư. Bản chất là tạo ra sự cân bằng giữa quyền riêng tư và tính dễ sử dụng của sản phẩm. Nếu bạn theo đuổi sự bảo mật và quyền riêng tư tối đa, bạn có thể chuyển về chế độ RGB truyền thống; nếu không quan tâm đến điều này, bạn có thể sử dụng RGB++ một cách an toàn. Chế độ này hoàn toàn phụ thuộc vào nhu cầu cá nhân của bạn. (Trên thực tế, với tính hoàn chỉnh về chức năng mạnh mẽ của các chuỗi công khai như CKB và Cardano, ZK có thể được sử dụng để thực hiện các giao dịch riêng tư)

Cần nhấn mạnh ở đây rằng RGB++ đưa ra một giả định tin cậy quan trọng: người dùng phải lạc quan rằng chuỗi CKB/Cardano 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.

Theo giao thức RGB++, 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/Cardano mà không cần chuỗi chéo, họ chỉ cần sử dụng các đặc điểm của UTXO trong các chuỗi công khai ở trên để đặt điều kiện mở khóa của vùng chứa Di động. Chỉ cần đặt nó được liên kết với một địa chỉ Bitcoin/Bitcoin UTXO nhất định. 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 Cam kết trên chuỗi Bitcoin. Sau khi hoàn tất nhiều lần chuyển RGB, họ có thể gửi Cam kết tới chuỗi Bitcoin. Điều nà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 isomorphic bind cần một public chain hỗ trợ mô hình UTXO, hoặc một cơ sở hạ tầng có đặc điểm tương tự trong state storage, chuỗi EVM không phù hợp và sẽ gặp nhiều cạm bẫy. (Chủ đề này có thể viết riêng và liên quan đến nhiều nội dung. Bạn đọc quan tâm có thể tham khảo bài viết trước của Geek Web3RGB++ và liên kết đẳng cấu: Cách CKB, Cardano và nhiên liệu trao quyền cho hệ sinh thái Bitcoin；

Đượ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 để triển khai liên kết đẳng cấu phải có các đặc điểm sau:

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

• 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;

• 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;

• Có những cây cầu hoặc nút ánh sáng liên quan đến Bitcoin;