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

Giao thức RGB là một giao thức tài sản P2P đặc biệt và một hệ thống tính toán dưới chuỗi Bitcoin. Nó tương tự như một kênh thanh toán ở một số khía cạnh: Người dùng cần chạy client của họ và xác minh hành vi chuyển giao của họ (Xác minh bởi chính mình). Ngay cả khi bạn chỉ là người nhận tài sản, bạn phải đảm bảo trước rằng không có lỗi nào trong tuyên bố chuyển giao của người gửi tài sản trước khi tuyên bố chuyển giao có thể có hiệu lực. Rõ ràng điều này hoàn toàn khác biệt so với hình thức truyền gửi 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 phải như vậy? 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. (Khi dữ liệu đi qua giao thức đồng thuận, nó sẽ được quan sát bởi hầu hết các nút trong mạng và quyền riêng tư không được đảm bảo). Làm thế nào để đảm bảo rằng các thay đổi tài sản là an toàn mà không cần quá trình đồng thuận liên quan đến một số lượng lớn các nút? Ý tưởng được gọi là "Xác minh khách hàng" (Tự xác minh) được sử dụng ở đây. Bạn cần tự điều hành khách hàng và đích thân xác minh các thay đổi tài sản liên quan đến bạn. Giả sử có một người dùng RGB tên Bob 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 nhượng của "Alice to Bob", trước tiên cô ấy phải gửi thông tin chuyển nhượng và dữ liệu tài sản liên quan đến Bob và để anh ấy tự kiểm tra để đảm bảo rằng nó chính xác trước khi vào quy trình tiếp theo và cuối cùng nó trở thành chuyển khoản RGB hợp lệ. Bằng cách này, giao thức RGB cho phép người dùng xác minh cá nhân 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, dữ liệu nhận được và lưu trữ bởi các máy khách RGB khác nhau là 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 tình trạng tài sản của người khác. Trong khi bảo vệ quyền riêng tư, điều này cũng tạo thành một "hòn đảo dữ liệu". Nếu ai đó tuyên bố có 1 triệu mã thông báo TEST và muốn chuyển 100.000 cho bạn, làm thế nào 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, theo dõi lại nguồn lịch sử của tài sản từ lần phát hành ban đầu đến nhiều lần đổi chủ và đảm bảo rằng Mã thông báo sẽ được chuyển cho bạn sạch sẽ. Điều này giống như khi bạn nhận được tiền giấy không rõ nguồn gốc và 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ó được tạo ra bởi tổ chức phát hành được chỉ định hay không, để tránh tiền giả.

(Nguồn ảnh: Coinex)

Các quy trình trên xảy ra dưới chuỗi Bitcoin, và những quy trình này một mình không thể làm cho RGB liên quan trực tiếp đến mạng Bitcoin. Liên quan đến điều này, giao thức RGB áp dụng một ý tưởng gọi là 'niêm phong sử dụng đơn' để ràng buộc tài sản RGB với UTXO trên chuỗi Bitcoin. Miễn là UTXO Bitcoin không bị tiêu thụ kép, tài sản RGB bị ràng buộc sẽ không bị tiêu thụ kép. Theo cách này, mạng Bitcoin có thể được sử dụng để ngăn chặn 'Tổ chức lại' tài sản RGB. Tất nhiên, Cam kết này cần được công bố trên chuỗi Bitcoin và mã opcode OP_Return được sử dụng.

Đây là bản tóm tắt về quy trình làm việc của giao thức RGB:

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

(Nguồn hình ảnh: Geekweb3/GeekWeb3)

1. Alice xây dựng dữ liệu chuyển nhượng tài sản RGB “Alice đến Bob”, cùng với các nguồn tài sản lịch sử này, và gửi chúng cho Bob để xác minh.
2. Sau khi Bob xác nhận cục bộ rằng dữ liệu ổn, anh ta gửi biên nhận cho Alice, cho biết giao dịch có thể được thực hiện.
3. Alice xây dựng dữ liệu chuyển RGB của “Alice đến Bob” vào một Cây Merkle, và công bố Gốc Merkle lên chuỗi Bitcoin như là Một cam kết. Chúng ta có thể đơn giản hiểu Cam kết như là băm của dữ liệu chuyển.
4. Nếu ai đó muốn xác nhận trong tương lai rằng việc chuyển tiền “Alice to Bob” như đã đề cập trên đã diễn ra, anh ấy cần thực hiện hai việc: lấy thông tin chuyển khoản đầy đủ của “Alice to Bob” trên chuỗi Bitcoin, sau đó kiểm tra xem có giao dịch tương ứng nào trên Chuỗi Bitcoin Cam kết (băm dữ liệu chuyển khoản), đó là tất cả.

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

(Nguồn ảnh: BTCEden.org)

Chắc chắn, an ninh cực kỳ cao, kháng kiểm duyệt và bảo vệ quyền riêng tư đi kèm với những chi phí rõ ràng: Người dùng phải chạy máy khách để xác minh dữ liệu mình. Nếu bên kia gửi cho bạn một số tài sản đã thay đổi chủ nhân hàng chục ngàn lần và có một lịch sử dài, bạn phải xác minh tất cả chúng dưới áp lực.

Ngoài ra, mỗi giao dịch yêu cầu nhiều lần truyền thông 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 và sau đó gửi một biên nhận để phê duyệt yêu cầu chuyển khoả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 qua giữa hai bên. Loại “chuyển giao tương tác” này hoàn toàn không nhất quán với “chuyển giao không tương tác” mà hầu hết mọi người quen thuộc.

Bạn có thể tưởng tượng ai đó muốn chuyển tiền cho bạn, nhưng họ phải gửi dữ liệu giao dịch cho bạn để xác minh, và chỉ sau khi nhận được tin nhắn biên nhận của bạn thì quá trình chuyển khoản mới hoàn tất được.

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 thuận lợi cho việc di chuyển các kịch bản hợp đồng thông minh phức tạp từ chuỗi công cộng truyền thống sang mạng RGB, vì giao thức Defi trên Ethereum hoặc Solana dựa vào một sổ cái toàn cầu và dữ liệu rõ ràng. 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ông thể tránh khỏi cho giao thức RGB.

RGB++: Xác minh phía khách hàng trở thành sự quản lý lạc quan

Giao thức được gọi là RGB++ đề xuất một ý tưởng mới. Nó kết hợp giao thức RGB với chuỗi công khai hỗ trợ UTXO như CKB, Cardano và Fuel. Phần sau phục vụ như lớp xác minh và lớp lưu trữ dữ liệu cho tài sản RGB, và chuyển đổi dữ liệu được xử lý ban đầu bởi người dùng thành công việc xác minh và được chuyển giao cho các nền tảng bên thứ ba/chuỗi công khai như CKB. Điều này tương đương với việc thay thế việc 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, Fuel, v.v.. Ngay cả khi bạn không tin tưởng họ, bạn cũng có thể chuyển về chế độ RGB truyền thống.

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

Để đạt được các hiệu ứng được đề cập ở trên, chúng ta cần sử dụng một ý tưởng gọi là 'ràng buộc đồng cấu'. Các chuỗi công cộng như CKB và Cardano có UTXO mở rộng riêng của họ, mà có khả năng lập trình cao hơn so với UTXO trên chuỗi BTC. 'Ràng buộc đồng cấu' là sử dụng UTXO mở rộng trên các chuỗi CKB, Cardano và Fuel như 'container' cho dữ liệu tài sản RGB, viết các tham số của tài sản RGB vào các container này và hiển thị chúng trực tiếp trên blockchain. Khi có giao dịch tài sản RGB xảy ra, container tài sản tương ứng cũng có thể hiển thị các đặc tính tương tự, giống như mối quan hệ giữa thực thể và bóng. Điều này chính là bản chất của 'ràng buộc đồng cấu'.

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

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ó một UTXO trên chuỗi CKB, UTXO này được đánh dấu bằng “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 mã thông báo cho Bob, cô ấy có thể trước tiên tạo một cam kết. Tuyên bố tương ứng là: chuyển 30 trong số các mã thông báo 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 tiêu UTXO A trên chuỗi Bitcoin, công bố tuyên bố trên và sau đó khởi tạo giao dịch trên chuỗi CKB để tiêu diệt bộ chứa UTXO mang theo 100 mã thông báo RGB và tạo ra hai bộ chứa mới, một bộ chứa 30 mã (cho Bob), một bộ chứa 70 mã (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 tuyên bố 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. Lúc này, CKB và Cardano đóng vai trò là lớp xác minh và lớp DA dưới chuỗi Bitcoin.

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

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 điểm có thể xác minh toàn cầu và có lợi cho việc triển khai Defi, như là hồ bơi thanh khoản và giao thức thế chấp 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à phải thực hiện một sự cân nhắc giữa quyền riêng tư và sự dễ sử dụng của sản phẩm. Nếu bạn theo đuổi an ninh và quyền riêng tư tối đa, bạn có thể chuyển về chế độ RGB truyền thống; nếu bạn không quan tâm đến điều này, bạn có thể an toàn sử dụng chế độ RGB++, tất cả phụ thuộc vào nhu cầu cá nhân của bạn. (Trong thực tế, với sự hoàn thiện chức năng mạnh mẽ của các chuỗi công cộng như CKB và Cardano, ZK có thể được sử dụng để triển khai các giao dịch riêng tư)

Đây cần được nhấn mạnh ở đây rằng RGB++ giới thiệu một giả thuyết tin cậy quan trọng: Người dùng nên lạc quan rằng chuỗi CKB/Cardano, 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ể tuân theo quá trình giao tiếp tương tác và xác minh trong giao thức RGB ban đầu và chạy máy khách của mình.

Dưới giao thức RGB++, người dùng có thể trực tiếp sử dụng tài khoản Bitcoin của họ để vận hành các container tài sản RGB trên chuỗi UTXO như CKB/Cardano mà không cần chuyển chuỗi. Chỉ cần tận dụng các đặc điểm của UTXO trong chuỗi công khai trên và thiết lập điều kiện mở khóa của container Cell để liên kết với một địa chỉ Bitcoin/Bitcoin UTXO cụ thể. Nếu cả hai bên tham gia giao dịch tài sản RGB có thể tin tưởng vào sự an toàn của CKB, họ thậm chí không cần phải phát hành Cam kết thường xuyên trên chuỗi Bitcoin. Sau khi thực hiện nhiều lần chuyển tài sản RGB, một Cam kết có thể được gửi đến 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.

Nhưng hãy cẩn thận, “container” được sử dụng trong việc kết nối đồng đẳng cần một chuỗi công cộng hỗ trợ mô hình UTXO, hoặc một cơ sở hạ tầng có các đặc điểm tương tự trong lưu trữ trạng thái. Chuỗi EVM không phù hợp và sẽ gặp rất nhiều rủi ro. (Chủ đề này có thể được viết riêng và liên quan đến nhiều nội dung. Độc giả quan tâm có thể tham khảo các bài viết trước đó của Geek Web3).“RGB++ và Isomorphic Binding: Làm thế nào CKB, Cardano và Fuel đẩy mạnh hệ sinh thái Bitcoin”；

Tóm lại, Một chuỗi công cộng/lớp mở rộng chức năng phù hợp để thực hiện liên kết đồng cấu nên 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. Có cầu nối hoặc nút nhẹ liên quan đến Bitcoin;

Xin lưu ý:

1. Bài viết này được sao chép từ [ Geek Web3], tiêu đề gốc là “Thiết kế giao thức RGB và RGB++ trong vài phút: hướng dẫn đơn giản”, bản quyền thuộc về tác giả gốc [Faust], nếu bạn có bất kỳ ý kiến phản đối nào về việc sao chép, vui lòng liên hệ Gate Learn Team, nhóm sẽ xử lý nó càng sớm càng tốt theo các quy trình liên quan.

2. Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ đại diện cho quan điểm cá nhân 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 phiên bản ngôn ngữ khác của bài viết được dịch bởi nhóm Gate Learn. Mà không có tham chiếu Gate.io, việc sao chép, phân phối hoặc đạo văn các bài báo dịch là không được phép.