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

المؤلف: Maggie@Foresight Ventures

TL;DR:

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

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

• المجموعات المتفائلة أسهل في التكيف مع EIP4844، في حين أن المجموعات المجمعة ZK أكثر تعقيدًا في التكيف. لا يوجد لدى Ethereum عقد مُجمَّع مسبقًا لدعم المنحنيات الإهليلجية BLS12-381، مما يجعل بعض عمليات التحقق من ZKP صعبة ويعيق تقدم مجموعات ZK التي تتكيف مع EIP4844.

• يمكن حل مشكلة المنحنيات الإهليلجية بطريقتين، 1. انتظر استجابة Ethereum إلى BLS12- 381 منحنى إهليلجي للتجميع المسبق؛ 2. استخدم طريقة إثبات أخرى لتحقيق نفس الغرض، استخدم BN254 المدعوم بالتجميع المسبق لـ Ethereum.

• في الوقت الحالي،تتكيف كل من Arbitrum وOptimistic وStarknet وzkSync وScroll وPolygon zkEVM وL2 Morph الجديد مع EIP4844. من بينها، صرحت Arbitrum وOptimistic وStarknet أنهم سينفذون تكييف EIP4844 بعد ترقية Cancun. أخذ Morph زمام المبادرة في إطلاق حل التكيف zkSNARK zkEVM المبتكر، والذي سيكون أول zkSNARK zkEVM يتم تكييفه مع EIP4844

1. الخلفية

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

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

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

لمزيد من المعلومات حول ما هي طبقة DA، والمبادئ الفنية لـ Danksharding، ومحتوى EIP4844، يرجى الرجوع إلى المقالة الفنية التي كتبتها العام الماضي: DA (توفر البيانات) الصيف قادم؟ https://foresightnews.pro/article/detail/33575

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

يقدم 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. ويمكن تنفيذ هذا الجزء ببطء. بعد كل شيء، العديد من التقارير المتفائلة لم تطلق بعد أدلة على الاحتيال. لقد وضعت شهادة احتيال عبر الإنترنت، ولكن وجدت أنه لم يتم تقديم أي شهادة احتيال منذ أكثر من عامين.

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

• tx_payload_body - هو TransactionPayloadBody لمعاملة EIP-2718 الثنائية الكبيرة الحجم القياسية.

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

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

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

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

• أولاً، يحتاج المثل والمنافس إلى جولات متعددة من التفاعل للعثور على نقطة النزاع .

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

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

تتكيف ZK Rollups مع EIP4844

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



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

2. تقديم إثبات 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 مباشرةً في العقد الذكي.

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

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

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

للحصول على حل Morph المتكامل EIP-4844 zkEVM، يرجى الاطلاع على: https://medium.com /@morphlayer2/morphs-solution-to-eip-4844-zkevm-integration-7f469910478f

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

في مجموعة Optimistic، أعربت Optimism وArbitrum عن التزامهما باعتماد EIP-4844 ويعملان بشكل وثيق مع مجتمعاتهما لاختبار التحديثات الضرورية ونشرها. Arbitrum عبارة عن مجموعة تراكمية من المرحلة الأولى وتتمتع بأمان جيد نسبيًا. إنه ينطوي على الحاجة إلى تكييف دليل الاحتيال مع EIP4844. مجموعة التحديثات المتفائلة هي مرحلة 0. لا يوجد حاليًا أي دليل على الاحتيال. من الأسهل التكيف، لكن الأمان ليس عاليًا بدرجة كافية.

في ZK التراكمي، تختلف صعوبة تكيف التراكمي باستخدام STRAK وSNARK. من الأسهل تكييف EIP4844 مع مجموعة STARK، وStarknet هو أحد الممثلين. نشرت Starknet مقالًا يفيد بأن كانكون ستقوم بتنفيذ تعديل EIP4844 بعد الترقية (رابط المقالة). من خلال مجموعة SNARK، تستكشف zkSync أيضًا كيفية الاستفادة من المعاملات ذات البيانات الكبيرة لتقليل التكاليف وتحسين الأداء. نشرت Scroll مقالاً العام الماضي تقدم فيه فكرة التكيف مع EIP4844 (رابط المقالة)

الشيء الأكثر إثارة للإعجاب هو Morph، وهو عبارة عن ZK Rollup المتفائل وكان أول من أطلق حل zkEVM لتكييف EIP4844 يمكن القول أنه أول مجموعة تجميعية لـ zkEVM تكمل EIP4844.

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

<الشكل>