تعد السلسلة المتعددة هي اتجاه التطوير المستقبلي ، وقد أدى السعي وراء قابلية التوسع إلى قيام Ethereum ببناء تقنية Rollup. في الانتقال إلى سلاسل الكتل المعيارية ، تم الاهتمام مرة أخرى بـ Lisk. وفي المستقبل غير البعيد ، نسمع شائعات حول التراكميات الخاصة بالتطبيقات ، و L3s ، والسلاسل السيادية. لكن كل هذا سيأتي على حساب التجزئة ، وغالبًا ما تكون الجسور الحالية عبر السلاسل محدودة في الوظائف وتعتمد على الموقِّعين الموثوق بهم للأمن.
إذن ، كيف سيبدو Web3 المتصل في النهاية؟ نعتقد أن الجسور عبر السلاسل سوف تتطور في النهاية إلى بروتوكولات للرسائل عبر السلاسل أو بروتوكولات "المراسلة التعسفية" (AMP) لفتح سيناريوهات جديدة للتطبيق ، مما يسمح للتطبيقات بتمرير رسائل عشوائية بين سلسلة المصدر والسلسلة المستهدفة. سنشهد أيضًا ظهور "مشهد آلية الثقة" ، حيث سيجري البناة العديد من المفاضلات بين سهولة الاستخدام والتعقيد والأمان.
يحتاج كل حل من حلول AMP إلى تنفيذ وظيفتين رئيسيتين:
التحقق: القدرة على التحقق من صحة الرسائل من سلسلة المصدر على السلسلة المستهدفة
الحياة: القدرة على تمرير المعلومات من سلسلة المصدر إلى السلسلة المستهدفة
لسوء الحظ ، فإن التحقق غير الموثوق به بنسبة 100٪ ليس واقعيًا ، يجب على المستخدمين اختيار الثقة في الكود أو نظرية اللعبة أو البشر (أو الكيانات) أو مزيج من هذه ، اعتمادًا على ما إذا كان التحقق على السلسلة أو خارج السلسلة.
في هذه الورقة ، نقسم عموديًا مجال التشغيل البيني الشامل إلى آليات قائمة على الثقة وبنيات قائمة على التكامل.
آلية الثقة:
رمز الثقة والرياضيات: بالنسبة لهذه الحلول ، يوجد دليل على السلسلة يمكن لأي شخص التحقق منه. تعتمد هذه الحلول عادةً على العملاء الخفيفين للتحقق من إجماع سلسلة المصدر على السلسلة المستهدفة أو التحقق من صحة انتقال الحالة لسلسلة المصدر إلى السلسلة المستهدفة. يمكن أن يؤدي التحقق من خلال العملاء الخفيفين إلى تحسين الكفاءة من خلال البراهين الصفرية المعرفة ، وضغط الحسابات الطويلة بشكل تعسفي ليتم إجراؤها في وضع عدم الاتصال ، مع توفير تحقق بسيط على السلسلة لإثبات نتائج الحساب.
Trust Game Theory: عندما يحتاج المستخدم / التطبيق إلى الوثوق بطرف ثالث أو شبكة طرف ثالث لضمان مصداقية المعاملة ، يتم تضمين افتراضات ثقة إضافية. يمكن تحسين أمان هذه الآليات من خلال استخدام الشبكات غير المرخصة ونظرية الألعاب مثل الحوافز الاقتصادية والأمن المتفائل.
الثقة في البشر: تعتمد هذه الحلول على صدق أو استقلالية غالبية المدققين الذين ينقلون معلومات مختلفة. بالإضافة إلى الوثوق بإجماع السلسلتين التفاعليتين ، تحتاج أيضًا إلى الوثوق بطرف ثالث. في هذه الحالة ، فإن الخطر الوحيد هو سمعة الكيانات المشاركة. تعتبر المعاملة صالحة إذا وافق عدد كافٍ من الكيانات المشاركة على أنها صالحة.
تجدر الإشارة إلى أن جميع الحلول تتطلب الثقة في الكود والبشر إلى حد ما. يمكن للمخترقين استغلال أي حل برمز عربات التي تجرها الدواب ، ولكل حل بعض العناصر البشرية في إعداد قاعدة التعليمات البرمجية أو ترقيتها أو صيانتها.
العمارة المتكاملة:
نموذج من نقطة إلى نقطة: يجب إنشاء قناة اتصال مخصصة بين كل سلسلة مصدر وسلسلة مستهدفة.
نموذج المحور المركزي: يجب إنشاء قناة اتصال مع المحور المركزي لتحقيق الترابط مع جميع سلاسل الكتل الأخرى المتصلة بالمحور.
من الصعب نسبيًا قياس نموذج نظير إلى نظير لأن كل blockchain متصل يتطلب قناة اتصال مقترنة. قد يكون تطوير هذه القنوات تحديًا للكتل ذات الإجماع والأطر المختلفة. ومع ذلك ، توفر الجسور المقترنة مزيدًا من المرونة لتخصيص التكوين إذا رغبت في ذلك. المناهج الهجينة ممكنة أيضًا ، مثل التوجيه متعدد القفزات من خلال المرحلات باستخدام بروتوكول Inter-Blockchain Communication (IBC) ، والذي يلغي الحاجة إلى الاتصال المباشر من نظير إلى نظير ، ولكنه يقدم المزيد من التعقيدات من حيث الأمان ووقت الاستجابة و يكلف.
كود الثقة والرياضيات
من أجل الاعتماد فقط على الكود / الرياضيات لافتراضات الثقة ، يمكن استخدام العملاء الخفيفين للتحقق من إجماع سلسلة المصدر على السلسلة المستهدفة. العملاء / العقد الخفيفة هي برامج تتصل بالعقد الكاملة للتفاعل مع blockchain. عادةً ما يقوم العملاء الخفيفون في السلسلة المستهدفة بتخزين محفوظات (بالترتيب) لرؤوس كتل سلسلة المصدر ، وهو ما يكفي للتحقق من المعاملات. يقوم الوكيل خارج السلسلة (مثل المرحل) بمراقبة الأحداث على سلسلة المصدر ، وإنشاء أدلة تشفير للتضمين ، وإعادة توجيهها جنبًا إلى جنب مع رؤوس الكتلة لإضاءة العملاء في السلسلة المستهدفة. نظرًا لأن العملاء الخفيفين يقومون بتخزين رؤوس الكتل بالتتابع ، كل منها يحتوي على تجزئة جذر Merkle التي يمكن استخدامها لإثبات الحالة ، فإنهم قادرون على التحقق من المعاملات. فيما يلي نظرة عامة على الميزات الرئيسية لهذا النهج:
أمان
يتم تقديم افتراضات الثقة أثناء تهيئة العملاء الخفيفين. عند إنشاء عميل light جديد ، سيتم تهيئته إلى رأس كتلة من ارتفاع معين في السلسلة الأخرى. ومع ذلك ، هناك احتمال أن تكون رؤوس الكتل المقدمة غير صحيحة ، مما يجعل من الممكن خداع العملاء الخفيفين باستخدام رؤوس الكتل المزورة. بمجرد تهيئة عميل خفيف ، لا يتم تقديم أي افتراضات ثقة أخرى. ومع ذلك ، تجدر الإشارة إلى أن عملية التهيئة هذه تعتمد على افتراض ثقة ضعيف ، حيث يمكن لأي شخص التحقق منه. بالإضافة إلى ذلك ، هناك افتراض حيوي لنقل المعلومات المستمر للترحيل.
ينفذ
يعتمد تنفيذ العملاء الخفيفين على توفر أساسيات التشفير المطلوبة للمصادقة. إذا تم توصيل نفس النوع من السلاسل ، مما يعني أنها تشترك في نفس إطار عمل التطبيق وخوارزمية الإجماع ، فستكون تطبيقات العميل الخفيف في كلا الطرفين هي نفسها. على سبيل المثال ، تستخدم جميع السلاسل المستندة إلى Cosmos SDK بروتوكول Inter-Blockchain Communication (IBC). من ناحية أخرى ، تعتمد التطبيقات مثل العملاء الخفيفين على دعم أساسيات التشفير المطلوبة للمصادقة. إذا تم توصيل نفس النوع من السلاسل ، أي أنها تشترك في نفس إطار عمل التطبيق وخوارزمية الإجماع ، فستكون تطبيقات العميل الخفيفة على كلا الجانبين هي نفسها. على سبيل المثال ، يتم استخدام بروتوكول Inter-Blockchain Communication (IBC) لجميع السلاسل المستندة إلى Cosmos SDK. من ناحية أخرى ، إذا تم توصيل نوعين مختلفين من السلاسل ، مثل أطر تطبيق مختلفة أو أنواع إجماع ، فسيكون تنفيذ العميل الخفيف مختلفًا. مثال على ذلك ؛ Composable Finance ، الذين يعملون على ربط سلسلة Cosmos SDK بإطار عمل تطبيق الركيزة للنظام الإيكولوجي Polkadot عبر IBC. هذا يتطلب عميل خفيف Tendermint على سلسلة Substrate وعميل خفيف "سمين" على سلسلة Cosmos SDK. في الآونة الأخيرة ، أنشأوا أول اتصال بين Polkadot و Kusama عبر IBC.
تحدي
كثافة الموارد هو تحد مهم. قد يكون تشغيل أزواج من العملاء الخفيفين على جميع السلاسل مكلفًا لأن عمليات الكتابة على blockchain باهظة الثمن. علاوة على ذلك ، فإن تكثيف الموارد باستخدام أدوات التحقق الديناميكية يمثل تحديًا مهمًا. قد يكون تشغيل العملاء الخفيفين المقترنين على جميع السلاسل أمرًا مكلفًا لأن عمليات الكتابة على blockchain باهظة الثمن. أيضًا ، بالنسبة للسلاسل ذات مجموعات التحقق الديناميكية (مثل Ethereum) ، ليس من الممكن تشغيل عملاء خفيفين.
قابلية التوسع هو تحد آخر. يختلف تنفيذ العملاء الخفيفين وفقًا لبنية السلسلة ، مما يجعل من الصعب توسيع نطاق الأنظمة البيئية المختلفة وربطها.
تشكل الثغرات الأمنية في الكود خطرًا محتملاً لأن الأخطاء الموجودة في الكود يمكن أن تؤدي إلى ثغرات أمنية. على سبيل المثال ، كشف خرق سلسلة BNB في أكتوبر 2022 عن وجود خلل أمني خطير يؤثر على جميع السلاسل الممكّنة لـ IBC.
لمعالجة التكلفة والتطبيق العملي لتشغيل العملاء الخفيفين على جميع السلاسل ، يمكن استخدام حلول بديلة مثل أدلة المعرفة الصفرية (ZK) لإزالة الحاجة إلى ثقة الطرف الثالث.
البراهين الصفرية المعرفة كحل لثقة الطرف الثالث
يمكن استخدام براهين المعرفة الصفرية للتحقق من صحة انتقالات الحالة لسلسلة المصدر على السلسلة المستهدفة. مقارنةً بأداء الحساب بأكمله على السلسلة ، فإن براهين ZK تقوم فقط بجزء التحقق من الحساب على السلسلة ، بينما يحدث الحساب الفعلي خارج السلسلة. يسمح هذا الأسلوب بالتحقق بشكل أسرع وأكثر كفاءة من إعادة تشغيل الحساب الأصلي. بعض الأمثلة تشمل Polymer Labs ؛ Polymer ZK-IBC ؛ و Succinct Labs ؛ التخاطر. تقوم شركة Polymer بتطوير حاويات متعددة القفزات لتحسين الاتصال وتقليل عدد التوصيلات المزدوجة المطلوبة.
تشمل الجوانب الرئيسية للآلية ما يلي:
أمان
يعتمد أمان zk-SNARKs على المنحنيات الإهليلجية ، بينما تعتمد zk-STARK على وظائف التجزئة. قد تتطلب zk-SNARKs إعدادًا موثوقًا به ، بما في ذلك إنشاء المفاتيح الأولية المستخدمة لإنشاء البراهين المستخدمة في التحقق. المفتاح هو تدمير سر حدث الإعداد لمنع المصادقة على المعاملات عن طريق التزوير. بمجرد اكتمال الإعداد الموثوق به ، لا يتم تقديم أي افتراضات ثقة أخرى. بالإضافة إلى ذلك ، فإن أطر عمل ZK الأحدث (مثل Halo و Halo ؛ 2 ؛) تزيل تمامًا الحاجة إلى إعداد موثوق به.
ينفذ
هناك مجموعة متنوعة من مخططات إثبات ZK ، مثل SNARK و STARK و VPD و SNARG ، و SNARK هو الأكثر استخدامًا حاليًا. أطر إثبات SNARK المختلفة ، مثل Groth ؛ 16 ، Plonk ، Marlin ، Halo ، و Halo ؛ 2 ؛ تقدم المفاضلات من حيث حجم الإثبات ، ووقت الإثبات ، ووقت التحقق ، ومتطلبات الذاكرة ، ومتطلبات الإعداد الموثوقة. ظهرت أيضًا براهين ZK التكرارية ، مما يسمح بتوزيع عبء عمل الإثبات عبر أجهزة كمبيوتر متعددة بدلاً من جهاز واحد. من أجل إنشاء أدلة على الصلاحية ، يجب تنفيذ الأساسيات الأساسية التالية: التحقق من مخطط التوقيع المستخدم من قبل المدقق ، وتخزين البراهين للمفتاح العام للمدقق في التزام مجموعة المدقق المخزن على السلسلة ، وتتبع مجموعة المدقق ، والتي قد كثيرا ما تتغير.
تحدي
يتطلب تنفيذ مخططات التوقيع المختلفة في zkSNARKs تنفيذ عمليات منحنى بيضاوي حسابي ومعقد خارج المجال ، وهي ليست تافهة وقد تتطلب تطبيقات مختلفة اعتمادًا على إطار العمل وإجماع السلاسل المختلفة. تدقيق دوائر ZK مهمة صعبة وعرضة للخطأ. يحتاج المطورون إلى أن يكونوا على دراية باللغات الخاصة بالمجال مثل Circom و Cairo و Noir ، أو تنفيذ الدوائر بشكل مباشر ، وكلاهما يمكن أن يكون صعبًا ويمكن أن يبطئ من اعتمادهما. إذا ثبت أن الوقت والجهد مرتفعان جدًا ، فقد يتم التعامل معه فقط من قبل فرق مخصصة وأجهزة مخصصة ، مما قد يؤدي إلى المركزية. كما تتسبب أوقات التوليد الأطول في حدوث تأخيرات. يمكن لتقنيات مثل الحساب القابل للتحقق بشكل متزايد (IVC) تحسين أوقات الإثبات ، لكن العديد منها لا يزال في مرحلة البحث ، في انتظار التنفيذ. ستزيد أوقات التحقق وأعباء العمل الأطول من تكاليف السلسلة.
الثقة في نظرية اللعبة
يمكن تقسيم بروتوكولات التشغيل البيني المستندة إلى نظرية اللعبة على نطاق واسع إلى فئتين ، وفقًا لكيفية تحفيزهم للسلوك الصادق من قبل الكيانات المشاركة:
الفئة الأولى هي آلية الأمن الاقتصادي التي تتعاون فيها جهات خارجية متعددة (مثل المدققين) للوصول إلى توافق في الآراء لتحديد الحالة المحدثة لسلسلة المصدر. لكي يصبح المشاركون مدققين ، يحتاجون إلى مشاركة مقدار معين من الرموز المميزة ، والتي يمكن تخفيضها في حالة حدوث نشاط ضار. في الإعداد بدون إذن ، يمكن لأي شخص أن يجمع حصته ويصبح مدققًا. بالإضافة إلى ذلك ، يتم توفير الحوافز الاقتصادية مثل المكافآت الجماعية للمدققين الذين يتبعون البروتوكول لضمان الحوافز الاقتصادية للسلوك النزيه. ومع ذلك ، إذا تجاوز المبلغ المسروق المحتمل المبلغ المحجوز ، فقد يتواطأ المشاركون لسرقة الأموال. تتضمن أمثلة البروتوكولات التي تستخدم آليات الأمن الاقتصادي ؛ Axelar و Celer IM.
الفئة الثانية هي آليات الأمان المتفائلة ، حيث يعتمد الحل على افتراض أن عددًا صغيرًا فقط من المشاركين في blockchain صادقون ويلتزمون بقواعد البروتوكول. في هذا النهج ، يعمل المشارك الصادق كضمان. على سبيل المثال ، يتيح الحل الأمثل لأي شخص تقديم إثباتات الاحتيال. على الرغم من وجود حافز مالي ، إلا أن المراقب الصادق قد يفقد معاملة احتيالية. التراكمية المتفائلة تستخدم هذه الآلية أيضًا. Nomad و ChainLink CCIP ؛ أمثلة على البروتوكولات التي تستخدم آليات أمان متفائلة. في حالة Nomad ، تمكن المراقبون من إثبات الاحتيال ، على الرغم من إدراجهم في القائمة البيضاء وقت كتابة هذا التقرير. تخطط ChainLink CCIP لاستخدام شبكة لمكافحة الاحتيال تتكون من شبكة موزعة من oracles لاكتشاف النشاط الضار ، على الرغم من أن تنفيذ شبكة CCIP لمكافحة الاحتيال غير معروف.
أمان
فيما يتعلق بالأمن ، تعتمد كلا الآليتين على مشاركة غير مصرح بها من المحققين والمراقبين لضمان صحة نظرية اللعبة. في آلية الأمن الاقتصادي ، تكون الأموال أكثر عرضة للخطر إذا كان المبلغ المحصن أقل من المبلغ الذي يمكن سرقته. من ناحية أخرى ، في الآليات الأمنية المتفائلة ، يمكن استغلال افتراض ثقة الأقلية إذا لم يقدم أي شخص دليلًا على الاحتيال ، أو إذا تم اختراق أو إزالة مراقبي الإذن. في المقابل ، آليات الأمن الاقتصادي أقل اعتمادًا على القدرة على الحفاظ على الأمن.
ينفذ
فيما يتعلق بالتنفيذ ، يتضمن أحد الأساليب سلسلة وسيطة مع المدققين الخاصين بها. في هذا الإعداد ، تراقب مجموعة من المدققين الخارجيين سلسلة المصدر وتتوصل إلى إجماع على صحة المعاملة عند اكتشاف استدعاء. بمجرد التوصل إلى توافق في الآراء ، فإنهم يقدمون البراهين على السلسلة المستهدفة. عادةً ما يُطلب من المدققين الحصول على قدر معين من الرموز المميزة ، والتي يمكن تقليلها إذا تم اكتشاف نشاط ضار. تتضمن أمثلة البروتوكولات التي تستخدم طريقة التنفيذ هذه شبكة Axelar و Celer IM.
طريقة أخرى للتنفيذ تتضمن استخدام وكلاء خارج السلسلة. تُستخدم الوكلاء خارج السلسلة لتنفيذ حلول متفائلة تشبه التراكمية. في غضون فترة زمنية محددة مسبقًا ، يمكن لهذه الوكلاء خارج السلسلة تقديم إثباتات الاحتيال وعكس المعاملات إذا لزم الأمر. على سبيل المثال ، يعتمد Nomad على وكلاء مستقلون خارج السلسلة لترحيل الرؤوس وبراهين التشفير. من ناحية أخرى ، تخطط ChainLink CCIP للاستفادة من شبكتها الحالية من oracles لمراقبة المعاملات عبر السلسلة والتصديق عليها.
نقاط القوة والتحديات
تتمثل الميزة الرئيسية لحلول AMP النظرية للعبة في تحسين الموارد ، حيث تكون عملية التحقق عادةً خارج السلسلة ، مما يقلل من متطلبات الموارد. علاوة على ذلك ، فإن هذه الآليات قابلة للتطوير حيث تظل آلية الإجماع كما هي بالنسبة لأنواع مختلفة من السلاسل ويمكن توسيعها بسهولة لتشمل سلاسل الكتل غير المتجانسة.
هناك أيضًا العديد من التحديات المرتبطة بهذه الآليات. إذا تواطأت غالبية المدققين ، فيمكن استغلال افتراضات الثقة لسرقة الأموال ، مما يتطلب تدابير مضادة مثل التصويت التربيعي وإثبات الغش. علاوة على ذلك ، تقدم الحلول القائمة على الأمان المتفائل تعقيدات من حيث النهاية والحيوية ، حيث يحتاج المستخدمون والتطبيقات إلى انتظار النوافذ الاحتيالية لضمان صحة المعاملات.
ثق بالبشر
يمكن أيضًا تقسيم الحلول التي تتطلب الثقة في الكيانات البشرية على نطاق واسع إلى فئتين:
أمن السمعة: تعتمد هذه الحلول على تطبيقات متعددة التوقيعات ، حيث تقوم كيانات متعددة بالتحقق من المعاملات وتوقيعها. بمجرد الوصول إلى الحد الأدنى ، تعتبر المعاملة صالحة. الافتراض هنا هو أن معظم الكيانات صادقة ، وإذا وقعت غالبية هذه الكيانات على معاملة معينة ، فإن هذه المعاملة تكون صالحة. الشيء الوحيد المعرض للخطر هنا هو سمعة الكيانات المعنية. تتضمن بعض الأمثلة ؛ Multichain (Anycall V؛ 6؛) و Wormhole. لا تزال الثغرات موجودة بسبب الثغرات الأمنية في العقود الذكية ، كما يتضح من اختراق Wormhole في أوائل عام 2022.
الاستقلالية: قسمت هذه الحلول عملية المراسلة بأكملها إلى جزأين وتعتمد على كيانات مستقلة مختلفة لإدارة العمليتين. الافتراض هنا هو أن هذين الكيانين مستقلين عن بعضهما البعض ولا يمكنهما التواطؤ. LayerZero مثال على ذلك. يتم إرسال رؤوس الكتل عند الطلب من خلال أوراكل الموزعة ، ويتم إرسال إثباتات المعاملات من خلال المرحلات. إذا تطابق الإثبات مع الرأس ، تعتبر المعاملة صالحة. بينما يعتمد إثبات المطابقة على الكود / الرياضيات ، يحتاج المشاركون إلى الوثوق في أن هذه الكيانات تظل مستقلة وليس لها نوايا خبيثة. التطبيقات المبنية على ؛ LayerZero ؛ يمكن أن تختار أوراكلها ومرحلاتها (أو تستضيف أوراكل / مرحلات خاصة بها) ، وبالتالي تحد من المخاطر على الأفراد / المرحلات. يحتاج المستخدمون النهائيون إلى الوثوق في أن LayerZero أو الجهات الخارجية أو التطبيق نفسه يقوم بتشغيل أوراكل وترحيل بشكل مستقل ، دون أي نية خبيثة.
في كلا النهجين ، فإن سمعة كيانات الطرف الثالث المشاركة تردع السلوك الضار. عادة ما تكون هذه الكيانات تحظى باحترام كبير في مجتمع المدقق و oracle ، وإذا تصرفت بشكل ضار ، فإنها تخاطر بإلحاق الضرر بالسمعة والتأثير السلبي على الأنشطة التجارية الأخرى.
اعتبارات إضافية لحلول AMP
عند النظر في أمان حل AMP وقابليته للاستخدام ، نحتاج أيضًا إلى النظر في تفاصيل تتجاوز الآليات الأساسية. نظرًا لأن هذه مكونات يمكن أن تتغير بمرور الوقت ، فإننا لم ندرجها في المقارنة الشاملة.
تكامل الكود
استغلت الاختراقات الحديثة أخطاء التعليمات البرمجية ، مما سلط الضوء على الحاجة إلى تدقيق قوي ، ومكافآت الأخطاء ، وعمليات تنفيذ متنوعة للعملاء. إذا قام جميع المدققين (في المجال الاقتصادي / المتفائل / الأمن المتعلق بالسمعة) بتشغيل نفس العميل (برنامج للتحقق) ، فإنه يزيد من الاعتماد على قاعدة بيانات واحدة ويقلل من تنوع العميل. على سبيل المثال ، تعتمد Ethereum على العديد من عملاء التنفيذ مثل geth و netermind و erigon و besu و akula. قد تؤدي التطبيقات المتعددة بلغات مختلفة إلى زيادة التنوع ، مع عدم وجود عميل واحد يسيطر على الشبكة ، مما يقضي على نقطة واحدة محتملة للفشل. يمكن أن يساعد وجود عملاء متعددين أيضًا في الحفاظ على الحيوية في حالة فشل عدد قليل من المدققين / المُوقِّعين / العملاء الخفيفين بسبب خطأ / هجوم في تنفيذ معين.
الإعداد والترقية
يحتاج المستخدمون والمطورون إلى معرفة ما إذا كان بإمكان المدققين / المراقبين الانضمام إلى الشبكة بدون إذن ، وإلا فإن الثقة ستخفيها الكيانات التي تختار الإذن. يمكن أن تؤدي الترقيات إلى العقود الذكية أيضًا إلى ظهور نقاط ضعف يمكن أن تؤدي إلى هجمات وربما حتى تغيير افتراضات الثقة. يمكن تنفيذ حلول مختلفة للتخفيف من هذه المخاطر. على سبيل المثال ، في إنشاء مثيل حالي ، يمكن ترقية بوابة Axelar ولكنها تتطلب موافقة من اللجنة غير المتصلة بالإنترنت (عتبة 4/8) ، ومع ذلك ، في المستقبل القريب تخطط Axelar لمطالبة جميع المدققين بالموافقة الجماعية على أي ترقيات للبوابة. عقود Wormhole الأساسية قابلة للترقية وتتم إدارتها من خلال نظام إدارة Wormhole على السلسلة. يعتمد LayerZero على العقود الذكية غير القابلة للتغيير والمكتبات غير القابلة للتغيير لتجنب أي ترقيات ، ولكن يمكن دفع مكتبات جديدة ، وستحصل dapps التي تعين الإعدادات الافتراضية على إصدارات أحدث ، وتحتاج dapps التي تعين الإصدار يدويًا إلى تعيينها على الإصدار الجديد.
أقصى قيمة قابلة للاستخراج (MEV)
لا تتم مزامنة سلاسل الكتل المختلفة بواسطة ساعة مشتركة ولها أوقات نهائية مختلفة. لذلك ، قد يختلف ترتيب التنفيذ والتوقيت في السلسلة المستهدفة من سلسلة إلى أخرى. في عالم متعدد السلاسل ، يصعب تحديد MEV بوضوح. يقدم مقايضة بين الحياة وأمر التنفيذ. ستضمن القناة المرتبة تسليم الرسائل بالترتيب ، ولكن إذا انتهت مهلة الرسالة ، فسيتم إغلاق القناة. قد لا يفضل تطبيق آخر أي طلب ، لكن تسليم الرسائل الأخرى لن يتأثر.
اليقين سلسلة المصدر
من الناحية المثالية ، يجب أن تنتظر حلول AMP وصول سلسلة المصدر إلى نهايتها قبل إرسال معلومات الحالة الخاصة بسلسلة المصدر إلى سلسلة مستهدفة واحدة أو أكثر. سيضمن ذلك أن الكتل الموجودة في سلسلة المصدر بالكاد يمكن عكسها أو تغييرها. ومع ذلك ، توفر العديد من الحلول مراسلة فورية وتضع افتراضات ثقة حول النهاية من أجل توفير أفضل تجربة للمستخدم. في هذه الحالة ، إذا خضعت سلسلة المصدر لاستعادة الحالة بعد تسليم الرسالة وتمرير أصل الجسر ، فقد يؤدي ذلك إلى حالات مثل الإنفاق المزدوج لأموال الجسر. يمكن لحلول AMP إدارة هذه المخاطر بعدة طرق ، مثل وضع افتراضات نهائية مختلفة لسلاسل مختلفة اعتمادًا على مدى لامركزية السلسلة ، أو عن طريق إجراء مفاضلات بين السرعة والأمان. يمكن للجسور التي تستخدم حلول AMP أن تضع قيودًا على كمية الأصول التي يتم تجسيرها قبل أن تصل سلسلة المصدر إلى نهايتها.
الاتجاهات والتوقعات المستقبلية أمان قابل للتخصيص وإلحاق
لتقديم خدمة أفضل لحالات الاستخدام المتنوعة ، يتم تحفيز حلول AMP لتوفير المزيد من المرونة للمطورين. يقدم Axelar طريقة لتمكين قابلية التوسع في المراسلة والتحقق من الصحة دون تغيير منطق طبقة التطبيق. يقدم HyperLane V2 وحدات تسمح للمطورين بالاختيار من بين خيارات متعددة مثل الأمان الاقتصادي والأمان المتفائل والأمان الديناميكي والأمان المختلط. توفر CelerIM أمانًا متفائلًا إضافيًا بالإضافة إلى الأمان الاقتصادي. تنتظر العديد من الحلول الحد الأدنى المحدد مسبقًا من تأكيدات الكتلة على سلسلة المصدر قبل تسليم الرسالة. يسمح LayerZero للمطورين بتحديث هذه المعلمات. نتوقع أن تستمر بعض حلول AMP في تقديم المزيد من المرونة ، ولكن خيارات التصميم هذه تتطلب بعض المناقشة. هل يجب أن تكون التطبيقات قادرة على تكوين أمانها ، وإلى أي مدى ، وماذا يحدث إذا تم تصميم التطبيقات بتصميم دون المستوى الأمثل؟ من المرجح أن يصبح وعي المستخدم بالمفاهيم الأساسية وراء الأمن ذا أهمية متزايدة. في النهاية ، نتوقع تجميع واستخراج حلول AMP ، ربما في شكل شكل من أشكال التكوين أو أمان "إضافي".
نضج آلية "كود الثقة والرياضيات"
في المرحلة النهائية المثالية ، سيتم تقليل الثقة في جميع الرسائل عبر السلاسل من خلال استخدام البراهين الصفرية المعرفة (ZK). لقد رأينا مشاريع مماثلة تظهر مثل Polymer Labs و Succinct Labs. نشرت Multichain أيضًا ورقة بيضاء zkRouter حول إمكانية التشغيل البيني عبر براهين ZK. من خلال جهاز Axelar Virtual Machine الذي تم الإعلان عنه مؤخرًا ، يمكن للمطورين الاستفادة من Interchain Amplifier لإنشاء اتصالات جديدة بشبكة Axelar بدون إذن. على سبيل المثال ، بمجرد تطوير عملاء قويين للضوء وإثباتات ZK لحالة Ethereum ، يمكن للمطورين دمجهم بسهولة في شبكة Axelar لاستبدال أو تحسين الاتصالات الحالية. أعلنت شبكة سيلير عن Brevis ، وهي عبارة عن منصة ZK عبر سلسلة لإثبات البيانات والتي تمكّن dApps والعقود الذكية من الوصول إلى البيانات التعسفية وحسابها والاستفادة منها في العديد من سلاسل الكتل. نفذت سيلير أحد الأصول الموجه نحو المستخدم zkBridge باستخدام دائرة العميل الخفيف ZK للتسلسل المتقاطع بين Ethereum Goerli testnet و BNB Chain testnet. تناقش LayerZero في وثائقها إمكانية إضافة مكتبات رسائل برهان محسّنة جديدة في المستقبل. تستكشف المشاريع الأحدث مثل Lagrange تجميع البراهين المتعددة من سلاسل مصادر متعددة ، بينما يجعل Herodotus تخزين البراهين ممكنًا باستخدام براهين ZK. ومع ذلك ، سيستغرق هذا الانتقال وقتًا ، حيث يصعب توسيع نطاق هذا النهج عبر البلوكشين التي تعتمد على آليات وأطر إجماع مختلفة.
ZK هي تقنية جديدة ومعقدة نسبيًا يصعب تدقيقها ، وتكاليف التحقق الحالية وتوليد الإثبات ليست مثالية. نعتقد أنه على المدى الطويل ، لدعم التطبيقات عبر السلاسل القابلة للتطوير بدرجة كبيرة على blockchains ، من المحتمل أن تجمع العديد من حلول AMP بين البرامج التي يمكن التحقق منها مع البشر والكيانات الموثوق بهم للأسباب التالية:
من خلال مكافآت التدقيق والأخطاء ، يمكن التقليل من إمكانية استغلال الكود. بمرور الوقت ، سيصبح من السهل الوثوق بهذه الأنظمة حيث يصبح تاريخها دليلاً على أمانها.
سيتم تخفيض تكلفة إنتاج البراهين ZK. مع المزيد من البحث والتطوير حول ZKPs و ZKPs العودية وتجميع الإثبات وخطط الطي والأجهزة المتخصصة ، نتوقع أن تنخفض التكلفة الزمنية لإنشاء الأدلة والتحقق بشكل كبير ، مما يجعلها نهجًا أكثر فعالية من حيث التكلفة.
سوف تصبح blockchain أكثر دعمًا لـ ZK. في المستقبل ، ستتمكن zkEVM من تقديم أدلة موجزة على صلاحية التنفيذ ، وستكون الحلول الخفيفة القائمة على العميل قادرة على التحقق بسهولة من تنفيذ سلسلة المصدر والإجماع. في المرحلة النهائية من Ethereum ، من المخطط أيضًا "zk-SNARK كل شيء" ، بما في ذلك آلية الإجماع.
المؤهلات البشرية والسمعة والهوية
لا يمكن تغليف أمان نظام معقد مثل حل AMP بإطار عمل واحد فقط ويتطلب حلاً متعدد الطبقات. على سبيل المثال ، بالإضافة إلى الحوافز الاقتصادية ، يطبق أكسلار آلية تصويت تربيعية لمنع تركيز قوة التصويت بين مجموعة فرعية من العقد وتعزيز اللامركزية. يمكن أيضًا أن تكمل البراهين البشرية والسمعة والهويات الأخرى آليات الإعداد والإذن.
ختاماً
بروح Web3 المنفتحة ، قد نرى مستقبلًا تعدديًا حيث تتعايش مناهج متعددة. في الواقع ، يمكن للتطبيق أن يختار استخدام حلول متعددة للتشغيل البيني ، إما بطريقة زائدة عن الحاجة أو ليختار المستخدم مجموعة بناءً على المقايضات. بين مسارات "حركة المرور العالية" ، قد يتم إعطاء الأولوية للحلول من نقطة إلى نقطة ، بينما قد تهيمن نماذج المحور والتحدث على الذيل الطويل للسلسلة. في النهاية ، كمجتمع من المستخدمين والبناة والمساهمين ، سنشكل الشكل الأساسي لإنترنت Web3.
الارتباط الأصلي
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
كيف يحل التفسير المتعمق لبروتوكولات الرسائل العشوائية مشكلة ثقة إمكانية التشغيل البيني؟
المؤلف الأصلي: شي خاي وي ، راغاف أغاروال
التجميع الأصلي: Kxp ، BlockBeats
مقدمة
تعد السلسلة المتعددة هي اتجاه التطوير المستقبلي ، وقد أدى السعي وراء قابلية التوسع إلى قيام Ethereum ببناء تقنية Rollup. في الانتقال إلى سلاسل الكتل المعيارية ، تم الاهتمام مرة أخرى بـ Lisk. وفي المستقبل غير البعيد ، نسمع شائعات حول التراكميات الخاصة بالتطبيقات ، و L3s ، والسلاسل السيادية. لكن كل هذا سيأتي على حساب التجزئة ، وغالبًا ما تكون الجسور الحالية عبر السلاسل محدودة في الوظائف وتعتمد على الموقِّعين الموثوق بهم للأمن.
إذن ، كيف سيبدو Web3 المتصل في النهاية؟ نعتقد أن الجسور عبر السلاسل سوف تتطور في النهاية إلى بروتوكولات للرسائل عبر السلاسل أو بروتوكولات "المراسلة التعسفية" (AMP) لفتح سيناريوهات جديدة للتطبيق ، مما يسمح للتطبيقات بتمرير رسائل عشوائية بين سلسلة المصدر والسلسلة المستهدفة. سنشهد أيضًا ظهور "مشهد آلية الثقة" ، حيث سيجري البناة العديد من المفاضلات بين سهولة الاستخدام والتعقيد والأمان.
يحتاج كل حل من حلول AMP إلى تنفيذ وظيفتين رئيسيتين:
لسوء الحظ ، فإن التحقق غير الموثوق به بنسبة 100٪ ليس واقعيًا ، يجب على المستخدمين اختيار الثقة في الكود أو نظرية اللعبة أو البشر (أو الكيانات) أو مزيج من هذه ، اعتمادًا على ما إذا كان التحقق على السلسلة أو خارج السلسلة.
في هذه الورقة ، نقسم عموديًا مجال التشغيل البيني الشامل إلى آليات قائمة على الثقة وبنيات قائمة على التكامل.
آلية الثقة:
رمز الثقة والرياضيات: بالنسبة لهذه الحلول ، يوجد دليل على السلسلة يمكن لأي شخص التحقق منه. تعتمد هذه الحلول عادةً على العملاء الخفيفين للتحقق من إجماع سلسلة المصدر على السلسلة المستهدفة أو التحقق من صحة انتقال الحالة لسلسلة المصدر إلى السلسلة المستهدفة. يمكن أن يؤدي التحقق من خلال العملاء الخفيفين إلى تحسين الكفاءة من خلال البراهين الصفرية المعرفة ، وضغط الحسابات الطويلة بشكل تعسفي ليتم إجراؤها في وضع عدم الاتصال ، مع توفير تحقق بسيط على السلسلة لإثبات نتائج الحساب.
Trust Game Theory: عندما يحتاج المستخدم / التطبيق إلى الوثوق بطرف ثالث أو شبكة طرف ثالث لضمان مصداقية المعاملة ، يتم تضمين افتراضات ثقة إضافية. يمكن تحسين أمان هذه الآليات من خلال استخدام الشبكات غير المرخصة ونظرية الألعاب مثل الحوافز الاقتصادية والأمن المتفائل.
الثقة في البشر: تعتمد هذه الحلول على صدق أو استقلالية غالبية المدققين الذين ينقلون معلومات مختلفة. بالإضافة إلى الوثوق بإجماع السلسلتين التفاعليتين ، تحتاج أيضًا إلى الوثوق بطرف ثالث. في هذه الحالة ، فإن الخطر الوحيد هو سمعة الكيانات المشاركة. تعتبر المعاملة صالحة إذا وافق عدد كافٍ من الكيانات المشاركة على أنها صالحة.
تجدر الإشارة إلى أن جميع الحلول تتطلب الثقة في الكود والبشر إلى حد ما. يمكن للمخترقين استغلال أي حل برمز عربات التي تجرها الدواب ، ولكل حل بعض العناصر البشرية في إعداد قاعدة التعليمات البرمجية أو ترقيتها أو صيانتها.
العمارة المتكاملة:
نموذج من نقطة إلى نقطة: يجب إنشاء قناة اتصال مخصصة بين كل سلسلة مصدر وسلسلة مستهدفة.
نموذج المحور المركزي: يجب إنشاء قناة اتصال مع المحور المركزي لتحقيق الترابط مع جميع سلاسل الكتل الأخرى المتصلة بالمحور.
من الصعب نسبيًا قياس نموذج نظير إلى نظير لأن كل blockchain متصل يتطلب قناة اتصال مقترنة. قد يكون تطوير هذه القنوات تحديًا للكتل ذات الإجماع والأطر المختلفة. ومع ذلك ، توفر الجسور المقترنة مزيدًا من المرونة لتخصيص التكوين إذا رغبت في ذلك. المناهج الهجينة ممكنة أيضًا ، مثل التوجيه متعدد القفزات من خلال المرحلات باستخدام بروتوكول Inter-Blockchain Communication (IBC) ، والذي يلغي الحاجة إلى الاتصال المباشر من نظير إلى نظير ، ولكنه يقدم المزيد من التعقيدات من حيث الأمان ووقت الاستجابة و يكلف.
كود الثقة والرياضيات
من أجل الاعتماد فقط على الكود / الرياضيات لافتراضات الثقة ، يمكن استخدام العملاء الخفيفين للتحقق من إجماع سلسلة المصدر على السلسلة المستهدفة. العملاء / العقد الخفيفة هي برامج تتصل بالعقد الكاملة للتفاعل مع blockchain. عادةً ما يقوم العملاء الخفيفون في السلسلة المستهدفة بتخزين محفوظات (بالترتيب) لرؤوس كتل سلسلة المصدر ، وهو ما يكفي للتحقق من المعاملات. يقوم الوكيل خارج السلسلة (مثل المرحل) بمراقبة الأحداث على سلسلة المصدر ، وإنشاء أدلة تشفير للتضمين ، وإعادة توجيهها جنبًا إلى جنب مع رؤوس الكتلة لإضاءة العملاء في السلسلة المستهدفة. نظرًا لأن العملاء الخفيفين يقومون بتخزين رؤوس الكتل بالتتابع ، كل منها يحتوي على تجزئة جذر Merkle التي يمكن استخدامها لإثبات الحالة ، فإنهم قادرون على التحقق من المعاملات. فيما يلي نظرة عامة على الميزات الرئيسية لهذا النهج:
أمان
يتم تقديم افتراضات الثقة أثناء تهيئة العملاء الخفيفين. عند إنشاء عميل light جديد ، سيتم تهيئته إلى رأس كتلة من ارتفاع معين في السلسلة الأخرى. ومع ذلك ، هناك احتمال أن تكون رؤوس الكتل المقدمة غير صحيحة ، مما يجعل من الممكن خداع العملاء الخفيفين باستخدام رؤوس الكتل المزورة. بمجرد تهيئة عميل خفيف ، لا يتم تقديم أي افتراضات ثقة أخرى. ومع ذلك ، تجدر الإشارة إلى أن عملية التهيئة هذه تعتمد على افتراض ثقة ضعيف ، حيث يمكن لأي شخص التحقق منه. بالإضافة إلى ذلك ، هناك افتراض حيوي لنقل المعلومات المستمر للترحيل.
ينفذ
يعتمد تنفيذ العملاء الخفيفين على توفر أساسيات التشفير المطلوبة للمصادقة. إذا تم توصيل نفس النوع من السلاسل ، مما يعني أنها تشترك في نفس إطار عمل التطبيق وخوارزمية الإجماع ، فستكون تطبيقات العميل الخفيف في كلا الطرفين هي نفسها. على سبيل المثال ، تستخدم جميع السلاسل المستندة إلى Cosmos SDK بروتوكول Inter-Blockchain Communication (IBC). من ناحية أخرى ، تعتمد التطبيقات مثل العملاء الخفيفين على دعم أساسيات التشفير المطلوبة للمصادقة. إذا تم توصيل نفس النوع من السلاسل ، أي أنها تشترك في نفس إطار عمل التطبيق وخوارزمية الإجماع ، فستكون تطبيقات العميل الخفيفة على كلا الجانبين هي نفسها. على سبيل المثال ، يتم استخدام بروتوكول Inter-Blockchain Communication (IBC) لجميع السلاسل المستندة إلى Cosmos SDK. من ناحية أخرى ، إذا تم توصيل نوعين مختلفين من السلاسل ، مثل أطر تطبيق مختلفة أو أنواع إجماع ، فسيكون تنفيذ العميل الخفيف مختلفًا. مثال على ذلك ؛ Composable Finance ، الذين يعملون على ربط سلسلة Cosmos SDK بإطار عمل تطبيق الركيزة للنظام الإيكولوجي Polkadot عبر IBC. هذا يتطلب عميل خفيف Tendermint على سلسلة Substrate وعميل خفيف "سمين" على سلسلة Cosmos SDK. في الآونة الأخيرة ، أنشأوا أول اتصال بين Polkadot و Kusama عبر IBC.
تحدي
كثافة الموارد هو تحد مهم. قد يكون تشغيل أزواج من العملاء الخفيفين على جميع السلاسل مكلفًا لأن عمليات الكتابة على blockchain باهظة الثمن. علاوة على ذلك ، فإن تكثيف الموارد باستخدام أدوات التحقق الديناميكية يمثل تحديًا مهمًا. قد يكون تشغيل العملاء الخفيفين المقترنين على جميع السلاسل أمرًا مكلفًا لأن عمليات الكتابة على blockchain باهظة الثمن. أيضًا ، بالنسبة للسلاسل ذات مجموعات التحقق الديناميكية (مثل Ethereum) ، ليس من الممكن تشغيل عملاء خفيفين.
قابلية التوسع هو تحد آخر. يختلف تنفيذ العملاء الخفيفين وفقًا لبنية السلسلة ، مما يجعل من الصعب توسيع نطاق الأنظمة البيئية المختلفة وربطها.
تشكل الثغرات الأمنية في الكود خطرًا محتملاً لأن الأخطاء الموجودة في الكود يمكن أن تؤدي إلى ثغرات أمنية. على سبيل المثال ، كشف خرق سلسلة BNB في أكتوبر 2022 عن وجود خلل أمني خطير يؤثر على جميع السلاسل الممكّنة لـ IBC.
لمعالجة التكلفة والتطبيق العملي لتشغيل العملاء الخفيفين على جميع السلاسل ، يمكن استخدام حلول بديلة مثل أدلة المعرفة الصفرية (ZK) لإزالة الحاجة إلى ثقة الطرف الثالث.
البراهين الصفرية المعرفة كحل لثقة الطرف الثالث
يمكن استخدام براهين المعرفة الصفرية للتحقق من صحة انتقالات الحالة لسلسلة المصدر على السلسلة المستهدفة. مقارنةً بأداء الحساب بأكمله على السلسلة ، فإن براهين ZK تقوم فقط بجزء التحقق من الحساب على السلسلة ، بينما يحدث الحساب الفعلي خارج السلسلة. يسمح هذا الأسلوب بالتحقق بشكل أسرع وأكثر كفاءة من إعادة تشغيل الحساب الأصلي. بعض الأمثلة تشمل Polymer Labs ؛ Polymer ZK-IBC ؛ و Succinct Labs ؛ التخاطر. تقوم شركة Polymer بتطوير حاويات متعددة القفزات لتحسين الاتصال وتقليل عدد التوصيلات المزدوجة المطلوبة.
تشمل الجوانب الرئيسية للآلية ما يلي:
أمان
يعتمد أمان zk-SNARKs على المنحنيات الإهليلجية ، بينما تعتمد zk-STARK على وظائف التجزئة. قد تتطلب zk-SNARKs إعدادًا موثوقًا به ، بما في ذلك إنشاء المفاتيح الأولية المستخدمة لإنشاء البراهين المستخدمة في التحقق. المفتاح هو تدمير سر حدث الإعداد لمنع المصادقة على المعاملات عن طريق التزوير. بمجرد اكتمال الإعداد الموثوق به ، لا يتم تقديم أي افتراضات ثقة أخرى. بالإضافة إلى ذلك ، فإن أطر عمل ZK الأحدث (مثل Halo و Halo ؛ 2 ؛) تزيل تمامًا الحاجة إلى إعداد موثوق به.
ينفذ
هناك مجموعة متنوعة من مخططات إثبات ZK ، مثل SNARK و STARK و VPD و SNARG ، و SNARK هو الأكثر استخدامًا حاليًا. أطر إثبات SNARK المختلفة ، مثل Groth ؛ 16 ، Plonk ، Marlin ، Halo ، و Halo ؛ 2 ؛ تقدم المفاضلات من حيث حجم الإثبات ، ووقت الإثبات ، ووقت التحقق ، ومتطلبات الذاكرة ، ومتطلبات الإعداد الموثوقة. ظهرت أيضًا براهين ZK التكرارية ، مما يسمح بتوزيع عبء عمل الإثبات عبر أجهزة كمبيوتر متعددة بدلاً من جهاز واحد. من أجل إنشاء أدلة على الصلاحية ، يجب تنفيذ الأساسيات الأساسية التالية: التحقق من مخطط التوقيع المستخدم من قبل المدقق ، وتخزين البراهين للمفتاح العام للمدقق في التزام مجموعة المدقق المخزن على السلسلة ، وتتبع مجموعة المدقق ، والتي قد كثيرا ما تتغير.
تحدي
يتطلب تنفيذ مخططات التوقيع المختلفة في zkSNARKs تنفيذ عمليات منحنى بيضاوي حسابي ومعقد خارج المجال ، وهي ليست تافهة وقد تتطلب تطبيقات مختلفة اعتمادًا على إطار العمل وإجماع السلاسل المختلفة. تدقيق دوائر ZK مهمة صعبة وعرضة للخطأ. يحتاج المطورون إلى أن يكونوا على دراية باللغات الخاصة بالمجال مثل Circom و Cairo و Noir ، أو تنفيذ الدوائر بشكل مباشر ، وكلاهما يمكن أن يكون صعبًا ويمكن أن يبطئ من اعتمادهما. إذا ثبت أن الوقت والجهد مرتفعان جدًا ، فقد يتم التعامل معه فقط من قبل فرق مخصصة وأجهزة مخصصة ، مما قد يؤدي إلى المركزية. كما تتسبب أوقات التوليد الأطول في حدوث تأخيرات. يمكن لتقنيات مثل الحساب القابل للتحقق بشكل متزايد (IVC) تحسين أوقات الإثبات ، لكن العديد منها لا يزال في مرحلة البحث ، في انتظار التنفيذ. ستزيد أوقات التحقق وأعباء العمل الأطول من تكاليف السلسلة.
الثقة في نظرية اللعبة
يمكن تقسيم بروتوكولات التشغيل البيني المستندة إلى نظرية اللعبة على نطاق واسع إلى فئتين ، وفقًا لكيفية تحفيزهم للسلوك الصادق من قبل الكيانات المشاركة:
الفئة الأولى هي آلية الأمن الاقتصادي التي تتعاون فيها جهات خارجية متعددة (مثل المدققين) للوصول إلى توافق في الآراء لتحديد الحالة المحدثة لسلسلة المصدر. لكي يصبح المشاركون مدققين ، يحتاجون إلى مشاركة مقدار معين من الرموز المميزة ، والتي يمكن تخفيضها في حالة حدوث نشاط ضار. في الإعداد بدون إذن ، يمكن لأي شخص أن يجمع حصته ويصبح مدققًا. بالإضافة إلى ذلك ، يتم توفير الحوافز الاقتصادية مثل المكافآت الجماعية للمدققين الذين يتبعون البروتوكول لضمان الحوافز الاقتصادية للسلوك النزيه. ومع ذلك ، إذا تجاوز المبلغ المسروق المحتمل المبلغ المحجوز ، فقد يتواطأ المشاركون لسرقة الأموال. تتضمن أمثلة البروتوكولات التي تستخدم آليات الأمن الاقتصادي ؛ Axelar و Celer IM.
الفئة الثانية هي آليات الأمان المتفائلة ، حيث يعتمد الحل على افتراض أن عددًا صغيرًا فقط من المشاركين في blockchain صادقون ويلتزمون بقواعد البروتوكول. في هذا النهج ، يعمل المشارك الصادق كضمان. على سبيل المثال ، يتيح الحل الأمثل لأي شخص تقديم إثباتات الاحتيال. على الرغم من وجود حافز مالي ، إلا أن المراقب الصادق قد يفقد معاملة احتيالية. التراكمية المتفائلة تستخدم هذه الآلية أيضًا. Nomad و ChainLink CCIP ؛ أمثلة على البروتوكولات التي تستخدم آليات أمان متفائلة. في حالة Nomad ، تمكن المراقبون من إثبات الاحتيال ، على الرغم من إدراجهم في القائمة البيضاء وقت كتابة هذا التقرير. تخطط ChainLink CCIP لاستخدام شبكة لمكافحة الاحتيال تتكون من شبكة موزعة من oracles لاكتشاف النشاط الضار ، على الرغم من أن تنفيذ شبكة CCIP لمكافحة الاحتيال غير معروف.
أمان
فيما يتعلق بالأمن ، تعتمد كلا الآليتين على مشاركة غير مصرح بها من المحققين والمراقبين لضمان صحة نظرية اللعبة. في آلية الأمن الاقتصادي ، تكون الأموال أكثر عرضة للخطر إذا كان المبلغ المحصن أقل من المبلغ الذي يمكن سرقته. من ناحية أخرى ، في الآليات الأمنية المتفائلة ، يمكن استغلال افتراض ثقة الأقلية إذا لم يقدم أي شخص دليلًا على الاحتيال ، أو إذا تم اختراق أو إزالة مراقبي الإذن. في المقابل ، آليات الأمن الاقتصادي أقل اعتمادًا على القدرة على الحفاظ على الأمن.
ينفذ
فيما يتعلق بالتنفيذ ، يتضمن أحد الأساليب سلسلة وسيطة مع المدققين الخاصين بها. في هذا الإعداد ، تراقب مجموعة من المدققين الخارجيين سلسلة المصدر وتتوصل إلى إجماع على صحة المعاملة عند اكتشاف استدعاء. بمجرد التوصل إلى توافق في الآراء ، فإنهم يقدمون البراهين على السلسلة المستهدفة. عادةً ما يُطلب من المدققين الحصول على قدر معين من الرموز المميزة ، والتي يمكن تقليلها إذا تم اكتشاف نشاط ضار. تتضمن أمثلة البروتوكولات التي تستخدم طريقة التنفيذ هذه شبكة Axelar و Celer IM.
طريقة أخرى للتنفيذ تتضمن استخدام وكلاء خارج السلسلة. تُستخدم الوكلاء خارج السلسلة لتنفيذ حلول متفائلة تشبه التراكمية. في غضون فترة زمنية محددة مسبقًا ، يمكن لهذه الوكلاء خارج السلسلة تقديم إثباتات الاحتيال وعكس المعاملات إذا لزم الأمر. على سبيل المثال ، يعتمد Nomad على وكلاء مستقلون خارج السلسلة لترحيل الرؤوس وبراهين التشفير. من ناحية أخرى ، تخطط ChainLink CCIP للاستفادة من شبكتها الحالية من oracles لمراقبة المعاملات عبر السلسلة والتصديق عليها.
نقاط القوة والتحديات
تتمثل الميزة الرئيسية لحلول AMP النظرية للعبة في تحسين الموارد ، حيث تكون عملية التحقق عادةً خارج السلسلة ، مما يقلل من متطلبات الموارد. علاوة على ذلك ، فإن هذه الآليات قابلة للتطوير حيث تظل آلية الإجماع كما هي بالنسبة لأنواع مختلفة من السلاسل ويمكن توسيعها بسهولة لتشمل سلاسل الكتل غير المتجانسة.
هناك أيضًا العديد من التحديات المرتبطة بهذه الآليات. إذا تواطأت غالبية المدققين ، فيمكن استغلال افتراضات الثقة لسرقة الأموال ، مما يتطلب تدابير مضادة مثل التصويت التربيعي وإثبات الغش. علاوة على ذلك ، تقدم الحلول القائمة على الأمان المتفائل تعقيدات من حيث النهاية والحيوية ، حيث يحتاج المستخدمون والتطبيقات إلى انتظار النوافذ الاحتيالية لضمان صحة المعاملات.
ثق بالبشر
يمكن أيضًا تقسيم الحلول التي تتطلب الثقة في الكيانات البشرية على نطاق واسع إلى فئتين:
أمن السمعة: تعتمد هذه الحلول على تطبيقات متعددة التوقيعات ، حيث تقوم كيانات متعددة بالتحقق من المعاملات وتوقيعها. بمجرد الوصول إلى الحد الأدنى ، تعتبر المعاملة صالحة. الافتراض هنا هو أن معظم الكيانات صادقة ، وإذا وقعت غالبية هذه الكيانات على معاملة معينة ، فإن هذه المعاملة تكون صالحة. الشيء الوحيد المعرض للخطر هنا هو سمعة الكيانات المعنية. تتضمن بعض الأمثلة ؛ Multichain (Anycall V؛ 6؛) و Wormhole. لا تزال الثغرات موجودة بسبب الثغرات الأمنية في العقود الذكية ، كما يتضح من اختراق Wormhole في أوائل عام 2022.
الاستقلالية: قسمت هذه الحلول عملية المراسلة بأكملها إلى جزأين وتعتمد على كيانات مستقلة مختلفة لإدارة العمليتين. الافتراض هنا هو أن هذين الكيانين مستقلين عن بعضهما البعض ولا يمكنهما التواطؤ. LayerZero مثال على ذلك. يتم إرسال رؤوس الكتل عند الطلب من خلال أوراكل الموزعة ، ويتم إرسال إثباتات المعاملات من خلال المرحلات. إذا تطابق الإثبات مع الرأس ، تعتبر المعاملة صالحة. بينما يعتمد إثبات المطابقة على الكود / الرياضيات ، يحتاج المشاركون إلى الوثوق في أن هذه الكيانات تظل مستقلة وليس لها نوايا خبيثة. التطبيقات المبنية على ؛ LayerZero ؛ يمكن أن تختار أوراكلها ومرحلاتها (أو تستضيف أوراكل / مرحلات خاصة بها) ، وبالتالي تحد من المخاطر على الأفراد / المرحلات. يحتاج المستخدمون النهائيون إلى الوثوق في أن LayerZero أو الجهات الخارجية أو التطبيق نفسه يقوم بتشغيل أوراكل وترحيل بشكل مستقل ، دون أي نية خبيثة.
في كلا النهجين ، فإن سمعة كيانات الطرف الثالث المشاركة تردع السلوك الضار. عادة ما تكون هذه الكيانات تحظى باحترام كبير في مجتمع المدقق و oracle ، وإذا تصرفت بشكل ضار ، فإنها تخاطر بإلحاق الضرر بالسمعة والتأثير السلبي على الأنشطة التجارية الأخرى.
اعتبارات إضافية لحلول AMP
عند النظر في أمان حل AMP وقابليته للاستخدام ، نحتاج أيضًا إلى النظر في تفاصيل تتجاوز الآليات الأساسية. نظرًا لأن هذه مكونات يمكن أن تتغير بمرور الوقت ، فإننا لم ندرجها في المقارنة الشاملة.
تكامل الكود
استغلت الاختراقات الحديثة أخطاء التعليمات البرمجية ، مما سلط الضوء على الحاجة إلى تدقيق قوي ، ومكافآت الأخطاء ، وعمليات تنفيذ متنوعة للعملاء. إذا قام جميع المدققين (في المجال الاقتصادي / المتفائل / الأمن المتعلق بالسمعة) بتشغيل نفس العميل (برنامج للتحقق) ، فإنه يزيد من الاعتماد على قاعدة بيانات واحدة ويقلل من تنوع العميل. على سبيل المثال ، تعتمد Ethereum على العديد من عملاء التنفيذ مثل geth و netermind و erigon و besu و akula. قد تؤدي التطبيقات المتعددة بلغات مختلفة إلى زيادة التنوع ، مع عدم وجود عميل واحد يسيطر على الشبكة ، مما يقضي على نقطة واحدة محتملة للفشل. يمكن أن يساعد وجود عملاء متعددين أيضًا في الحفاظ على الحيوية في حالة فشل عدد قليل من المدققين / المُوقِّعين / العملاء الخفيفين بسبب خطأ / هجوم في تنفيذ معين.
الإعداد والترقية
يحتاج المستخدمون والمطورون إلى معرفة ما إذا كان بإمكان المدققين / المراقبين الانضمام إلى الشبكة بدون إذن ، وإلا فإن الثقة ستخفيها الكيانات التي تختار الإذن. يمكن أن تؤدي الترقيات إلى العقود الذكية أيضًا إلى ظهور نقاط ضعف يمكن أن تؤدي إلى هجمات وربما حتى تغيير افتراضات الثقة. يمكن تنفيذ حلول مختلفة للتخفيف من هذه المخاطر. على سبيل المثال ، في إنشاء مثيل حالي ، يمكن ترقية بوابة Axelar ولكنها تتطلب موافقة من اللجنة غير المتصلة بالإنترنت (عتبة 4/8) ، ومع ذلك ، في المستقبل القريب تخطط Axelar لمطالبة جميع المدققين بالموافقة الجماعية على أي ترقيات للبوابة. عقود Wormhole الأساسية قابلة للترقية وتتم إدارتها من خلال نظام إدارة Wormhole على السلسلة. يعتمد LayerZero على العقود الذكية غير القابلة للتغيير والمكتبات غير القابلة للتغيير لتجنب أي ترقيات ، ولكن يمكن دفع مكتبات جديدة ، وستحصل dapps التي تعين الإعدادات الافتراضية على إصدارات أحدث ، وتحتاج dapps التي تعين الإصدار يدويًا إلى تعيينها على الإصدار الجديد.
أقصى قيمة قابلة للاستخراج (MEV)
لا تتم مزامنة سلاسل الكتل المختلفة بواسطة ساعة مشتركة ولها أوقات نهائية مختلفة. لذلك ، قد يختلف ترتيب التنفيذ والتوقيت في السلسلة المستهدفة من سلسلة إلى أخرى. في عالم متعدد السلاسل ، يصعب تحديد MEV بوضوح. يقدم مقايضة بين الحياة وأمر التنفيذ. ستضمن القناة المرتبة تسليم الرسائل بالترتيب ، ولكن إذا انتهت مهلة الرسالة ، فسيتم إغلاق القناة. قد لا يفضل تطبيق آخر أي طلب ، لكن تسليم الرسائل الأخرى لن يتأثر.
اليقين سلسلة المصدر
من الناحية المثالية ، يجب أن تنتظر حلول AMP وصول سلسلة المصدر إلى نهايتها قبل إرسال معلومات الحالة الخاصة بسلسلة المصدر إلى سلسلة مستهدفة واحدة أو أكثر. سيضمن ذلك أن الكتل الموجودة في سلسلة المصدر بالكاد يمكن عكسها أو تغييرها. ومع ذلك ، توفر العديد من الحلول مراسلة فورية وتضع افتراضات ثقة حول النهاية من أجل توفير أفضل تجربة للمستخدم. في هذه الحالة ، إذا خضعت سلسلة المصدر لاستعادة الحالة بعد تسليم الرسالة وتمرير أصل الجسر ، فقد يؤدي ذلك إلى حالات مثل الإنفاق المزدوج لأموال الجسر. يمكن لحلول AMP إدارة هذه المخاطر بعدة طرق ، مثل وضع افتراضات نهائية مختلفة لسلاسل مختلفة اعتمادًا على مدى لامركزية السلسلة ، أو عن طريق إجراء مفاضلات بين السرعة والأمان. يمكن للجسور التي تستخدم حلول AMP أن تضع قيودًا على كمية الأصول التي يتم تجسيرها قبل أن تصل سلسلة المصدر إلى نهايتها.
الاتجاهات والتوقعات المستقبلية أمان قابل للتخصيص وإلحاق
لتقديم خدمة أفضل لحالات الاستخدام المتنوعة ، يتم تحفيز حلول AMP لتوفير المزيد من المرونة للمطورين. يقدم Axelar طريقة لتمكين قابلية التوسع في المراسلة والتحقق من الصحة دون تغيير منطق طبقة التطبيق. يقدم HyperLane V2 وحدات تسمح للمطورين بالاختيار من بين خيارات متعددة مثل الأمان الاقتصادي والأمان المتفائل والأمان الديناميكي والأمان المختلط. توفر CelerIM أمانًا متفائلًا إضافيًا بالإضافة إلى الأمان الاقتصادي. تنتظر العديد من الحلول الحد الأدنى المحدد مسبقًا من تأكيدات الكتلة على سلسلة المصدر قبل تسليم الرسالة. يسمح LayerZero للمطورين بتحديث هذه المعلمات. نتوقع أن تستمر بعض حلول AMP في تقديم المزيد من المرونة ، ولكن خيارات التصميم هذه تتطلب بعض المناقشة. هل يجب أن تكون التطبيقات قادرة على تكوين أمانها ، وإلى أي مدى ، وماذا يحدث إذا تم تصميم التطبيقات بتصميم دون المستوى الأمثل؟ من المرجح أن يصبح وعي المستخدم بالمفاهيم الأساسية وراء الأمن ذا أهمية متزايدة. في النهاية ، نتوقع تجميع واستخراج حلول AMP ، ربما في شكل شكل من أشكال التكوين أو أمان "إضافي".
نضج آلية "كود الثقة والرياضيات"
في المرحلة النهائية المثالية ، سيتم تقليل الثقة في جميع الرسائل عبر السلاسل من خلال استخدام البراهين الصفرية المعرفة (ZK). لقد رأينا مشاريع مماثلة تظهر مثل Polymer Labs و Succinct Labs. نشرت Multichain أيضًا ورقة بيضاء zkRouter حول إمكانية التشغيل البيني عبر براهين ZK. من خلال جهاز Axelar Virtual Machine الذي تم الإعلان عنه مؤخرًا ، يمكن للمطورين الاستفادة من Interchain Amplifier لإنشاء اتصالات جديدة بشبكة Axelar بدون إذن. على سبيل المثال ، بمجرد تطوير عملاء قويين للضوء وإثباتات ZK لحالة Ethereum ، يمكن للمطورين دمجهم بسهولة في شبكة Axelar لاستبدال أو تحسين الاتصالات الحالية. أعلنت شبكة سيلير عن Brevis ، وهي عبارة عن منصة ZK عبر سلسلة لإثبات البيانات والتي تمكّن dApps والعقود الذكية من الوصول إلى البيانات التعسفية وحسابها والاستفادة منها في العديد من سلاسل الكتل. نفذت سيلير أحد الأصول الموجه نحو المستخدم zkBridge باستخدام دائرة العميل الخفيف ZK للتسلسل المتقاطع بين Ethereum Goerli testnet و BNB Chain testnet. تناقش LayerZero في وثائقها إمكانية إضافة مكتبات رسائل برهان محسّنة جديدة في المستقبل. تستكشف المشاريع الأحدث مثل Lagrange تجميع البراهين المتعددة من سلاسل مصادر متعددة ، بينما يجعل Herodotus تخزين البراهين ممكنًا باستخدام براهين ZK. ومع ذلك ، سيستغرق هذا الانتقال وقتًا ، حيث يصعب توسيع نطاق هذا النهج عبر البلوكشين التي تعتمد على آليات وأطر إجماع مختلفة.
ZK هي تقنية جديدة ومعقدة نسبيًا يصعب تدقيقها ، وتكاليف التحقق الحالية وتوليد الإثبات ليست مثالية. نعتقد أنه على المدى الطويل ، لدعم التطبيقات عبر السلاسل القابلة للتطوير بدرجة كبيرة على blockchains ، من المحتمل أن تجمع العديد من حلول AMP بين البرامج التي يمكن التحقق منها مع البشر والكيانات الموثوق بهم للأسباب التالية:
من خلال مكافآت التدقيق والأخطاء ، يمكن التقليل من إمكانية استغلال الكود. بمرور الوقت ، سيصبح من السهل الوثوق بهذه الأنظمة حيث يصبح تاريخها دليلاً على أمانها.
سيتم تخفيض تكلفة إنتاج البراهين ZK. مع المزيد من البحث والتطوير حول ZKPs و ZKPs العودية وتجميع الإثبات وخطط الطي والأجهزة المتخصصة ، نتوقع أن تنخفض التكلفة الزمنية لإنشاء الأدلة والتحقق بشكل كبير ، مما يجعلها نهجًا أكثر فعالية من حيث التكلفة.
سوف تصبح blockchain أكثر دعمًا لـ ZK. في المستقبل ، ستتمكن zkEVM من تقديم أدلة موجزة على صلاحية التنفيذ ، وستكون الحلول الخفيفة القائمة على العميل قادرة على التحقق بسهولة من تنفيذ سلسلة المصدر والإجماع. في المرحلة النهائية من Ethereum ، من المخطط أيضًا "zk-SNARK كل شيء" ، بما في ذلك آلية الإجماع.
المؤهلات البشرية والسمعة والهوية
لا يمكن تغليف أمان نظام معقد مثل حل AMP بإطار عمل واحد فقط ويتطلب حلاً متعدد الطبقات. على سبيل المثال ، بالإضافة إلى الحوافز الاقتصادية ، يطبق أكسلار آلية تصويت تربيعية لمنع تركيز قوة التصويت بين مجموعة فرعية من العقد وتعزيز اللامركزية. يمكن أيضًا أن تكمل البراهين البشرية والسمعة والهويات الأخرى آليات الإعداد والإذن.
ختاماً
بروح Web3 المنفتحة ، قد نرى مستقبلًا تعدديًا حيث تتعايش مناهج متعددة. في الواقع ، يمكن للتطبيق أن يختار استخدام حلول متعددة للتشغيل البيني ، إما بطريقة زائدة عن الحاجة أو ليختار المستخدم مجموعة بناءً على المقايضات. بين مسارات "حركة المرور العالية" ، قد يتم إعطاء الأولوية للحلول من نقطة إلى نقطة ، بينما قد تهيمن نماذج المحور والتحدث على الذيل الطويل للسلسلة. في النهاية ، كمجتمع من المستخدمين والبناة والمساهمين ، سنشكل الشكل الأساسي لإنترنت Web3.
الارتباط الأصلي