ترقية Ethereum Dencun والفرص المحتملة

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

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

ستكون كل ترقية لـ Ethereum تقريبًا مصحوبة بموجة من أسعار السمات. آخر مرة تمت فيها ترقية Ethereum كانت ترقية Shanghai في 12 أبريل 2023. . ، تم البحث عن المشاريع المتعلقة بنقاط البيع من قبل السوق.

إذا تم اتباع الخبرة السابقة، فستتاح أيضًا الفرصة لترقية Dencun هذه للتخطيط مسبقًا.

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

لذلك، ستستخدم هذه المقالة لغة سهلة الفهم لشرح التفاصيل الفنية لترقية Dencun، وفرز هذه الترقية وتوافر البيانات DA والطبقة الثانية مسابقات للقراء الروابط بين الطرق.

EIP 4484

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

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

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

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

السبب وراء رخص سعة تخزين BLOB

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

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

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

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

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

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

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

أولاً وقبل كل شيء، يجب أن نأخذ في الاعتبار المستفيدين الأكثر بديهية من هذه الترقية، وهم Optimistic Rollups (مثل: Arbitrum وOptimism،)، لأنه وفقًا لإعداد مجموعات متفائلة، هناك نافذة زمنية مدتها 7 أيام لإثبات Fruad.

بيانات المعاملة المخزنة في blob هي بالضبط ما تحتاجه Optimistic Rollups عند إطلاق التحدي.

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

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

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

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

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

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

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

العلاقة بين BLOB وLayer2

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

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

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

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

بعد قراءة هذا قد يتبادر إلى ذهنك سؤال. هذا النوع من بيانات المعاملات لا يبدو مهمًا. ما فائدته؟

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

• < p style="text-align: left;">بالنسبة إلى مجموعة التحديثات المتفائلة، استنادًا إلى افتراض الثقة، قد تكون هناك مشكلات تتعلق بعدم الأمانة. في هذا الوقت، أصبحت سجلات المعاملات التي تم تحميلها بواسطة مجموعة التحديثات مفيدة. يمكن للمستخدمين استخدام هذه البيانات للبدء تحديات المعاملات (إثبات الاحتيال)؛

• بالنسبة إلى ZK Rollup، أثبت إثبات المعرفة الصفرية أن تحديث الحالة صحيح، وأن التحميل البيانات مخصصة فقط للمستخدمين لحساب الحالة الكاملة وتمكين آلية الهروب عندما لا تعمل عقدة المستوى الثاني بشكل صحيح (يتطلب Escape Hatch شجرة حالة L2 كاملة، والتي ستتم مناقشتها في القسم الأخير).

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

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

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

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

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

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

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

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

الفرص المتاحة لـ Dencun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يمكن القول أن هذا المفهوم يمكن أن يلبي/يعوض حقًا مسار Dencun الذي تمت ترقيته، وهو يستحق الاهتمام جدًا.

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

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

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

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

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