Yellow.com

صُممت الآلة الافتراضية لـ إيثريوم (ETH) عام 2015 لتشغيل العقود الذكية، لا لإنتاج إثباتات تشفيرية. في المقابل، بُنيت إثباتات عدم المعرفة أساساً للتحقق من صحة العمليات الحسابية بكلفة منخفضة وبدرجة عالية من الخصوصية، دون أي إدراك لماهية تعليمات التشغيل (opcodes).

لسنوات طويلة، بدا أن المنظومتين غير قابلتين للتوفيق من حيث التصميم.

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

يرمز ZkEVM إلى “Zero-Knowledge Ethereum Virtual Machine”، أي الآلة الافتراضية لإيثريوم المبنية على إثباتات عدم المعرفة. الفكرة هي تشغيل عقود ذكية متوافقة بالكامل مع إيثريوم، ثم إثبات صحة تنفيذها باستخدام إثباتات ZK، من دون أن يُطلب من المطورين إعادة كتابة كودهم أو تعديل بيئة عملهم.

يبدو المفهوم بسيطاً نظرياً، لكن تطبيقه عملياً استلزم حل مشكلات أربكت القطاع بأكمله لنحو نصف عقد.

خلاصة سريعة

تنفذ ZkEVM عقوداً ذكية متوافقة مع إيثريوم وتولّد إثبات عدم معرفة يؤكد صحة التنفيذ، ما يسمح بتسوية سريعة ورخيصة للمعاملات على الشبكة الرئيسية.

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

يستفيد المستخدمون من ضمانات أمن إيثريوم دون تحمّل تكاليف الغاز المرتفعة على الشبكة الرئيسية، فيما يتمكن المطورون من نشر عقود Solidity الحالية مع تعديلات محدودة أو من دون أي تعديل.

ما الذي تفعله إثباتات عدم المعرفة فعلاً؟

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

المثال الكلاسيكي هو إثبات أنك تعرف كلمة المرور دون إرسالها. في سلاسل الكتل، تكون العبارة محل الإثبات عادةً حسابية: “لقد شغّلت هذا البرنامج على هذه المُدخلات، وحصلت على هذه المخرجات، وقمت بكل ذلك بشكل صحيح”.

في حالة ZkEVM، يكون المُتحقق عادةً عقداً ذكياً على طبقة إيثريوم الأساسية (Layer 1)، يتحقق من صحة الإثبات في أجزاء من الثانية، بدلاً من إعادة تنفيذ جميع المعاملات بنفسه.

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

يهيمن نظامان من أنظمة الإثبات حالياً على مشهد ZkEVM:
SNARKs (براهين معرفة موجزة ولا تفاعلية) تنتج إثباتات صغيرة وسريعة التحقق، لكنها تحتاج إلى “إعداد موثوق” (trusted setup).
STARKs (براهين معرفة قابلة للتوسع وشفافة) لا تحتاج إلى إعداد موثوق وتُعد مقاومة للحوسبة الكمية، لكنها تولّد إثباتات أكبر حجماً. معظم فرق ZkEVM تميل حالياً إلى استخدام أنظمة SNARK لأن كلفة التحقق على شبكة إيثريوم الرئيسية تبقى قيداً صارماً.

لماذا إثبات الآلة الافتراضية لإيثريوم بهذه الصعوبة؟

الآلة الافتراضية لإيثريوم بيئة تنفيذ قائمة على المكدّس (stack-based) تضم أكثر من 140 تعليمة تشغيل (opcode)، مع نظام محاسبة للغاز، وهيكلية ذاكرة معقدة، ومجموعة كبيرة من الحالات الحدّية التي تراكمت على مدى عقد من التشغيل الفعلي. يجب تمثيل كل تعليمة تشغيل، من عملية جمع بسيطة (ADD) إلى الدوال التشفيرية المسبقة التجميع مثل ECRECOVER، في صورة قيود حسابية يفهمها نظام إثبات ZK.

المشكلة أن أنظمة إثبات ZK تتعامل مع لغة رياضية ضيقة للغاية؛ فهي تعمل أصلاً على الحقول المنتهية والمعادلات متعددة الحدود. لم تُصمم الآلة الافتراضية لإيثريوم مع هذا النموذج في الاعتبار. تعليمات مثل KECCAK256 (دالة الهاش الأساسية في إيثريوم) غير صديقة تماماً لدوائر ZK، لأنها تعتمد بدرجة كبيرة على عمليات ثنائية على مستوى البِت، ما يتحول في دوائر ZK إلى مجموعات هائلة ومكلفة من القيود الحسابية.

هذا التباين ولّد ما عُرف بـ “مشكلة عدم توافق EVM مع ZK”. كان بإمكان المطورين بناء تجميعة (rollup) مبنية على ZK سريعة ورخيصة، لكنها لا تشغّل إلا برامج مكتوبة خصيصاً لبيئات صديقة لإثباتات ZK. أو يمكنهم محاولة دعم EVM كاملة، لكن عندها تصبح عملية توليد الإثبات بطيئة وباهظة إلى درجة تفقد عندها الفكرة جدواها. التحدي الهندسي لـ ZkEVM هو تقليص هذه الموازنة قدر الإمكان.

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

الأنواع الأربعة لـ ZkEVM وما تعنيه

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

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

النوع الثاني (Type 2): مكافئ لـ EVM
يسمح ببعض التغييرات الداخلية، مثل استبدال KECCAK بدالة هاش أكثر ملاءمة لإثباتات ZK في شجرة الحالة، لكنه يحافظ على توافق كامل مع بايت كود EVM. سلوك العقود الذكية متطابق، والمطورون لا يلاحظون أي فرق. توليد الإثبات هنا أسرع من Type 1 لكنه لا يزال ثقيلاً. مشروع Scroll والنسخ المبكرة من Polygon zkEVM تستهدف هذه الفئة.

النوع الثالث (Type 3): تعديلات إضافية مع كسر محدود لبعض الحواف
يجري تعديلات أوسع تكسر عدداً صغيراً من الوظائف الحدّية، مثل بعض الدوال المسبقة التجميع (precompiles). الغالبية الساحقة من العقود الحالية تستمر بالعمل دون تغيير. كلفة توليد الإثبات تنخفض بشكل ملموس. معظم حلول ZkEVM التجارية التي أطلقت خلال 2023-2024 بدأت بين Type 2 وType 3.

النوع الرابع (Type 4): آلة افتراضية مخصصة صديقة لـ ZK
هنا لا يتم إثبات بايت كود EVM مباشرة، بل تُترجم شيفرات Solidity أو Vyper إلى آلة افتراضية مخصصة مصممة لتكون أكثر ملاءمة لدوائر ZK. هذا الخيار هو الأسرع والأقل كلفة، لكنه قد ينتج اختلافات دقيقة في السلوك، وبعض الحيل منخفضة المستوى في EVM لن تعمل. zkSync Era تتبع هذا النهج من خلال مترجم مخصص مبني على LLVM.

هذا التصنيف مهم لبناة البروتوكولات. مشروع ينقل بروتوكول DeFi ناضج من الشبكة الرئيسية لإيثريوم سيُفضّل Type 2 أو Type 3 لضمان تطابق السلوك. أما مشروع يبدأ من الصفر فقد يقبل Type 4 مقابل كلفة إثبات أدنى وزمن نهائية أسرع.

كيف تعالج ZkEVM المعاملة خطوة بخطوة؟

تتضح بنية ZkEVM أكثر عند تتبّع معاملة واحدة من البداية إلى النهاية. عندما يرسل المستخدم معاملة إلى شبكة ZkEVM، يمر التسلسل بالمراحل التالية:

أولاً، تصل المعاملة إلى المُرتِّب (Sequencer)، وهو عقدة مسؤولة عن ترتيب المعاملات وتجميعها في دفعات. يقوم المُرتب بتنفيذ المعاملات، وتحديث حالة الطبقة الثانية، وتقديم “تأكيد مبدئي” للمستخدم. في هذه اللحظة يظهر في محفظة المستخدم أن رصيده تغيّر، لكن المعاملة لم تُنه بعد على إيثريوم من الناحية التشفيرية.

ثانياً، تُرسل دفعة المعاملات إلى المُثبت (Prover)، وهو برنامج أو عتاد متخصص لتنفيذ خوارزمية إثبات ZK. يأخذ المُثبت حالة ما قبل التنفيذ، وجميع المعاملات، وحالة ما بعد التنفيذ، ويولّد إثبات صلاحية يؤكد أن انتقال الحالة حُسب بشكل صحيح. هذه الخطوة كثيفة حسابياً وقد تستغرق من ثوانٍ إلى دقائق بحسب النظام.

ثالثاً، يُنشر الإثبات مع كمية صغيرة من بيانات المعاملات المضغوطة إلى عقد ذكي على إيثريوم يُسمى عقد المُتحقق (Verifier Contract).

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

ZkEVM المعيارية والتشغيل البيني بين السلاسل

التصميم الأصلي لـ ZkEVM افترض طبقة تسوية واحدة: إيثريوم. كل ما يُثبت، يُسوى على الشبكة الرئيسية لإيثريوم. لكن معمارية أحدث، تُعرف بـ ZkEVM المعيارية (Modular)، تفصل بين طبقة التنفيذ، وطبقة الإثبات، وطبقة التسوية، بحيث يمكن تركيب كل منها بشكل مستقل.

هنا تحديداً يبرز دور مشاريع مثل Prom.

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

أهمية هذا النهج أنه يزيل الافتراض القائل إن إيثريوم هي سطح التسوية الوحيد الممكن.

فالإثبات في ZkEVM في النهاية مجرد بنية رياضية. إذا امتلكت السلسلة (A) والسلسلة (B) عقد تحقق قادراً على فحص هذا الإثبات، يمكن لإثبات واحد أن يحسم انتقال الحالة على السلسلتين معاً في الوقت ذاته. عندها تتحول إثباتات ZK إلى أداة تشغيل بيني عامة، لا مجرد تقنية لتحسين قابلية التوسع.

تفصل معماريات ZkEVM المعيارية بين التنفيذ والتسوية، بحيث يمكن التحقق من نفس إثبات الصلاحية على إيثريوم أو على سلسلة غير متوافقة مع EVM أو على كلتيهما، لتوليد “حقيقة تشفيرية مشتركة” عبر أنظمة بيئية كانت سابقاً غير قابلة للتكامل.

مقارنة مباشرة بين ZkEVM والتجميعات المتفائلة Optimistic Rollups

المقارنة بين ZkEVM والتجميعات المتفائلة لم تعد ترفاً نظرياً، فكلتاهما تستهدف حل المشكلة نفسها لكن بمنطق مختلف تماماً.

التجميعات المتفائلة تنطلق من فرضية أن المعاملة سليمة افتراضياً، ولا تُراجع إلا إذا قدّم أحدهم «إثبات احتيال» خلال فترة نزاع محددة (عادةً سبعة أيام). هذا النموذج يجعل تشغيلها أقل كلفة وأسهل بناءً، لكنه يفرض زمناً طويلاً للسحب نحو الشبكة الرئيسية لإيثريوم، حيث تستغرق العملية أسبوعاً ما لم يستخدم المستخدم «جسور سيولة» متخصصة. شبكتا Arbitrum وOptimism هما أبرز تطبيقات هذا النهج اليوم.

أما تجميعات ZkEVM فتنطلق من العكس تماماً: لا تُعتبر أي دفعة معاملات صحيحة إلا بعد إرفاق «إثبات صلاحية» رياضي. هذا يرفع كلفة الحوسبة على جانب التحقق، لكنه يتيح تسوية السحوبات على شبكة إيثريوم في غضون ساعات، من دون الاعتماد على جهات مراقبة صادقة لاكتشاف الاحتيال.

من زاوية المستخدمين، يمكن تلخيص الفوارق العملية كالتالي:

سرعة السحب: تفوز ZkEVM بشكل واضح؛ إذ تُنجز نهائية المعاملة المعتمدة على الإثبات خلال ساعات، مقابل نحو سبعة أيام لعمليات السحب الأصلية على التجميعات المتفائلة.
تكلفة المعاملات: التجميعات المتفائلة أرخص حالياً في كثير من السيناريوهات، لأن توليد الإثباتات في ZkEVM يضيف تكلفة إضافية. لكن هذه الفجوة تضيق مع تحسن العتاد والخوارزميات الخاصة بالتوليد.
نموذج الأمان: ZkEVM تقدم ضمانات أمان مبنية على صحة رياضية (Validity Proofs)، في حين تعتمد التجميعات المتفائلة على أمان اقتصادي عبر إثباتات الاحتيال؛ قوي لكنه ليس مكافئاً من الناحية الرياضية.
التوافق مع EVM: أجيال ZkEVM الحديثة (النوع 2 و3) أغلقت معظم فجوة التوافق، وباتت تدعم تقريباً كل أدوات إيثريوم القائمة، ما أزال ميزة رئيسية كانت لصالح التجميعات المتفائلة.
مخاطر التوقف (Liveness): أنظمة ZkEVM يمكن أن تتوقف إذا تعطل «المُثبت» (Prover). أما التجميعات المتفائلة فتواصل العمل طالما أن الـ Sequencer يعمل.

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

من المستفيد فعلياً من ZkEVM في الوقت الحالي؟

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

بروتوكولات DeFi المنتقلة من الشبكة الرئيسية لإيثريوم تستفيد من بيئة تنفيذ تكاد تكون طبق الأصل (Type 2/3)، مع انخفاض حاد في تكاليف الغاز. بروتوكول كانت رسوم المبادلة فيه تصل إلى 30 دولاراً للصفقة الواحدة على الشبكة الرئيسية، يمكنه على ZkEVM تقديم معاملات بتكلفة أقل من السنت الواحد، من دون إعادة كتابة عقوده الذكية.

الجسور والتطبيقات متعددة السلاسل تستفيد من تصميمات ZkEVM المعيارية التي تُنشر إثباتاتها على أكثر من سلسلة. بدلاً من الاعتماد على جسور «Multisig» – وهي تاريخياً من أكثر النقاط تعرضاً للاختراق في عالم الكريبتو – يمكن للمستخدمين الاتكال على إثبات رياضي يتم التحقق منه على السلسلة.

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

المطورون الذين يبدؤون مشاريع جديدة اليوم عليهم فهم مفاضلة «Type 4 مقابل Type 2» قبل اختيار الشبكة. إذا كنت تكتب عقود Solidity من الصفر وتبحث عن أسرع إثبات وأدنى رسوم، فقد يكون Type 4 خياراً مناسباً. أما إذا كنت تهاجر بروتوكولاً قائماً ولا يمكنك المخاطرة بأي اختلافات سلوكية، فاختيار شبكة Type 2 أو Type 3 أكثر أماناً.

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

الخلاصة

ZkEVM تمثل واحداً من أعقد تحديات التقاطع بين التشفير التطبيقي والبنى اللامركزية: تحويل آلة افتراضية صُممت دون بنية رياضية صارمة إلى بيئة «تنطق» بلغة براهين عدم المعرفة.

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

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

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

اقرأ التالي: خطة إنفيديا لتمويل الذكاء الاصطناعي بـ500 مليار دولار تضع رموز "كريبتو الحوسبة" تحت المجهر

لماذا يمكن لـ ZkEVM تشغيل كود إيثريوم وإثباته بتقنية إثباتات عدم المعرفة