jakiro
المؤلف: Vitalik ، مؤسس Ethereum ؛
ملاحظة: هذه المقالة هي الجزء الخامس من سلسلة المقالات التي نشرتها فيتاليك مؤخرًا ، مؤسس Ethereum ،العقود الآجلة المحتملة لبروتوكول Ethereum ، الجزء 5: التطهير“، انظر الجزء الرابع”Vitalik: حافة Ethereum“. يرى “Vitalik: الأهداف الرئيسية لل Ethereum مرحلة Scourge“، انظر الجزء الثاني”Vitalik: كيف ينبغي أن يتطور بروتوكول Ethereum في مرحلة الارتفاع“، انظر الجزء الأول”ماذا يمكن تحسينه على Ethereum POS“ما يلي هو النص الكامل للجزء الخامس:
أحد التحديات التي تواجه Ethereum هو أنه بشكل افتراضي ، سوف يزداد الانتفاخ وتعقيد أي بروتوكول blockchain بمرور الوقت.يحدث هذا بطريقتين:
-
البيانات التاريخية:يجب أن يتم تخزين أي معاملة وأي حساب تم إنشاؤه في أي لحظة تاريخية بشكل دائم من قبل جميع العملاء ويتم تنزيله من قبل أي عميل جديد تتم مزامنته بالكامل مع الشبكة.يؤدي هذا إلى زيادة وقت تحميل العميل ووقت التزامن مع مرور الوقت ، حتى لو بقيت سعة السلسلة كما هي.
-
وظائف البروتوكول:تعد إضافة ميزات جديدة أسهل بكثير من إزالة الميزات القديمة ، مما يؤدي إلى زيادة تعقيد الكود بمرور الوقت.
من أجل أن تستمر Ethereum لفترة طويلة ، نحتاج إلى وضع ضغط مكثف على كلا الاتجاهين ، مما يقلل من التعقيد والانتفاخ مع مرور الوقت.لكن في الوقت نفسه ، أنانحن بحاجة إلى الاحتفاظ بأحد سمات blockchain الرئيسية: الثبات.يمكنك وضع NFTS أو Love Letters في بيانات مكالمات المعاملات أو العقود الذكية التي تحتوي على مليون دولار على السلسلة ، وإدخال كهف لمدة عشر سنوات ، وتجد أنه لا يزال هناك في انتظارك للقراءة والتفاعل.من أجل أن تكون DAPPs غير مركزية بالكامل وإزالة مفاتيح الترقية بثقة ، يجب أن يكونوا متأكدين من أن تبعياتهم لا تتم ترقيتها بطريقة تكسرها – خاصةً L1 نفسها.
تطهير ، 2023 خريطة الطريق.
إذا ركزنا على هذه الاحتياجات وتوازنها ، فإن التقليل من أو عكس التوسع والتعقيد والركود مع الحفاظ على الاستمرارية ، ممكن تمامًا.يمكن للكائنات الحية القيام بذلك: في حين أن معظم الكائنات الحية مع مرور الوقت ، لحسن الحظ ، فإن بعض الكائنات الحية لا تتقدم في العمر.حتى الأنظمة الاجتماعية يمكن أن يكون لها عمر طويل للغاية.في بعض الحالات ، كان Ethereum ناجحًا: لقد اختفى إثبات العمل ، وقد اختفى رمز Opcode الذاتي بشكل أساسي ، وتخزين عقدة سلسلة المنارة بيانات قديمة لمدة تصل إلى ستة أشهر.إن إيجاد هذا المسار لـ Ethereum بطريقة أكثر عمومية والانتقال نحو النتيجة النهائية المستقرة على المدى الطويل هو التحدي النهائي لتوسيع نطاق التوسع على المدى الطويل لـ Ethereum ، والاستدامة التكنولوجية وحتى الأمن.
التطهير: الأهداف الرئيسية
تقليل متطلبات تخزين العميل عن طريق تقليل أو إلغاء الحاجة إلى تخزين كل عقدة بشكل دائم ، وقد تنهيها بشكل دائم
تقليل تعقيد البروتوكول عن طريق القضاء على الميزات غير المرغوب فيها
انتهت البيانات التاريخية
ما هي المشكلات التي يحلها؟
اعتبارًا من كتابة هذه السطور ، تتطلب عقدة Ethereum المتزامنة بالكامل حوالي 1.1 تيرابايت من مساحة القرص لتنفيذ العميل ، ومساحة بضع مئات من الجياشناع لاستخدامها في عميل الإجماع.معظمهم بيانات تاريخية: بيانات حول الكتل التاريخية والمعاملات والإيصالات ، معظمها منذ سنوات.هذا يعني أنه حتى إذا لم يزداد حد الغاز على الإطلاق ، فإن حجم العقدة يزيد بمئات GB في السنة.
ما هذا؟كيف تعمل؟
تتمثل الميزة الرئيسية المبسطة لمشكلة التخزين التاريخية في أنه نظرًا لأن كل كتلة تشير إلى الكتلة السابقة من خلال روابط التجزئة (والهياكل الأخرى) ، فإن التوصل إلى توافق في الآراء على التيار يكفي للتوصل إلى توافق في الآراء بشأن التاريخ.طالما توافق الشبكة على أحدث كتلة ، يمكن توفير أي كتلة تاريخية أو معاملة أو حالة (رصيد الحساب والرقم العشوائي والرمز والتخزين) من قبل أي مشارك واحد مع Merkle Proof هو الجنس الصحيح.على الرغم من أن الإجماع هو نموذج N/2-Of-N Trust ، إلا أن التاريخ هو نموذج الثقة 1 من N.
هذا يفتح الكثير من الخيارات لكيفية تخزين التاريخ.الخيار الطبيعي هو شبكة لا تخزن فيها كل عقدة سوى جزء صغير من البيانات.هذه هي الطريقة التي عملت بها شبكة التورنت منذ عقود: في حين أن الشبكة تخزن وتوزيع ملايين الملفات في المجموع ، فإن كل مشارك يخزن ويوزع عدد قليل منهم فقط.ربما على عكسي ، قد لا يقلل هذا النهج من متانة البيانات.إذا تمكنا من تنفيذ شبكة تضم 100000 عقد عن طريق تقليل تكلفة تشغيل العقدة ، حيث تخزن كل عقدة بشكل عشوائي 10 ٪ من السجل ، فسيتم نسخ كل جزء من البيانات 10000 مرة – مع 10،000 من المحتوى المخزن لكل عقدة عامل النسخ المتماثل من كل شبكة عقدة هي نفسها بالضبط.
اليوم ، بدأت Ethereum في التخلص من النموذج حيث تخزن جميع العقد كل التاريخ بشكل دائم.يتم تخزين كتلة الإجماع (أي الجزء المتعلق بإثبات إجماع الحصة) لمدة 6 أشهر فقط.يتم تخزين النقط لمدة حوالي 18 يومًا فقط.تم تصميم EIP-4444 لتقديم فترة تخزين لمدة عام واحد للكتل التاريخية والإيصالات.الهدف طويل الأجل هو أن يكون لديك فترة منسقة (ربما حوالي 18 يومًا) ، حيث تكون كل عقدة مسؤولة عن تخزين كل شيء ، ثم هناك شبكة نظير إلى نظير من العقد الإثيرية التي تخزن البيانات القديمة بطريقة موزعة .
يمكن استخدام محو الترميز لتحسين المتانة مع الحفاظ على عامل النسخ المتماثل دون تغيير.في الواقع ، لدعم أخذ عينات توافر البيانات ، اعتمدت النقطات رموز المحو.قد يكون الحل الأسهل هو إعادة استخدام رمز المحو هذا ووضع بيانات التنفيذ والإجماع على البيانات في النقطة أيضًا.
ما الأبحاث المتوفرة؟
EIP-4444:https://eips.ethereum.org/eips/eip-4444
السيول و EIP-4444:https://ethreesear.ch/t/torrents-and-eip-4444/19788
شبكة البوابة:https://ethereum.org/en/developers/docs/networking-layer/portal-network/
شبكة البوابة و EIP-4444:https://github.com/ethereum/portal-network-specs/issues/308
تخزين واسترجاع كائنات SSZ في البوابة:https://ethreesear.ch/t/distributed-storage-and-crypticalicial-secured-retrival-of-sz-objects-for-portal-network/19575
كيفية زيادة حد الغاز (المعلمة):https://www.paradigm.xyz/2024/05/how-to-raise-the–gas-limit-2
ما هي الباقي وما هي المفاضلات الموجودة؟
يتضمن العمل الرئيسي المتبقي بناء ودمج حل موزع ملموس لتخزين السجل – على الأقل تاريخ التنفيذ ، ولكن في النهاية يشمل الإجماع والنقط.الحل الأسهل هو (1) ببساطة إدخال مكتبة التورنت الحالية ، و (2) حل أصلي Ethereum يسمى شبكة البوابة.بمجرد تقديم أي من هذه ، يمكننا تمكين EIP-4444.لا يتطلب EIP-4444 نفسها شوكة صلبة ، ولكنها تتطلب إصدارًا جديدًا من بروتوكول الشبكة.لذلك ، من المهم تمكينه لجميع العملاء في نفس الوقت ، لأنه قد يفشل العملاء بسبب الاتصال بالعقد الأخرى التي تتوقع تنزيل السجل الكامل ولكن لم يتم تنفيذها بالفعل.
تتضمن المفاضلة الرئيسية كيفية عملنا على إتاحة البيانات التاريخية “السابقة”.الحل الأسهل هو التوقف عن تخزين البيانات السابقة غدًا والاعتماد على العقد الأرشيف الحالية ومقدمي الخدمات المركزية المختلفة للتكرار.هذا أمر سهل ، لكنه يضعف موقف Ethereum كتسجيل بيانات دائمة.هناك نهج أصعب ولكنه أكثر أمانًا هو بناء ودمج شبكة التورنت أولاً لتخزين التاريخ بطريقة موزعة.هنا هناك بعدين:
-
ما مقدار الجهد الذي نحتاجه للتأكد من أن الحد الأقصى لعدد العقد يقوم بتخزين جميع البيانات؟
-
ما مدى عمقنا دمج التخزين التاريخي مع البروتوكولات؟
بالنسبة إلى (1) ، فإن النهج الأكثر صرامة قد ينطوي على دليل على الحضانة: في الواقع ، يلزم كل دليل على التحقق من الحصة لتخزين نسبة مئوية معينة من التاريخ والتحقق من ما إذا كان يفعل ذلك من خلال التشفير.تتمثل النهج الأكثر تواضعًا في وضع معيار طوعي للنسبة المئوية للتاريخ المخزن لكل عميل.
بالنسبة إلى (2) ، لا يتضمن التنفيذ الأساسي سوى ما تم القيام به اليوم: قام Portal بتخزين ملف ERA الذي يحتوي على تاريخ Ethereum بأكمله.قد يتضمن التنفيذ الأكثر شمولاً توصيله فعليًا بعملية التزامن بحيث إذا كان شخص ما يريد مزامنة عقدة تخزين التاريخ الكاملة أو عقدة الأرشيف ، حتى لو لم تكن عقد أرشيف أخرى على الإنترنت ، فيمكنهم القيام بذلك عن طريق المزامنة مباشرة من شبكة البوابة.
كيف تتفاعل مع بقية خريطة الطريق؟
إذا كنا نريد أن نجعل العقدة تعمل أو البدء بسيطة للغاية ، يمكن القول أن تقليل متطلبات التخزين التاريخية أكثر أهمية من عدم الجنسية: من بين 1.1 تيرابايت المطلوبة في العقدة ، حوالي 300 جيجابايت هي الحالة ، والبقاء حوالي 800 جيجابايت هو التاريخ.يتم تحقيق رؤية عقدة Ethereum التي تعمل على ساعة ذكية وإعدادها في بضع دقائق فقط إذا تم تحقيق عديمة الجنسية و EIP-4444 في وقت واحد.
إن الحد من التخزين التاريخي يجعل تطبيقات عقدة Ethereum الأحدث أكثر جدوى لدعم أحدث إصدارات البروتوكول فقط ، مما يجعلها أكثر بساطة.على سبيل المثال ، نظرًا لأن جميع فتحات التخزين الفارغة التي تم إنشاؤها خلال هجوم DOS 2016 قد تم حذفها ، يمكن حذف العديد من خطوط التعليمات البرمجية بأمان.الآن بعد أن يكون التحول إلى إثبات الحصة هو السجل ، يمكن للعميل حذف جميع التعليمات البرمجية بأمان المتعلقة بإثبات العمل.
انتهت بيانات الحالة
ما هي المشكلات التي يحلها؟
حتى إذا ألقينا الحاجة إلى سجل تخزين العميل ، فإن الطلب على تخزين العميل سيستمر في النمو ، حوالي 50 جيجابايت سنويًا ، حيث تستمر الدولة في النمو: أرصدة الحساب والأرقام العشوائية ورموز العقود وتخزين العقود.يمكن للمستخدمين دفع رسوم لمرة واحدة ، والتي ستضع دائمًا عبئًا على عملاء Ethereum الحاليين والمستقبليين.
من الصعب “انتهاء صلاحية” الحالة ، لأن افتراض التصميم الأساسي لـ EVM هو أنه بمجرد إنشاء كائن الدولة ، سيكون موجودًا إلى الأبد ويمكن قراءته بواسطة أي معاملة في أي وقت.إذا قدمنا عديمي الجنسية ، فإن بعض الأشخاص يعتقدون أن هذه المشكلة قد لا تكون بهذا السوء: يمكن فقط تشغيل فئة واحدة من شركات بناء الكتل المتخصصة تخزينًا فعليًا للحالة ، ويمكن أن تعمل جميع العقد الأخرى (حتى بما في ذلك توليد القائمة!) بلا جنسية.ومع ذلك ، يعتقد بعض الناس أننا لا نريد الاعتماد على الكثير من عدم الجنسية ، وفي النهاية قد نريد أن تنتهي الدولة للحفاظ على إلهاء Ethereum.
ما هذا؟كيف تعمل؟
اليوم ، عندما تقوم بإنشاء كائن حالة جديد (يمكن القيام به بإحدى الطرق الثلاث: (1) أرسل ETH إلى حساب جديد ، (2) إنشاء حساب جديد مع الكود ، (3) تم إعداده في السابق تخزينًا لم يمسها سابقًا) سيكون كائن الدولة دائمًا في تلك الحالة.بدلاً من ذلك ، ما نريده هو أن ينتهي الكائن تلقائيًا بمرور الوقت.التحدي الرئيسي هو القيام بذلك بطريقة تحقق ثلاثة أهداف:
-
كفاءة:لا يلزم وجود كمية كبيرة من الحساب الإضافي لتشغيل عملية انتهاء الصلاحية.
-
سهولة الاستخدام:إذا عاد شخص ما إلى خمس سنوات في الكهف ، فلا ينبغي أن يفقدوا الوصول إلى مواقع ETH و ERC20 و NFT و CDP …
-
الود المطور:لا يتعين على المطورين التبديل إلى نماذج التفكير غير المألوفة تمامًا.علاوة على ذلك ، يجب أن تستمر التطبيقات التي أصبحت الآن جامدة وغير مثيرة للقلق بشكل معقول.
دون تحقيق هذه الأهداف ، من السهل حل المشكلة.على سبيل المثال ، يمكنك أيضًا تخزين كل كائن دولة أيضًا عدادًا لتسجيل تاريخ انتهاء صلاحيته (والذي يمكن تمديده عن طريق تدمير ETH ، والذي يمكن أن يحدث تلقائيًا عند القراءة أو الكتابة) ، والحصول على حلقة من خلال الحالة لحذف حالة انتهاء الصلاحية عملية الكائن.ومع ذلك ، فإن هذا يقدم حسابًا إضافيًا (حتى متطلبات التخزين) وبالتأكيد لا يلبي متطلبات سهولة الاستخدام.من الصعب أيضًا على المطورين أن يتسببوا في الحالات القصوى التي تنطوي على قيم مخزنة في بعض الأحيان إلى الصفر.إذا قمت بتعيين مؤقت انتهاء الصلاحية في نطاق العقد ، فإن هذا من الناحية الفنية يجعل عمل المطور أسهل ، ولكن يجعل الاقتصاد أكثر صعوبة: يتعين على المطورين التفكير في كيفية “تمرير” تكاليف التخزين المستمرة لمستخدميهم.
هذه هي القضايا التي يعمل عليها مجتمع Ethereum Core Development Community بجد لحلها لسنوات ، بما في ذلك مقترحات مثل “Blockchain Rental” و “Regeneration”.في النهاية ، نجمع بين أفضل أجزاء الاقتراح والتركيز على فئتين من “الحلول الأقل السيئة المعروفة”:
-
بعض حلول انتهاء صلاحية الدولة.
-
اقتراح انتهاء صلاحية الدولة بناءً على دورة العنوان.
انتهت بعض الحالة
تتبع بعض مقترحات انتهاء صلاحية الدولة نفس المبادئ.نقسم الدولة إلى قطع.يخزن الجميع بشكل دائم “الخريطة ذات المستوى الأعلى” والتي تكون الكتل فارغة أو غير فارغة.يتم تخزين البيانات الموجودة في كل كتلة فقط إذا تمت زيارتها مؤخرًا.هناك آلية “قيامة” حيث لم تعد هناك كتلة مخزنة ، يمكن لأي شخص استعادة تلك البيانات من خلال تقديم دليل على ما هو عليه.
الاختلافات الرئيسية بين هذه المقترحات هي: (1) كيف نحدد “مؤخرًا” ، و (2) كيف نحدد “الكتل”؟اقتراح محدد هو EIP-7736 ، والذي يعتمد على تصميم “الجذعية والأوراق” التي تم تقديمها لأشجار Verkle (على الرغم من أنها متوافقة مع أي شكل من أشكال الأشجار عديمية ، مثل الأشجار الثنائية).في هذا التصميم ، يتم تخزين الرؤوس والرموز وفتحات التخزين المتاخمة لبعضها البعض تحت نفس “الجذع”.يمكن أن تصل البيانات المخزنة تحت الساق إلى 256 * 31 = 7،936 بايت.في كثير من الحالات ، سيتم تخزين العنوان بالكامل ورمز الحساب ، بالإضافة إلى العديد من فتحات التخزين الرئيسية ، تحت نفس العمود الفقري.إذا لم تتم قراءة أو كتابة البيانات الموجودة تحت عنوان Backbone معين في غضون 6 أشهر ، فإن البيانات لم تعد مخزنة ، ولكن فقط الالتزام 32 بايت بالبيانات (“كعب”).ستتطلب المعاملات المستقبلية الوصول إلى هذه البيانات “إحياء” البيانات وتقديم دليل على التحقق من كعب الكعب.
هناك طرق أخرى لتنفيذ أفكار مماثلة.على سبيل المثال ، إذا لم يكن فاصل الحساب كافيًا ، فيمكننا تطوير خطة حيث يتم التحكم في كل جزء من الشجرة من الشجرة بواسطة آلية ساق وورقة مماثلة.
هذا أكثر صعوبة بسبب العوامل التحفيزية: يمكن للمهاجم “تحديث الشجرة” عن طريق وضع كمية كبيرة من البيانات في شجرة فرعية واحدة وإرسال معاملة واحدة كل عام ، مما يجبر العميل على تخزين كمية كبيرة من الحالة بشكل دائم.إذا جعلت تكلفة التحديث تتناسب مع حجم الشجرة (أو مدة التحديث تتناسب عكسيا مع حجم الشجرة) ، فقد يؤذي شخص ما مستخدمًا آخر عن طريق وضع الكثير من البيانات في نفس الشجرة الفرعية.يمكنك محاولة الحد من هاتين المسألتين من خلال تنظيم فترات الحساب ديناميكيًا استنادًا إلى حجم الشجرة الفرعية: على سبيل المثال ، يمكن التعامل مع كل كائنات الحالة 2^16 = 65536 على أنها “مجموعة”.ومع ذلك ، فإن هذه الأفكار أكثر تعقيدًا ؛
اقتراح انتهاء صلاحية الدولة بناءً على دورة العنوان
ماذا لو أردنا تجنب أي نمو دائم للدولة تمامًا ، حتى كعب 32 بايت؟فيما يلي لغز: ماذا لو تم حذف كائن الحالة ، وبعد ذلك ، يضع تنفيذ EVM كائنًا آخر في الحالة في نفس الموقف بالضبط ، ولكن بعد ذلك الشخص الذي يهتم بكائن الحالة الأصلي يعود ويحاول استعادته؟لبعض انتهاء صلاحية الدولة ، يمنع كعب البيانات من إنشاء البيانات الجديدة.من أجل انتهاء صلاحية الحالة الكاملة ، لا يمكننا حتى تخزين كبار السن.
يعد التصميم المستند إلى دورة العنوان هو أفضل طريقة لحل هذه المشكلة.بدلاً من تخزين الدولة بأكملها بشجرة الدولة ، لدينا قائمة متزايدة من أشجار الدولة ، ويتم حفظ أي حالات قراءة أو مكتوبة في أحدث شجرة الدولة.أضف شجرة حالة فارغة جديدة في كل دورة (فكر: سنة واحدة).يتم إصلاح أشجار الدولة القديمة.تحتاج العقدة الكاملة فقط إلى تخزين أقرب شجرتين.إذا لم يتم لمس كائن الحالة في دورتين وبالتالي يقع في الشجرة المنتهية الصلاحية ، فلا يزال من الممكن قراءته أو كتابته ، ولكن المعاملة تحتاج إلى إثبات وجود دليل على Merkle – بمجرد الانتهاء ، سيتم حفظ النسخة مرة أخرى في أحدث شجرة .
الفكرة الرئيسية لجعل كل هذا الأمر سهلاً للمستخدم والمطور هو مفهوم دورات العنوان.دورة العنوان عبارة عن رقم جزء من العنوان.القاعدة الرئيسية هي أن العناوين مع فترة العنوان لا يمكن قراءتها أو كتابتها إلا خلال الفترة N (أي عندما تصل قائمة شجرة الحالة إلى الطول N).إذا كنت ترغب في حفظ كائن حالة جديد (على سبيل المثال ، عقد جديد أو رصيد جديد ERC20) ، إذا كنت تتأكد مباشرة دون تقديم أي دليل على أي شيء من قبل.من ناحية أخرى ، يتطلب أي إضافة أو تحرير دولة في دورة العنوان القديمة إثباتًا.
يحتفظ هذا التصميم بمعظم خصائص Ethereum الحالية ، مع حساب إضافي صغير جدًا ، مما يسمح لكتابة التطبيقات تقريبًا كما هي الآن (يجب إعادة كتابة ERC20 للتأكد الفترة N) وحل مشكلة “المستخدم الذي يدخل الكهف لمدة خمس سنوات”.ومع ذلك ، فإنه لديه مشكلة كبيرة:يجب توسيع العنوان إلى أكثر من 20 بايت لتناسب دورة العنوان.
العنوان تمديد مساحة
يتمثل أحد الاقتراحات في تقديم تنسيق جديد 32 بايت يتضمن رقم الإصدار ورقم فترة العنوان وقيمة التجزئة الموسعة.
0x01000000000157AE408398DF7E55552091A69125D5DFCB7B8C2659029395BDF
الأحمر هو رقم الإصدار.هنا تمثل الأصفار البرتقالية الأربعة مساحات فارغة ويمكنها استيعاب أرقام قشور في المستقبل.الأخضر هو رقم فترة العنوان.الأزرق هو تجزئة 26 بايت.
التحدي الرئيسي هنا هو التوافق المتخلف.تم تصميم العقود الحالية حول العنوان 20 بايت وغالبًا ما يتم استخدامها مع تقنيات تغليف بايت ضيقة ، مما يوضح أن العنوان يبلغ طوله 20 بايت.تتمثل إحدى الأفكار لحل هذه المشكلة في استخدام رسم بياني للتحول حيث سيشهد عقد على الطراز القديم الذي يتفاعل مع عنوان على الطراز الجديد تجزئة 20 بايت للعنوان على الطراز الجديد.ومع ذلك ، فإنه يتطلب جهدا كبيرا لضمان سلامتها.
معالجة تقلص المساحة
في الاتجاه الآخر: نقوم على الفور بتعطيل بعض العنوان الفرعي لحجم 2128 (مثل جميع العناوين التي تبدأ بـ 0xffffffff) ، ثم نستخدم هذا النطاق لإدخال عناوين مع فترات العناوين و 14 بايت.
0xffffffff000169125d5dfcb7b8c2659029395bdf
التضحية الرئيسية لهذا النهج هي أنه يقدم مخاطر أمنية للعناوين المضادة للضرب: العناوين التي تحمل الأصول أو الأذونات ولكن لم يتم نشر رمزها على السلسلة.يتضمن المخاطر شخصًا يقوم بإنشاء عنوان يدعي أنه يحتوي على رمز (لم ينشر بعد) ، ولكن هناك رمز آخر صالح مع قيمة التجزئة التي تشير إلى نفس العنوان.يتطلب حساب هذه التصادمات اليوم 280 تجزئة.
تعد منطقة المخاطر الحاسمة ، وليس العنوان المضاد للمحفظة التي يحتفظ بها مالك واحد ، وضعًا نادرًا نسبيًا اليوم ، ولكن مع دخولنا إلى العالم متعدد L2 ، قد يصبح هذا الموقف أكثر شيوعًا.الحل الوحيد هو قبول هذا الخطر ببساطة ، ولكن تحديد جميع حالات الاستخدام الشائعة التي قد تنشأ فيها المشكلات والتوصل إلى حلول فعالة.
ما الأبحاث المتوفرة؟
المقترحات المبكرة
رسوم تأجير blockchain:https://github.com/ethereum/eips/issues/35
نظرية إدارة حجم حالة Ethereum:https://hackmd.io/@vbuterin/state_size_management
العديد من المسارات الممكنة لعدم الجنسية وإنهاء صلاحية الدولة:https://hackmd.io/@vbuterin/state_expiry_paths
بعض مقترحات انتهاء صلاحية الحالة
EIP-7736:https://eips.ethereum.org/eips/eip-7736
العنوان الوثيقة الموسعة للمساحة
الاقتراح الأصلي:https://ethereum-magicians.org/t/incring-address-size-from-20-to-32-bytes/5485
تعليقات Ipsilon:https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
تعليقات نشر المدونة:https://medium.com/@chaisomsri96/stateless-series-part2-ase-asddress-space-extense-60626544b8e6
ماذا يحدث إذا فقدنا مقاومة الاصطدام:https://ethreesear.ch/t/what-would-break-if-we-lose-address-collision-drainistant/11356
ماذا تبقى ليفعل؟ماذا تزن؟
أعتقد أن هناك أربعة مسارات قابلة للحياة في المستقبل:
-
نحن نمارس عدم الإحباط وعدم تقديم انتهاء صلاحية الدولة.تتزايد الدولة (على الرغم من أبطأ: قد لا نراها أكثر من 8 تيرابايت منذ عقود) ، ولكن يجب الاحتفاظ بها فقط من قبل فئات المستخدمين المحترفين نسبيًا: حتى صحة نقاط البيع لا يحتاجون إلى حالة.
ميزة واحدة تتطلب الوصول إلى الحالة الجزئية هي تضمين توليد القائمة ، ولكن يمكنناتنفيذ هذا بطريقة لا مركزية:كل مستخدم مسؤول عن الحفاظ على جزء شجرة الحالة الذي يحتوي على حسابه الخاص.عندما يبثون المعاملات ، يقومون ببث دليل على كائن الحالة الذي يتم الوصول إليه أثناء خطوة التحقق (وهذا ينطبق على حسابات EOA و ERC-4337).يمكن للمقحة عديمة الجنسية بعد ذلك الجمع بين هذه الأدلة في الدليل بالكامل الذي يحتوي على القائمة.
-
نحن ننفذ انتهاء صلاحية الحالة الجزئية ونقبل معدل نمو حجم الدولة الدائم ولكن لا يزال غير صفري.قد تكون هذه النتيجة مشابهة لمقترح انتهاء الصلاحية التاريخي الذي يشتمل على شبكات نظير إلى نظير ، والذي يقبل معدل نمو تاريخي دائم للتخزين الذي يجب على كل عميل تخزينه بنسبة مئوية أقل ولكن الثابتة من البيانات التاريخية ، ولكنه أقل بكثير ، ولكنه لم يكن صفرًا.
-
نعلن تاريخ انتهاء الصلاحية وتوسيع مساحة العنوان.سيتضمن ذلك عملية متعددة السنوات لضمان أن تكون طرق تحويل تنسيق العنوان فعالة وآمنة ، بما في ذلك التطبيقات الحالية.
-
لقد أعلننا تاريخ انتهاء الصلاحية وتقليص مساحة العنوان.سيتضمن ذلك عملية متعددة السنوات لضمان معالجة جميع المخاطر الأمنية التي تنطوي على تعارضات العنوان ، بما في ذلك المواقف عبر السلسلة.
النقطة المهمة هي أنه سواء تم تنفيذ مخطط انتهاء صلاحية الدولة الذي يعتمد على تغييرات تنسيق العنوان أم لا ، يجب في نهاية المطاف حل مشكلة توسيع مساحة العنوان والانكماش.اليوم ، هناك حاجة إلى حوالي 2^80 تجزئة لإنشاء تعارضات عناوين ، وهذا الحمل الممكنة بالفعل للمشاركين الغنيين بالموارد: يمكن لـ GPU القيام بحوالي 2^27 ، بحيث يمكن تشغيلها لمدة عام يتم حسابها ، لذلك يمكن لحوالي 2^30 وحدات معالجة الرسومات في العالم حساب النزاعات في حوالي 1/4 من العام ، ويمكن لـ FPGAs و ASIC أن يزيد من تسريع هذه العملية.في المستقبل ، ستكون هذه الهجمات مفتوحة لمزيد من الناس.لذلك ، قد لا تكون التكلفة الفعلية لتنفيذ انتهاء صلاحية الحالة الكاملة مرتفعة كما يبدو ، كما يتعين علينا حل مشكلة العنوان الصعبة للغاية على أي حال.
كيف تتفاعل مع بقية خريطة الطريق؟
قد يؤدي تنفيذ انتهاء صلاحية الحالة إلى جعل التحويل من تنسيق شجرة الحالة إلى أخرى أسهل لأنه لا توجد حاجة لعملية التحويل: يمكنك ببساطة البدء في صنع شجرة جديدة بتنسيق جديد ثم تصلبها لاحقًا لتحويل الشجرة القديمة.لذلك على الرغم من أن انتهاء صلاحية الدولة معقد ، إلا أنه يساعد في تبسيط الجوانب الأخرى لخريطة الطريق.
التنظيف الوظيفي
ما هي المشكلات التي يحلها؟
أحد المتطلبات الأساسية للأمن وسهولة الوصول والجدارة بالثقة هو البساطة.إذا كان البروتوكول جميلًا وبسيطًا ، يتم تقليل إمكانية وجود أخطاء.يزيد من فرصة أن يتمكن المطورون الجدد من الانضمام إلى أي جزء منه واستخدامه.من المرجح أن تكون عادلة ومن المرجح أن تقاوم المصالح الخاصة.لسوء الحظ ، تصبح البروتوكولات ، مثل أي نظام اجتماعي ، أكثر تعقيدًا بشكل افتراضي مع مرور الوقت.إذا لم نرغب في الحصول على ثقب أسود معقد بشكل متزايد ، فنحن بحاجة إلى القيام بأحد أمرين:(1) توقف عن إجراء التغييرات وتصلب البروتوكول ، (2) تكون قادرة على إزالة الميزات وتقليل التعقيد.الطرق المتوسطة ، أي إجراء تغييرات أقل على البروتوكول مع القضاء على القليل من التعقيد على الأقل مع مرور الوقت ، من الممكن أيضًا.يناقش هذا القسم كيفية تقليل التعقيد أو القضاء عليه.
ما هذا؟كيف تعمل؟
لا يوجد حل كبير يقلل من تعقيد البروتوكول.
مثال تم إنجازه بشكل أساسي يمكن استخدامه كمخطط لكيفية التعامل مع المشكلات الأخرى ، أي حذف رمز Opcode ذاتيًا.رمز OPCODE SELFDERSTRUCT هو الرمز OPCODE الوحيد الذي يمكنه تعديل عدد غير محدود من فتحات التخزين داخل كتلة واحدة ، مما يتطلب تعقيدًا أكبر من العملاء لتجنب هجمات DOS.الغرض الأصلي من هذا الرمز opcode هو تحقيق تطوع الحالة الطوعية ، مما يسمح لحجم الدولة بالانخفاض بمرور الوقت.في الواقع ، ينتهي قلة من الناس باستخدامه.يتم إضعاف رمز opcode ، مما يسمح فقط بحسابات التدمير الذاتي التي تم إنشاؤها في نفس المعاملة في شوكة Dencun الصلبة.هذا يحل مشكلات DOS ويسمح بتبسيط كبير لرمز العميل.في المستقبل ، قد يكون من المنطقي إزالة الرمز البسيط تمامًا.
بعض الأمثلة الرئيسية لفرص تبسيط البروتوكول المحددة حتى الآن تشمل ما يلي.أولاً ، بعض الأمثلة خارج EVM ؛
-
RLP → تحويل SSZ:في البداية ، تم تسلسل كائنات Ethereum باستخدام ترميز يسمى RLP.اليوم ، تستخدم سلاسل المنارة SSZ ، والتي هي أفضل بكثير من نواح كثيرة ، بما في ذلك ليس فقط دعم التسلسل ولكن أيضًا التجزئة.في النهاية ، نريد التخلص من RLP تمامًا ونقل جميع أنواع البيانات إلى بنية SSZ ، مما يجعل الترقية بشكل أسهل.تشمل EIPs المقترحة حاليًا لهذا [1] [2] [3].
-
حذف أنواع المعاملات القديمة:هناك العديد من أنواع المعاملات اليوم ، وقد يتم حذف الكثير منها.البديل الأكثر تواضعًا للحذف بالكامل هو ميزة تجريد الحساب ، والتي يمكن من خلالها تحتوي الحسابات الذكية على رموز لمعالجة المعاملات القديمة والتحقق منها (إذا كانت ترغب في ذلك).
-
إصلاح السجل:تقوم السجلات بإنشاء مرشحات بلوم وغيرها من المنطق ، مما يضيف التعقيد إلى البروتوكول ، ولكن لأنه بطيء للغاية ، فإن العميل لا يستخدمه بالفعل.يمكننا إزالة هذه الميزات وبدلاً من ذلك تخصيص طاقتنا للبدائل ، مثل أدوات قراءة السجل اللامركزية خارج البروتوكول باستخدام التقنيات الحديثة مثل Snark.
-
أخيرًا ، سيتم إلغاء آلية لجنة مزامنة سلسلة المنارة:تم تقديم آلية لجنة التزامن في الأصل لتمكين مصادقة عميل الضوء من أجل Ethereum.ومع ذلك ، فإنه يضيف تعقيد البروتوكول.في نهاية المطاف ، سنكون قادرين على استخدام Snark للتحقق مباشرة من طبقة إجماع Ethereum مباشرة ، والتي ستزيل الحاجة إلى بروتوكول التحقق من عميل الضوء المخصص.من خلال إنشاء بروتوكول عميل أكثر “أصليًا” يتضمن التحقق من صحة التوقيعات من مجموعة فرعية عشوائية من مدقق إجماع Ethereum.
-
تنسيق تنسيق البيانات:اليوم ، يتم تخزين حالة التنفيذ في شجرة Merkle Patricia ، ويتم تخزين حالة الإجماع في شجرة SSZ ، ويتم تقديم النقط كما وعدت KZG.في المستقبل ، من المنطقي إنشاء تنسيق موحد واحد لبيانات الكتلة والحالة.ستغطي هذه التنسيقات جميع الاحتياجات المهمة: (1) دليل بسيط على العملاء عديمي الجنسية ، (2) التسلسل وترميز البيانات ، و (3) هياكل البيانات الموحدة.
-
حذف لجنة سلسلة منارة:تم تقديم هذه الآلية في البداية لدعم إصدارات محددة من شد التنفيذ.بدلاً من ذلك ، ينتهي بنا المطاف بالتشويش من خلال L2 و Blob.لذلك ، فإن اللجنة غير ضرورية وتعمل على إزالتها.
-
حذف ترتيب بايت مختلط:EVM هو أمر بايت كبير ، وطبقة الإجماع هي أمر بايت صغير.قد يكون من المنطقي إعادة الإحداثيات وجعل كل شيء كبير إنديان إنديان كبير (ربما يكون ENDIAN الكبير ، حيث يصعب تغيير EVM).
الآن ، بعض الأمثلة داخل EVM:
-
تبسيط آلية الغاز:لم يتم تحسين قواعد الغاز الحالية جيدًا بعد ، ومن المستحيل الحد من عدد الموارد المطلوبة بشكل صريح للتحقق من الكتلة.تتضمن أمثلة رئيسية على ذلك (1) تكاليف القراءة/الكتابة للتخزين ، المصممة للحد من أوقات القراءة/الكتابة في كتلة ، ولكنها حاليًا تعسفية للغاية ، و (2) قواعد تعبئة الذاكرة ، والتي يصعب حاليًا تقديرها لأقصى قدر من استهلاك الذاكرة للذاكرة و EVM.تشمل الإصلاحات الموصى بها تغييرات في تكلفة الغاز عديمة الجنسية ، والتوفيق بين جميع التكاليف المتعلقة بالتخزين في صيغة بسيطة ، وتوصيات تسعير الذاكرة.
-
قم بإزالة التجميع المسبق:العديد من الموهجات المسبقة التي لدى Ethereum اليوم غير ضرورية وغير مستخدمة نسبيًا ، وتفسير نسبة كبيرة من مخاطر فشل الإجماع ، ولكنها لا تستخدمها أي تطبيق بالفعل.طريقتان للتعامل مع هذه المشكلة هما (1) إزالة مباشرة من الإلغاء ، و (2) استبدالها برمز EVM (وأكثر تكلفة) حتماً) التي تنفذ نفس المنطق.يوصي مسودة EIP بفعل ذلك أولاً للهوية.
-
قم بإزالة قابلية الملاحظة للغاز:يجعل تنفيذ EVM قادرًا على معرفة مقدار الغاز الذي تركه.هذا يكسر بعض التطبيقات (الأكثر برعاية الصفقات) ، ولكن يمكن ترقيتها بسهولة أكبر في المستقبل (على سبيل المثال ، لإصدارات الغاز متعددة الأبعاد أكثر تقدمًا).لقد جعلت مواصفات EOF الغاز غير قابل للملاحظة ، ولكن لتسهيل تبسيط البروتوكول ، يجب أن يكون EOF إلزاميًا.
-
تحسينات في التحليل الثابت:من الصعب إجراء رمز EVM اليوم تحليلًا ثابتًا ، خاصة وأن القفزات يمكن أن تكون ديناميكية.هذا أيضًا يجعل من الصعب إنشاء تطبيق EVM محسّن (رمز EVM precompile إلى لغات أخرى).يمكننا حل هذه المشكلة عن طريق إزالة القفزات الديناميكية (أو جعلها أكثر تكلفة ، على سبيل المثال ، ترتبط تكاليف الغاز خطيًا بإجمالي عدد القفزات في العقد).هذا ما يفعله EOF ، لكن الحصول على فوائد تبسيط البروتوكول منه يتطلب جعل EOF إلزاميًا.
ما الأبحاث المتوفرة؟
الخطوات التالية للتطهير:https://notes.ethereum.org/i_aihysjttcyau_adoy2ta
تدمير الذات:https://hackmd.io/@vbuterin/selfdestruct
SSZ-IPORING EIPS: [1] [2] [3]
تغييرات تكلفة الغاز عديمة الجنسية:https://eips.ethereum.org/eips/eip-4762
تسعير الذاكرة الخطية:https://notes.ethereum.org/ljptsqbgr2knssu0yurwxw
مسبق وحذفه:https://notes.ethereum.org/iwtx222ymqde1k_fz9psxig
إزالة مرشح بلوم:https://eips.ethereum.org/eips/eip-7668
