تحت اختبار إجهاد النقش ، أكملت zkSync "تدريبا مفتوحا" ناجحا

المؤلف الأصلي: Haotian (X: @tmel0211)

ملاحظة المحرر: لا يزال مسار النقش ساخنا ، وقد غمرت سلسلة zkSync بعدد كبير من المعاملات في فترة زمنية قصيرة ، في “اختبار الإجهاد” هذا ، تعطل zkSync بسبب النقش ، أم تم اختباره بشكل مثالي؟ أوضح باحث التشفير Haotian (X: @tmel0211) الوهم وسوء الفهم ل “التجربة السيئة” ل zkSync من المنطق التقني ، وقامت Odaily Planet Daily بفرزها على النحو التالي:

إن النقش المحفور على سلسلة zkSync والتدفق قصير المدى للمعاملات المرتفعة هي بالفعل “اختبار إجهاد” لأداء السلسلة العامة للطبقة 2 ، ولكن النتيجة ليست “توقفا” ، بل على العكس ، هذا تدريب عام @zksync ، والنتيجة هي أن ذروة TPS واستقرار الغاز وما إلى ذلك قد تم اختبارها بشكل مثالي. **

للوهلة الأولى ، ألا يبدو الأمر غير بديهي بعض الشيء؟ بعد ذلك ، مع المنطق التقني ، دعني أوضح لك ذلك:

مبدأ عمل كتل تغليف zkSync هو ببساطة كما يلي: يقوم المستخدمون بإنشاء المعاملات في تسلسل الفرز الخاص ب zkSync Sequencer ، ثم يقوم Sequencer بتعبئتها في كتل وفقا لترتيب رسوم الغاز ، ثم يمرر الكتل إلى نظام Proof للتحقق منها ، وأخيرا يرسلها إلى الشبكة الرئيسية لإكمال تأكيد الحالة النهائية. **

** - هناك 2 النقاط الرئيسية هنا ، والتي من السهل خلق وهم “تجربة سيئة” :* *

1. يقوم المستخدمون بإنشاء روابط المعاملات: سيبدأ معظم المستخدمين المعاملات من خلال محافظ مثل Metamask ، ويرسلون المعاملات إلى zkSync من خلال المحافظ ، وستدخل المعاملات أولا إلى خادم الاتصال عن بعد RPC ، ثم يتلقى Sequencer هذه المعاملات ويدخل التسلسل في قائمة الانتظار. يمكن أن يكون وقت قائمة الانتظار هنا قصيرا مثل بضع ثوان أو بضع دقائق ، وإذا انتظرت لفترة طويلة ، فسيفترض MetaMask أن المعاملة قد فشلت ، ثم ستعرض الواجهة الأمامية رسالة تفيد بفشل المعاملة.

ومع ذلك ، هذا لا يعني أن المعاملة فشلت بالفعل ، ولكن فقط بسبب “عدم التوافق” بين وقت استجابة RPC الخاص ب Metamask ومنطق التغذية الراجعة ومنطق معاملات الحزمة في قائمة انتظار zkSync. ** هذا هو السبب في أن بعض المعاملات التي يبدو أنها فشلت في MetaMask تظهر النجاح مرة أخرى بعد الانتظار لفترة من الوقت.

إذا لم يمر المستخدم عبر خط أنابيب المحفظة واستخدم رمز الواجهة الخلفية مباشرة للاتصال ب RPC الخاص ب zkSync ، فلن تكون هناك مهلة استجابة وفشل فوري ، وستكون التجربة سلسة نسبيا. يعطي هذا ميزة لبعض “العلماء” الذين يمكنهم استخدام تعليمات التعليمات البرمجية الخلفية ، ولكنها في الأساس مشكلة في جانب تجربة المحفظة ولا علاقة لها بقوة معالجة سلسلة zkSync.

2. جلسة الطلب العادل لجهاز التسلسل: عندما يرسل المستخدم معاملة إلى قائمة انتظار RPC لفترة قصيرة ، سيتم تكديس كل معاملة من قيمة nonce البالغة 0 ، إذا كانت المعاملة السابقة لا تزال في حالة قائمة الانتظار ، فإن nonce هي 0 ، ثم يبدأ المستخدم معاملة جديدة ب nonce من 1 ، وسيقوم جهاز التسلسل الخاص ب zkSync بتعيين nonce لهذه المعاملات وفقا للوقت ، ثم فرزها بالترتيب.

ومع ذلك ، إذا أرسل المستخدم معاملة جديدة في نفس الوقت بعد رؤية أن المعاملة السابقة فشلت في القسم السابق من MetaMask ، فمن المحتمل ألا يتم إرسال بعض المعاملات المرسلة حديثا بنجاح إلى قائمة انتظار RPC بسبب مشكلة جانب المحفظة واستدعاء واجهة zkSync API. يعتقد المستخدمون أنه تم تقديم الكثير من المعاملات ، ولكن في الواقع لم يتلق zkSync سوى جزء منها ، وبمجرد استلامها ، سيقومون بفرزها.

بالنظر إلى الأمر بهذه الطريقة ، يرى المستخدمون أن MetaMask يبلغ عن فشل المعاملات ، وأن فعل إرسال المعاملات الجديدة باستمرار سيؤدي أيضا إلى عدد كبير من حالات فشل المعاملات ، لأنه لا يوجد إرسال إلى الواجهة الخلفية لسلسلة zkSync على الإطلاق ، لكنك تعتقد أنك أرسلته على الواجهة الأمامية. **

بشكل عام ، ستؤدي مشكلات منطق وقت استجابة RPC في محفظة MetaMask واندفاع المستخدمين لتراكب المعاملات على السلسلة إلى عدد كبير من “إخفاقات” المعاملات ، ومن الأسهل نسبيا تجنب مشكلات تجربة التحسين هذه إذا كنت واضحا بشأن سير عمل معالجة المعاملات الخلفية ل zkSync.

** - استنادا إلى العلم الشعبي أعلاه ، دعنا نوضح مشكلة “التوقف”: **

سلسلة zkSync ليست “معطلة” ، إنها مجرد مشكلة عرض في الواجهة الأمامية للمتصفح ، لأن المتصفح سيسحب أحدث البيانات من خلال واجهة RPC الخاصة ب zkSync ، ولكن سيكون هناك تأخير في استجابة الواجهة ، وسيؤدي عدد كبير من المعاملات الجديدة إلى إبطاء الاستجابة.

باختصار ، لا يمكن لسرعة مزامنة بيانات سحب المتصفح مواكبة الزيادة في المعاملات في قائمة الانتظار ، وهي مشكلة في الواجهة الأمامية للمتصفح ولا علاقة لها بتشغيل السلسلة. ** عادة ما يتم حل المشكلة عندما تتباطأ سرعة المعاملة بشكل مناسب ويمكن للمتصفح التقاط بيانات جديدة.

عندما لا يعمل المستعرض، يمكنك استخدام متصفحات أخرى تقوم بمزامنة معلومات بيانات كتلة zkSync للتحقق المتبادل، مثل:

** - ما هو “الأداء التشغيلي” للسلسلة الحقيقية؟

1. بعد اندلاع ما يسمى بشائعات انقطاع الخدمة ، قام الموظفون الرسميون في zkSync @anthonykrose بتغريد تحديثات TPS. في الواقع ، ارتفع zkSync TPS إلى ذروة 187.9 ، وفي ظل الظروف العادية ، يبلغ TPS حوالي 50-100 فقط ، مما يشير إلى وجود تدفق هائل للمعاملات الجديدة ، وقد قاوم zkSync الضغط بالفعل. هذا يوفر “اختبار إجهاد” كامل للآلاف ، إن لم يكن عشرات الآلاف ، من TPS في المستقبل.

2. تحدد الآلية الخاصة ل ZK-Rollup أنه كلما زاد حجم المعاملات التي تمت معالجتها ، كانت رسوم الغاز أرخص ، في الواقع ، فإن رسوم الغاز في zkSync أرخص بالفعل ، لأن تكلفة المعاملة مشتركة أيضا ، وفقا لبيانات growthepie ، ** في ال 24 ساعة الماضية ، انخفض متوسط غاز zkSync أيضا بنسبة 5.2٪ ، بمتوسط حوالي 0.19 دولار ، قد لا تكون هذه البيانات هي نفسها بالنسبة للجميع ، لكن بيانات تشغيل السلسلة المتكاملة أرخص بالفعل. ** هذا يثبت أن التجربة الأكثر سلاسة ل ZK-Rollup تتطلب زيادة كبيرة في مقياس المستخدم الحالي.

** - تأثير أحداث النقش على السلاسل العامة من الطبقة 2؟**

وفقا لبيانات الكثبان الرملية ، أضاف سك نقش Sync 5 ملايين معاملة في 14 ساعة ، وشارك 65,575 حاملا. كما ذكر أعلاه ، يدرك مسؤولو zkSync “اختبار الإجهاد” الذي بدأه المجتمع ويتخذون خطوات عاجلة لضمان تشغيل سلسلة zkSync بطريقة منظمة.

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

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

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

رابط المقال الأصلي