عندما تتخلى إيثيريوم عن EVM من أجل RISC-V: إعادة تصميم الهندسة التي قد تعيد تعريف حوسبة البلوكشين

يقف إيثريوم عند نقطة تحول. بينما قامت آلة إيثريوم الافتراضية (EVM) بتشغيل عقد من الابتكار في البلوكتشين على مدى عقد من الزمن—مؤسسة لتمهيد الطريق لـ DeFi وNFTs—بات من الواضح بشكل متزايد أن هذا الطبقة التنفيذية المصممة خصيصًا لم تُصمم للمستقبل الحاسوبي الذي بدأ الآن في الوصول. إن التحول نحو التحقق بصفر معرفة (ZK) وظهور بنية آلة عامة في معايير برمجة الأنظمة يجبر على مواجهة الواقع: هل يمكن لبنية إيثريوم القديمة التكيف، أم أنها بحاجة إلى إعادة تصور كاملة؟

وفقًا للباحثين الفنيين وقيادة مؤسسة إيثريوم، أصبح الجواب واضحًا بشكل لا لبس فيه. البروتوكول يخطو نحو استبدال EVM بـ RISC-V، وهي بنية مجموعة تعليمات مفتوحة المصدر تعد بكشف عن قابلية التوسع، وتقليل التعقيد، وتوحيد إيثريوم مع النظام البيئي الأوسع للحوسبة القابلة للتحقق.

أزمة الأداء التي لا يتحدث عنها أحد: لماذا لا يمكن لـ EVM مواكبة ZK

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

إليك الواقع الفني: اليوم، zkEVM لا يثبت مباشرة تنفيذ EVM. بدلاً من ذلك، يثبت مفسرًا تم تجميعه إلى رمز RISC-V. هذا الطبقة التجريدية الإضافية هي الجاني. تكلفة الأداء؟ التقديرات تتراوح بين 50 إلى 800 مرة أبطأ من التنفيذ الأصلي. حتى بعد تحسين مكونات أخرى—مثل التحول إلى خوارزميات تجزئة أكثر كفاءة—يبقى تنفيذ الكتل هو الاختناق، حيث يمثل 80-90% من وقت توليد الإثباتات.

كما أوجز فيتالك بوتيرين المشكلة: إذا كانت zkVM في النهاية تقوم بتجميع كل شيء إلى RISC-V على أي حال، فلماذا يجبر مطورو العقود الذكية على العمل من خلال وسيط EVM لا يضيف شيئًا سوى الحمل الزائد؟

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

الديون الفنية المدفونة في البروتوكول

اختيارات تصميم EVM كانت منطقية تمامًا في 2015، لكنها أصبحت الآن قيودًا متصلبة. فكر في ثلاثة مشاكل محددة:

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

إضافة المزيد من العقود المجمعة يتطلب فواصل هارد فورك مثيرة للجدل ويشمل رمز غلاف أكثر تعقيدًا من تنفيذ RISC-V بأكمله. استنتاج فيتالك: يجب على البروتوكول التوقف تمامًا عن إضافة العقود المجمعة.

بنية 256-بت لمجال الاستخدام الخاطئ. تم تصميم مكدس EVM البالغ 256-بت للقيم التشفيرية، لكن معظم العقود الذكية تعمل بأعداد صحيحة 32 أو 64-بت. هذا التفاوت يخلق معادلة كفاءة قاسية: الأرقام الصغيرة لا توفر موارد، بينما تضاعف أو تربع التعقيد. في أنظمة إثبات ZK، تتضخم هذه الكفاءة بشكل أكبر.

المكدس مقابل السجلات. بنية EVM المعتمدة على المكدس تتطلب أوامر أكثر من نموذج السجلات في RISC-V لأداء العمليات نفسها، مما يعقد تحسين المترجم ويزيد من عبء توليد الإثباتات.

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

RISC-V: لماذا المعيار المفتوح يتفوق على التصميم المخصص

RISC-V ليست تكنولوجيا مملوكة. إنها معيار مجموعة تعليمات مفتوح المصدر—وهو بمثابة مخطط مجاني لتصميم المعالج. اعتمادها لهذا الدور ليس عشوائيًا أو تجريبيًا.

لماذا البساطة قوة. تحتوي مجموعة التعليمات الأساسية لـ RISC-V على حوالي 47 أمرًا. هذا الحد الأدنى الجذري متعمد. قلة الأوامر تعني قاعدة شفرة موثوقة أصغر—أسهل في التدقيق، والتحقق الرسمي، وإثبات الأمان. كما أكد جيريمي بروستيل في مؤتمرات الصناعة، هذا التصميم “تقريبًا مثالي للآلة العامة ذات الحد الأدنى التي نحتاجها.”

نضج النظام البيئي عبر LLVM. باختيار معيار راسخ، تكسب إيثريوم الوصول إلى عقود من بنية المترجمين. من خلال دعم LLVM، يمكن للمطورين استخدام أي لغة برمجة رئيسية—مثل Rust، C++، Go، Python—وتجميعها مباشرة إلى RISC-V. هذا يلغي الحاجة لإعادة بناء نظام بيئي كامل من الصفر. أوضح جاستن دراك: “نحصل على دعم جميع اللغات عالية المستوى بواسطة LLVM مجانًا.”

التقارب مع zkVM يحدث بالفعل. لقد صوت السوق بالفعل. من بين أكبر عشر تطبيقات zkVM قادرة على إثبات كتل إيثريوم، اختارت تسع منها RISC-V. هذا ليس تكهنًا—إنه تصديق عملي. لقد حددت منظومة ZK على RISC-V كهدف تنفيذي، مما يجعل اعتماد إيثريوم ليس مقامرة بل توافق مع الاتجاه الذي يسير إليه القطاع.

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

حدود الأمان المدمجة في الأجهزة. يتضمن RISC-V بنية امتياز مع وضع المستخدم ووضع المشرف. تعمل العقود الذكية في وضع المستخدم ولا يمكنها الوصول مباشرة إلى حالة blockchain؛ بدلاً من ذلك، تصدر طلبات ECALL إلى نواة موثوقة. هذا يخلق حدود أمان يفرضها معمارية المعالج نفسها—أكثر متانة بكثير من الحماية بواسطة الصندوق الرمل البرمجي فقط. كما شرح دييغو من Cartesi: “كل هذه الآليات الوقائية جزء من معيار RISC-V.”

الانتقال على ثلاث مراحل: تقليل المخاطر عبر التدرج

لا يخطط إيثريوم لانتقال مفاجئ. يتبع الترحيل خارطة طريق متحفظة عمدًا:

المرحلة 1: RISC-V كبديل للعقود المجمعة. في البداية، يتوقف البروتوكول عن إضافة عقود مجمعة جديدة. بدلاً من ذلك، يتم تنفيذ الوظائف التشفيرية الجديدة من خلال برامج RISC-V البيضاء. يسمح هذا للمعمارية الجديدة باختبار الشبكة الرئيسية في بيئة خاضعة للرقابة ومنخفضة المخاطر قبل اعتمادها على نطاق أوسع.

المرحلة 2: coexistence بين الآلتين الافتراضيتين. تكتسب العقود الذكية القدرة على إعلان ما إذا كانت الشفرة النصية تستهدف EVM أو RISC-V. والأهم، يمكن للعقود في كلا البيئتين استدعاء بعضها عبر استدعاءات نظام ECALL المعيارية. يخلق هذا فترة هجينة حيث تعمل البنيتان معًا، مما يثبت التوافق قبل الترحيل الكامل.

المرحلة 3: EVM كعقد محاكاة. تعتبر النهاية أن الـ EVM بمثابة لغة عالية المستوى—عقد ذكي موثوق رسميًا يعمل بشكل أصلي على RISC-V L1. تظل التطبيقات القديمة مدعومة بشكل دائم، لكن نواة تنفيذ البروتوكول تصبح RISC-V بحتة، مما يبسط بشكل كبير تطوير العملاء وصيانته.

هذا النهج المرحلي يحول ترحيلًا كارثيًا محتملًا إلى تطور manageable.

إعادة توجيه النظام البيئي: الفائزون والخاسرون

لا يؤثر هذا التحول على جميع Layer 2 بشكل متساوٍ—بل يخلق فائزين وخاسرين.

الـ Optimistic Rollups تواجه تحديات معمارية. تعتمد مشاريع مثل Arbitrum وOptimism على أدلة الاحتيال: يتطلب الطعن في معاملة إعادة تنفيذها على L1. إذا تغيرت آلة الـ L1 من EVM إلى RISC-V، ينهار هذا النموذج الأمني. تواجه هذه المشاريع خيارًا: إما بذل جهود هندسية ضخمة لإعادة تصميم أدلة الاحتيال للمعمارية الجديدة، أو الانفصال تمامًا عن نموذج أمان إيثريوم. كلا الخيارين مكلف.

ZK Rollups تكتسب ميزة استراتيجية هائلة. لقد حددت مشاريع مثل Polygon وzkSync وScroll بالفعل على RISC-V داخليًا. إن وجود L1 “يتحدث لغتهم” يلغي طبقات الترجمة. ما تسميه مؤسسة إيثريوم “الـ Rollups الأصلية” يصبح ممكنًا: يصبح L2 نسخة متخصصة من بيئة تنفيذ L1، مشاركة الأدوات، والمترجمين، والبنية التحتية للتحقق الرسمي. النتيجة العملية: لم تعد فرق L2 تبني جسورًا بين VMs غير متوافقة، وتتكبد تكاليف تطوير أقل، وتتوافق اقتصاديات الغاز بشكل أكثر عقلانية.

تتحول تجربة المطورين. بدلاً من تعلم Solidity حصريًا، يكتب المطورون بـ Rust، Go، أو أي لغة مدعومة بواسطة LLVM. يمكن للعقود استخدام مكتبات ناضجة من النظام البيئي البرمجي الأوسع. يقارن فيتالك الأمر بـ Node.js: رمز على السلسلة وخارج السلسلة موحد في نفس اللغة، مع نفس الأدوات. هذا الحد من الحواجز سيعيد تشكيل من يمكنه المشاركة في تطوير البلوكتشين.

تحسن اقتصاديات المستخدم بشكل كبير. تنخفض تكاليف الإثبات بحوالي 100 ضعف. تنخفض رسوم المعاملات لـ L1 وL2 بشكل متناسب. يفتح هذا المجال لـ “Gigagas L1”—حوالي 10,000 معاملة في الثانية—مما يمكّن تطبيقات معقدة تتطلب كل من الإنتاجية والأمان.

سُقنتك لابز وSP1: إثبات أن الرؤية تعمل اليوم

الانتقال ليس نظريًا فقط. لقد أظهرت شركة سُقنتك لابز بالفعل مزايا RISC-V العملية من خلال SP1، وهو zkVM مفتوح المصدر يثبت أن الأطروحة المعمارية تعمل.

ابتكار SP1: يتبنى تصميمًا “مركزًا على العقود المجمعة” يحل عنق الزجاجة التشفيري لـ EVM دون خلق مشكلة التعقيد. العمليات المكثفة مثل تجزئة Keccak تعمل في دوائر ZK متخصصة، وتُستدعى عبر تعليمات ECALL القياسية. يجمع هذا بين أداء الأجهزة المخصصة ومرونة البرمجيات.

الأثر العملي فوري. يوفر منتج OP Succinct من سُقنتك لابز قدرات ZK على الـ Optimistic Rollups. النتيجة: بدلاً من الانتظار سبعة أيام للتأكيد النهائي والسحب، يتم إتمام المعاملات في حوالي ساعة واحدة. بالنسبة لنظام OP Stack بأكمله، يعالج هذا التحسين سرعة نقطة ألم حاسمة.

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

المخاطر الخفية: ما الذي لا يزال يمكن أن يسير بشكل خاطئ

على الرغم من مزايا RISC-V، فإن التحول يقدم مخاطر جديدة:

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

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

هذه المخاطر قابلة للحل لكنها ليست سهلة.

التخفيف: الدفاع في العمق

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

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

التوحيد القياسي لمنع التشتت. يجب أن تعتمد المجتمع على معيار واحد RISC-V، من المحتمل RV64GC مع ABI متوافق مع Linux. هذا يعظم دعم أدوات السلسلة ويمنع تشرذم النظام البيئي، مما يسمح للمطورين بالاستفادة الكاملة من مزايا نظام LLVM.

طبقة الإنترنت القابلة للتحقق: اللعبة الطويلة لإيثريوم

الانتقال من EVM إلى RISC-V ليس مجرد تحسينات أداء تدريجية. إنه إعادة تموضع إيثريوم من “آلة العقد الذكي” إلى أن تصبح أساس الثقة القابلة للتحقق للحوسبة الإنترنتية العامة.

يلخص فيتالك الهدف النهائي: “الهدف النهائي يشمل… جعل كل شيء ZK-snarkified.”

هذا التحول يعالج عمود “التنفيذ الرشيق” في إيثريوم—جزء من رؤية “إيثريوم الرشيق” الأوسع. يبسط البروتوكول من آلة موحدة ضخمة إلى طبقة تسوية وتوفر البيانات مصممة خصيصًا للحوسبة القابلة للتحقق. تسريع إثباتات الأجهزة (ASICs وFPGAs من SP1، Nervos، Cartesi) يصبح ممكنًا بمجرد استقرار مجموعة التعليمات حول RISC-V.

الانتقال حتمي ليس لأنه مثالي بمعزل، بل لأنه يتماشى مع مسار الحوسبة نفسه. تمثل إثباتات ZK الثالثة بعد التجزئة والتوقيعات. رهان إيثريوم هو أن من يوفر طبقة الثقة الأساسية للحوسبة القابلة للتحقق—الدمج الأصلي لبنية آلة عامة في برمجة الأنظمة—يسيطر على العصر القادم للإنترنت.

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

يبدأ التحول الآن. مشاريع مثل Ethproofs تجمع البيانات التعاونية اللازمة لتنفيذ هذا التحول. فرق مثل سُقنتك لابز تقدم المخططات العملية. خلال 6-12 شهرًا، توقع ظهور أول بدائل للعقود المجمعة تعمل برمز RISC-V على الشبكة الرئيسية لإيثريوم—معلنة بداية النهاية لـ آلة إيثريوم الافتراضية كما نعرفها.