خارطة طريق Interop "تتسارع": بعد ترقية Fusaka، قد يشهد تكامل Ethereum خطوة حاسمة

توجيهات Chainfeeds:

بدون ZK في الوقت الحقيقي، من الصعب تحقيق تجربة مستخدم Interop قابلة للاستخدام فعليًا.

مصدر المقال:

كاتب المقال:

imToken Labs

وجهة نظر:

imToken Labs: في 4 ديسمبر، تم تفعيل ترقية Fusaka الخاصة بـ Ethereum رسميًا على الشبكة الرئيسية، لكنها لم تكن ضخمة كما كانت ترقية Dencun في السابق، حيث تركزت أضواء السوق أكثر على توسيع Blob و PeerDAS، مع الكثير من النقاش حول المزيد من خفض تكاليف بيانات L2. لكن بعيدًا عن هذه الضجة، هناك اقتراح غير ملحوظ هو EIP-7825، الذي أزال أكبر عقبة أمام تحقيق L1 zkEVM والإثبات في الوقت الحقيقي على Ethereum، ويمكن القول إنه يمهد بهدوء الطريق لنهاية Interop. في هذه الترقية، كان تركيز الجميع تقريبًا على التوسعة: زيادة سعة Blob بمقدار 8 أضعاف، مع التحقق من PeerDAS عبر العينة العشوائية، مما جعل سرد تكلفة DA (توفر البيانات) جزءًا من الماضي. بالفعل، L2 الأرخص أمر جيد، لكن بالنسبة لمسار ZK طويل الأمد لـ Ethereum، فإن EIP-7825 هو المغير الحقيقي لقواعد اللعبة، لأنه يحدد حدًا أقصى للغاز لكل معاملة واحدة (حوالي 16.78 مليون Gas). كما هو معروف، تم رفع حد الغاز لكتلة Ethereum هذا العام إلى 60 مليون، لكن حتى مع زيادة الحد الأعلى باستمرار، نظريًا إذا كان هناك من يرغب في دفع Gas Price مرتفع جدًا، لا يزال بإمكانه إرسال "معاملة ضخمة" معقدة للغاية (Mega-Transaction)، تملأ سعة الكتلة البالغة 60 مليون Gas بالكامل، مما يؤدي إلى انسداد الكتلة بأكملها. فلماذا إذًا يجب تقييد حجم المعاملة الواحدة؟ في الواقع، هذا التغيير ليس له أي تأثير على التحويلات العادية للمستخدمين، لكنه مسألة حياة أو موت بالنسبة لـ ZK Prover (مولد الإثباتات)، وهذا مرتبط ارتباطًا وثيقًا بطريقة توليد الإثباتات في أنظمة ZK. على سبيل المثال، قبل EIP-7825، إذا احتوت الكتلة على "معاملة ضخمة" تستهلك 60 مليون Gas، كان على ZK Prover تنفيذ هذه المعاملة المعقدة للغاية بالتسلسل، دون إمكانية تقسيمها أو معالجتها بالتوازي، مثل طريق سريع بمسار واحد تسير عليه شاحنة ضخمة ببطء شديد، وجميع السيارات الصغيرة (المعاملات الأخرى) عالقة خلفها حتى تمر. وهذا بلا شك كان يحكم على "الإثبات في الوقت الحقيقي" بالإعدام — لأن وقت توليد الإثبات يصبح غير قابل للتحكم، وقد يستغرق عشرات الدقائق أو أكثر. أما بعد EIP-7825، حتى لو توسعت سعة الكتلة في المستقبل إلى 100 مليون Gas، فبما أن كل معاملة مقيدة إجباريًا بـ 16.78 مليون Gas، يتم تقسيم كل كتلة إلى "وحدات مهام صغيرة" يمكن التنبؤ بها، محدودة، وقابلة للمعالجة بالتوازي، ما يعني أن توليد الإثباتات على Ethereum تحول من "مشكلة منطقية معقدة" إلى "مشكلة قوة حوسبة فقط (Money Problem)": طالما يمكننا استثمار ما يكفي من قوة الحوسبة المتوازية، يمكننا معالجة هذه المهام الصغيرة المقسمة في وقت قصير جدًا، وبالتالي توليد إثباتات ZK للكتل الضخمة. ومع ذلك، على الرغم من أن EIP-7825 مهد الطريق الفعلي (قابلية المعالجة بالتوازي) للإثبات في الوقت الحقيقي من خلال تقييد حجم المعاملة الواحدة، إلا أن هذه مجرد وجه واحد للعملة، أما الوجه الآخر فهو كيف يمكن لـ Ethereum Mainnet الاستفادة من هذه القدرة؟ هذا يتعلق بأقوى سرد في خارطة طريق Ethereum — L1 zkEVM. لطالما اعتُبر zkEVM "الكأس المقدسة" لتوسعة Ethereum، ليس فقط لأنه يحل عنق الزجاجة في الأداء، بل لأنه يعيد تعريف آلية الثقة في البلوكشين، حيث يتمثل جوهر الفكرة في تمكين Ethereum Mainnet من توليد والتحقق من إثباتات ZK. بمعنى آخر، في المستقبل، بعد تنفيذ كل كتلة على Ethereum، يمكن إخراج إثبات رياضي قابل للتحقق، بحيث لا يحتاج العقد الأخرى (خاصة العقد الخفيفة و L2) إلى إعادة الحساب لتأكيد صحة النتائج — وإذا تم تضمين قدرة توليد إثباتات ZK مباشرة في طبقة بروتوكول Ethereum (L1)، فعندما يقوم Proposer بتجميع كتلة وتوليد إثبات ZK، لن يحتاج عقد التحقق إلى إعادة تنفيذ المعاملات، بل يكفي فقط التحقق من هذا الإثبات الرياضي الصغير للغاية.