إعادة توجيه العنوان الأصلي 'RGB++ والربط الإسومورفي: كيه سي بي، كاردانو وفيويل كيف يمكن أن يمنحوا بيئة بيتكوين القوة'

ملخص:· اقترح فريق CKB بروتوكول RGB++ للأصول الذين اقترح فريق CKB جوهر فكرة "الربط المتطابق" هو استخدام CKB وCardano وFuel وغيرها من البلوكشينات القائمة على نموذج البرمجة UTXO كطبقة توسع وظيفية تحمل "حاويات" الأصول RGB. يمكن تطبيق الربط المتطابق هذا أيضًا على بروتوكولات الأصول البيئية لبيتكوين ذات الخصائص UTXO مثل Atomical وRunes، مما يجعل من السهل بناء طبقة عقد ذكي خارج السلسلة لبيتكوين.

· في بروتوكول RGB++، لا يحتاج المستخدمون إلى تشغيل العميل للتحقق شخصيًا من بيانات المعاملات، ويمكنهم تسليم المهام مثل التحقق من صحة الأصول وتخزين البعد لسلاسل UTXO مثل CKB وCardano. طالما كنت "متفائلاً" وتعتقد أن أمان السلاسل العامة المذكورة أعلاه موثوق به نسبيًا، فلا حاجة للتحقق بنفسك؛

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

· إذا كانت تحت نظام عقد EVM ، فإن العديد من ميزات RGB++ ليست سهلة الدعم. بشكل عام ، يجب أن يكون لطبقة توسيع سلسلة / وظيفة عامة تناسب الربط المتطابق الإيزومورفي الخصائص التالية:

1. استخدم نموذج UTXO أو نظام تخزين الحالة المماثل؛

2. لديه قابلية برمجة UTXO كبيرة ، مما يسمح للمطورين بكتابة البرامج النصية لإلغاء القفل ؛

3. هناك مساحة حالة متعلقة بـ UTXO يمكن أن تخزن حالة الأصول؛

4. يمكنها دعم عمل عُقد البيتكوين الخفيفة من خلال العقود الذكية أو وسائل أخرى؛

· بالإضافة إلى CKB، يمكن أيضًا لـ Cardano و Fuel دعم الربط الإسومورفي. ومع ذلك، قد تكون لدى الأخيرتين بعض الأمتعة من حيث لغة العقد الذكي وتفاصيل تصميم العقد. في الوقت الحالي، يبدو أن CKB أكثر ملاءمة من الأخيرتين كطبقة توسيع وظيفية لبروتوكولات الأصول البيتكوين المتصلة إسومورفيًا.

في عام 2017، اقترح Cipher، المؤسس المشترك لـ Nervos CKB، فكرة المنتج للمرة الأولى. بالمقارنة مع حلول Bitcoin Layer 2 الأخرى، يمكن أن يكون الربط الإسومورفي أكثر توافقًا مع بروتوكولات الأصول مثل RGB، و Runes، و Atomical، ويمكن تجنب العوامل مثل الأصول العابرة التي تجلب أعباء أمنية إضافية.

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

RGB++ والربط الإيزومورفي

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

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

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

البروتوكول RGB غريب للغاية. من أجل تعزيز الخصوصية، يقوم ببساطة بحذف موافقة العقدة/العميل، وهو أمر تقليدي في عالم البلوكشين. يجب على المستخدمين تشغيل عميل RGB بأنفسهم واستقبال وتخزين "بيانات الأصول المتعلقة بهم" فقط. لا يمكنهم رؤية ما فعله الآخرون. على عكس إيثريوم وERC-20، حيث تكون جميع سجلات التحويل مرئية على السلسلة.

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

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

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

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

(مخطط تدفق تفاعل بروتوكول RGB)

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

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

استعراض العملية أعلاه، فمن غير الصعب أن نرى أن البيانات التي يتم استلامها وتخزينها من قبل عملاء RGB المختلفين غالباً ما تكون مستقلة، وغالباً ما لا تعرف ما هي الأصول التي يمتلكها الآخرون وكم هي. بالمقابل، لا يعرف الآخرون بشكل أساسي حالة أصولك.

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

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

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

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

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

(مخطط تدفق تفاعل بروتوكول RGB++ [النسخة القصيرة])

في المقالات السابقة"من RGB إلى RGB++: كيف يمنح CKB بروتوكول الأصول البيتكوين البيئية القوة", لقد قمنا بنشر شعبية بسيطة لل"ربط المتماثل" ل RGB++. هنا سنقوم بمراجعة سريعة:

تحتوي CKB على UTXO موسعة خاصة بها تُسمى Cell، والتي تُعتبر أكثر قابلية للبرمجة من UTXO على سلسلة BTC. الربط المتطابق يكون باستخدام Cell على سلسلة CKB كـ "حاوية" لبيانات RGB للأصول، وكتابة المعلمات الرئيسية للأصول RGB داخل الـ Cell.

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

على سبيل المثال، إذا كانت لدى أليس 100 رمز RGB و UTXO A على سلسلة البيتكوين، وكان لديها حصة في سلسلة CKB، يتم وضع علامة على هذه الحصة بـ "رصيد رمز RGB: 100"، وتكون شروط الفتح مرتبطة بـ UTXO A.

إذا أرادت آليس إرسال 30 رمزًا إلى بوب، يمكنها أولاً إنشاء تعهد. البيان المقابل هو: نقل 30 من رموز RGB المرتبطة بـ UTXO A إلى بوب، ونقل 70 إلى UTXOs أخرى تحكم فيها.

بعد ذلك ، تنفق أليس UTXO A على سلسلة Bitcoin ، وتنشر البيان أعلاه ، ثم تبدأ معاملة على سلسلة CKB لاستهلاك حاوية Cell التي تحمل 100 رمز RGB وإنشاء حاويتين جديدتين ، واحدة تحتوي على 30 رمزا (إلى بوب) ، والأخرى تحمل 70 رمزا (تسيطر عليها أليس). في هذه العملية ، يتم إكمال مهمة التحقق من صحة أصول أليس وصحة بيان المعاملة من خلال عقد شبكة CKB من خلال الإجماع ، دون تدخل بوب. يعمل CKB الآن كطبقة تحقق وطبقة DA ضمن سلسلة Bitcoin.

هذا يشبه الحقيقة التي في كل مرة يتغير فيها حالة عقد Ethereum ERC-20، لا يحتاج المستخدم إلى تشغيل التحقق من العميل. المبدأ مماثل. بروتوكول الإجماع وشبكة العقد تحل محل التحقق من العميل. علاوة على ذلك، يتم تخزين بيانات أصول RGB الخاصة بالجميع على سلسلة CKB، والتي يمكن التحقق منها على نطاق عالمي، مما يسهل تنفيذ سيناريوهات Defi، مثل حمامات السيولة وبروتوكولات الترهين الأصول.

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

بالطبع، إذا أراد شخص ما تشغيل عميل RGB++ بنفسه والتحقق من المصدر التاريخي لأصول الأشخاص الآخرين، فيمكنه التحقق مباشرة من التاريخ المتعلق بحاوية أصل RGB Cell على سلسلة CKB. طالما كنت تقوم بتشغيل عقدة CKB الخفيفة وتستلم دليل Merkle ورؤوس كتل CKB، يمكنك التأكد من أن البيانات التاريخية التي تتلقاها لم يتم تلاعبها من قبل المهاجمين الخبيثين في الشبكة. يمكن القول أن CKB يعمل كطبقة تخزين بيانات تاريخية هنا.

ببساطة ، ليس التزام الربط المتماثل مطبقاً فقط على RGB ، بل أيضًا على مختلف بروتوكولات الأصول التي تحمل سمات UTXO مثل Runes و Atomic ، حيث ينقل جميع حالات الأصول والبيانات التاريخية والعقود الذكية المقابلة المخزنة محليًا على جهاز العميل لمساحات البيانات العمومية ذات سمات UTXO مثل CKB أو Cardano للتخزين والاستضافة. يمكن لبروتوكول الأصول UTXO المذكور أعلاه استخدام نموذج UTXO لـ CKB أو Cardano كـ "حاوية" لعرض شكل وحالة الأصول. من السهل التعاون مع سيناريوهات مثل العقود الذكية.

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

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

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

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

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

في الختام، يجب أن تتمتع سلسلة عامة/طبقة توسيع الوظائف المناسبة لتحقيق الربط الإسومورفي بالخصائص التالية:

1. استخدم نموذج UTXO أو نظام تخزين الحالة المماثل؛
2. لديه قابلية برمجة UTXO كبيرة، مما يسمح للمطورين بكتابة النصوص الخاصة بإلغاء القفل؛
3. هناك مساحة حالة متعلقة بـ UTXO يمكن أن تخزن حالة الأصول؛
4. هناك جسور أو عقد ضوئية متعلقة بالبيتكوين؛

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

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

وقود: إثيريوم OP Rollup استنادًا إلى UTXO

Fuel هو Ethereum OP Rollup مستند إلى UTXO، وهو رائد في إدخال مفهوم دليل الاحتيال إلى نظام الطبقة 2 في Ethereum. بالنسبة لدعم وظيفة UTXO العادية، يكون Fuel متماشيًا تمامًا مع BTC.

يقسم الوقود UTXO الداخلية إلى الفئات الثلاث التالية:

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

عقد الإدخال: تحتوي UTXO المستخدمة لنداءات العقد على بيانات مثل جذر حالة العقد وأصول العقد؛

رسالة الإدخال: يحتوي UTXO المستخدم لنقل المعلومات بشكل رئيسي على حقول مثل مستلم المعلومات؛

عندما ينفق المستخدم UTXO، يتم إنتاج الإخراج التالي:

العملة الناتجة: لنقل الأصول القياسية؛

عقد الإخراج: الإخراج الذي تم إنشاؤه بواسطة تفاعل العقد داخلياً يحتوي على جذر الحالة بعد تفاعل العقد؛

تم إنشاء عقد الإخراج: UTXO الخاص هو الإخراج الذي يتم إنشاؤه عند إنشاء عقد، والذي يحتوي على معرف وجذر الحالة للعقد؛

على عكس الخلية CKB، التي تحتوي على جميع حالات العقد داخليًا، لا يحمل UTXO في Fuel في الواقع جميع حالات العقد ذات الصلة بالمعاملات. يحمل Fuel فقط جذر الحالة للعقد Stateroot في UTXO، والذي يعد جذر شجرة الحالة. يتم تخزين الحالة الكاملة للعقد داخل مكتبة حالة Fuel وتمتلكها العقد الذكي.

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

يمكننا أن نرى أن منطق كتابة عقد Sway مشابه لمنطق عقد Solidity العام. نعطي أولاً ABI للعقد، ثم متغيرات الحالة للعقد، ومن ثم التنفيذ الspecifi للعقد. جميع عمليات كتابة الشيفرة لا تشمل نظام UTXO لـ Fuel.

لذلك، تختلف تجربة برمجة عقود Fuel عن لغات برمجة UTXO مثل CKB وCardanao. يوفر Fuel تجربة أقرب إلى برمجة وتطوير عقود EVM الذكية. يمكن للمطورين أيضًا استخدام لغة Sway لإنشاء سكربتات فتح لتنفيذ منطق التحقق من خوارزمية التوقيع الخاصة أو منطق فتح متعدد التوقيع المعقد.

من الممكن تنفيذ الربط المتماثل بوقود، ولكن لا تزال هناك المشاكل التالية:

يتم استخدام لغة السوي من قبل Fuel أقرب إلى سلسلة EVM من حيث تصميم العقد الذكي منها إلى BTC أو CKB وCardano. يحتاج مُصدرو أصول UTXO مثل RGB وAtomics إلى إنشاء عقد ذكي بشكل محدد على Fuel. تستخدم CKB وسلاسل أخرى واحدة أخرى، وهو أمر معقد تماماً.

كاردانو: سلسلة عملات عامة eUTXO تعتمد على POS

كاردانو هي سلسلة كتل أخرى تستخدم نموذج UTXO، ولكن على عكس Fuel، فهي سلسلة عامة من الطبقة 1. يستخدم Cardano eUTXO (UTXO الموسع) للإشارة إلى نموذج برمجة UTXO في نظامه. بالمقارنة مع CKB، يحتوي eUTXO في Cardano على الهياكل التالية:

النص: يتم استخدام العقود الذكية للتحقق مما إذا كان بإمكان UTXO الفتح وأداء عمليات الانتقال الحالية؛

المُخلِصون: البيانات التي يقدمها المستخدمون لفتح UTXO عادة ما تكون بيانات توقيع، مشابهة لشهادة بيتكوين؛

المساحة الحالية للعقود الذكية يمكن أن تخزن البيانات مثل حالة الأصول؛

سياق المعاملة: بيانات سياقية لمعاملات UTXO، مثل المعلمات الداخلية ونتائج المعاملة (يتم أداء عملية حساب المعاملة لسلسلة UTXO مباشرة خارج السلسلة، وتُرسَل نتائج الحساب إلى السلسلة للتحقق. إذا نجحت عملية التحقق، يتم تحميل نتائج المعاملة إلى السلسلة)

يمكن للمطورين استخدام لغة PlutusCore لبرمجة UTXO على سلسلة Cardano. على غرار CKB، يمكن للمطورين كتابة السكربتات الخاصة بالفتح وبعض الوظائف لتحديثات الحالة.

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

لتنفيذ عملية المزاد أعلاه، يجب تخزين بعض الحالات في UTXO لعقد المزاد الذكي، مثل أعلى سعر للمزاد الحالي والشخص الذي قدم العرض. يُظهر الشكل أدناه بيان الحالة داخل PlutusCore. يمكننا رؤية أن bBidder وbAmount يعرضان العرض في المزاد وعنوان المحفظة التي قدمت العرض. تحتوي Auction Params على المعلومات الأساسية للمزاد.

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

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

تلخيص

الربط المتطابق يتطلب أن تحتوي السلسلة على الخصائص التالية:

1. استخدم نموذج UTXO
2. لديها إمكانية برمجة UTXO كبيرة، مما يتيح للمطورين كتابة سكربتات فتح
3. هناك مساحة حالة مرتبطة بـ UTXO يمكن أن تخزن حالة الأصول
4. يمكنه دعم تشغيل عقد ذكي أو وسائل أخرى لعقد العملة البيتكوين الخفيفة.

نظرًا لتفرد أفكار برمجة العقد الذكي الخاصة به، يتوافق Fuel مع الربط الإيزومورفي، ولكنه لا يزال يحمل بعض الأمتعة؛ بينما يستخدم Cardaon لغة برمجة Haskell لبرمجة العقود، مما يجعل الأمر صعبًا على معظم المطورين بدء العمل بسرعة. استنادًا إلى الأسباب المذكورة أعلاه، يمكن أن يكون CKB، الذي يعتمد مجموعة تعليمات RISC-V والأكثر توازنًا في خصائص برمجة UTXO، طبقة توسيع وظيفية أكثر ملاءمة للربط الإيزومورفي.

إخلاء المسؤولية:

1. تمت إعادة طبع هذه المقالة من [ويب3 المتطرف]. إعادة توجيه العنوان الأصلي 'RGB++ والربط المتجانس: كيوكيو، كاردانو والوقود كيف يعززون البيتكوين البيئي. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [شو]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، يرجى التواصل مع بوابة تعلمالفريق، وسوف يتعاملون معه على الفور.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالات إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو نسخ المقالات المترجمة ممنوع.