مقدمة العملة

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

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

كيف ستبدو نهاية لعبة web3 المترابطة؟ نعتقد أن جميع الجسور ستتطور إلى رسائل عبر السلاسل أو بروتوكولات «تمرير الرسائل التعسفي» (AMP) لفتح حالات الاستخدام الجديدة، من خلال السماح للتطبيقات بتمرير رسائل عشوائية من المصدر إلى سلسلة الوجهة. سنرى أيضًا ظهور «مشهد آليات الثقة»، حيث يقوم البناة بإجراء مقايضات مختلفة في سهولة الاستخدام والتعقيد والأمان.

يحتاج كل حل من حلول AMP إلى إمكانيتين أساسيتين:

• التحقق: القدرة على التحقق من صحة الرسالة من سلسلة المصدر على سلسلة الوجهة
• Liveness: القدرة على نقل المعلومات من المصدر إلى الوجهة

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

نحن نقسم المشهد العام للتشغيل البيني بناءً على آلية الثقة وبنية التكامل.

آلية الثقة:

1. رمز الثقة/الرياضيات: بالنسبة لهذه الحلول، يوجد دليل على السلسلة ويمكن التحقق منه من قبل أي شخص. تعتمد هذه الحلول عمومًا على العميل الخفيف إما للتحقق من توافق سلسلة المصدر على سلسلة الوجهة أو التحقق من صحة انتقال الحالة لسلسلة المصدر على سلسلة الوجهة. يمكن جعل التحقق من خلال العملاء الخفيفين أكثر كفاءة من خلال براهين Zero Knowledge لضغط الحسابات الطويلة بشكل تعسفي دون اتصال بالإنترنت وتوفير تحقق بسيط على السلسلة لإثبات الحسابات.
2. نظرية لعبة الثقة: هناك افتراض ثقة إضافي عندما يتعين على المستخدم/التطبيق الوثوق بطرف ثالث أو شبكة من الأطراف الثالثة من أجل صحة المعاملات. يمكن جعل هذه الآليات أكثر أمانًا من خلال الشبكات غير المصرح بها إلى جانب نظريات الألعاب مثل الحوافز الاقتصادية والأمن المتفائل.
3. ثق بالبشر: تعتمد هذه الحلول على الصدق من غالبية المدققين أو استقلالية الكيانات التي تنقل معلومات مختلفة. إنها تتطلب الثقة في الأطراف الثالثة بالإضافة إلى الثقة في إجماع السلسلتين المتفاعلتين. الشيء الوحيد على المحك هنا هو سمعة الكيانات المشاركة. إذا وافق عدد كافٍ من الكيانات المشاركة على أن المعاملة صالحة، فإنها تعتبر صالحة.

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

بنية التكامل:

1. نموذج نقطة إلى نقطة: يجب إنشاء قناة اتصال مخصصة بين كل مصدر وكل وجهة.
2. نموذج Hub and Spoke: يجب إنشاء قناة اتصال باستخدام لوحة وصل مركزية تتيح الاتصال بجميع سلاسل الكتل الأخرى المتصلة بهذا المركز.

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

رمز الثقة/الرياضيات

كيف يتحقق العملاء الخفيفون من إجماع سلسلة المصدر على سلسلة الوجهة؟

العميل/العقدة الخفيفة عبارة عن برنامج يتصل بالعقد الكاملة للتفاعل مع البلوكشين. عادةً ما يقوم العملاء الخفيفون في سلسلة الوجهة بتخزين محفوظات رؤوس الكتل (بالتتابع) لسلسلة المصدر وهو ما يكفي للتحقق من المعاملات. يقوم الوكلاء خارج السلسلة مثل المرحلين بمراقبة الأحداث على سلسلة المصدر وإنشاء أدلة تضمين التشفير وإعادة توجيهها جنبًا إلى جنب مع رؤوس الكتل إلى العميل الخفيف في سلسلة الوجهة. يمكن للعملاء الخفيفين التحقق من المعاملة أثناء قيامهم بتخزين رؤوس الكتل بالتتابع ويحتوي كل رأس كتلة على تجزئة Merkle root التي يمكن استخدامها لإثبات الحالة. الميزات الرئيسية لهذه الآلية هي:

1. الأمان:

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

1. التنفيذ: يعتمد على توفر الدعم لأساسيات التشفير المطلوبة للتحقق

• إذا كان نفس النوع من السلسلة متصلاً (نفس إطار التطبيق وخوارزمية الإجماع)، فسيكون تنفيذ العميل الخفيف على كلا الجانبين هو نفسه. مثال: IBC لجميع السلاسل القائمة على Cosmos SDK.
• إذا تم توصيل نوعين مختلفين من السلاسل (أطر تطبيق مختلفة أو أنواع إجماع)، فسيختلف تنفيذ العميل الخفيف. مثال: يعمل التمويل القابل للتكوين على تمكين سلاسل Cosmos SDK من الاتصال عبر IBC بـ Substrate (إطار تطبيق نظام Polkadot البيئي). يتطلب ذلك عميل Tendermint الخفيف في سلسلة الركيزة وما يسمى بالعميل الخفيف الثقيل المضاف إلى سلسلة Cosmos SDK.

1. التحديات:

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

كيف تتحقق براهين ZK من صحة انتقال الحالة لسلسلة المصدر على سلسلة الوجهة؟

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

1. الأمان: تعتمد ZK-snarks على المنحنيات البيضاوية لأمنها وتعتمد ZK-starks على وظائف التجزئة. قد تتطلب ZK-snarks أو لا تتطلب إعدادًا موثوقًا به. لا يلزم الإعداد الموثوق به إلا في البداية والذي يشير إلى حدث الإنشاء الأولي للمفاتيح المستخدمة لإنشاء البراهين المطلوبة للتحقق من تلك البراهين. إذا لم يتم إتلاف الأسرار في حدث الإعداد، فيمكن استخدامها لتزوير المعاملات عن طريق عمليات التحقق الكاذبة. لا يتم تقديم افتراضات الثقة بمجرد الانتهاء من الإعداد الموثوق به.
2. التنفيذ: توجد اليوم مخططات مختلفة لإثبات ZK مثل SNARK و STARK و VPD و SNARG وهي حاليًا الأكثر اعتمادًا على نطاق واسع. تعد براهين ZK المتكررة تطورًا آخر يسمح بتقسيم العمل الكلي للإثبات بين أجهزة كمبيوتر متعددة بدلاً من جهاز واحد فقط. لإنشاء أدلة الصلاحية، يجب تنفيذ الأساسيات الأساسية التالية:

• التحقق من نظام التوقيع المستخدم من قبل المدققين
• إدراج إثبات المفاتيح العامة للمدقق في التزام مجموعة أدوات التحقق (التي يتم تخزينها على السلسلة)
• تتبع مجموعة المدققين التي يمكن أن تستمر في التغيير بشكل متكرر

1. التحديات:

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

1. أمثلة: بوليمر ZK-IBC من مختبرات البوليمر، مختبرات سكسينكت. تعمل Polymer على IBC الممكّن متعدد القفزات لزيادة الاتصال مع تقليل عدد الاتصالات الزوجية المطلوبة.

نظرية لعبة الثقة

يمكن تقسيم بروتوكولات التشغيل البيني التي تعتمد على نظريات الألعاب على نطاق واسع إلى فئتين بناءً على كيفية تحفيز السلوك الصادق من الكيانات المشاركة:

1. الأمن الاقتصادي: يصل العديد من المشاركين الخارجيين (مثل المدققين) إلى توافق في الآراء بشأن الحالة المحدثة لسلسلة المصدر. يشبه هذا الإعداد متعدد التوقيعات ولكن لكي يصبحوا مدققين، يُطلب من المشاركين مشاركة كمية معينة من الرموز، والتي يمكن خفضها في حالة اكتشاف أي نشاط ضار. في الإعدادات غير المصرح بها، يمكن لأي شخص تجميع الرهانات وأن يصبح مدققًا. هناك أيضًا مكافآت جماعية، لتكون بمثابة حوافز اقتصادية، عندما يتبع المدققون المشاركون البروتوكول. وبالتالي يتم تحفيز المشاركين اقتصاديًا ليكونوا صادقين. ومع ذلك، إذا كان المبلغ الذي يمكن سرقته أعلى بكثير من المبلغ المرصود، فقد يحاول المشاركون التواطؤ لسرقة الأموال. أمثلة: أكسيلار، سيلير إيم
2. الأمن المتفائل: تعتمد الحلول الأمنية المتفائلة على افتراض ثقة الأقلية الذي يفترض أن أقلية فقط من المشاركين في بلوكتشين يعيشون وصادقين ويتبعون قواعد البروتوكول. قد يتطلب الحل مشاركًا صادقًا واحدًا فقط للحصول على ضمان. المثال الأكثر شيوعًا هو الحل الأمثل حيث يمكن لأي شخص تقديم دليل على الاحتيال. هناك أيضًا حافز اقتصادي هنا ولكن من الممكن عمليًا حتى لمراقب نزيه أن يفوت صفقة احتيالية. كما تستفيد عمليات التجميع المتفائلة من هذا النهج. أمثلة: نوماد، تشين لينك CCIP

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

الميزات الرئيسية لهذه الآليات هي:

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

• السلسلة الوسطى مع المدققين الخاصين بها: تقوم مجموعة من المدققين الخارجيين بمراقبة سلسلة المصدر، والتوصل إلى توافق في الآراء بشأن صحة المعاملة كلما تم اكتشاف مكالمة، وتقديم شهادة على سلسلة الوجهة إذا تم التوصل إلى توافق في الآراء. عادةً ما يُطلب من المدققين مشاركة كمية معينة من الرموز التي يمكن خفضها إذا تم اكتشاف نشاط ضار. أمثلة: الشبكة المحورية، SIM Celer
• عبر وكلاء خارج السلسلة: يمكن استخدام الوكلاء خارج السلسلة لتنفيذ حل متفائل يشبه التجميع حيث خلال فترة زمنية محددة مسبقًا، سيتم السماح للوكلاء خارج السلسلة بتقديم إثبات الاحتيال وإعادة المعاملة. مثال: يعتمد Nomad على وكلاء مستقلين خارج السلسلة لترحيل العنوان وإثبات التشفير. ستستفيد ChainLink CCIP من شبكة أوراكل الحالية لمراقبة المعاملات عبر السلاسل وإثباتها.

1. التحديات:

• يمكن استغلال افتراضات الثقة لسرقة الأموال إذا تواطأت غالبية المدققين، الأمر الذي يتطلب اتخاذ تدابير مضادة مثل التصويت التربيعي وأدلة الاحتيال.
• النهاية: تقدم حلول AMP المتفائلة القائمة على الأمان تعقيدًا في النهاية والحيوية لأن المستخدمين والتطبيقات بحاجة إلى انتظار نافذة الاحتيال.

1. المزايا:

• تحسين الموارد: لا يتطلب هذا النهج عادةً الكثير من الموارد لأن التحقق لا يحدث عادةً على السلسلة
• القابلية للتوسعة: هذا النهج أكثر قابلية للتوسعة حيث تظل آلية الإجماع كما هي لجميع أنواع السلاسل ويمكن توسيعها بسهولة إلى سلاسل الكتل غير المتجانسة.

ثق بالبشر

1. افتراض صدق الأغلبية: تعتمد هذه الحلول على تطبيق متعدد التوقيعات حيث تقوم كيانات متعددة بالتحقق من المعاملات والتوقيع عليها. بمجرد تحقيق الحد الأدنى، تعتبر المعاملة صالحة. الافتراض هنا هو أن غالبية الكيانات صادقة وإذا وقعت غالبية هذه الكيانات على معاملة معينة، فهي صالحة. الشيء الوحيد على المحك هنا هو سمعة الكيانات المشاركة. أمثلة: سلسلة متعددة (Anycall V6)، ثقب دودي. لا تزال عمليات الاستغلال بسبب أخطاء العقد الذكي ممكنة، كما يتضح من اختراق Wormhole في أوائل عام 2022.
2. الاستقلالية: تقسم هذه الحلول عملية تمرير الرسائل بأكملها إلى قسمين وتعتمد على كيانات مستقلة مختلفة لإدارة العمليتين. الافتراض هنا هو أن الكيانين مستقلان عن بعضهما البعض ولا يتواطآن. مثال: الطبقة صفر. يتم بث رؤوس الكتل عند الطلب عن طريق الأوراكل اللامركزية ويتم إرسال أدلة المعاملات عبر المرحلات. إذا تطابق الإثبات مع العناوين، تعتبر المعاملة صالحة. بينما تعتمد مطابقة الإثبات على الكود/الرياضيات، يتعين على المشاركين الوثوق بالكيانات لتظل مستقلة. تتمتع التطبيقات المبنية على LayerZero بخيار اختيار Oracle و Relayer (أو استضافة Oracle/Relayer الخاصة بها)، مما يحد من المخاطر التي يتعرض لها تواطؤ أوراكل/ريلاير الفردي. يحتاج المستخدمون النهائيون إلى الثقة في أن LayerZero أو طرف ثالث أو التطبيق نفسه يقوم بتشغيل oracle and relayer بشكل مستقل وبدون نوايا ضارة.

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

ما وراء افتراضات الثقة ومستقبل قابلية التشغيل البيني

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

• تكامل الكود: استفاد عدد من الاختراقات في الماضي القريب من الأخطاء في الكود مما يتطلب عمليات تدقيق موثوقة ومكافآت أخطاء جيدة التخطيط وتطبيقات متعددة للعملاء. إذا قام جميع المدققين (في مجال الأمن الاقتصادي/المتفائل/المرتبط بالسمعة) بتشغيل نفس العميل (برنامج للتحقق)، فإن ذلك يزيد من الاعتماد على قاعدة بيانات واحدة ويقلل من تنوع العملاء. تعتمد إيثريوم، على سبيل المثال، على العديد من عملاء التنفيذ مثل geth و nethermind و Erigon و besu و akula. من المرجح أن تؤدي التطبيقات المتعددة في مجموعة متنوعة من اللغات إلى زيادة التنوع دون سيطرة أي عميل على الشبكة، وبالتالي القضاء على نقطة فشل واحدة محتملة. يمكن أن يساعد وجود العديد من العملاء أيضًا في تحقيق الحيوية في حالة تعطل أقلية من المدققين/الموقعين/العملاء الخفيفين بسبب الاستغلالات/الأخطاء في تطبيق واحد معين.
• الإعداد والترقية: يجب أن يكون المستخدمون والمطورون على دراية بما إذا كان بإمكان المدققين/المراقبين الانضمام إلى الشبكة بطريقة غير مصرح بها، وإلا فإن الثقة مخفية عن طريق اختيار الكيانات المرخص لها. يمكن أن تؤدي ترقيات العقود الذكية أيضًا إلى حدوث أخطاء يمكن أن تؤدي إلى عمليات استغلال أو حتى تغيير افتراضات الثقة. يمكن تنفيذ حلول مختلفة للتخفيف من هذه المخاطر. على سبيل المثال، في عملية الإنشاء الحالية، يمكن ترقية بوابات Axelar رهناً بموافقة لجنة غير متصلة بالإنترنت (حد 4/8)، ومع ذلك، تخطط Axelar في المستقبل القريب لمطالبة جميع المدققين بالموافقة بشكل جماعي على أي ترقيات للبوابات. العقود الأساسية لـ Wormhole قابلة للترقية وتتم إدارتها عبر نظام إدارة Wormhole على السلسلة. تعتمد LayerZero على العقود الذكية غير القابلة للتغيير والمكتبات غير القابلة للتغيير لتجنب أي ترقيات، ومع ذلك، يمكنها دفع مكتبة جديدة، وستحصل dapps ذات الإعدادات الافتراضية على الإصدار المحدث، وستحتاج dapps مع إصدارها المعين يدويًا إلى تعيينها على الإصدار الجديد.
• MEV: لا تتم مزامنة سلاسل الكتل المختلفة من خلال ساعة مشتركة ولها أوقات مختلفة حتى النهاية. ونتيجة لذلك، يمكن أن يختلف ترتيب ووقت التنفيذ على سلسلة الوجهة عبر السلاسل. من الصعب تحديد MEV في عالم متعدد السلاسل بوضوح. يقدم المفاضلة بين الحيوية وترتيب التنفيذ. ستضمن القناة المطلوبة التسليم المطلوب للرسائل ولكن سيتم إغلاق القناة في حالة انتهاء مهلة رسالة واحدة. قد يفضل تطبيق آخر سيناريو لا يكون فيه الطلب ضروريًا ولكن تسليم الرسائل الأخرى لا يتأثر.

الاتجاهات والنظرة المستقبلية:

• الأمان القابل للتخصيص والإضافي: لتقديم خدمة أفضل لحالات الاستخدام المتنوعة، يتم تحفيز حلول AMP لتوفير المزيد من المرونة للمطورين. قدمت Axelar نهجًا لترقية تمرير الرسائل والتحقق منها، دون أي تغييرات في منطق طبقة التطبيق. قدم HyperLane V2 وحدات تسمح للمطورين بالاختيار من بين خيارات متعددة مثل الأمن الاقتصادي والأمن المتفائل والأمان الديناميكي والأمان المختلط. تقدم CeleRim أمانًا متفائلًا إضافيًا إلى جانب الأمن الاقتصادي. تنتظر العديد من الحلول الحد الأدنى المحدد مسبقًا من تأكيدات الحظر على سلسلة المصدر قبل إرسال الرسالة. يسمح LayerZero للمطورين بتحديث هذه المعلمات. نتوقع أن تستمر بعض حلول AMP في تقديم المزيد من المرونة ولكن خيارات التصميم هذه تتطلب بعض المناقشة. هل يجب أن تكون التطبيقات قادرة على تكوين أمانها، وإلى أي مدى، وماذا يحدث إذا اعتمدت التطبيقات بنية تصميم دون المستوى؟ قد يصبح وعي المستخدم بالمفاهيم الأساسية وراء الأمان مهمًا بشكل متزايد. وفي نهاية المطاف، نتوقع تجميع حلول AMP وتجريدها، ربما في شكل من أشكال الأمان المركب أو «الإضافي».
• نمو ونضج آليات «كود الثقة/الرياضيات»: في نهاية اللعبة المثالية، سيتم تقليل الثقة في جميع الرسائل عبر السلاسل باستخدام براهين المعرفة الصفرية (ZK) للتحقق من الرسائل والحالات. نحن نشهد بالفعل هذا التحول مع ظهور مشاريع مثل Polymer Labs و Succint Labs. كما نشرت Multichain مؤخرًا ورقة عمل ZKRouter لتمكين قابلية التشغيل البيني من خلال براهين ZK. مع جهاز Axelar Virtual Machine الذي تم الإعلان عنه مؤخرًا، يمكن للمطورين الاستفادة من مضخم Interchain لإعداد اتصالات جديدة بشبكة Axelar بدون إذن. على سبيل المثال، بمجرد تطوير براهين العملاء الخفيفة القوية & ZK لحالة إيثريوم، يمكن للمطور دمجها بسهولة في شبكة Axelar لاستبدال اتصال موجود أو تحسينه. تتحدث LayerZero في وثائقها عن إمكانية إضافة مكتبات رسائل إثبات محسّنة جديدة في المستقبل. تستكشف المشاريع الأحدث مثل Lagrange تجميع البراهين المتعددة من سلاسل المصادر المتعددة، ويقوم Herodotus بجعل براهين التخزين مجدية من خلال براهين ZK. ومع ذلك، سيستغرق هذا الانتقال بعض الوقت حيث يصعب توسيع نطاق هذا النهج بين سلاسل البلوكشين التي تعتمد على آليات وأطر إجماع مختلفة. ZK هي تقنية جديدة ومعقدة نسبيًا يصعب تدقيقها، وحاليًا، لا يعد إنشاء التحقق والإثبات مثاليًا من حيث التكلفة. نعتقد أنه على المدى الطويل، لدعم التطبيقات متعددة السلاسل القابلة للتطوير بدرجة كبيرة على بلوكتشين، من المرجح أن تكمل العديد من حلول AMP الأشخاص والكيانات الموثوق بهم ببرامج يمكن التحقق منها للأسباب التالية:
• يمكن تقليل إمكانية استغلال الكود من خلال عمليات التدقيق ومكافآت الأخطاء. مع مرور الوقت، سيكون من الأسهل الوثوق بهذه الأنظمة لأن تاريخها سيكون بمثابة دليل على أمنها.
• ستنخفض تكلفة توليد براهين ZK. مع وجود المزيد من R & D في ZKPs، وZK العودية، وتجميع الأدلة، والأجهزة المتخصصة، نتوقع تقليل وقت وتكلفة إنشاء الإثبات والتحقق بشكل كبير، مما يجعله نهجًا أكثر فعالية من حيث التكلفة.
• ستصبح البلوكشين أكثر ملاءمة لـ zk. في المستقبل، ستتمكن zkEVMS من تقديم إثبات موجز لصلاحية التنفيذ، وستتمكن الحلول الخفيفة القائمة على العميل من التحقق بسهولة من كل من التنفيذ والإجماع على سلسلة المصدر على سلسلة الوجهة. وفي نهاية لعبة إيثريوم، هناك أيضًا خطط «لتحديد كل شيء» بما في ذلك الإجماع.
• إثبات الإنسانية/السمعة/الهوية: لا يمكن تضمين أمان الأنظمة المعقدة مثل حلول AMP من خلال إطار عمل واحد ويضمن طبقات متعددة من الحلول. على سبيل المثال، إلى جانب الحوافز الاقتصادية، نفذت Axelar التصويت التربيعي لمنع تركيز قوة التصويت بين مجموعة فرعية من العقد وتعزيز اللامركزية. يمكن للأدلة الأخرى على الإنسانية والسمعة والهوية أيضًا أن تكمل آليات الإعداد والإذن.

بروح الانفتاح على Web3، من المحتمل أن نرى مستقبلًا متعدد حيث تتعايش مناهج متعددة. في الواقع، قد تختار التطبيقات استخدام حلول متعددة للتشغيل البيني، إما بطريقة زائدة عن الحاجة، أو السماح للمستخدمين بالاختلاط والتوافق مع الكشف عن المقايضات. قد يتم إعطاء الأولوية للحلول من نقطة إلى نقطة بين مسارات «حركة المرور العالية»، في حين قد تهيمن نماذج المحور والمقطع على الذيل الطويل للسلاسل. في النهاية، الأمر متروك لنا، نحن المطورين الجماعيين والمستخدمين والبنائين والمساهمين، لتشكيل تضاريس الويب المترابطة 3.

نود أن نشكر بو دو وبيتر كيم من شركة بوليمر لابز، وجالين مور من شبكة أكسيلار، وأوما روي من شركة سكسينسينت لابز، وماك غلاسمان، وريان زاريك من لاير زيرو لمراجعتهم وتقديم ملاحظاتهم القيمة.

قائمة المراجع:

• أكسيلار: https://docs.axelar.dev/
• سيليريم: https://im-docs.celer.network/developer/celer-im-overview
• تشين لينك CCIP: https://blog.chain.link/introducing-the-cross-chain-interoperability-protocol-ccip/
• ديبريدج: https://docs.debridge.finance/
• IBC: https://tutorials.cosmos.network/academy/3-ibc/
• الطبقة صفر: https://layerzero.gitbook.io/docs/
• متعدد السلاسل: https://docs.multichain.org/getting-started/introduction
• البدوي: https://docs.nomad.xyz/nomad-101/introduction
• مختبرات البوليمر: https://polymerlabs.medium.com/
• مختبرات الإيجاز: https://blog.succinct.xyz/
• الثقب الدودي: https://docs.wormhole.com/wormhole/

قائمة قراءة إضافية:

• التنقل في جسور المراسلة التعسفية: إطار المقارنة: https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• إطار مخاطر L2Bridge: https://gov.l2beat.com/t/l2bridge-risk-framework/31
• هوراتيوس عند الجسر: https://maven11.substack.com/p/horatius-at-the-bridge

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

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