سوف تعزز الجسور التفاعل عبر السلاسل

لسنوات ، كان التفاعل عبر السلاسل أحد أكثر المشكلات حدة التي تواجه فضاء blockchain. في سلاسل الكتل المختلفة ، يتم استخدام أصول مختلفة . مثل WAVES on Waves و ETH و USDT (ERC-20) على Ethereum أو BNB و USDT (BEP-20) BNB Chain.

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

بناء بروتوكول تفاعل عبر السلاسل يتسم بالشفافية واللامركزية

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

يجب أن يفي بروتوكول من هذا النوع بمجموعة من المتطلبات:

١. عقود التعليمات البرمجية مفتوحة المصدر .
٢. درجة عالية من الأمان والموثوقية لوسائل الكريبتو المستخدمة .
٣. رسوم منخفضة
٤. الشفافية وإمكانية التدقيق .
٥. حوكمة البروتوكول اللامركزية عبر DAO ؛
٦. استخدام العقود الذكية للتحكم في منطق الأعمال وضمانات ثباتها ؛
٧. قابلية تطوير النظام
٨. تكامل البروتوكول مع المنتجات الأخرى (AMM ، بروتوكولات الإقراض ، DEXes إلخ) ؛
٩. التقليل إلى الحد الأدنى واللامركزية في الخدمات الخلفية.

بروتوكول التفاعل عبر السلاسل: العملية

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

من الأفضل شرح تشغيل بروتوكول من هذا النوع باستخدام مثال بسيط.

لنفترض أن المستخدم يحتاج إلى تحويل توكنز USDT (ERC-20) من Ethereum إلى BNB Chain. لهذا الغرض ، سيتم قفل التوكنز التي يحتاج المستخدم لنقلها على Ethereum وسيتم إصدارها في نموذج “ملفوف” على سلسلة BNB. سوف تمثل التوكنز المغلفة التزامًا للمستخدم لتلقي أصول BEP-20 المكافئة على سلسلة BNB. في عملية النقل مرة أخرى إلى Ethereum ، سيتم حرق التوكنز المغلفة في BNB Chain ، وسيتم إلغاء قفل التوكنز المميزة الأصلية على Ethereum.

الميزة الرئيسية لهذا النظام هي إمكانية التحقق منه. يمكن لأي مستخدم التأكد من أن مقدار التوكنز المغلفة في الشبكة المستهدفة هو نفس مقدار التوكنز “الحقيقية” المقفلة في الشبكة الأصلية.

إلى جانب ذلك ، هناك ميزة ملحوظة تتمثل في حقيقة أن العقود الذكية لها كود مفتوح المصدر وستحكم من خلال DAO . بينما يمكن تشغيل وحدات البرنامج (Witness-proxy ، Relayer) من قبل أي شخص.

تنفيذ البروتوكول

عندما يتعلق الأمر بتنفيذ البروتوكول . فإن المهمة الرئيسية هي بناء آلية للتفاعل عبر السلاسل بناءً على شبكة من العقود الذكية. نظرًا لأن استدعاء عقد ذكي في blockchain واحد من blockchain آخر أمر مستحيل ، فسيتعين استخدام oracles.

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

عناصر

يستدعي المتصل حدث إتمام معاملة يتلقاها Witness-proxy.

يقوم Executor بتنفيذ استدعاء يقوم إما بإنشاء توكنز مغلفة جديدة أو فتح التوكنز الأصلية.

يقر وكيل الشاهد (مكون خارج السلسلة) بحدث تم استدعاؤه بواسطة Caller وينقل بياناته إلى blockchain الهدف.

يتحقق الشاهد (المكون خارج السلسلة) من صحة المعلومات المنقولة بواسطة Witness-proxy ويتلقى مكافأة في توكن الأداة المساعدة بعد التأكيد الناجح للحدث.

المُوقِّع (مكوِّن خارج السلسلة) هو عنصر من مجموعة وحدات البرامج المستخدمة للتحقق من صحة المعلومات حول المعاملة المنفذة من خلال الجزء الخاص بها من التوقيع بعد تأكيدها من قبل العديد من الشهود.

بمجرد تحقيق النصاب القانوني للتوقيعات . ستتم كتابتها جميعًا في blockchain (blockchain للنقل هو Waves). سيتم نشر الحدث في عقد Witness الذكي حيث يتم أيضًا تخزين معلومات التأكيد. في العقد الذكي الموقّع ، سيتم نشر التوقيعات لتأكيد الأحداث المبكرة.

يمكن لمكون Relayer (خارج السلسلة) استدعاء Executor للمستخدم وتحصيل رسوم مقابل ذلك. بدلاً من ذلك ، يمكن للمستخدمين القيام بذلك بأنفسهم.

مخطط تفاعل المكونات

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

بعد ذلك ، يستدعي المستخدم أو Relayer Executor . الذي يصدر كمية محددة من التوكن المغلف ويرسله إلى جهاز الاستقبال. بعد ذلك ، يتم تشغيل عقد Bridge الذكي . مما يؤدي إلى إصدار كمية محددة من التوكن المغلف. بدلاً من ذلك ، يتم نسخ التوكن الملفوف ويتم إلغاء تأمين التوكن “الحقيقي” في الشبكة الأصلية.

تستند هذه الفكرة إلى السعي لتحقيق استدعاء عقد ذكي بواسطة بروتوكول في blockchain آخر.

وفي الوقت نفسه ، بالنسبة للمستخدم ، سيكون للواجهة مظهر بسيط للغاية. تمامًا مثل مقايضات التوكن . سيكون هناك الحقلين “إرسال” و “استلام” ، بالإضافة إلى العديد من الرسوم: رسوم المعاملة ، ورسوم الترحيل ، ورسوم البروتوكول.

أفكار ختامية

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