الجزء الأول من سلسلة zkEVM: البنية الشاملة وعملية تنفيذ المعاملات ل Polygon zkEVM

المؤلف: 0xhhh، Ethstorage (تويتر: @hhh69251498)

المحرر:ريد وان

في 27 مارس ، تم إطلاق الإصدار التجريبي من الشبكة الرئيسية Polygon zkEVM رسميا ، وأكملت Vitalik أول معاملة لها.

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

في المقالتين التاليتين ، سنقوم أيضا بتفصيل تفاصيل تصميم جسر zkEVM الخاص ب Polygon zkEVM و zkEVM ، بالإضافة إلى خارطة الطريق لجهاز التسلسل اللامركزي التالي من Polygon zkEVM.

أولا ، الإظهار هو تحقيق التحجيم الحسابي ل Ethereum

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

** التراكمي المتفائل **

بتفاؤل ، فإن معاملة التجميع وحالة التجميع المقابلة المرسلة إلى Ethereum صحيحة ، ويمكن لأي شخص تحدي حالة التجميع التي لا تزال في فترة التحدي من خلال توفير دليل على الاحتيال.

** مجموعة المعرفة الصفرية **

ستقدم ZK دليلا على صحة المعاملة التراكمية المرسلة إلى Ethereum وحالة التجميع المقابلة (تم التحقق منها بموجب العقد على Ethereum لإثبات أن الإظهار في الحالة الصحيحة بعد تنفيذ المعاملة المقابلة).

** الرجوع إلى التعريف الرسمي ل Ethereum: **

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

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

يعتمد الوقت الذي يستغرقه Zero-Knowledge Rollup (zk-Rollup) للوصول إلى النهاية على الوقت الذي يستغرقه تقديم إثبات صحة المعاملة إلى Ethereum والتحقق منها. في الوقت الحاضر ، قد يكون حوالي 1 ساعة للنهاية (بسبب الحاجة إلى النظر في تكلفة الغاز).

ثانيا ، عملية تنفيذ مضلع zkEVM

دعونا نلقي نظرة على كيفية عمل Polygon zkEVM مع عملية تأكيد بسيطة للمعاملة ، وذلك للحصول على فهم ملموس للبروتوكول العام ، ويمكن تقسيم العملية برمتها إلى ثلاث خطوات رئيسية:

1. يقوم جهاز التسلسل بحزم معاملات مستخدم متعددة على دفعات وإرسالها إلى عقد L1.

2. يقوم Prover بإنشاء إثبات صلاحية لكل معاملة ويجمع إثباتات الصلاحية لمعاملات متعددة في إثبات صلاحية واحد.

3. يقدم المجمع إثبات صحة المجمع الذي قام بتجميع معاملات متعددة في عقد L1.

1 يقوم جهاز التسلسل بتجميع معاملات المستخدم على دفعات وإرسالها إلى عقد L1.

1. يرسل المستخدم المعاملة إلى Sequencer ، وسيقوم Sequencer بمعالجة المعاملة محليا بترتيب الاستلام (FRFS) ، عندما يقوم Sequencer بتنفيذ المعاملة محليا ، إذا كان المستخدم يعتقد أن Sequencer صادق ، فيمكنه اعتبار المعاملة قد وصلت إلى النهاية. من المهم أن نلاحظ هنا أن معظم Mempools داخل Sequencer خاصة حاليا ، لذلك هناك عدد قليل نسبيا من MEVs التي يمكن الحصول عليها في الوقت الحالي.

2. سيقوم جهاز التسلسل بتعبئة معاملات متعددة في دفعة واحدة (حاليا معاملة واحدة فقط في الدفعة) ثم إرسال دفعات متعددة معا إلى المعاملة Calldata ل L1 عبر وظيفة SequenceBatch () ل PolygonZKEvm.sol على L1.

(تجدر الإشارة إلى أنه يتم تقديم دفعات متعددة في وقت واحد من أجل تقليل استهلاك الغاز من L1 قدر الإمكان.)

3. عندما يتلقى PolygonZkEvm.sol الدفعات المقدمة من Sequencer ، فإنه سيحسب تجزئة كل دفعة في العقد بدوره ، ثم يسجل تجزئة الدفعة السابقة في الدفعة التالية ، لذلك نحصل على هيكل الدفعة في الشكل التالي.

4) يتم أيضا تحديد ترتيب المعاملات في كل دفعة ، لذلك عندما يتم تحديد ترتيب الدفعة ، فإننا نعتبر أن ترتيب جميع المعاملات المضمنة في الدفعة التي سيتم تقديمها إلى عقد L1 Polygon zkEVM قد تم تحديده.

العملية الفعلية المذكورة أعلاه هي أيضا العمل الذي يحتاج L1 إلى إكماله كطبقة Rollup DA (لم يتم إكمال أي عمل للتحقق من الحالة أو التقدم في هذا الوقت).

**2. يقوم المجمع بإنشاء إثبات صلاحية لدفعات متعددة من المعاملات

1. عندما يستمع المجمع إلى الإرسال الناجح للدفعات الجديدة في عقد PolyonZKEVM.sol على L1 ، فإنه يقوم بمزامنة هذه الدفعات مع العقدة الخاصة به ويرسل هذه المعاملات إلى zkProver.

2. بعد استلام هذه المعاملات ، ستقوم zkProver بإنشاء إثبات صلاحية لكل معاملة ، ثم تجميع إثبات صحة المعاملات الواردة في دفعات متعددة في إثبات الصلاحية.

3. يرسل zkProver إثبات الصلاحية لتجميع معاملات متعددة إلى المجمع.

**3. يقدم المجمع عقد البراهين الإجمالية إلى L1 **

سيقدم المجمع إثبات الصلاحية هذا إلى عقد Polygon zkEvm.sol على L1 جنبا إلى جنب مع الحالة المقابلة لتنفيذ الدفعات عن طريق استدعاء الطريقة التالية:

ثم يتم تنفيذ الإجراءات التالية ضمن العقد للتحقق من صحة انتقال الحالة.

عندما يتم تنفيذ هذه الخطوة بنجاح في عقد L1 ، ستصل جميع المعاملات المدرجة في هذا الجزء من الدفعة حقا إلى النهاية (المقابلة لنهاية فترة التحدي لمدة 7 أيام من OP).

3. دور الإيثريوم في Polygon-zkEVM

الآن بعد أن نظرنا إلى العملية الشاملة ل Polygon zkEVM ، دعنا نراجع ما فعلته Ethereum لمجموعة التحديثات:

في الخطوة الأولى ، يقوم Sequencer بجمع معاملات التجميع وحزمها على دفعات ، والتي يتم إرسالها بعد ذلك إلى عقد L1. لا يوفر L1 وظائف طبقة DA فحسب ، بل يكمل أيضا بعض وظائف طلب المعاملات ، عند إرسال معاملة إلى Sequencer ، لا يتم طلب المعاملة حقا ، لأن Sequencer لديه القدرة على تغيير ترتيب المعاملات حسب الرغبة ، ولكن عندما يتم تضمين المعاملة في الدفعة وتقديمها إلى عقد L1 ، لا يحق لأحد تغيير ترتيب المعاملات.

في الخطوة الثانية ، يقوم المجمع بإحضار إثبات الصلاحية إلى عقد L1 للوصول إلى الحالة الجديدة ، والمجمع هو دور يشبه مقدم العرض ، والعقد مشابه لدور المدقق ، ويقدم المجمع إثبات صلاحية لإثبات صحة الحالة الجديدة ويخبر المدقق بالصلاحية التي أقدمها ما هي دفعات المعاملات المتضمنة في Proof، وأين توجد في L1.

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

رابعا ، هيكلة مجموعة العقود الذكية من منظور النمطية

إذا كان Polygon zkEVM ينتمي من منظور النمطية إلى نوع Smart Contract Rollup ، فيمكننا محاولة تفكيك وحداته ، ومن الرسم البياني الذي قدمته دلفي ، يمكننا أيضا أن نرى أن Polygon ZkEVM هو في الواقع طبقة الإجماع وطبقة DA وتسوية Smart Contrat Rollup تقترن الطبقات في الواقع بعقد PolygonZkEVM.sol ، والذي لا يتميز جيدا. ولكن دعونا نحاول تفكيك الوحدات:

طبقة توفر البيانات: حيث يتم تخزين المعاملات المجمعة ، وفي حالة Polygon-zkEVM ، عندما يستدعي Sequencer طريقة SequenceBatch () ، فإنه يتضمن في الواقع تقديم بيانات المعاملة إلى طبقة DA.

طبقة التسوية: تشير على وجه التحديد إلى آلية تدفق الأموال بين Rollup و L1 ، وتحديدا الجسر الرسمي ل Polygon-zkEVM (المزيد حول هذا الموضوع في المقالة التالية).

طبقة الإجماع: تحتوي على ترتيب المعاملات وكيفية تحديد الحالة الصالحة التالية (تحديد الشوكة) ، ويكمل Sequencer ترتيب المعاملات عندما يستدعي SequenceBatch () في عقد L1 ، ويؤكد الحالة القانونية التالية عندما يستدعي المجمع TustedVerifyBatches() في عقد L1.

طبقة التنفيذ: العملية التي يتم من خلالها تنفيذ معاملة والحصول على حالة عالمية جديدة ، عندما يرسل المستخدم معاملة إلى Sequencer ، ويتم الحصول على الحالة الجديدة بعد تنفيذ Sequencer ( لهذا السبب نميل إلى القول إن عمليات التجميع عبارة عن تحجيم حسابي ، لأن L1 تستعين بمصادر خارجية لعملية تنفيذ المعاملات للحصول على حالة جديدة إلى Rollups ، ويفوض Sequencer zkProver للمساعدة في إنشاء إثبات الصلاحية من خلال المجمع.

5. لماذا يرث Polygon-zkEVM أمان L1

انطلاقا من العملية الشاملة الموضحة أعلاه ، يقوم Sequencer في الواقع بشيء مشابه لمقترح Ethereum ، حيث يقترح أن مجموعة من المعاملات هي معاملات صالحة ، وإعطاء الحالة الجديدة لهذه الدفعة من المعاملات بعد التنفيذ ، ومنطق التحقق من عقد L1 يعادل جميع مدققي L1 سيتم تنفيذهم في عملاء Ethereum الخاصين بهم ، في الواقع ، يعمل جميع مدققي Ethereum كمدققين لمجموعة التحديثات ، لذلك نعتقد أن Polygon zkEVM ورثت أمن إيثريوم.

من ناحية أخرى ، نظرا لأن جميع المعاملات وحالة التراكمات يتم تخزينها على Ethereum ، حتى إذا هرب فريق Polygon zkEVM ، فسيظل لدى أي شخص القدرة على استرداد شبكة Rollup بالكامل بناء على البيانات المخزنة على Ethereum.

6. آلية تحفيز zkEVM المضلع

تدور حوافز التجميع في المقام الأول حول كيفية جعل جهاز التسلسل والمجمع مربحا وبالتالي الحفاظ على استمرار العمل؟

بادئ ذي بدء ، يحتاج المستخدمون إلى دفع رسوم المعاملات الخاصة بهم على Rollup ، والتي يتم تحديدها في ETH وتدفع في Bridged ETH.

سيحتاج Sequencer إلى دفع تكلفة تحميل الدفعة التي تحتوي على معاملة Rollup إلى Calldata لمعاملة L1 (تكلفة استدعاء SequenceBatch (الدفعات ()) ، وسيحتاج Matic إلى دفع مبلغ معين من Matic إلى عقد L1 في نفس الوقت الذي يتم فيه تحميل الدفعة ، والتي ستدفع لاحقا تكلفة المجمع الذي يوفر إثبات الصلاحية لهذه الدفعات.

بينما يدعو المجمع VerifyBatches الموثوق به لتقديم إثبات الصلاحية للدفعات في عقد L1 الذي لم يكن نهائيا بعد ، يمكن ل Sequencer أيضا إخراج رموز MATIC المدفوعة مقدما بواسطة Sequencer في العقد كمكافأة لتقديم إثبات الصلاحية.

إيرادات جهاز التسلسل = رسوم الغاز لجميع المعاملات في مجموعة التحديثات - رسوم غاز شبكة L1 التي يتم إنفاقها في تحميل الدفعات إلى L1 - رسوم التصديق المدفوعة إلى المجمع (فئة MATIC).

إيرادات المجمع = مكافآت MATIC المدفوعة بواسطة جهاز التسلسل - رسوم الغاز المقدمة إلى إثبات الصلاحية إلى L1 - رسوم الأجهزة التي يتم إنفاقها لإنشاء إثباتات الصلاحية.

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

هناك طريقة في العقد تقوم بضبط تكلفة تقديم البراهين للدفعات:

وظيفة _updateBatchFee(uint64 newLastVerifiedBatch) الداخلية

يغير متغيرا في العقد يسمى BatchFee ، والذي يحدد مقدار رموز MATIC التي يدفعها Sequencer لكل دفعة.

آلية التغيير هي كما يلي:

يحتفظ العقد بمتغير VeryBatchTimeTarget يمثل الحالة المتوقعة لكل دفعة يتم التحقق من صحتها خلال ذلك الوقت بعد الالتزام ب L1 بواسطة Sequencer.

سيسجل العقد جميع الدفعات التي لم يتم التحقق من صحتها بعد تجاوز VeryBatchTimeTarget ، وسيتم تسجيل العدد الإجمالي لهذه الدفعات على أنها DiffBatches.

لذلك ، عندما تتأخر الدفعات ، سيتم تعديل BatchFee بالصيغة التالية:

MultiplierBatchFee هو رقم يقتصر على نطاق 1000 ~ 1024 ، والذي يمكن تغييره بواسطة مسؤول العقد عبر مجموعة الوظائفMultiplierBatchFee ():

FunctionsetMultiplier BatchFee(uint16newMultiplierBatchFee) public onlyAdmin

وتجدر الإشارة إلى أن استخدام MultiplierBatchFee و 10 ^ 3 هنا هو تحقيق دقة الضبط بعد 3 نقاط عشرية.

وبالمثل ، إذا كانت الدفعات مقدما ، تشغيل آلية تعديل batchFee المقابلة: يشير DiffBatches إلى عدد الدفعات في حالة التحقق المبكر.

ملخص

في هذه المقالة ، نقوم بفرز الآلية الأساسية ل Polygon zkEVM وتحليل جدواها لتحقيق التوسع الحسابي ل Ethereum. مع مخطط شامل ، في المقالات التالية سوف نتعمق في الجزء الداخلي من البروتوكول ، ونحلل تفاصيل تصميم جسر zkEVM ، ومسار اللامركزية ل Sequencer ، وتنفيذ zkProver ، ومبادئ تصميم zkEVM.

—— للمتابعة——