يعزز نظام RGB قابلية التوسع وقدرات الخصوصية الخاصة بـ Bitcoin وLightning Network

TL؛ DR

• يعمل نظام RGB كحل من الطبقة 2/3 على نموذج التحقق من صحة Bitcoin وLightning Network.client-side، والذي يضم جميع بيانات العقود الذكية خارج معاملات Bitcoin. ويضمن هذا التصميم تشغيل النظام فوق شبكة Lightning Network، مما يلغي الحاجة إلى إجراء تعديلات على بروتوكولات LN.
  
• تم تصميم العقود الذكية RGB لقابلية التوسع والسرية. يدعم النظام الملكية الخاصة والمتبادلة، ويلخص الاهتمامات ويفصلها، ويمثل شكلاً كاملاً من الحوسبة الموزعة غير الموثوق بها بعد سلسلة الكتل، تورينج دون الحاجة إلى إدخال رموز جديدة.
  
• يتم تنظيم عقود RGB في أجزاء منفصلة تسمى "الأجزاء"، ولكل منها تاريخها وبياناتها الخاصة، مما يعزز قابلية التوسع ويمنع خلط التواريخ من عقود مختلفة. وهي تتفاعل عبر بروتوكول Bifrost على شبكة Lightning Network، مما يتيح إجراء تغييرات منسقة بين أطراف متعددة، على غرار DEXes التي تعمل على شبكة Lightning Network.
  
• يستخدم RGB الأختام ذات الاستخدام الواحد defiنيد على Bitcoin UTXOs للأمان. يمكن لأي طرف يمتلك تاريخ حالة العقد الذكي التحقق من تفرده، والاستفادة من نص البيتكوين defiحقوق الملكية والوصول الجديدة.
  
• في RGB، تعد ملكية الدولة والتحقق من صحتها كيانين منفصلين. تتم إدارة الملكية بواسطة برنامج Bitcoin النصي، وهو نظام غير تابع لـ Turing. من ناحية أخرى، يتم تحديد قواعد التحقق من الصحة بواسطة مخطط RGB باستخدام برنامج Turing Complete Simplicity/Contractum/Rust Script.
  
• يرتبط كل عقد ذكي RGB بحالة فريدة باستخدام أختام أحادية الاستخدام. تتبع الأختام والحالة قواعد وتحققات محددة يحددها منشئ العقد، ويحكمها "المخطط". يعمل هذا المخطط كمجموعة قواعد للتحقق من بيانات العقد من جانب العميل، مما يتيح مستوى عالٍ من قابلية تطوير البروتوكول والخصوصية.
  
• يتميز تصميم RGB بأنه قابل للتشغيل المتبادل بشكل كبير مع تقنيات Bitcoin وLightning Network الحالية، مما يسهل التكامل السلس مع هذه المنصات وأي ترقيات مستقبلية.
  
• على عكس أسلوب البرمجة الحتمي للعديد من منصات blockchain، يستخدم RGB أسلوبًا تعريفيًا. يركز هذا النهج على تحديد النتيجة المرجوة بدلاً من تفصيل الخطوات المحددة لتحقيقها.
  
• يستخدم RGB العديد من التقنيات المتقدمة، بما في ذلك AluVM لمهام الحوسبة المحمولة الحتمية، وPRISM لحوسبة أجهزة الحالة اللانهائية المنسوخة جزئيًا، وStorm للتخزين غير الموثوق به القائم على الضمان باستخدام إثباتات zk. تساهم هذه التقنيات في تعزيز قوة RGB وسريتها وقابليتها للتوسعة.
  
• يقدم RGB (الإصدار 0.10) تحسينات ملحوظة لتجربة المستخدم وعمليات التكامل، وتبسيط العمليات وتقليل التبعيات. يتميز الإصدار المحدث بواجهة برمجة تطبيقات مكتبة موحدة وأداة سطر أوامر، مما يجعلها أكثر سهولة في الوصول إليها وسهولة الاستخدام.

وصف قصير

RGB هو بروتوكول مصمم لإصدار الرموز المميزة على شبكة Bitcoin مع تعزيز الخصوصية والتوافق مع شبكة Lightning Network. إنه يعتمد على مفهوم "العملات المعدنية الملونة"، مثل تلك المستخدمة في بروتوكول OmniLayer حيث تشير البيانات الوصفية في معاملات Bitcoin إلى نقل الرمز المميز. على سبيل المثال، تعمل معاملات USDT على OmniLayer كمعاملات Bitcoin معززة ببيانات إضافية توضح بالتفصيل حركات رمز USDT. ومع ذلك، تواجه هذه الأساليب قيودًا مثل قيود حجم البيانات في مخرجات OP_RETURN، والمسح المكثف لـ blockchain والخصوصية المقيدة الناجمة عن الرؤية على السلسلة.

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

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

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

المقدمة والرؤية

بطانة واحدة: حالة التحقق من صحة العميل ونظام العقد الذكي الذي يعمل في الطبقة 2/3 في Bitcoin وLightning Network.

مزيد من التفاصيل:

RGB هو نظام عقود ذكية قابل للتطوير وسري لشبكة Bitcoin وLightning Network. تعمل العقود الذكية RGB مع التحقق من جانب العميل النموذج والإسكان جميع بيانات العقد الذكي في الخارج معاملات البيتكوين، أي Bitcoin blockchain أو حالة قناة Lightning. يسمح هذا للنظام بالعمل على شبكة Lightning Network دون أي تغييرات على بروتوكولات LN، كما يوفر أساسًا لمستوى عالٍ من قابلية تطوير البروتوكول والخصوصية.

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

تعمل عقود RGB في أجزاء منفصلة تسمى "الأجزاء". كل جزء له تاريخه وبياناته الخاصة، مما يعني أن العقود المختلفة لا تخلط بين تاريخها. تعمل هذه الطريقة على تحسين قابلية التوسع. يُستخدم مصطلح "shard" لإظهار أن RGB يحقق أهدافًا مماثلة لما كان مقصودًا من مفهوم Shards الخاص بـ Ethereum.

على الرغم من أنها تعمل بشكل مستقل، إلا أن عقود RGB يمكن أن تتفاعل من خلال بروتوكول Bifrost على شبكة Lightning Network. وهذا يسمح بإجراء تغييرات منسقة بين أطراف متعددة. على سبيل المثال، فهو يمكّن DEXes من العمل عبر شبكة Lightning Network.

التكنولوجيا والهندسة المعمارية

نظرة عامة عالية المستوى على تشغيل RGB والأختام ذات الاستخدام الواحد

الشكل 1. نظرة عامة رفيعة المستوى على تشغيل RGB.
المصدر: جمعية LNP/BP جيثب.

كآلية أمنية، يستخدم RGB الأختام ذات الاستخدام الواحد defiتم استبداله عبر Bitcoin UTXOs، والذي يوفر القدرة لأي طرف لديه سجل حالة العقد الذكي للتحقق من تفرده. في جوهر الأمر، يستفيد نظام RGB من نص Bitcoin في نموذج الأمان الخاص به و defiغير مذكورة ملكية و حقوق الوصول.

الشكل 2. مبدأ العمل عالي المستوى RGB.
المصدر: "دفع التبني الجماعي للعملات المشفرة: كيف ينير بروتوكول RGB مستقبل البيتكوين" بواسطة Waterdrip Capital.

كل عقد ذكي RGB هو defiنيد بواسطة أ حالة التكوين، من صنع مصدر العقد الذكي (أو ببساطة، المُصدر) ورسم بياني حلقي موجه (DAG) لـ تحولات الدولة يتم الاحتفاظ بها كبيانات تم التحقق من صحتها من قبل العميل.

الشكل 3. المعاملات والختم المغلق والشاهد.
المصدر: جمعية LNP/BP جيثب.

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

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

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

الملكية والوصول: الخصائص الأساسية

الشكل 4. الملكية والوصول.
المصدر: جمعية LNP/BP جيثب.

ملكية الدولة والتحقق من صحتها هي مفاهيم متميزة. تحدد قواعد التحقق كيف يمكن أن تتغير الحالة، في حين أنها لا تحدد من يمكنه تنفيذ التغيير. 

من ناحية أخرى، يتم التحكم في الملكية من خلال برنامج Bitcoin النصي على مستوى Bitcoin blockchain، وهو ليس Turing Complete. في المقابل، تخضع قواعد التحقق من الصحة لمخطط RGB باستخدام برنامج Simplicity/Contractum Script، أي أن يكون Turing Complete. 

مخطط RGB

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

الشكل 5. مخطط RGB.
المصدر: جمعية LNP/BP جيثب.

مبادئ التحقق والتصميم من جانب العميل

الشكل 6. التحقق من جانب العميل RGB.
المصدر: جمعية LNP/BP جيثب.

1. ملكية قوية: في RGB، العقود الذكية لها وضوح defiنيد مالك أو أصحاب. يمتلك المالكون المعينون فقط سلطة تعديل حالة العقد. تحدد هذه العقود حقوقًا أو عمليات مميزة مصنفة إما عامة (متاحة للجميع) أو مملوكة (مقصورة على المالك).
2. سرية: تبقى المعلومات الواردة في العقد سرية، ولا يعرفها إلا المشاركون، وخاصة أصحاب الدولة. يتوفر للمشاركين خيار جعل بعض البيانات عامة، ولكن بشكل افتراضي، تكون جميع المعلومات خاصة. تمنع هذه السرية أدوات التحليل الخارجية من الوصول إلى البيانات، مما يضمن عدم تخزين أي معلومات حساسة في دفاتر الأستاذ العامة.
3. فصل الاهتمامات: يتميز نظام RGB بتصميم معياري بطبقات مميزة، يتم تعيين كل منها بمهمة محددة. تعمل هذه الطبقات بشكل مستقل، مما يلغي ضرورة أن تكون الطبقات السفلية على دراية ببنية الطبقات العليا. يعزز هذا التصميم تنظيم وكفاءة النظام.
4. التمدد: النظام قابل للتمديد بسهولة، مما يسمح بإنشاء وتكامل العقود الذكية المتقدمة دون الحاجة إلى تعديل البروتوكول الأساسي أو إعادة ترجمة مكتبة RGB بأكملها.
5. الحتمية: يعتبر منطق التحقق من صحة RGB حتميًا، ويؤدي باستمرار إلى نتائج متطابقة مع نفس المدخلات والحالة السائدة لقناة blockchain أو شبكة Lightning Network الأساسية. ويتحقق هذا الاتساق من خلال عنصرين رئيسيين: أ. منطق التحقق الأساسي، المكتوب بلغة Rust، هو نفسه في جميع الأنظمة التي تعمل بنظام RGB. ب. يتم تشغيل منطق التحقق الخاص بالعقد على AluVM، وهو جهاز افتراضي يوفر مجموعة متسقة من التعليمات بغض النظر عن النظام الأساسي.
6. إمكانية التشغيل البيني LNP/BP: تم تصميم RGB للعمل بسلاسة مع تقنيات Bitcoin وLightning Network الحالية. لقد تم تصميمه أيضًا ليكون متوافقًا مع أي ترقيات مستقبلية لهذه التقنيات.
   

نهج RGB ونهج Blockchain / L1 النقي

يقول فريق RGB إن نهج blockchain/L1 النقي خاطئ.

الشكل 7. تعليقات RGB على نهج Blockchain/L1.
المصدر: جمعية LNP/BP جيثب.

نهج RGB: البرمجة التعريفية مقابل البرمجة الحتمية:

• تستخدم معظم منصات blockchain، بما في ذلك Ethereum، العقود الذكية المكتوبة بأسلوب حتمي. في هذا النهج، يعمل العقد كبرنامج يوجه بوضوح تنفيذ المهام خطوة بخطوة، مما يشبه وصفة دقيقة ومفصلة.
• غالبًا ما تكون هذه البرامج الحتمية مقيدة تمامًا ومحدودة بقدرات منصة blockchain الأساسية. على الرغم من أنه يشار إليها أحيانًا باسم Turing-Complete، إلا أنها تأتي مع قيود كبيرة.

الطبيعة التصريحية للعقود الذكية RGB:

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

التحول النموذجي في البرمجة:

• يشبه الانتقال من أسلوب Ethereum الحتمي إلى أسلوب RGB التعريفي في برمجة العقود الذكية التحول من البرمجة الحتمية التقليدية إلى البرمجة الوظيفية أو التعريفية في تطوير البرامج بشكل عام.
• ويتطلب هذا التحول عقلية مختلفة: التركيز على "ماذا" (النتائج المرجوة) بدلا من "كيف" (الخطوات المحددة لتحقيق تلك النتائج).

البساطة

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

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

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

موشور

يرمز PRISM إلى حوسبة "أجهزة الحالة اللانهائية المنسوخة جزئيًا".

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

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

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

يمكنك أدناه رؤية عرض رفيع المستوى حول الاختلافات بين قنوات الدولة والتحقق من جانب العميل: 

الشكل 8. فصل الأنظمة الموزعة.
المصدر: جمعية LNP/BP جيثب.

المزيد من الاختلافات المحددة هي كما يلي: 

الشكل 9. مقارنة قنوات الدولة والتحقق من جانب العميل.
المصدر: جمعية LNP/BP جيثب.

AluVM

AluVM - (وحدة المنطق الخوارزمية VM) عبارة عن جهاز ظاهري RISC وظيفي خالص مصمم لمهام الحوسبة المحمولة الحتمية

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

الخصائص الرئيسية: استثنائي، قابلية النقل، وضع الحماية، الأمان، قابلية التوسعة.

تم تصميم بنية مجموعة التعليمات (ISA) الخاصة بـ AluVM لتكون قابلة للتكيف، مما يسمح لها بإنشاء بيئات تشغيل مختلفة لمختلف التطبيقات. AluVM نفسها عبارة عن جهاز ظاهري قابل للتنبؤ به للغاية وعملي ومعتمد على التسجيل وISA. 

أثناء تقييد الوصول إلى الذاكرة العشوائية، يتفوق AluVM ISA في أداء المهام الحسابية، بما في ذلك تلك المتعلقة بالمنحنيات الإهليلجية. بشكل فريد، يمكن لبيئة VM توسيع AluVM ISA، مما يتيح إضافة وظائف مثل تحميل البيانات في سجلات VM ودعم التعليمات المتخصصة (على سبيل المثال، SIMD) المصممة لتطبيقات محددة.

تم تصميم AluVM بشكل أساسي للاستخدام في الأنظمة الموزعة حيث يكون الاتساق والموثوقية عبر الأنظمة الأساسية المختلفة أكثر أهمية من سرعة المعالجة. تشمل الاستخدامات الأساسية لـ AluVM، مع امتدادات ISA الصحيحة، تقنية blockchain، والحسابات المهمة للتوافق في الشبكات، وحوسبة الحافة، والحوسبة متعددة الأطراف (التي تغطي التعلم الآلي الحتمي)، والتحقق من جانب العميل، وحوسبة Internet2 المقيدة، والخوارزميات الجينية. تستفيد هذه التطبيقات من قدرة AluVM على الأداء بشكل متسق وآمن في بيئات مختلفة.

الشكل 10. مقارنة AluVM.
المصدر: جمعية LNP/BP جيثب.

العقد

تميز Contractum نفسها عن غيرها من لغات برمجة العقود الذكية من خلال مزج القدرات الوظيفية لـ Haskell مع القرب من المعدن العاري الموجود في Rust. إنها تحتل مكانة لم يكن من الممكن الوصول إليها في السابق للعقود الذكية:

الشكل 11. مقارنة التعاقد والبساطة واللغات الأخرى.
المصدر Contractum.org

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

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

الشكل 12. ميزات العقد.
المصدر Contractum.org

للمشاركة في تصميم Contractum، من المهم التعرف على التقنيات المستخدمة في العقود الذكية RGB:

الشكل 13. التقنيات التي تستخدمها العقود الذكية RGB.
المصدر Contractum.org

التحديثات الأخيرة في الإصدار الجديد RGB v0.10

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

الحالة العالمية في عقود RGB

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

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

واجهات العقد

يقدم الإصدار 0.10 من RGB "واجهات العقد" كبروتوكول اتصال موحد للعقود الذكية المتنوعة. تعمل هذه الواجهات بشكل مشابه لعقد Ethereum ABIs (الواجهات الثنائية للتطبيقات) وERCs (طلب Ethereum للتعليقات).

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

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

نظام نوع صارم

يستخدم تنسيق التشفير الجديد في RGB v0.10 نظام "الأنواع الصارمة". هذا النظام عبارة عن نهج جديد لنوع البيانات الوظيفية مصمم للتمثيل الفعال والتأمل في حالات العقد ضمن إطار عمل RGB.

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

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

العقود الذكية القائمة على الصدأ

يمكن الآن تأليف العقود الذكية ذات الألوان RGB (RGB) بلغة Rust، مما يؤدي إلى الاستفادة من إمكانات اللغة فيما يتعلق بأمان الكتابة والأداء.

يسهل التكامل الصارم لنوع النظام التجميع المباشر لأنواع بيانات Rust في هياكل عقود RGB، مما يحسن كفاءة وموثوقية كود العقد.

تعزيز قدرات الدولة على الاستبطان

يمكن للعقود الذكية في RGB v0.10 أن تستكشف حالتها الخاصة ضمن رمز التحقق الذي ينفذه جهاز RGB الظاهري.

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

تنسيق الفاتورة المستند إلى عنوان URL

يقدم التحديث تنسيق فاتورة جديدًا يحل محل النظام السابق المشفر بـ Bech32m.

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

دعم WASM (WebAssembly).

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

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

واصفات الجذر والاشتقاق المخصص

يستخدم الإصدار RGB v0.10 التزامات OP_RETURN المستندة إلى الجذر (يشار إليها باسم Tapret)، مما يستلزم دعمًا على مستوى الواصف للمحافظ للتعرف على المعاملات ذات المخرجات المعدلة.

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

التبعيات المبسطة

لقد قللت طبقة إجماع RGB في الإصدار 0.10 من تبعياتها، ولا سيما الابتعاد عن تطبيق مخصص مضاد للرصاص مشتق في الأصل من مشاريع Grin.

يؤدي هذا الانخفاض في التبعيات إلى تعزيز استقرار واجهة برمجة التطبيقات (API) وقوة النظام بشكل عام.

عملية التكامل المبسطة

يعمل التحديث على تبسيط سير العمل التشغيلي عن طريق تقليل الحاجة إلى استدعاءات API المتعددة وترميز بنية البيانات المعقدة عبر اللغات.

يتم الآن تمثيل حالات عقد RGB ككائنات JSON، مما يتيح إجراء تسلسل مباشر عبر لغات برمجة مختلفة.

تحسينات تجربة المستخدم

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

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

يتضمن هذا القسم شكر خاص لشركة Waterdrip Capital لتسليط الضوء على أحدث الميزات في مقالتها التي تحمل عنوان "قيادة التبني الشامل للعملات المشفرة: كيف يضيء بروتوكول RGB مستقبل البيتكوين".

المنافسين RGB

الشكل 14. FRGB مقابل Ethereum بكلمات بسيطة.
المصدر: جمعية LNP/BP جيثب

أصل

Taproot Assets، المعروف سابقًا باسم Taro، هو بروتوكول مصمم لإطلاق الرموز المميزة على شبكة Bitcoin. يستفيد هذا البروتوكول من نموذج UTXO الخاص بـ Taproot جنبًا إلى جنب مع الحلول المرتبطة به مثل Tapscript وtaptweak. تُستخدم هذه الأدوات لتخزين المعلومات حول عرض وتوازن الأصل ضمن بيانات معاملات Bitcoin.

الشكل 15. مخطط لتخزين المعلومات حول الرموز المميزة لـ Taproot Assets.
المصدر: "أصول Taproot: إصدار الأصول على Bitcoin" بواسطة Voltage

تستخدم Taproot Assets طريقة مشابهة لمفهوم Ordinals، حيث تقوم رموز BRC-20 بتخزين معلومات العرض في البيانات الوصفية الخاصة بالساتوشي المذكورة. على العكس من ذلك، تقوم أصول Taproot بتضمين هذه المعلومات في مخرجات Taproot لمعاملة Bitcoin، وذلك باستخدام ما يُعرف باسم "شجرة Merkle المتفرقة". بشكل أساسي، تقوم Taproot Assets بدمج شجرة Merkle في معاملة Bitcoin، والتي تعمل كدليل على رصيد مستخدم معين والعرض الإجمالي للرموز. تعكس هذه الشجرة بدورها بيانات من "الكون" - وهو مستودع يحتفظ بسجل الأصول الكامل ويديره مصدر الرمز المميز.

الشكل 16. شجرة الحالة الرقمية.
المصدر: "أصول Taproot: إصدار الأصول على Bitcoin" بواسطة Voltage

شجرة الحالة الرقمية – توفر بنية Taproot Assets خيارين لإثبات التوازن: البيانات خارج السلسلة من الكون أو شجرة Merkle المتفرقة المضمنة في UTXO.

آلية التشغيل

1. ينفذ منشئ الرمز المميز معاملة P2TR (الدفع إلى Taproot) باستخدام بروتوكول Taproot Assets. 
2. يتم تخزين المعلومات حول الأصل، على شكل شجرة Merkle، في UTXO لهذه المعاملة (في الواقع، كتلة التكوين). 
3. لنقل الرمز المميز، يقوم مالك مفتاح Taproot بتعديل معلومات الرصيد في شجرة Merkle، مما يضمن بقاء إجمالي عرض الأصول ثابتًا. 
4. يتم تقديم مثل هذه التعديلات عبر معاملة Taproot جديدة. ومع ذلك، بالنسبة لكل عملية نقل رمزية، لا يلزم إجراء معاملة منفصلة على السلسلة. على غرار عمليات التجميع أو الشبكة المسرّعة، يسمح البروتوكول للمالك بمعالجة "دفعة" من التحويلات، ثم نشر الحالة المحدثة للأرصدة.

مزايا أصول Taproot

• إحدى المزايا الرئيسية لـ Taproot Assets هي توافقها الكامل مع شبكة Lightning Network، مما يعزز إمكانيات قابلية التوسع ويقلل تكاليف المعاملات.
• تقوم Taproot Assets بإنشاء طبقة مميزة لتسجيل العمليات باستخدام الرموز المميزة. وفي حين أنها تعتمد في المقام الأول على البيانات خارج السلسلة، فإنها تنشر حالة الأرصدة على الشبكة الرئيسية. 
• يعد هذا النهج أكثر مرونة وقابلية للتطوير وشمولية مقارنة بـ BRC-20، ولكنه يشكل أيضًا المزيد من التعقيد للمستخدمين عديمي الخبرة.

BitVM

BitVM هو مشروع متطور يهدف إلى تحويل Bitcoin إلى منصة حوسبة لامركزية بالكامل. تقدم الوثيقة البيضاء لـ BitVM، التي تم تقديمها في 9 أكتوبر 2023، تقنية هي حاليًا في مرحلة الاختبار وتتطلب مزيدًا من التطوير للوصول إلى إمكاناتها الكاملة.

الوظائف الأساسية ومفهوم BitVM

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

التعامل مع التحقق على السلسلة في شبكة محدودة حسابيًا

وينشأ التحدي في كيفية إجراء فحص العمليات في شبكة لا تدعم في جوهرها مثل هذه الحسابات. لمعالجة هذه المشكلة، تستخدم BitVM شجرة Merkle لإنشاء نظام بوابة NAND منطقي، والذي يتم تسجيله بعد ذلك في معاملة Taproot. في الأساس، تعمل شجرة Merkle في بيانات المعاملة كمخطط NAND، حيث يحمل كل "فرع" واحدة من القيمتين المحتملتين: 1 أو 0. وتستمر العمليات الحسابية على السلسلة شيئًا فشيئًا، ويصبح ناتج "فرع" واحد الإدخال للتالي. تحدث عمليات تبادل المعاملات المستمرة للتحقق من القيمة بين أطراف العقد الذكي. إذا تم العثور على نسخة حسابية غير صحيحة، يتلقى المدقق أصوله المقفلة في معاملة Taproot.

الشكل 17. التمثيل التخطيطي لـ NAND.
المصدر: "الصفقة الكبيرة مع BitVM: الحوسبة التعسفية ممكنة الآن على Bitcoin بدون شوكة" من مجلة Bitcoin

بناء NAND باستخدام Taproot وشجرة Merkle

يمكن العثور على معلومات تفصيلية حول كيفية تسهيل BitVM لبناء NAND باستخدام شجرتي Taproot وMerkle، بالإضافة إلى تأثيرها على العمليات الحسابية، في الوثائق الفنية.

يسمح هذا النهج بالتحقق الدقيق خطوة بخطوة من حسابات العقود الذكية، بما يتماشى مع مبادئ سلامة وأمن blockchain.

التحديات التي تواجه ثنائية العقود الذكية

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

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

للحصول على تعمق مفصل، لا تتردد في قراءة BitVM Whitepaper - https://bitvm.org/bitvm.pdf 

وفي الختام

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

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

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

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

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

آخر تحديث لـ RGB، الإصدار 0.10، يضعها كمنافس بارز في المشهد المتطور لتقنيات blockchain، خاصة ضد البروتوكولات الناشئة مثل Taproot Assets وBitVM. على عكس Taproot Assets، الذي يركز على الاستفادة من نموذج UTXO الخاص بـ Taproot لإصدار الرمز المميز على شبكة Bitcoin، تتميز RGB بميزات الخصوصية المتقدمة ومعالجة البيانات خارج السلسلة، مما يوفر نهجًا متميزًا لوظائف العقد الذكي وإدارة الرمز المميز.

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

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

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

مراجع المصطلح: 

1. تورينج كاملة: من الناحية العملية، يمكن للنظام تنفيذ أي مشكلة حسابية بوقت وذاكرة كافيين. معظم لغات البرمجة الحديثة هي كاملة تورينج، مما يدل على قدرتها النظرية على معالجة أي مشكلة حسابية.
   
2. مخطط: يعمل مخطط العقد بمثابة الكود الفعلي للعقد الذكي، والذي يمكن استخدامه كـ "قالب عقد" من قبل الجهات المصدرة دون الحاجة إلى ترميز أو تدقيق التعليمات البرمجية المخصصة المقدمة من مصادر خارجية. مخطط RGB ليس برنامجًا نصيًا ولكنه عبارة عن بنية بيانات.
   
3. عقود السجل المنفصلة (DLCs) في سياق القنوات الحكومية هي عقود ذكية متخصصة تستخدم بشكل أساسي في شبكة Bitcoin. فهي تتيح التنفيذ الخاص والفعال للاتفاقيات المالية المعقدة بناءً على أحداث خارجية، مثل أسعار الأصول. تعمل DLCs خارج السلسلة، مع الحفاظ على سرية تفاصيل العقد وهويات المشاركين. يستخدمون مصادر البيانات الخارجية، أو أوراكل، لحل العقود. عند دمجها مع القنوات الحكومية، تعمل DLCs على تعزيز قابلية التوسع من خلال السماح بتسويات المعاملات المتعددة دون ازدحام blockchain، مما يجعلها مثالية للمعاملات المالية الخاصة والفعالة التي تعتمد على نتائج العالم الحقيقي.
   
4. عاصفة - التخزين غير الموثوق به على أساس الضمان باستخدام zk-proofs. تجمع Storm بين التخزين غير الموثوق به القائم على الضمان وإثباتات المعرفة الصفرية لتسهيل المعاملات الآمنة والخاصة. في هذا النظام، يتم الاحتفاظ بالبيانات أو الأصول في ضمان ولا يتم إصدارها إلا عند استيفاء شروط محددة، مما يضمن بيئة غير موثوقة حيث لا توجد حاجة إلى سلطة مركزية. يسمح تكامل zk-proofs بالتحقق من هذه المعاملات مع الحفاظ على أقصى قدر من السرية، لأنها تمكن من التحقق من صحة البيانات دون الكشف عن أي تفاصيل أساسية.
   
5. محب العمل - الحوسبة الموزعة غير الموثوقة القائمة على التحكيم. تمثل بروميثيوس نهجًا للحوسبة اللامركزية، يجمع بين آليات التحكيم لحل النزاعات، والتفاعلات غير الموثوقة للعمليات الآمنة واللامركزية، وكفاءة القنوات الحكومية لإدارة الحسابات خارج السلسلة.
   
6. A انخفاض الكمبيوتر مجموعة التعليمات هو نوع من بنية المعالجات الدقيقة التي تستخدم مجموعة صغيرة ومحسنة للغاية من التعليمات بدلاً من مجموعة التعليمات عالية التخصص التي توجد عادةً في بنيات أخرى.