RGB++ وربط التماثل: كيف تعمل CKB وCardano وFuel على تمكين BTC

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

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

3. < /strong>توجد مساحة حالة مرتبطة بـ UTXO يمكنها تخزين حالة الأصول؛

4. يمكن أن تدعم تشغيل Bitcoin Light من خلال العقود الذكية أو وسائل أخرى. p>

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

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

لتبسيط الأمر، يستخدم الربط المتماثل UTXO في سلاسل CKB وCardano كـ "حاويات" للتعبير عن أصول UTXO مثل RGB، ثم يضيف قابلية البرمجة والمزيد من التعقيد إليها. سابقًا، نشر Geek web3 في "من BTC إلى Sui وADA وNervos: نموذج UTXO والتوسعات ذات الصلة < "لقد لخص /a>" سلسلة من سلاسل الكتل التي تدعم UTXO القابلة للبرمجة. ستستكشف هذه المقالة ما إذا كانت سلاسل الكتل هذه يمكنها التكيف مع مخطط الربط المتماثل.

RGB++ والربط المتماثل

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

في المقالة السابقة في "من RGB إلى RGB++: كيف يعمل CKB على تمكين بروتوكول الأصول البيئية للبيتكوين"، قمنا بإيجاز بترويج "الربط المتماثل" لـ RGB++. هنا سنقوم بذلك بسرعة المراجعة:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. يوجد جسر أو عقدة خفيفة مرتبطة بالبيتكوين؛

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

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

الوقود: مجموعة Ethereum OP استنادًا إلى UTXO

الوقود عبارة عن مجموعة Ethereum OP تعتمد على UTXO، أو مفهوم إثبات الاحتيال أ رائدة في تقديم النظام البيئي Ethereum Layer 2. لدعم وظيفة UTXO العادية، يتوافق Fuel بشكل أساسي مع BTC.

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

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

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

رسالة الإدخال:UTXO المستخدمة يستخدم لنقل المعلومات، ويتضمن بشكل أساسي حقولًا مثل مستلم المعلومات؛

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

عملة الإخراج : تُستخدم في عمليات نقل الأصول القياسية؛

عقد الإخراج : المخرج الناتج عن تفاعل العقد، والذي يحتوي على جذر الحالة بعد تفاعل العقد؛

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

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

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

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

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

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

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

Cardano: سلسلة eUTXO العامة القائمة على نقاط البيع

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

النص:  عقد ذكي، يُستخدم للتحقق مما إذا كان يمكن فتح UTXO وإجراء انتقالات الحالة؛

المخلصون: البيانات المقدمة من قبل المستخدم لفتح UTXO، وعادةً ما تكون بيانات التوقيع، المشابهة لـ Bitcoin's Witness؛

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

سياق المعاملة:   < /strong>البيانات السياقية لمعاملات UTXO، مثل معلمات الإدخال ونتائج المعاملة (يتم تنفيذ عملية حساب المعاملات لسلسلة UTXO مباشرة خارج السلسلة، ويتم إرسال نتائج الحساب إلى السلسلة للتحقق منها. إذا بعد اجتياز عملية التحقق، يتم تحميل نتائج المعاملة إلى chain.chain)

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

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

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

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

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

الملخص

يتطلب الارتباط المتماثل أن تتمتع السلسلة بالخصائص التالية:

1. استخدام نموذج UTXO

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

   < /li>

3. توجد مساحة حالة مرتبطة بـ UTXO يمكنها تخزين حالة الأصول

4. يمكنها دعم تشغيل عقد Bitcoin الخفيفة من خلال العقود الذكية أو غيرها يعني

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