ما هي الإمكانات الحقيقية لبروتوكول إصدار الأصول BTC RGB؟

** المؤلف ****|****أ جيان **

الرابط الأصلي:

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

ما هو بروتوكول RGB؟

كانت فكرة إصدار الأصول على BTC موجودة منذ فترة طويلة. ومع ذلك ، فإن BTC البروتوكول له خصائصه الخاصة: يتم التعبير عن حالته بواسطة وفقط من خلال BTC UTXOs (“مخرجات المعاملات غير المنفقة”) ، ويحمل UTXO قطعتين فقط من البيانات: فئته الخاصة (القيمة BTC) ، و “المفتاح العام للبرنامج النصي” (المعروف أيضا باسم “البرنامج النصي للقفل”) الذي يستخدم لبرمجة الشروط التي يتم بموجبها إنفاق الأموال ، مثل توفير توقيع لمفتاح عام ، ويتم توفير رموز التشغيل التي تسمح ببرمجة نص القفل من خلال قواعد الإجماع الخاصة ب BTC ، والتي لا يمكن استخدامها لتنفيذ قواعد الأمان التعسفية. نتيجة لذلك ، لا يمكن إنشاء أصول أخرى داخل UTXO - لا يمكن للنصوص البرمجية BTC برمجة فحوصات الأمان لهذه الأصول. هذا يعني أن كل فكرة إصدار الأصول على BTC هي في الأساس استخدام إبداعي لمساحة الكتلة BTC. هذا يعني أننا بحاجة إلى تصميم نظام عقد ذكي خارج السلسلة ونطلب أن يتم تحميل المعلومات حول الخطوات التي تغير حالة العقد - على سبيل المثال ، يغير العقد A المعلمات ، B ينقل كمية معينة من الأصل إلى C - إلى blockchain ، بحيث يمكن الحصول على أحدث حالة لنظام العقد الذكي من خلال جمع هذه المعلومات.

تتمثل فكرة التصميم الخام في تحميل معلومات الخطوات التي تغير حالة العقد إلى BTC blockchain سليمة. بالطبع ، يمكن أن ينجح هذا ، ومع ذلك ، سيواجه العديد من المشكلات: (1) بسبب تحميل المعلومات الكاملة ، قد يستهلك مساحة أكبر ، وعندما يحتاج المستخدمون إلى تغيير حالة العقد (مثل التحويلات) ، سيحتاجون أيضا إلى دفع المزيد من الرسوم على السلسلة. على وجه الخصوص ، عندما نريد أن يتمتع نظام العقود خارج السلسلة بقابلية برمجة أفضل من BTC ، فقد تأتي الزيادة في قابلية البرمجة على حساب استهلاك مساحة أكبر من الكتلة: (2) المعلومات في أي مكان تقريبا في الكتلة لديها القدرة على تغيير العقد الذكي خارج السلسلة ، لذلك يجب على المستخدم الحصول على جميع بيانات الكتلة BTC من أجل الحصول على أحدث حالة لنظام العقود خارج السلسلة ، أي أنه أكثر تكلفة للتحقق ، (3) اعتمادا على تصميم نظام العقد الذكي خارج السلسلة ، قد يحصل فقط على نفس الخصوصية أو حتى أسوأ من BTC ، وإذا كان بإمكانه توفير المزيد من الخصوصية ، فقد يحتاج إلى استهلاك مساحة كتلة أكبر。

في الماضي ، لم يقم بروتوكول مستخدم بكثافة يسمى “Omni” بتحميل المعلومات الكاملة لمعاملات العقود خارج السلسلة ، فقط تجزئة المعاملة. يحل هذا النهج المشكلة المذكورة أعلاه 1 عن طريق فصل تعقيد معاملات العقود خارج السلسلة عن تكاليفها الاقتصادية ، ولكن لا يزال المستخدمون بحاجة إلى الحصول على الكمية الكاملة من بيانات الكتلة BTC للحصول على أحدث حالة لبروتوكول Omni ، ولا يعزز الخصوصية على وجه التحديد.

من ناحية أخرى ، يستخدم RGB نموذجا جديدا يسمى “الأختام ذات الاستخدام الواحد”. الطريقة التي تعمل بها بسيطة: تتطلب RGB إرفاق كل حالة من كل عقد ب UTXO BTC ، وبمجرد تغيير هذه الحالة ، يجب إنفاق UTXO بحيث يتم تأكيد المعاملة التي أنفقتها بواسطة blockchain ، ويجب أن توفر المعاملة BTC التي تنفقها أيضا تجزئة لانتقال الحالة للإشارة إلى UTXO التي ترتبط بها الحالة المتغيرة.

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

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

بالنسبة للقراء الذين هم على دراية بأنظمة العقود الذكية على السلسلة (مثل ETH Fang) ، فإن أحد الأشياء التي يصعب فهمها حول هذه العملية هو أنه إذا لم تعتمد على إجماع blockchain (مما يعني أنه سيتم التحقق من الحالة الأولية للعقد وكل تغيير في الحالة بواسطة كل عقدة) ، وكيفية التأكد من ضمان أمان نظام العقد الذكي هذا ، وكيفية التأكد من أن الأصول التي تتلقاها هي النوع الذي تريده ، وكيفية التأكد من عدم إصدار الأصول بشكل غير قانوني؟

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

أخيرا ، دعنا نستخدم مثالا لتوضيح خصائص بروتوكول RGB:

الآن ، تمتلك أليس UTXO A '، التي تحتفظ بالأصول Y من وحدات X الصادرة بموجب ترخيص RGB ، وتريد نقل وحدات Z من Y إلى Bob. استغرق الأمر ما مجموعه 5 مالكين سابقين (بما في ذلك المصدر) للأصول للوصول إلى أليس. لذلك ، تريد أليس تزويد بوب بدليل على انتقالات الحالة الأربعة هذه (تم تقديم أول 3 منها إلى أليس من قبل المالك السابق) ، بما في ذلك الحالة الأولية للعقد وقواعد انتقال الحالة ، والمعاملات BTC المستخدمة لكل عملية نقل ، وكل معاملة RGB ملتزم بها BTC البورصة ، والدليل على أن هذه المعاملات BTC قد تم تأكيدها بواسطة كتلة ، وإرسالها إلى بوب ، الذي سيتحقق من هذه ال 4 وفقا لقواعد انتقال الحالة للعقد نقل دون خرق القواعد ، ثم تقرر ما إذا كنت ستقبلها أم لا. عندما تنشئ أليس معاملة RGB ، نظرا لأن Z أقل من X ، فإنها ترتب أيضا UTXO لنفسها لتلقي الباقي. أخيرا ، تقوم Alice بتضمين تجزئة معاملة RGB في المعاملة BTC التي تكلف UTXO A لإكمال الدفع.

في النهاية ، بفضل استخدام حاويات UTXO ، يمكن تمثيل أحدث حالة لعقد RGB كنقطة على رسم بياني دوري موجه ليس له أحفاد حتى الآن (تمثل كل نقطة حالة مخزنة داخل حاوية UTXO). وبالنسبة للمالك P في الرسم البياني أدناه ، لن يعرف العملية إلا من الحالة الأولية G للعقد إليه ، وهي العملية المحاطة بدائرة باللون الأحمر ، ولن يعرف أي شيء عن النقاط الرمادية:

**مزايا RGB **

حالة رائعة يمكن التحقق منها

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

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

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

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

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

قابلية التوسع في RGB ذات شقين:

1. يتم تضمين تجزئة واحدة فقط في BTC معاملة ، مما يعني أنه لا يوجد حد لحجم معاملة RGB (بخلاف القواعد المخصصة بموجب العقد) - حتى إذا قمت بتقسيم أصل RGB واحد إلى 100 (ستكون معاملة RGB نفسها كبيرة جدا) ، هناك تجزئة واحدة فقط يجب تضمينها في BTC المعاملة. كما هو مذكور في الملاحظة 6 ، هناك طريقتان لتضمين مثل هذه التجزئة: إما باستخدام إخراج OP_RETURN ، مما يعني أنه يستهلك تجزئة واحدة من المساحة على السلسلة ، أو عن طريق إخفائها في شجرة البرنامج النصي التي وعد بها المفتاح العام للبرنامج النصي لإخراج Taproot - والذي لا يستهلك أي مساحة على السلسلة. هذا يعني أيضا أن المستخدمين لا يضطرون إلى التضحية بالاقتصاد من أجل قابلية البرمجة - فقط الرسوم على السلسلة.

2. أحدث حالة لعقد RGB هي نقطة مستقلة على رسم بياني دوري موجه بدون أحفاد - وهذا يعني أنه يمكن تغيير هذه الحالات بشكل مستقل دون التأثير على بعضها البعض ، أي أن التزامن مسموح به. هذه في الواقع ميزة موروثة من UTXO أيضا. وهذا يعني أيضا أن التغييرات غير الصالحة (المعاملات غير الصالحة) التي تحدث في أحد الفروع لن تؤثر على الفروع الأخرى ، ناهيك عن التسبب في تجميد العقد بأكمله ، لذلك يمكن اعتباره أيضا ميزة أمنية.

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

المفاضلة بين تعريف الأصول وآلية البيان الجمركي

لا تزال الفائدة الأخيرة مرتبطة ب UTXOs ، اعتمادا على كيفية فهمنا لآلية البرمجة النصية لقفل UTXO.

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

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

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

** تم تصميم RGB **

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

في التطوير الحالي لبروتوكول RGB ، يهتم المطورون بشكل خاص بخصوصية البروتوكول ، لذلك يعزز RGB الخصوصية بطريقتين:

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

** مساحة قابلة للاستكشاف **

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

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

القيود

علاوة على UTXOs ، يطلق على المفهوم الذي يوسع قابلية البرمجة “العهود”. القصد الأصلي من شرط التقييد هو تحديد الوجهة التي يمكن فيها تحويل مبلغ من المال. مع هذه القدرة ، يمكننا برمجة العديد من التطبيقات المثيرة للاهتمام ، مثل:

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

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

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

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

**الوصول المتقاطع **

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

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

في الواقع ، هناك بالفعل أنظمة عقود على السلسلة تعتمد على هياكل شبيهة ب UTXO (على سبيل المثال ، شبكة Nervos) تستخدم هذا لتحقيق قدرات الوصول المتبادل للعقود 11. هذا مجال جديد للغاية ، ينفتح على المناطق التي نادرا ما تأثرت بها الدراسات BTC السابقة ، وقد تكون هناك بعض المفاجآت المدفونة فيه.

خاتمة

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

وهذا يفسر أيضا لماذا سيواجه الأشخاص الذين لا يفهمون BTC صعوبة في فهم RGB. وأولئك الذين يحبون BTC سوف يتعرفون على التصميمات التي صنعتها RGB بالفعل.