تحاول هذه المقالة تقديم وصف موجز لـ RGB، وهو بروتوكول لإصدار الأصول على Bitcoin (يمكن فهمه أيضًا على أنه نظام عقد ذكي خارج السلسلة)، وتشير إلى أنه يختلف تمامًا عن المشاريع الأخرى التي تهدف إلى لتحقيق نفس البروتوكولات الوظيفية أو ما شابهها، فإن هذه الاختلافات تجعل بروتوكول RGB أكثر قابلية للتوسع منها، وتترك مساحة برمجة أوسع. بالإضافة إلى تقديم تصميمات RGB الكاملة، سنستكشف أيضًا إمكانيات البرمجة هذه.
ما هو بروتوكول RGB؟
كانت فكرة إصدار الأصول على البيتكوين موجودة منذ فترة طويلة. لكن بروتوكول Bitcoin له خصائصه الخاصة: يتم التعبير عن حالته بواسطة Bitcoin UTXO فقط ("مخرجات المعاملة غير المنفقة")؛ يحمل UTXO فقط بياناتين: الفئة الخاصة به (قيمة البيتكوين)، و"المفتاح العام للبرنامج النصي" (أيضًا يُعرف باسم "نص القفل")، ويستخدم لبرمجة شروط الإنفاق لهذا الصندوق، على سبيل المثال: توفير توقيع لمفتاح عام معين؛ السماح بتحديد كود التشغيل المستخدم في برمجة نص القفل من خلال قواعد الإجماع الخاصة بالبيتكوين بشرط ألا تتمكن من ذلك استخدامها لتنفيذ قواعد أمنية تعسفية. لذلك، من المستحيل إنشاء أصول أخرى داخل UTXO - لا يمكن لبرنامج Bitcoin النصي برمجة عمليات التحقق الأمني لهذه الأصول. وهذا يعني أن جميع الأفكار المتعلقة بإصدار الأصول على البيتكوين هي في الأساس استخدامات إبداعية لمساحة كتلة البيتكوين. هذا يعني أننا بحاجة إلى تصميم نظام عقد ذكي خارج السلسلة ونطلب الخطوات اللازمة لتغيير حالة العقد - على سبيل المثال، يغير العقد "أ" المعلمات، وينقل "ب" مبلغًا معينًا من أصل معين إلى "ج" —— يتم تحميل المعلومات إلى blockchain، بحيث يمكن الحصول على أحدث حالة لنظام العقد الذكي من خلال جمع هذه المعلومات.
تتمثل فكرة التصميم التقريبية في تحميل معلومات الخطوات التي تغير حالة العقد إلى Bitcoin blockchain سليمة. من المؤكد أن هذا يعمل، لكنه يواجه عدة مشاكل:
(1) نظرًا لأن المعلومات الكاملة تم تحميلها، فقد تستهلك مساحة أكبر، وعندما يحتاج المستخدمون إلى تغيير حالة العقد (مثل النقل)، سيحتاجون أيضًا إلى دفع المزيد من رسوم المعالجة على السلسلة. على وجه الخصوص، عندما نأمل أن يتمتع نظام العقود خارج السلسلة هذا بقابلية برمجة أفضل من البيتكوين، فإن الزيادة في قابلية البرمجة قد تأتي على حساب استهلاك المزيد من مساحة الكتلة؛
(2) قد تؤدي أي معلومات موجودة في الكتلة تقريبًا إلى تغيير العقد الذكي خارج السلسلة، لذلك يجب على المستخدمين الحصول على جميع بيانات كتلة Bitcoin للحصول على أحدث حالة لنظام العقود خارج السلسلة، أي أن التحقق منها أكثر تكلفة؛
(3) اعتمادًا على تصميم نظام العقود الذكية خارج السلسلة، قد لا تتمكن إلا من الحصول على خصوصية مماثلة لتلك التي تتمتع بها Bitcoin، أو حتى أسوأ من ذلك؛ وإذا كان بإمكانك توفير المزيد من الخصوصية، فقد تحتاج إلى استهلاك المزيد من المساحة. مساحة الكتلة.
في الماضي، لم يكن البروتوكول المستخدم على نطاق واسع يسمى "Omni" يحمّل معلومات كاملة حول معاملات العقود خارج السلسلة، ولكن فقط قيمة التجزئة للمعاملة. يحل هذا النهج المشكلات المذكورة أعلاه ويفصل تعقيد معاملات العقود خارج السلسلة عن تكاليفها الاقتصادية؛ ومع ذلك، لا يزال المستخدمون بحاجة إلى الحصول على الكمية الكاملة من بيانات كتلة Bitcoin للحصول على أحدث حالة لبروتوكول Omni؛ بالإضافة إلى ذلك، فإنه لا غير مصممة خصيصًا لتعزيز الخصوصية.
يستخدم RGB نموذجًا جديدًا يسمى "الأختام ذات الاستخدام الواحد". استخدامه بسيط للغاية: يتطلب RGB أن كل حالة من كل عقد يجب أن تكون مرتبطة بـ Bitcoin UTXO معين، وبمجرد أن تريد تغيير هذه الحالة، يجب عليك إنفاق UTXO هذا والسماح للمعاملة التي تنفقه بالحصول على تأكيد على blockchain؛ بالإضافة إلى ذلك، يجب أن توفر معاملة Bitcoin التي تنفقها أيضًا تجزئة لمحتويات انتقال الحالة للإشارة إلى UTXO المرتبط بالحالة المتغيرة.
بالنسبة لمطوري RGB، التصميم مشابه لختم بلاستيكي مرقم: من السهل معرفة ما إذا تمت إزالته، وبمجرد إزالته، لا يمكن إعادة استخدامه. ومع ذلك، هناك منظور آخر وهو اعتبار UTXO المملوك بمثابة الحاوية أو الحصالة الخزفية في هذه الحالة - إذا كنت تريد إخراج الأموال الموجودة في الحصالة، فيجب عليك كسر الحصالة. ثم ضع الأموال بالداخل في الجرة الجديدة.
يتناقض هذا التصميم بشكل حاد مع البروتوكولات السابقة التي تعامل الكتلة بأكملها على أنها لوحة كتابة كبيرة: استخدام UTXO كحاوية يعني أن المعاملات التي لا تنفق هذا UTXO لا يمكن أن يكون لها أي تأثير على حالة العقد في الحاوية، لذلك، للتحقق حالة معينة لعقد معين، لا نحتاج إلى الحصول على بيانات جميع الكتل، كل ما نحتاجه هو سلسلة من معاملات البيتكوين، دليل على أن معاملات البيتكوين هذه موجودة في كتلة معينة، وهذه البتات تحويل حالة RGB الموعود بها يعد تبادل العملات (زوج واحد لواحد مع معاملة Bitcoin ذات الصلة) كافيًا. يجب أن تسمح لنا هذه البيانات، التي يمكن ربطها في سلسلة، بالرجوع إلى الحالة الأولية لهذا العقد، مما يسمح لنا بتحديد جوهر هذه الحالة.
بالنسبة للقراء الذين هم على دراية بأنظمة العقود الذكية على السلسلة (مثل Ethereum)، هناك شيء واحد يصعب فهمه حول هذه العملية وهو أنه إذا لم يعتمد على إجماع blockchain (مما يعني أن الحالة الأولية للشبكة العقد وسيتم التحقق من كل تغيير في الحالة بواسطة كل عقدة)، كيف يتم ضمان أمان نظام العقد الذكي هذا؟ كيف تتأكد من أن الأصول التي تتلقاها هي التي تريدها، وكيف تتأكد من أن الأصول لم يتم إصدارها بشكل غير قانوني؟
الإجابة أيضًا بسيطة للغاية، وتسمى "التحقق من جانب العميل" - حيث تقوم بالتحقق منها بنفسك. في نظام العقود على السلسلة، تتحقق العقد من كل عملية انتقال حالة وفقًا لقواعد انتقال الحالة العامة، وترفض العمليات غير الصالحة، ثم تحسب الحالة الأخيرة بناءً على الحالة الأولية. ومع ذلك، طالما أن قواعد انتقال الحالة والحالة الأولية معروفة، فإن التحقق من خلال الإجماع على السلسلة ليس هو الطريقة الوحيدة. يمكن للمستخدمين التحقق مما إذا كانت كل خطوة من خطوات انتقال الحالة تتبع انتقال الحالة المحدد في الأصل بناءً على المعلومات المقدمة من قبل the payer.rule. وبهذه الطريقة، يمكن للطرف المتحقق (المفترض أنه متلقي الأصل) أيضًا اكتشاف التحولات غير القانونية للدولة ورفض قبولها.
وأخيرا، نستخدم مثالا لتوضيح خصائص بروتوكول RGB:
الآن، تمتلك أليس UTXO A، الذي يحتفظ بوحدات X من الأصل Y الصادرة وفقًا لبروتوكول RGB. وهي تريد نقل وحدات Z من Y إلى Bob. مرت هذه المجموعة من الأصول بإجمالي 5 مالكين سابقين (بما في ذلك جهة إصدار الأصول) قبل أن تصل إلى يدي أليس. لذلك، تحتاج أليس إلى تزويد بوب بدليل على تحولات الحالة الأربع هذه (تم تقديم الثلاثة الأولى منها إلى أليس من قبل المالك السابق)، بما في ذلك الحالة الأولية للعقد وقواعد انتقال الحالة، والبتات المستخدمة لكل عملية نقل يتم إرسال معاملات البيتكوين ومعاملات RGB التي ترتكبها كل بورصة بيتكوين والدليل على أن معاملات البيتكوين هذه قد تم تأكيدها بواسطة كتلة معينة إلى بوب، وسيتحقق بوب من أن عمليات النقل الأربعة هذه لا تنتهك القواعد وفقًا لقواعد انتقال الحالة العقد، ثم تقرر قبوله أم لا. عندما تقوم أليس ببناء معاملة RGB، نظرًا لأن Z أصغر من X، يتعين عليها أيضًا ترتيب UTXO لنفسها لتلقي الجزء المتبقي. أخيرًا، تقوم أليس بتضمين قيمة التجزئة لمعاملة RGB هذه في معاملة Bitcoin التي تكلف UTXO A' لإكمال الدفع.
أخيرًا، نظرًا لاستخدام حاويات UTXO، يمكن تمثيل أحدث حالة لعقد RGB كنقطة على رسم بياني حلقي موجه ليس له فروع (تمثل كل نقطة حالة مخزنة في حاوية UTXO). علاوة على ذلك، بالنسبة للمالك P في الشكل أدناه، فلن يعرف العملية إلا من الحالة الأولية G للعقد للوصول إليه، أي العملية المميزة بالدائرة الحمراء، ولن يعرف شيئًا عن النقاط الرمادية:
#مزايا RGB
حالة خفيفة الوزن يمكن التحقق منها
كما ذكرنا سابقًا، بالمقارنة مع بروتوكولات إصدار الأصول السابقة (أنظمة العقود خارج السلسلة) التي ظهرت على Bitcoin، فإن RGB يقلل بشكل كبير من تكلفة التحقق (حالة معينة من العقد). أثناء المعاملة، لم يعد المتلقي بحاجة إلى اجتياز جميع الكتل لجمع معلومات حول التغييرات في حالة العقد، ولكنه يحتاج فقط إلى الحصول على سلسلة من معاملات البيتكوين، بالإضافة إلى معاملات RGB التي وعدت بها هذه البورصات، وكتل البيتكوين هذه تحتوي المعاملات على أدلة (استنادًا إلى أدلة Merkle الموجودة في رأس الكتلة)، يمكنك التأكد من أن الدافع يمتلك بالفعل مبلغًا معينًا من أصل معين.
كما أن هذا التخفيض في تكاليف التحقق يقلل بشكل كبير من اعتماد المستخدمين (ثقتهم) على كبار مقدمي البنية التحتية. في البروتوكولات السابقة، نظرًا لارتفاع تكلفة التحقق، كان من الصعب على المستخدمين حساب أحدث حالة للعقد بأنفسهم، لذلك كان على المستخدمين أن يثقوا في بعض مقدمي الخدمة (مثل مزود حالة العقد الذي تستخدمه محفظتهم الخاصة)؛ في في الوقت نفسه، لأنهم يستطيعون تحمل تكاليف ذلك، هناك عدد أقل من الموردين لحساب التكاليف، وهو ما يعني أيضًا مركزية الموردين. ولكن في RGB، يحتاج المستخدمون فقط إلى استخدام عميل Bitcoin Light للتحقق من جزء المعاملة باستخدام Bitcoin وبروتوكول RGB للتحقق من جزء معاملة RGB، ويمكنهم تحمل تكاليفه.
بالمقارنة مع بعض أنظمة العقود الموجودة على السلسلة، فإن RGB أخف أيضًا. ينعكس هذا في حقيقة أن RGB يمكنه التحقق على وجه التحديد من حالة معينة من العقد؛ في تلك الأنظمة التي لا تعتمد على UTXO، نظرًا لعدم وجود آلية للتحكم في الوصول مثل UTXO، فإن أي معاملة قد تغير أي حالة، لذلك يمكنك يكاد يكون من المستحيل التحقق من حالة معينة على وجه التحديد، ولكن يمكن فقط تحديد حالة معينة أثناء حساب جميع الحالات الأخيرة - وبهذا المعنى، فإن الخصائص المعبر عنها بـ "الدولة العالمية" يجب أن تسمى في الواقع "الدولة الموحدة". يوفر ميزة الوصول المتبادل بين العقود، كما أنه يحدد أيضًا أن تكلفة التحقق الخاصة به ستكون أعلى وسيكون الحصول على الثقة أكثر صعوبة.
في بروتوكولات العقود على السلسلة هذه، يتمثل أحد إجراءات التحسين الرئيسية في مطالبة رأس الكتلة بالالتزام بأحدث حالة ("جذر الحالة")، وبالتالي السماح للعملاء الخفيفين بالتحقق من حالة معينة من العقد الذي تم الحصول عليه من العقدة الكاملة بناءً على هذه الالتزامات.. هذه طريقة لإعادة استخدام الحسابات التي تم إجراؤها بالفعل (الحسابات التي تم إجراؤها بواسطة العقدة الكاملة)، وهي أيضًا فعالة جدًا، لذلك إذا لم يتم أخذ انعدام الثقة في الاعتبار، فيمكن اعتبارها أكثر كفاءة من RGB. ومع ذلك، فهذا يعني بعد كل شيء أن العقد الخفيفة تعتمد على العقد الكاملة للتحقق من المعاملة الأساسية وحساب حالة العقد. في محفظة RGB التي تستخدم عميل Bitcoin Light، فإن افتراض الثقة الذي تعتمد عليه هو أن معاملة Bitcoin ذات الصلة هي معاملة صالحة، وقد تم التحقق من الجزء المتعلق بحالة العقد شخصيًا من قبل العميل، لذلك فهو أكثر ثقة. مجاني . . العيب هو أن تأخير التحقق أطول ويجب الاحتفاظ بمزيد من البيانات.
قابلية التوسع
تنعكس قابلية التوسع في RGB في جانبين:
تعد قيمة التجزئة المضمنة في معاملة Bitcoin مجرد قيمة تجزئة، مما يعني أنه لا يوجد حد لحجم معاملة RGB (باستثناء القواعد المخصصة للعقد) - حتى إذا قمت بتقسيم أصل RGB واحد إلى 100 جزء (معاملة RGB ستكون كبيرة جدًا)، وهناك قيمة تجزئة واحدة فقط يجب تضمينها في معاملة Bitcoin. كما هو مذكور في الملاحظة 6، هناك طريقتان لتضمين قيمة التجزئة هذه: إحداهما هي استخدام إخراج OP_RETURN، مما يعني أنها ستستهلك المساحة الموجودة على السلسلة لقيمة التجزئة؛ والأخرى هي إخفاء الإخراج العام للبرنامج النصي في مفتاح Taproot - لا يستهلك هذا أي مساحة على السلسلة. وهذا يعني أيضًا أنه لا يتعين على المستخدمين التضحية بالاقتصاد من أجل قابلية البرمجة، مع الأخذ في الاعتبار فقط الرسوم الموجودة على السلسلة.
أحدث حالة لعقد RGB هي نقطة مستقلة على رسم بياني حلقي موجه بدون أي فروع - وهذا يعني أنه يمكن تغيير هذه الحالات بشكل مستقل دون التأثير على بعضها البعض، مما يعني السماح بالتزامن. هذه في الواقع ميزة موروثة من UTXO. وهذا يعني أيضًا أن التغييرات غير الصالحة (المعاملات غير الصالحة) التي تحدث في أحد الفروع لن تؤثر على الفروع الأخرى، ناهيك عن التسبب في توقف العقد بأكمله، لذلك يمكن اعتبارها أيضًا ميزة أمنية.
إحدى النقاط التي تم انتقاد RGB بسببها من حيث قابلية التوسع هي أن كل عملية نقل تتطلب من المستلم التحقق من جميع المعاملات المعنية من الحالة الأولية إلى حالة الدافع - مع زيادة عدد المرات التي يتم فيها تغيير الأصل، فإن عبء التحقق على المستلمين اللاحقين يزيد، وسوف يصبح أثقل وأثقل. وهذا النقد صحيح. وتحسين ذلك يعني أننا بحاجة أيضًا إلى إيجاد طريقة لإعادة استخدام العمليات التي حدثت بالفعل. تعد تقنيات نظام الإثبات مثل SNARKs بتوفير مثل هذا الحل.
التمييز بين تعريف الأصول وآلية الحفظ
الميزة الأخيرة لا تزال مرتبطة بـ UTXO وتعتمد على كيفية فهمنا لآلية قفل UTXO.
يمكن استخدام برنامج القفل لبرمجة شروط فتح الصندوق، وبالتالي يمكنه تنفيذ قواعد الحفظ. على سبيل المثال، إذا كان برنامج القفل يحتوي على مفتاح عام واحد فقط، فهذا يعني أن مالك المفتاح الخاص المقابل فقط يمكنه التحكم فيه. ومع ذلك، فإن قواعد الحفظ هذه هي أيضًا الأساس لبرمجة بروتوكول عقد البيتكوين. على سبيل المثال، يمكن لـ UTXO الذي يستخدم نص قفل متعدد التوقيع 2 من 2 أن يكون قناة سريعة؛ أثناء تشغيل القناة، يمكن للطرفين أن يدفعا لبعضهما البعض عددًا لا يحصى من المرات تقريبًا دون أي تغيير في النموذج الموجود على السلسلة موارد مالية. بمعنى آخر، في هذا الوقت، يشكل نص القفل متعدد التوقيع 2 من 2 آلية نقل القيمة التي تسمح لكلا الطرفين بنقل القيمة دون تغيير شكل الأموال في السلسلة.
يمكن استخدام مثل هذه الآلية لقيمة البيتكوين التي تحملها UTXO، وبطبيعة الحال، يمكن استخدامها أيضًا لأصول RGB التي تحملها. يمكننا إصدار أصل RGB وإرفاقه بـ 2 من 2 UTXO متعدد التوقيع، وبالتالي استخدام آلية قناة البرق لدفع هذا الأصل لبعضنا البعض لعدد غير محدود من المرات. وبنفس الطريقة، يمكن أيضًا إدخال أصول RGB في عقود أخرى بناءً على نصوص Bitcoin.
هنا، يشكل نص UTXO وبروتوكول RGB تمايزًا وظيفيًا: الأول ملتزم بتحقيق قواعد حفظ القيمة ونقل القيمة؛ بينما يركز الأخير على تعريف الأصول. وبالتالي، يمكن فصل حضانة الأصول وتعريف الأصول. يعد هذا تحسينًا أمنيًا مهمًا وهو شيء يسعى الناس لتحقيقه في بعض أنظمة العقود الأخرى الموجودة على السلسلة.
تصميم RGB مصنوع بالفعل
الخصائص المذكورة أعلاه صحيحة بالفعل بالنسبة لجميع البروتوكولات المستندة إلى ختم UTXO لمرة واحدة والتحقق من العميل. ولكن على هذا الأساس، تم تصميم بروتوكول RGB بشكل أكبر.
في التطوير الحالي لبروتوكول RGB، يهتم المطورون بشكل خاص بخصوصية البروتوكول، لذا فإن RGB يعزز الخصوصية في جانبين:
أعمى UTXO. في معاملة RGB، يحتاج المستلم فقط إلى استخدام معرف UTXO المبهم لاستلام الأصل دون الكشف عن خصائص UTXO التي استلمت الأصل بالفعل. وهذا لا يؤدي إلى إضعاف قدرة المستلم على تقديم الأدلة إلى المالك التالي، في حين يمكّن مستلمي الأصول اللاحقين من الدفاع عن أنفسهم ضد أعين المتطفلين لمالك الأصول السابق.
ضد الرصاص. يمكن استخدامها لإخفاء المبلغ المحدد في كل معاملة. ومع ذلك، لا يزال بإمكان مالكي الأصول اللاحقة التحقق من عدم حدوث أي إصدار إضافي من قبل.
الفضاء الذي سيتم استكشافه
في هذا القسم، سأناقش المساحة التي يمكن لبروتوكول RGB الاستمرار في استكشافها، والتي تتعلق بشكل أساسي بالقابلية للبرمجة.
في الوقت الحالي، تركز قوالب (مخطط) عقود RGB المقترحة على إصدار الأصول. ومع ذلك، بما أن RGB يستخدم نموذج "التحقق من جانب العميل"، فيمكننا في الواقع إضافة أي خصائص إليه يمكن ضمانها من خلال التحقق من جانب العميل - يقتصر فقط على بنية UTXO.
قيود
على أساس UTXO، يُطلق على المفهوم الذي يمكنه توسيع نطاق البرمجة اسم "العهود". الهدف الأصلي من شرط التقييد هو تحديد الوجهة التي يمكن تحويل مبلغ من المال إليها. وبهذه القدرة يمكننا برمجة العديد من التطبيقات المثيرة للاهتمام، مثل:
مجمع الأموال لعمليات السحب غير التفاعلية. يمكننا تجميع أموال العديد من الأشخاص في نفس UTXO واستخدام شروط التقييد للتأكد من أن أيًا منهم يمكنه سحب أمواله الخاصة دون مساعدة الآخرين. يمكن أن يكون لهذا تأثير في مساعدة الأشخاص على الخروج من الأماكن عالية الخطورة بتكلفة منخفضة عندما يكون الطلب على المساحات السكنية مرتفعًا.
عقد الخزنة. يجب أولاً إنفاق الأموال في مكان ما والخضوع لقفل زمني قبل أن يتم إنفاقها بحرية؛ خلال فترة القفل الزمني، يمكن لمالك الخزنة مقاطعة هذه العملية باستخدام مفتاح الطوارئ وتحويل الأموال على الفور إلى مكان آخر. يمكن أن يكون هذا الجهاز بمثابة مساعدة كبيرة للحضانة المستقلة.
لا يتمتع برنامج Bitcoin Script الحالي بهذه الإمكانية، لذا فإن تمكين القيود على برنامج Bitcoin Script يتطلب عملية شوكة ناعمة.
ومع ذلك، طالما أننا على استعداد للتضحية ببعض الفوائد التي يجلبها "التمايز بين تعريف الأصول وآليات الحفظ"، فيمكننا تجربة مثل هذه الميزات على أصول RGB. يمكننا تنفيذ مثل هذه الوظائف على مستوى عقد RGB - على الرغم من أنها يمكن أن تكون كذلك. فقط لا يعمل مع أصول RGB التي تستخدمه (وليس البيتكوين)، ولكنه سيفتح بالتأكيد مساحة مثيرة للاهتمام.
تُظهر الأبحاث الحالية حول شروط التقييد أنه يمكنها توسيع مساحة البرمجة للمعاملات المستندة إلى UTXO وتوفير العديد من الميزات. لكن هذه الدراسات تعتمد بشكل أساسي على البيتكوين، وعلى بروتوكولات مثل البيتكوين، سنكون أكثر تحفظًا. في RGB، يمكننا تعميم القدرة الأساسية لشروط التقييد بجرأة - القدرة على قراءة المعاملات التي تنفق نفسها على مستوى البرنامج النصي - لتوفير قابلية برمجة أكثر مرونة: القدرة على الوصول المتبادل إلى العقود.
الوصول المتقاطع
المصطلحات المقيدة بالحد الأدنى تعني أنه عند إنفاق UTXO، يمكن للبرنامج النصي الخاص به قراءة مخرجات معاملة الإنفاق. لكن القيد المعمم بالكامل يعني أنه يمكنه قراءة جميع أجزاء المعاملة التي أنفقها. وهذا يعني أنه يمكنه أيضًا قراءة المدخلات الأخرى للمعاملة، وإذا لم نحد من المدخلات الأخرى التي تأتي من نفس العقد، فهذا يعني أنه يمكنه قراءة حالة العقود الأخرى.
في RGB، نفترض أن كل عقد هو عالم مستقل له رسم بياني حلقي موجه خاص به. ومع ذلك، لا يزال من الممكن للمستخدم الاحتفاظ بحالة عقدين مختلفين في نفس الوقت. إذا سمحت معاملات RGB بالإنفاق المتزامن للأصول من كلا العقدين، فقد يكون لإمكانيات الوصول المتبادل هذه تطبيقات (على الرغم من أنها قد تجعل التحقق من المعاملات أكثر تعقيدًا).
في الواقع، توجد بالفعل أنظمة عقود على السلسلة تعتمد على هياكل UTXO المماثلة (على سبيل المثال: شبكة Nervos)، والتي تستخدم هذا لتحقيق إمكانات الوصول المتبادل للعقود. يعد هذا مجالًا جديدًا للغاية، وينفتح على مناطق نادرًا ما تطرقت إليها أبحاث البيتكوين السابقة، وقد تكون هناك بعض المفاجآت مدفونة هناك.
ختاماً
في هذه المقالة، سيجد القراء أن هناك مفهومًا يتم ذكره بشكل متكرر ويمر عبر جميع عمليات التفكير والخيال: "UTXO". هذا هو بالضبط نيتي. إذا كنت لا تفهم UTXO، فلن تتمكن من فهم نقطة البداية لتصميم بروتوكول مثل RGB، ولا يمكنك فهم مزايا تصميم بروتوكول RGB، ولا يمكنك تخيل الطريقة التي يستخدمها الناس. تتشكل خصائص بروتوكول RGB إلى حد كبير من خلال شكل UTXO المختوم لمرة واحدة. في المقابل، يمكن أيضًا تطبيق الأبحاث المتعلقة بـ UTXO المتراكمة في مجال أبحاث Bitcoin على الأبحاث المتعلقة بـ RGB.
وهذا ما يفسر أيضًا سبب صعوبة فهم الأشخاص الذين لا يفهمون عملة البيتكوين في فهم RGB. سوف يتعرف الأشخاص الذين يحبون Bitcoin على التصميم الذي صنعته RGB.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
افهم الإمكانات الحقيقية لبروتوكول إصدار الأصول RGB في مقال واحد
المؤلف: جيان
تحاول هذه المقالة تقديم وصف موجز لـ RGB، وهو بروتوكول لإصدار الأصول على Bitcoin (يمكن فهمه أيضًا على أنه نظام عقد ذكي خارج السلسلة)، وتشير إلى أنه يختلف تمامًا عن المشاريع الأخرى التي تهدف إلى لتحقيق نفس البروتوكولات الوظيفية أو ما شابهها، فإن هذه الاختلافات تجعل بروتوكول RGB أكثر قابلية للتوسع منها، وتترك مساحة برمجة أوسع. بالإضافة إلى تقديم تصميمات RGB الكاملة، سنستكشف أيضًا إمكانيات البرمجة هذه.
ما هو بروتوكول RGB؟
كانت فكرة إصدار الأصول على البيتكوين موجودة منذ فترة طويلة. لكن بروتوكول Bitcoin له خصائصه الخاصة: يتم التعبير عن حالته بواسطة Bitcoin UTXO فقط ("مخرجات المعاملة غير المنفقة")؛ يحمل UTXO فقط بياناتين: الفئة الخاصة به (قيمة البيتكوين)، و"المفتاح العام للبرنامج النصي" (أيضًا يُعرف باسم "نص القفل")، ويستخدم لبرمجة شروط الإنفاق لهذا الصندوق، على سبيل المثال: توفير توقيع لمفتاح عام معين؛ السماح بتحديد كود التشغيل المستخدم في برمجة نص القفل من خلال قواعد الإجماع الخاصة بالبيتكوين بشرط ألا تتمكن من ذلك استخدامها لتنفيذ قواعد أمنية تعسفية. لذلك، من المستحيل إنشاء أصول أخرى داخل UTXO - لا يمكن لبرنامج Bitcoin النصي برمجة عمليات التحقق الأمني لهذه الأصول. وهذا يعني أن جميع الأفكار المتعلقة بإصدار الأصول على البيتكوين هي في الأساس استخدامات إبداعية لمساحة كتلة البيتكوين. هذا يعني أننا بحاجة إلى تصميم نظام عقد ذكي خارج السلسلة ونطلب الخطوات اللازمة لتغيير حالة العقد - على سبيل المثال، يغير العقد "أ" المعلمات، وينقل "ب" مبلغًا معينًا من أصل معين إلى "ج" —— يتم تحميل المعلومات إلى blockchain، بحيث يمكن الحصول على أحدث حالة لنظام العقد الذكي من خلال جمع هذه المعلومات.
تتمثل فكرة التصميم التقريبية في تحميل معلومات الخطوات التي تغير حالة العقد إلى Bitcoin blockchain سليمة. من المؤكد أن هذا يعمل، لكنه يواجه عدة مشاكل:
(1) نظرًا لأن المعلومات الكاملة تم تحميلها، فقد تستهلك مساحة أكبر، وعندما يحتاج المستخدمون إلى تغيير حالة العقد (مثل النقل)، سيحتاجون أيضًا إلى دفع المزيد من رسوم المعالجة على السلسلة. على وجه الخصوص، عندما نأمل أن يتمتع نظام العقود خارج السلسلة هذا بقابلية برمجة أفضل من البيتكوين، فإن الزيادة في قابلية البرمجة قد تأتي على حساب استهلاك المزيد من مساحة الكتلة؛
(2) قد تؤدي أي معلومات موجودة في الكتلة تقريبًا إلى تغيير العقد الذكي خارج السلسلة، لذلك يجب على المستخدمين الحصول على جميع بيانات كتلة Bitcoin للحصول على أحدث حالة لنظام العقود خارج السلسلة، أي أن التحقق منها أكثر تكلفة؛
(3) اعتمادًا على تصميم نظام العقود الذكية خارج السلسلة، قد لا تتمكن إلا من الحصول على خصوصية مماثلة لتلك التي تتمتع بها Bitcoin، أو حتى أسوأ من ذلك؛ وإذا كان بإمكانك توفير المزيد من الخصوصية، فقد تحتاج إلى استهلاك المزيد من المساحة. مساحة الكتلة.
في الماضي، لم يكن البروتوكول المستخدم على نطاق واسع يسمى "Omni" يحمّل معلومات كاملة حول معاملات العقود خارج السلسلة، ولكن فقط قيمة التجزئة للمعاملة. يحل هذا النهج المشكلات المذكورة أعلاه ويفصل تعقيد معاملات العقود خارج السلسلة عن تكاليفها الاقتصادية؛ ومع ذلك، لا يزال المستخدمون بحاجة إلى الحصول على الكمية الكاملة من بيانات كتلة Bitcoin للحصول على أحدث حالة لبروتوكول Omni؛ بالإضافة إلى ذلك، فإنه لا غير مصممة خصيصًا لتعزيز الخصوصية.
يستخدم RGB نموذجًا جديدًا يسمى "الأختام ذات الاستخدام الواحد". استخدامه بسيط للغاية: يتطلب RGB أن كل حالة من كل عقد يجب أن تكون مرتبطة بـ Bitcoin UTXO معين، وبمجرد أن تريد تغيير هذه الحالة، يجب عليك إنفاق UTXO هذا والسماح للمعاملة التي تنفقه بالحصول على تأكيد على blockchain؛ بالإضافة إلى ذلك، يجب أن توفر معاملة Bitcoin التي تنفقها أيضًا تجزئة لمحتويات انتقال الحالة للإشارة إلى UTXO المرتبط بالحالة المتغيرة.
بالنسبة لمطوري RGB، التصميم مشابه لختم بلاستيكي مرقم: من السهل معرفة ما إذا تمت إزالته، وبمجرد إزالته، لا يمكن إعادة استخدامه. ومع ذلك، هناك منظور آخر وهو اعتبار UTXO المملوك بمثابة الحاوية أو الحصالة الخزفية في هذه الحالة - إذا كنت تريد إخراج الأموال الموجودة في الحصالة، فيجب عليك كسر الحصالة. ثم ضع الأموال بالداخل في الجرة الجديدة.
يتناقض هذا التصميم بشكل حاد مع البروتوكولات السابقة التي تعامل الكتلة بأكملها على أنها لوحة كتابة كبيرة: استخدام UTXO كحاوية يعني أن المعاملات التي لا تنفق هذا UTXO لا يمكن أن يكون لها أي تأثير على حالة العقد في الحاوية، لذلك، للتحقق حالة معينة لعقد معين، لا نحتاج إلى الحصول على بيانات جميع الكتل، كل ما نحتاجه هو سلسلة من معاملات البيتكوين، دليل على أن معاملات البيتكوين هذه موجودة في كتلة معينة، وهذه البتات تحويل حالة RGB الموعود بها يعد تبادل العملات (زوج واحد لواحد مع معاملة Bitcoin ذات الصلة) كافيًا. يجب أن تسمح لنا هذه البيانات، التي يمكن ربطها في سلسلة، بالرجوع إلى الحالة الأولية لهذا العقد، مما يسمح لنا بتحديد جوهر هذه الحالة.
بالنسبة للقراء الذين هم على دراية بأنظمة العقود الذكية على السلسلة (مثل Ethereum)، هناك شيء واحد يصعب فهمه حول هذه العملية وهو أنه إذا لم يعتمد على إجماع blockchain (مما يعني أن الحالة الأولية للشبكة العقد وسيتم التحقق من كل تغيير في الحالة بواسطة كل عقدة)، كيف يتم ضمان أمان نظام العقد الذكي هذا؟ كيف تتأكد من أن الأصول التي تتلقاها هي التي تريدها، وكيف تتأكد من أن الأصول لم يتم إصدارها بشكل غير قانوني؟
الإجابة أيضًا بسيطة للغاية، وتسمى "التحقق من جانب العميل" - حيث تقوم بالتحقق منها بنفسك. في نظام العقود على السلسلة، تتحقق العقد من كل عملية انتقال حالة وفقًا لقواعد انتقال الحالة العامة، وترفض العمليات غير الصالحة، ثم تحسب الحالة الأخيرة بناءً على الحالة الأولية. ومع ذلك، طالما أن قواعد انتقال الحالة والحالة الأولية معروفة، فإن التحقق من خلال الإجماع على السلسلة ليس هو الطريقة الوحيدة. يمكن للمستخدمين التحقق مما إذا كانت كل خطوة من خطوات انتقال الحالة تتبع انتقال الحالة المحدد في الأصل بناءً على المعلومات المقدمة من قبل the payer.rule. وبهذه الطريقة، يمكن للطرف المتحقق (المفترض أنه متلقي الأصل) أيضًا اكتشاف التحولات غير القانونية للدولة ورفض قبولها.
وأخيرا، نستخدم مثالا لتوضيح خصائص بروتوكول RGB:
الآن، تمتلك أليس UTXO A، الذي يحتفظ بوحدات X من الأصل Y الصادرة وفقًا لبروتوكول RGB. وهي تريد نقل وحدات Z من Y إلى Bob. مرت هذه المجموعة من الأصول بإجمالي 5 مالكين سابقين (بما في ذلك جهة إصدار الأصول) قبل أن تصل إلى يدي أليس. لذلك، تحتاج أليس إلى تزويد بوب بدليل على تحولات الحالة الأربع هذه (تم تقديم الثلاثة الأولى منها إلى أليس من قبل المالك السابق)، بما في ذلك الحالة الأولية للعقد وقواعد انتقال الحالة، والبتات المستخدمة لكل عملية نقل يتم إرسال معاملات البيتكوين ومعاملات RGB التي ترتكبها كل بورصة بيتكوين والدليل على أن معاملات البيتكوين هذه قد تم تأكيدها بواسطة كتلة معينة إلى بوب، وسيتحقق بوب من أن عمليات النقل الأربعة هذه لا تنتهك القواعد وفقًا لقواعد انتقال الحالة العقد، ثم تقرر قبوله أم لا. عندما تقوم أليس ببناء معاملة RGB، نظرًا لأن Z أصغر من X، يتعين عليها أيضًا ترتيب UTXO لنفسها لتلقي الجزء المتبقي. أخيرًا، تقوم أليس بتضمين قيمة التجزئة لمعاملة RGB هذه في معاملة Bitcoin التي تكلف UTXO A' لإكمال الدفع.
أخيرًا، نظرًا لاستخدام حاويات UTXO، يمكن تمثيل أحدث حالة لعقد RGB كنقطة على رسم بياني حلقي موجه ليس له فروع (تمثل كل نقطة حالة مخزنة في حاوية UTXO). علاوة على ذلك، بالنسبة للمالك P في الشكل أدناه، فلن يعرف العملية إلا من الحالة الأولية G للعقد للوصول إليه، أي العملية المميزة بالدائرة الحمراء، ولن يعرف شيئًا عن النقاط الرمادية:
#مزايا RGB
حالة خفيفة الوزن يمكن التحقق منها
كما ذكرنا سابقًا، بالمقارنة مع بروتوكولات إصدار الأصول السابقة (أنظمة العقود خارج السلسلة) التي ظهرت على Bitcoin، فإن RGB يقلل بشكل كبير من تكلفة التحقق (حالة معينة من العقد). أثناء المعاملة، لم يعد المتلقي بحاجة إلى اجتياز جميع الكتل لجمع معلومات حول التغييرات في حالة العقد، ولكنه يحتاج فقط إلى الحصول على سلسلة من معاملات البيتكوين، بالإضافة إلى معاملات RGB التي وعدت بها هذه البورصات، وكتل البيتكوين هذه تحتوي المعاملات على أدلة (استنادًا إلى أدلة Merkle الموجودة في رأس الكتلة)، يمكنك التأكد من أن الدافع يمتلك بالفعل مبلغًا معينًا من أصل معين.
كما أن هذا التخفيض في تكاليف التحقق يقلل بشكل كبير من اعتماد المستخدمين (ثقتهم) على كبار مقدمي البنية التحتية. في البروتوكولات السابقة، نظرًا لارتفاع تكلفة التحقق، كان من الصعب على المستخدمين حساب أحدث حالة للعقد بأنفسهم، لذلك كان على المستخدمين أن يثقوا في بعض مقدمي الخدمة (مثل مزود حالة العقد الذي تستخدمه محفظتهم الخاصة)؛ في في الوقت نفسه، لأنهم يستطيعون تحمل تكاليف ذلك، هناك عدد أقل من الموردين لحساب التكاليف، وهو ما يعني أيضًا مركزية الموردين. ولكن في RGB، يحتاج المستخدمون فقط إلى استخدام عميل Bitcoin Light للتحقق من جزء المعاملة باستخدام Bitcoin وبروتوكول RGB للتحقق من جزء معاملة RGB، ويمكنهم تحمل تكاليفه.
بالمقارنة مع بعض أنظمة العقود الموجودة على السلسلة، فإن RGB أخف أيضًا. ينعكس هذا في حقيقة أن RGB يمكنه التحقق على وجه التحديد من حالة معينة من العقد؛ في تلك الأنظمة التي لا تعتمد على UTXO، نظرًا لعدم وجود آلية للتحكم في الوصول مثل UTXO، فإن أي معاملة قد تغير أي حالة، لذلك يمكنك يكاد يكون من المستحيل التحقق من حالة معينة على وجه التحديد، ولكن يمكن فقط تحديد حالة معينة أثناء حساب جميع الحالات الأخيرة - وبهذا المعنى، فإن الخصائص المعبر عنها بـ "الدولة العالمية" يجب أن تسمى في الواقع "الدولة الموحدة". يوفر ميزة الوصول المتبادل بين العقود، كما أنه يحدد أيضًا أن تكلفة التحقق الخاصة به ستكون أعلى وسيكون الحصول على الثقة أكثر صعوبة.
في بروتوكولات العقود على السلسلة هذه، يتمثل أحد إجراءات التحسين الرئيسية في مطالبة رأس الكتلة بالالتزام بأحدث حالة ("جذر الحالة")، وبالتالي السماح للعملاء الخفيفين بالتحقق من حالة معينة من العقد الذي تم الحصول عليه من العقدة الكاملة بناءً على هذه الالتزامات.. هذه طريقة لإعادة استخدام الحسابات التي تم إجراؤها بالفعل (الحسابات التي تم إجراؤها بواسطة العقدة الكاملة)، وهي أيضًا فعالة جدًا، لذلك إذا لم يتم أخذ انعدام الثقة في الاعتبار، فيمكن اعتبارها أكثر كفاءة من RGB. ومع ذلك، فهذا يعني بعد كل شيء أن العقد الخفيفة تعتمد على العقد الكاملة للتحقق من المعاملة الأساسية وحساب حالة العقد. في محفظة RGB التي تستخدم عميل Bitcoin Light، فإن افتراض الثقة الذي تعتمد عليه هو أن معاملة Bitcoin ذات الصلة هي معاملة صالحة، وقد تم التحقق من الجزء المتعلق بحالة العقد شخصيًا من قبل العميل، لذلك فهو أكثر ثقة. مجاني . . العيب هو أن تأخير التحقق أطول ويجب الاحتفاظ بمزيد من البيانات.
قابلية التوسع
تنعكس قابلية التوسع في RGB في جانبين:
تعد قيمة التجزئة المضمنة في معاملة Bitcoin مجرد قيمة تجزئة، مما يعني أنه لا يوجد حد لحجم معاملة RGB (باستثناء القواعد المخصصة للعقد) - حتى إذا قمت بتقسيم أصل RGB واحد إلى 100 جزء (معاملة RGB ستكون كبيرة جدًا)، وهناك قيمة تجزئة واحدة فقط يجب تضمينها في معاملة Bitcoin. كما هو مذكور في الملاحظة 6، هناك طريقتان لتضمين قيمة التجزئة هذه: إحداهما هي استخدام إخراج OP_RETURN، مما يعني أنها ستستهلك المساحة الموجودة على السلسلة لقيمة التجزئة؛ والأخرى هي إخفاء الإخراج العام للبرنامج النصي في مفتاح Taproot - لا يستهلك هذا أي مساحة على السلسلة. وهذا يعني أيضًا أنه لا يتعين على المستخدمين التضحية بالاقتصاد من أجل قابلية البرمجة، مع الأخذ في الاعتبار فقط الرسوم الموجودة على السلسلة.
أحدث حالة لعقد RGB هي نقطة مستقلة على رسم بياني حلقي موجه بدون أي فروع - وهذا يعني أنه يمكن تغيير هذه الحالات بشكل مستقل دون التأثير على بعضها البعض، مما يعني السماح بالتزامن. هذه في الواقع ميزة موروثة من UTXO. وهذا يعني أيضًا أن التغييرات غير الصالحة (المعاملات غير الصالحة) التي تحدث في أحد الفروع لن تؤثر على الفروع الأخرى، ناهيك عن التسبب في توقف العقد بأكمله، لذلك يمكن اعتبارها أيضًا ميزة أمنية.
إحدى النقاط التي تم انتقاد RGB بسببها من حيث قابلية التوسع هي أن كل عملية نقل تتطلب من المستلم التحقق من جميع المعاملات المعنية من الحالة الأولية إلى حالة الدافع - مع زيادة عدد المرات التي يتم فيها تغيير الأصل، فإن عبء التحقق على المستلمين اللاحقين يزيد، وسوف يصبح أثقل وأثقل. وهذا النقد صحيح. وتحسين ذلك يعني أننا بحاجة أيضًا إلى إيجاد طريقة لإعادة استخدام العمليات التي حدثت بالفعل. تعد تقنيات نظام الإثبات مثل SNARKs بتوفير مثل هذا الحل.
التمييز بين تعريف الأصول وآلية الحفظ
الميزة الأخيرة لا تزال مرتبطة بـ UTXO وتعتمد على كيفية فهمنا لآلية قفل UTXO.
يمكن استخدام برنامج القفل لبرمجة شروط فتح الصندوق، وبالتالي يمكنه تنفيذ قواعد الحفظ. على سبيل المثال، إذا كان برنامج القفل يحتوي على مفتاح عام واحد فقط، فهذا يعني أن مالك المفتاح الخاص المقابل فقط يمكنه التحكم فيه. ومع ذلك، فإن قواعد الحفظ هذه هي أيضًا الأساس لبرمجة بروتوكول عقد البيتكوين. على سبيل المثال، يمكن لـ UTXO الذي يستخدم نص قفل متعدد التوقيع 2 من 2 أن يكون قناة سريعة؛ أثناء تشغيل القناة، يمكن للطرفين أن يدفعا لبعضهما البعض عددًا لا يحصى من المرات تقريبًا دون أي تغيير في النموذج الموجود على السلسلة موارد مالية. بمعنى آخر، في هذا الوقت، يشكل نص القفل متعدد التوقيع 2 من 2 آلية نقل القيمة التي تسمح لكلا الطرفين بنقل القيمة دون تغيير شكل الأموال في السلسلة.
يمكن استخدام مثل هذه الآلية لقيمة البيتكوين التي تحملها UTXO، وبطبيعة الحال، يمكن استخدامها أيضًا لأصول RGB التي تحملها. يمكننا إصدار أصل RGB وإرفاقه بـ 2 من 2 UTXO متعدد التوقيع، وبالتالي استخدام آلية قناة البرق لدفع هذا الأصل لبعضنا البعض لعدد غير محدود من المرات. وبنفس الطريقة، يمكن أيضًا إدخال أصول RGB في عقود أخرى بناءً على نصوص Bitcoin.
هنا، يشكل نص UTXO وبروتوكول RGB تمايزًا وظيفيًا: الأول ملتزم بتحقيق قواعد حفظ القيمة ونقل القيمة؛ بينما يركز الأخير على تعريف الأصول. وبالتالي، يمكن فصل حضانة الأصول وتعريف الأصول. يعد هذا تحسينًا أمنيًا مهمًا وهو شيء يسعى الناس لتحقيقه في بعض أنظمة العقود الأخرى الموجودة على السلسلة.
تصميم RGB مصنوع بالفعل
الخصائص المذكورة أعلاه صحيحة بالفعل بالنسبة لجميع البروتوكولات المستندة إلى ختم UTXO لمرة واحدة والتحقق من العميل. ولكن على هذا الأساس، تم تصميم بروتوكول RGB بشكل أكبر.
في التطوير الحالي لبروتوكول RGB، يهتم المطورون بشكل خاص بخصوصية البروتوكول، لذا فإن RGB يعزز الخصوصية في جانبين:
أعمى UTXO. في معاملة RGB، يحتاج المستلم فقط إلى استخدام معرف UTXO المبهم لاستلام الأصل دون الكشف عن خصائص UTXO التي استلمت الأصل بالفعل. وهذا لا يؤدي إلى إضعاف قدرة المستلم على تقديم الأدلة إلى المالك التالي، في حين يمكّن مستلمي الأصول اللاحقين من الدفاع عن أنفسهم ضد أعين المتطفلين لمالك الأصول السابق.
ضد الرصاص. يمكن استخدامها لإخفاء المبلغ المحدد في كل معاملة. ومع ذلك، لا يزال بإمكان مالكي الأصول اللاحقة التحقق من عدم حدوث أي إصدار إضافي من قبل.
الفضاء الذي سيتم استكشافه
في هذا القسم، سأناقش المساحة التي يمكن لبروتوكول RGB الاستمرار في استكشافها، والتي تتعلق بشكل أساسي بالقابلية للبرمجة.
في الوقت الحالي، تركز قوالب (مخطط) عقود RGB المقترحة على إصدار الأصول. ومع ذلك، بما أن RGB يستخدم نموذج "التحقق من جانب العميل"، فيمكننا في الواقع إضافة أي خصائص إليه يمكن ضمانها من خلال التحقق من جانب العميل - يقتصر فقط على بنية UTXO.
قيود
على أساس UTXO، يُطلق على المفهوم الذي يمكنه توسيع نطاق البرمجة اسم "العهود". الهدف الأصلي من شرط التقييد هو تحديد الوجهة التي يمكن تحويل مبلغ من المال إليها. وبهذه القدرة يمكننا برمجة العديد من التطبيقات المثيرة للاهتمام، مثل:
مجمع الأموال لعمليات السحب غير التفاعلية. يمكننا تجميع أموال العديد من الأشخاص في نفس UTXO واستخدام شروط التقييد للتأكد من أن أيًا منهم يمكنه سحب أمواله الخاصة دون مساعدة الآخرين. يمكن أن يكون لهذا تأثير في مساعدة الأشخاص على الخروج من الأماكن عالية الخطورة بتكلفة منخفضة عندما يكون الطلب على المساحات السكنية مرتفعًا.
عقد الخزنة. يجب أولاً إنفاق الأموال في مكان ما والخضوع لقفل زمني قبل أن يتم إنفاقها بحرية؛ خلال فترة القفل الزمني، يمكن لمالك الخزنة مقاطعة هذه العملية باستخدام مفتاح الطوارئ وتحويل الأموال على الفور إلى مكان آخر. يمكن أن يكون هذا الجهاز بمثابة مساعدة كبيرة للحضانة المستقلة.
لا يتمتع برنامج Bitcoin Script الحالي بهذه الإمكانية، لذا فإن تمكين القيود على برنامج Bitcoin Script يتطلب عملية شوكة ناعمة.
ومع ذلك، طالما أننا على استعداد للتضحية ببعض الفوائد التي يجلبها "التمايز بين تعريف الأصول وآليات الحفظ"، فيمكننا تجربة مثل هذه الميزات على أصول RGB. يمكننا تنفيذ مثل هذه الوظائف على مستوى عقد RGB - على الرغم من أنها يمكن أن تكون كذلك. فقط لا يعمل مع أصول RGB التي تستخدمه (وليس البيتكوين)، ولكنه سيفتح بالتأكيد مساحة مثيرة للاهتمام.
تُظهر الأبحاث الحالية حول شروط التقييد أنه يمكنها توسيع مساحة البرمجة للمعاملات المستندة إلى UTXO وتوفير العديد من الميزات. لكن هذه الدراسات تعتمد بشكل أساسي على البيتكوين، وعلى بروتوكولات مثل البيتكوين، سنكون أكثر تحفظًا. في RGB، يمكننا تعميم القدرة الأساسية لشروط التقييد بجرأة - القدرة على قراءة المعاملات التي تنفق نفسها على مستوى البرنامج النصي - لتوفير قابلية برمجة أكثر مرونة: القدرة على الوصول المتبادل إلى العقود.
الوصول المتقاطع
المصطلحات المقيدة بالحد الأدنى تعني أنه عند إنفاق UTXO، يمكن للبرنامج النصي الخاص به قراءة مخرجات معاملة الإنفاق. لكن القيد المعمم بالكامل يعني أنه يمكنه قراءة جميع أجزاء المعاملة التي أنفقها. وهذا يعني أنه يمكنه أيضًا قراءة المدخلات الأخرى للمعاملة، وإذا لم نحد من المدخلات الأخرى التي تأتي من نفس العقد، فهذا يعني أنه يمكنه قراءة حالة العقود الأخرى.
في RGB، نفترض أن كل عقد هو عالم مستقل له رسم بياني حلقي موجه خاص به. ومع ذلك، لا يزال من الممكن للمستخدم الاحتفاظ بحالة عقدين مختلفين في نفس الوقت. إذا سمحت معاملات RGB بالإنفاق المتزامن للأصول من كلا العقدين، فقد يكون لإمكانيات الوصول المتبادل هذه تطبيقات (على الرغم من أنها قد تجعل التحقق من المعاملات أكثر تعقيدًا).
في الواقع، توجد بالفعل أنظمة عقود على السلسلة تعتمد على هياكل UTXO المماثلة (على سبيل المثال: شبكة Nervos)، والتي تستخدم هذا لتحقيق إمكانات الوصول المتبادل للعقود. يعد هذا مجالًا جديدًا للغاية، وينفتح على مناطق نادرًا ما تطرقت إليها أبحاث البيتكوين السابقة، وقد تكون هناك بعض المفاجآت مدفونة هناك.
ختاماً
في هذه المقالة، سيجد القراء أن هناك مفهومًا يتم ذكره بشكل متكرر ويمر عبر جميع عمليات التفكير والخيال: "UTXO". هذا هو بالضبط نيتي. إذا كنت لا تفهم UTXO، فلن تتمكن من فهم نقطة البداية لتصميم بروتوكول مثل RGB، ولا يمكنك فهم مزايا تصميم بروتوكول RGB، ولا يمكنك تخيل الطريقة التي يستخدمها الناس. تتشكل خصائص بروتوكول RGB إلى حد كبير من خلال شكل UTXO المختوم لمرة واحدة. في المقابل، يمكن أيضًا تطبيق الأبحاث المتعلقة بـ UTXO المتراكمة في مجال أبحاث Bitcoin على الأبحاث المتعلقة بـ RGB.
وهذا ما يفسر أيضًا سبب صعوبة فهم الأشخاص الذين لا يفهمون عملة البيتكوين في فهم RGB. سوف يتعرف الأشخاص الذين يحبون Bitcoin على التصميم الذي صنعته RGB.