أكبر مساهم في مقاومة ضغط النقوش؟حول تحسين zkSync من خلال ترقية Boojum

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

في الآونة الأخيرة ، أكملت @zksync ترقية Boojum ، وعلى هذه الفرضية صمدت zkSync أمام اختبار الإجهاد لعملية نقش SYNC. ومع ذلك ، فإن Boojum مقومة بأقل من قيمتها من قبل السوق.

ما هي تحسينات الأداء التي يجلبها Boojum؟ هل يمكن حل مشكلة الاستقرار المالي اللامركزي التي تم انتقادها؟ بعد ذلك ، دعنا نتحدث عن فهمي:

1. ستسمح ترقية Boojum ، المفهومة ببساطة ، ل zkSync بإكمال الانتقال من SNARK إلى دليل STARK. سير العمل تقريبا كما يلي:

عندما يتم تغليف دفعة ، يتم تقسيم هذه المعاملات إلى دوائر محددة متعددة ، والتي تتم معالجتها بعد ذلك بالتوازي وبسرعة عالية لإنشاء عدد كبير من STARKs ، والتي يتم تجميعها أخيرا في دليل STARK. أخيرا ، يتم تغليف دليل STARK في دليل SNARK وتقديمه إلى Mainnet للتحقق منه.

يضمن هذا المزيج من STARKs و SNARKs المعالجة الفعالة لكميات كبيرة من المعاملات ، مع إسقاط حجم البيانات المقدمة إلى Mainnet (SNARKs أبسط) وأكثر توافقا مع Mainnet.

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

2. وفقا لتغريدة @0xtaetaehoho ، كان متوسط حجم البيانات لكل معاملة 211 بايت قبل تحديث Boojum ، ويمكن تخفيضه إلى حوالي 68 بايت بعد الترقية ، وسيؤدي تحسين تقنية الضغط بشكل مباشر إلى زيادة حجم المعاملات لكل دفعة في الطبقة 2 بشكل كبير ، مما سيزيد بشكل كبير من TPS (حوالي 450) ، وستنخفض تكلفة الغاز لمعاملة واحدة (حوالي 65٪).

ليس من الصعب فهم المبدأ ، فالطبقة 2 تقدم دليلا على بيانات الحالة إلى بيانات استدعاء الشبكة الرئيسية ، نظرا لبيانات التخزين المحدودة على الشبكة الرئيسية ، تحدد قدرات المعالجة المتوازية STARK للطبقة 2 وتقنية معالجة ضغط SNARK حجم المعاملة ومستوى الغاز الذي يمكن معالجته بواسطة دفعة واحدة ؛

3. في السابق ، واجهت ZK-Rollup مشاكل عدم الاستقرار في معالجة معاملات التمويل اللامركزي منخفضة التردد ، ولم يكن اتجاهها الأصلي يفضي إلى استقرار التمويل اللامركزي. على سبيل المثال، يتطلب السعر المتغير للتمويل اللامركزي موجزات أسعار Oracle متعددة، وإذا لم يتم تجميع المعاملتين في نفس الحالة، فسيزداد تآكل المعاملة الناتجة.

الآن زاد حجم المعاملات لدفعة واحدة في الطبقة 2 بشكل كبير ، ويمكن استيعاب المزيد من تحديثات حالة بيانات Oracle داخل الكتلة. كما سيتم حل قضايا الاستقرار المالي اللامركزي بشكل فعال.

كما ذكر مسؤول zkSync @anthonykrose ، بغض النظر عن عدد تحديثات Oracle Machine المضمنة في الكتلة ، يمكن معالجة حالة الكتلة بأكملها وتسجيلها ككل ، وتحتاج فقط إلى دفع تكلفة كتابة حالة واحدة. هذا مفيد للرسوم المنخفضة والكفاءة العالية والاستقرار لتطبيقات التمويل اللامركزي على سلسلة ZK-Rollup.

من المنطقي أن تعتبر ترقية Boojum علامة فارقة ل zkSync.

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

بعد ترقية كانكون ، كان من المتوقع أن يؤدي حجم كتلة EthereumMainnet blob إلى خفض تكلفة معاملات دفعات layer2 ، والآن أدى التحسين الفني لنظام ZK نفسه إلى جلب مجموعة سلسلة ZK ومجموعة OP إلى نفس المستوى.

النقطة المهمة هي أن ZK-Rollup أكثر “نشاطا” من OP-Rollup. تم إثبات مزايا تقنية ZK-Rollup ، التي قيل دائما ، بشكل كامل بعد ترقية Boojum.

المرجع: لتسريع أجهزة ZK ، وتحسين قوة الحوسبة ، وما إلى ذلك ، يرجى الرجوع إلى التقارير البحثية التالية: