تلخيص؛ لم تُقرأ بعد

• =nil; هو zkRollup مقسم - مفهوم L2 جديد لتوسيع إثيريوم بشكل ديناميكي وآمن من خلال تنفيذ المعاملات المتوازية على مستوى البروتوكول عبر الأقسام.
• مجهز بـ zkSharding، =nil؛ يقدم التوسيع الأفقي دون التنازل عن فوائد طبقة التنفيذ الواحدة، وهي السيولة الموحدة والأمان الاقتصادي.
• =nil; توفر تطبيقات القدرة الكاملة على التكامل مع إثيريوم من خلال الوصول الشفاف والقابل للتحقق إلى بيانات إثيريوم.
• =nil; يقدم نوع zkEVM المترجم بـ zkLLVM من النوع 1.
• يتم ضمان تكوين الإثبات السريع من خلال منافسة السوق المفتوحة من خلال سوق الإثبات - سوق تكوين الإثبات غير المرخص.

مقدمة لـ zkSharding

اليوم، تتداول حلول الطبقة 2 تداول التوازن بين التوسعية وتجزئة الحالة. نقدم تصميم الطبقة 2 (L2)، =nil؛، الذي يدفع حدود توسعية إثيريوم دون التنازل عن فوائد بيئة التنفيذ الموحدة. تجمع الحلول بين آلية تجزئة ديناميكية مع وصول قابل للتحقق إلى بيانات إثيريوم، مؤمنة بتقنيات المعرفة الصفرية. العناصر الرئيسية تشمل:

• zkRollup مع مشاركة: النواة الخاصة ب =nil; هي بروتوكول مشاركة قابل للإثبات، مما يتيح التوسع الأفقي دون المساس بالأمان أو الكفاءة. تتناول هذه الطريقة بعض القيود الحالية للتوسيع الرأسي (L3، L4، إلخ)، وتحديدا تجزئة البيانات والسيولة.
• الوصول المباشر إلى بيانات إثيريوم: القدرة على استدعاء بيانات إثيريوم الأصلية من تطبيقات L2 تسمح لنا باستخدام التطبيقات المنشورة بالفعل. الوصول المباشر إلى بيانات L1 من L2 يضمن بيئة موحدة وسلسة أكثر.

من خلال zkSharding =nil؛ تستفيد من مزايا التصميمين الأحادي والمعياري بما في ذلك:

• قابلية التوسع

  • لا توجد قيود على التوسعية حيث أن التنفيذ متوازي. يُقدر مُعدل الإنتاجية بحوالي 60 ألف تحويل ERC-20 في الثانية مع نحو 400 عقدة.
  • توفير جيل البرهان التنافسي عبر الProof Market يوفر أسرع L1-finality وأرخص تكاليف إنشاء البرهان.

• بيئة تنفيذ موحدة

  • تضمن البيئة الموحدة للتنفيذ عدم تجزؤ الأمان /السيولة حيث أن كل شارد هو جزء من العنقود بأكمله.
  • تقليل حاجة ترحيل السيولة من إثيريوم ك =nil؛ يوفر وصولًا شفافًا إلى بياناته للتطبيقات من خلال إجبار كل مدقق على الاحتفاظ بحالة إثيريوم الكاملة كجزء من النشر مما يسمح للتطبيقات بالوصول إلى البيانات مباشرة من zkEVM لـ =nil؛.

• أمان

  • الانتقالات الحالية مؤمنة بواسطة zkEVM المترجمة عبر zkLLVM. يوفر الأمان القابل للتدقيق (على سبيل المثال، أمان القيود) حيث يمكن تفتيش الشيفرة بسهولة نظرًا لأن دوائر zkEVM تتم ترجمتها من تنفيذ EVM المستخدم في الإنتاج بلغة عالية المستوى وليست مكتوبة يدويًا.
  • لامركزي منذ اليوم الأول بفضل توليد البرهان اللامركزي الممكّن من =nil؛ سوق البرهان.

• وظائف

  • نوع 1 zkEVM, تم ترجمتها بالكامل إلى بيانات البايت EVM مكافئة باستخدام zkLLVM.
  • بيئة مصممة للتطبيقات التي تتطلب الكثير من الوقت والذاكرة وتعقيد الخوارزميات من خلال زيادة توحيد الشارد الفردي وإدخال توجيه التطبيقات الفرعية المفروض لتقليل التأخير. الأمثلة تشمل التبادلات غير المركزية، أسواق الإثبات، المتسلسلين/البنائين غير المركزيين، تطبيقات الحالة المشتركة (العوالم الذاتية وما إلى ذلك).

توسيع قابل للتكوين ديناميكي

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

الأجزاء الثانوية تعمل كـ "العمال", تنفذ معاملات المستخدم. تحافظ هذه الأجزاء على سيولة موحدة وبيانات من خلال بروتوكول رسائل بين الأجزاء، مما يقضي على أي تشتت بينها.

كل قطاع يتم رقابته بواسطة لجنة من المدققين. هناك دورة دورية لهؤلاء المدققين عبر القطاعات. بالإضافة إلى ذلك، يتم التحقق من تحديثات حالة القطاع إلى القطاع الرئيسي باستخدام zkEVM.

لتوضيح تدفق المعاملات من بدء المستخدم إلى تأكيد على إثيريوم، ننظر إلى الخطوات التالية:

• المستخدم يوقع على عملية (tx) ويبعثها إلى الشبكة.
• المحققون في قطاع S، حيث يقع محفظة المستخدم، يضعون tx في حوض الذاكرة.
• ثم يقوم هؤلاء المحققون بإنشاء كتلة جديدة B(1/S)
• يتم تسجيل تجزئة B(1/S) على الشارد الرئيسي داخل الكتلة B(1/M)
• يتم إنتاج دليل انتقال الحالة لـ B(1/S) وتحققه الشريحة الرئيسية في الكتلة B(2/M)
• يتم إرسال دليل على انتقال الحالة لـ B(2/M) إلى إثيريوم للتحقق ويرتبط بالبيانات الضرورية لضمان توفر البيانات.
• بمجرد أن يكتمل هذا العملية، يحقق tx التأكيد عن طريق إثيريوم.

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

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

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

zkEVM عبر zkLLVM: النوع-1 آمنة، قابلة للتدقيق وفعالة zkEVM

=nil;s zkEVM هو zkEVM من النوع 1 المترجم باستخدام zkLLVM. لفهم الفروقات بين zkEVMs التقليدية و zkEVM لـ =nil;، نحتاج إلى مناقشة القيود المرتبطة بعملية تعريف الدوائر التي تكمن وراء zkEVMs. دائرة zkEVM هي جزء حرج، المسؤول عن ضمان أن دليل تحويل الحالة يعتبر صحيحًا، وعادة ما يتم تعريفه باستخدام بعض zkDSL المخصص أو ببساطة مكتبة. يثير هذا الطريقة في تعريف الدائرة مسائل تتعلق ب:

• الأمان: قضايابسبب حجم الدائرة والنسخ اليدوي لمنطق EVM.
• قابلية التدقيق: محدودةقابلية التدقيقوقابلية التفتيشنظرًا لتعقيد وعدم وضوح zkDSLs المستخدمة.
• قابلية الترقية: تعقيدات الصيانة والترقية بسبب متطلبات تعريف القيود اليدوية. في حال حدوث أي تغيير في EVM - سيتعين إعادة إنجاز الغالبية العظمى من دوائر zkEVM وإعادة فحصها من الصفر.
• توافق: تعقيد تنفيذ الدائرة zkEVM المتوافقة بالبايت الفعلي (المعروفة أيضًا باسم النوع 1) غالبًا ما يؤدي إلى قيود على التطبيقات بسبب الاختلافات في سلوك zkEVM وسلوك EVM الفعلي.

=nil؛ يقوم zkEVM بحل جميع هذه التحديات بفعالية من خلال كونه:

• يجب أن يتم إنشاء دائرة آلية من نفس الكود عالي المستوى المستخدم في عقد تشغيل العقد الفعلي لإثيريوم لضمان عدم وجود فروقات في الخوارزميات.
• يجب تمثيل الدائرة في لغة برمجة عالية المستوى (مثل C++ أو Rust) التي يجب أن تكتب بطريقة تجعلها قابلة للقراءة بسهولة من قبل المطور العادي.
• قابل للترقية: يجب تحديد دائرة الطريقة بحيث يمكن ترجمة/تجميع أي تغيير داخل EVM بسهولة إلى دائرة zkEVM تثبت/تحدد بالضبط نفس السلوك. لا ينبغي أن ينشأ أي ضرورة لإعادة تجميع كامل أو إعادة فحص من مثل هذه الترقية.
• التوافق بين بايت كود (المعروف أيضًا باسم النوع 1): تجميع الدوائر من لغات عالية المستوى يجلب توافقًا كاملاً مع بايت كود وسلوك EVM مما يقلل بشكل drastique من الوقت اللازم للتسويق لتطبيقات EVM والوقت/الجهود اللازمة لتحقيق مثل هذا التوافق.

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

علاوة على ذلك، لأن =nil؛ تم تجميع zkEVM عبر zkLLVM، فإنه أكثر مرونة بشكل طبيعي (وبالتالي، مستقبل برهنة) من الدوائر المحددة يدويًا حيث يمكن تعديله بسهولة وإنشاء الدائرة تكون تلقائية. كما أنها أكثر قابلية للتدقيق، مما يعني أن أمانها لا يأتي على حساب تضمين أحدث EIPs المضافة إلى Ethereum.

zkRollup مع أمان Ethereum وتوافر البيانات

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

• يستخدم الشارد الرئيسي إثيريوم كـDA.
• الشرائح الثانوية لديها الخيار لاستخدام إثيريوم أو عدم الاختيار لعدم وجود DA مميز.

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

بالإضافة إلى ذلك، يمكن توسيع هذا الإطار ليشمل أنواع أخرى من DA.

الوصول الشفاف إلى بيانات إثيريوم

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

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

ماذا بعد:

=nil؛ و zkSharding هما تجسيد للمنتجات التي قامت =nil؛ بتطويرها على مدى السنوات الأربع الماضية. هدفها أن تكون أول حلاً composable وقابلاً للتطوير والعالمي لـ Ethereum L2 zkRollup. نحن متحمسون لمشاركة المزيد من تفاصيل التنفيذ خلال الأشهر القليلة القادمة. تأكد من متابعة حسابنا على تويتر للبقاء على اطلاع على تقدمنا!

بالنسبة لأولئك الذين لديهم فهم فني، لقد قمنا بتطويرمقدمة منفصلة شاملةالذي يغوص في تفاصيل =nil؛ و zkSharding. هذا المبادئ الأساسية هو بوابتك لفهم تفاصيل هذا النهج، مجهزة بجميع التفاصيل التقنية والتمهيدات التي تحتاج إليها.

انغمس الآن في دليلنا التقني وانضم إلى المحادثة علىDiscordوتيليجرام. دعونا نستكشف سويًا الإمكانيات اللامحدودة لـ zkSharding!

إخلاء المسؤولية:

1. هذا المقال مأخوذ من [nil.foundation]. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [nil.foundation]. إذا كانت هناك اعتراضات على هذا النشر، يرجى التواصل مع بوابة تعلمالفريق، وسوف يتولى التعامل معها بسرعة.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك للكاتب ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالات إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو نسخ المقالات المترجمة ممنوع.