بروتوكول RGB: يجب على المستخدمين إجراء التحقق من البيانات بأنفسهم

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

لماذا يجب أن يكون الأمر كذلك؟ والسبب هو أنه من أجل ضمان الخصوصية ، لا يعتمد بروتوكول RGB "بروتوكول الإجماع" في سلاسل الكتل التقليدية مثل Bitcoin و Ethereum. (بمجرد مرور البيانات عبر بروتوكول الإجماع ، ستتم ملاحظتها من قبل جميع العقد تقريبا في الشبكة ، والخصوصية غير مضمونة). كيف يمكن التأكد من أن تغييرات الأصول آمنة دون عملية إجماع تتضمن عددا كبيرا من العقد؟ يتم استخدام الفكرة المسماة "التحقق من العميل" (تحقق بنفسك) هنا. تحتاج إلى تشغيل العميل بنفسك والتحقق شخصيا من تغييرات الأصول المتعلقة بك. لنفترض أن هناك مستخدم RGB يدعى بوب يعرف أليس ، وتريد أليس نقل 100 رمز TEST إلى بوب. بعد أن تنشئ أليس معلومات نقل "أليس إلى بوب" ، يجب عليها أولا إرسال معلومات النقل وبيانات الأصول المعنية إلى بوب ، والسماح له بالتحقق منها شخصيا للتأكد من صحتها قبل الدخول في العملية اللاحقة ، وأخيرا يصبح نقل RGB صالحا. بهذه الطريقة ، يسمح بروتوكول RGB للمستخدمين بالتحقق شخصيا من صحة البيانات ، ليحل محل خوارزمية الإجماع التقليدية. ولكن بدون توافق في الآراء ، تكون البيانات التي يتم تلقيها وتخزينها بواسطة عملاء RGB مختلفين غير متسقة. يخزن الجميع بيانات مواد العرض الخاصة بهم محليا فقط ولا يعرفون حالة مواد العرض للآخرين. مع حماية الخصوصية ، يشكل هذا أيضا "جزيرة بيانات". إذا ادعى شخص ما أن لديه مليون رمز اختبار ويريد تحويل 100000 إليك ، فكيف تصدق ذلك؟ في شبكة RGB ، إذا أراد شخص ما تحويل الأموال إليك ، فيجب عليه أولا إظهار دليل على الأصول ، وتتبع المصدر التاريخي للأصول من الإصدار الأولي إلى التغييرات المتعددة في الأيدي ، والتأكد من أن الرمز المميز المراد نقله إليك نظيف. هذا يشبه عندما تتلقى أوراقا نقدية مجهولة المصدر وتطلب من الطرف الآخر شرح المصدر التاريخي لهذه الأوراق النقدية وما إذا كانت قد صنعت من قبل المصدر المعين ، وذلك لتجنب العملة المزيفة.

(مصدر الصورة: كوينكس)

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

هنا ملخص لسير العمل لبروتوكول RGB:

1. ترتبط أصول RGB بـ Bitcoin UTXO، وبوب يمتلك بعض Bitcoin UTXOs معينة. تريد آليس نقل 100 رمز إلى بوب. قبل استلام الأصول، يخبر بوب آليس مسبقًا أي Bitcoin UTXO يجب استخدامه لربط هذه الأصول RGB.

(مصدر الصورة: Geekweb3/GeekWeb3)

1. أليس تُنشئ بيانات نقل الأصول RGB "من أليس إلى بوب"، إلى جانب المصادر التاريخية لهذه الأصول، وتقدمها إلى بوب للتحقق.
2. بعد أن يؤكد بوب محليًا أن البيانات على ما يرام، يرسل إيصالًا إلى أليس، يخبرها بأن الصفقة يمكن أن تتم.
3. تقوم أليس ببناء بيانات نقل RGB الخاصة بـ "أليس إلى بوب" في شجرة Merkle، وتنشر Merkle Root على سلسلة البتكوين كالتزام. يمكننا ببساطة فهم التزام الهاش لبيانات النقل.
4. إذا أراد شخص ما تأكيدًا في المستقبل أن عملية التحويل المذكورة أعلاه من "أليس إلى بوب" حدثت فعلا، فإنه يحتاج إلى القيام بشيئين: الحصول على معلومات التحويل الكاملة من "أليس إلى بوب" تحت سلسلة البيتكوين، ثم التحقق مما إذا كان هناك عملية تحويل مقابلة على سلسلة البيتكوين (تزامن البيانات المحولة)، هذا كل شيء.

يعمل بيتكوين هنا كسجل تاريخي لشبكة RGB، ولكن يتم تسجيل فقط الهاش/جذر ميركل لبيانات المعاملات في السجل بدلاً من بيانات المعاملات نفسها. بفضل التحقق من الجانب العميل والختم لمرة واحدة، يتمتع بروتوكول RGB بأمان عالٍ للغاية؛ نظرًا لأن شبكة RGB تتكون من عملاء مستخدمين ديناميكيين في شكل ند لند دون توافق، يمكنك تغيير الطرف الثاني في أي وقت دون إرسال طلبات معاملات إلى عدد محدود من العقد، لذلك تتمتع الشبكات RGB بمقاومة للرقابة بشكل كبير، هذه الشكل الإداري أكثر مقاومة للرقابة من السلاسل العامة الكبيرة مثل إيثيريوم.

(مصدر الصورة: BTCEden.org)

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

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

هل يمكنك تخيل شخص ما يرغب في تحويل الأموال إليك، ولكن عليهم أن يرسلوا لك بيانات العملية للتحقق، وفقط بعد استلام رسالة الإيصال الخاصة بك يمكن إكمال عملية التحويل؟

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

RGB++: التحقق من الجانب العميل يصبح حضانة متفائلة

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

RGB++ والبروتوكول الأصلي RGB نظريا متوافقان مع بعضهما البعض.

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

(مصدر الصورة: RGB++ LightPaper)

على سبيل المثال، إذا كانت لدى أليس 100 رمز RGB و UTXO A على سلسلة بيتكوين، وكذلك لديها UTXO على سلسلة CKB، يتم وضع علامة على هذا UTXO بـ "رصيد رمز RGB: 100"، وتكون شروط الإلغاء مرتبطة بـ UTXO A.

إذا كانت أليس ترغب في إرسال 30 رمزًا إلى بوب، يمكنها أولاً إنشاء التزامًا. البيان المقابل هو: نقل 30 من رموز RGB المرتبطة بـ UTXO A إلى بوب، ونقل 70 إلى UTXOs أخرى تحكم فيها.

بعد ذلك، تنفق أليس UTXO A على سلسلة البيتكوين، وتنشر البيان أعلاه، ثم تبدأ في عملية تحويل على سلسلة CKB لاستهلاك حاوية UTXO التي تحمل 100 رمز RGB وتوليد حاويتين جديدتين، تحمل الأولى 30 رمزًا (لصالح بوب)، وتحمل الثانية 70 رمزًا (تحت سيطرة أليس). في هذه العملية، يتم إكمال مهمة التحقق من صحة أصول أليس وصحة بيان العملية من قبل العقد الشبكية مثل CKB أو Cardano من خلال التوافق، دون تدخل بوب. في هذا الوقت، تعمل CKB وCardano كطبقة التحقق وطبقة DA تحت سلسلة البيتكوين.

(مصدر الصورة: RGB++ LightPaper)

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

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

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

ولكن كن حذرًا، يحتاج "الحاوية" المستخدمة في الربط المتماثل إلى سلسلة عامة تدعم نموذج UTXO، أو بنية تحتية تتمتع بخصائص مماثلة في تخزين الحالة. سلسلة EVM غير مناسبة وستواجه العديد من الكمائن.(يمكن كتابة هذا الموضوع على حدة ويتضمن الكثير من المحتوى. يمكن للقراء المهتمين الرجوع إلى مقالات Geek Web3 السابقة.)"RGB++ and Isomorphic Binding: How CKB, Cardano and Fuel تمكين البيتكوين النظام البيئي"؛

في الختام، يجب أن تتمتع سلسلة عامة / طبقة توسيع الوظائف المناسبة لتحقيق الربط الإنومورفي بالخصائص التالية:

1. استخدام نموذج UTXO أو نظام تخزين الحالة المماثل؛
2. لديه قدرا كبيرا من القابلية للبرمجة UTXO، مما يتيح للمطورين كتابة النصوص الخاصة بالفتح؛
3. هناك مساحة حالة متعلقة بـ UTXO يمكن أن تخزن حالة الأصول؛
4. هناك جسور أو عقد خفيفة متعلقة ببيتكوين؛

إخلاء المسؤولية:

1. تم استنساخ هذه المقالة من [ المتخصص ويب3]، عنوان الأصلي هو “تصميم بروتوكول RGB وRGB++ في دقائق قليلة: تعليمات واضحة”، حقوق النشر تنتمي إلى الكاتب الأصلي [Faust]، إذا كان لديك أي اعتراض على إعادة النشر، يرجى التواصل فريق تعلم Gate, سيقوم الفريق بالتعامل مع ذلك في أقرب وقت ممكن وفقا للإجراءات ذات الصلة.

2. تعبر الآراء والافكار المعبر عنها في هذا المقال عن آراء الكاتب فقط ولا تشكل أي نصيحة استثمارية.

3. تتم ترجمة النسخ الأخرى من المقال بواسطة فريق Gate Learn. دون الرجوع إلىبوابة.ايو، نسخ أو توزيع أو سرقة المقالات المترجمة ممنوعة.