من أجل حل مشكلة التوسع في شبكة blockchain Layer 1 ، ظهر حل Rollup إلى حيز الوجود. إلى جانب تقنية ZK ، أصبحت ZK Rollup هي الحبيبة الجديدة لمسار Layer 2. ومع ذلك ، بالنسبة لمعظم الأشخاص ، قد يكون للمفاهيم ذات الصلة مثل ZK و Rollup و EVM حد معين من الفهم. لذلك ، الهدف من هذا التقرير البحثي هو فرز سلسلة من مفاهيم zkEVM Rollup بشكل منهجي بلغة موجزة وسهلة الفهم ، وتحليل عميق لتطور وتطوير تقنية zkEVM Rollup ، وتفسير البيئة الرئيسية بالتفصيل. إنه مصمم لمساعدتك على الفهم الكامل والحكم على اتجاه تطوير مسار zkEVM Rollup.
** الجزء 1 ** ** فهم ZK **
ZK (أو ZKP) ، الاسم الكامل هو Zero-Knowledge Proof ، أي إثبات المعرفة الصفرية. في التشفير ، يُعد إثبات المعرفة الصفرية أو بروتوكول المعرفة الصفرية طريقة يمكن من خلالها لطرف واحد (المُثبِّت) الإرسال إلى الطرف الآخر (المُصدق على التحقق) لإثبات حقيقة دون الكشف عن المعلومات المحددة للحقيقة ، أي أن أحد الأطراف (المُثبِت) يمكنه أن يُعلم الطرف الآخر ما إذا كانت الحقيقة صحيحة دون الكشف عن أي "معلومات محددة" عن في الواقع ، يمكن استخدام تقنية ZK في الخصوصية. يوفر لنا مجال الحماية مساحة كبيرة للخيال.
بالطبع ، بالإضافة إلى مزايا حماية الخصوصية التي يمكن أن توفرها تقنية ZK ، في ZK Rollup ، تعد تقنية ZK أكثر أهمية لحل مشكلة "التحقق الصعب". تعتبر عملية "التحقق" مهمة جدًا بالنسبة إلى blockchain ، حيث تهدف معظم عمليات الحساب في Ethereum إلى تلبية متطلبات التحقق ، ويمكن أن يقلل ZK Rollup بشكل كبير من الوقت الذي يقضيه في التحقق من خلال شبكة العقدة بأكملها. على سبيل المثال ، إذا استغرقت الكتلة وقتًا طويلاً للتحقق من أنها تفي بقواعد الشبكة بالكامل عندما تم إنشاء الكتلة ، فيمكن أن يكون هناك مُثبِت واحد يتحقق أولاً من الكتلة وينشئ "دليلًا" على نتيجة الحساب لهذه الكتلة ، والباقي يمكن تحقيق الغرض من التحقق من الكتلة عن طريق التحقق بسرعة من هذا "الإثبات" بدلاً من الكتلة الأصلية بكمية ضخمة من الحساب.
ينقسم بروتوكول ZK البسيط إلى الخطوات التالية ، وإنشاء المفتاح ، والإثبات والتحقق ، وسأفككها لك واحدة تلو الأخرى.
** 01 ** ** إنشاء المفتاح والإثبات والتحقق **
في ZK ، نحتاج أولاً إلى تحويل المسألة ليتم التحقق منها إلى تعبير رياضي ، ثم إلى كثير حدود ، والتعبير عنها في شكل دائرة حسابية. عندما يتم تحويل برنامج إلى دائرة حسابية ، يتم تقسيمه إلى خطوات فردية تتكون من عمليات حسابية أساسية مثل الجمع والطرح وما إلى ذلك. كدالة سيتم إخراجها ، يمكن تحويلها إلى مخطط الدائرة التالي ، انظر الشكل 1.
الشكل 1 مثال على مخطط الدائرة ، يمكن ملاحظة أن جميع العمليات في الدائرة مقسمة إلى أبسط العمليات الأساسية | المصدر
باستخدام هذه الدائرة وبعض الأرقام العشوائية كمدخلات ، يمكننا إنشاء مفتاح إثبات (pk ، مفتاح إثبات) ومفتاح التحقق (vk ، مفتاح التحقق) لعملية التحقق اللاحقة ، يظهر الرسم التخطيطي في الشكل 2.
الشكل 2 إنشاء "المعلمات العامة"
يتطلب نظام الإثبات لدينا أيضًا نوعين من المدخلات - خاص وعام ، جنبًا إلى جنب مع مفتاح الإثبات لإنشاء الدليل. من بينها ، المدخلات الخاصة (الشاهد) هي السر الذي نريد إخفاءه ، والمدخلات العامة هي المعلومات التي يمكن نشرها. على سبيل المثال ، في المعادلة X + Y \ * Z = OUT ، X و OUT هي مدخلات عامة ، بينما Y و Z لهما قيم لا نريد أن تكون عامة للمدقق. على الرغم من إمكانية استنتاج قيمة Y \ * Z بناءً على المدخلات العامة ، إلا أن القيم المحددة لـ Y و Z لا تزال غير مؤكدة.
الشكل 3 عملية الإثبات وعملية التحقق من ZK-SNARKs
عندما يتلقى المدقق الدليل ، فإنه يستخدم الإدخال العام ومفتاح الإثبات والتحقق للتحقق من الإثبات ، ويعيد نتيجة التحقق (أي ما إذا كان التحقق ناجحًا).
بعد فهم العملية المذكورة أعلاه ، يمكننا تطبيق هذه التقنية لمنع التحقق لتحقيق ZK-SNARK صغير ، كما هو موضح في الشكل 3. هناك العديد من البروتوكولات والطرق لتحقيق إثبات عدم المعرفة الصفرية. SNARK سهل الفهم نسبيًا ، وهو أيضًا اختيار معظم المشاريع في هذه المرحلة. في الفقرة "من ZK-SNARKs إلى ZK-STARKs" سنتحدث عن مزايا وعيوب SNARKs.
** 02 ** ** جرب SNARK قليلاً **
لنأخذ إثبات عدم المعرفة لشجرة Merkle التي تسجل حالة الحساب كمثال للتدريب. تسجل Merkle Tree العنوان ورصيد الحساب. عندما تكون هناك معاملة جديدة تحتاج إلى تحديث Merkle Tree ، نحتاج إلى إجراء العمليات التالية:
تحقق من أن المرسل والمتلقي للمعاملة موجودان على العقد الطرفية للشجرة.
التحقق من توقيع المرسل.
تحديث أرصدة المرسل والمستلم.
قم بتحديث عقدة جذر Merkle Tree (مثل Merkle Root) واستخدمها كإخراج نهائي.
في حالة عدم وجود أدلة على المعرفة الصفرية ، يحتاج المدقق إلى تكرار هذه الخطوات لضمان دقة الحساب. ولكن بعد استخدام إثبات عدم المعرفة ، فإن الوضع مختلف. أولاً ، نحتاج إلى تحديد نوعين من المدخلات:
أثناء هذه العملية ، تكون معلومات المعاملة الجديدة فقط وجذر Merkle الأصلي و Merkle Root المحدث مدخلات عامة.
تعمل Merkle Tree نفسها كشاهد (شاهد) ولا تحتاج إلى قراءتها أو معالجتها بواسطة المدقق.
ثانيًا ، نحتاج إلى إنشاء مفاتيح ودوائر حسابية. نقوم ببناء عمليات حسابية مثل تحديث Merkle Tree والتحقق من عنوان الإدخال والإخراج في دوائر الحساب للحصول على مفاتيح الإثبات ومفاتيح التحقق. لا علاقة لهذه الدائرة بمعلومات معاملات الإدخال ، ولا مع Merkle Root الحالي ، لأن طريقة حساب Merkle Tree ثابتة.
في مرحلة إنشاء البراهين ، نأخذ شجرتي Merkle ومعلومات المعاملة كمدخلات. في مرحلة المدقق ، يمكن للمدقق ضمان موثوقية التحديث دون الحصول على Merkle Tree ، أي دون معرفة معلومات الحساب. الدائرة تشبه الصندوق الأسود الصلب ، طالما أن الإدخال صحيح ، فستحصل على الإخراج الصحيح.
باستخدام إثبات المعرفة الصفرية ، يمكن للمحققين الآخرين التحقق بسرعة من مصداقية عملية إنشاء Merkle Tree ، وبالتالي تقليل وقت التحقق المتكرر على الشبكة ، ولا يلزم الكشف عن معلومات Merkle Tree للمدقق.
** 03 ** ** من ZK-SNARKs إلى ZK-STARKs **
بروتوكول الإثبات المذكور أعلاه هو ZK-SNARKs. يرمز SNARK إلى الحجج الموجزة غير التفاعلية للمعرفة ، حيث يشير الإيجاز إلى إيجاز هذه الطريقة ، ويشير غير التفاعلي إلى ذلك بالمقارنة مع طرق الإثبات الأخرى ، فإن SNARKs هي براهين غير تفاعلية ، أي أن المدقق يحتاج فقط إلى الاستخدام الإثبات المقدم من قبل المثقف يمكن أن يحصل الدليل الذي تم إنشاؤه على نتيجة التحقق. ومع ذلك ، هناك بعض المشاكل مع ZK-SNARKs. في مرحلة توليد المفاتيح ، تكون الدائرة والرقم العشوائي معادلين لمجموعة من المعلمات العامة الأولية ، وهناك مشكلة مركزية حتمية في عملية توليد هذه المعلمة العامة.
ZK-STARKs لها نهج مختلف يعتمد على SNARKs ، حيث تعني "s" قابلية التوسع ، مما يثبت أن وقت التوليد ووقت الحساب الأصلي شبه خطي ، ووقت التحقق لوغاريتمي في الحساب الأصلي ، مما يعني في في حالة وجود مجموعة بيانات كبيرة كبيانات ، يتم تقصير وقت التحقق المطلوب بواسطة المدقق بشكل كبير.
في الوقت نفسه ، كإصدار مطور من ZK-SNARKs ، لا يمكن لـ ZK-STARK فقط تحسين كفاءة التحقق (الكفاءة النظرية 10 مرات) ، ولكن أيضًا لا تعتمد على المنحنيات البيضاوية أو الإعدادات الموثوقة ، ولا تتطلب العملية لتوليد المعلمات العامة الأولية (الحرف "T" يرمز إلى الشفافية) ، مما يلغي الحاجة إلى إعداد مركزي موثوق. يعتقد بعض المطورين أن وظيفة التجزئة في ZK-STARK يمكن أن تساعد في مقاومة الهجمات الكمومية.
ومع ذلك ، تم تقديم ZK-STARKs في وقت متأخر ، والتكنولوجيا الحالية ليست ناضجة بدرجة كافية ، وتعتمد على وظائف التجزئة ، مما يحد من تعدد استخداماتها. لا تزال ZK-SNARKs خوارزمية إثبات عامة. بعض الأمثلة على الخوارزميات القائمة على STARK تشمل Fractal و SuperSonic وما إلى ذلك ، وتشمل المشاريع ذات الصلة StarkWare و Polygon Miden وما إلى ذلك.
** الجزء 2 ** ** فهم التراكمية **
بالإضافة إلى ZK ، هناك مفهوم آخر نحتاج إلى فهمه وهو Rollup. تكمن أهمية Rollup في حل مشكلة الازدحام في شبكة الطبقة الأولى.
خذ Ethereum كمثال ، لديها حاليًا مشكلة ازدحام المعاملات. هناك طريقتان لحل هذه المشكلة: الأولى هي زيادة سعة المعاملات في blockchain نفسها ، مثل توسيع إنتاجية blockchain من خلال تقنيات مثل التجزئة. نهج آخر هو تغيير طريقة استخدام blockchain ، أي لأداء معظم الأنشطة في الطبقة الثانية (الطبقة 2 ، المشار إليها فيما يلي باسم L2) ، بدلاً من مباشرة على السلسلة. في هذه الحالة ، غالبًا ما يتم نشر العقد الذكي على السلسلة ، وهو المسؤول الوحيد عن معالجة الإيداعات والسحوبات ، ويستخدم طرقًا مختلفة لقراءة البيانات خارج السلسلة للتحقق من أن كل ما يحدث خارج السلسلة يتوافق مع القواعد. وهذا يعادل إقامة طريق سريع بجوار طريق صغير ، أي من خلال توسعة L2 لحل مشكلة الازدحام.
حاليًا ، الأنواع أو الحلول الثلاثة الرئيسية لتوسيع L2 هي قنوات الحالة ، والبلازما ، والتراكمية. هناك ثلاثة نماذج مختلفة ، لكل منها مزايا وعيوب. يمكن تصنيف جميع امتدادات L2 تقريبًا إلى هذه الفئات الثلاث (على الرغم من وجود بعض الخلافات حول التسمية ، مثل validium) ، ومن بينها Rollup مزاياها الخاصة.
** التراكمية وتوافر البيانات **
بالمقارنة مع حلول التوسع الأخرى ، فإن Rollup له مزايا معينة. ومن المزايا الأكثر بديهية أنه يحل مشكلة توفر بيانات البلازما (المذكورة في فصل "توفر البيانات" من مقالة السيد دارين) ، وهنا سأقوم ببعض ملحق.
حقيقة أن البيانات متصلة بالسلسلة مهمة جدًا (ملاحظة: وضع البيانات "على IPFS" لن ينجح ، لأن IPFS لا يوفر التحقق من مستوى الإجماع على عدم وجود ضمان بتوفر بيانات معينة ، أي يجب أن تكون البيانات مخزنة في كتل). في مخططي التوسع للبلازما والقناة السابقة ، يتم وضع البيانات والحسابات بالكامل في شبكة الطبقة الثانية. عندما تتفاعل شبكة الطبقة الثانية مع Ethereum ، لا يتم تضمين جميع بيانات المعاملات في سلسلة الطبقة الثانية. من الحالة من منظور الجهاز ، أي ، لا يتم تضمين كل تغيير حالة في سلسلة البلازما. سيؤدي هذا إلى حقيقة أنه إذا تم فصل Ethereum عن شبكة الطبقة الثانية مثل Plasma ، فلن تكون قادرة على استعادة تغييرات الحالة السابقة.لذلك ، فإن توفر بيانات Ethereum يعتمد بشكل كبير على حماية بيانات البلازما.
** آلية التراكم **
من أجل ضمان توفر البيانات ، يختار السوق التراكمي ، فكيف يعمل التراكمي؟
الشكل 4 جذر الحالة في العقد L1 | المصدر
في تصميم Rollup ، يوجد عقد تراكمي على السلسلة الرئيسية ، والذي يخزن جذر الحالة. يمكن اعتبار جذر الحالة هذا كإصدار مطور من جذر Merkle لشجرة Merkle ، والذي يخزن رصيد الحساب (أي نوع من الحالة) ، ورمز العقد ومعلومات أخرى. يوضح الشكل 4 جذر الحالة المخزن في عقد التجميع .
تحتوي العقدة L2 على ثلاث وظائف رئيسية: أولاً ، تحديد المعاملات التي يجب تعبئتها أولاً (عادةً ما يُطلق على هذا النوع من العقدة أو العميل اسم Sequencer Sequencer) ، وثانيًا ، يجب تقديم دليل لكل بيانات مجمعة ، وأخيراً إرسالها إلى L1 يتم التحقق من عقد التجميع بموجب هذا العقد. يوضح الشكل 5 دور منظم التسلسل في L2.
الشكل 5 تسلسل وإثبات وتقديم الدُفعة هي الوظائف الرئيسية لمرحلة L2 | المصدر
على وجه التحديد ، يمكن لـ L2 نقل دفعة من البيانات (دُفعة) إلى L1. يمكن أن تكون هذه البيانات عبارة عن مجموعات معاملات مضغوطة للغاية أو تغييرات الحالة بعد تشغيل العقد ، وتتضمن أيضًا جذر الحالة المخزن في عقد L1 وجذر ما بعد الحالة الجديد ( جذر ما بعد الحالة) تم الحصول عليه بعد معالجة L2 للبيانات. يتحقق العقد من صحة جذر ما بعد الحالة بناءً على هذه البيانات. بمجرد اجتياز التحقق ، سيتم تأكيد مجموعة البيانات في طبقة L1 ، لإكمال العملية على السلسلة من L2 إلى L1.
يتم حساب جذر ما بعد الحالة (جذر ما بعد الحالة) من البيانات الأصلية. للتأكد من صحة جذر ما بعد الحالة الجديد في البيانات المقدمة ، فإن الطريقة الأكثر وضوحًا هي السماح لـ L1 بإعادة الحساب مرة واحدة. ومع ذلك ، فإن القيام بذلك سيضع بلا شك الكثير من الضغط على L1. لحل هذه المشكلة الحرجة ، هناك مخططا تحسين مختلفان تمامًا ، Optimistic Rollup و ZK Rollup.
** ZK Rollup و Optimistic Rollup **
تستخدم ZK Rollup أدلة بروتوكول التشفير مثل ZK-SNARKs أو ZK-STARKs للتحقق من صحة جذر ما بعد الحالة بعد تنفيذ الدفعة. بغض النظر عن مقدار الحساب في L2 ، يمكن لـ ZK Rollup التحقق بسرعة من سلسلة L1.
نوع آخر من الإثبات هو Optimistic Rollup ، والذي يستخدم إثباتات الاحتيال. يوجد تشبيه واضح هنا ، مثل الأم التي لا تدقق في واجبات ابنها المنزلية كثيرًا ، ولكن طالما لم يتم إنجاز الواجب المنزلي مرة واحدة ، فستتم معاقبتها بشدة. بموجب هذه الآلية ، يتتبع عقد التراكم التاريخ الكامل لجذر الحالة وتجزئة كل دفعة. إذا اكتشف شخص ما أن الدُفعة لها جذر غير صحيح لما بعد الحالة ، فيمكنه نشر دليل على أن الدُفعة تم حسابها بشكل غير صحيح. تتحقق العقد الأخرى معًا من الإثبات واستعادة الدُفعة وجميع الدُفعات اللاحقة.
يلخص الشكل 6 مقارنة مزايا وعيوب Optimistic Rollup و ZK Rollup. من المهم أن نلاحظ هنا أن ZK Rollup يتفوق في TPS وله ميزة كبيرة في دورات الاسترداد. ومع ذلك ، فإن عيوبها هي توافق EVM والاستهلاك الحسابي في طبقة L2:
مشاريع التراكمية المتفائلة ، مثل التفاؤل و Arbitrum ، تستخدم OVM و AVM على التوالي ، وبيئاتها الافتراضية هي أساسًا مثل EVM ، حتى تتمكن من ترحيل عقود L1 مباشرة إلى L2 للنشر. ومع ذلك ، في ZK Rollup ، من الصعب جدًا استخدام ZK-SNARK لإثبات تنفيذ EVM العام ، لأن EVM لم يتم تطويره وفقًا للمتطلبات الرياضية لحساب إثبات ZK ، لذلك من الضروري تحويل نوع معين من عميل EVM للاستخدام تقنية ZK للتحقق من المعاملات وعمليات العقد.
في الوقت نفسه ، حتى بعد التحويل المقابل ، لا تزال عملية ZK تتطلب الكثير من مدخلات طاقة الحوسبة ، لذا فإن ZK Rollup ليست فعالة مثل Optimistic Rollup في كفاءة طبقة L2.
يوفر ZK Rollup ضغط بيانات أفضل من Optimistic Rollup ، لذلك يمكنه إرسال بيانات أصغر على L1.
نظرًا لأن عملية التحقق من الإثبات في ZK أسرع ولها كثافة دفعية أعلى ، فإن ZK Rollup يكون أقل في استهلاك حساب طبقة L1. يمكن فهم أن دفع العقدة على L2 يقلل بشكل كبير من متطلبات العقد L1 ، وبالتالي يحسن بشكل كبير قابلية التوسع في الطبقة L1.
الشكل 6 مقارنة بين طريقتين للجمع | المصدر:
** ZK Rollup أو zkEVM Rollup؟ **
على الرغم من أن ZK Rollup تبدو جذابة ، إلا أن هناك العديد من الصعوبات في النشر الفعلي. في الوقت الحالي ، لا يزال ZK Rollup يعاني من قيود كبيرة ، بينما لا يزال Optimistic Rollup هو الحل السائد. معظم ZK Rollups التي تم تنفيذها هي أيضًا مصممة خصيصًا لبعض التطبيقات المحددة.
كيفية فهم ZK Rollup المخصص؟ ينشئ المطورون دوائر خاصة بالتطبيقات ("ASICs") لمختلف DApps ، مثل Loopring و StarkEx rollup و zkSync 1.0 ، والتي تدعم أنواعًا معينة من الدفع أو تبادل الرموز أو صب NFT. ومع ذلك ، يتطلب تصميم الدوائر الخاصة بهم درجة عالية من المعرفة التقنية ، مما يؤدي إلى ضعف خبرة المطور. بأخذ نوع معين من بيانات الدفع كمثال ، تقوم العقدة بإرسال بيانات المعاملة إلى جهاز التسلسل ، ويقوم منظم التسلسل بحزمها في دفعة وإرسالها إلى العقدة التي تقدم الإثبات كمدخل عام وعملية الإثبات والعقد عملية التنفيذ على الجهاز الظاهري ليس لديها ما تفعله ، ZK هي المسؤولة فقط عن إثبات حساب التجميع وعملية الضغط لنتيجة تنفيذ محددة.
ويمثل zkEVM Rollup القدرة على تجميع نتائج تشغيل الجهاز الظاهري. عند تشغيل عقد ذكي للأغراض العامة على طبقة L2 ، من الضروري إثبات صحة انتقال الحالة قبل وبعد تشغيل العقد ، ويلزم وجود بيئة افتراضية لدعم تشغيل خوارزمية ZK. لذلك ، فإن معنى zkEVM هو تشغيل العقد ، وإخراج الحالة النهائية ، وإثبات صحة عملية تنفيذ العقد ، وتقديم سجلات المعاملات ، وسجلات الحساب ، وبيانات سجل تغيير الحالة معًا في مجموعة. تحتاج الطبقة L1 فقط إلى التحقق بسرعة من الإثبات ، والنفقات العامة صغيرة ، وليس هناك حاجة لتشغيل العقد مرة أخرى.يوضح الشكل 7 بوضوح دور zkVM. تجدر الإشارة إلى أن zkEVM هو في الواقع آلة افتراضية تشبه EVM تعمل على طبقة L2 ، لذا فإن المصطلح الأكثر دقة هو Zero Knowledge Virtual Machine ، zkVM ، لكن الجميع يؤكد أنه متوافق مع Ethereum ويطلق عليه zkEVM.
الشكل 7 رسم تخطيطي يوضح zkVM | المصدر
تدرس المشاريع الحالية أيضًا التخلي التدريجي عن التحسين لتطبيقات محددة ، والترقية لدعم تشغيل عقود الأغراض العامة ، أي zkEVM Rollup. لذلك ، على الرغم من أن zkEVM Rollup هو مفهوم ثانوي لـ ZK Rollup ، في معظم الحالات ، عندما يتم ذكر ZK Rollup ، فإنه يشير إلى zkEVM rollup.
** الجزء 4 ** ** نظرة عامة على مشروع مجموعة zkEVM **
في النصف الأول من عام 2023 ، ستظهر العديد من مشاريع zkEVM بشكل سريع. وعند الاهتمام بهذه المشاريع ، يركز المؤلف بشكل أساسي على الجوانب التالية:
تقدم المشروع الحالي: بما في ذلك مرحلة المشروع الحالية ، ووقت الإطلاق المتوقع لشبكة الاختبار والشبكة الرئيسية ، وما إذا كانت متوافقة مع خارطة طريق التطوير.
التفاعل الفعلي للمشروع: من خلال التفاعل مع شبكة الاختبار (الرئيسية) ، وما إلى ذلك ، تشعر بشكل شخصي بشبكة TPS ، ووقت التأكيد لمعاملة واحدة ، وما إلى ذلك ، ولديك شعور بديهي بأداء الشبكة.
التوافق مع zkEVM: هذه هي النقطة الفنية الأساسية والأصعب في الحكم عليها.حتى لو كانت بعض المشاريع مفتوحة المصدر ، فإن التكنولوجيا على مستوى VM هي الأصعب وتتضمن المزيد من بروتوكولات ZK. على وجه التحديد ، من الضروري الانتباه إلى بروتوكول ZK وأمن الجهاز الظاهري والتوافق وما إلى ذلك.
zkEVM العمارة التراكمية: بالمقارنة مع zkEVM ، ستكشف المشاريع العامة عن معمارية التراكمية في الأوراق البيضاء والمستندات الفنية الأخرى ، والفرق العام أقل ، ولكن يجب الانتباه إلى درجة اللامركزية الإجمالية.
التشغيل البيئي: عدد مستخدمي المشروع ، ودرجة النشاط ، وتشغيل واحتضان بيئة التطبيق على السلسلة ، وصيانة مجتمع المطورين هي مؤشرات تعكس برفق تشغيل المشروع.
وضع الاستثمار والتمويل.
تتناول هذه المقالة المشروع بشكل أكبر من منظور النقاط الأربع الأولى ، وتولي مزيدًا من الاهتمام للبنية العامة لـ zkEVM Rollup من المستوى الفني.
** تمرير **
تأسس فريق Scroll في عام 2021 ، وهو ملتزم بتطوير مكافئ EVM لـ ZK Rollup لتوسيع نطاق Ethereum. منذ ما يقرب من عامين ، يعمل Scroll مع فريق Privacy and Scaling Explorations ومساهمين آخرين من المصادر المفتوحة لإنشاء مجموعة متوافقة مع الرمز الثانوي بشكل عام . zkEVM. في نهاية شهر فبراير ، أعلنت Scroll أن شبكة اختبار Alpha الخاصة بها أصبحت متاحة الآن على Goerli. يمكن لأي مستخدم المشاركة في الاختبار الفني دون إذن. يبلغ متوسط وقت الحظر لشبكة الاختبار 3 ثوانٍ. وهناك بالفعل أكثر من 20 مليون معاملة و أكثر من 1.5 مليون كتلة وأكثر من 4 ملايين عنوان تفاعلي. في الوقت نفسه ، فتح Scroll أيضًا واجهة النظام البيئي لموقع الويب في 11 أبريل.
انطلاقًا من الكشف الأخير عن المعلومات ، يتقدم Scroll باستمرار على طريق معادلة النوع 2 EVM. أكمل Scroll مؤخرًا التطوير المتوافق لجميع أكواد التشغيل EVM ، وهو في طور التدقيق ، وفي الوقت نفسه ، فإن الهدف التالي هو أن يكون متوافقًا مع معاملات EIP2718.
فيما يتعلق بالهندسة المعمارية الفنية ، فإن بنية Scroll تقليدية نسبيًا ، لذلك سيتم تقديمها بالتفصيل هنا. كما هو موضح في الشكل 8 ، يتم تقسيمه بشكل أساسي إلى جزأين: الجزء الأساسي هو zkEVM ، والذي يستخدم لإثبات صحة تنفيذ EVM في L2 ؛ ولكن لتحويل zkEVM إلى ZK Rollup كامل على Ethereum ، يحتاج L2 الكامل إلى يتم بناؤها حول هندسة zkEVM. على وجه التحديد ، تتكون شبكة اختبار التمرير ألفا الحالية من عقدة التمرير وعقد الجسر وعقد التجميع:
الشكل 8 العمارة الكلية التمرير | المصدر
عقدة التمرير: تتكون من جهاز التسلسل والمرحل والمنسق.
أ) يفتح Sequencer ، ما يسمى بـ Sequencer ، JSON-RPC للمستخدمين والتطبيقات ، ويقرأ المعاملات في تجمع المعاملات ويولد كتل L2 وجذور الحالة. في هذه المرحلة ، تكون عُقد التسلسل في Scroll مركزية ، وستصبح لامركزية تدريجياً في الترقيات المستقبلية.
ب) المنسق مسؤول عن الاتصال بين الأسطوانة وعقدة التمرير. عندما يتم إنشاء كتلة جديدة في جهاز التسلسل ، يتم اختيار الأسطوانة الموجودة في التجمع بشكل عشوائي لإنشاء الدليل.
ج) يراقب المُرحِّل العقد الجسر وعقد التجميع على سلاسل Ethereum و Scroll. يضمن عقد التجميع توفر البيانات لبيانات L2 على مستوى L1 ، ويضمن إمكانية استعادة كتلة L2 في طبقة L1. بمجرد التحقق من الكتلة المرسلة بواسطة طبقة L2 من خلال عقد التجميع على طبقة L1 ، فإن الكتلة سيصل إلى النهاية عند الطبقة L2. الحالة الثابتة لـ. يعتبر عقد الجسر مسؤولاً عن الاتصال بين عقود السلسلة المزدوجة عند عبور السلاسل أو إرسال رسائل عشوائية في كلا الاتجاهين أو إكمال عمليات تعهد الأصول وسحبها عند عبور السلاسل.
الشكل 9 2. شبكة الأسطوانة | المصدر
شبكة الأسطوانة: تحتوي الأسطوانة على zkEVM مدمج ، والذي يعمل كمثبِّت في الشبكة وهو مسؤول عن إنشاء براهين صلاحية لـ ZK Rollup ، كما هو موضح في الشكل 9.
أ) يقوم Roller أولاً بتحويل تتبع الإجراء الذي تم استلامه من المنسق (أي ، العمليات المحددة التي قام بها العقد والعناوين المعنية) إلى شهود الدائرة.
ب) يولد البراهين لكل دائرة zkEVM ويجمع أخيرًا هذه البراهين من دوائر ZK متعددة.
** StarkWare **
يوفر StarkWare حلاً للتوسيع قائمًا على STARK لضمان أمان L2 وسرعة وتجربة مستخدم سلسة. أنها تدعم أوضاع توفر البيانات المتعددة. StarkNet هي شبكة L2 الخاصة بهم ، في حين أن StarkEx هي خدمة تحقق من التراكمية لمستخدمي المؤسسات ، ويمكن بناء DApps على خدمات StarkEx. ومع ذلك ، يمكن حاليًا كتابة الدوائر المخصصة فقط من أجل DApps محددة ، وليس مجموعة zkEVM العامة. تدعم StarkEx سلسلة من خدمات التوصيل والتشغيل ، بما في ذلك سك وتداول NFT وتداول المشتقات وما إلى ذلك. من حيث البيئة ، فإن منصة تداول العقود الآجلة اللامركزية DYDX هي مستخدم مخلص لـ StarkWare.
StarkNet ، بالمعنى الدقيق للكلمة ، هو zkVM. بدلاً من عمل دوائر ZK لأكواد تشغيل Ethereum ، فقد صنعت مجموعة من لغات التجميع الأكثر ملاءمة لـ ZK ، AIR (التمثيل الجبري المتوسط) واللغة عالية المستوى في القاهرة. على الرغم من أن StarkNet نفسها غير متوافقة مع EVM ، إلا أنه لا يزال من الممكن أن تكون متوافقة مع Ethereum من خلال طرق أخرى بما في ذلك Kakarot (Kakarot هو zkEVM مكتوب في القاهرة ، وهو zkEVM الذي يعادل رمزه الثانوي EVM). وفقًا لفهمي ، يعد StarkNet مشروعًا مركزيًا نسبيًا ، أحدها أنه لا يمكن مزامنته مع الترقية الأمنية لـ Ethereum. لذلك ، من الضروري تركيز موظفي البحث والتطوير لتعويض أوجه القصور في الأمان ومتابعة التطوير و تعديل اتفاقية ETH الجديدة.
تستخدم StarkNet نظام STARK كنظام إثبات ، وبالمقارنة مع SNARK ، فإن STARK لديها ابتكارات أكثر. لا يحتاج إلى الاعتماد على "إعدادات موثوقة" مثل SNARK. علاوة على ذلك ، فإنه يحتوي أيضًا على افتراضات تشفير أبسط ، ويتجنب الحاجة إلى المنحنى الإهليلجي ، والاقتران ، وافتراضات المعرفة الأسية ، ويعتمد فقط على نظرية التجزئة والمعلومات ، لذلك فهو أكثر مقاومة للهجمات الكمومية. بشكل عام ، تعتبر STARKs أكثر أمانًا من SNARKs. فيما يتعلق بقدرات التوسع ، فإن STARK لها تأثير هامشي كبير ، وكلما زاد الدليل ، انخفضت التكلفة الإجمالية.
ومع ذلك ، فيما يتعلق بالهندسة المعمارية ، لا يوجد حاليًا سوى جهاز تسلسل واحد (منظم التسلسل) في النظام ، يتم التحكم فيه بواسطة StarkWare ، ولا يوجد سوى Prover واحد (أي المُثبِّت الذي ينشئ ZK Proof) ، والذي لا يولد فقط البراهين لـ StarkNet ، ولكنها تعمل أيضًا من تلقاء نفسها. دليل الجيل لجميع التطبيقات الأخرى في مجموعة StarkEx.
** متغيرات ZK Rollup: Validiums and Volitions **
Validium هو أيضًا حل قياس L2 يستخدم دليلًا على الحساب مثل ZK Rollup لفرض تكامل عملية المعاملة. على عكس ZK Rollup ، لا يقوم Validium بتخزين بيانات المعاملات على شبكة Ethereum الرئيسية. يعد التضحية بتوافر البيانات على السلسلة مقايضة يمكن أن تؤدي إلى تحسينات هائلة في قابلية التوسع ، والنقطة الأكثر إلحاحًا هي أن Validiums يمكنها معالجة حوالي 9000 معاملة في الثانية.
ولكن في نظر المؤلف ، لا يمكن اعتبار Validium على أنها مجموعة ZK Rollup صارمة. هذا الحل مشابه لـ Plasma ، ولا يحقق توفر البيانات في طبقة L1 ، لذلك لا يمكن اعتباره تراكمي. الاختلاف مع Plasma هو أن Plasma قد أنشأت "آلية خروج لمدة سبعة أيام" مماثلة لـ OP Rollup في طبقة L2 ، بينما تستخدم Validium وتعني ZK لتقصير وقت التحقق من البيانات في طبقة L2 ولا تزامن البيانات إلى L1.
تتيح Volition ، التي ابتكرتها StarkWare ، للمستخدمين التبديل بسهولة بين ZK Rollup و Validium. على سبيل المثال ، قد تكون بعض التطبيقات ، مثل تبادلات المشتقات اللامركزية ، أكثر ملاءمة لـ Validium ، بينما لا تزال ترغب في أن تكون قابلة للتشغيل البيني مع التطبيقات الموجودة على ZK Rollup ، ثم توفر Volition قابلية التبديل هذه.
** zkSync **
على غرار StarkNet ، أصر zkSync دائمًا على اختيار zkVM ، وهو ما يعادل لغة عالية المستوى ، وقد اجتذب الكثير من الاهتمام ، وشعبية كبيرة للغاية وحجم قفل. تم إطلاق zkSync 1.0 (zkSync Lite) على شبكة Ethereum mainnet في 15 يونيو 2020 ، محققة معدل نقل معاملة يبلغ حوالي 300 TPS ، ولكنه غير متوافق مع EVM. وسيتم إطلاق zkSync 2.0 (zkSync Era) في 24 مارس 2023.
الهدف من zkSync Era هو إنشاء البراهين بشكل أسرع باستخدام VM المخصص للتحسين بدلاً من مطاردة تكافؤ EVM. وهو يدعم Solidity و Vyper و Yul و Zinc (لغة البرمجة الداخلية للتجميع) من خلال مترجم LLVM قوي لتنفيذ معظم وظائف العقد الذكي. نظرًا لـ VM المطور ذاتيًا ، يدعم zkSync Era تجريد الحساب الأصلي ، بحيث يمكن لأي حساب استخدام أي رمز مميز للدفع.
بالإضافة إلى ذلك ، من خلال تطبيق بروتوكول zkPorter ، جنبًا إلى جنب مع ZK Rollups وتقنية التجزئة ، تمت زيادة إنتاجية الشبكة بشكل كبير ، لتصل إلى أكثر من 20000 TPS (على غرار تبديل توفر البيانات في Volitions).
بشكل عام ، zkSync هو مشروع L2 غني بيئيًا جذب انتباه المطورين والمستثمرين. على الرغم من وجود بعض الحالات الحديثة لمشاريع فاشلة تمامًا على zkSync ، لا يزال هناك سؤال حول ما إذا كان يمكن للمطورين الحصول على تجربة تطوير وترحيل جيدة على لغة مكافئة عالية المستوى لـ zkVM. يوجد حاليًا نقص في تقارير الاستخدام الدقيقة على مستوى المطور. إذا كان لدى المطورين خبرة جيدة ، فما الفائدة من الأنواع الأخرى من zkVM التي تسعى جاهدة لتكون قريبة من EVM؟ ما زلنا بحاجة إلى مزيد من الوقت للمراقبة.
** مضلع zkEVM **
أطلقت Polygon النسخة التجريبية من الشبكة الرئيسية zkEVM Rollup في 27 مارس ، والتي تعد أيضًا الجهاز الظاهري المكافئ لـ Ethereum ، وفتحت المصدر جميع رموز zkEVM. بالمقارنة مع zkSync ، فإن المقدار المقفل للمضلع zkEVM أصغر بكثير ، ولكن هناك أيضًا العديد من المشاريع الديناميكية والمثيرة للاهتمام في البيئة.
فيما يتعلق بتصميم Rollup ، يختلف Polygon عن Scroll من حيث أنه يستخدم نموذج إثبات الكفاءة (PoE) لتحفيز جهاز التسلسل والتجميع لحل بعض تحديات اللامركزية والمدققين بدون إذن. في النموذج المكون من خطوتين بدون إذن من فارز التجميع ، يمكن لأي فارز تقديم طلب لتعبئة دفعات من أجل الحصول على رسوم التعبئة ، ولكنه يحتاج إلى دفع رسوم الغاز للطبقة L1 وإيداع مبلغ معين من الرمز المميز ؛ في الوقت نفسه ، تحتاج رموز التجميع إلى تحديد أهدافها الخاصة لتعظيم الربح المضمون لكل جيل إثبات. بالإضافة إلى ذلك ، فإن وضعي Polygon و Volition (ZK Rollup و Validium) لهما أيضًا نماذج توفر بيانات متوافقة للغاية لتزويد المستخدمين بمستويات مختلفة من الخدمات.
بالإضافة إلى ذلك ، استثمرت Polygon أيضًا قدرًا كبيرًا من العمل في بروتوكول ZK ، وكان التأثير ملحوظًا أيضًا. في الوثيقة ، تلخص مزاياها التقنية ، بما في ذلك النقاط التالية بشكل أساسي:
أكثر توافقًا: أصر Polygon دائمًا على استخدام zkVM ، وهو ما يعادل EVM ، لتقليل تكلفة ترحيل المطورين dApps. في الوقت نفسه ، على الرغم من أن Polygon Miden تتبنى بروتوكول ZK-STARK ، إلا أنها لا تزال تدعم تشغيل عقود Solidity.
تحقق أسهل: السبب وراء انتقاد ZK Rollup غالبًا هو أن إنشاء أدلة على الصلاحية يتطلب أجهزة متخصصة باهظة الثمن يديرها البائعون وينقلون التكلفة إلى المستخدمين. يهدف Polygon ZK Rollup (مثل Polygon Zero) إلى تبسيط مخططات الإثبات بحيث يمكن للأجهزة ذات المستوى الأدنى المشاركة ، على سبيل المثال ، اختبارات إنشاء دليل Plonky2 على أجهزة الكمبيوتر الشخصية للمستهلكين.
عملية إنشاء إثبات أسرع والتحقق منه: يمكن لـ Polygon Zero إنشاء دليل 45 كيلو بايت في 170 مللي ثانية.
** الجزء الخامس ** ** فجوة بين التكنولوجيا النظرية والمشاريع العملية **
قام تقرير البحث هذا بشكل أساسي بالترويج العلمي لتكنولوجيا ZK وإدخال آلية Rollup ، مع التأكيد على أهمية توفر البيانات ، وتمييزًا معينًا حول مسألة ZK أو zkEVM Rollup. بالإضافة إلى ذلك ، على أساس التمييز بين zkVM و zkEVM ، فإنه يقوم أيضًا بفرز الاختلافات بين الأنواع الثلاثة من zkEVM والأنواع المختلفة ومسارات ZK ذات الصلة بالتفصيل. أخيرًا ، جنبًا إلى جنب مع العديد من المشاريع المفيدة ، قاموا بمراجعة الأطر الفنية الخاصة بكل منهم والبيئة القائمة.
ومع ذلك ، فيما يتعلق بمشاريع محددة ، تحتل المشاريع التي تختار لغات عالية المستوى مكافئة المكانة السائدة في السوق ، ويمكن أيضًا لبعض المنتجات ذات المركزية الجادة مثل StarkWare أن تفوز بميزة السوق. على الرغم من أن النوع الأول من الأجهزة الظاهرية المذكورة في البحث النظري له قيود قوية ، في ظل العملاء المحدودين في السوق ، يبدو أن "العالمية" تمثل عبئًا ، ولا يمكننا التمييز بين المشكلات التي تم اختراقها من خلال "التوسع الفعال" وإدراك التأثير الذي يتجاوز النظرية . بالطبع ، في الواقع ، كثير من الناس لا يهتمون بالميزات التقنية ، لذلك يبدو أن هذا ليس Web3 تمامًا ، ولكن أيضًا Web3 جدًا.
الغرض من تقنية Rollup هو زيادة الاستفادة من قيمة blockchain ، ولكن غالبًا بسبب الحاجة الملحة لأن تصبح "مفهومًا مبتكرًا" في السوق ، هناك ظاهرة "التراجع" والعودة إلى المركزية. هذه هي مشكلة السوق الحالية.
من السهل رؤية قيمة blockchain ، فمن منا لا يرغب في امتلاك جهاز كمبيوتر أبدي؟ لكن المشكلة الأساسية هي أنه عندما تكون السعة التشغيلية لهذا الكمبيوتر أقل بكثير من أي خادم من حولنا وتتطلب الكثير من الاستثمار في الموارد ، حتى لو كانت قيمة الاستخدام أقل بكثير من تكلفة المدخلات لدينا ، "كمنتج عام" ، لا يزال هل يمكن للجميع المشاركة؟
عندما يكون لدينا بالفعل منتجات من العديد من البلدان والمجتمعات وحتى الأفراد ، في ظل أي ظروف نحن على استعداد لتجاهل التكلفة العالية للاستخدام ومتابعة نتيجة "الإنترنت دائمًا ، صحيح دائمًا"؟ أعتقد أن هذا شيء تحتاج صناعة blockchain إلى التفكير فيه اليوم. يمكن لتقنية الالتفاف تحسين هذه المشكلة تقنيًا ، ولكن لا يزال هناك عدد كبير من المشكلات التي يجب تركها للسوق المتهور لحلها.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
zkEVM Rollup: الفجوة بين رؤية التكنولوجيا والمشروع
من أجل حل مشكلة التوسع في شبكة blockchain Layer 1 ، ظهر حل Rollup إلى حيز الوجود. إلى جانب تقنية ZK ، أصبحت ZK Rollup هي الحبيبة الجديدة لمسار Layer 2. ومع ذلك ، بالنسبة لمعظم الأشخاص ، قد يكون للمفاهيم ذات الصلة مثل ZK و Rollup و EVM حد معين من الفهم. لذلك ، الهدف من هذا التقرير البحثي هو فرز سلسلة من مفاهيم zkEVM Rollup بشكل منهجي بلغة موجزة وسهلة الفهم ، وتحليل عميق لتطور وتطوير تقنية zkEVM Rollup ، وتفسير البيئة الرئيسية بالتفصيل. إنه مصمم لمساعدتك على الفهم الكامل والحكم على اتجاه تطوير مسار zkEVM Rollup.
** الجزء 1 ** ** فهم ZK **
ZK (أو ZKP) ، الاسم الكامل هو Zero-Knowledge Proof ، أي إثبات المعرفة الصفرية. في التشفير ، يُعد إثبات المعرفة الصفرية أو بروتوكول المعرفة الصفرية طريقة يمكن من خلالها لطرف واحد (المُثبِّت) الإرسال إلى الطرف الآخر (المُصدق على التحقق) لإثبات حقيقة دون الكشف عن المعلومات المحددة للحقيقة ، أي أن أحد الأطراف (المُثبِت) يمكنه أن يُعلم الطرف الآخر ما إذا كانت الحقيقة صحيحة دون الكشف عن أي "معلومات محددة" عن في الواقع ، يمكن استخدام تقنية ZK في الخصوصية. يوفر لنا مجال الحماية مساحة كبيرة للخيال.
بالطبع ، بالإضافة إلى مزايا حماية الخصوصية التي يمكن أن توفرها تقنية ZK ، في ZK Rollup ، تعد تقنية ZK أكثر أهمية لحل مشكلة "التحقق الصعب". تعتبر عملية "التحقق" مهمة جدًا بالنسبة إلى blockchain ، حيث تهدف معظم عمليات الحساب في Ethereum إلى تلبية متطلبات التحقق ، ويمكن أن يقلل ZK Rollup بشكل كبير من الوقت الذي يقضيه في التحقق من خلال شبكة العقدة بأكملها. على سبيل المثال ، إذا استغرقت الكتلة وقتًا طويلاً للتحقق من أنها تفي بقواعد الشبكة بالكامل عندما تم إنشاء الكتلة ، فيمكن أن يكون هناك مُثبِت واحد يتحقق أولاً من الكتلة وينشئ "دليلًا" على نتيجة الحساب لهذه الكتلة ، والباقي يمكن تحقيق الغرض من التحقق من الكتلة عن طريق التحقق بسرعة من هذا "الإثبات" بدلاً من الكتلة الأصلية بكمية ضخمة من الحساب.
ينقسم بروتوكول ZK البسيط إلى الخطوات التالية ، وإنشاء المفتاح ، والإثبات والتحقق ، وسأفككها لك واحدة تلو الأخرى.
** 01 ** ** إنشاء المفتاح والإثبات والتحقق **
في ZK ، نحتاج أولاً إلى تحويل المسألة ليتم التحقق منها إلى تعبير رياضي ، ثم إلى كثير حدود ، والتعبير عنها في شكل دائرة حسابية. عندما يتم تحويل برنامج إلى دائرة حسابية ، يتم تقسيمه إلى خطوات فردية تتكون من عمليات حسابية أساسية مثل الجمع والطرح وما إلى ذلك. كدالة سيتم إخراجها ، يمكن تحويلها إلى مخطط الدائرة التالي ، انظر الشكل 1.
الشكل 1 مثال على مخطط الدائرة ، يمكن ملاحظة أن جميع العمليات في الدائرة مقسمة إلى أبسط العمليات الأساسية | المصدر
باستخدام هذه الدائرة وبعض الأرقام العشوائية كمدخلات ، يمكننا إنشاء مفتاح إثبات (pk ، مفتاح إثبات) ومفتاح التحقق (vk ، مفتاح التحقق) لعملية التحقق اللاحقة ، يظهر الرسم التخطيطي في الشكل 2.
الشكل 2 إنشاء "المعلمات العامة"
يتطلب نظام الإثبات لدينا أيضًا نوعين من المدخلات - خاص وعام ، جنبًا إلى جنب مع مفتاح الإثبات لإنشاء الدليل. من بينها ، المدخلات الخاصة (الشاهد) هي السر الذي نريد إخفاءه ، والمدخلات العامة هي المعلومات التي يمكن نشرها. على سبيل المثال ، في المعادلة X + Y \ * Z = OUT ، X و OUT هي مدخلات عامة ، بينما Y و Z لهما قيم لا نريد أن تكون عامة للمدقق. على الرغم من إمكانية استنتاج قيمة Y \ * Z بناءً على المدخلات العامة ، إلا أن القيم المحددة لـ Y و Z لا تزال غير مؤكدة.
الشكل 3 عملية الإثبات وعملية التحقق من ZK-SNARKs
عندما يتلقى المدقق الدليل ، فإنه يستخدم الإدخال العام ومفتاح الإثبات والتحقق للتحقق من الإثبات ، ويعيد نتيجة التحقق (أي ما إذا كان التحقق ناجحًا).
بعد فهم العملية المذكورة أعلاه ، يمكننا تطبيق هذه التقنية لمنع التحقق لتحقيق ZK-SNARK صغير ، كما هو موضح في الشكل 3. هناك العديد من البروتوكولات والطرق لتحقيق إثبات عدم المعرفة الصفرية. SNARK سهل الفهم نسبيًا ، وهو أيضًا اختيار معظم المشاريع في هذه المرحلة. في الفقرة "من ZK-SNARKs إلى ZK-STARKs" سنتحدث عن مزايا وعيوب SNARKs.
** 02 ** ** جرب SNARK قليلاً **
لنأخذ إثبات عدم المعرفة لشجرة Merkle التي تسجل حالة الحساب كمثال للتدريب. تسجل Merkle Tree العنوان ورصيد الحساب. عندما تكون هناك معاملة جديدة تحتاج إلى تحديث Merkle Tree ، نحتاج إلى إجراء العمليات التالية:
تحقق من أن المرسل والمتلقي للمعاملة موجودان على العقد الطرفية للشجرة.
التحقق من توقيع المرسل.
تحديث أرصدة المرسل والمستلم.
قم بتحديث عقدة جذر Merkle Tree (مثل Merkle Root) واستخدمها كإخراج نهائي.
في حالة عدم وجود أدلة على المعرفة الصفرية ، يحتاج المدقق إلى تكرار هذه الخطوات لضمان دقة الحساب. ولكن بعد استخدام إثبات عدم المعرفة ، فإن الوضع مختلف. أولاً ، نحتاج إلى تحديد نوعين من المدخلات:
أثناء هذه العملية ، تكون معلومات المعاملة الجديدة فقط وجذر Merkle الأصلي و Merkle Root المحدث مدخلات عامة.
تعمل Merkle Tree نفسها كشاهد (شاهد) ولا تحتاج إلى قراءتها أو معالجتها بواسطة المدقق.
ثانيًا ، نحتاج إلى إنشاء مفاتيح ودوائر حسابية. نقوم ببناء عمليات حسابية مثل تحديث Merkle Tree والتحقق من عنوان الإدخال والإخراج في دوائر الحساب للحصول على مفاتيح الإثبات ومفاتيح التحقق. لا علاقة لهذه الدائرة بمعلومات معاملات الإدخال ، ولا مع Merkle Root الحالي ، لأن طريقة حساب Merkle Tree ثابتة.
في مرحلة إنشاء البراهين ، نأخذ شجرتي Merkle ومعلومات المعاملة كمدخلات. في مرحلة المدقق ، يمكن للمدقق ضمان موثوقية التحديث دون الحصول على Merkle Tree ، أي دون معرفة معلومات الحساب. الدائرة تشبه الصندوق الأسود الصلب ، طالما أن الإدخال صحيح ، فستحصل على الإخراج الصحيح.
باستخدام إثبات المعرفة الصفرية ، يمكن للمحققين الآخرين التحقق بسرعة من مصداقية عملية إنشاء Merkle Tree ، وبالتالي تقليل وقت التحقق المتكرر على الشبكة ، ولا يلزم الكشف عن معلومات Merkle Tree للمدقق.
** 03 ** ** من ZK-SNARKs إلى ZK-STARKs **
بروتوكول الإثبات المذكور أعلاه هو ZK-SNARKs. يرمز SNARK إلى الحجج الموجزة غير التفاعلية للمعرفة ، حيث يشير الإيجاز إلى إيجاز هذه الطريقة ، ويشير غير التفاعلي إلى ذلك بالمقارنة مع طرق الإثبات الأخرى ، فإن SNARKs هي براهين غير تفاعلية ، أي أن المدقق يحتاج فقط إلى الاستخدام الإثبات المقدم من قبل المثقف يمكن أن يحصل الدليل الذي تم إنشاؤه على نتيجة التحقق. ومع ذلك ، هناك بعض المشاكل مع ZK-SNARKs. في مرحلة توليد المفاتيح ، تكون الدائرة والرقم العشوائي معادلين لمجموعة من المعلمات العامة الأولية ، وهناك مشكلة مركزية حتمية في عملية توليد هذه المعلمة العامة.
ZK-STARKs لها نهج مختلف يعتمد على SNARKs ، حيث تعني "s" قابلية التوسع ، مما يثبت أن وقت التوليد ووقت الحساب الأصلي شبه خطي ، ووقت التحقق لوغاريتمي في الحساب الأصلي ، مما يعني في في حالة وجود مجموعة بيانات كبيرة كبيانات ، يتم تقصير وقت التحقق المطلوب بواسطة المدقق بشكل كبير.
في الوقت نفسه ، كإصدار مطور من ZK-SNARKs ، لا يمكن لـ ZK-STARK فقط تحسين كفاءة التحقق (الكفاءة النظرية 10 مرات) ، ولكن أيضًا لا تعتمد على المنحنيات البيضاوية أو الإعدادات الموثوقة ، ولا تتطلب العملية لتوليد المعلمات العامة الأولية (الحرف "T" يرمز إلى الشفافية) ، مما يلغي الحاجة إلى إعداد مركزي موثوق. يعتقد بعض المطورين أن وظيفة التجزئة في ZK-STARK يمكن أن تساعد في مقاومة الهجمات الكمومية.
ومع ذلك ، تم تقديم ZK-STARKs في وقت متأخر ، والتكنولوجيا الحالية ليست ناضجة بدرجة كافية ، وتعتمد على وظائف التجزئة ، مما يحد من تعدد استخداماتها. لا تزال ZK-SNARKs خوارزمية إثبات عامة. بعض الأمثلة على الخوارزميات القائمة على STARK تشمل Fractal و SuperSonic وما إلى ذلك ، وتشمل المشاريع ذات الصلة StarkWare و Polygon Miden وما إلى ذلك.
** الجزء 2 ** ** فهم التراكمية **
بالإضافة إلى ZK ، هناك مفهوم آخر نحتاج إلى فهمه وهو Rollup. تكمن أهمية Rollup في حل مشكلة الازدحام في شبكة الطبقة الأولى.
خذ Ethereum كمثال ، لديها حاليًا مشكلة ازدحام المعاملات. هناك طريقتان لحل هذه المشكلة: الأولى هي زيادة سعة المعاملات في blockchain نفسها ، مثل توسيع إنتاجية blockchain من خلال تقنيات مثل التجزئة. نهج آخر هو تغيير طريقة استخدام blockchain ، أي لأداء معظم الأنشطة في الطبقة الثانية (الطبقة 2 ، المشار إليها فيما يلي باسم L2) ، بدلاً من مباشرة على السلسلة. في هذه الحالة ، غالبًا ما يتم نشر العقد الذكي على السلسلة ، وهو المسؤول الوحيد عن معالجة الإيداعات والسحوبات ، ويستخدم طرقًا مختلفة لقراءة البيانات خارج السلسلة للتحقق من أن كل ما يحدث خارج السلسلة يتوافق مع القواعد. وهذا يعادل إقامة طريق سريع بجوار طريق صغير ، أي من خلال توسعة L2 لحل مشكلة الازدحام.
حاليًا ، الأنواع أو الحلول الثلاثة الرئيسية لتوسيع L2 هي قنوات الحالة ، والبلازما ، والتراكمية. هناك ثلاثة نماذج مختلفة ، لكل منها مزايا وعيوب. يمكن تصنيف جميع امتدادات L2 تقريبًا إلى هذه الفئات الثلاث (على الرغم من وجود بعض الخلافات حول التسمية ، مثل validium) ، ومن بينها Rollup مزاياها الخاصة.
** التراكمية وتوافر البيانات **
بالمقارنة مع حلول التوسع الأخرى ، فإن Rollup له مزايا معينة. ومن المزايا الأكثر بديهية أنه يحل مشكلة توفر بيانات البلازما (المذكورة في فصل "توفر البيانات" من مقالة السيد دارين) ، وهنا سأقوم ببعض ملحق.
حقيقة أن البيانات متصلة بالسلسلة مهمة جدًا (ملاحظة: وضع البيانات "على IPFS" لن ينجح ، لأن IPFS لا يوفر التحقق من مستوى الإجماع على عدم وجود ضمان بتوفر بيانات معينة ، أي يجب أن تكون البيانات مخزنة في كتل). في مخططي التوسع للبلازما والقناة السابقة ، يتم وضع البيانات والحسابات بالكامل في شبكة الطبقة الثانية. عندما تتفاعل شبكة الطبقة الثانية مع Ethereum ، لا يتم تضمين جميع بيانات المعاملات في سلسلة الطبقة الثانية. من الحالة من منظور الجهاز ، أي ، لا يتم تضمين كل تغيير حالة في سلسلة البلازما. سيؤدي هذا إلى حقيقة أنه إذا تم فصل Ethereum عن شبكة الطبقة الثانية مثل Plasma ، فلن تكون قادرة على استعادة تغييرات الحالة السابقة.لذلك ، فإن توفر بيانات Ethereum يعتمد بشكل كبير على حماية بيانات البلازما.
** آلية التراكم **
من أجل ضمان توفر البيانات ، يختار السوق التراكمي ، فكيف يعمل التراكمي؟
الشكل 4 جذر الحالة في العقد L1 | المصدر
في تصميم Rollup ، يوجد عقد تراكمي على السلسلة الرئيسية ، والذي يخزن جذر الحالة. يمكن اعتبار جذر الحالة هذا كإصدار مطور من جذر Merkle لشجرة Merkle ، والذي يخزن رصيد الحساب (أي نوع من الحالة) ، ورمز العقد ومعلومات أخرى. يوضح الشكل 4 جذر الحالة المخزن في عقد التجميع .
تحتوي العقدة L2 على ثلاث وظائف رئيسية: أولاً ، تحديد المعاملات التي يجب تعبئتها أولاً (عادةً ما يُطلق على هذا النوع من العقدة أو العميل اسم Sequencer Sequencer) ، وثانيًا ، يجب تقديم دليل لكل بيانات مجمعة ، وأخيراً إرسالها إلى L1 يتم التحقق من عقد التجميع بموجب هذا العقد. يوضح الشكل 5 دور منظم التسلسل في L2.
الشكل 5 تسلسل وإثبات وتقديم الدُفعة هي الوظائف الرئيسية لمرحلة L2 | المصدر
على وجه التحديد ، يمكن لـ L2 نقل دفعة من البيانات (دُفعة) إلى L1. يمكن أن تكون هذه البيانات عبارة عن مجموعات معاملات مضغوطة للغاية أو تغييرات الحالة بعد تشغيل العقد ، وتتضمن أيضًا جذر الحالة المخزن في عقد L1 وجذر ما بعد الحالة الجديد ( جذر ما بعد الحالة) تم الحصول عليه بعد معالجة L2 للبيانات. يتحقق العقد من صحة جذر ما بعد الحالة بناءً على هذه البيانات. بمجرد اجتياز التحقق ، سيتم تأكيد مجموعة البيانات في طبقة L1 ، لإكمال العملية على السلسلة من L2 إلى L1.
يتم حساب جذر ما بعد الحالة (جذر ما بعد الحالة) من البيانات الأصلية. للتأكد من صحة جذر ما بعد الحالة الجديد في البيانات المقدمة ، فإن الطريقة الأكثر وضوحًا هي السماح لـ L1 بإعادة الحساب مرة واحدة. ومع ذلك ، فإن القيام بذلك سيضع بلا شك الكثير من الضغط على L1. لحل هذه المشكلة الحرجة ، هناك مخططا تحسين مختلفان تمامًا ، Optimistic Rollup و ZK Rollup.
** ZK Rollup و Optimistic Rollup **
تستخدم ZK Rollup أدلة بروتوكول التشفير مثل ZK-SNARKs أو ZK-STARKs للتحقق من صحة جذر ما بعد الحالة بعد تنفيذ الدفعة. بغض النظر عن مقدار الحساب في L2 ، يمكن لـ ZK Rollup التحقق بسرعة من سلسلة L1.
نوع آخر من الإثبات هو Optimistic Rollup ، والذي يستخدم إثباتات الاحتيال. يوجد تشبيه واضح هنا ، مثل الأم التي لا تدقق في واجبات ابنها المنزلية كثيرًا ، ولكن طالما لم يتم إنجاز الواجب المنزلي مرة واحدة ، فستتم معاقبتها بشدة. بموجب هذه الآلية ، يتتبع عقد التراكم التاريخ الكامل لجذر الحالة وتجزئة كل دفعة. إذا اكتشف شخص ما أن الدُفعة لها جذر غير صحيح لما بعد الحالة ، فيمكنه نشر دليل على أن الدُفعة تم حسابها بشكل غير صحيح. تتحقق العقد الأخرى معًا من الإثبات واستعادة الدُفعة وجميع الدُفعات اللاحقة.
يلخص الشكل 6 مقارنة مزايا وعيوب Optimistic Rollup و ZK Rollup. من المهم أن نلاحظ هنا أن ZK Rollup يتفوق في TPS وله ميزة كبيرة في دورات الاسترداد. ومع ذلك ، فإن عيوبها هي توافق EVM والاستهلاك الحسابي في طبقة L2:
مشاريع التراكمية المتفائلة ، مثل التفاؤل و Arbitrum ، تستخدم OVM و AVM على التوالي ، وبيئاتها الافتراضية هي أساسًا مثل EVM ، حتى تتمكن من ترحيل عقود L1 مباشرة إلى L2 للنشر. ومع ذلك ، في ZK Rollup ، من الصعب جدًا استخدام ZK-SNARK لإثبات تنفيذ EVM العام ، لأن EVM لم يتم تطويره وفقًا للمتطلبات الرياضية لحساب إثبات ZK ، لذلك من الضروري تحويل نوع معين من عميل EVM للاستخدام تقنية ZK للتحقق من المعاملات وعمليات العقد.
في الوقت نفسه ، حتى بعد التحويل المقابل ، لا تزال عملية ZK تتطلب الكثير من مدخلات طاقة الحوسبة ، لذا فإن ZK Rollup ليست فعالة مثل Optimistic Rollup في كفاءة طبقة L2.
يوفر ZK Rollup ضغط بيانات أفضل من Optimistic Rollup ، لذلك يمكنه إرسال بيانات أصغر على L1.
نظرًا لأن عملية التحقق من الإثبات في ZK أسرع ولها كثافة دفعية أعلى ، فإن ZK Rollup يكون أقل في استهلاك حساب طبقة L1. يمكن فهم أن دفع العقدة على L2 يقلل بشكل كبير من متطلبات العقد L1 ، وبالتالي يحسن بشكل كبير قابلية التوسع في الطبقة L1.
الشكل 6 مقارنة بين طريقتين للجمع | المصدر:
** ZK Rollup أو zkEVM Rollup؟ **
على الرغم من أن ZK Rollup تبدو جذابة ، إلا أن هناك العديد من الصعوبات في النشر الفعلي. في الوقت الحالي ، لا يزال ZK Rollup يعاني من قيود كبيرة ، بينما لا يزال Optimistic Rollup هو الحل السائد. معظم ZK Rollups التي تم تنفيذها هي أيضًا مصممة خصيصًا لبعض التطبيقات المحددة.
كيفية فهم ZK Rollup المخصص؟ ينشئ المطورون دوائر خاصة بالتطبيقات ("ASICs") لمختلف DApps ، مثل Loopring و StarkEx rollup و zkSync 1.0 ، والتي تدعم أنواعًا معينة من الدفع أو تبادل الرموز أو صب NFT. ومع ذلك ، يتطلب تصميم الدوائر الخاصة بهم درجة عالية من المعرفة التقنية ، مما يؤدي إلى ضعف خبرة المطور. بأخذ نوع معين من بيانات الدفع كمثال ، تقوم العقدة بإرسال بيانات المعاملة إلى جهاز التسلسل ، ويقوم منظم التسلسل بحزمها في دفعة وإرسالها إلى العقدة التي تقدم الإثبات كمدخل عام وعملية الإثبات والعقد عملية التنفيذ على الجهاز الظاهري ليس لديها ما تفعله ، ZK هي المسؤولة فقط عن إثبات حساب التجميع وعملية الضغط لنتيجة تنفيذ محددة.
ويمثل zkEVM Rollup القدرة على تجميع نتائج تشغيل الجهاز الظاهري. عند تشغيل عقد ذكي للأغراض العامة على طبقة L2 ، من الضروري إثبات صحة انتقال الحالة قبل وبعد تشغيل العقد ، ويلزم وجود بيئة افتراضية لدعم تشغيل خوارزمية ZK. لذلك ، فإن معنى zkEVM هو تشغيل العقد ، وإخراج الحالة النهائية ، وإثبات صحة عملية تنفيذ العقد ، وتقديم سجلات المعاملات ، وسجلات الحساب ، وبيانات سجل تغيير الحالة معًا في مجموعة. تحتاج الطبقة L1 فقط إلى التحقق بسرعة من الإثبات ، والنفقات العامة صغيرة ، وليس هناك حاجة لتشغيل العقد مرة أخرى.يوضح الشكل 7 بوضوح دور zkVM. تجدر الإشارة إلى أن zkEVM هو في الواقع آلة افتراضية تشبه EVM تعمل على طبقة L2 ، لذا فإن المصطلح الأكثر دقة هو Zero Knowledge Virtual Machine ، zkVM ، لكن الجميع يؤكد أنه متوافق مع Ethereum ويطلق عليه zkEVM.
الشكل 7 رسم تخطيطي يوضح zkVM | المصدر
تدرس المشاريع الحالية أيضًا التخلي التدريجي عن التحسين لتطبيقات محددة ، والترقية لدعم تشغيل عقود الأغراض العامة ، أي zkEVM Rollup. لذلك ، على الرغم من أن zkEVM Rollup هو مفهوم ثانوي لـ ZK Rollup ، في معظم الحالات ، عندما يتم ذكر ZK Rollup ، فإنه يشير إلى zkEVM rollup.
** الجزء 4 ** ** نظرة عامة على مشروع مجموعة zkEVM **
في النصف الأول من عام 2023 ، ستظهر العديد من مشاريع zkEVM بشكل سريع. وعند الاهتمام بهذه المشاريع ، يركز المؤلف بشكل أساسي على الجوانب التالية:
تقدم المشروع الحالي: بما في ذلك مرحلة المشروع الحالية ، ووقت الإطلاق المتوقع لشبكة الاختبار والشبكة الرئيسية ، وما إذا كانت متوافقة مع خارطة طريق التطوير.
التفاعل الفعلي للمشروع: من خلال التفاعل مع شبكة الاختبار (الرئيسية) ، وما إلى ذلك ، تشعر بشكل شخصي بشبكة TPS ، ووقت التأكيد لمعاملة واحدة ، وما إلى ذلك ، ولديك شعور بديهي بأداء الشبكة.
التوافق مع zkEVM: هذه هي النقطة الفنية الأساسية والأصعب في الحكم عليها.حتى لو كانت بعض المشاريع مفتوحة المصدر ، فإن التكنولوجيا على مستوى VM هي الأصعب وتتضمن المزيد من بروتوكولات ZK. على وجه التحديد ، من الضروري الانتباه إلى بروتوكول ZK وأمن الجهاز الظاهري والتوافق وما إلى ذلك.
zkEVM العمارة التراكمية: بالمقارنة مع zkEVM ، ستكشف المشاريع العامة عن معمارية التراكمية في الأوراق البيضاء والمستندات الفنية الأخرى ، والفرق العام أقل ، ولكن يجب الانتباه إلى درجة اللامركزية الإجمالية.
التشغيل البيئي: عدد مستخدمي المشروع ، ودرجة النشاط ، وتشغيل واحتضان بيئة التطبيق على السلسلة ، وصيانة مجتمع المطورين هي مؤشرات تعكس برفق تشغيل المشروع.
وضع الاستثمار والتمويل.
تتناول هذه المقالة المشروع بشكل أكبر من منظور النقاط الأربع الأولى ، وتولي مزيدًا من الاهتمام للبنية العامة لـ zkEVM Rollup من المستوى الفني.
** تمرير **
تأسس فريق Scroll في عام 2021 ، وهو ملتزم بتطوير مكافئ EVM لـ ZK Rollup لتوسيع نطاق Ethereum. منذ ما يقرب من عامين ، يعمل Scroll مع فريق Privacy and Scaling Explorations ومساهمين آخرين من المصادر المفتوحة لإنشاء مجموعة متوافقة مع الرمز الثانوي بشكل عام . zkEVM. في نهاية شهر فبراير ، أعلنت Scroll أن شبكة اختبار Alpha الخاصة بها أصبحت متاحة الآن على Goerli. يمكن لأي مستخدم المشاركة في الاختبار الفني دون إذن. يبلغ متوسط وقت الحظر لشبكة الاختبار 3 ثوانٍ. وهناك بالفعل أكثر من 20 مليون معاملة و أكثر من 1.5 مليون كتلة وأكثر من 4 ملايين عنوان تفاعلي. في الوقت نفسه ، فتح Scroll أيضًا واجهة النظام البيئي لموقع الويب في 11 أبريل.
انطلاقًا من الكشف الأخير عن المعلومات ، يتقدم Scroll باستمرار على طريق معادلة النوع 2 EVM. أكمل Scroll مؤخرًا التطوير المتوافق لجميع أكواد التشغيل EVM ، وهو في طور التدقيق ، وفي الوقت نفسه ، فإن الهدف التالي هو أن يكون متوافقًا مع معاملات EIP2718.
فيما يتعلق بالهندسة المعمارية الفنية ، فإن بنية Scroll تقليدية نسبيًا ، لذلك سيتم تقديمها بالتفصيل هنا. كما هو موضح في الشكل 8 ، يتم تقسيمه بشكل أساسي إلى جزأين: الجزء الأساسي هو zkEVM ، والذي يستخدم لإثبات صحة تنفيذ EVM في L2 ؛ ولكن لتحويل zkEVM إلى ZK Rollup كامل على Ethereum ، يحتاج L2 الكامل إلى يتم بناؤها حول هندسة zkEVM. على وجه التحديد ، تتكون شبكة اختبار التمرير ألفا الحالية من عقدة التمرير وعقد الجسر وعقد التجميع:
الشكل 8 العمارة الكلية التمرير | المصدر
أ) يفتح Sequencer ، ما يسمى بـ Sequencer ، JSON-RPC للمستخدمين والتطبيقات ، ويقرأ المعاملات في تجمع المعاملات ويولد كتل L2 وجذور الحالة. في هذه المرحلة ، تكون عُقد التسلسل في Scroll مركزية ، وستصبح لامركزية تدريجياً في الترقيات المستقبلية.
ب) المنسق مسؤول عن الاتصال بين الأسطوانة وعقدة التمرير. عندما يتم إنشاء كتلة جديدة في جهاز التسلسل ، يتم اختيار الأسطوانة الموجودة في التجمع بشكل عشوائي لإنشاء الدليل.
ج) يراقب المُرحِّل العقد الجسر وعقد التجميع على سلاسل Ethereum و Scroll. يضمن عقد التجميع توفر البيانات لبيانات L2 على مستوى L1 ، ويضمن إمكانية استعادة كتلة L2 في طبقة L1. بمجرد التحقق من الكتلة المرسلة بواسطة طبقة L2 من خلال عقد التجميع على طبقة L1 ، فإن الكتلة سيصل إلى النهاية عند الطبقة L2. الحالة الثابتة لـ. يعتبر عقد الجسر مسؤولاً عن الاتصال بين عقود السلسلة المزدوجة عند عبور السلاسل أو إرسال رسائل عشوائية في كلا الاتجاهين أو إكمال عمليات تعهد الأصول وسحبها عند عبور السلاسل.
الشكل 9 2. شبكة الأسطوانة | المصدر
أ) يقوم Roller أولاً بتحويل تتبع الإجراء الذي تم استلامه من المنسق (أي ، العمليات المحددة التي قام بها العقد والعناوين المعنية) إلى شهود الدائرة.
ب) يولد البراهين لكل دائرة zkEVM ويجمع أخيرًا هذه البراهين من دوائر ZK متعددة.
** StarkWare **
يوفر StarkWare حلاً للتوسيع قائمًا على STARK لضمان أمان L2 وسرعة وتجربة مستخدم سلسة. أنها تدعم أوضاع توفر البيانات المتعددة. StarkNet هي شبكة L2 الخاصة بهم ، في حين أن StarkEx هي خدمة تحقق من التراكمية لمستخدمي المؤسسات ، ويمكن بناء DApps على خدمات StarkEx. ومع ذلك ، يمكن حاليًا كتابة الدوائر المخصصة فقط من أجل DApps محددة ، وليس مجموعة zkEVM العامة. تدعم StarkEx سلسلة من خدمات التوصيل والتشغيل ، بما في ذلك سك وتداول NFT وتداول المشتقات وما إلى ذلك. من حيث البيئة ، فإن منصة تداول العقود الآجلة اللامركزية DYDX هي مستخدم مخلص لـ StarkWare.
StarkNet ، بالمعنى الدقيق للكلمة ، هو zkVM. بدلاً من عمل دوائر ZK لأكواد تشغيل Ethereum ، فقد صنعت مجموعة من لغات التجميع الأكثر ملاءمة لـ ZK ، AIR (التمثيل الجبري المتوسط) واللغة عالية المستوى في القاهرة. على الرغم من أن StarkNet نفسها غير متوافقة مع EVM ، إلا أنه لا يزال من الممكن أن تكون متوافقة مع Ethereum من خلال طرق أخرى بما في ذلك Kakarot (Kakarot هو zkEVM مكتوب في القاهرة ، وهو zkEVM الذي يعادل رمزه الثانوي EVM). وفقًا لفهمي ، يعد StarkNet مشروعًا مركزيًا نسبيًا ، أحدها أنه لا يمكن مزامنته مع الترقية الأمنية لـ Ethereum. لذلك ، من الضروري تركيز موظفي البحث والتطوير لتعويض أوجه القصور في الأمان ومتابعة التطوير و تعديل اتفاقية ETH الجديدة.
تستخدم StarkNet نظام STARK كنظام إثبات ، وبالمقارنة مع SNARK ، فإن STARK لديها ابتكارات أكثر. لا يحتاج إلى الاعتماد على "إعدادات موثوقة" مثل SNARK. علاوة على ذلك ، فإنه يحتوي أيضًا على افتراضات تشفير أبسط ، ويتجنب الحاجة إلى المنحنى الإهليلجي ، والاقتران ، وافتراضات المعرفة الأسية ، ويعتمد فقط على نظرية التجزئة والمعلومات ، لذلك فهو أكثر مقاومة للهجمات الكمومية. بشكل عام ، تعتبر STARKs أكثر أمانًا من SNARKs. فيما يتعلق بقدرات التوسع ، فإن STARK لها تأثير هامشي كبير ، وكلما زاد الدليل ، انخفضت التكلفة الإجمالية.
ومع ذلك ، فيما يتعلق بالهندسة المعمارية ، لا يوجد حاليًا سوى جهاز تسلسل واحد (منظم التسلسل) في النظام ، يتم التحكم فيه بواسطة StarkWare ، ولا يوجد سوى Prover واحد (أي المُثبِّت الذي ينشئ ZK Proof) ، والذي لا يولد فقط البراهين لـ StarkNet ، ولكنها تعمل أيضًا من تلقاء نفسها. دليل الجيل لجميع التطبيقات الأخرى في مجموعة StarkEx.
** متغيرات ZK Rollup: Validiums and Volitions **
Validium هو أيضًا حل قياس L2 يستخدم دليلًا على الحساب مثل ZK Rollup لفرض تكامل عملية المعاملة. على عكس ZK Rollup ، لا يقوم Validium بتخزين بيانات المعاملات على شبكة Ethereum الرئيسية. يعد التضحية بتوافر البيانات على السلسلة مقايضة يمكن أن تؤدي إلى تحسينات هائلة في قابلية التوسع ، والنقطة الأكثر إلحاحًا هي أن Validiums يمكنها معالجة حوالي 9000 معاملة في الثانية.
ولكن في نظر المؤلف ، لا يمكن اعتبار Validium على أنها مجموعة ZK Rollup صارمة. هذا الحل مشابه لـ Plasma ، ولا يحقق توفر البيانات في طبقة L1 ، لذلك لا يمكن اعتباره تراكمي. الاختلاف مع Plasma هو أن Plasma قد أنشأت "آلية خروج لمدة سبعة أيام" مماثلة لـ OP Rollup في طبقة L2 ، بينما تستخدم Validium وتعني ZK لتقصير وقت التحقق من البيانات في طبقة L2 ولا تزامن البيانات إلى L1.
تتيح Volition ، التي ابتكرتها StarkWare ، للمستخدمين التبديل بسهولة بين ZK Rollup و Validium. على سبيل المثال ، قد تكون بعض التطبيقات ، مثل تبادلات المشتقات اللامركزية ، أكثر ملاءمة لـ Validium ، بينما لا تزال ترغب في أن تكون قابلة للتشغيل البيني مع التطبيقات الموجودة على ZK Rollup ، ثم توفر Volition قابلية التبديل هذه.
** zkSync **
على غرار StarkNet ، أصر zkSync دائمًا على اختيار zkVM ، وهو ما يعادل لغة عالية المستوى ، وقد اجتذب الكثير من الاهتمام ، وشعبية كبيرة للغاية وحجم قفل. تم إطلاق zkSync 1.0 (zkSync Lite) على شبكة Ethereum mainnet في 15 يونيو 2020 ، محققة معدل نقل معاملة يبلغ حوالي 300 TPS ، ولكنه غير متوافق مع EVM. وسيتم إطلاق zkSync 2.0 (zkSync Era) في 24 مارس 2023.
الهدف من zkSync Era هو إنشاء البراهين بشكل أسرع باستخدام VM المخصص للتحسين بدلاً من مطاردة تكافؤ EVM. وهو يدعم Solidity و Vyper و Yul و Zinc (لغة البرمجة الداخلية للتجميع) من خلال مترجم LLVM قوي لتنفيذ معظم وظائف العقد الذكي. نظرًا لـ VM المطور ذاتيًا ، يدعم zkSync Era تجريد الحساب الأصلي ، بحيث يمكن لأي حساب استخدام أي رمز مميز للدفع.
بالإضافة إلى ذلك ، من خلال تطبيق بروتوكول zkPorter ، جنبًا إلى جنب مع ZK Rollups وتقنية التجزئة ، تمت زيادة إنتاجية الشبكة بشكل كبير ، لتصل إلى أكثر من 20000 TPS (على غرار تبديل توفر البيانات في Volitions).
بشكل عام ، zkSync هو مشروع L2 غني بيئيًا جذب انتباه المطورين والمستثمرين. على الرغم من وجود بعض الحالات الحديثة لمشاريع فاشلة تمامًا على zkSync ، لا يزال هناك سؤال حول ما إذا كان يمكن للمطورين الحصول على تجربة تطوير وترحيل جيدة على لغة مكافئة عالية المستوى لـ zkVM. يوجد حاليًا نقص في تقارير الاستخدام الدقيقة على مستوى المطور. إذا كان لدى المطورين خبرة جيدة ، فما الفائدة من الأنواع الأخرى من zkVM التي تسعى جاهدة لتكون قريبة من EVM؟ ما زلنا بحاجة إلى مزيد من الوقت للمراقبة.
** مضلع zkEVM **
أطلقت Polygon النسخة التجريبية من الشبكة الرئيسية zkEVM Rollup في 27 مارس ، والتي تعد أيضًا الجهاز الظاهري المكافئ لـ Ethereum ، وفتحت المصدر جميع رموز zkEVM. بالمقارنة مع zkSync ، فإن المقدار المقفل للمضلع zkEVM أصغر بكثير ، ولكن هناك أيضًا العديد من المشاريع الديناميكية والمثيرة للاهتمام في البيئة.
فيما يتعلق بتصميم Rollup ، يختلف Polygon عن Scroll من حيث أنه يستخدم نموذج إثبات الكفاءة (PoE) لتحفيز جهاز التسلسل والتجميع لحل بعض تحديات اللامركزية والمدققين بدون إذن. في النموذج المكون من خطوتين بدون إذن من فارز التجميع ، يمكن لأي فارز تقديم طلب لتعبئة دفعات من أجل الحصول على رسوم التعبئة ، ولكنه يحتاج إلى دفع رسوم الغاز للطبقة L1 وإيداع مبلغ معين من الرمز المميز ؛ في الوقت نفسه ، تحتاج رموز التجميع إلى تحديد أهدافها الخاصة لتعظيم الربح المضمون لكل جيل إثبات. بالإضافة إلى ذلك ، فإن وضعي Polygon و Volition (ZK Rollup و Validium) لهما أيضًا نماذج توفر بيانات متوافقة للغاية لتزويد المستخدمين بمستويات مختلفة من الخدمات.
بالإضافة إلى ذلك ، استثمرت Polygon أيضًا قدرًا كبيرًا من العمل في بروتوكول ZK ، وكان التأثير ملحوظًا أيضًا. في الوثيقة ، تلخص مزاياها التقنية ، بما في ذلك النقاط التالية بشكل أساسي:
أكثر توافقًا: أصر Polygon دائمًا على استخدام zkVM ، وهو ما يعادل EVM ، لتقليل تكلفة ترحيل المطورين dApps. في الوقت نفسه ، على الرغم من أن Polygon Miden تتبنى بروتوكول ZK-STARK ، إلا أنها لا تزال تدعم تشغيل عقود Solidity.
تحقق أسهل: السبب وراء انتقاد ZK Rollup غالبًا هو أن إنشاء أدلة على الصلاحية يتطلب أجهزة متخصصة باهظة الثمن يديرها البائعون وينقلون التكلفة إلى المستخدمين. يهدف Polygon ZK Rollup (مثل Polygon Zero) إلى تبسيط مخططات الإثبات بحيث يمكن للأجهزة ذات المستوى الأدنى المشاركة ، على سبيل المثال ، اختبارات إنشاء دليل Plonky2 على أجهزة الكمبيوتر الشخصية للمستهلكين.
عملية إنشاء إثبات أسرع والتحقق منه: يمكن لـ Polygon Zero إنشاء دليل 45 كيلو بايت في 170 مللي ثانية.
** الجزء الخامس ** ** فجوة بين التكنولوجيا النظرية والمشاريع العملية **
قام تقرير البحث هذا بشكل أساسي بالترويج العلمي لتكنولوجيا ZK وإدخال آلية Rollup ، مع التأكيد على أهمية توفر البيانات ، وتمييزًا معينًا حول مسألة ZK أو zkEVM Rollup. بالإضافة إلى ذلك ، على أساس التمييز بين zkVM و zkEVM ، فإنه يقوم أيضًا بفرز الاختلافات بين الأنواع الثلاثة من zkEVM والأنواع المختلفة ومسارات ZK ذات الصلة بالتفصيل. أخيرًا ، جنبًا إلى جنب مع العديد من المشاريع المفيدة ، قاموا بمراجعة الأطر الفنية الخاصة بكل منهم والبيئة القائمة.
ومع ذلك ، فيما يتعلق بمشاريع محددة ، تحتل المشاريع التي تختار لغات عالية المستوى مكافئة المكانة السائدة في السوق ، ويمكن أيضًا لبعض المنتجات ذات المركزية الجادة مثل StarkWare أن تفوز بميزة السوق. على الرغم من أن النوع الأول من الأجهزة الظاهرية المذكورة في البحث النظري له قيود قوية ، في ظل العملاء المحدودين في السوق ، يبدو أن "العالمية" تمثل عبئًا ، ولا يمكننا التمييز بين المشكلات التي تم اختراقها من خلال "التوسع الفعال" وإدراك التأثير الذي يتجاوز النظرية . بالطبع ، في الواقع ، كثير من الناس لا يهتمون بالميزات التقنية ، لذلك يبدو أن هذا ليس Web3 تمامًا ، ولكن أيضًا Web3 جدًا.
الغرض من تقنية Rollup هو زيادة الاستفادة من قيمة blockchain ، ولكن غالبًا بسبب الحاجة الملحة لأن تصبح "مفهومًا مبتكرًا" في السوق ، هناك ظاهرة "التراجع" والعودة إلى المركزية. هذه هي مشكلة السوق الحالية.
من السهل رؤية قيمة blockchain ، فمن منا لا يرغب في امتلاك جهاز كمبيوتر أبدي؟ لكن المشكلة الأساسية هي أنه عندما تكون السعة التشغيلية لهذا الكمبيوتر أقل بكثير من أي خادم من حولنا وتتطلب الكثير من الاستثمار في الموارد ، حتى لو كانت قيمة الاستخدام أقل بكثير من تكلفة المدخلات لدينا ، "كمنتج عام" ، لا يزال هل يمكن للجميع المشاركة؟
عندما يكون لدينا بالفعل منتجات من العديد من البلدان والمجتمعات وحتى الأفراد ، في ظل أي ظروف نحن على استعداد لتجاهل التكلفة العالية للاستخدام ومتابعة نتيجة "الإنترنت دائمًا ، صحيح دائمًا"؟ أعتقد أن هذا شيء تحتاج صناعة blockchain إلى التفكير فيه اليوم. يمكن لتقنية الالتفاف تحسين هذه المشكلة تقنيًا ، ولكن لا يزال هناك عدد كبير من المشكلات التي يجب تركها للسوق المتهور لحلها.