Từ RGB đến RGB++, tìm hiểu lại tiềm năng của CKB với tư cách là lớp 2 của Bitcoin và lớp thanh toán bên ngoài chuỗi
Tuyển chọn TechFlowTuyển chọn TechFlow
Từ RGB đến RGB++, tìm hiểu lại tiềm năng của CKB với tư cách là lớp 2 của Bitcoin và lớp thanh toán bên ngoài chuỗi
RGB++ về bản chất là đánh đổi quyền riêng tư để lấy tính dễ sử dụng, đồng thời mang lại những kịch bản mà giao thức RGB không thể thực hiện được.
Chuyên sâu báo cáo Web3Tác giả: Shew, Faust, Geeker web3
Cố vấn: CyberOrange, Unipass
Tóm tắt (dài): Giao thức RGB là một giao thức mở rộng BTC đầy tiềm năng, về bản chất là một hệ thống tính toán ngoài chuỗi, áp dụng tư tưởng tương tự Lightning Network: người dùng tự xác minh và ủy quyền các thay đổi tài sản liên quan đến bản thân (Verify by yourself), gửi kết quả/giá trị cam kết được bên khởi tạo giao dịch chấp nhận lên chuỗi Bitcoin.
-
Giao thức RGB tận dụng ý tưởng tương tự như Colored Coins và Mastercoin, gắn các "tài sản ký sinh" vào UTXO của Bitcoin. Nó lưu trữ "cam kết" (commitment) dữ liệu giao dịch ngoài chuỗi lên chuỗi Bitcoin, thay vì công bố toàn bộ dữ liệu DA như giao thức Ordinals. Dựa trên giá trị cam kết được ghi lại trên chuỗi Bitcoin, các client RGB có thể xác minh xem dữ liệu lịch sử RGB do client khác cung cấp có hợp lệ hay không.
-
Đồng thời, chỉ với hash/commitment thì không thể khôi phục được dữ liệu gốc ban đầu, bên ngoài không thể trực tiếp quan sát dữ liệu ngoài chuỗi tương ứng với giá trị cam kết trên chuỗi, điều này giúp bảo vệ quyền riêng tư, và so với inscription, việc chỉ đưa cam kết lên chuỗi giúp tiết kiệm dung lượng. Từ góc nhìn của bên thứ ba, họ thực sự không biết client RGB đang làm gì.
-
RGB còn tận dụng đặc điểm UTXO chỉ tiêu một lần của Bitcoin, thông qua cơ chế gọi là "niêm phong một lần", liên kết quyền sở hữu tài sản RGB với UTXO của Bitcoin. Như vậy có thể tận dụng tính bảo mật mạnh mẽ của Bitcoin để tránh tình trạng "tiêu kép / thanh toán kép" đối với tài sản RGB (miễn là UTXO Bitcoin không bị tiêu kép, tài sản RGB cũng sẽ không bị tiêu kép).
-
Tuy nhiên, như một hệ thống hợp đồng thông minh hoạt động ngoài chuỗi Bitcoin, RGB phụ thuộc vào các client khác nhau lưu trữ dữ liệu lịch sử cục bộ, mỗi client (người dùng) chỉ lưu dữ liệu liên quan đến bản thân, không thể thấy trạng thái tài sản của người khác. "Đảo dữ liệu" này tuy bảo vệ quyền riêng tư nhưng cũng khiến RGB gặp khó khăn khi mở rộng quy mô, giống như một mạng ngang hàng (P2P) gồm những người giao dịch OTC.
-
Ý tưởng của RGB++ là dùng Cell trên chuỗi CKB để biểu thị mối quan hệ quyền sở hữu tài sản RGB. Nó chuyển dữ liệu tài sản trước đây lưu trữ cục bộ trên client RGB sang biểu diễn dưới dạng Cell trên chuỗi CKB, thiết lập mối quan hệ ánh xạ giữa Cell và UTXO Bitcoin, biến CKB thành cơ sở dữ liệu công khai và tầng tiền thanh toán ngoài chuỗi cho tài sản RGB, thay thế client RGB, đạt được việc quản lý dữ liệu đáng tin cậy hơn và tương tác hợp đồng RGB.
-
Bản thân giao thức RGB chỉ hỗ trợ quy trình chuyển tiền tương tác, hai bên phải liên lạc thường xuyên, mô hình này khó hỗ trợ các trường hợp DeFi và phát hành tài sản RGB. Khi CKB thay thế client độc lập, có thể thực hiện giao dịch RGB không cần tương tác, thuận lợi cho việc triển khai DeFi, airdrop và các chức năng khác, đồng thời hỗ trợ tài sản BTC tương tác với tài sản trên chuỗi CKB mà không cần cross-chain.
-
Về bản chất, RGB++ là đánh đổi quyền riêng tư lấy tính dễ dùng, đồng thời mang lại các kịch bản mà giao thức RGB không thể thực hiện. Nếu người dùng coi trọng sự đơn giản, dễ dùng và tính đầy đủ chức năng, họ sẽ ưa thích RGB++; nếu theo đuổi quyền riêng tư và an ninh "Verify by yourself", họ sẽ ưa thích giao thức RGB truyền thống – tất cả tùy thuộc vào lựa chọn cá nhân. (Lý thuyết mà nói, RGB++ cũng có thể giải quyết vấn đề riêng tư bằng ZK và các phương pháp khác.)
Nguyên lý và ưu nhược điểm của giao thức RGB
Bản thân giao thức RGB là một giải pháp khá phức tạp, chúng tôi sẽ lấy một ví dụ cụ thể về chuyển tài sản RGB để giải thích cách hoạt động của giao thức RGB.
Giả sử có một loại token tuân thủ yêu cầu của giao thức RGB, gọi là TEST. Alice muốn Bob chuyển 100 token TEST cho mình, nói cách khác, muốn tạo ra một giao dịch chuyển token từ Bob → Alice.
Trước tiên, cần hiểu rằng giao thức RGB áp dụng cơ chế gọi là "đóng gói một lần". Về mặt hình thức, Bob chuyển cho Alice, thực tế là Bob kiểm soát UTXO A trên chuỗi Bitcoin, và UTXO A này thông qua một số phương pháp liên kết với một số tài sản RGB.
Nếu Bob tuyên bố muốn chuyển phần tài sản RGB liên kết với UTXO A cho Alice, ông ấy có thể tuyên bố như sau: chuyển 30 token TEST liên kết với UTXO A sang liên kết với UTXO B. Vì Alice là chủ sở hữu của UTXO B, cô ấy sẽ sở hữu 30 token TEST liên kết đó.
(Nguồn ảnh: Discoco Labs)
Thực tế, cách ghi nhận quyền sở hữu trên chuỗi Bitcoin đều được thực hiện thông qua UTXO. Việc tuyên bố rằng UTXO B có quyền kiểm soát một lượng tài sản RGB nhất định tương đương với việc chủ sở hữu UTXO B có thể kiểm soát lượng tài sản RGB đó, điều này khác biệt so với mô hình địa chỉ tài khoản mà chúng ta quen thuộc, là đặc tính riêng của các blockchain công cộng kiểu UTXO như Bitcoin.
Hiểu rõ điều này, chúng ta hãy xem xét quy trình hoạt động của giao thức RGB, từ đó cảm nhận được sự khác biệt với các tài sản ký sinh UTXO Bitcoin như Colored Coin và Mastercoin:
1. Theo nguyên lý giao thức RGB, Alice phải xuất hóa đơn (issues an invoice) cho giao dịch chuyển tiền, nêu rõ ý định của mình. Hóa đơn bao gồm các thông tin sau:
-
ID hợp đồng: Alice tuyên bố muốn tương tác với hợp đồng tài sản RGB nào
-
Giao diện: để Bob hiểu các giao diện tương tác của hợp đồng
-
Thao tác: tên giao diện hợp đồng mà Alice yêu cầu Bob gọi
-
Trạng thái: trạng thái hợp đồng mà Bob cần sửa đổi, trong ví dụ này là số lượng token mà Bob chuyển cho Alice
-
Seal (niêm phong): UTXO dùng cho niêm phong một lần, có thể hiểu đơn giản là UTXO Alice dùng để nhận ủy quyền tài sản RGB từ Bob.
Cuối cùng, Alice sẽ nhận được nội dung hóa đơn như sau:
Hóa đơn trên tuân theo định dạng sau:
2. Alice cần gửi hóa đơn trên cho Bob. Bob sẽ kiểm tra thông tin hóa đơn, tạo giao dịch RGB mới theo ý định của Alice để chuyển tài sản RGB cho Alice.
Tuy nhiên, cần lưu ý đặc biệt rằng Bob phải tìm cách chứng minh mình thực sự sở hữu một phần tài sản TEST. Lý do tại sao phải làm như vậy là vì giao thức RGB mặc định "không có bản ghi trạng thái tài sản toàn cục", không giống như Ethereum sử dụng một hợp đồng lưu ký công cộng để ghi lại và xử lý tài sản của mọi người.
Dưới giao thức RGB, các client khác nhau chỉ ghi lại dữ liệu tài sản liên quan đến bản thân, bao gồm số dư hiện tại và nguồn gốc lịch sử của tài sản đó, dữ liệu ghi lại bởi mỗi client cơ bản là khác nhau. Do đó, mỗi người không thể xác nhận tình trạng tài sản của người khác, nên khi giao dịch P2P phải xuất trình bằng chứng sở hữu tài sản.
Một cách ví von sinh động: bạn và đối phương đang giao dịch bằng tiền mặt, nhưng bạn không biết tiền mặt của họ có phải là tiền giả tự in hay không, bạn yêu cầu họ làm rõ nguồn gốc tiền, đã qua tay bao nhiêu người, để xác định xem họ có đang lừa bạn bằng tiền giả hay không.
Sau khi cả hai bên công nhận lẫn nhau, có thể giao dịch một cách thoải mái, mỗi giao dịch RGB chỉ cần các bên tham gia công nhận là đủ, hoàn toàn ngang hàng (giống như OTC).
Rõ ràng, mô hình này có thể bảo vệ quyền riêng tư, vì tình trạng tài sản và ghi chép giao dịch của mỗi người sẽ không dễ dàng bị bên ngoài biết được, người ngoài khó biết được bạn và đối tác đã làm gì. Cũng giống như tiền mặt có thể ẩn danh tốt hơn chuyển khoản ngân hàng. Tuy nhiên, rõ ràng điều này cũng gây bất tiện cho trải nghiệm người dùng.
Trong ví dụ Alice và Bob đã nêu, sau khi Bob nhận được hóa đơn của Alice và biết được ý định của cô, anh ta phải chọn từ dữ liệu lịch sử cục bộ của client những bản ghi chuyển nhượng liên quan đến tài sản TEST, cùng với giao dịch mới tạo Bob → Alice, gửi cho Alice để kiểm tra, chứng minh rằng giao dịch RGB mới / thay đổi quyền sở hữu đằng sau là hợp lệ và chính xác về nguồn gốc quyền sở hữu tài sản.
Thông thường, dữ liệu lưu trữ cục bộ trên client được gọi là Stash ("kho chứa"), bao gồm dữ liệu quá khứ của tài sản RGB. Chúng ta có thể coi Stash như bản ghi nhật ký của hợp đồng tài sản RGB.
3. Khi Alice nhận được dữ liệu và giao dịch mới tuyên bố Bob → Alice từ Bob, cô sẽ xác minh tính hợp lệ; nếu vượt qua xác minh, Alice sẽ tạo một "chữ ký xác nhận", gửi lại cho Bob.
4. Sau khi Bob nhận được chữ ký xác nhận từ Alice, anh ta sẽ phát tán Commitment (cam kết) tương ứng với giao dịch Bob → Alice vào mạng BTC, cuối cùng ghi vào chuỗi BTC, làm cho nó có "tính cuối cùng".
(Sơ đồ cấu trúc Commitment, thực chất là một merkle root)
Nếu trong giao dịch chuyển Bob → Alice, tuyên bố chủ nhân UTXO B sẽ sở hữu 30 token TEST, thì Alice chỉ cần chứng minh mình là chủ nhân UTXO B là có thể sử dụng các token TEST đó.
5. Nếu trong tương lai Alice muốn chuyển token TEST cho người khác, khi xuất trình nguồn gốc lịch sử của các token TEST này, đối phương có thể xác minh dựa trên giá trị commitment trên chuỗi Bitcoin, xem dữ liệu mà Alice cung cấp có khớp với giá trị cam kết trên chuỗi hay không. Điều này có thể ngăn chặn việc làm giả dữ liệu.
Ưu điểm của giao thức RGB là có thể hỗ trợ tính toán hợp đồng thông minh phức tạp ngoài chuỗi. Về bản chất, nó chuyển các bước tính toán ra ngoài chuỗi BTC, chỉ ghi lại Commitment trên chuỗi, vừa bảo vệ quyền riêng tư, vừa tuyên bố ngoài chuỗi mối liên hệ giữa UTXO Bitcoin và quyền sở hữu tài sản RGB, mượn sức mạnh của Bitcoin để khắc ghi và thực hiện thay đổi quyền sở hữu tài sản RGB.
Do tất cả các tuyên bố giao dịch đều cần được các bên liên quan xác minh và ủy quyền, mô hình bảo mật dựa trên giả định "con người hợp lý", miễn là các bên liên quan tỉnh táo, miễn là Bitcoin an toàn, quyền sở hữu tài sản RGB là "cơ bản an toàn".
Tuy nhiên, nhược điểm của giao thức RGB cũng rất rõ ràng (trước đó đã đề cập đến vấn đề "đảo dữ liệu" và lưu trữ phân mảnh). Thứ nhất, để chuyển tiền cho người khác, thậm chí cần có sự đồng ý và xác nhận của đối phương, hai bên cơ bản phải luôn trực tuyến;
Thứ hai, do thiếu phương thức ghi chép dữ liệu có thể nhìn thấy toàn cục, việc phát hành hợp đồng RGB thậm chí còn sử dụng hình thức kỳ lạ, người dùng hợp đồng phải biết trước từ người phát hành về các chức năng giao diện mà hợp đồng chứa, cách biết cụ thể có thể qua email hoặc quét mã QR. (Theo lời tuyên bố hiện tại của nhóm phát triển, có lẽ treo mã hợp đồng trên trang chủ website, ghim tweet cũng được.)
Chúng ta hãy cùng thảo luận về trạng thái hợp đồng của giao thức RGB. Trong giao thức RGB, trạng thái khởi nguyên (Genesis) của hợp đồng do người tạo thiết lập khi tạo hợp đồng, ví dụ như tên token, tổng cung trong hợp đồng RBG-20. Sau đó, trạng thái hợp đồng thay đổi theo tiến trình liên tục của giao dịch RGB, nhưng sự tiến hóa trạng thái hợp đồng này là phi tuyến tính, tạo thành một đồ thị acyclic có hướng (DAG).
(Phạm vi nhìn thấy của owner1 là phần màu xanh lam và xanh lá, phạm vi nhìn thấy của Owner2 là phần màu xanh lam và vàng)
Ví dụ, khi Bob chuyển cho Alice, Bob chỉ xuất trình bản ghi chuyển nhượng từ lúc khởi tạo hợp đồng đến lúc Bob nhận được token, đường dữ liệu chứa đựng khá hẹp. Alice cũng chỉ có thể biết được thông tin giao dịch trong nhánh đường dẫn này, khó biết được thông tin chuyển nhượng của người khác. Điều này tuy bảo vệ quyền riêng tư cho người dùng RGB nhưng cũng gây hậu quả xấu: người dùng khó biết được trạng thái toàn cục của hợp đồng RGB, ví dụ như mỗi người có bao nhiêu tài sản RGB. Điều này sẽ gây ra nhiều rắc rối.
Ví dụ, khi giao dịch Bob → Alice tiến hành đến bước cuối cùng, giá trị cam kết được ghi vào chuỗi BTC và không thể đảo ngược, Bob có thể xóa một phần dữ liệu cục bộ — nếu Bob đã chuyển toàn bộ token TEST của mình cho người khác, anh ta có thể trực tiếp xóa dữ liệu liên quan đến token TEST lưu trữ cục bộ để giảm áp lực lưu trữ.
Trong khi đó, Alice với tư cách là người nhận token, phải ghi lại cục bộ toàn bộ dữ liệu liên quan đến giao dịch này. (Nếu Bob xóa dữ liệu token TEST cục bộ, và nút client của Alice lại bị hỏng hoàn toàn do sự cố, lúc đó tài sản của Alice có bị đóng băng vĩnh viễn không? Bởi vì không có nơi nào khác lưu trữ dữ liệu tài sản TEST của Alice, trừ khi đã sao lưu trước đó.)
Điều này về bản chất có thể quy về vấn đề DA và lưu trữ dữ liệu, tức là dữ liệu mới của giao thức RGB không thể được lan truyền một cách đáng tin cậy và toàn cục, cuối cùng khiến các client khác nhau trở thành "đảo dữ liệu". Trước đây, phương án Plasma từng cực kỳ thịnh hành trong hệ sinh thái Ethereum nhưng sau đó bị bỏ rơi, cũng vì không thể giải quyết vấn đề DA, cuối cùng chết yểu.
Ngoài ra, giao thức RGB còn yêu cầu hai bên giao dịch phải liên lạc rất nhiều, nhiều bước liên lạc phải dựa vào cơ sở hạ tầng tập trung, chi tiết ở khía cạnh này chưa trưởng thành, nhóm phát triển thậm chí nói có thể liên lạc qua email.
Rõ ràng, thiết kế giao thức RGB không thân thiện với người dùng phổ thông theo đuổi tính dễ dùng, dù những người giàu có nhiều tài sản và theo đuổi quyền riêng tư cao sẽ sẵn lòng sao lưu dữ liệu và duy trì client, nhưng đối với người dùng phổ thông, gánh nặng này vẫn quá lớn, gây cản trở nghiêm trọng cho việc áp dụng quy mô lớn. Thậm chí đến nay, người ta cho rằng chưa xuất hiện tài sản RGB hiện tượng nào.
Trong hình dưới đây, chúng tôi đưa ra sơ đồ quy trình chuyển tài sản RGB, độc giả có thể dựa vào hình này để hiểu sâu hơn toàn bộ quy trình chuyển tiền.
Tóm lại, giao thức RGB mượn UTXO Bitcoin để thực hiện thay đổi quyền sở hữu tài sản RGB, và bằng cách phát hành giá trị cam kết (Commitment) lên chuỗi BTC, đảm bảo dữ liệu ngoài chuỗi không thể bị client tự ý thay đổi. Thực tế, "niêm phong một lần" của RGB là thông qua tuyên bố giao dịch RGB ngoài chuỗi để liên kết UTXO Bitcoin với quyền sở hữu tài sản RGB, nhờ vậy mượn sức mạnh bảo mật tuyệt vời của Bitcoin để đảm bảo an toàn cho tài sản RGB. Tuy nhiên, do vấn đề DA và lưu trữ dữ liệu, tính khả dụng và UX của giao thức RGB nguyên bản khá kém, và tài sản dễ bị đóng băng (không dùng được) do mất dữ liệu.
RGB++: Giao thức RGB nâng cao dựa trên CKB
Ở phần trên, chúng tôi đã tổng kết ưu và nhược điểm của hệ thống RBG, trong đó, "đảo dữ liệu" của client và trạng thái hợp đồng không thể nhìn thấy toàn cục là những yếu tố chính ảnh hưởng đến tính dễ dùng của giao thức RGB.
Thực tế, ưu và nhược điểm của giao thức RGB đều rất rõ ràng, những người theo đuổi quyền riêng tư và an ninh cao sẽ có xu hướng tự vận hành client và sao lưu dữ liệu, nhưng người dùng phổ thông rõ ràng không đủ kiên nhẫn (ví dụ, đa số người dùng Lightning Network sẽ phụ thuộc vào các nút bên thứ ba thay vì tự vận hành client).
Dựa trên lý do này, đồng sáng lập Nervos Cipher đã đề xuất giải pháp RGB++, nhằm ủy thác trạng thái tài sản RGB, phát hành hợp đồng và xác minh giao dịch cho chuỗi công cộng CKB. CKB đóng vai trò nền tảng lưu trữ dữ liệu và tính toán bên thứ ba, không còn cần người dùng tự vận hành client RGB.
Do bản thân CKB là mô hình UTXO mở rộng (Cell), có thể ghi thông tin ngoài chuỗi của tài sản RGB vào Cell, và thiết lập mối quan hệ ánh xạ 1-1 giữa Cell và UTXO Bitcoin, thực hiện giải pháp lưu trữ và xác minh dữ liệu tài sản RGB dựa trên CKB, giải quyết vấn đề tính dễ dùng, bổ sung tăng cường cho phương án RGB nguyên bản.
Đoạn văn này đọc có vẻ hơi rối, chúng tôi sẽ giải thích rõ hơn:
Như đã đề cập trước đó, bản chất giao thức RGB là thông qua việc phát hành cam kết trên chuỗi và tuyên bố ngoài chuỗi để liên kết UTXO Bitcoin với quyền sở hữu tài sản RGB. Nhưng dữ liệu hợp đồng tài sản RGB được lưu trữ phân mảnh cục bộ trên các client khác nhau, không có cái nhìn toàn cục.
RGB++ sử dụng phiên bản UTXO mở rộng của CKB - Cell, để hiển thị trực tiếp mối quan hệ ánh xạ giữa UTXO Bitcoin và tài sản RGB tương ứng trên chuỗi CKB, và để chuỗi công cộng CKB thay thế client P2P của người dùng, xác minh tính hợp lệ của từng giao dịch RGB.
Có được bản ghi dữ liệu RGB có thể nhìn thấy toàn cục này, nhiều kịch bản khó triển khai trong giao thức RGB sẽ dễ dàng hiện thực hơn.
(Quy trình giao dịch RGB++, ghi thông tin tài sản RGB vào Cell, thiết lập liên kết giữa Cell và UTXO Bitcoin, cuối cùng bao gồm cả giao dịch RGB++ xảy ra trên CKB và UTXO Bitcoin liên kết với tài sản RGB++, rồi đưa tất cả vào cam kết, ghi giá trị cam kết lên chuỗi Bitcoin)
Có thể có người nghĩ ngay đến EVM. Liệu chúng ta có thể dùng EVM để lưu trữ trạng thái và xác minh RGB không? Câu trả lời là: rất phiền phức, vì tài sản RGB về bản chất sống ký sinh trên UTXO Bitcoin, có mối quan hệ ánh xạ 1-1 với UTXO Bitcoin. Nếu muốn thiết lập mối quan hệ ánh xạ giữa UTXO Bitcoin và dữ liệu hợp đồng EVM, việc hiện thực kỹ thuật sẽ không thuận lợi, thà chọn thẳng một chuỗi công cộng UTXO còn hơn.
Hơn nữa, "tài sản" trên Ethereum thường là hàng hóa công cộng kiểu pool, một hợp đồng ghi lại dữ liệu tài sản của vô số người, người kiểm soát hợp đồng có quyền lực tuyệt đối, cách xử lý tài sản này mâu thuẫn nghiêm trọng với UTXO Bitcoin và giao thức RGB, hai bên sau theo đuổi triệt để tư nhân hóa tài sản, mỗi người hoàn toàn kiểm soát tài sản của mình (hãy nghĩ đến sự khác biệt giữa tiền mặt và WeChat Pay), không cần lo lắng về các vấn đề vốn tồn tại trên Ethereum và các chuỗi EVM: chủ hợp đồng滥 dụng quyền lực, hợp đồng lỗi gây thiệt hại tài chính, di dời dữ liệu hợp đồng tài sản rất phiền phức, v.v.
(Trích từ bài viết trước đây của Geeker web3: "Nhân vật nổi tiếng trong giới công nghệ Xiangma: Các chuỗi hiệu suất cao khó tạo chuyện mới, hợp đồng thông minh liên quan đến phân phối quyền lực")
Vì vậy, nếu muốn biểu đạt mối quan hệ ánh xạ giữa UTXO Bitcoin và tài sản RGB ngoài chuỗi một cách thuận lợi, lựa chọn tốt nhất vẫn là thông qua chuỗi UTXO. CKB hỗ trợ UTXO mở rộng - Cell, và tập lệnh CKB VM dựa trên RISC-V, dễ dàng tương thích với các thuật toán mật mã học khác nhau hơn EVM, bao gồm thuật toán xác minh khóa công khai/khóa riêng của Bitcoin, do đó thuận lợi hơn cho việc hiện thực giải pháp kỹ thuật đề xuất bởi RGB++.
Hiện thực kỹ thuật của RGB++
RGB++ sử dụng UTXO mở rộng của CKB - Cell. Một Cell bao gồm các trường sau:
Capacity đại diện cho kích thước không gian trên chuỗi mà Cell này sở hữu, data chỉ dữ liệu được chứa trong Cell, có thể đọc hoặc sửa đổi.
Type là mã chương trình gắn với Cell này, giới hạn điều kiện sửa đổi dữ liệu data. Ví dụ, Cell của bạn chứa dữ liệu 100 token TEST, nhưng bạn tuyên bố chuyển 110 token cho người khác, điều này không phù hợp với điều kiện giới hạn trong Type, sẽ bị từ chối.
Lock đại diện cho logic xác minh quyền sở hữu Cell, tương tự như script mở khóa của UTXO Bitcoin.
Chúng ta có thể hiểu Cell như UTXO phiên bản nâng cấp, thêm hai trường Type và Capacity, đồng thời data có thể tự định nghĩa kiểu dữ liệu; còn cách thay đổi quyền sở hữu Cell thì tương tự UTXO Bitcoin, đều thông qua script mở khóa để thực hiện.
Ý tưởng của RGB++ là dùng Cell trên chuỗi CKB để biểu thị mối quan hệ quyền sở hữu tài sản RGB. Nó chuyển dữ liệu tài sản trước đây lưu trữ cục bộ trên client RGB sang biểu diễn dưới dạng Cell trên chuỗi CKB, biến CKB thành cơ sở dữ liệu công khai cho tài sản RGB. Cell biểu thị tài sản RGB sẽ có mối quan hệ ánh xạ 1-1 với UTXO trên chuỗi Bitcoin, mối quan hệ ánh xạ này sẽ được hiển thị trực tiếp trong trường Lock của Cell.
Ví dụ, giả sử một tài sản RGB liên kết với UTXO A của Bitcoin, thì Cell ánh xạ tương ứng có thể thiết lập điều kiện xác minh quyền sở hữu của mình giống như UTXO A (tức là đặt script Lock bằng điều kiện mở khóa của UTXO A). Nếu bạn là người kiểm soát UTXO A, bạn có thể trực tiếp thao tác Cell ánh xạ trên CKB, dĩ nhiên, CKB sẽ xác minh xem bạn có thực sự là chủ nhân UTXO A hay không.
Trên chuỗi CKB sẽ hiện thực nút nhẹ Bitcoin, đồng bộ tiêu đề khối Bitcoin. Khi bạn tuyên bố giao dịch RGB, muốn thao tác Cell tương ứng với tài sản RGB, trước tiên phải chứng minh mình là người kiểm soát UTXO A của Bitcoin, các bước chứng minh gồm hai bước:
-
Chứng minh với nút nhẹ Bitcoin trên chuỗi CKB rằng UTXO A tồn tại trên chuỗi Bitcoin, cần xuất trình Merkle Proof;
-
Xuất trình chữ ký số, chứng minh mình là chủ sở hữu UTXO A.
Trong phương án RGB++, sau khi người dùng tuyên bố chuyển tài sản RGB ở frontend, sẽ kích hoạt một giao dịch trên chuỗi CKB, sửa đổi Cell ghi lại dữ liệu tài sản RGB, thay đổi quyền sở hữu của nó. Ban đầu có thể là người kiểm soát UTXO 1 của Bitcoin sở hữu Cell này, sau khi thay đổi quyền sở hữu, người kiểm soát UTXO 2 của Bitcoin trở thành chủ nhân mới của Cell. Tất cả điều này đều có thể nhìn thấy trên chuỗi CKB.
Lưu ý rằng, quy trình làm việc liên quan đến cam kết trên chuỗi BTC vẫn diễn ra trên mạng chính BTC, nghĩa là RGB++ vẫn phải phát hành Commitment lên chuỗi Bitcoin, liên kết với bản ghi giao dịch tài sản RGB xảy ra trên CKB. Bước này không khác gì so với giao thức RGB truyền thống.
Tuy nhiên, điểm khác biệt là công việc trước đây do client RGB đảm nhận ngoài chuỗi nay được CKB đảm nhiệm, ví dụ như đối tác giao dịch cần xác minh nguồn gốc tài sản, client cần lưu trữ cục bộ dữ liệu nguồn gốc tài sản, việc phát hành hợp đồng RGB phải qua kênh bên thứ ba, v.v., những gánh nặng phiền phức này đều được CKB giải quyết, người dùng không cần tự vận hành client.
Như vậy giải quyết được vấn đề "đảo dữ liệu" của client RGB, cũng khắc phục được nhược điểm trạng thái hợp đồng không thể nhìn thấy toàn cục. Đồng thời, hợp đồng RGB có thể được triển khai trực tiếp trên chuỗi CKB, nhìn thấy toàn cục, để các Cell RGB tham chiếu, tránh được loạt thao tác kỳ lạ khi phát hành hợp đồng trong giao thức RGB.
Tóm lại, CKB tận dụng tính lập trình của script Cell, trước tiên xác định người khởi tạo giao dịch RGB thực sự sở hữu UTXO Bitcoin liên kết với tài sản RGB, nếu vượt qua xác minh, cho phép người dùng chuyển nhượng Cell ghi lại dữ liệu tài sản RGB cho người khác thông qua giao dịch.
Tóm gọn, CKB đóng vai trò nền tảng lưu trữ dữ liệu công khai cho tài sản RGB, cung cấp chức năng lưu trữ dữ liệu và phát hành hợp đồng có thể nhìn thấy toàn cục, đồng thời cung cấp chức năng xác minh quyền sở hữu và tính toán. Nói gọn hơn, CKB thay thế client trong RGB, đồng thời giải quyết luôn các vấn đề khác.
Tất nhiên, vì RGB++ đã thực hiện phát hành dữ liệu có thể nhìn thấy toàn cục, mức độ riêng tư so với giao thức RGB tất nhiên bị giảm, nhưng lợi ích là tính dễ dùng được nâng cao đáng kể.
Do đó, bản chất RGB++ là đánh đổi riêng tư lấy tính dễ dùng, đồng thời mang lại các kịch bản mà giao thức RGB không thể thực hiện. Nếu người dùng coi trọng sự đơn giản, dễ dùng và tính đầy đủ chức năng, họ sẽ ưa thích RGB++; nếu theo đuổi riêng tư và an ninh "Verify by yourself", họ sẽ ưa thích giao thức RGB truyền thống – tất cả tùy thuộc vào lựa chọn cá nhân (tư duy tương tự như Vitalik bình luận về Layer2 Ethereum, theo đuổi an ninh thì dùng Rollup, theo đuổi chi phí thấp thì dùng các phương án non-Rollup như Validium và Optimium). Tất nhiên, theo whitepaper RGB++, sau này cũng có thể hiện thực giải pháp giao dịch riêng tư trên chuỗi CKB, ẩn danh danh tính người dùng và số tiền giao dịch.
Tính năng bổ sung của RGB++
Tính không tương tác của giao dịch (rất quan trọng)
Một vấn đề quan trọng của giao thức RGB nguyên bản là người nhận phải gửi một tin nhắn cho người gửi (tức cái "phiếu thu" đã nói ở trên), chỉ rõ việc liên kết một UTXO của mình với tài sản RGB, giao dịch chuyển RGB mới có thể thực hiện thuận lợi. Điều này yêu cầu người nhận và người gửi phải trao đổi tương tác nhiều lần mới hoàn thành một giao dịch thông thường, rõ ràng làm tăng độ khó hiểu cho người dùng và độ phức tạp của sản phẩm. Trong khi đó, RGB++ tận dụng đặc điểm của CKB là nền tảng lưu trữ và tính toán dữ liệu, cho phép các đối tác hoàn thành chuyển tiền bằng phương pháp bất đồng bộ, không cần tương tác.
Khi A chuyển cho B, chỉ cần biết trước địa chỉ của B, tuyên bố chuyển cho địa chỉ đó, không cần người nhận trực tuyến hay cung cấp dữ liệu. Sau đó, người nhận có thể tự đi nhận tài sản, script code trên chuỗi CKB sẽ xác minh xem người nhận có phải là người được người gửi chỉ định hay không. Rõ ràng, mô hình này phù hợp hơn với thói quen của đa số người, các mô hình như airdrop, phân phối thưởng vốn không hỗ trợ trong giao thức RGB nay cũng có thể thực hiện được, điều này cũng thuận lợi cho việc phát hành tài sản RGB.
Hơn nữa, mô hình hoạt động của giao thức RGB vốn dĩ không thuận lợi cho việc triển khai các trường
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@godrealmx
