سيتم إطلاق ترقية كانكون في 13 مارس 2024، وسيكون EIP4844 متاحًا عبر الإنترنت قريبًا. ** Danksharding هو جوهر خارطة طريق Ethereum، وهذه الترقية هي الخطوة الأولى لتنفيذ Danksharding **.
بعد تكيف Ethereum L2 مع EIP4844، انخفضت رسوم المعاملات بشكل ملحوظ، وتضاعف TPS الخاص بـ L2. ** سيشعر المستخدمون أن المعاملات أسرع وأرخص وأكثر سلاسة وأكثر استجابة. سيكون هناك تطبيقات Dapp أكثر تعقيدًا وأكبر على L2s هذه. **
تعد عمليات التجميع المتفائلة أسهل في التكيف مع EIP4844، في حين أن مجموعات ZK أكثر تعقيدًا في التكيف **. لا يوجد لدى Ethereum عقد مُجمَّع مسبقًا لدعم المنحنيات الإهليلجية BLS12-381، مما يجعل بعض عمليات التحقق من ZKP صعبة ويعيق تقدم مجموعات ZK التي تتكيف مع EIP4844. **
يمكن حل مشكلة المنحنيات الإهليلجية بطريقتين، 1. انتظر Ethereum للترجمة المسبقة للمنحنيات الإهليلجية BLS12-381؛ 2. استخدم طريقة إثبات أخرى لتحقيق نفس الغرض، استخدم BN254 المدعوم من التجميع المسبق للإيثريوم.
حاليًا، Arbitrum، وOptimistic، وStarknet، وzkSync، وScroll، وPolygon zkEVM، وL2 Morph الجديد كلها تتكيف مع EIP4844. من بينها، صرحت Arbitrum وOptimistic وStarknet أنهم سينفذون تكييف EIP4844 بعد ترقية كانكون. أخذ Morph زمام المبادرة في إطلاق حل التكيف zkSNARK zkEVM المبتكر، والذي سيكون أول zkSNARK zkEVM يتكيف مع EIP4844
1. الخلفية
في عام 2020، أصدرت Ethereum "خريطة طريق Ethereum المتمحورة حول مجموعة البيانات"، والصورة النهائية لـ Ethereum الموضحة في "Endgame" التي نشرها Vitalik في العام التالي، ** حددت الصورة الكبيرة لـ Ethereum. من الطبقة الأساسية من Ethereum لخدمة التراكمي. **
صممت Ethereum تقنية تقسيم Danksharding لتحسين قابلية استخدام Ethereum كطبقة توفر البيانات. سيؤدي ذلك إلى تقليل رسوم معاملات L2 بشكل كبير، وزيادة TPS الخاصة بـ Rollup، وتحقيق توسع كبير في Ethereum.
حتى هذا العام، تم إطلاق ترقية Ethereum Cancun-Dencun أخيرًا في 13 مارس 2024، وكان EIP4844 على وشك الاتصال بالإنترنت، ويمكن القول أن هذا الانقسام الصلب هو الخطوة الأولى في تنفيذ Ethereum لـ Danksharding، وهو جوهر خارطة الطريق. **
فيما يتعلق بما هي طبقة DA، والمبادئ الفنية لـ Danksharding، ومحتوى EIP4844، يرجى الرجوع إلى مقال فني كتبته العام الماضي: DA (توفر البيانات) الصيف قادم؟
**2. كيف ستستفيد ترقية كانكون من المستوى الثاني؟ **
يقدم EIP4844 نوعًا جديدًا من المعاملات يُسمى المعاملات ذات البيانات الكبيرة الكبيرة**. ** يمكن لكل معاملة تحمل النقطة أن "تحمل" قائمة من النقاط. النقطة عبارة عن حزمة من البيانات يبلغ حجمها حوالي 125 كيلو بايت. يتم تخزين النقط لفترة زمنية قصيرة، 4096 فترة فقط، أي ما يزيد قليلاً عن 18 يومًا.
انخفضت رسوم معاملات L2 بشكل ملحوظ. نظرًا لأن Blobs لا تتطلب تخزينًا دائمًا، فإن Blobs أكبر وأرخص من مساحة الكتلة. يمكن لـ Blob تخزين بيانات أكثر بـ 10 مرات من Calldata بنفس استهلاك الغاز. يمكن لمجموعة التحديثات التي تم تكييفها مع EIP4844 تخزين بيانات المعاملات في Blobs، مما يقلل رسوم المعاملات بمقدار كبير.
تم مضاعفة TPS لـ L2. الهدف الحالي هو 3 نقاط لكل كتلة، مع الحد الأقصى المسموح به وهو 6 نقاط. يبلغ حجم الكتل 90 كيلو بايت فقط، ويبلغ حجم كل فقاعة حوالي 125 كيلو بايت. إن إدخال Blob يعادل توسيع مساحة الكتلة عدة مرات لتخزين بيانات التجميع، لذلك يمكن أيضًا مضاعفة TPS الخاص بـ Rollup. وذكر "حول زيادة حد كتلة الغاز" الذي كتبه توني وفيتاليك أنه من خلال زيادة حد كتلة الغاز وسعر بايتات Calldata غير الصفرية، سيتم تحقيق حجم كتلة أصغر مع متغيرات أقل، بحيث يمكن إضافة المزيد في المستقبل.بلوب. كلما زاد عدد النقط، زادت مساحة التخزين.
بالنسبة للمستخدمين النهائيين، بعد تكييف **EthereumL2 مع EIP4844، ستكون سرعة المعاملة أسرع، وستكون التكلفة أقل، وستكون التجربة أكثر سلاسة، وستكون الاستجابة أكثر استجابة. سيكون هناك تطبيقات Dapp أكثر تعقيدًا وأكبر على L2s هذه. **
3. كيف يتكيف L2 مع EIP4844؟
كيف يتكيف L2 مع EIP4844؟ نحن بحاجة لمناقشة مجموعة التراكمي المتفائل وZK التراكمية بشكل منفصل.
المجموعات المتفائلة تتكيف مع EIP4844
تستخدم مجموعة التحديثات المتفائلة دليلاً على الاحتيال لضمان صحة تنفيذ مجموعة التحديثات. أي أن العقدة تختار أولاً الاعتقاد بأن انتقال الحالة صحيح، وما لم يبدأ شخص ما شهادة احتيال خلال فترة زمنية محددة لإثبات أن انتقال الحالة المقدم مسبقًا غير قانوني، فسيتم إلغاء انتقال الحالة.
تعد مجموعة التحديثات المتفائلة أسهل في التكيف مع EIP4844 مقارنة بمجموعة ZK. أرسل جميع معاملات L2 إلى L1 من خلال معاملات Blob-carrying لإكمال عملية التكييف. بالإضافة إلى ذلك، يجب تعديل إثبات الاحتيال ليتكيف مع EIP4844. ويمكن تنفيذ هذا الجزء ببطء. بعد كل شيء، العديد من التقارير المتفائلة لم تطلق بعد أدلة على الاحتيال. لقد وضعت شهادة احتيال عبر الإنترنت، ولكن وجدت أنه لم يتم تقديم أي شهادة احتيال منذ أكثر من عامين.
إرسال معاملة L2: عند إرسال البيانات المجمعة، يتم استخدام المعاملة الحاملة للبيانات الثنائية الكبيرة لتخزين بيانات البيانات المجمعة في البيانات الثنائية الكبيرة. الحمولة النافعة للمعاملة التي تحمل Blob هي rlp([tx_payload_body, blobs, engagements, prophes])، حيث
tx_payload_body- هو TransactionPayloadBody لمعاملة EIP-2718 blob القياسية.
النقط - قائمة النقط. يمكن أن تحتوي المعاملة على ما يصل إلى نقطتين.
الالتزامات - قائمة التزامات KZG للنقطة.
البراهين- فقاعة كبيرة وقائمة من البراهين المقابلة لالتزام KZG. سيتم التحقق من هذا الدليل بواسطة عقدة ETH.
تعديل إثبات الاحتيال:
أولاً، يحتاج المُثبت والمنافس إلى جولات متعددة من التفاعل للعثور على نقطة الخلاف.
ثم أرسل النقطة المتنازع عليها إلى L1 للحكم عليها. للتكيف مع EIP4844، قد يكون من الضروري إثبات أن البيانات المعنية مخزنة على كائن Blob معين.
بما أنه سيتم حذف بيانات الكائن الثنائي الكبير بعد 18 يومًا تقريبًا، يجب أن تكون فترة التحدي قبل حذفها، وهو ما يتم استيفاءه من خلال عمليات التجميع المتفائلة الحالية. بشكل عام مدة التحدي لا تتجاوز 7 أيام.
تتكيف ZK Rollups مع 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.
حل Morph's EIP-4844 zkEVM المتكامل، يرجى الاطلاع على:
**4. ما هي لغات L2 التي تم تكييفها مع 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 Rollup يكمل EIP4844. **
تجمع مجموعة ZK المتفائل بين مزايا كلا النوعين من مجموعة التحديثات. إنه يؤمن بشكل متفائل بنتائج التنفيذ المقدمة من Sequencer ويسمح لأولئك الذين لديهم شكوك حول النتائج ببدء التحديات. فقط عند إصدار التحدي، سيقوم المُثبت بإنشاء ZKP لإثبات صحة نتائج التنفيذ. **يتمتع بكفاءة تراكمية متفائلة وموثوقية ZK المثبتة لـ ZK. **
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
ترقية كانكون قادمة، ما هي التعديلات التي قامت بها لغات L2 السائدة؟
ل;د:
1. الخلفية
في عام 2020، أصدرت Ethereum "خريطة طريق Ethereum المتمحورة حول مجموعة البيانات"، والصورة النهائية لـ Ethereum الموضحة في "Endgame" التي نشرها Vitalik في العام التالي، ** حددت الصورة الكبيرة لـ Ethereum. من الطبقة الأساسية من Ethereum لخدمة التراكمي. **
صممت Ethereum تقنية تقسيم Danksharding لتحسين قابلية استخدام Ethereum كطبقة توفر البيانات. سيؤدي ذلك إلى تقليل رسوم معاملات L2 بشكل كبير، وزيادة TPS الخاصة بـ Rollup، وتحقيق توسع كبير في Ethereum.
حتى هذا العام، تم إطلاق ترقية Ethereum Cancun-Dencun أخيرًا في 13 مارس 2024، وكان EIP4844 على وشك الاتصال بالإنترنت، ويمكن القول أن هذا الانقسام الصلب هو الخطوة الأولى في تنفيذ Ethereum لـ Danksharding، وهو جوهر خارطة الطريق. **
**2. كيف ستستفيد ترقية كانكون من المستوى الثاني؟ **
يقدم EIP4844 نوعًا جديدًا من المعاملات يُسمى المعاملات ذات البيانات الكبيرة الكبيرة**. ** يمكن لكل معاملة تحمل النقطة أن "تحمل" قائمة من النقاط. النقطة عبارة عن حزمة من البيانات يبلغ حجمها حوالي 125 كيلو بايت. يتم تخزين النقط لفترة زمنية قصيرة، 4096 فترة فقط، أي ما يزيد قليلاً عن 18 يومًا.
بالنسبة للمستخدمين النهائيين، بعد تكييف **EthereumL2 مع EIP4844، ستكون سرعة المعاملة أسرع، وستكون التكلفة أقل، وستكون التجربة أكثر سلاسة، وستكون الاستجابة أكثر استجابة. سيكون هناك تطبيقات Dapp أكثر تعقيدًا وأكبر على L2s هذه. **
3. كيف يتكيف L2 مع EIP4844؟
كيف يتكيف L2 مع EIP4844؟ نحن بحاجة لمناقشة مجموعة التراكمي المتفائل وZK التراكمية بشكل منفصل.
المجموعات المتفائلة تتكيف مع EIP4844
تستخدم مجموعة التحديثات المتفائلة دليلاً على الاحتيال لضمان صحة تنفيذ مجموعة التحديثات. أي أن العقدة تختار أولاً الاعتقاد بأن انتقال الحالة صحيح، وما لم يبدأ شخص ما شهادة احتيال خلال فترة زمنية محددة لإثبات أن انتقال الحالة المقدم مسبقًا غير قانوني، فسيتم إلغاء انتقال الحالة.
تعد مجموعة التحديثات المتفائلة أسهل في التكيف مع EIP4844 مقارنة بمجموعة ZK. أرسل جميع معاملات L2 إلى L1 من خلال معاملات Blob-carrying لإكمال عملية التكييف. بالإضافة إلى ذلك، يجب تعديل إثبات الاحتيال ليتكيف مع EIP4844. ويمكن تنفيذ هذا الجزء ببطء. بعد كل شيء، العديد من التقارير المتفائلة لم تطلق بعد أدلة على الاحتيال. لقد وضعت شهادة احتيال عبر الإنترنت، ولكن وجدت أنه لم يتم تقديم أي شهادة احتيال منذ أكثر من عامين.
إرسال معاملة L2: عند إرسال البيانات المجمعة، يتم استخدام المعاملة الحاملة للبيانات الثنائية الكبيرة لتخزين بيانات البيانات المجمعة في البيانات الثنائية الكبيرة. الحمولة النافعة للمعاملة التي تحمل Blob هي rlp([tx_payload_body, blobs, engagements, prophes])، حيث
تعديل إثبات الاحتيال:
تتكيف ZK Rollups مع EIP4844
تستخدم مجموعة ZK ZKP لإثبات صحة انتقال حالة L2. يعد تكيف ZK التراكمي مع EIP4844 أكثر تعقيدًا من التراكمي المتفائل.
**4. ما هي لغات L2 التي تم تكييفها مع 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 Rollup يكمل EIP4844. **
تجمع مجموعة ZK المتفائل بين مزايا كلا النوعين من مجموعة التحديثات. إنه يؤمن بشكل متفائل بنتائج التنفيذ المقدمة من Sequencer ويسمح لأولئك الذين لديهم شكوك حول النتائج ببدء التحديات. فقط عند إصدار التحدي، سيقوم المُثبت بإنشاء ZKP لإثبات صحة نتائج التنفيذ. **يتمتع بكفاءة تراكمية متفائلة وموثوقية ZK المثبتة لـ ZK. **