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

بروتوكول RGB: يحتاج المستخدمون إلى التحقق شخصيًا من البيانات

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

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

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

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

دعونا نوضح سير عمل بروتوكول RGB:

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

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

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

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

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

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

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

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

تقدم RGB++ نهج الوصاية المتفائل، محل الحيازة على جانب العميل.

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

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

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

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

على سبيل المثال، إذا كانت لدى أليس 100 رمز RGB و UTXO (لنسميه UTXO A) على سلسلة البتكوين، بالإضافة إلى UTXO على سلسلة CKB معلمة بـ "رصيد رمز RGB: 100" وظروف فتح مرتبطة بـ UTXO A:

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

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

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

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

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

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

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

في الختام، يجب أن تحتوي السلاسل العامة أو طبقات تمديد الوظائف المناسبة لتنفيذ الروابط التشابهية على السمات التالية:

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

تنصل:

1. تم نقل هذه المقالة من [极客 Web3]، كل حقوق النشر تنتمي إلى الكاتب الأصلي [فاوست]. إذا كانت هناك اعتراضات على هذه الإعادة طبع، يرجى الاتصال بالبوابة تعلمالفريق، وسيتولون بالأمر على الفور.
2. إخلاء المسؤولية عن الضرر: الآراء والآراء الواردة في هذه المقالة هي فقط تلك التي يعبر عنها المؤلف ولا تشكل أي نصيحة استثمارية.
3. يتم إجراء ترجمات المقالة إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، يُحظر نسخ أو توزيع أو ارتكاب الانتحال في المقالات المترجمة.