بقلم فيديريكو تينجا ، عضو فريق Bitfinex RGB ، مطور محفظة Iris ؛ ترجمة: جولدن فاينانس شياوزو
في الآونة الأخيرة ، كان هناك اهتمام متزايد بمقارنة الرموز المستندة إلى Bitcoin و Lightning Network. فكرة إنشاء الرموز المميزة لتمثيل الأصول التي يمكن نقلها وتخزينها بأمان وسهولة ، تماما مثل Bitcoin ، ليست جديدة. في الواقع ، في عام 2013 ، كانت بروتوكولات مثل Counterparty و OmniLayer (Mastercoin سابقا) رائدة في الفكرة ، والتي تم تبنيها لاحقا بواسطة Ethereum وغيرها من العملات البديلة. ومع ذلك ، فإن استخدام العملات البديلة لتأمين الأصول المالية ليس مثاليا ، لأنها لا تقدم نفس مستوى الأمان واللامركزية مثل Bitcoin. لهذا السبب ، كانت هناك أيضا مشاريع على مر السنين ظهرت في محاولة لتحديث بروتوكول الرمز المميز على شبكة Bitcoin وجعله متوافقا مع شبكة Lightning ، وتحديدا RGB و OmniBolt ومؤخرا Taro. ستركز هذه المقالة على RGB ، وتقدم نظرة عامة شاملة على كيفية عملها وعرض قيمتها.
بروتوكولات الرمز المميز القديمة المستندة إلى Bitcoin ، مثل Counterparty و OmniLayer ، “تلوينها” عن طريق وضع البيانات الوصفية في معاملات Bitcoin والإشارة إلى أنه يجب اعتبارها نقلا رمزيا. تحدث هذه الإشارة عادة في إخراج OP \ _RETURN ، والذي يتم تجاهله بواسطة عقدة Bitcoin عادية ، ولكن يمكن تفسيره بواسطة عقدة مدركة لبروتوكول الرمز المميز ، والتي تفرض بعد ذلك قواعد التحقق من صحة بروتوكول الرمز المميز.
! [mWMQA4cCFyxXoXu0rU5vn5oBWdvOm88zGE9uQMCV.png] (https://img.jinse.cn/7133079_watermarknone.png “7133079”)
في حين أن هذا التصميم فعال ، إلا أن هناك بعض العيوب:
· كمية المعلومات المتعلقة بنقل الرمز المميز محدودة بوحدات بايت إخراج OP \ _RETURN ، وهي 80 بايت وفقا للقواعد القياسية ، وهو ما يكفي لترميز بيانات المعاملات الأساسية ، ولكنه ليس كافيا لدعم حالات الاستخدام الأكثر تعقيدا.
· تحتاج عقد بروتوكول الرمز المميز إلى فحص blockchain بالكامل بحثا عن عمليات نقل الرمز المميز التي قد تكون ذات صلة بالمستخدمين في إخراج OP \ _RETURN ، وهي عملية تصبح أكثر كثافة في استخدام الموارد مع نمو حجم blockchain.
· حماية الخصوصية للمستخدمين أمر فظيع لأن جميع بيانات المعاملات مرئية لأي شخص على السلسلة ، وقد يكون إخفاء هوية الرمز المميز الذي تستخدمه أضعف من حجم Bitcoin الذي تستخدمه عادة.
لتحسين هذا التصميم ، اقترح مشروع RGB حلا أكثر قابلية للتطوير ووعيا بالخصوصية ومقاوما للمستقبل يعتمد على مفهوم التحقق من جانب العميل والأختام ذات الاستخدام الواحد ، والذي اقترحه في الأصل بيتر تود في عام 2017.
في قلب الفكرة هي فكرة استخدام Bitcoin blockchain فقط عندما تضطر إلى ذلك ، أي استخدام إثبات العمل والطبيعة اللامركزية للشبكة لحماية الإنفاق المزدوج ومقاومة الرقابة. يمكن نقل جميع أعمال التحقق من نقل الرمز المميز من طبقة الإجماع العالمية والحفاظ عليها خارج السلسلة ، وتفويضها فقط للعملاء الذين يتلقون المدفوعات.
كيف يعمل كل هذا؟ في RGB ، يجب دائما تخصيص الرموز المميزة بشكل أساسي ل Bitcoin UTXOs (موجودة بالفعل أو تم إنشاؤها خصيصا) ، ومن أجل نقل الرموز المميزة ، تحتاج إلى إنفاق مثل هذه UTXOs. عند إنفاق UTXOs ، يجب أن تتضمن معاملات Bitcoin رسالة تعد بأن الرسالة تحتوي على معلومات دفع RGB ، ومدخلات التعريف ، و Bitcoin UTXO الذي سيتم إرسال الرمز المميز إليه ، ومعرف الأصل ، والمبلغ ، وشروط الإنفاق ، وأي بيانات إضافية أخرى قد ترغب في إرفاقها.
! [LnBQoqrWgI47Ivmp7lSrEoRoyGV4VefYNgqG3gR6.png] (https://img.jinse.cn/7133083_watermarknone.png “7133083”)
لذلك ، لنقل رموز RGB المخصصة ل Bitcoin UTXOs ، يجب أن تكون معاملات Bitcoin مطلوبة. ومع ذلك ، لا يلزم أن يكون إخراج نقل RGB هو نفسه ناتج معاملة Bitcoin! كما رأينا في المثال أعلاه ، يمكن لمعاملة RGB إخراج UTXO لا علاقة له تماما بمعاملة Bitcoin المقدمة إليها. هذا يعني أنه يمكن “نقل” رموز RGB المميزة من UTXO إلى آخر دون ترك أي أثر في الرسم البياني لمعاملات Bitcoin. إنه جيد للخصوصية!
في هذا التصميم ، يتم استخدام Bitcoin UTXO كختم لمرة واحدة يحتوي على أصول RGB ، ولنقل الأصول ، تحتاج بشكل أساسي إلى فتح الختم القديم ووضع الختم الجديد.
يتم نقل بيانات الدفع الخاصة ب RGB من عميل الدافع إلى عميل المستلم عبر قناة اتصال مخصصة تتحقق من اتباع قواعد بروتوكول RGB. بهذه الطريقة ، لن يتمكن مراقبو blockchain من استخراج أي معلومات حول نشاط مستخدم RGB.
لسوء الحظ ، لا يكفي التحقق من الدفعة المستلمة للتأكد من أن المرسل هو المالك الحقيقي للأصل الذي تم إرساله إليك للتو ، لذلك لكي تعتبر الدفعة المستلمة نهائية ، يجب أن تتلقى كل سجل المعاملات المتعلق بالرمز المميز الذي أرسلته للتو من الدافع ، وصولا إلى الإصدار الأولي. من خلال التحقق من سجل المعاملات بالكامل ، يمكنك التأكد من أن الأصل خال من التضخم وأنه يتم الالتزام بجميع شروط الإنفاق المتعلقة بالأصل.
! [zZVf5MlHozml9TA3HMdyWavHbBD9OISh9cWrjsEz.png] (https://img.jinse.cn/7133084_watermarknone.png “7133084”)
يساعد هذا التصميم في قابلية التوسع لأنك لست مضطرا للتحقق من السجل الكامل للأصل ، فقط تلك المعاملات ذات الصلة بك. بالإضافة إلى ذلك ، لا يتم بث المعاملات إلى دفتر الأستاذ العالمي ، مما يؤدي إلى تحسين الخصوصية لأن عددا أقل من الأشخاص يعرفون أن معاملاتك موجودة.
لزيادة تحسين الخصوصية ، يدعم RGB تعمية الإخراج ، مما يعني أنه في طلب الدفع الذي ترسله إلى الشخص الذي يحتاج إلى الدفع لك ، لا تكشف عن UTXO الذي تريد استلام الرمز المميز ، ما عليك سوى أن تطلب من الدافع إرسال الرمز المميز إلى تجزئة تقوم بإنشائها عن طريق ربط UTXO بمفتاح تعمية عشوائي. بهذه الطريقة ، لن يعرف الدافع أن UTXO تتلقى الرموز المميزة ، لذلك من المستحيل على البورصة أو مزود الخدمة الآخر معرفة ما إذا كانوا يساعدون في سحب UTXO “المدرج في القائمة السوداء” من قبل المنظم ، أو مراقبة متى سيتم إنفاق الرموز المميزة في المستقبل.
لاحظ أنه عند دفع الرموز المميزة ، يجب الكشف عن المفتاح المعمى للمستلم حتى يتمكن المستلم من التحقق من جميع معاملات Bitcoin في سجل المعاملات. هذا يعني أنه مع RGB ، لديك حاليا خصوصية كاملة ، ولكن سيتمكن حاملو الرمز المميز في المستقبل من رؤية UTXO الكامل المتضمن في النقل. لذلك ، بينما يتمتع المستخدمون بخصوصية تامة عند تلقي الرموز المميزة والاحتفاظ بها ، فإن سرية الأنشطة المالية السابقة للمستخدمين تتناقص بمرور الوقت حيث يتم نقل الرموز المميزة باستمرار بين الأشخاص ، مما يقترب من مستوى الخصوصية في سجل معاملات Bitcoin السابق.
نظرا لأن RGB مبني على Bitcoin ، فمن الممكن أيضا نقل رموز RGB المميزة إلى شبكة Lightning ، وهذا قيد الدراسة بالفعل. شبكة Lightning هي حل قابلية التوسع القائم على قناة الدفع والذي يتطلب في الواقع بعض العمل لتمهيد سيولة قناة جيدة عبر الأصول ، إما من خلال اعتماد الأصول على نطاق واسع ، أو من خلال برنامج إدارة القناة الذي يتصل مباشرة بالعقد التي تدعم الأصول التي يهتم بها المستخدم ، مما يخلق نوعا من الشبكة الفرعية الخاصة بالأصول.
حل آخر لجعل الأصول الأقل شعبية قابلة للتطبيق على شبكة Lightning Network هو تقديم العقد التي توفر خدمة تبادل بين أصل معين و Bitcoin. بهذه الطريقة ، بمجرد تبادلها مع Bitcoin ، يمكن نقل القيمة عبر الشبكة من خلال سيولة Bitcoin ، وعندما تصل إلى الطرف الآخر من المسار ، تقوم عقدة تبادل أخرى بتحويل Bitcoin مرة أخرى إلى الأصل الأصلي. هذا سوف يلغي الحاجة إلى شبكة محددة من الأصول السائلة. ومع ذلك ، من أجل جعل هذا حقيقة واقعة ، يجب أن يكون حجم تداول كل أصل مع Bitcoin كبيرا بما يكفي لتحفيز صناع السوق على تشغيل عقد التداول في مواقع متعددة على الشبكة ، وتقديم فروق أسعار العرض والطلب منخفضة بما يكفي لتجنب فقدان الكثير من القيمة من المدفوعات بين الصفقتين.
! [fhtSwIHlaPktkY8QF0YxwdPwpVowif3GioSbk6ev.png] (https://img.jinse.cn/7133085_watermarknone.png “7133085”)
باستخدام معاملات Bitcoin ، يرث RGB تلقائيا جميع وظائف العقد الذكي للبيتكوين ، ولكن الأمر لا يقتصر على ذلك! عندما تقوم بتحويل الرموز المميزة إلى طرف مقابل ، يمكنك تحديد شروط الإنفاق الإضافية التي يجب أن يفي بها هذا الطرف المقابل في المستقبل في الدفع. لا يتم فرض شرط الإنفاق الإضافي هذا من خلال الإجماع على مستوى blockchain ، ولكن من خلال عملية التحقق من عقدة RGB. هذا يعني أنه إذا حاول شخص ما إنفاق الرموز المميزة دون الالتزام بقواعد شرط الإنفاق المحددة ل RGB ، فلن تتمكن عقدة المستلم من التحقق من صحتها بنجاح وستعتبر الدفعة غير نهائية ، وهو أمر سيء بشكل خاص للمرسل. في الواقع ، بينما تفشل مدفوعات RGB ، قد تكون معاملات Bitcoin التي تكلف UTXOs (يتم تخصيص الرموز المميزة ل UTXOs) قد تم تأكيدها بالفعل على blockchain ، مما يعني أن هذه الرموز لن يتم تخصيصها لأي UTXOs ويمكن أيضا اعتبارها محترقة (محترقة) ، وهو عامل ديناميكي يجب مراعاته عند كتابة عقود RGB الذكية.
هناك مقايضة أخرى يجب أن تكون على دراية بها وهي أنه في حين أن عقود RGB يمكن أن توفر المزيد من الخصوصية وقابلية التوسع أكثر من أي بديل ، إلا أن حالتها لا يمكن الوصول إليها عالميا ، ولا يمكن أن تكون بلا مالك (كما يحدث في سلاسل الكتل الأخرى) ، والتي تمثل أيضا درجة من القيود لبعض حالات الاستخدام.
نظرا لطبيعة RGB من جانب العميل ، يمكن اقتراح العديد من أطر العقود الذكية وتنفيذها بطريقة غير مصرح بها. في وقت كتابة هذا التقرير ، كان هناك مشروع يسمى AluVM يعمل في هذا الاتجاه.
سيجد أي شخص مهتم باعتماد RGB نفسه يتساءل كيف يقارن ببروتوكولات الرمز المميز الأخرى. دعنا نحلل بعض الأمثلة:
** الرموز القائمة على Altcoin **
تقدم معظم بروتوكولات الرموز المميزة القائمة على altcoins (على سبيل المثال ، ERC-20) عقودا ذكية مع دولة عالمية بلا مالك ، مما يجعل من السهل إلى حد ما نشر DEXs والتطبيقات المالية الأخرى ، ولكن من الصعب توسيع نطاقها ، وليس لها خصوصية ، وترث جميع عيوب هذه العملات البديلة ، مثل ارتفاع تكاليف تشغيل العقدة ، وانخفاض اللامركزية ، وضعف مقاومة الرقابة.
الأصول السائلة
Liquid عبارة عن سلسلة جانبية موحدة من Bitcoin تقدم بعض الميزات المثيرة للاهتمام ، مثل دعم الأصول الأصلية والمعاملات السرية ، والتي يمكن أن تخفي مبلغ الدفع ومعرف الأصل المنقول من مراقبي blockchain. ولكن مرة أخرى، يثير النموذج الفيدرالي نفس المشكلة: اللامركزية المنخفضة ومقاومة الرقابة الضعيفة.
OmniBolt هو إصدار متوافق مع Lightning من OmniLayer ، والذي تمت تغطيته لفترة وجيزة في بداية هذه المقالة. لديها مقايضات مشابهة جدا ل RGB ، لكنها توفر حماية أقل للخصوصية وقابلية التوسع لأن جميع البيانات المتعلقة بالرمز المميز يتم الاحتفاظ بها على السلسلة.
*قلقاس
أعلنت Bitcoin 2022 Miami أن Taro ، وهو مشروع مدعوم من Lightning Labs ، يهدف إلى وضع الأصول على رأس شبكة Lightning. وفقا لملاحظات المواصفات المنشورة ، فإن التصميم مشابه جدا ل RGB ، مع نفس الميزات والمقايضات بشكل أساسي. في وقت كتابة هذا التقرير ، يبدو أن الاختلاف الرئيسي بين RGB و Taro هو أن RGB قد أصدرت بعض التعليمات البرمجية القابلة للمراجعة ، بينما أصدرت Taro المواصفات فقط ، ولكن من ناحية أخرى ، يمكنك القول أن Taro مدعوم من قبل أحد أفضل الفرق في النظام البيئي للبرق ، مما يجعل التطبيقات المستقبلية واعدة. بالنظر إلى أوجه التشابه بين التصميمين ، سيكون من الرائع أن يتمكن Taro و RGB أخيرا من التشغيل البيني ، ولكن الوقت فقط هو الذي سيحدد ما إذا كان ذلك سيحدث.