مقدمة

ما تخزنه وتشير إليه سلاسل الكتل أثناء معالجة المعاملات يُسمى الحالة. على الإيثيريوم، الحالة هي الخاصية التي تُيسر توافق العقدة. كل عقدة كاملة تحتاج إلى تخزين وتحديث هذه الحالة خلال كل فترة من الكتل الصالحة. الحالة، بقدر أهميتها في سلاسل الكتل، تأتي مع عيب؛ فهي تنمو مع الوقت. إنها مشكلة كبيرة في سلاسل الكتل، مثل بيتكوين والإيثيريوم، لأن الزيادة في الحجم تأتي مع زيادة متساوية في متطلبات الأجهزة للعقد. يُحدث الحد الفضائي إخراج بعض العقد مع مرور الوقت، مما يؤدي إلى التمركز.EIP-2935تقترح جلب الحالة اللا دولية إلى إيثيريوم، مما يخفف على العقد الحاملين لعبء الحجم. EIP-2935 هو اقتراح تحسين يحاول تحقيق الحالة اللا دولية عن طريق تخزين وخدمة آخر 8192 تجزئة للكتلة من الحالة للتنفيذ اللا دولي في إيثيريوم.

نظرة عامة على الهيكل الحالي لإيثيريوم

الكتل

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

تغيير الحالة في إيثريوم

بمجرد معالجة كتلة جديدة وبثها مع محقق على الشبكة، يضيف بقية المشاركين إليها إلى تخزينهم ويحدثون حالتهم العامة. يتم اختيار محقق كل كتلة عشوائيًا بواسطة تقنية ترتيب السحب العشوائي اللامركزية (RANDAO)المعلمة. هيكل الكتلة مُرَتَّب بدقة، وتُحدَّد عملية إنشاء الكتلة وعمليات الاتفاق بموجب بروتوكول الإثبات بالمال الخاص بإثيريوم.

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

إيثيريوم12 ثانيةفترة إنشاء الكتلة، المعروفة أيضًا بـ “فتحة”، تأتي من تمكين ما يكفي من الوقت لمشاركي الشبكة لمزامنة الكتل الجديدة والاتفاق على التوافق. خلال هذه الفترة:

1. يختار مقترح الكتلة عشوائيًا محققًا،
2. يقوم المحقق بتجميع المعاملات معًا وتنفيذها لتحديد حالة عالمية جديدة،
3. يتضمنون هذه المعلومات في كتلة جديدة ويبثونها إلى بقية مجموعة المحققين من خلال بروتوكول النميمة،
4. المحققون الآخرون يعيدون تنفيذ المعاملات لضمان الصحة والاتفاق مع تغيير الحالة العالمية كاتفاق،
5. إذا قام المحقق بالتحقق من الكتلة الجديدة كصالحة، فإنهم يضيفونها إلى تخزينهم.

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

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

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

تجربة ميركل وميركل باتريشيا

تعتبر هياكل الـTrie، وخاصة الـMerkle Tries، أساسية لتخزين سلسلة الكتل. بدون الـMerkle tries، تصبح سلاسل الكتل كتل واحدة تصعب معالجتها في كل مرة. بفضل الـMerkle tries، أو بشكل عام هندسة الـtrie، تحقق سلاسل الكتل اكتمالًا مع التجزئات الأساسية. وهذا يمكنها من أن تصبح مشاركين في الشبكة بمتطلبات أجهزة منخفضة.

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

إيثريوم يفضل Merkle Patricia Tries، وهي هيكل Merkle trie مزدوج. إنها تستخدم Binary Tries لمعالجة البيانات الأساسية، مثل بيانات المعاملات، نظرًا لكفاءة هذا النهج في مثل تلك الحالات. ومع ذلك، يستخدم إيثريوم Merkle Patricia Tries الأكثر تعقيدًا في الحالات المعقدة، مثل معالجة الحالة.

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

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

Alt: القائمة المفرزة الثنائية

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

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

Alt: شجرة ميركل باتريشيا تراي

غاز

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

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EIP-1559قامت بإجراء بعض التغييرات الكبيرة على آلية رسوم المعاملات. دفع رسوم الغاز لتضمين المعاملات في الكتل تمت بطريقة تشبه المزاد في الماضي. مع EIP-1559، هناك حد أدنى يسمى رسوم الأساس ونصيحة تسمى رسوم الأولوية. يُقترح أن تبدأ الكتل من المعاملة التي تحمل أعلى رسوم أولوية. بعد عملية الكتلة، يتم حرق الرسوم الأساسية، وتُستخدم رسوم الأولوية لتحفيز المدققين.

الدولة

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

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

الفروق بين انتهاء البيانات وانتهاء الحالة

انتهاء البيانات

انتهاء البيانات أو التاريخ يعني تقليم البيانات غير الضرورية من العملاء بعد فترة معينة. من خلال "نقاط التحقق من الذاتية الضعيفة"، يمكن للعملاء أن يجدوا طريقهم في المزامنة من النشأة وتقليم البيانات التاريخية الزائدة.

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

EIP-4444يوفر المسار العملي إلى@hBXHLw_9Qq2va4pRtI4bIAيحقق انتهاء البيانات من خلال الضعف-الموضوعية. لا تهدف الاقتراحات إلى تغيير كيفية تعامل العقد الذكية في إيثيريوم مع بيانات الحالة؛ بل يعدّل الوصول إلى البيانات التاريخية.

انتهاء الحالة

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

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

الحالة غير المرتبطة بالإثيريوم

مقدمة إلى عدم الحالة وشبكة إيثيريوم اللاحدية

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

EIP-161قدمت الطريقة الأولى لتقليل الحالة. تعرضت إثريوم لهجوم DoS (إنكار الخدمة)، وسمحت هذه الثغرة بإنشاء حسابات فارغة زادت من الحالة العالمية لإثريوم. اقترح EIP-161 إزالة الحسابات الفارغة بقيمة صفر (0) عند nonce الخاص بها الذي نشأ من هذا الهجوم، بتكاليف منخفضة. تم تنفيذ الاقتراح، مما أدى إلى إرجاع الحالة.

تم اقتراح جهد آخر نحو عدم الانتماء إلى الحالة عبر EIP-4788. هدفت هذه الاقتراحات إلى الكشف عن جذور كتل سلسلة البيكون في EVM. على غرار النهج الذي اتبعته الجسر إث1-إث2عند ربط سلسلة البيكون (طبقة التوافق) وطبقة التنفيذ، تتيح هذه الاقتراحات وصولًا غير مركز للثقة بين EVM وطبقة التوافق.

لأن كل كتلة تنفيذ تحتوي على جذر كتلة الوالد البصرية، فإن أحداث فتحات الفوترة المفقودة لن تحتاج إلى تغيير جذر الكتلة السابقة. لذلك، تقتصر متطلبات التنفيذ على حجز مساحة صغيرة لمدخلات الثقة المُنَعَّشة في كل كتلة تنفيذ. تقترح المقترحات تخزين تاريخ صغير لجذور الكتل في عقد الجذر لتحسين كفاءة المُنَعَّش.

العديمة للحالة في إثيريوم ممكنة سواء كانت عديمة ضعيفة أو عديمة قوية.

ضعف البلا دولي

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

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

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

حالة عدم الدولة القوية

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

ومع ذلك، يمكن استخدام بعض التغييرات والخصائص لتحقيق عدم الاعتماد على الحالة. يقترح EIP-2935 تقديم تاريخ كتلة الهاشات من الحالة للسماح بالتنفيذ غير المعتمد على الحالة.

مقدمة لـ EIP-2935

EIP-2935 يهدف إلى حفظ تجزئات تخزين خاصة تسمى HISTORY_STORAGE_ADDRESS في حالة البلوكشين التاريخية في الحالة الخاصة. سيسمح هذا العملية بالتنفيذ بدون حالة عن طريق تيسير الوصول السهل إلى المعلومات التاريخية الضرورية في عملاء بدون حالة.

يقترح EIP-2935 تخزين تاريخ ما يصل إلى 8192 جزءًا من تاريخ تجزئة الكتل في عقد النظام لاستخدامه كجزء من منطق معالجة الكتل. المشكلة التي تحاول هذا المقترح حلها هي افتراض EVM أن لدى العميل تجزئة الكتل الأخيرة. هذا النهج القائم على الافتراض لا ينطبق على مستقبل Ethereum وخصوصًا العملاء غير المتماسكين.

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

توسيع نطاق الكتل التي يخدمها blockHash إلى 8192 كتلة سيسمح بانتقال ناعم إلى أساليب التنفيذ. يمكن لل Rollups الاستفادة من هذه النافذة الزمنية الأطول من خلال الاستعلام مباشرة عن هذا العقد لأن بيانات blockHash مخزنة في هذا العقد. بالإضافة إلى ذلك، سيسهل هذا EIP التحقق من الأدلة المتعلقة بكمية 8192 كتلة من نافذة HISTORY_SERVE_WINDOW مقابل الحالة الحالية.

فهم EIP-2935

يتيح EIP-2935 لعملاء Ethereum، وخاصة العملاء اللاحدوديين، الوصول بسهولة إلى تجزئات الكتل الأخيرة. لجعل هذا العمل يعمل، يقدم أربعة معلمات جديدة:

• نافذة خدمة تحديد هاش الكتلة: تخبر العملاء بعدد تحديد من الهاشات الكتلة السابقة التي يجب أن يحتفظوا بها. القيمة الافتراضية هي 256.
• نافذة تاريخ الخدمة: يحدد هذا المعلمة عدد كتل القيمة من الهاشات التي تم تخزينها. القيمة الافتراضية هي 8191.
• عنوان النظام: عنوان خاص (تم إدخاله أصلاً في EIP-4788) الذي يعمل كـ "المتصل" لكتابة تجزئة الكتل في التخزين.
• HISTORY_STORAGE_ADDRESS: عنوان العقد حيث يتم تخزين عناوين هذه الكتل.

توجه مواصفات الاقتراح بتخزين تشفيرات الكتل الأخيرة في نافذة خدمة التاريخ في تخزين حلقي بطول نافذة خدمة التاريخ.

حلقة التخزين المؤقت

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

قواعد اختيار الشوكة والمواصفات

بعد الفورك، عندما يبدأ الشبكة مع هذه الاعتبارات EIP، سيتم الإشارة إلى PARAMETER_HISTORY_STORAGE_ADDRESS باسم SYSTEM_ADDRESS مع إدخال block.parent.hash (32 بايت افتراضي) وحد الغاز 30.000.000، وقيمة 0. سيؤدي هذا العملية إلى تشغيل وظيفة set() لعقد التاريخ.

يختلف عملية الانشقاق بعد الاقتراح عن العملية الانشقاق العادية. هذه العملية set() هي عملية نظام عامة، ولكن يتبع الاستدعاء هذه الاتفاقيات:

• يجب تنفيذها حتى الانتهاء
• لا يحتسب ضد حد الغاز للكتلة
• لا يتبع آلية حرق EIP-1559
• إذا لم يوجد كود في عنوان تخزين السجلات، يجب أن يفشل الاستدعاء دون وقوع أخطاء فادحة.

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

سيكون لدى عقد تاريخ تجزئة الكتلتين عمليتان: get() و set(). يتم تنشيط عملية set() إذا كان منادي العقد في معاملة يساوي SYSTEM_ADDRESS التي تم تقديمها مع EIP-4788. إذا لم يكن منادي النظام و SYSTEM_ADDRESS متساويين أو لا يستوفون الشروط، يتم تنشيط عملية get().

يتم استخدام عملية get() في EVM لتحديد تجزئة hashes. يُسمح للمتصلين بتقديم رقم الكتلة التي يتم الاستعلام عنها، إذا كان إدخال calldata ليس 32 بايتًا (وهو ما يعني أنها كتلة والدية صالحة. hash) وإذا كان الطلب خارج نطاق ([رقم الكتلة-HISTORY_SERVE_WINDOW، رقم الكتلة-1])، فإنه يعيد المعاملة.

set() يأخذ block.parent.hash كمدخل عندما يقوم النداء بالاتصال بالعقد بمعاملة. كما يقوم أيضًا بتعيين قيمة التخزين كـ calldata[0:32] في block.number-1 % HISTORY_SERVE_WINDOW.

سيتم نشر عنوان تخزين السجلات التاريخية عبر EIP-4788، والذي يشار إليه أعلاه باعتباره وسيلة الوصول إلى تجزئة الكتل مباشرةً عبر طبقة الاتفاق. سيكون لدى عنوان تخزين السجلات التاريخية قيمة nonce بوصفها 1 وسيكون معفىً من معيار تنظيف nonce صفري EIP-161.

منطق انتقال BLOCKHASH

إحدى المخاوف بشأن هذا EIP هي كيفية الانتقال الأمثل لمنطق حل BLOCKHASH بعد الشوكة. يُنظر إلى نهجين رئيسيين حاليًا:

• انتظر تقديم HISTORY_SERVE_WINDOW كتل ليستمر كل التاريخ ذي الصلة
• قم بتخزين جميع تجاويف الكتل الأخيرة في HISTORY_SERVE_WINDOW على كتلة الشوكة.

يختار المطورون الخيار الأول. إنه أكثر عملية لأنه لا يتطلب أي تغييرات مؤقتة.

ما الفرق بين EIP-2935 وEIPs المماثلة؟

تمت اقتراح EIPs مماثلة من قبل للسماح بالتنفيذ بدون حالة وتحقيقه. يختلف EIP-2935 عن هذه الاقتراحات السابقة لأنه يستهدف التعقيدات المسلطة أدناه.

• نهج هيكل الشجرة: لا يستخدم EIP-2935 هيكل شجرة مثل الشجرة ذات الطبقات المتعددة وبدلاً من ذلك يختار قائمة واحدة. على العكس، اقترح EIP-4444 تقليم البيانات التاريخية في عملاء التنفيذ القديمة بعمر سنة. لدى EIPs الأخرى ذات الطموحات المماثلة تفاعلات Verkle كمتطلبات.
• كتابة EIP في EVM Code: لا يتطلب EIP-2935 تغييرًا في EVM.
• التخزين المتسلسل غير المحدود للتشفيرات: التخزين التسلسلي غير المحدود للتشفيرات غير كفء. يتغلب هذا EIP على هذه المشكلة من خلال تجميع التشفيرات.

اعتبارات الأمان

نظرًا لأن EIP-2935 يستخدم عقود ذكية، فإنه يعرض نفسه لهجمات تسمم الفروع. ومع ذلك، يجعل حجم جذر الحالة أي محاولة للتحديث بطيئة وهجوم تسمم أكثر تكلفة بشكل كبير.

ما الذي يمكن أن يجلبه؟

• جعل أنظمة البوابات غير الموثوق بها أسرع: في بوابات البوابات المعتمدة على Uniswap v2، يمكن لأي شخص لديه وصول إلى عقد Ethereum إنشاء دليل على تخزين Uniswap وتقديمه للتحقق على السلسلة. يتم تحديد السعر المتوسط ​​بين الكتلة الحالية وكتلة الدليل الموردة، مع تحقق الدليل حتى 256 كتلة، حيث يدعم blockHash حتى 256 كتلة. من استفادة EIP-2935، يمكن تحسين هذه العملية عن طريق السماح بالوصول إلى تجاوزات الكتل القديمة، مما يعني أن يمكن التحقق من الدلائل على مدى فترة زمنية أطول.
• السماح للعقود بالنظر في تأكيدات الحالة السابقة، بطريقة غير قابلة للثقة: تحسين EIP-2935 يخلق إمكانية النظر في بيانات سلسلة الكتل من داخل EVM، بطريقة غير قابلة للثقة. يمكن للعميل استعلام التاريخ، والحصول على تجزئته، والتحقق منه مع العقداء الآخرين. يمكن أن تجعل الحلول العملاء الخفيفة فعالة وسهلة التنفيذ.
• الجسر بين L1 <> L2: للتحقق من رسالة من L2، يجب على L1 معرفة جذور حالة L2 وتجزئة الكتل. ومع ذلك، لا يمكن لـ L1 في حالته الحالية الوصول إلى تجزئة الكتل التي تحدث عشوائيًا بسبب حدود الغاز والقيود المعمارية. يمكن لـ EIP-2935 لـ L1 التحقق من البيانات التاريخية العشوائية بالقدرة على استكشاف دلائل الاحتواء للأحداث القديمة. ستتحسن القدرة على الوصول والتحقق، وأداء الجسر.

استنتاج

تمثل EIP-2935 خطوة حاسمة نحو تحقيق الهدف طويل الأمد لـ Ethereum الخالي من الحالة. يتمثل تخزين آخر 8192 عنوان تشفيري في عقد مخصص ضمن عناوين الحالة في تحديد الحدود الأساسية في التصميم الحالي. فإن افتراض Ethereum بأن العملاء لديهم بشكل طبيعي وصول إلى تشفيرات الكتل الأخيرة. في سياق التنفيذ الخالي من الحالة، حيث لا يقوم العملاء بالاحتفاظ بالحالة الكاملة بعد الآن، يصبح هذا الافتراض قديمًا. يحل EIP-2935 هذه المشكلة من خلال إدخال آلية خفيفة الوزن وفعالة وغير مُزعجة تمكن العملاء الخاليين من الحالة من الوصول إلى البيانات التاريخية اللازمة دون تعديل EVM أو الاعتماد على هياكل بيانات معقدة مثل تجارب Verkle.

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

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

تنصل:

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