يتم فرز آلية تشغيل zkSync ، فهي لا "تعطل" بشكل متكرر

رأيت صديقًا يشكو من أنzkSync معطل دائمًا. في الواقع ، وصفه بـ "وقت التعطل" هو نوع من المبالغة. على وجه الدقة ، إنه "إنشاء كتلة غير مستقر".

بشكل أساسي ، الوقت النهائي الذي تم التحقق منه للمعاملة المقدمة من Sequencer غير مستقر ، لكن تصور المستخدم ليس واضحًا في النهاية التفاعلية ، لأن تصميم التحقق من zkSync به تأخير في التأكيد.

سيتم تخفيف عدم الاستقرار في مرحلة اللامركزية المستقبلية. لقد رسمت سير عمل لمناقشته معك.

قد يكون السبب وراء إدراك المستخدمين "لوقت التوقف عن العمل" هو مشكلة فشل المعاملة الناتجة عن التوافق بين بعض DApps والطبقة السفلية من السلسلة.

يستغرق الأمر حوالي 30 دقيقة - ساعة واحدة لملاحظة تغيير الحالة من الالتزام إلى التحقق من المتصفح الرسمي ، بينما لا يتأثر تطبيق DApp التفاعلي من جانب المستخدم بهذا.

تركز هذه المقالة على المنطق الأساسي لتكنولوجيا zkSync العلمية الشائعة ، وتوفر لك فهمًا واضحًا لـ zkSync.

كما هو موضح في سير العمل ، يتم تشغيل zkSync في الخطوات التالية:

  1. يرسل المستخدم حركات دفعية إلى جهاز التسلسل من خلال إعادة توجيه الترحيل ؛

  2. جهاز التسلسل مسؤول عن فرز المعاملات وتجميع الدفعات وتعبئتها في شجرة Merkle ؛

  3. ينشئ zkPorter شهادات zk-SNARK من شجرة Merkle ؛ يتم ترحيل شهادات zk-SNARK على التوالي إلى L2 Validators وسلسلة L1 الرئيسية لإنشاء Commit Hash ؛ يتحمل المدققون مسؤولية التحقق

  4. يتم تقديم صحة إثبات zk-SNARK إلى العقد الذكي L1 لإنشاء تجزئة تحقق ؛

  5. يتحقق عقد zkSync الذكي على L1 من مطابقة Commit Hash و Verify Hash ؛

  6. بعد المطابقة الناجحة ، يتم إنشاء معاملة تم التحقق منها ويتم تحميل المعاملة أخيرًا إلى السلسلة ؛

  7. إذا فشلت المطابقة ، فسيتم إبطال تجزئة الالتزام الأصلية ، وسيقوم جهاز التسلسل بإعادة إرسال الدُفعة ومتابعة العملية مرة أخرى.

يجب التأكيد هنا على أن zkSync تتبنى "التزام على مرحلتين (2PC)" ، وتحدد أخيرًا دفعة المعاملة القانونية من خلال التحقق من التجزئة في مرحلتي Commit Hash و Verify Hash.

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

سير عمل zkSync بشكل أساسي له أربعة أدوار: Relay ، Sequencer ، zkPorter ، و Validator. سيكون هناك العديد من "العوامل غير المستقرة" في العمل التنسيقي.

يمكن تلخيصها على أنها استقرار وظائف العقدة ، واستقرار تعاون العقدة ، وتعقيد الخوارزميات والبروتوكولات الأساسية. قد يتسبب أي خطأ في أي ارتباط في تأخير الحظر. تعتبر الأعطال الفنية الشائعة لـ Arbitrum Sequencer نموذجية ، وسيواجه zkSync المزيد من التحديات فقط.

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

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

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

باختصار ، إذا أوضحت عملية تشغيل zkSync بالكامل ، وفهمت بشكل أكبر التعقيد التقني للطبقة 2 والآلية "الخاصة" المصممة للأمان ، يمكنك تعزيز ثقتك في المسار الفني L2.

شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
  • أعجبني
  • تعليق
  • مشاركة
تعليق
0/400
لا توجد تعليقات
  • تثبيت
تداول العملات الرقمية في أي مكان وفي أي وقت
qrCode
امسح لتنزيل تطبيق Gate.io
المنتدى
بالعربية
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)