صُمِّمت الآلة الافتراضية لـ إيثريوم (ETH) عام 2015 لتشغيل العقود الذكية، لا لإنتاج إثباتات تشفيرية. أما إثباتات المعرفة الصفرية فطُوِّرت للتحقق من صحة العمليات الحسابية بكلفة منخفضة وبسرية تامة، من دون أي مفهوم للتعامل مع "أوامر تشغيل" أو تعليمات برمجية على مستوى الآلة.
لسنوات بدا أن المنظومتين متناحرتان من حيث الفلسفة والتصميم.
لاحقاً، نجح مهندسون في دمجهما، وكانت النتيجة واحدة من أكثر طبقات البنية التحتية تعقيداً من الناحية التقنية في عالم الكريبتو.
ZkEVM – اختصاراً لـ Zero-Knowledge Ethereum Virtual Machine – هي محاولة لتشغيل عقود ذكية متوافقة مع إيثريوم، ثم إنتاج إثبات معرفة صفرية بصحة تنفيذها، من دون أن يُضطر المطوّرون إلى إعادة كتابة كودهم.
على الورق تبدو الفكرة بسيطة؛ عملياً، كان لا بد من حل مشكلات حيّرت القطاع بأكمله لما يقرب من خمس سنوات.
ملخص تنفيذي
- تقوم ZkEVM بتنفيذ عقود ذكية متوافقة مع إيثريوم، وتوليد إثبات معرفة صفرية يؤكد صحة التنفيذ، ما يتيح تسوية سريعة ورخيصة للمعاملات على شبكة إيثريوم الرئيسة.
- كلّما زادت درجة تطابق ZkEVM مع بيئة إيثريوم الأصلية، زادت صعوبة بنائها تعبوياً وحسابياً؛ وهذه الموازنة تمثل جوهر كل قرار تصميمي في هذا المجال.
- يستفيد المستخدمون من ضمانات أمان إيثريوم من دون تحمّل رسوم الغاز العالية على الشبكة الرئيسة، بينما يمكن للمطورين نشر عقود Solidity الحالية مع تعديلات طفيفة أو من دون تعديل.
ما الذي تفعله إثباتات المعرفة الصفرية فعلياً؟
قبل التطرق إلى جانب الآلة الافتراضية، يجب توضيح مفهوم إثبات المعرفة الصفرية وما ليس منه. إثبات المعرفة الصفرية هو أسلوب تشفيري يسمح لطرف (المُثبِت) بإقناع طرف آخر (المُتحقِّق) بصحة عبارة ما، من دون كشف البيانات التي تجعل هذه العبارة صحيحة.
المثال الكلاسيكي هو إثبات أنك تعرف كلمة المرور من دون إرسالها. في سياق البلوكتشين، تكون العبارة عادة حسابية: "لقد شغّلت هذا البرنامج على هذه المدخلات وحصلت على هذه المخرجات، ونفذت كل خطوة بشكل صحيح."
في هذه الحالة، يكون المتحقق عقداً ذكياً على شبكة إيثريوم (الطبقة الأولى)، يراجع الإثبات خلال جزء من الثانية، بدلاً من إعادة تنفيذ كل معاملة بنفسه.
تسمح إثباتات المعرفة الصفرية لشبكة من الطبقة الثانية بتجميع آلاف المعاملات دفعة واحدة، وإنتاج إثبات صغير الحجم يؤكد صحة جميعها، ثم نشر هذا الإثبات فقط على إيثريوم، ما يخفض الكلفة لكل مستخدم خفضاً جذرياً.
يهيمن نظامان رئيسيان اليوم على مشهد ZkEVM:
SNARKs (Succinct Non-interactive ARguments of Knowledge) تنتج إثباتات صغيرة وسريعة التحقق، لكنها تحتاج إلى ما يُعرف بـ "إعداد موثوق" (Trusted Setup).
STARKs (Scalable Transparent ARguments of Knowledge) لا تحتاج إلى إعداد موثوق وتُعد مقاومة للحوسبة الكمية، لكن حجم إثباتاتها أكبر.
معظم فرق ZkEVM تميل حالياً إلى أنظمة SNARK، لأن كلفة التحقق على شبكة إيثريوم الرئيسة عامل حرج لا يمكن تجاوزه.
اقرأ أيضاً: ترامب ميديا تلغي صفقة خزانة كرونوس بقيمة 6.42 مليار دولار مع Crypto.com
لماذا يصعب إثبات الآلة الافتراضية لإيثريوم؟
الآلة الافتراضية لإيثريوم بيئة تنفيذ تعتمد على المكدّس (Stack-based)، تضم أكثر من 140 تعليمة تشغيل (opcode)، ونظاماً معقداً لحساب الغاز، وهيكليات ذاكرة وتشعبات حالة راكمت عشر سنوات من الاستخدام في بيئات حقيقية.
كل تعليمة، من عملية جمع بسيطة ADD إلى الدوال التمهيدية التشفيرية مثل ECRECOVER، يجب أن تُترجم إلى قيود حسابية يمكن لنظام إثبات المعرفة الصفرية التعامل معها.
المشكلة أن أنظمة الإثبات هذه لا تتحدث سوى "لغة" رياضية ضيقة جداً، قائمة على الحقول المنتهية والمعادلات متعددة الحدود. الآلة الافتراضية لإيثريوم صُممت من دون أي اعتبار لهذه القيود. تعليمات مثل KECCAK256 (دالة الهاش الرئيسية في إيثريوم) تكاد تكون الأسوأ من منظور دوائر ZK لأنها تعتمد على عمليات على مستوى البِتات تتحول عند نمذجتها إلى ملايين القيود المكلفة.
هذا التباين خلق ما سُمي "مشكلة عدم توافق الـ EVM".
كان بإمكانك بناء رول آب ZK سريع ورخيص، لكنه لن يشغّل سوى برامج صُممت خصيصاً لبيئة صديقة لـ ZK.
أو يمكنك محاولة دعم الـ EVM بالكامل، لكن عندها تصبح عملية توليد الإثباتات بطيئة وباهظة إلى حد ينسف جدوى الحل.
جوهر التحدي الهندسي في ZkEVM هو تقليص هذه الفجوة إلى الحد الأدنى.
توليد إثبات ZK لعملية هاش واحدة باستخدام KECCAK256 يمكن أن يتطلب ملايين القيود الحسابية.
ومع احتواء الكتلة النموذجية على آلاف عمليات الهاش، استغرق توليد إثبات ZkEVM ساعات في الإصدارات الأولى، وما زال يحتاج إلى عتاد متخصّص اليوم.
اقرأ أيضاً: آرثر هايز يتوقع صعود بيتكوين إذا فتح الفيدرالي حوض سندات اليابان البالغ 1.373 تريليون دولار
الأنواع الأربعة لـ ZkEVM وماذا تعني للسوق؟
ليست كل ZkEVM متماثلة. قدّم الباحث في إيثريوم فيتاليك بوترين عام 2022 تصنيفاً أصبح مرجعاً، يقسم تطبيقات ZkEVM إلى أربعة أنواع بحسب درجة تطابقها مع بنية إيثريوم الحالية. فهم هذه الأنواع أسرع طريقة لتقييم أي مشروع ZkEVM.
النوع الأول (Type 1):
مكافئ بالكامل لإيثريوم. يثبت الانتقال في حالة الشبكة، وبنية الكتل، ودوال الهاش، وكل التفاصيل الدقيقة كما هي، من دون أي تعديل.
النتيجة أن عملاء إيثريوم الحاليين يمكنهم مزامنة هذه السلسلة مباشرة، وكل الأدوات تعمل "من الصندوق".
الثمن هو أن توليد الإثباتات بطيء ومكلف للغاية. لا توجد اليوم ZkEVM إنتاجية تعمل كنوع أول كامل، وإن كانت بعض الفرق تعمل نحو هذا الهدف.
النوع الثاني (Type 2):
مكافئ للـ EVM. يسمح ببعض التغييرات في الهياكل الداخلية للبيانات – مثل استبدال KECCAK بدالة هاش أكثر ملاءمة لـ ZK في شجرة الحالة – مع الحفاظ على تطابق كامل مع البايت كود الخاص بالـ EVM.
العقود الذكية تتصرف بالطريقة نفسها، ولا يلاحظ المطورون اختلافاً.
توليد الإثباتات هنا أسرع من النوع الأول، لكنه ما زال ثقيلاً. Scroll والإصدارات الأولى من Polygon zkEVM استهدفت هذا المستوى.
النوع الثالث (Type 3):
يسمح بتعديلات إضافية تكسر عدداً محدوداً من الحالات الحدّية (edge cases)، مثل بعض الدوال التمهيدية الخاصة.
معظم العقود القائمة تعمل كما هي، لكن جزءاً صغيراً قد يتطلب تعديلاً.
كلفة توليد الإثباتات تنخفض هنا بشكل ملحوظ.
معظم حلول ZkEVM التجارية التي أُطلقت بين 2023 و2024 تَمركزت عملياً بين النوعين الثاني والثالث في مراحلها الأولى.
النوع الرابع (Type 4):
بدلاً من إثبات بايت كود الـ EVM مباشرة، يتم تجميع كود Solidity أو Vyper إلى آلة افتراضية مخصّصة، مصممة لتكون صديقة لـ ZK.
هذا المسار هو الأسرع والأرخص من حيث الإثباتات، لكنه قد ينتج اختلافات سلوكية دقيقة، وبعض "حيل" الـ EVM منخفضة المستوى لن تعمل.
zkSync Era مثال بارز على هذا النهج، مستفيداً من مترجم خاص مبني على LLVM.
هذا التصنيف مهم للبنّائين.
مشروع يرغب في نقل بروتوكول DeFi ناضج من شبكة إيثريوم الرئيسة سيُفضِّل نوعاً ثانياً أو ثالثاً لضمان تطابق السلوك.
أما مشروع جديد من الصفر فقد يقبل بالانتقال إلى نوع رابع مقابل كلفة إثبات أقل وزمن نهائية أسرع.
اقرأ أيضاً: Anthropic تحجز 191 ميغاواط من كهرباء تكساس من عامل تعدين بيتكوين
كيف تعالج ZkEVM المعاملة خطوة بخطوة؟
قراءة رحلة معاملة واحدة من البداية للنهاية تساعد على تجسيد الهيكلية.
عندما يرسل المستخدم معاملة إلى شبكة ZkEVM، تحدث سلسلة من الخطوات:
أولاً، تصل المعاملة إلى المنسّق (Sequencer)، وهو عقدة مسؤولة عن ترتيب المعاملات وتجميعها في دفعات.
يقوم المنسّق بتنفيذ المعاملات، وتحديث حالة الطبقة الثانية، ومنح المستخدم "تأكيداً ناعماً" شبه فوري. في هذه المرحلة، تظهر الأرصدة الجديدة في محفظة المستخدم، لكن المعاملة لم تُستكمَل تسويتها التشفيرية بعد على إيثريوم.
ثانياً، تُنقل الدفعة إلى المُثبِت (Prover)، وهو برنامج – أو عتاد مخصص – يشغّل خوارزمية إثبات المعرفة الصفرية.
يأخذ المُثبِت حالة ما قبل التنفيذ، وسجل المعاملات، وحالة ما بعد التنفيذ، ويُنتج إثبات صلاحية يؤكد أن الانتقال في الحالة حُسب بشكل صحيح.
هذه الخطوة كثيفة حسابياً، وقد تستغرق من ثوانٍ إلى دقائق تبعاً للنظام والحمولة.
ثالثاً، يُرسَل الإثبات مع كمية صغيرة من بيانات المعاملات المضغوطة إلى عقد ذكي على إيثريوم يُسمى عقد التحقق (Verifier Contract).
يفحص هذا العقد الإثبات في استدعاء واحد على السلسلة، بكلفة غاز ثابتة تقريباً بغض النظر عن عدد المعاملات في الدفعة.
بعد التحقق، تُثبَّت جذر حالة الطبقة الثانية على إيثريوم، وتُعتبَر نهائية وآمنة بقدر أي معاملة على الشبكة الرئيسة.
اقرأ أيضاً: صندوق XRP ETF يظهر في إفصاح لصندوق كريبتو بقيمة 111 ألف دولار لدى بنك كندا الوطني
ZkEVM المعياري والتشغيل البيني عبر السلاسل
التصميم الأولي لـ ZkEVM افترض طبقة تسوية واحدة: إيثريوم. كل ما يُثبَت، يُسلَّم في النهاية هناك.
لكن بنية أحدث – ZkEVM المعياري – تفصل بين طبقة التنفيذ، وطبقة الإثبات، وطبقة التسوية، بحيث يمكن تركيب كل منها بشكل مستقل.
هنا يظهر دور مشاريع مثل Prom.
تقدّم Prom نفسها كحل طبقة ثانية من نوع ZkEVM معياري، يمكّن التشغيل البيني بين سلاسل متوافقة مع EVM وأخرى غير متوافقة معها.
بدلاً من إثبات التنفيذ والتسوية على إيثريوم فقط، ترسل Prom إثباتات إلى عدة سلاسل في الوقت نفسه، لتصنع "جسراً رياضياً" بين أنظمة كانت سابقاً معزولة عن بعضها من دون جسر موثوق.
أهمية النهج المعياري أنه يزيل الافتراض القائل إن إيثريوم هي سطح التسوية الوحيد الممكن.
إثبات ZkEVM في جوهره مجرد معادلات رياضية.
إذا امتلكت السلسلة A والسلسلة B عقد تحقق قادراً على فحص هذه المعادلات، يمكن لإثبات واحد أن يثبّت انتقال حالة على السلسلتين معاً في آن واحد.
بهذه الطريقة تتحول إثباتات ZK من أداة توسعة فقط إلى "بدائية" أساسية للتشغيل البيني عبر السلاسل.
بنى ZkEVM المعيارية تفصل التنفيذ عن التسوية، ما يعني أن إثبات صلاحية واحد يمكن التحقق منه على إيثريوم، أو على سلسلة غير متوافقة مع EVM، أو على كليهما، ليخلق مصدراً مشتركاً للحقيقة التشفيرية بين أنظمة كانت غير متوافقة تقنياً.
اقرأ أيضاً: TRON مرّرت 2.1 تريليون دولار من USDT، لكن مجمعات DeFi لديها انكمشت 1.9%
مقارنة ZkEVM مع التجميعات المتفائلة: نظرة مباشرة
المقارنة بين ZkEVM والتجميعات المتفائلة (Optimistic Rollups) تكاد تكون دائمة الحضور، ولسبب واضح: كلاهما يحاول حل المشكلة نفسها لكن بمنطق عكسي بالكامل.
التجميعات المتفائلة تنطلق من فرضية أن المعاملات صحيحة افتراضياً، ولا يعاد التحقق منها إلا إذا تقدّم أحدهم بدعوى احتيال خلال فترة نزاع محددة (غالباً سبعة أيام). هذا النهج يجعل تشغيلها أقل كلفة وأسهل في التطوير، لكنه يعني أن عمليات السحب نحو شبكة إيثريوم الرئيسية تستغرق أسبوعاً ما لم يستخدم المستخدم جسور سيولة. Arbitrum وOptimism هما أبرز شبكتين تعملان بهذا النموذج اليوم.
أما تجميعات ZkEVM فتعكس المعادلة تماماً: لا يُفترض صحة أي دفعة معاملات مسبقاً؛ كل دفعة تعتبر غير صالحة إلى أن يثبت العكس بواسطة البرهان التشفيري. هذا يفرض عبئاً حسابياً أعلى على جهة توليد البراهين، لكنه يسمح بتسوية عمليات السحب على إيثريوم خلال ساعات بدلاً من أيام، دون الاعتماد على “مراقبين أمناء” لاكتشاف الاحتيال.
من زاوية المستخدم، الفوارق العملية يمكن تلخيصها كالتالي:
- سرعة السحب: الكفة تميل بوضوح لصالح ZkEVM؛ نهائية المعاملة المعتمدة على البرهان تستغرق ساعات مقابل سبعة أيام لعمليات السحب الأصلية على التجميعات المتفائلة.
- كلفة المعاملة: التجميعات المتفائلة حالياً أرخص في كثير من الحالات، لأن توليد البراهين في ZkEVM يضيف كلفة إضافية. هذه الفجوة تضيق تدريجياً مع تحسن العتاد الخدمي والخوارزميات.
- نموذج الأمان: ZkEVM يقدم ضمانات صلاحية قائمة على التشفير الرياضي. التجميعات المتفائلة تعتمد على أمان اقتصادي عبر “براهين الاحتيال”؛ نموذج قوي لكنه ليس مكافئاً رياضياً للضمانات التشفيرية.
- التوافق مع EVM: أجيال ZkEVM الحديثة (Type 2/3) أغلقت الهوة إلى حد كبير، وباتت تدعم تقريباً كل أدوات إيثريوم الحالية، ما سحب من التجميعات المتفائلة إحدى أهم مزاياها التاريخية.
- مخاطر التوقف (Liveness): شبكات ZkEVM يمكن أن تتعطل إذا توقفت جهة التحقق (Prover). في المقابل، التجميعات المتفائلة تستمر في الإنتاج طالما أن المجمّع (Sequencer) يعمل.
لا يمكن إعلان نموذج واحد كحل أمثل للجميع. التطبيقات كثيفة الحجم التي تركّز على أقل كلفة ممكنة ويمكنها تحمل نافذة سحب طويلة تميل إلى اختيار التجميعات المتفائلة. أما التطبيقات التي تحتاج نهائية سريعة، أو تسوية عبر سلاسل متعددة، أو إثباتاً رياضياً لصحة التنفيذ، فتتجه أكثر نحو ZkEVM.
اقرأ أيضاً: سهم CoreWeave يقفز 11% بعد تضاعف إيرادات الربع الثاني مدفوعاً بطفرة الذكاء الاصطناعي
من المستفيد الفعلي من ZkEVM حالياً؟
ZkEVM لم يعد تقنية مستقبلية على الورق. هناك بالفعل شبكات حية تعمل بهذا النموذج، تضم قيماً مقفلة حقيقية ومستخدمين يدفعون رسوماً حقيقية. ومع ذلك، من المفيد فهم من يستفيد أكثر من كل طبقة في هذه المنظومة.
بروتوكولات DeFi التي تنتقل من شبكة إيثريوم الرئيسية تستفيد من بيئة تنفيذ شبه مطابقة (Type 2/3) مع خفض جذري في رسوم الغاز. بروتوكول كانت رسوم المعاملة الواحدة عليه تصل إلى 30 دولاراً على الشبكة الرئيسية، باستطاعته على ZkEVM تقديم معاملات بأقل من السنت الواحد، دون إعادة كتابة العقود الذكية.
الجسور والتطبيقات متعددة السلاسل تستفيد من بنى ZkEVM المعيارية التي تتيح نشر البراهين على أكثر من سلسلة. بدلاً من الاعتماد على جسر محكوم بتوقيع متعدد (Multisig)، وهو أكثر القطاعات تعرضاً للاختراق تاريخياً في سوق العملات المشفرة، يمكن للمستخدمين الركون إلى برهان رياضي يتم التحقق منه على السلسلة نفسها.
المؤسسات والشركات التي تبني تطبيقات مرخّصة أو شبه مرخّصة تحصل على بيئة تنفيذ مثبتة مع قابلية تدقيق مشفّرة. كل انتقال حالة في السلسلة يمكن إثبات صحته حسابياً، وهو عامل حاسم في قضايا الامتثال والحوكمة والمحاسبة.
المطورون الذين يطلقون مشاريع جديدة اليوم ينبغي أن يستوعبوا جيداً مفاضلة Type 4 مقابل Type 2 قبل اختيار الشبكة. إذا كنت تكتب عقود Solidity من الصفر وتبحث عن أعلى سرعة في توليد البراهين وأدنى رسوم ممكنة، فقد تكون شبكة Type 4 الأنسب. أما إذا كنت تهاجر ببروتوكول قائم ولا تستطيع تحمل اختلافات سلوكية أو مفاجآت في التنفيذ، فاختيار شبكة Type 2 أو Type 3 سيكون أكثر أماناً.
بالنسبة للمستخدم العادي، تُختبر ZkEVM ببساطة كسلسلة متوافقة مع إيثريوم: معاملات أرخص وأسرع، المحافظ نفسها تعمل دون تغيير، والرموز يمكن جسرها كما اعتاد المستخدم. الآلة التشفيرية المعقدة تحت الغطاء تبقى غير مرئية، وهذا تحديداً ما يفترض بالبنية التحتية الجيدة أن تكون عليه.
اقرأ أيضاً: Monad يسجل رقماً قياسياً بقيمة 868 مليون دولار TVL وسط ضعف في الطلب على MON
الخلاصة
ZkEVM ربما تمثل أعقد مسألة “تقارب” في التشفير التطبيقي: فرض لغة البراهين عديمة المعرفة على آلة افتراضية صُممت أصلاً دون بنية رياضية ملائمة لهذا الغرض.
الفرق التي نجحت في ذلك أمضت سنوات في معالجة تعارضات دوال التجزئة، وانفجار القيود الحسابية، والحاجة إلى عتاد للتوليد لم يكن متوافراً عملياً عندما كُتبت الأوراق البحثية الأولى.
المجال لا يزال في حالة تطور متسارع. أزمنة توليد البراهين تتقلص باطراد. شبكات لا مركزية لمولّدات البراهين بدأت في العمل. وهدف الوصول إلى تكافؤ كامل مع إيثريوم (Type 1) ما زال على الطاولة، مع تسارع واضح في وتيرة الاقتراب منه من قبل عدة فرق.
بالنسبة لأي طرف يبني على منظومة إيثريوم أو يستثمر فيها، فهم كيفية عمل ZkEVM فعلياً – بعيداً عن العناوين التسويقية – يمثل حجر الأساس لكل قرار استراتيجي لاحق.
اقرأ تالياً: دفعة تمويل الذكاء الاصطناعي بـ 500 مليار دولار من Nvidia تضع رموز حوسبة الكريبتو تحت المجهر
