ينتقل هوس النقش إلى الطبقة 2 ، فلماذا يمكن ل zkSync اجتياز اختبار الإجهاد للتداول المرتفع؟

** تأليف: هاوتيان **

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

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

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

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

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

ومع ذلك ، هذا لا يعني أن المعاملة فشلت بالفعل ، ولكن فقط بسبب وجود “عدم توافق” بين وقت استجابة RPC الخاص ب Metamask ومنطق التعليقات وقائمة انتظار Sequencer الخاصة ب 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 ، بتغريد تقارير تحديث 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 لفرز الكتل ، ثم التخلص من سوء فهم “التجربة السيئة” ، يجب أن تفهم أن كل شيء يسير على ما يرام ، وعلينا أن نعطي layer2 مزيدا من الثقة.