المؤلف: شو وفاوست، مهووس الويب3

ملخص (أطول): · يعد بروتوكول RGB بروتوكول توسيع BTC واعدًا نسبيًا. وهو في الأساس نظام حوسبة خارج السلسلة يستخدم الشبكة المسرّعة. فكرة مماثلة : يقوم المستخدمون شخصيًا بالتحقق والموافقة على تغييرات الأصول المتعلقة بهم (تحقق بنفسك)، وإرسال النتائج/الالتزامات المعتمدة من قبل بادئ المعاملة إلى سلسلة Bitcoin.

·يستخدم بروتوكول RGB أفكارًا مشابهة لأفكار العملات المعدنية الملونة وMastercoin، ويرتبط بـ Bitcoin UTXO “الأصول الطفيلية”. يقوم بتخزين "الالتزام" الخاص ببيانات المعاملات خارج السلسلة على سلسلة Bitcoin، بدلاً من نشر بيانات DA كاملة مثل بروتوكول Ordinals. استنادًا إلى قيمة الالتزام المسجلة في سلسلة Bitcoin، يمكن لعميل RGB التحقق مما إذا كانت بيانات RGB التاريخية المقدمة من العملاء الآخرين صالحة.

·في الوقت نفسه، لا يمكن للتجزئة/الالتزام وحده استعادة الصورة الأصلية خلفه، والخارج لا يمكن للعالم أن يراقب السلسلة مباشرة. قم بتحميل البيانات خارج السلسلة المقابلة لقيمة الالتزام، والتي يمكن أن تحمي الخصوصية. بالمقارنة مع النقش، فإن وضع الوعد على السلسلة فقط هو الذي يمكن أن يوفر المساحة. من وجهة نظر الطرف الثالث، فهو في الواقع لا يعرف ما يفعله عميل RGB.

·يستفيد RGB أيضًا من ميزة الإنفاق لمرة واحدة في Bitcoin UTXO، ويربط ملكية أصول RGB مع Bitcoin UTXO من خلال فكرة تسمى حامل "الختم لمرة واحدة" أعلى. يمكن أن يستفيد هذا من الأمان القوي للبيتكوين لتجنب "الإنفاق المزدوج/الإنفاق المزدوج" لأصول RGB (طالما لم يتم إنفاق Bitcoin UTXO بشكل مزدوج، فلن يتم إنفاق أصول RGB بشكل مضاعف).

·لكن RGB، باعتباره نظام عقد ذكي يتم تنفيذه ضمن سلسلة Bitcoin، يعتمد على عملاء مختلفين. يقوم بتخزين البيانات التاريخية محليًا، ويقوم العملاء المختلفون (المستخدمون) بتخزين البيانات المتعلقة بهم فقط ولا يمكنهم رؤية حالة الأصول للآخرين. على الرغم من أن "جزيرة البيانات" هذه تحمي الخصوصية، إلا أنها تجعل RGB يواجه مشكلة في الاعتماد على نطاق واسع، مما يجعلها أشبه بشبكة P2P تتكون من متداولين خارج البورصة.

·تتمثل فكرة RGB++ في استخدام الخلايا الموجودة في سلسلة CKB للتعبير عن علاقة ملكية أصول RGB. فهو ينقل بيانات الأصول المخزنة محليًا في الأصل على عميل RGB إلى سلسلة CKB ويعبر عنها في شكل خلية، مما ينشئ علاقة رسم خرائط مع Bitcoin UTXO، مما يسمح لـ CKB بالعمل كقاعدة بيانات عامة وطبقة تسوية مسبقة خارج السلسلة لـ أصول RGB: يستبدل عميل RGB لتحقيق استضافة بيانات أكثر موثوقية وتفاعل عقد RGB. بالنسبة للطبقة الثانية الأخرى المستندة إلى UTXO، يعد هذا "الربط المتماثل" اتجاهًا.

·يدعم بروتوكول RGB نفسه عمليات النقل التفاعلية فقط. يحتاج طرفا المعاملة إلى التواصل بشكل متكرر. يصعب دعم هذا النموذج لسيناريوهات Defi ولا يفضي إلى إصدار أصول RGB. بعد أن يحل CKB محل العميل المستقل، يمكنه تحقيق معاملات RGB غير التفاعلية، مما يفضي إلى وظائف مثل هبوط Defi والإسقاط الجوي، ويدعم أصول BTC دون تفاعل عبر السلسلة مع الأصول الموجودة في سلسلة CKB.

·إن جوهر RGB++ هو المتاجرة بالخصوصية من أجل سهولة الاستخدام، مع تحقيق سيناريوهات لا يمكن تحقيقها بواسطة بروتوكول RGB. إذا كان المستخدمون يقدرون سهولة الاستخدام والوظائف الكاملة للمنتج، فسوف يفضلون RGB++. إذا كانوا يسعون وراء الخصوصية والأمان للتحقق بنفسك، فسوف يفضلون بروتوكول RGB التقليدي. كل هذا يتوقف على اختيار المستخدم. (من الناحية النظرية، يمكن لـ RGB++ أيضًا حل مشكلات الخصوصية من خلال ZK وطرق أخرى)

مبادئ بروتوكول RGB ومزاياه و العيوب

يعد بروتوكول RGB بحد ذاته حلاً معقدًا نسبيًا. فلنأخذ نقل أصول RGB محددًا كمثال لشرح RGB للجميع كيف يعمل البروتوكول.

لنفترض أن هناك رمزًا مميزًا يلبي متطلبات بروتوكول RGB، يسمى TEST. تأمل أليس أن ينقل بوب 100 رمز TEST إلى نفسها، وبعبارة أخرى، تأمل في إنشاء نقل رمزي من بوب إلى أليس.

دعني أشرح هنا أولاً. يتبنى بروتوكول RGB فكرة تسمى "التغليف لمرة واحدة". ظاهريًا يقال ذلك يقوم بوب بتحويل الأموال إلى أليس، ما يعنيه في الواقع هو أن بوب يتحكم في UTXO A على سلسلة البيتكوين، ويرتبط UTXO A ببعض أصول RGB من خلال طرق معينة.

إذا أعلن بوب أنه يريد نقل جزء من أصول RGB المرتبطة بـ UTXO A إلى Alice، فيمكنه الإعلان على النحو التالي: نقل يتم نقل 30 رمزًا مرتبطًا برموز UTXO A TEST إلى UTXO B للارتباط. نظرًا لأن أليس هي مالكة UTXO B، فهي تمتلك 30 رمزًا مميزًا مرتبطًا بـ TEST.

(المصدر: Discoco Labs)

في الواقع، طريقة تسجيل الملكية على سلسلة Bitcoin تتم من خلال UTXO Realized، موضحًا أن UTXO B مؤهل للتحكم بمقدار xx من أصول RGB وهو ما يعادل القول بأن مالك UTXO B يمكنه التحكم بمقدار xx من أصول RGB. وهذا لا يتوافق مع نموذج عنوان الحساب الذي اعتدنا عليه، وهو فريد لـ UTXO العام سلاسل مثل Bitcoin.سمات فريدة من نوعها.

بعد فهم ذلك، دعونا نفحص سير عمل بروتوكول RGB، ويمكننا أن نشعر بالفرق بينه وبين أصول Bitcoin UTXO الطفيلية مثل العملات المعدنية الملونة وMastercoin:

1. وفقًا لمبادئ بروتوكول RGB، يجب على أليس أولاً إصدار فاتورة لمعاملة التحويل والإشارة إلى نيتها. تحتوي الفاتورة على المعلومات التالية:

معرف العقد:تعلن أليس عن عقد أصول RGB الذي تريد التفاعل معه

الواجهة: دع بوب يعرف جميع الواجهات التفاعلية للعقد

العملية:اسم واجهة العقد التي تطلب أليس من بوب الاتصال بها

الحالة:حالة العقد التي يحتاج Bob إلى تعديلها، في هذه الحالة هو عدد الرموز المميزة التي ينقلها Bob إلى Alice

Seal: UTXO يُستخدم للختم لمرة واحدة. ويمكن فهمه ببساطة على أنه UTXO الذي تستخدمه Alice لقبول تفويض أصول Bob's RGB.

أخيرًا، ستحصل أليس على محتوى الفاتورة التالية:

< img src="https://img.jinse.cn/7180016_image3.png">

تتبع الفاتورة أعلاه التنسيق التالي:

2.تحتاج أليس إلى إرسال الفاتورة أعلاه إلى بوب. سيتحقق بوب من معلومات الفاتورة، وينشئ معاملة RGB جديدة وفقًا لنية Alice، وينقل أصول RGB إلى Alice.

ولكن ينبغي إيلاء اهتمام خاص هنا. يجب أن يحاول بوب إثبات أنه يمتلك ملكية جزئية لأصول TEST. أما سبب القيام بذلك، فذلك لأن بروتوكول RGB الافتراضي هو "لا توجد سجلات حالة أصول مرئية عالميًا" ولا يستخدم عقد وصاية عام لتسجيل ومعالجة أصول الجميع كما تفعل إيثريوم.

بموجب بروتوكول RGB، يقوم العملاء المختلفون بتسجيل بيانات الأصول المتعلقة بهم فقط، بما في ذلك الرصيد الحالي والمصادر التاريخية لهذه الأصول. المسجلة من قبل كل عميل غير متناسقة في الأساس. بهذه الطريقة، لا يستطيع الجميع تأكيد حالة أصول الآخرين، لذلك يجب تقديم شهادات الأصول أثناء معاملات P2P.

لاستخدام استعارة حية، تستخدم أنت والطرف الآخر الأوراق النقدية للتداول، لكنك لا تعرف ما إذا كانت الأوراق النقدية للطرف الآخر أم لا إذا قمت بطباعة نقود مزيفة، فاطلب منه أن يخبرك بوضوح من أين حصل على الأوراق النقدية وعدد الأشخاص الذين تداول معهم، وذلك لتحديد ما إذا كان الطرف الآخر يستخدم النقود المزيفة لخداعك.

بعد أن يتعرف الطرفان على بعضهما البعض، يمكنهم إجراء معاملات جريئة بثقة. تتطلب كل معاملة RGB فقط أن يتعرف الطرفان على بعضهما البعض. إنها P2P تمامًا (على غرار OTC).

من الواضح أن هذا النموذج يمكنه حماية الخصوصية، لأن حالة الأصول وسجلات المعاملات لكل شخص لن تكون معروفة للعالم الخارجي بسهولة. وهذا أمر صعب لكي يعرف الغرباء ما تم فعله مع الطرف المقابل. والمنطق هنا هو أن الأوراق النقدية يمكن إخفاءها بشكل أفضل من التحويلات المصرفية. ولكن من الواضح أن هذا سيؤدي أيضًا إلى إزعاج تجربة المستخدم.

في حالة أليس وبوب المذكورة سابقًا، بعد أن يتلقى بوب فاتورة أليس ويعلم بنيتها، فإنه يحتاج إلى الحصول على الفاتورة من العميل المحلي. من البيانات التاريخية، حدد سجلات النقل التاريخية المتعلقة بأصل TEST، جنبًا إلى جنب مع Bob الذي تم إنشاؤه حديثًا -> نقل Alice، وقم بتسليمها إلى Alice للتحقق منها لإثبات تغيير معاملة/ملكية RGB الجديد، والتغيير المقابل مصدر ملكية الأصول وراءه صالح وخالي من الأخطاء.

بشكل عام، تسمى البيانات المخزنة محليًا على العميل "مجموعة Stash"، والتي تحتوي على البيانات السابقة لأصول RGB. يمكننا أن نفكر في Stash باعتباره سجل سجل لعقد أصول RGB.

3.عندما تتلقى أليس البيانات من بوب وبوب المعلن عنه حديثًا -> بعد معاملة أليس، سيتم التحقق من صحتها،إذا بعد مرور عملية التحقق، ستقوم أليس بإنشاء "توقيع تأكيد" وإعادته إلى بوب.

4. بعد أن يتلقى بوب توقيع تأكيد أليس، يرسل بوب —> أليس الالتزام يتم بث المعاملة المقابلة إلى شبكة BTC ثم كتابتها أخيرًا إلى سلسلة BTC، مما يجعلها "نهائية".

(المخطط الهيكلي للالتزام هو في الواقع جذر ميركل)

إذا كان بوب —>أليس أثناء عملية النقل، يُذكر أن مالك UTXO B سيمتلك 30 رمز TEST. يمكن لـ Alice استخدام رموز TEST هذه طالما أنها تثبت أنها مالكة UTXO B.

5.إذا أرادت أليس نقل رموز TEST المميزة إلى الآخرين في المستقبل، فيجب عليها إظهار المصدر التاريخي من هذه الاختبارات في هذا الوقت، يمكن للطرف الآخر التحقق بناءً على قيمة الالتزام في سلسلة البيتكوين لمعرفة ما إذا كانت البيانات المقدمة من أليس تتوافق مع قيمة الالتزام في السلسلة. يمنع هذا تزوير البيانات.

تتمثل فائدة بروتوكول RGB في أنه يمكنه دعم حسابات العقود الذكية المعقدة خارج السلسلة. إنه ينقل بشكل أساسي خطوات الحساب خارج سلسلة BTC ويسجل فقط الالتزام على السلسلة. بينما يحمي الخصوصية، فإنه يعلن أيضًا عن ملكية أصول Bitcoin UTXO وRGB خارج السلسلة. ، باستخدام Bitcoin لحرق وتحقيق تغييرات ملكية أصول RGB.

نظرًا لأن جميع بيانات المعاملات تحتاج إلى التحقق والترخيص من قبل الأطراف، فإن نموذج الأمان الخاص بها يعتمد على "افتراض الشخص العقلاني" ",طالما أن الأطراف المعنية عقلانية وطالما أن عملة البيتكوين آمنة، فإن ملكية أصول RGB "آمنة بالأساس".

لكن أوجه القصور في بروتوكول RGB واضحة أيضًا (تم ذكر مشكلات جزر البيانات والتخزين المجزأ سابقًا) . أولاً وقبل كل شيء، إذا كنت تريد تحويل أموال إلى شخص آخر، فيجب عليك الحصول على موافقة الطرف الآخر وتأكيده أولاً، ويجب أن يكون كلا الطرفين متصلين بالإنترنت في نفس الوقت؛

ثانيًا، نظرًا لعدم وجودطرق تسجيل البيانات المرئية عالميًا، فإن RGBيتبنى نشر العقود شكلًا غريبًا للغاية. < /strong>يجب على مستخدمي العقد الحصول على المعلومات من ناشر العقد مقدمًا. عند هذه النقطة، يمكنك التعرف على وظائف الواجهة الواردة في العقد. يمكن أن تكون الطريقة المحددة للتعلم من خلال البريد الإلكتروني أو مسح رمز الاستجابة السريعة. (بالنظر إلى الخطاب الرسمي الحالي، من المقدر أنه يمكن نشر رمز العقد على الصفحة الرئيسية للموقع الرسمي أو تثبيته في الجزء العلوي من تويتر)

< img src="https://img.jinse.cn/7180023_image3.png">

دعونا نناقش حالة العقد لبروتوكول RGB. في بروتوكول RGB، يتم تعيين الحالة الأولية (التكوين) للعقد من قبل المنشئ عند إنشاء العقد، مثل اسم الرمز المميز والمبلغ الإجمالي وما إلى ذلك في عقد RBG-20. بعد ذلك،تتغير حالة العقد مع التقدم المستمر لمعاملات RGB، ولكن تطور حالة العقد هذا غير خطي، مما يشكل رسمًا بيانيًا حلقيًا موجهًا DAG.

(في الصورة، مجال رؤية المالك 1 هو الأجزاء الزرقاء والخضراء، ومجال رؤية المالك 2 هو الأجزاء الزرقاء والصفراء)

على سبيل المثال، عندما يقوم Bob بتحويل الأموال إلى Alice، يتم عرض جزء فقط من سجل التحويل من تهيئة العقد إلى حصول Bob على الرمز المميز، ويكون مسار البيانات المضمن ضيقًا نسبيًا. لا تستطيع أليس سوى معرفة معلومات المعاملة الموجودة في فرع المسار هذا، ومن الصعب معرفة معلومات نقل الأشخاص الآخرين. على الرغم من أن هذا يحمي خصوصية مستخدمي RGB، إلا أنه يؤدي أيضًا إلىعواقب غير مرغوب فيها: فمن الصعب على المستخدمين معرفة الحالة العامة لعقد RGB، مثل عدد أصول RGB التي يمتلكها كل شخص. هذا يمكن أن يسبب الكثير من المتاعب.

على سبيل المثال، عندما يصل تحويل Bob —> Alice إلى الخطوة النهائية، تتم كتابة قيمة التزامه في سلسلة BTC وبعد أن يصبح الأمر لا رجعة فيه، يمكن لـ Bob حذف بعض البيانات محليًا - إذا أعطى Bob جميع رموز TEST المميزة الخاصة به للآخرين، فيمكنه حذف البيانات المتعلقة برموز TEST المميزة المخزنة محليًا مباشرةً لتقليل ضغط التخزين.

باعتبارها متلقية الرمز المميز، تحتاج أليس إلى تسجيل جميع البيانات المتضمنة في هذه المعاملة محليًا. (إذا قام بوب بحذف بيانات رمز TEST المحلي وتضررت عقدة عميل Alice بالكامل نتيجة لحادث، فهل سيتم تجميد أصول Alice بشكل دائم في هذا الوقت؟ لأنه لا يوجد مكان آخر لتخزين بيانات أصول TEST الخاصة بـ Alice، ما لم يتم نسخها احتياطيًا مسبقًا.)

يمكن أن يُعزى هذا بشكل أساسي إلى DA ومشكلات تخزين البيانات، أي أن البيانات الجديدة لبروتوكول RGB لا يمكن نشرها بطريقة موثوقة ومرئية عالميًا، الأمر الذي سيؤدي في النهاية إلى تحول العملاء المختلفين إلى "جزر بيانات". إن حل البلازما، الذي ازدهر سابقًا في النظام البيئي للإيثريوم ولكن تم التخلي عنه لاحقًا، وُلد ميتًا لأنه لم يتمكن من حل مشكلة DA.

بالإضافة إلى ذلك،يتطلب بروتوكول RGB أيضًا الكثير من التواصل بين طرفي المعاملة،كثيرًا وتعتمد خطوات الاتصال على مرافق مركزية، والوصف التفصيلي في هذا المجال لم ينضج بعد، حتى أن المسؤول قال إنه يمكن إجراء الاتصال عبر البريد الإلكتروني.

من الواضح أن تصميم بروتوكول RGB ليس مناسبًا جدًا للمستخدمين طويلي الأمد الذين يسعون إلى سهولة الاستخدام.

وبناءً على هذا السبب، اقترحت Nervos Lianchuang Cipher خطة تسمى RGB++، تحاول تحرير حالة أصول RGB وعقودها، ويُعهد بالتحقق من المعاملات إلى سلسلة CKB العامة. يعمل CKB كمنصة لاستضافة البيانات والحوسبة تابعة لجهة خارجية، ولم يعد يطلب من المستخدمين تشغيل عميل RGB بأنفسهم.

نظرًا لأن CKB نفسه عبارة عن نموذج UTXO ممتد (خلية)، يمكن كتابة المعلومات خارج السلسلة الخاصة بأصول RGB في الخلية وA تم إنشاء علاقة رسم خرائط فردية بين Cell وBitcoin UTXO لتنفيذ حل حفظ بيانات أصول RGB والتحقق منها القائم على CKB لحل مشكلة سهولة الاستخدام والعمل كمكمل محسن لحل RGB الأصلي.

قد يكون هذا المقطع مربكًا بعض الشيء عند قراءته، لذا دعنا نوضحه أكثر:

كما ذكرنا سابقًا في المقالة، فإن جوهر بروتوكول RGB هو ربط ملكية أصول Bitcoin UTXO وRGB من خلال إصدار التزامات على السلسلة وبيانات خارج السلسلة. ومع ذلك، يتم تجزئة بيانات عقد أصول RGB وتخزينها محليًا على عملاء مختلفين، دون عرض مرئي عالميًا.

يستخدم RGB++ نسخة CKB الموسعة من UTXO - Cell لتعيين العلاقة بين Bitcoin UTXO وأصول RGB المقابلة. ، يتم عرضها مباشرة على سلسلة CKB، وتستبدل سلسلة CKB العامة عميل P2P الخاص بالمستخدم للتحقق من صحة كل عملية نقل RGB.

باستخدام سجل بيانات RGB المرئي عالميًا، سيكون من الأسهل الهبوط على العديد من السيناريوهات التي يصعب تنفيذها في بروتوكول RGB .

(تتمثل عملية معاملة RGB++ في كتابة معلومات أصول RGB في الخلية، ثم ربط الخلية بـ Bitcoin UTXO، وأخيرًا دمج معاملات RGB++ التي حدثت على CKB وRGB++ الأصول المرتبطة بها.Bitcoin UTXO، متضمن في الالتزام، ثم اكتب قيمة الالتزام إلى سلسلة Bitcoin)

ربما كان شخص ما أول ما يتبادر إلى ذهني هو EVM. هل يمكننا استخدام EVM لحمل حالة RGB والتحقق من صحتها؟ الجواب هو: إنه أمر مزعج للغاية، لأن أصول RGB هي في الأساس طفيلية على Bitcoin UTXO ولها علاقة رسم 1 إلى 1 مع Bitcoin UTXO. إذا كنت ترغب في إنشاء علاقة تعيين بين بيانات عقد Bitcoin UTXO وEVM، فإن التنفيذ الفني ليس سلسًا، فمن الأفضل اختيار سلسلة UTXO العامة مباشرةً.

علاوة على ذلك، غالبًا ما تكون "الأصول" الموجودة على Ethereum سلعًا عامة في مجموعات نظير إلى نظير، وعدد لا يحصى من الأشخاص المسجلة في عقد واحد. يتمتع مراقب العقد بالسلطة المطلقة على بيانات الأصول. تتعارض طريقة معالجة الأصول هذه بشكل خطير مع بروتوكولات Bitcoin UTXO وRGB. تتمثل فكرة التصميم للأخيرين في التنفيذ الكامل خصخصة الأصول. الجميع السيطرة الكاملة على الأصول الخاصة بك (فكر في الفرق بين الأوراق النقدية ودفع WeChat)، دون الحاجة إلى النظر في المشاكل التي كانت موجودة دائمًا في سلاسل Ethereum وEVM: أصحاب عقود الأصول يسيئون استخدام سلطتهم، وأخطاء العقد تؤدي إلى أضرار رأس المال، ومن المزعج ترحيل بيانات عقود الأصول وغيرها من القضايا.

(من مقالة Geek Web3 السابقة: "لص المشاهير في دائرة التكنولوجيا: من الصعب إنشاء أشياء جديدة في سلاسل عامة عالية الأداء، والعقود الذكية تتضمن توزيع الطاقة") strong>

لذلك، إذا كنت تريد التعبير عن علاقة التعيين بين Bitcoin UTXO وoff- أصول سلسلة RGB أكثر سلاسة، الخيار الأفضل هو من خلال سلسلة UTXO. يدعم CKB خلية UTXO-Cell الموسعة، وتعتمد مجموعة تعليمات CKB VM على RISC-V، وهو أكثر توافقًا مع خوارزميات التشفير المختلفة من EVM، بما في ذلك خوارزمية التحقق من المفتاح العام والخاص لبيتكوين، لذلك فهو أكثر إنه يساعد على تحقيق الحل التقني الذي يقترحه RGB++.

التنفيذ الفني لـ RGB++

يستخدم RGB++ خلية UTXO الموسعة الخاصة بـ CKB. تحتوي الخلية على الحقول التالية:

تمثل السعة المساحة الموجودة على السلسلة التي تمتلكها هذه الخلية، وتشير البيانات إلى مجموعة البيانات الموجودة في الخلية، والتي يمكن قراءتها أو تعديلها.

النوع هو رمز البرنامج المرتبط بهذه الخلية، والذي يحد من شروط تعديل بيانات البيانات. على سبيل المثال، إذا كانت الخلية الخاصة بك تحتوي على بيانات 100 رمز TEST، ولكنك تعلن عن نقل 110 رمز TEST إلى الآخرين، فإن هذا لا يفي بالقيود المحددة في النوع وسيتم رفضه.

يمثل القفل منطق التحقق من ملكية الخلية، على غرار البرنامج النصي لإلغاء القفل الخاص بـ Bitcoin UTXO.

يمكننا فهم الخلية كنسخة مطورة من UTXO، مع حقلين إضافيين: النوع والسعة، ويمكن تخصيص البيانات. أما بالنسبة لطريقة تغيير ملكية الخلية، فهي مشابهة لطريقة Bitcoin UTXO، وكلاهما يتم من خلال فتح البرامج النصية.

فكرة RGB++ هي استخدام الخلايا الموجودة في سلسلة CKB للتعبير عن علاقة ملكية أصول RGB. فهو ينقل بيانات الأصول المخزنة محليًا في الأصل على عميل RGB إلى سلسلة CKB ويعبر عنها في شكل خلية، مما يسمح لـ CKB بالعمل كقاعدة بيانات عامة لأصول RGB. سيكون للخلية التي تمثل أصول RGB علاقة تعيين 1 إلى 1 مع UTXO على سلسلة Bitcoin. سيتم عرض علاقة التعيين هذه مباشرة في حقل القفل بالخلية.

على سبيل المثال، بافتراض أن أصل RGB معينًا مرتبط بـ Bitcoin UTXO A، يمكن أن يكون الإصدار المعين المقابل من الخلية هو تم ضبط شروط التحقق من الملكية لتكون متوافقة مع Bitcoin UTXO A (أي أن نص القفل مضبوط على شرط إلغاء القفل الخاص بـ Bitcoin UTXO A). إذا كنت المتحكم في UTXO A، فيمكنك تشغيل خلية التعيين مباشرة على CKB. وبالطبع، سوف يتحقق CKB مما إذا كنت مالك UTXO A.

ستعمل سلسلة CKB على تنفيذ عقد Bitcoin الخفيفة ومزامنة رؤوس كتلة Bitcoin. عندما تعلن عن معاملة RGB وترغب في تشغيل الخلية المقابلة لأصل RGB، يجب عليك أولاً إثبات أنك المتحكم في Bitcoin UTXO A. ينقسم الإثبات إلى خطوتين:

1. أثبت لعقدة Bitcoin الخفيفة المطبقة على سلسلة CKB أن UTXO A موجود في سلسلة Bitcoin ويجب تقديم Merkle Proof؛

2. أظهر التوقيع الرقمي لإثبات أنك مالك UTXO A.

في حل RGB++، بعد أن يعلن المستخدم عن نقل أصول RGB على الواجهة الأمامية، سيتم تشغيل المعاملة على سلسلة CKB، تعيد كتابة الخلية التي تسجل بيانات أصول RGB وتغير ملكيتها. في الأصل، قد يمتلك المتحكم في Bitcoin UTXO 1 هذه الخلية. وبعد تغيير الملكية، أصبح المتحكم في Bitcoin UTXO 2 هو المالك الجديد للخلية. كل هذا مرئي على سلسلة CKB.

ما يجب ملاحظته هنا هو أن سير العمل المتعلق بالالتزام على سلسلة BTC لا يزال يتم تنفيذه على شبكة BTC الرئيسية، مما يعني أن RGB++ لا يزال يتعين عليه إصدار الالتزام على سلسلة Bitcoin ,يرتبط بسجلات معاملات أصول RGB التي حدثت على CKB. لا تختلف هذه الخطوة عن بروتوكولات RGB التقليدية.

لكن الفرق هو أنه في بروتوكول RGB التقليدي، تتم معالجة العمل الذي يكون العميل مسؤولاً عنه خارج السلسلة. بواسطة CKB ، على سبيل المثال، يحتاج الطرف المقابل إلى التحقق من مصدر الأصول، ويحتاج العميل إلى تخزين بيانات مصدر الأصول محليًا، ويجب أن يتم إصدار عقد RGB من خلال قنوات خارجية، وما إلى ذلك. ويمكن حل هذه الأعباء المرهقة بواسطة CKB ولا تتطلب من المستخدمين تشغيلها بأنفسهم.client.

يحل هذا مشكلة جزيرة بيانات عميل RGB ويحل أيضًا العيب المتمثل في عدم إمكانية رؤية حالة العقد عالميًا. وفي الوقت نفسه، يمكن نشر عقد RGB مباشرة على سلسلة CKB ويكون مرئيًا عالميًا للرجوع إليه بواسطة خلية RGB، وهذا يتجنب سلسلة من العمليات الغريبة عند إصدار عقد بروتوكول RGB.

باختصار، يستخدم CKB قابلية برمجة البرنامج النصي للخلية للتأكد أولاً من أن بادئ نقل RGB يمتلك بالفعل Bitcoin UTXO المرتبط بأصل RGB. إذا تم اجتياز التحقق، فسيقوم المستخدم يُسمح بالنقل. انقل بيانات أصول RGB الخاصة بالتسجيل الخلوي إلى الآخرين.

باختصار، يعمل CKB كمنصة عامة لاستضافة البيانات لأصول RGB، مما يوفر تخزين البيانات وإصدار العقود المرئية عالميًا. وظيفة، ويوفر أيضا التحقق من الملكية ووظائف الحساب. وبعبارة أكثر إيجازًا، يستبدل CKB العميل في RGB ويحل المشكلات الأخرى بالمصادفة.

بالطبع، نظرًا لأن RGB++ يحقق إصدار بيانات مرئية عالميًا، فلا بد أن تكون الخصوصية أقل من تلك الخاصة ببروتوكول RGB، ولكن الميزة هي أنه من السهل أن يتم تحسين سهولة الاستخدام بشكل كبير.

لذلكيستبدل RGB++ الخصوصية بشكل أساسي لسهولة الاستخدام، وفي الوقت نفسه يمكن أن يؤدي إلى سيناريوهات لا يمكن تحقيقها بواسطة بروتوكول RGB. إذا كان المستخدمون يقدرون البساطة وسهولة الاستخدام والوظائف الكاملة للمنتج، فسوف يفضلون RGB++. وإذا كانوا يسعون إلى الخصوصية والأمان في التحقق بنفسك، فسوف يفضلون بروتوكول RGB التقليدي. كل شيء يعتمد على اختيار المستخدم الخاص< /strong> (الفكرة مشابهة لما عبر عنه فيتاليك عندما علق على طبقة الإيثريوم 2. إذا كنت تسعى إلى الأمان، فاستخدم Rollup، وإذا كنت تسعى إلى التكلفة المنخفضة، فاستخدم حلولًا غير Rollup مثل Validium والأمثل.) بالطبع، وفقًا للورقة البيضاء RGB++، يمكن أيضًا تنفيذ حلول المعاملات الخاصة على سلسلة CKB في المستقبل لإخفاء هوية المستخدم ومبلغ التحويل.

ميزات إضافية لـ RGB++

الطبيعة غير التفاعلية للمعاملات (مهم جدًا)

RGB الأصلي هناك مشكلة مهمة تتمثل في أنه يجب على المستفيد أولاً إرسال رسالة إلى الدافع (الشيك المذكور أعلاه)، تشير إلى أن أحد UTXOs الخاص به يجب أن يكون مرتبطًا بأصل RGB، بحيث يمكن تنفيذ نقل RGB بسلاسة. يتطلب هذا اتصالات تفاعلية متعددة بين المستفيد والدافع لإكمال معاملة عادية، مما يزيد بوضوح من صعوبة فهم المستخدمين وتعقيد المنتج. يستفيد RGB++ من خصائص CKB كمنصة لاستضافة البيانات والحوسبة، مما يسمح للأطراف المقابلة بإكمال عمليات النقل من خلال طرق غير متزامنة وغير تفاعلية.

عندما يقوم "أ" بتحويل أموال إلى "ب"، فإنه يحتاج فقط إلى معرفة عنوان "ب" مسبقًا والإعلان عن التحويل إلى هذا العنوان. مطلوب المستفيد للتواصل أو تقديم البيانات عبر الإنترنت. بعد ذلك، يمكن للمدفوع لأمره جمع الأصول بنفسه، وسيتحقق رمز البرنامج النصي الموجود في سلسلة CKB مما إذا كان المدفوع لأمره هو الشخص الذي عينه الدافع. من الواضح أن هذا النموذج أقرب إلى عادات معظم الناس، ويمكن أيضًا أن تعمل النماذج غير المدعومة في الأصل في بروتوكول RGB، مثل الإنزال الجوي وتوزيع المكافآت، وهو ما يفضي أيضًا إلى إصدار أصول RGB.

بالإضافة إلى ذلك، فإن وضع العمل لبروتوكول RGB لا يساعد بشكل طبيعي على تطوير سيناريوهات Defi. على سبيل المثال، Uniswap، وهي معاملة نموذجية من متعدد إلى متعدد وغير تفاعلية التجمع، ليس له أي استخدام تقريبًا في بروتوكول RGB الأصلي. لا يمكن توسيعه، وينفذ RGB++ معاملات غير تفاعلية، وتكون الحالة مرئية عالميًا وقابلة للتحقق. طالما يتم استخدام الخلية لتنفيذ "عقد بدون مالك" حيث " كل من يستوفي الشروط يمكنه تعديل حالته،" يمكن تنفيذ العديد من سيناريوهات Defi.

وبطبيعة الحال، عقد لا مالك فيه الجميع يمكن أن يؤدي تعديل حالته إلى حدوث تنافس على الحالة/تعارض القراءة والكتابة، حتى لو كان هناك عدة أشخاص إذا كنت ترغب في تعديل حالة العقد في نفس الوقت، فسيؤدي ذلك إلى حدوث فوضى، ومن أجل حل هذه المشكلة، يخطط RGB++ لاستخدام يتم تطبيق Intent Cell على السلسلة باعتبارها "جهاز تسلسل" لفرز الطلبات المختلفة.

طي المعاملات (إصدار الالتزام الذي يجمع معاملات متعددة )

من السهل فهم طي المعاملات، أي أنه يتم استخدام CKB كـ "مسبق خارج السلسلة" -طبقة التسوية". بعد حدوث عمليات نقل RGB متعددة، يتم تجميع مجموعة من المعاملات لإنشاء التزام يتوافق مع المعاملة المجمعة. ويتم نشرها على سلسلة Bitcoin في وقت واحد.

الأداء المحدد هو المخطط الانسيابي التالي:

لا تحتاج أصول BTC إلى سلسلة متقاطعة للتفاعل مباشرة مع الأصول الموجودة في سلسلة CKB

يدرك RGB++ التكامل بين Bitcoin UTXO وCKB Cell بعد تعيين الارتباط بينهما، قابلية التشغيل البيني عبر السلسلة دون الحاجة إلى الأصول يمكن تحقيقها مباشرة.يمكنك نقل Bitcoin UTXO الخاص بك إلى الآخرين من خلال بيان المعاملة RGB++، ويمكن للطرف الآخر نقل ملكية أصول CKB الخاصة به إليك. يتمتع هذا النموذج بمساحة كبيرة للخيال، فبالإضافة إلى طي المعاملات المذكورة سابقًا (المعاملات المجمعة)، يمكنه نظريًا تحقيق قابلية التشغيل البيني للأصول على سلسلة BTC-CKB دون الحاجة إلى أصول BTC عبر السلسلة.

الملخص

يقوم RGB++ بتحويل بيانات الأصول المخزنة محليًا في عملاء RGB مختلفين مباشرةً يتم التعبير عنها باستخدام الخلية الموجودة في سلسلة CKB، ثم ربط الخلية بـ UTXO في سلسلة Bitcoin. يمكن للمستخدمين التفاعل مع أصول RGB++ الخاصة بهم على سلسلة CKB من خلال حسابات/أصول Bitcoin. هذه الطريقة بسيطة نسبيًا وتحل المشكلات في بروتوكول RGB، مثل الحاجة إلى اتصال مسبق بين الطرفين للنقل، وصعوبة دعم الحالات المرئية عالميًا، وتجزئة تخزين البيانات، والعقود الذكية غير الودية وDefi.

يمكن لـ RGB++ تحقيق قابلية التشغيل البيني بين BTC وCKB بدون أصول عبر السلسلة، وتسهيل أصول RGB وDefi مزيج المشاهد يحل بشكل كبير مشكلة سهولة استخدام بروتوكول RGB. ولكن بالنسبة لمشغلات RGB المتخصصة التي تسعى إلى درجة عالية من الخصوصية، فإن جوهر RGB++ هو استبدال الخصوصية بسهولة الاستخدام، وكل شيء يعتمد على اختيار المستخدم. ولكن من الناحية النظرية، يمكن حل مشكلات الخصوصية في سلسلة CKB من خلال تقديم ZK وطرق أخرى.

بشكل عام، يوضح RGB++ إمكانات CKB كطبقة تسوية/طبقة حوسبة ضمن سلسلة Bitcoin، وستكون هذه الفكرة في المستقبل سيتم اعتمادها من قبل المزيد والمزيد من طبقة البيتكوين 2 أو بروتوكولات الأصول، ومن المتوقع أن تبدأ المنافسة بين طبقات تسوية الطرف الثالث ضمن سلسلة البيتكوين قريبًا. قد تتمكن CKB، التي تركز على POW وUTXO ولديها سنوات عديدة من تراكم التكنولوجيا، من إظهار مزاياها التقنية في هذه المنافسة على سلاسل الكتل المعيارية.