تكديس المعاملات صفري المعرفة

تجميعات المعرفة الصفرية (ZK-rollups) هي حلول توسّع من الطبقة 2 تزيد من الإنتاجية على شبكة إيثريوم الرئيسية (Mainnet) عن طريق نقل الحسابات وتخزين الحالة خارج السلسلة. يمكن لـ ZK-rollups معالجة آلاف المعاملات دفعة واحدة ثم نشر بعض البيانات الموجزة البسيطة فقط على الشبكة الرئيسية. تلخص هذه البيانات التغييرات التي يجب إجراؤها على حالة إيثريوم وبعض الأدلة التشفيرية التي تثبت صحة هذه التغييرات.

المتطلبات الأساسية

يجب أن تكون قد قرأت وفهمت صفحتنا حول توسع إيثريوم والطبقة 2.

ما هي عمليات تجميع المعرفة الصفرية؟

تُجمّع تجميعات المعرفة الصفرية (ZK-rollups) المعاملات في دفعات (أو 'تُكدّسها') يتم تنفيذها خارج السلسلة. يؤدي الحساب خارج السلسلة إلى تقليل كمية البيانات التي يجب نشرها على بلوك شين. يقوم مشغلو ZK rollup بإرسال ملخص للتغييرات المطلوبة لتمثيل جميع المعاملات في دفعة واحدة بدلاً من إرسال كل معاملة على حدة. كما أنها تُصدر لإثبات صحة تغييراتها.

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

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

تكتب تجميعات المعرفة الصفرية (ZK-rollups) المعاملات إلى إيثريوم على أنها calldata. calldata هو المكان الذي يتم فيه تخزين البيانات المضمنة في الاستدعاءات الخارجية لوظائف العقود الذكية. تُنشر المعلومات الموجودة في calldata على البلوكتشين، مما يسمح لأي شخص بإعادة بناء حالة التجميع بشكل مستقل. تستخدم عمليات تجميع ZK تقنيات الضغط لتقليل بيانات المعاملات - على سبيل المثال، يتم تمثيل الحسابات بواسطة فِهْرِس بدلاً من عنوان، مما يوفر 28 بايتًا من البيانات. إن نشر البيانات على السلسلة يمثل تكلفة كبيرة لعمليات التجميع، لذا فإن ضغط البيانات يمكن أن يقلل الرسوم على المستخدمين.

كيف تتفاعل ZK-rollups مع إيثريوم؟ تجميعات المعرفة الصفرية وإيثريوم

سلسلة ZK-rollup عبارة عن بروتوكول خارج السلسلة يعمل على قمة بلوك شين إيثريوم ويتم إدارته بواسطة عقود إيثريوم الذكية على السلسلة. تنفذ ZK-rollups المعاملات خارج الشبكة الرئيسية، ولكنها تلتزم بشكل دوري بدفعات المعاملات خارج السلسلة لعقد التجميع على السلسلة. يعد سجل المعاملة هذا غير قابل للتغيير، تمامًا مثل سلسلة إيثريوم بلوك شين، و يشكل سلسلة ZK-rollup.

يتكون الهيكل الأساسي لـ ZK-rollup من المكونات التالية:

1. العقود على السلسلة: كما ذكرنا، يتم التحكم في بروتوكول تجميع المعرفة الصفرية بواسطة العقود الذكية التي تعمل على إيثريوم. يتضمن ذلك العقد الرئيس الذي يخزن الكتل المجمعة، ويتتبع الودائع، ويراقب تحديثات الحالة. يتحقق عقد آخر على السلسلة (عقد التحقق) من أدلة المعرفة الصفرية المقدمة من قبل منتجي الكتل. وبالتالي، يعمل الإيثريوم بمثابة الطبقة الأساسية أو "الطبقة 1" لـ ZK-rollup.

2. آلة افتراضية خارج السلسلة (VM): بينما يوجد بروتوكول تجميع المعرفة الصفرية على إيثريوم، فإن تنفيذ المعاملات وتخزين الحالة يحدثان على آلة افتراضية منفصلة مستقلة عن آلة إيثريوم الافتراضية (EVM). تُعد هذه الآلة الافتراضية خارج السلسلة بيئة التنفيذ للمعاملات على ZK-rollup وتعمل كطبقة ثانوية أو "طبقة 2" لبروتوكول ZK-rollup. تضمن أدلة الصلاحية التي تم التحقق منها على شبكة إيثريوم الشبكة الرئيسية صحة انتقالات الحالة في VM خارج السلسلة.

ZK-rollups هي "حلول التوسع الهجينة" - بروتوكولات خارج السلسلة تعمل بشكل مستقل ولكنها تستمد الأمان من إيثريوم. على وجه التحديد، تعمل شبكة إيثريوم على فرض صحة تحديثات الحالة على ZK-rollup وتضمن توفر البيانات وراء كل تحديث لحالة التجميع. ونتيجة لذلك، فإن تجميعات المعرفة الصفرية أكثر أمانًا بكثير من حلول التوسّع خارج السلسلة، مثل السلاسل الجانبية، المسؤولة عن خصائصها الأمنية، أو validiums، التي تتحقق أيضًا من المعاملات على إيثريوم بإثباتات الصلاحية، ولكنها تخزن بيانات المعاملات في مكان آخر.

: تعتمد ZK-rollups على بروتوكول إيثريوم الرئيسي لَمَّا يل:

توفر البيانات

تنشر ZK-rollups بيانات الحالة لكل معاملة تتم معالجتها خارج السلسلة إلى إيثريوم. باستخدام هذه البيانات، أصبح من الممكن للأفراد والشركات إعادة إنتاج حالة التجميع والتحقق من صحة السلسلة بأنفسهم. يجعل إيثريوم هذه البيانات متاحة لجميع المشاركين في الشبكة على أنها calldata.

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

يعد Onchain ضروريًا ليتمكن المستخدمون من التفاعل مع التجميع. بدون الوصول إلى بيانات الحالة، لا يستطيع المستخدمون الاستعلام عن رصيد حساباتهم أو بدء المعاملات (على سبيل المثال، عمليات السحب) التي تعتمد على معلومات الحالة.

نهائية المعاملة

يعمل الإيثريوم كطبقة تسوية لعمليات ZK-rollups: يتم الانتهاء من معاملات L2 فقط إذا قبل عقد L1 إثبات الصحة. يؤدي هذا إلى التخلص من خطر قيام المشغلين الضارين بإفساد السلسلة (على سبيل المثال، سرقة الأموال المجمعة) حيث يجب الموافقة على كل معاملة على الشبكة الرئيسية. زيادة على ذلك، يضمن إيثريوم عدم إمكانية فضح عمليات المستخدم بمجرد الانتهاء منها على L1.

مقاومة الرقابة

تستخدم معظم عمليات تجميع ZK "عقدة فرعية" (المشغل) لتنفيذ المعاملات وإنتاج الدفعات وإرسال الكتل إلى L1. في حين أن هذا يضمن الكفاءة، إلا أنه يزيد من خطر الرقابة: يمكن لمشغلي ZK-rollup الخبيثين فرض رقابة على المستخدمين من خلال رفض تضمين معاملاتهم في دفعات.

كإجراء أمني، تسمح ZK-rollups للمستخدمين بإرسال المعاملات مباشرة إلى عقد التجميع على الشبكة الرئيسية إذا كانوا يعتقدون أنهم يخضعون للرقابة من قبل المشغل. يتيح هذا للمستخدمين فرض الخروج من ZK-rollup إلى إيثريوم دون الحاجة إلى الاعتماد على إذن المشغل.

كيف تعمل ZK-rollups؟

المعاملات

يقوم المستخدمون في ZK-rollup بتوقيع المعاملات وإرسالها إلى مشغلي L2 للمعالجة والتضمين في الدفعة التالية. في بعض الحالات، يكون المشغل كيانًا مركزيًا، يُسمى المُسلسل، والذي ينفذ المعاملات ويجمعها في دفعات ويرسلها إلى L1. يعد جهاز التسلسل في هذا النظام الكيان الوحيد المسموح له بإنتاج كتل L2 وإضافة معاملات التجميع إلى عقد ZK-rollup.

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

كيفية نشر تجميعات المعرفة الصفرية لبيانات المعاملات على إيثريوم

كما هو موضح، يتم نشر بيانات المعاملات على إيثريوم على أنها calldata. calldata هي منطقة بيانات في عقد ذكي تُستخدم لتمرير الوسائط إلى دالة وتتصرف بشكل مشابه للذاكرة (memory). بينما لا يتم تخزين calldata كجزء من حالة إيثريوم، إلا أنها تظل على السلسلة كجزء من سجلات المحفوظات (opens in a new tab) لسلسلة إيثريوم. لا تؤثر calldata على حالة إيثريوم، مما يجعلها طريقة رخيصة لتخزين البيانات على السلسلة.

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

التزامات الحالة

يتم تمثيل حالة تجميع المعرفة الصفرية، والتي تشمل حسابات وأرصدة الطبقة الثانية، كشجرة ميركل. يتم تخزين تجزئة تشفيرية لجذر شجرة Merkle (جذر Merkle) في عقد onchain، مما يسمح لبروتوكول التجميع بتتبع التغييرات في حالة ZK-rollup.

يتم انتقال التجميع إلى حالة جديدة بعد تنفيذ مجموعة جديدة من المعاملات. يُطلب من المشغل الذي بدأ انتقال الحالة أن يحسب جذر حالة جديد ويرسله إلى عقد onchain. إذا تم التحقق من صحة دليل الصحة المرتبط بالدفعة من خلال عقد التحقق، يصبح جذر Merkle الجديد هو جذر الحالة الأساسي لـ ZK-rollup.

بالإضافة إلى حساب جذور الحالة، يقوم عامل ZK-rollup أيضًا بإنشاء جذر دفعة - جذر شجرة Merkle التي تتألف من جميع المعاملات في دفعة واحدة. عند إرسال دفعة جديدة، يقوم عقد التجميع بتخزين جذر الدفعة، مما يسمح للمستخدمين بإثبات تضمين معاملة (على سبيل المثال، طلب سحب) في الدفعة. سيتعين على المستخدمين تقديم تفاصيل المعاملة، وجذر الدفعة، وإثبات ميركل الذي يوضح مسار التضمين.

إثباتات الصلاحية

جذر الحالة الجديد الذي يقدمه مشغل ZK-rollup إلى عقد L1 هو نتيجة لتحديثات حالة التجميع. لنفترض أن أليس أرسلت 10 رموز إلى بوب، فإن المشغل ببساطة يقلل رصيد أليس بمقدار 10 ويزيد رصيد بوب بمقدار 10. يقوم المشغل بعد ذلك بتجزئة بيانات الحساب المحدثة وإعادة بناء شجرة Merkle المجمعة وإرسال جذر Merkle الجديد إلى العقد على السلسلة.

لكن عقد التجميع لن يقبل تلقائيًا التزام الحالة المقترح حتى يثبت المشغل أن جذر Merkle الجديد نتج عن تحديثات صحيحة لحالة التجميع. يقوم مشغل ZK-rollup بذلك عن طريق إنتاج دليل على الصحة، وهو عبارة عن التزام تشفيري موجز يتحقق من صحة المعاملات المجمعة.

تسمح أدلة الصحة للأطراف بإثبات صحة بيان ما دون الكشف عن البيان نفسه - ومن ثم، تُسمى أيضًا أدلة عدم المعرفة. تستخدم ZK-rollups أدلة الصلاحية لتأكيد صحة انتقالات الحالة خارج السلسلة دون الحاجة إلى إعادة تنفيذ المعاملات على إيثريوم. يمكن أن تأتي هذه الإثباتات في شكل ZK-SNARK (opens in a new tab) (حجة المعرفة الصفرية المختصرة غير التفاعلية) أو ZK-STARK (opens in a new tab) (حجة المعرفة الصفرية الشفافة القابلة للتوسع).

يساعد كل من SNARKs وSTARKs في إثبات سلامة الحوسبة خارج السلسلة في عمليات تجميع ZK، على الرغم من أن كل نوع من أنواع الإثبات لديه ميزات مميزة.

ZK-SNARKs

لكي يعمل بروتوكول ZK-SNARK، من الضروري إنشاء سلسلة مرجعية مشتركة (CRS): توفر CRS معلمات عامة لإثبات صحة الأدلة والتحقق منها. يعتمد أمان نظام الإثبات على إعداد CRS؛ فإذا وقعت المعلومات المستخدمة لإنشاء المعلمات العامة في حوزة جهات ضارة، فقد يتمكنون من إنشاء أدلة صحة كاذبة.

تحاول بعض تجميعات المعرفة الصفرية حل هذه المشكلة باستخدام حفل حساب متعدد الأطراف (MPC) (opens in a new tab)، يتضمن أفرادًا موثوقًا بهم، لتوليد معلمات عامة لدائرة ZK-SNARK. يساهم كل طرف بقدر من العشوائية (يُطلق عليه "النفايات السامة") في بناء نظام CRS، والذي يجب عليهم تدميره على الفور.

يتم استخدام الإعدادات الموثوقة لأنها تزيد من أمان إعداد CRS. طالما قام أحد المشاركين الصادقين بتدمير مدخلاته، فإن أمن نظام ZK-SNARK مضمون. ومع ذلك، فإن هذا النهج يتطلب الثقة في قدرة المشاركين على حذف العينات العشوائية وعدم تقويض ضمانات أمن النظام.

وبعيدًا عن افتراضات الثقة، فإن ZK-SNARKs تحظى بشعبية كبيرة بسبب أحجام الإثبات الصغيرة والتحقق في الوقت الثابت. نظرًا لأن التحقق من الإثبات على L1 يشكل التكلفة الأكبر لتشغيل ZK-rollup، فإن L2s تستخدم ZK-SNARKs لإنشاء أدلة يمكن التحقق منها بسرعة وبتكلفة منخفضة على Mainnet.

ZK-STARKs

مثل ZK-SNARKs، تثبت ZK-STARKs صحة الحوسبة خارج السلسلة دون الكشف عن المدخلات. ومع ذلك، تعتبر ZK-STARKs بمثابة تحسين على ZK-SNARKs بسبب قابليتها للتوسع وشفافيتها.

تعتبر ZK-STARKs "شفافة"، حيث يمكنها العمل بدون الإعداد الموثوق به لسلسلة مرجعية مشتركة (CRS). بدلاً من ذلك، تعتمد ZK-STARKs على العشوائية التي يمكن التحقق منها علنًا لإعداد المعلمات اللازمة لتوليد البراهين والتحقق منها.

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

تعتبر ZK-STARKs آمنة أيضًا ضد أجهزة الكمبيوتر الكمومية، في حين يُعتقد على نطاق واسع أن تشفير المنحنى الإهليلجي (ECC) المستخدم في ZK-SNARKs عرضة لهجمات الحوسبة الكمومية. الجانب السلبي لـ ZK-STARKs هو أنها تنتج أحجام إثبات أكبر، وهو أمر أكثر تكلفة للتحقق منه على إيثريوم.

كيف تعمل أدلة الصحة في ZK-rollups؟ إثباتات الصلاحية في تجميعات المعرفة الصفرية

توليد الدليل

قبل قبول المعاملات، سيقوم المشغل بإجراء الفحوص المعتادة. ويتضمن ذلك التأكيد على ما يلي:

• يعد حساب المرسل والمستقبل جزءًا من شجرة الحالة.
• لدى المرسل أموال كافية لمعالجة المعاملة.
• المعاملة صحيحة وتتطابق مع المفتاح العام للمرسل في التجميع.
• رَقْم المرسل صحيح، وما إلى ذلك.

بمجرد حصول عقدة ZK-rollup على عدد كافٍ من المعاملات، فإنها تجمعها في دفعة وتجمع المدخلات لدائرة الإثبات لتجميعها في دليل ZK موجز. ويتضمن ذلك:

• جذر شجرة ميركل يشتمل على جميع المعاملات في الدفعة.
• أدلة Merkle للمعاملات لإثبات الإدراج في الدفعة.
• يقوم Merkle بإجراء إثباتات لكل زوج من المرسل والمستقبل في المعاملات لإثبات أن هذه الحسابات هي جزء من شجرة حالة التجميع.
• مجموعة من جذور الحالة الوسيطة، المستمدة من تحديث جذر الحالة بعد تطبيق تحديثات الحالة لكل معاملة (أي تقليل حسابات المرسل وزيادة حسابات المستقبل).

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

يعكس جذر Merkle هذا التغيير الوحيد في حالة ZK-rollup: تغيير في رصيد المرسل وnonce. هذا ممكن لأن دليل ميركل المستخدم لإثبات وجود الحساب يستخدم لاستنباط جذر الحالة الجديد.

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

تتكرر العملية لكل معاملة؛ كل "حلقة" تنشئ جذر حالة جديد من تحديث حساب المرسل وجذر جديد لاحق من تحديث حساب المستقبل. كما تم شرحه، فإن كل تحديث لجذر الحالة يمثل جزءًا واحدًا من تغيير شجرة حالة التجميع.

تتكرر دائرة إثبات ZK على دفعة المعاملة بأكملها، للتحقق من تسلسل التحديثات التي تؤدي إلى جذر الحالة النهائي بعد تنفيذ المعاملة الأخيرة. يصبح جذر Merkle المحسوب الأخير هو جذر الحالة الأساسية الأحدث لـ ZK-rollup.

التحقق من الإثبات

بعد أن تقوم دائرة الإثبات بالتحقق من صحة تحديثات الحالة، يقوم مشغل L2 بإرسال دليل الصلاحية المحسوب إلى عقد التحقق على L1. تعمل دائرة التحقق الخاصة بالعقد على التحقق من صحة الإثبات وتتحقق أيضًا من المدخلات العامة التي تشكل جزءًا من الإثبات:

• جذر ما قبل الحالة: جذر الحالة القديم لتجميع المعرفة الصفرية (أي قبل تنفيذ المعاملات المجمعة)، والذي يعكس آخر حالة صالحة معروفة لسلسلة الطبقة الثانية.

• جذر ما بعد الحالة: جذر الحالة الجديد لتجميع المعرفة الصفرية (أي بعد تنفيذ المعاملات المجمعة)، والذي يعكس أحدث حالة لسلسلة الطبقة الثانية. جذر ما بعد الحالة هو الجذر النهائي المشتق بعد تطبيق تحديثات الحالة في دائرة الإثبات.

• جذر الدفعة: جذر ميركل للدفعة، مشتق من خلال بناء شجرة ميركل من المعاملات في الدفعة وتجزئة (هاش) جذر الشجرة.

• مدخلات المعاملات: البيانات المرتبطة بالمعاملات التي تم تنفيذها كجزء من الدفعة المرسلة.

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

الدخول والخروج

يدخل المستخدمون إلى ZK-rollup عن طريق إيداع الرموز في عقد التجميع المنشور على سلسلة L1. تم وضع هذه المعاملة في قائمة الانتظار نظرًا لأن المشغلين فقط هم من يمكنهم إرسال المعاملات إلى عقد التجميع.

إذا بدأت قائمة الإيداع المعلقة بالامتلاء، فسوف يقوم مشغل ZK-rollup بأخذ معاملات الإيداع وإرسالها إلى عقد التجميع. بمجرد أن تصبح أموال المستخدم موجودة في المجموعة، يمكنه البدء في إجراء المعاملات عن طريق إرسال المعاملات إلى المشغل للمعالجة. يمكن للمستخدمين التحقق من الأرصدة في التجميع عن طريق تجزئة بيانات حساباتهم، وإرسال التجزئة إلى عقد التجميع، وتوفير دليل Merkle للتحقق من جذر الحالة الحالية.

إن الانسحاب من ZK-rollup إلى L1 أمر بسيط. يقوم المستخدم ببدء معاملة الخروج عن طريق إرسال أصوله في التجميع إلى حساب محدد للحرق. إذا قام المشغل بتضمين المعاملة في الدفعة التالية، فيمكن للمستخدم إرسال طلب سحب إلى عقد onchain. سيتضمن طلب السحب هذا ما يلي:

• دليل Merkle الذي يثبت إدراج معاملة المستخدم في حساب الحرق في دفعة المعاملات

• بيانات المعاملات

• جذر الدفعة

• عنوان L1 لاستلام الأموال المودعة

يقوم عقد التجميع بتجزئة بيانات المعاملة، والتحقق مما إذا كان جذر الدفعة موجودًا، واستخدام دليل Merkle للتحقق مما إذا كانت تجزئة المعاملة جزءًا من جذر الدفعة. بعد ذلك، يقوم العقد بتنفيذ معاملة الخروج ويرسل الأموال إلى العنوان الذي اختاره المستخدم على L1.

تجميعات المعرفة الصفرية والتوافق مع آلة إيثريوم الافتراضية (EVM)

على عكس الرول أب التفاؤلي، فإن تجميعات المعرفة الصفرية ليست متوافقة بسهولة مع آلة إيثريوم الافتراضية (EVM). يعد إثبات حسابات EVM للأغراض العامة في الدوائر أكثر صعوبة ويتطلب موارد أكثر من إثبات الحسابات البسيطة (مثل نقل الرمز الموصوف سابقًا).

ومع ذلك، فإن التطورات في تقنية المعرفة الصفرية (opens in a new tab) تثير اهتمامًا متجددًا بتضمين حسابات آلة إيثريوم الافتراضية (EVM) في إثباتات المعرفة الصفرية. تهدف هذه الجهود إلى إنشاء تنفيذ EVM بدون معرفة (zkEVM) والذي يمكنه التحقق بكفاءة من صحة تنفيذ البرنامج. يقوم zkEVM بإعادة إنشاء أكواد EVM الموجودة لإثبات/التحقق في الدوائر، مما يسمح بتنفيذ العقود الذكية.

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

من المتوقع أن يساعد تقديم ZK-rollups المتوافقة مع EVM المطورين على الاستفادة من ضمانات قابلية التوسع والأمان لإثباتات المعرفة الصفرية. الأمر الأكثر أهمية هو أن التوافق مع البنية التحتية الأصلية لـ إيثريوم يعني أن المطورين يمكنهم بناء تطبيقات لامركزية صديقة لـ ZK باستخدام أدوات ولغات مألوفة (ومختبرة في المعارك).

كيف تعمل رسوم ZK-rollup؟

يعتمد المبلغ الذي يدفعه المستخدمون مقابل المعاملات على ZK-rollups على رسوم الغاز، تمامًا كما هو الحال في إيثريوم Mainnet. ومع ذلك، تعمل رسوم الغاز بشكل مختلف على L2 وتتأثر بالتكاليف التالية:

1. كتابة الحالة: هناك تكلفة ثابتة للكتابة على حالة إيثريوم (أي، إرسال معاملة على بلوكتشين إيثريوم). تعمل ZK-rollups على تقليل هذه التكلفة من خلال تجميع المعاملات وتوزيع التكاليف الثابتة على مستخدمين متعددين.

2. نشر البيانات: تنشر تجميعات المعرفة الصفرية بيانات الحالة لكل معاملة على إيثريوم على أنها calldata. تخضع تكاليف calldata حاليًا لمقترح تحسين الإيثريوم EIP-1559 (opens in a new tab)، الذي ينص على تكلفة 16 غازًا للبايتات غير الصفرية و4 غازات للبايتات الصفرية من calldata، على التوالي. تتأثر التكلفة المدفوعة لكل معاملة بكمية calldata التي يجب نشرها على السلسلة من أجلها.

3. رسوم مُشغِّل الطبقة الثانية (L2): هذا هو المبلغ المدفوع لمُشغِّل التجميع كتعويض عن التكاليف الحسابية المتكبدة في معالجة المعاملات، وتشبه إلى حد كبير "رسوم الأولوية (الإكراميات)" للمعاملات على شبكة إيثريوم الرئيسية (Mainnet).

4. إنشاء الإثبات والتحقق منه: يجب على مُشغِّلي تجميعات المعرفة الصفرية إصدار إثباتات الصلاحية لدفعات المعاملات، وهو أمر يتطلب موارد كثيفة. إن التحقق من أدلة المعرفة الصفرية على الشبكة الرئيسية يكلف أيضًا الغاز (~ 500000 غاز).

بالإضافة إلى تجميع المعاملات، تعمل ZK-rollups على تقليل الرسوم على المستخدمين من خلال ضغط بيانات المعاملات. يمكنك الاطلاع على نظرة عامة في الوقت الفعلي (opens in a new tab) حول تكلفة استخدام تجميعات المعرفة الصفرية الخاصة بإيثريوم.

كيف تقوم ZK-rollups بتوسيع نطاق إيثريوم؟ توسيع نطاق إيثريوم باستخدام تجميعات المعرفة الصفرية

ضغط بيانات المعاملات

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

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

الإثباتات العودية

من مزايا أدلة المعرفة الصفرية هو أن الأدلة يمكنها التحقق من أدلة أخرى. على سبيل المثال، يمكن لـ ZK-SNARK واحد التحقق من ZK-SNARKs الأخرى. تُسمى مثل هذه "إثباتات الإثبات" بإثباتات متكررة وتزيد بشكل كبير من الإنتاجية على عمليات تجميع ZK.

حاليًا، يتم إنشاء أدلة الصلاحية على أساس كتلة تلو الأخرى وإرسالها إلى عقد L1 للتحقق منها. ومع ذلك، فإن التحقق من أدلة الكتلة الفردية يحد من الإنتاجية التي يمكن أن تحققها عمليات تجميع ZK نظرًا لأنه لا يمكن الانتهاء إلا من كتلة واحدة عندما يرسل المشغل دليلاً.

ومع ذلك، فإن الأدلة التكرارية تجعل من الممكن الانتهاء من عدة كتل بدليل صحة واحد. يرجع ذلك إلى أن دائرة الإثبات تجمع بشكل متكرر أدلة كتلة متعددة حتى يتم إنشاء دليل نهائي واحد. يقوم مشغل L2 بإرسال هذا الدليل المتكرر، وإذا قبله العقد، فسيتم الانتهاء من جميع الكتل ذات الصلة على الفور. باستخدام الأدلة المتكررة، يزداد عدد معاملات ZK-rollup التي يمكن إنهاؤها على إيثريوم على فترات زمنية.

إيجابيات وسلبيات تجميعات المعرفة الصفرية

شرح مرئي لتجميعات المعرفة الصفرية

شاهد شرح Finematics لـ ZK-rollups:

من يعمل على zkEVM؟ مشاريع آلات إيثريوم الافتراضية ذات المعرفة الصفرية (zkEVM)

تتضمن المشاريع التي تعمل على zkEVMs ما يلي:

• zkEVM (opens in a new tab) - zkEVM هو مشروع تموله مؤسسة إيثريوم لتطوير تجميع معرفة صفرية متوافق مع آلة إيثريوم الافتراضية وآلية لتوليد إثباتات الصلاحية لكتل إيثريوم.

• بوليغون zkEVM (opens in a new tab) - هو تجميع لامركزي للمعرفة الصفرية (ZK Rollup) على شبكة إيثريوم الرئيسية (mainnet) يعمل على آلة إيثريوم الافتراضية ذات المعرفة الصفرية (zkEVM) التي تنفذ معاملات إيثريوم بطريقة شفافة، بما في ذلك العقود الذكية مع عمليات التحقق من صحة إثبات المعرفة الصفرية.

• Scroll (opens in a new tab) - Scroll هي شركة قائمة على التكنولوجيا تعمل على بناء حل أصلي من الطبقة الثانية لآلة إيثريوم الافتراضية ذات المعرفة الصفرية (zkEVM) لإيثريوم.

• تايكو (opens in a new tab) - Taiko هو تجميع لامركزي للمعرفة الصفرية مكافئ لإيثريوم (ZK-EVM من النوع 1 (opens in a new tab)).

• ZKsync (opens in a new tab) - ZKsync Era هو تجميع معرفة صفرية متوافق مع آلة إيثريوم الافتراضية تم إنشاؤه بواسطة Matter Labs، ويعمل بآلة إيثريوم الافتراضية ذات المعرفة الصفرية (zkEVM) الخاصة به.

• ستارك نت (opens in a new tab) - StarkNet هو حل توسّع من الطبقة الثانية متوافق مع آلة إيثريوم الافتراضية تم إنشاؤه بواسطة StarkWare.

• Morph (opens in a new tab) - Morph هو حل توسّع هجين يستخدم إثبات المعرفة الصفرية لمعالجة مشكلة تحدي الحالة في الطبقة الثانية.

• لينيا (opens in a new tab) - Linea هو حل من الطبقة الثانية لآلة إيثريوم الافتراضية ذات المعرفة الصفرية (zkEVM) مكافئ لإيثريوم، تم إنشاؤه بواسطة Consensys، وهو متوافق تمامًا مع منظومة إيثريوم.

قراءات إضافية حول تجميعات المعرفة الصفرية

• ما هي تجميعات المعرفة الصفرية؟ (opens in a new tab)
• ما هي تجميعات المعرفة الصفرية؟ (opens in a new tab)
• الدليل العملي لعمليات رول أب إيثريوم (opens in a new tab)
• مقارنة بين STARKs وSNARKs (opens in a new tab)
• ما هي آلة إيثريوم الافتراضية ذات المعرفة الصفرية (zkEVM)؟ (opens in a new tab)
• أنواع ZK-EVM: المكافئ لإيثريوم، والمكافئ لـ EVM، والنوع 1، والنوع 4، وغيرها من الكلمات الطنانة الغامضة (opens in a new tab)
• مقدمة إلى zkEVM (opens in a new tab)
• ما هي حلول الطبقة الثانية لآلة إيثريوم الافتراضية ذات المعرفة الصفرية (ZK-EVM L2s)؟ (opens in a new tab)
• موارد رائعة عن zkEVM (opens in a new tab)
• نظرة معمقة على ZK-SNARKS (opens in a new tab)
• كيف تكون SNARKs ممكنة؟ (opens in a new tab)