تم إطلاق إصدار Dencun testnet لترقية شبكة Ethereum على شبكة اختبار Goerli في 17 يناير 2024، وتم إطلاق شبكة اختبار Sepolia بنجاح في 30 يناير. ترقية Dencun تقترب أكثر فأكثر.

بعد ترقية شبكة اختبار Holesky في 7 فبراير، ستكون ترقية الشبكة الرئيسية. تم تحديد إطلاق الشبكة الرئيسية لترقية كانكون رسميًا في 13 مارس 2024.

تقريبًا كل ترقية لـ Ethereum تكون مصحوبة باتجاهات سوقية مهمة. إذا نظرنا إلى الترقية الأخيرة في 12 أبريل 2023، والمعروفة باسم ترقية شنغهاي، فقد شهدت المشاريع المتعلقة بإثبات الملكية (PoS) زيادة في الطلب في السوق.

إذا تابعنا التجارب السابقة، فمن المحتمل أن تكون هناك فرص لتحديد المواقع الإستراتيجية قبل ترقية Dencun القادمة.

ومع ذلك، نظرًا للتعقيد الفني الذي تنطوي عليه ترقية Dencun، لا يمكن تلخيصها بإيجاز مثل ترقية شنغهاي بعبارة واحدة مثل "انتقال Ethereum من إثبات العمل (PoW) إلى إثبات الحصة (PoS)." هذا التعقيد يجعل من الصعب فهم النقاط المحورية لتحديد المواقع الاستراتيجية.

ولذلك، تهدف هذه المقالة إلى شرح التفاصيل الفنية لترقية Dencun بلغة بسيطة ومفهومة. وسوف يوجه القراء من خلال تعقيدات هذه الترقية، ويسلط الضوء على اتصالاتها مع توفر البيانات (DA)، وحلول الطبقة الثانية، والجوانب الأخرى ذات الصلة.

01. إي آي بي 4484

يبرز EIP-4844 باعتباره الاقتراح الأكثر أهمية في ترقية Dencun، مما يمثل خطوة كبيرة لـ Ethereum في رحلة التوسع اللامركزي.

بعبارات عامة، تتطلب حلول الطبقة الثانية الحالية من إيثريوم إرسال المعاملات التي تحدث على الطبقة الثانية إلى بيانات الاتصال الخاصة بشبكة إيثريوم الرئيسية. يتم بعد ذلك استخدام بيانات الاستدعاء هذه بواسطة العقد للتحقق من صحة الكتل الموجودة على شبكة الطبقة الثانية.

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

يقدم EIP-4844 حلاً فعالاً من حيث التكلفة من خلال إنشاء نوع جديد من مساحة التخزين يسمى الكائن الثنائي الكبير (BLOB). يقدم نوعًا جديدًا من المعاملات يُعرف باسم "معاملة حمل BLOB" لاستبدال بيانات المعاملة المخزنة مسبقًا في بيانات الاتصال قبل الترقية. يساعد هذا النهج المبتكر النظام البيئي Ethereum Layer 2 على تحقيق وفورات في تكاليف الغاز.

لماذا يعد تخزين BLOB فعالاً من حيث التكلفة？

وكما نعلم جميعا، فإن فعالية التكلفة غالبا ما تأتي مع مقايضة. السبب وراء تكبد بيانات BLOB تكاليف أقل مقارنة ببيانات استدعاء Ethereum العادية ذات الحجم المماثل هو أن طبقة تنفيذ Ethereum (EL) لا يمكنها الوصول مباشرة إلى بيانات BLOB نفسها.

بدلاً من ذلك، يمكن لـ EL فقط الوصول إلى المراجع إلى بيانات BLOB، ولا يمكن تنزيل البيانات الفعلية لـ BLOB وتخزينها إلا بواسطة طبقة إجماع Ethereum (CL، المعروفة أيضًا باسم عقد المنارة). تعد الذاكرة والمتطلبات الحسابية لتخزين بيانات BLOB أقل بكثير من بيانات استدعاء Ethereum العادية.

علاوة على ذلك، يتمتع BLOB بميزة مميزة - لا يمكن تخزينه إلا لفترة محدودة (عادة حوالي 18 يومًا) ولا يتوسع إلى ما لا نهاية مثل حجم دفتر الأستاذ في Ethereum.

فترة صلاحية تخزين BLOB

وعلى النقيض من دفتر الأستاذ الدائم لـ blockchain، فإن BLOBs عبارة عن تخزين مؤقت متاح لمدة 4096 حقبة، أو ما يقرب من 18 يومًا.

بعد انتهاء الصلاحية، لن يتمكن معظم عملاء الإجماع من استرداد بيانات محددة في BLOB. ومع ذلك، سيظل دليل وجودها السابق على الشبكة الرئيسية في شكل التزامات KZG وسيتم تخزينه بشكل دائم على شبكة Ethereum الرئيسية.

لماذا 18 يوما؟ هذه مقايضة بين تكلفة التخزين والفعالية.

أولاً، يجب أن نأخذ في الاعتبار المستفيدين الأكثر بديهية من هذه الترقية، وهي المجموعات المتفائلة (مثل Arbitrum وOptimism،)، نظرًا لوجود نافذة زمنية لإثبات الاحتيال مدتها 7 أيام في المجموعات المتفائلة. إن بيانات المعاملات المخزنة في Blob هي بالضبط ما تحتاجه Optimistic Rollups عند إطلاق التحدي.

لذلك، يجب أن تضمن فترة صلاحية Blob إمكانية الوصول إلى دليل الاحتيال المتفائل. من أجل التبسيط، اختار مجتمع إيثريوم 2 أس 12 (4096 حقبة مشتقة من 2^12، والحقبة الواحدة تبلغ حوالي 6.4 دقيقة).

المعاملات الحاملة لـ BLOB وBLOB

يعد فهم العلاقة بين الاثنين أمرًا مهمًا لفهم دور BLOBs في توفر البيانات (DA).

الأول هو اقتراح EIP-4484 الشامل وهو نوع جديد من المعاملات، في حين يمكن فهم الأخير على أنه موقع تخزين مؤقت لمعاملات الطبقة الثانية.

يمكن فهم العلاقة بين الاثنين على أنها معظم البيانات الموجودة في الأول (بيانات معاملات الطبقة الثانية) يتم تخزينها في الأخير. سيتم تخزين البيانات المتبقية، أي التزام بيانات BLOB، في بيانات الاتصال الخاصة بالشبكة الرئيسية. بمعنى آخر، يمكن لآلية التصويت قراءة الوعود.

يمكن تصور الالتزام على أنه بناء جميع المعاملات في BLOB في شجرة Merkle، ومن ثم يمكن الوصول إلى جذر Merkle فقط، وهو الالتزام، من خلال العقد.

يمكن تحقيق ذلك بذكاء: على الرغم من أن EVM لا يمكنه معرفة المحتوى المحدد لـ BLOB، يمكن لعقد EVM التحقق من صحة بيانات المعاملة من خلال معرفة الالتزام.

02. العلاقة بين BLOB والطبقة الثانية

تحقق تقنية التجميع توفر البيانات (DA) عن طريق تحميل البيانات إلى شبكة Ethereum الرئيسية، ولكن ليس المقصود من عقود L1 الذكية قراءة هذه البيانات التي تم تحميلها أو التحقق منها مباشرة.

الغرض من تحميل بيانات المعاملات إلى L1 هو ببساطة السماح لجميع المشاركين بعرض البيانات.

قبل ترقية Dencun، كما هو مذكور أعلاه، ستقوم Optimistic Rollups بنشر بيانات المعاملات إلى Ethereum كبيانات اتصال. لذلك، يمكن لأي شخص استخدام معلومات المعاملة هذه لإعادة إنتاج الحالة والتحقق من صحة شبكة الطبقة الثانية.

ليس من الصعب أن نرى أن بيانات المعاملات المجمعة يجب أن تكون رخيصة ومفتوحة وشفافة. لا تعد Calldata مكانًا جيدًا لتخزين بيانات المعاملات خصيصًا للطبقة 2، كما أن معاملة BLOB-Carrying مصممة خصيصًا للتجميع.

في هذه المرحلة، قد تتساءل عن أهمية بيانات المعاملة.

في الواقع، يتم استخدام بيانات المعاملات فقط في سيناريوهات محددة:

• بالنسبة إلى مجموعة البيانات المتفائلة، المستندة إلى افتراض الثقة، هناك احتمال لعدم الأمانة. في مثل هذه الحالات، تصبح سجلات المعاملات التي تم تحميلها عن طريق التجميع مفيدة، مما يمكّن المستخدمين من بدء إثباتات الاحتيال.
• بالنسبة إلى ZK Rollup، أثبت إثبات المعرفة الصفرية أن تحديث الحالة صحيح. يهدف تحميل البيانات فقط إلى السماح للمستخدمين بحساب الحالة الكاملة بأنفسهم. عندما لا تعمل عقدة الطبقة الثانية بشكل صحيح، يتم تمكين آلية الهروب، التي تتطلب شجرة حالة L2 كاملة. سيتم مناقشة هذا في القسم الأخير من هذه المقالة.

وهذا يعني أن الاستخدام الفعلي لبيانات المعاملات من خلال العقود محدود للغاية. حتى في أدلة الاحتيال الخاصة بـ Optimistic Rollup، لا يلزم سوى إثبات أن بيانات المعاملة "موجودة" في لحظة معينة، وليست هناك حاجة لتخزين تفاصيل كل معاملة على الشبكة الرئيسية مسبقًا.

من خلال وضع بيانات المعاملة في BLOB، على الرغم من عدم إمكانية الوصول إليها في العقود، يمكن لعقد الشبكة الرئيسية تخزين التزام BLOB.

إذا كانت آلية إثبات الاحتيال تحتاج إلى معاملة محددة في المستقبل، فإن توفير البيانات الخاصة بتلك المعاملة، طالما كانت متطابقة، يمكن أن يقنع العقد ويوفر بيانات المعاملة لآلية إثبات الاحتيال.

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

من خلال تسجيل الالتزام فقط، يمكن التحقق من بيانات المعاملات مع تحسين التكاليف بشكل كبير. يعد هذا حلاً ذكيًا وفعالاً لتحميل بيانات المعاملات باستخدام تقنية التجميع.

تجدر الإشارة إلى أنه في التشغيل الفعلي لـ Dencun، لا يتم استخدام شجرة Merkle المشابهة لـ Celestia لتوليد الالتزام، ولكن يتم استخدام خوارزمية KZG (Kate-Zaverucha-Goldberg، Polynomial Commitment).

بالمقارنة مع إثبات شجرة Merkle، فإن عملية إنشاء إثبات KZG معقدة نسبيًا، ولكن حجم التحقق الخاص بها أصغر وخطوات التحقق أبسط. ومع ذلك، فإن العيب هو أنه يتطلب إعدادات جديرة بالثقة (ceremony.ethereum.org، والتي انتهت الآن) وليس لديها القدرة على منع هجمات الحوسبة الكمومية (يستخدم Dencun طريقة تجزئة الإصدار، ويمكن استبدال طرق التحقق الأخرى إذا لزم الأمر).

بالنسبة لمشروع DA المشهور الآن Celestia، فإنه يستخدم نوعًا مختلفًا من شجرة Merkle. على عكس KZG، فهو يعتمد إلى حد ما على سلامة العقد ولكنه يساعد على خفض عتبة الموارد الحسابية بين العقد، مما يحافظ على الطبيعة اللامركزية للشبكة.

03. الفرص في دينكون

بينما يعمل EIP-4844 على تقليل التكاليف وزيادة الكفاءة للطبقة الثانية، فإنه يزيد أيضًا من المخاطر الأمنية، مما يوفر أيضًا فرصًا جديدة.

لفهم السبب، علينا العودة إلى آلية فتحة الهروب أو آلية الانسحاب القسري المذكورة أعلاه.

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

في ظل الظروف العادية، يحتاج المستخدمون فقط إلى العثور على عقدة كاملة من الطبقة الثانية لطلب البيانات، وإنشاء دليل Merkle، ثم إرسالها إلى عقد الشبكة الرئيسية لإثبات شرعية انسحابهم.

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

هذا ما يشير إليه Vitalik غالبًا على أنه هجوم حجب البيانات.

قبل EIP-4844، تم تسجيل سجلات الطبقة الثانية الدائمة على الشبكة الرئيسية. عندما لا تتمكن عقدة الطبقة الثانية من توفير حالة كاملة خارج السلسلة، يمكن للمستخدمين نشر عقدة كاملة بأنفسهم.

يمكن لهذه العقدة الكاملة الحصول على جميع البيانات التاريخية الصادرة عن جهاز تسلسل الطبقة الثانية على الشبكة الرئيسية من خلال شبكة Ethereum الرئيسية. يمكن للمستخدمين إنشاء دليل Merkle المطلوب وإرسال الدليل إلى العقد على الشبكة الرئيسية لإكمال سحب أصول L2 بأمان.

بعد EIP-4844، توجد بيانات الطبقة الثانية فقط في BLOB الخاص بعقد Ethereum الكاملة، وسيتم حذف البيانات التاريخية قبل 18 يومًا تلقائيًا.

ولذلك، فإن الطريقة المذكورة في الفقرة السابقة للحصول على شجرة الحالة بأكملها عن طريق مزامنة الشبكة الرئيسية لم تعد مجدية. إذا كنت ترغب في الحصول على شجرة الحالة الكاملة للطبقة الثانية، فيمكنك الاعتماد فقط على عقد الشبكة الرئيسية التابعة لجهات خارجية والتي قامت بتخزين جميع بيانات Ethereum BLOB (والتي كان من المفترض أن يتم حذفها تلقائيًا بعد 18 يومًا)، أو العقد الأصلية للطبقة الثانية (والتي هي نادر).

بعد إطلاق EIP-4844، سيكون من الصعب جدًا على المستخدمين الحصول على شجرة الحالة الكاملة للطبقة الثانية بطريقة جديرة بالثقة تمامًا.

بدون طريقة مستقرة للمستخدمين للحصول على شجرة حالة الطبقة الثانية، لن يتمكنوا من إجراء عمليات السحب القسري في ظل الظروف القاسية. لذلك، أصبح EIP-4844 عيبًا أمنيًا للطبقة الثانية إلى حد ما.

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

يمكن لـ Ethstorage حل مشكلة انعدام الثقة وقد تلقت جولتين من التمويل من مؤسسة Ethereum.

في الواقع، يمكن لهذا المفهوم أن يلبي الإمكانات التي جلبتها ترقية Dencun، وهو يستحق اهتمامنا.

تتمثل الأهمية الأكثر سهولة لـ Ethstorage في أنه يمكنه تمديد الوقت المتاح لـ DA BLOB بطريقة لا مركزية تمامًا، مما يعوض عن أوجه القصور في أمان الطبقة الثانية بعد EIP-4844.

بالإضافة إلى ذلك، تركز معظم حلول اللغة الثانية الحالية بشكل أساسي على توسيع نطاق قوة حوسبة إيثريوم، أي زيادة TPS. ومع ذلك، فقد ارتفع الطلب على تخزين كميات كبيرة من البيانات بشكل آمن على شبكة إيثريوم الرئيسية، خاصة بسبب شعبية التطبيقات اللامركزية مثل NFTs وDeFi.

على سبيل المثال، يعد الطلب على تخزين NFTs على السلسلة ضخمًا، لأن المستخدمين لا يمتلكون الرموز المميزة لعقود NFT فحسب، بل يمتلكون أيضًا الصورة الموجودة على السلسلة. يمكن لـ Ethstorage حل مشكلات الثقة الإضافية التي تأتي مع تخزين هذه الصور في جهة خارجية.

أخيرًا، يمكن لـ Ethstorage أيضًا حل احتياجات الواجهة الأمامية للتطبيقات اللامركزية اللامركزية. تتم استضافة الحلول الحالية بشكل أساسي بواسطة خوادم مركزية (مع DNS). يجعل هذا الإعداد مواقع الويب عرضة للرقابة ومشكلات أخرى مثل اختطاف DNS أو اختراق مواقع الويب أو تعطل الخادم، كما يتضح من حوادث مثل Tornado Cash.

لا يزال Ethstorage في مرحلة الاختبار الأولي، ويمكن للمستخدمين المتفائلين بشأن آفاق هذا المسار تجربته.

تنصل:

1. تمت إعادة طبع هذا المقال من [Biteye]، جميع حقوق النشر مملوكة للمؤلف الأصلي [Biteye]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.