ترقية كانكون قادمة: ما هي مستويات L2 التي تم تعديلها؟

المؤلف: Maggie@Foresight Ventures

1. الخلفية

في عام 2020، أصدرت Ethereum "خارطة طريق Ethereum Centered Rollup" "، بالإضافة إلى الصورة النهائية لـ Ethereum الموصوفة في "Endgame" التي نشرها Vitalik في العام التالي، التي حددت الاتجاه العام لـ Ethereum: تحسين بناء الطبقة الأساسية لـ Ethereum، والتي تخدم التراكمي.

صممت Ethereum تقنية تقسيم Danksharding لتحسين إمكانية استخدام Ethereum كطبقة توفر البيانات. سيؤدي ذلك إلى تقليل رسوم معاملات L2 بشكل كبير، وزيادة TPS لـ Rollup، وتحقيق توسع كبير في Ethereum

حتى هذا العام،تم إطلاق ترقية Ethereum Cancun-Dencun أخيرًا في 13 مارس 2024، EIP4844 على وشك أن يصبح متصلاً بالإنترنت، ويمكن القول أن هذا الانقسام الكلي هو الخطوة الأولى لإيثريوم لتنفيذ Danksharding وهو جوهر خارطة طريق إيثريوم.

2. كيف ستستفيد ترقية Cancun من المستوى الثاني؟

يقدم EIP4844 نوعًا جديدًا من المعاملات يُسمى معاملة نقل البيانات الكبيرة الكبيرة. يمكن لكل معاملة تحمل كائنات كبيرة الحجم أن "تحمل" قائمة من الكائنات الثنائية الكبيرة. النقطة عبارة عن حزمة من البيانات يبلغ حجمها حوالي 125 كيلو بايت. يتم تخزين النقط لفترة زمنية قصيرة، 4096 فترة فقط، أي ما يزيد قليلاً عن 18 يومًا.

1. انخفضت رسوم معاملات اللغة الثانية بشكل ملحوظ. نظرًا لأن Blobs لا تتطلب تخزينًا دائمًا، فإن Blobs أكبر وأرخص من مساحة الكتلة. يمكن لـ Blobs تخزين بيانات أكثر بـ 10 مرات من Calldata بنفس استهلاك الغاز. يمكن لمجموعة التحديثات المتوافقة مع EIP4844 تخزين بيانات المعاملات في Blobs، مما يقلل رسوم المعاملات بمقدار كبير.

2. تمت مضاعفة TPS لـ L2. الهدف الحالي هو 3 نقاط لكل كتلة، مع الحد الأقصى المسموح به وهو 6 نقاط. يبلغ حجم الكتل 90 كيلو بايت فقط، ويبلغ حجم كل فقاعة حوالي 125 كيلو بايت. إن إدخال Blob يعادل توسيع مساحة الكتلة عدة مرات لتخزين بيانات التجميع، لذلك يمكن أيضًا مضاعفة TPS الخاص بـ Rollup. وذكر "حول زيادة حد كتلة الغاز" الذي كتبه توني وفيتاليك أنه من خلال زيادة حد كتلة الغاز وسعر بايتات Calldata غير الصفر، سيتم تحقيق حجم كتلة أصغر مع متغيرات أقل، بحيث يمكن إضافة المزيد في المستقبل.بلوب. كلما زاد عدد النقط، زادت مساحة التخزين.

بالنسبة للمستخدمين النهائيين، Ethereum   بعد تكيف L2 مع EIP4844، ستكون المعاملات أسرع وأكثر فعالية من حيث التكلفة منخفضة، التجربة أكثر سلاسة واستجابة. سيكون هناك تطبيقات Dapp أكثر تعقيدًا وأكبر حجمًا على لغات L2 هذه.

3. كيف يتكيف L2 مع EIP4844؟

كيف يتكيف L2 مع EIP4844؟ نحن بحاجة إلى مناقشة مجموعة التراكمي المتفائل ومجموعة ZK بشكل منفصل.

تتكيف مجموعة التحديثات المتفائلة مع EIP4844

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

يعد التراكمي المتفائل أسهل في التكيف مع EIP4844 من ZK التراكمي. أرسل جميع معاملات L2 إلى L1 من خلال معاملات Blob-carrying لإكمال عملية التكييف. بالإضافة إلى ذلك، يجب تعديل إثبات الاحتيال ليتكيف مع EIP4844. ويمكن تنفيذ هذا الجزء ببطء. بعد كل شيء، العديد من التقارير المتفائلة لم تطلق بعد أدلة على الاحتيال. لقد وضعت شهادة احتيال عبر الإنترنت، ولكن وجدت أنه لم يتم تقديم أي شهادة احتيال منذ أكثر من عامين.

إرسال معاملة L2: عند إرسال القائمة المجمعة، يتم استخدام المعاملة الحاملة للبيانات الثنائية الكبيرة لتخزين بيانات القيمة المجمعة في البيانات الثنائية الكبيرة. الحمولة النافعة للمعاملة الحاملة للكائنات الثنائية الكبيرة هي rlp([tx_payload_body, blobs, الالتزامات, البراهين])، حيث

tx_payload_body< /strong> - هي TransactionPayloadBody لمعاملة EIP-2718 الثنائية الكبيرة الحجم القياسية.

النقط  - قائمة النقط. يمكن أن تحتوي المعاملة على ما يصل إلى نقطتين.

الالتزامات - قائمة التزامات Blob's KZG.

الأدلة - Blob وقائمة الأدلة المقابلة لالتزامات KZG. سيتم التحقق من هذا الدليل بواسطة عقدة ETH.

ضبط إثبات الاحتيال:

أولاً، يحتاج المُثبِّت والمنافس إلى جولات متعددة من التفاعل للعثور على نقطة الخلاف.

ثم يتم تقديم نقطة النزاع إلى L1 للحكم عليها. للتكيف مع EIP4844، قد يكون من الضروري إثبات أن البيانات المعنية مخزنة على كائن Blob معين.

نظرًا لأنه سيتم حذف بيانات Blob بعد 18 يومًا تقريبًا، يجب أن تكون فترة التحدي قبل حذفها، وهو ما يتم استيفاءه من خلال عمليات التجميع المتفائلة الحالية. وبشكل عام فإن مدة التحدي لا تتجاوز 7 أيام.

تتكيف مجموعات ZK مع EIP4844

تم تمرير مجموعة ZK التراكمية يتم استخدام ZKP لإثبات صحة انتقال الحالة L2. يعد تكيف ZK التراكمي مع EIP4844 أكثر تعقيدًا من التراكمي المتفائل.



إرسال معاملة L2: هذه الخطوة من مجموعة الإظهار المتفائل مشابهة.

تقديم إثبات ZK: بالمقارنة مع ZK Rollup قبل التكيف، بالإضافة إلى إثبات ZKP لانتقال الحالة، يلزم إجراء عملية إثبات أخرى. وهذا يعني أنه تم إثبات أن التزام النقطة ومجموعة المعاملات متطابقان، وبالتالي ضمان صحة إدخال إثبات انتقال الحالة.

على سبيل المثال: يمكن لدائرة ZK لانتقال الحالة إنشاء دليل على عملية الحساب a + a = b. تم إنشاء ZKP عندما يكون (a=1,b=2) و(a=2,b=4) قانونيًا. لذلك، أحتاج أيضًا إلى تقديم دليل على أن المدخلات التي قدمتها في ذلك الوقت كانت (a=1,b=2) بدلاً من (a=2,b=4).

لا يلزم القيام بذلك قبل التكيف مع EIP4844، لأنه يتم تخزين البيانات مباشرة في Calldata ويمكن قراءتها مباشرة، مما يضمن عدم ضياع المدخلات. معبئ. . بعد استخدام EIP4844، لا يمكن قراءة بيانات Blob مباشرة، ولا يمكن إثبات ذلك إلا من خلال دائرة جديدة.

من الأسهل تنفيذ آلية الإثبات هذه باستخدام مجموعة ZK الخاصة بـ STARK (مثل Starknet). يمثل هذا تحديًا لمجموعة ZK باستخدام SNARK. والسبب هو:المنحنى الإهليلجي المستخدم من قبل التزام النقطة لـ EIP4844 هو BLS12-381، في حين أن العقد المترجم مسبقًا لـ ETH يدعم فقط BN254. ونظرًا للمنحنيات المختلفة، فهو من الصعب علينا التحقق من إثبات إكمال التزام blob مباشرةً في العقد الذكي.

يحتاج ZkEVM/zkVM باستخدام SNARK إلى حل المشكلة المذكورة في النقطة 2 والتي مفادها أنه لا يمكن إنشاء دليل ZK بسبب عدم تطابق المنحنى.

في انتظار دعم Ethereum للعقود المجمعة مسبقًا BLS12-381. سيكون هذا طويلا.

استخدم طريقة إثبات أخرى للإثبات. لتصميم دوائر جديدة، يجب عليك استخدام المنحنى الإهليلجي BN254 المدعوم بالعقد المترجم مسبقًا. حاليًا، نرى Morph يتخذ هذا النهج. وهذا أيضًا يجعل Morph أول zkEVM يكمل تكيف EIP4844.

4. ما هي L2s التي تم تكييفها مع EIP4844؟

من السهل نسبيًا التكيف مع مجموعة التحديثات المتفائلة مع EIP4844.

ستطلق Arbitrum ترقية Arb OS20 في 14 مارس لتنفيذ تغييرات EIP لترقية Cancun(رابط المقالة) . ينتمي Arbitrum إلى المرحلة الأولى من مجموعة التحديثات. ويحتاج كل من تقديم المعاملة وإثبات الاحتيال إلى التكيف مع EIP4844، كما أن أمانه جيد نسبيًا.

أطلقت شركة Optimism ترقية Ecotone لإكمال التعديل في 14 مارس(رابط المقالة). التراكم المتفائل هو المرحلة 0. لا يوجد حاليًا أي دليل على الاحتيال. من الأسهل التكيف معه، لكن الأمان ليس عاليًا بدرجة كافية. بعد اكتمال عملية التكيف، ستستفيد جميع شبكات السلسلة الفائقة في النظام البيئي Op أيضًا من EIP-4844.

في ZK، تختلف صعوبة تكيف القيمة المجمعة باستخدام STRAK وSNARK.

من الأسهل تكييف EIP4844 مع مجموعة STARK، وStarknet هو أحد الممثلين.

نشرت Starknet مقالًا يفيد بأن كانكون ستنفذ تكيف EIP4844 بعد الترقية(رابط المقالة).

تمت ترقية zkSync من خلال Boojum للسماح لـ zkSync بإكمال الانتقال من إثبات SNARK إلى إثبات STARK. يعد هذا أيضًا تحضيرًا لترقية EIP4844. Boojun هو نظام إثبات يعتمد على STARK.

التكيف باستخدام مجموعة SNARK أمر معقد نسبيًا

من المتوقع إطلاق Polygon zkEVM مع ترقية Feijoa في مايو، للتكيف مع EIP-4844. (رابط المقالة)

نشرت Scroll مقالة العام الماضي تقدم فيها فكرة تكييف EIP4844 (رابط المقالة).

الشيء الأكثر إثارة للإعجاب هو Morph، وهو مجموعة ZK متفائلة وكان أول من أطلق خطة التكيف zkSNARK zkEVM لـ EIP4844 ،يمكن القول أنه أول من أكمل مجموعة zkSNARK zkEVM لـ EIP4844 (رابط المقالة). يجمع ZK Rollup المتفائل بين مزايا كلا النوعين من التراكمي. إنه يؤمن بشكل متفائل بنتائج التنفيذ المقدمة من Sequencer ويسمح لأولئك الذين يشككون في النتائج ببدء التحديات. فقط عند إصدار التحدي، سيقوم المُثبت بإنشاء ZKP لإثبات صحة نتائج التنفيذ. يتمتع بكفاءة تراكمية متفائلة وموثوقية ZK المثبتة لـ ZK.