Với sự phổ biến ngày càng tăng của RGB ++ và phát hành tài sản liên quan, các cuộc thảo luận về các nguyên tắc của giao thức RGB và RGB ++ đã dần trở thành một chủ đề được nhiều người quan tâm hơn. Tuy nhiên, người ta nhận ra rằng để hiểu RGB ++, trước tiên người ta phải nắm bắt giao thức RGB. Giao thức RGB ban đầu có cấu trúc hơi kỹ thuật, với các tài liệu tham khảo rải rác và cho đến nay vẫn chưa có nhiều tài liệu tham khảo có hệ thống và dễ hiểu. Geek Web3 trước đây đã xuất bản hai cách giải thích có hệ thống về RGB và RGB ++ (có sẵn trong lịch sử tài khoản công khai của chúng tôi), nhưng theo phản hồi của cộng đồng, những bài viết này dài và quá phức tạp. Để cho phép nhiều người nhanh chóng hiểu các giao thức RGB và RGB ++, tác giả của bài viết này đã vội vàng hoàn thành một cách giải thích ngắn gọn của giáo dân về RGB và RGB ++ trong một sự kiện ở Hồng Kông. Nó có thể được đọc chỉ trong vài phút, nhằm giúp nhiều người đam mê cộng đồng hiểu rõ hơn và trực quan hơn về RGB và RGB ++.

Giao thức RGB: Người dùng cần phải xác minh dữ liệu cá nhân

Giao thức RGB là một loại giao thức tài sản P2P đặc biệt, hoạt động dưới hệ thống tính toán của chuỗi Bitcoin. Ở một số cách, nó tương tự như các kênh thanh toán: Người dùng cần chạy máy khách của họ cá nhân và xác minh các hành động chuyển nhượng liên quan đến họ ("Xác minh bởi chính bạn"). Ngay cả khi bạn chỉ là người nhận tài sản, bạn phải xác nhận trước rằng tuyên bố chuyển nhượng từ người gửi là chính xác trước khi chuyển nhượng có thể có hiệu lực. Phương pháp này, được biết đến là “chuyển nhượng tương tác,” khác biệt đáng kể so với các phương pháp chuyển nhượng và nhận truyền thống. Tại sao điều này cần thiết? Lý do là giao thức RGB, để bảo vệ quyền riêng tư, không sử dụng “giao thức đồng thuận” được tìm thấy trong chuỗi khối truyền thống như Bitcoin và Ethereum (nơi dữ liệu, một khi đã trong giao thức đồng thuận, được quan sát bởi hầu hết tất cả các nút trong mạng, làm cho quyền riêng tư khó bảo vệ). Mà không có quá trình đồng thuận liên quan đến một số lượng lớn các nút, làm thế nào có thể đảm bảo các thay đổi tài sản được an toàn? Đây là nơi mà ý tưởng “xác minh máy khách” ("Xác minh bởi chính bạn") xuất hiện. Bạn phải chạy máy khách của mình và xác minh cá nhân các thay đổi tài sản liên quan đến bạn.

Ví dụ: hãy xem xét một người dùng RGB tên là Bob, người biết Alice. Alice muốn chuyển 100 token TEST cho Bob. Sau khi tạo thông tin chuyển khoản "Alice to Bob", Alice gửi thông tin chuyển nhượng và dữ liệu tài sản liên quan cho Bob để anh ta đích thân kiểm tra. Chỉ khi Bob xác nhận rằng mọi thứ đều chính xác, việc chuyển nhượng mới tiến hành trở thành chuyển khoản RGB hợp lệ. Vì vậy, giao thức RGB yêu cầu người dùng tự xác minh tính hợp lệ của dữ liệu, thay thế các thuật toán đồng thuận truyền thống. Tuy nhiên, nếu 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ó liên quan đến bản thân họ tại địa phương và không biết về trạng thái tài sản của người khác. Trong khi điều này bảo vệ quyền riêng tư, nó cũng tạo ra "đả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 tin tưởng họ? Trong mạng RGB, nếu ai đó muốn chuyển tài sản cho bạn, trước tiên họ phải cung cấp bằng chứng về tài sản, truy tìm lịch sử tài sản từ khi phát hành ban đầu đến nhiều lần chuyển, đảm bảo rằng mã thông báo họ muốn chuyển cho bạn là hợp pháp. Nó giống như khi bạn nhận được tiền giấy không giải thích được, bạn yêu cầu người gửi giải thích lịch sử của những tờ tiền này, cho dù chúng được phát hành bởi nhà phát hành được chỉ định, để tránh tiền giả.

(Nguồn ảnh: Coinex)

Quá trình trên xảy ra trong chuỗi Bitcoin và các bước này một mình không thiết lập kết nối trực tiếp giữa RGB và mạng Bitcoin. Để giải quyết vấn đề này, giao thức RGB sử dụng khái niệm "con dấu sử dụng một lần", liên kết tài sản RGB với UTXOs (Đầu ra giao dịch chưa sử dụng) trên chuỗi Bitcoin. Miễn là Bitcoin UTXO không được chi tiêu gấp đôi, các tài sản RGB bị ràng buộc sẽ không phải thanh toán gấp đôi, do đó tận dụng mạng Bitcoin để 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 xuất bản các Cam kết về chuỗi Bitcoin và sử dụng opcode OP_Return.

Hãy đề cập đến 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 UTXOs, và Bob sở hữu một số Bitcoin UTXOs nhất định. Alice muốn chuyển 100 mã thông báo cho Bob. Trước khi nhận tài sản, Bob thông báo cho Alice biết UTXO Bitcoin của anh ấy nên đượ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 giao dịch cho việc chuyển đổi tài sản RGB từ "Alice tới Bob", cùng với lịch sử của những tài sản này, và đưa nó cho Bob để xác minh.
2. Sau khi Bob xác nhận rằng dữ liệu đúng đắn ở cấp địa phương, anh ta gửi một biên nhận cho Alice, thông báo rằng giao dịch có thể tiếp tục.
3. Alice xây dựng dữ liệu chuyển RGB "Alice đến Bob" thành cây Merkle và công bố Gốc Merkle trên chuỗi Bitcoin như một Cam kết. Chúng ta có thể hiểu Cam kết đơn giản là băm của dữ liệu chuyển.
4. Nếu ai đó trong tương lai muốn xác nhận rằng việc chuyển tiền “Alice tới Bob” thực sự đã xảy ra, họ cần thực hiện hai điều: lấy thông tin chuyển khoản đầy đủ của “Alice tới Bob” trên chuỗi Bitcoin và sau đó xác minh xem Cam kết tương ứng (băm dữ liệu chuyển khoản) có tồn tại trên chuỗi Bitcoin hay không.

Bitcoin phục vụ như một nhật ký lịch sử cho mạng RGB, nhưng nhật ký chỉ ghi lại hash/Merkle root của dữ liệu giao dịch, không phải dữ liệu giao dịch chính. Do việc áp dụng xác minh từ phía máy khách và con dấu sử dụng một lần, giao thức RGB cung cấp mứ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 cách tự do từ đồng thuận P2P, bạn có thể thay đổi đối tác giao dịch 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ế. Do đó, mạng RGB thể hiện sự chống lại kiểm duyệt mạnh mẽ. Cấu trúc tổ chức này khiến nó khá chống lại kiểm duyệt so với các chuỗi công cộng quy mô lớn như Ethereum.

(Nguồn hình ảnh: BTCEden.org)

Chắc chắn, tính an toàn cao, khả năng chống kiểm duyệt và bảo vệ quyền riêng tư mang lại bởi giao thức RGB cũng đi kèm với những chi phí đáng kể. Người dùng cần chạy máy khách của họ để xác minh dữ liệu. Nếu ai đó gửi cho bạn tài sản với lịch sử giao dịch dài liên quan đến hàng ngàn lần chuyển giao, bạn sẽ cần phải xác minh tất cả chúng, điều này có thể khá nặng nề.

Ngoài ra, mọi giao dịch đều yêu cầu nhiều giao tiếp giữa các bên. Người nhận cần xác minh nguồn tài sản của người gửi rồi gửi biên lai phê duyệt yêu cầu chuyển nhượng của người gửi. Quá trình này liên quan đến ít nhất ba lần trao đổi tin nhắn giữa các bên. "Chuyển giao tương tác" này khác rất nhiều so với "chuyển giao không tương tác" mà hầu hết mọi người đã quen thuộc. Hãy tưởng tượng ai đó cần gửi tiền cho bạn và phải gửi cho bạn dữ liệu giao dịch để kiểm tra, chờ tin nhắn nhận của bạn trước khi hoàn tất quá trình chuyển khoản.

Ngoài ra, như chúng tôi đã đề cập trước đó, mạng RGB thiếu sự đồng thuận, và mỗi khách hàng hoạt động độc lập, làm cho việc di dời 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 trở nên khó khăn. Điều này là do giao thức DeFi trên Ethereum hoặc Solana phụ thuộc vào sổ sách toàn cầu rõ ràng và minh bạch. 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à đối phó với những thách thức này trở thành một vấn đề không thể tránh khỏi cho giao thức RGB.

RGB++ giới thiệu một phương pháp giữ gìn lạc quan, thay thế việc xác minh từ phía khách hàng.

Giao thức được gọi là RGB++ giới thiệu một phương pháp mới bằng cách 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. Trong cài đặt này, phần sau phục vụ như lớp lưu trữ dữ liệu và xác nhận cho tài sản RGB, chuyển nhiệm vụ xác thực dữ liệu mà ban đầu được người dùng thực hiện sang các nền tảng/chuỗi bên thứ ba như CKB. Điều này hiệu quả thay thế việc xác thực phía máy khách bằng “xác thực trên nền tảng phi tập trung của bên thứ ba.” Miễn là bạn tin tưởng các nền tảng/chuỗi như CKB, Cardano hoặc Fuel, bạn có thể tiếp tục. Nếu bạn không tin tưởng họ, bạn luôn có thể chuyển lại 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; không phải là một trường hợp của một hoặc một trường hợp khác, mà họ có thể cùng tồn tại.

Để đạt được hiệu ứng được đề cập, chúng ta cần tận dụng một khái niệm gọi là “homomorphic bindings.” Các chuỗi công cộng như CKB và Cardano có mô hình UTXO mở rộng riêng của họ, cung cấp tính lập trình cao hơn so với UTXOs trên chuỗi Bitcoin. “Homomorphic binding” là ý tưởng sử dụng các UTXO mở rộng trên các chuỗi như CKB, Cardano và Fuel như “container” cho dữ liệu tài sản RGB. Các tham số của tài sản RGB được viết vào các container này và hiển thị trực tiếp trên chuỗi khối. Khi 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ị những đặc điểm tương tự, tương tự như mối quan hệ giữa các thực thể và bóng đen. Đây chính là bản chất của “homomorphic binding.”

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

Ví dụ, nếu Alice sở hữu 100 mã thông báo RGB và một UTXO (hãy gọi là UTXO A) trên chuỗi Bitcoin, cũng như một UTXO trên chuỗi CKB đượ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 với tuyên bố tương ứng: chuyển 30 mã thông báo RGB liên kết với UTXO A cho Bob và chuyển 70 mã thông báo sang một UTXO khác được kiểm soát bởi cô ấy.

Tiếp theo, Alice 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. Giao dịch này tiêu thụ bộ chứa UTXO chứa 100 mã thông báo RGB, tạo ra hai bộ chứa mới: một bộ chứa 30 mã thông báo (cho Bob) và một bộ chứa 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à các tuyên bố giao dịch được hoàn thành thông qua sự đồng thuận giữa các nút trên mạng như CKB hoặc Cardano, mà không cần sự tham gia của Bob. Tại thời điểm này, CKB và Cardano hoạt động như lớp xác thực và lớp DA (Khả năng Truy cập Dữ liệu), tương ứng, dưới chuỗi Bitcoin.

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

Dữ liệu tài sản RGB của tất cả cá nhân được lưu trữ trên chuỗi CKB hoặc Cardano, cung cấp một đặc điểm có thể xác minh toàn cầu giúp thúc đẩy việc triển khai các kịch bản DeFi như hồ bơi thanh khoản và giao thức đặt cược tài sản. Tất nhiên, phương pháp trên cũng đánh đổi quyền riêng tư. Điều này về cơ bản liên quan đến việc đánh đổi giữa quyền riêng tư và khả năng sử dụng sản phẩm. Nếu bạn ưu tiên bảo mật và quyền riêng tư tuyệt đối, bạn có thể chuyển về chế độ RGB truyền thống. Nếu bạn không quan tâm đến những đánh đổi này, bạn có thể tự tin chấp nhận chế độ RGB++, hoàn toàn phụ thuộc vào nhu cầu cá nhân của bạn. (Trên thực tế, thông qua việc tận dụng tính năng mạnh mẽ của các chuỗi công khai như CKB và Cardano, các giao dịch riêng tư có thể được thực hiện thông qua việc sử dụng ZK.)

Việc quan trọng cần nhấn mạnh là RGB++ giới thiệu một giả định tin cậy quan trọng: người dùng cần tin tưởng một cách 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 thông qua giao thức đồng thuận là đáng tin cậy và không có lỗi. Nếu bạn không tin tưởng CKB, bạn có thể theo dõi quá trình giao tiếp và xác minh tương tác trong giao thức RGB ban đầu bằng cách chạy client 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 thùng chứa tài sản RGB của mình trên chuỗi CKB/Cardano UTXO mà không cần giao dịch qua chuỗi. Họ chỉ cần tận dụng các đặc điểm của UTXO trong các chuỗi công khai nêu trên và thiết lập các điều kiện mở khóa của thùng chứa Cell để liên kết với một địa chỉ/UTXO Bitcoin cụ thể. Nếu các bên liên quan đến giao dịch tài sản RGB tin tưởng vào sự an toàn của CKB, họ thậm chí có thể không cần phải thường xuyên công bố Commitments trên chuỗi Bitcoin. Thay vào đó, họ có thể tổng hợp và gửi một Commitment đến chuỗi Bitcoin sau khi đã xảy ra một số lượng giao dịch RGB. Điều này được biết đến là tính năng “gập giao dịch”, có thể giảm chi phí giao dịch.

Lưu ý rằng các “container” được sử dụng trong các ràng buộc đồng cấm cần được hỗ trợ bởi các chuỗi công cộng sử dụng mô hình UTXO hoặc có các tính năng tương tự trong cơ sở lưu trữ trạng thái của họ. Các chuỗi dựa trên EVM không phù hợp lắm cho mục đích này và có thể gặp phải nhiều thách thức. (Chủ đề này có thể được đề cập trong một bài viết riêng, vì nó liên quan đến rất nhiều nội dung. Độc giả quan tâm có thể tham khảo các bài viết trước đây của Geek Web3 có tiêu đề “RGB++ và Homomorphic Bindings: Làm thế nào CKB, Cardano và Fuel tạo điều kiện cho hệ sinh thái Bitcoin.“)

Tóm lại, chuỗi công khai hoặc các lớp mở rộng chức năng phù hợp để triển khai các kết nối đồng dạng nên có những đặc điểm sau:

1. Sử dụng mô hình UTXO hoặc các kế hoạch lưu trữ trạng thái tương tự.
2. Cung cấp đủ tính linh hoạt cho UTXO, cho phép các nhà phát triển viết mã mở khóa.
3. Có một không gian trạng thái liên quan đến UTXOs 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 có sẵn.

Tuyên bố:

1. Bài viết này được in lại từ [极客 Web3], Tất cả bản quyền thuộc về tác giả gốc [Faust]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ Học việc Gateđội và họ sẽ xử lý nó ngay lập tức.
2. Bảo Miễn Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không đại diện cho 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 đội ngũ Gate Learn. Trừ khi được nêu rõ, 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.