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

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

اقترح تغييرات رئيسية اثنين. الأول يتعلق بشجرة الحالة في إيثريوم، يمكنك اعتبارها كنوع من نظام فهرسة السجل. حاليًا، هي بنية معقدة تسمى شجرة ميركل بيتا sextuple Keccak (نعم، الاسم غريب بعض الشيء). الفكرة هي استبدالها بشجرة ثنائية بسيطة. عمليًا، بدلًا من اختيار الاتجاه عند تقاطع ذو ستة فروع، سيكون لديك خياران فقط: يسار أو يمين. النتيجة؟ تقليل طول فروع ميركل بحوالي 75%. بالنسبة للعملاء الخفيفين، هذا ضخم من حيث عرض النطاق الترددي.

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

التغيير الثاني أكثر إثارة للجدل: استبدال الـ EVM بـ RISC-V على المدى الطويل. RISC-V هو مجموعة تعليمات مفتوحة المصدر، أُنشئت في الأصل لشيء آخر، لكنها الآن تُستخدم في كل مكان في أنظمة إثبات ZK. المنطق بسيط: بما أن جميع المبرهنين يتحدثون بالفعل RISC-V، فلماذا تستخدم الآلة الافتراضية لغة أخرى مع طبقة ترجمة وسيطة؟ هذا غير فعال. مترجم RISC-V يتطلب بضع مئات من الأسطر البرمجية فقط.

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

الأرقام التي قدمها مذهلة: شجرة الحالة والآلة الافتراضية تمثل معًا أكثر من 80% من عنق الزجاجة في إثبات إيثريوم. بمعنى آخر، بدون لمس هذين المكونين، يمكنك نسيان قابلية التوسع الحقيقية في عصر ZK.

لكن بالطبع، ليس الجميع متفقًا. شركة Offchain Labs، الفريق وراء Arbitrum، نشرت ردًا فنيًا مفصلًا. حجتهم: RISC-V جيد لإثباتات ZK، لكنه ليس مناسبًا لتوصيل العقود. يميزون بين أمرين مهمين: أنت لا تحتاج أن يقود الناقل رافعة شوكية فقط لأن مستودعك يستخدم واحدة. هم يدافعون عن WebAssembly (WASM) لطبقة العقود، وحججهم قوية. يتم تنفيذ WASM بكفاءة على معدات قياسية، بينما معظم عقد إيثريوم لا تعمل على شرائح RISC-V. حتى أن Offchain Labs نفذت نموذجًا أوليًا: WASM للعقود، مُجمَّع إلى RISC-V لإثبات ZK. طبقتان، كل واحدة تؤدي وظيفتها.

ما يثير الاهتمام هو السياق الأوسع. قبل بضعة أشهر، شكك فيتاليك في ضرورة وجود خارطة طريق L2 مخصصة لإيثريوم. وL2 لا تتوتر، بل بدأت بشكل نشط في "إزالة إيثريوميتها". بوليجون وOP Labs يتحدثون الآن عن إيثريوم كمعيار تسوية أساسي، وليس كالبنية التحتية الرئيسية لهم. هذا تحول حقيقي في الاتجاه.

فيتاليك نفسه يعترف بأنه لا يوجد توافق واسع بعد على استبدال الـ EVM. تطوير شجرة الحالة أكثر تقدمًا مع الـ EIP-7864 الذي لديه مشروع ملموس بالفعل. لكن استبدال الـ EVM بـ RISC-V؟ لا يزال في مرحلة الخطة الاستراتيجية، بعيدًا عن أن يُدمج في الكود.

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

السؤال الحقيقي هو: هل هو تجديد مدروس أم حفرة لا نهاية لها تتسع؟ من المستحيل تحديد ذلك في الوقت الحالي. لكن شيء واحد مؤكد: إيثريوم لا تنوي أن تصبح نظامًا قديمًا مصلحًا في عصر ZK. كيف نزيل الإصلاحات وما النموذج الذي نضعه، هذا النقاش نفسه قد يكون أكثر قيمة من الإجابة النهائية.