الخلفية

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

السلاسل الجانبية بما في ذلك Liquid وStacks وRootstock، وما إلى ذلك؛
قنوات الحالة مثل شبكة Lightning التي تعالج بعض المعاملات عالية التكرار خارج السلسلة؛
حلول التوسع غير القابلة للترقية مثل RGB وBitcoin Script التي لا تعدل شفرة البيتكوين؛
حلول التوسع القائمة على الترقية بما في ذلك Drivechain (BIP300/301) التي تتطلب دعمًا قويًا من المعدنين وتحقق قابلية التوسع من خلال التشعبات الصلبة.

من بين النهج المختلفة، تعود بعض حلول التوسع المبكرة لتحظى بالاهتمام. وبشكل ملحوظ، ساهم بروتوكول Nostr، الذي انتشر بشكل واسع في أواخر عام 2022، في الاعتماد الواسع لشبكة Lightning. وفي الوقت نفسه، ازدهرت Ordinals في أوائل عام 2023. وباعتباره حلًا للعقود الذكية يعتمد على البيتكوين وشبكة Lightning ويقدم اكتمال تورينغ وقابلية التوسع وحماية قوية للخصوصية، أصدر RGB إصدارًا جديدًا (v0.10) في أبريل من هذا العام.

تطور RGB

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

في عام 2019، قاد أورلوفسكي، وهو مطور رئيسي لـ RGB، تطوير RGB وأنشأ العديد من المكونات التي شكلت في النهاية بروتوكول RGB. بالإضافة إلى ذلك، ساعد إنشاء جمعية LNP/BP في سويسرا في توفير المعايير ذات الصلة.

بعد جهود تطوير مكثفة، كشفت RGB عن إصدارها v0.10 في أبريل 2023.

حول تصميم RGB

هذه هي الطريقة التي يحقق بها RGB قابلية التوسع والسرية:

التحقق من جانب العميل

تعمل معظم سلاسل الكتل العامة الموجودة حاليًا وفق نموذج إجماع عالمي، حيث تقوم جميع العقد بالتحقق من صحة جميع المعاملات، وتتبادل معلومات المعاملات فيما بينها، وتحافظ على حالة عالمية موحدة.

ومع ذلك، يطرح هذا النموذج العديد من التحديات، بما في ذلك:

قيود قابلية التوسع التي تجعل التحقق من صحة جميع تفاعلات العقود مكلفًا؛
التكاليف العالية التي تؤدي إلى تشغيل مركزي للعقد؛
انعدام الخصوصية بسبب المعلومات المفتوحة للمعاملات.

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

الميزات الرئيسية للـ CSV:

يتم تخزين المعلومات التفصيلية للمعاملات خارج السلسلة والتحقق منها فقط على جانب العميل؛
يتم تخزين الالتزامات ببيانات المعاملات فقط على السلسلة؛
ينطبق التحقق فقط على المعاملات التي يجب أن يكون المستخدمون على دراية بها.

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

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

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

الأختام أحادية الاستخدام المستندة إلى البيتكوين

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

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

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

دعونا نرى كيف تعمل هذه العملية بين أليس وبوب وديف:

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

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

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

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

قابلية التوسع

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

الخصوصية

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

وظائف RGB المتنوعة وحالات الاستخدام

المخططات

يمكن للمصدرين استخدام مخططات RGB، والتي تعمل كقوالب للعقود التي يمكن استخدامها لاستهداف حالات استخدام محددة.

إليك بعض الأمثلة:

إصدار الأصول القابلة للاستبدال RGB20
إصدار الأصول غير القابلة للاستبدال RGB21
الهويات الرقمية اللامركزية RGB22
سجل تاريخ فريد قابل للتحقق للبيانات القابلة للتدقيق RGB23
نظام أسماء النطاقات العالمي اللامركزي RGB24
إصدار الأصول القابلة للجمع RGB25

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

AluVM

تستخدم RGB نظام AluVM، وهو آلة افتراضية RISC قائمة على السجلات مصممة خصيصًا. يعتبر AluVM كاملاً من حيث تورينج ويمكنه تشغيل الحالة العالمية بنفس ضمانات التوفر الموجودة في الأنظمة القائمة على سلسلة الكتل. وبشكل مشابه لـ EVM، يتميز AluVM بهندسة تضع عقدة RGB فوق شبكة البرق، حيث يستضيف عميل RGB على عقد RGB.

متوافق تمامًا مع شبكة البرق

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

مقارنة مع الحلول الأخرى

RGB مقابل TARO

تم تقديم TARO (الآن أصول Taproot)، وهو بروتوكول Taro مدعوم بـ Taproot، من قبل Lightning Labs في أبريل 2022 بعد جمعها 70 مليون دولار في تمويل السلسلة B.

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

مقارنة مع حلول البيتكوين الأخرى

على عكس Drivechain، الذي يعتمد على BIP300 و BIP301 ويتطلب تفرعات صلبة، فإن RGB متوافق مع تقنية البيتكوين الحالية والتفرعات اللينة المحتملة في المستقبل، دون الحاجة إلى تعديلات في الطبقة الأساسية للبيتكوين.

تلتزم Ordinals بجميع البيانات في سلسلة الكتل، بينما تحتفظ RGB فقط بالتزامات البيانات على السلسلة. ونظرًا للأمان الذي توفره UTXOs، تستهلك RGB مساحة ضئيلة على السلسلة، مما يتيح التكامل السلس مع شبكة البرق.

RGB مقابل Rollup

Rollup هو حل لتوسيع نطاق Ethereum يتيح للمستخدمين إيداع الأموال في العقود الذكية لـ Ethereum ثم التعامل مع مستخدمين آخرين في نفس الـ Rollup. يتم تجميع هذه المعاملات دوريًا وتقديمها إلى سلسلة الكتل.

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

منحنى تعلم المطورين: بالإضافة إلى معرفة البيتكوين، يجب على المطورين أيضًا البقاء على اطلاع بانتقالات الحالة والعقود الخاصة بـ RGB.

مشاريع النظام البيئي

DIBA

الموقع الإلكتروني: https://diba.io/

DIBA هو سوق NFT للبيتكوين باستخدام بروتوكول العقود الذكية RGB.

Cosminmart

الموقع الإلكتروني: https://www.cosminmart.com/

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

مايسيتادل

الموقع الإلكتروني: https://mycitadel.io/

يتميز مايسيتادل بمجموعة واسعة من الوظائف، بما في ذلك التوقيع المتعدد، وشروط الإنفاق المقيدة زمنياً، وتابروت، وغيرها.

بيتماسك

الموقع الإلكتروني: https://bitmask.app/

بيتماسك هو امتداد للمحفظة.

حول كوينإكس

تأسست كوينإكس في عام 2017، وهي منصة عالمية لتداول العملات المشفرة ملتزمة بتسهيل تداول العملات المشفرة. توفر المنصة مجموعة من الخدمات، بما في ذلك التداول الفوري والتداول بالهامش والعقود الآجلة والمبادلات وحساب صنع السوق الآلي (AMM) وخدمات الإدارة المالية لأكثر من 5 ملايين مستخدم في أكثر من 200 دولة ومنطقة. تأسست كوينإكس بهدف أولي يتمثل في خلق بيئة متساوية ومحترمة للعملات المشفرة، وهي مكرسة لتفكيك حواجز التمويل التقليدية من خلال تقديم منتجات وخدمات سهلة الاستخدام لجعل تداول العملات المشفرة في متناول الجميع.

المراجع

https://hackernoon.com/top-4-directions-of-bitcoin-ecosystem-scalability

https://docs.rgb.info/

https://github.com/RGB-WG/blackpaper/blob/master/README.md

https://docs.lightning.engineering/the-lightning-network/taproot-assets

https://docsend.com/view/he8x9erkjmphphvn

تحليل موجز لـ RGB: بروتوكول عقود ذكية قابل للتوسع وسري مبني على بيتكوين