أحد التحديات التي تواجه إثيريوم هو أن ازدحام وتعقيد بروتوكول سلسلة الكتل الافتراضي يزداد مع مرور الوقت. يحدث هذا في مكانين:

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

لكي تحافظ Ethereum على نفسها على المدى الطويل ، نحتاج إلى ضغط مضاد قوي ضد كلا الاتجاهين ، مما يقلل من التعقيد والانتفاخ بمرور الوقت. ولكن في الوقت نفسه ، نحتاج إلى الحفاظ على إحدى الخصائص الرئيسية التي تجعل سلاسل الكتل رائعة: ديمومتها. يمكنك وضع NFT ، أو ملاحظة حب في بيانات مكالمات المعاملات ، أو عقد ذكي يحتوي على مليون دولار onchain ، أو الذهاب إلى كهف لمدة عشر سنوات ، والخروج والعثور عليه لا يزال هناك في انتظارك للقراءة والتفاعل معه. لكي تشعر dapps بالراحة في العمل اللامركزي بالكامل وإزالة مفاتيح الترقية الخاصة بها ، يجب أن تكون واثقة من أن تبعياتها لن تقوم بالترقية بطريقة تكسرها - خاصة L1 نفسها.

التطهير ، خريطة الطريق 2023.

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

التطهير: الأهداف الرئيسية

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

في هذا الفصل

• تاريخ انتهاء الصلاحية
• انتهاء الحالة
• تنظيف الميزات

تاريخ انتهاء الصلاحية

ما المشكلة التي يحلها؟

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

ما هو، وكيف يعمل؟

الميزة الرئيسية المبسطة لمشكلة تخزين المحفوظات هي أنه نظرا لأن كل كتلة تشير إلى الكتلة السابقة عبر رابط تجزئة (و آخرهياكل، والحصول على اتفاق في الوقت الحاضر يكفي للحصول على اتفاق في التاريخ. طالما أن الشبكة لديها اتفاق على الكتلة الأخيرة، يمكن توفير أي كتلة أو معاملة أو حالة تاريخية (رصيد الحساب، رقم عشوائي، رمز، تخزين) من قبل أي فاعل واحد جنبًا إلى جنب مع دليل Merkle، ويسمح الدليل لأي شخص آخر بالتحقق من صحته. في حين أن الاتفاق هو نموذج ثقة N/2-of-N، فإن التاريخ هو نموذج الثقة 1 من N.

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

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

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

ما هي بعض الروابط إلى الأبحاث الموجودة؟

• EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
• تورنت وEIP-4444: https://ethresear.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://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575
• كيفية زيادة حد الغاز (بارادايم):https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

ما الذي تبقى للقيام به وما هي التنازلات؟

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

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

1. ما مدى صعوبتنا في التأكد من أن مجموعة كبيرة بشكل قصوى من العقد تخزن حقًا جميع البيانات؟
2. إلى أي مدى ندمج التخزين التاريخي في البروتوكول؟

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

بالنسبة إلى (2) ، يتضمن التنفيذ الأساسي مجرد أخذ العمل الذي تم إنجازه بالفعل اليوم: يقوم Portal بالفعل بتخزين ملفات ERA التي تحتوي على سجل Ethereum بالكامل. قد يتضمن التنفيذ الأكثر شمولا ربط هذا فعليا بعملية المزامنة ، بحيث إذا أراد شخص ما مزامنة عقدة تخزين كاملة للمحفوظات أو عقدة أرشيف ، فيمكنه القيام بذلك حتى في حالة عدم وجود عقد أرشيف أخرى عبر الإنترنت ، عن طريق المزامنة مباشرة من شبكة البوابة.

كيف يتفاعل مع أجزاء أخرى من خريطة الطريق؟

تقليل متطلبات تخزين التاريخ أهم حتى من عدم الحالة إذا كنا نريد جعل تشغيل العقدة أو تشغيلها سريعًا للغاية أمرًا سهلاً: من الـ 1.1 تيرابايت التي تحتاج العقدة إلى الحصول عليها، تعد الحالة بحوالي 300 جيجابايت، والـ 800 جيجابايت المتبقية هي التاريخ. رؤية عقدة إثيريوم تعمل على ساعة ذكية وتستغرق بضع دقائق فقط للإعداد يمكن تحقيقها فقط إذا تم تنفيذ عدم الحالة و EIP-4444.

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

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

ما المشكلة التي يحلها؟

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

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

ما هو ذلك وكيف يعمل؟

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

1. الكفاءة: لا تتطلب كميات ضخمة من الحسابات الإضافية لتشغيل عملية الانتهاء
2. سهولة الاستخدام: إذا دخل شخص ما إلى كهف لمدة خمس سنوات وعاد، فلا ينبغي أن يفقد وصوله إلى إيثريوم، العملات الرقمية القابلة للتبادل (ERC20s)، العملات الرمزية غير القابلة للتداول (NFTs)، مواقع CDP...
3. ملاءمة المطور: يجب ألا يضطر المطورون إلى التبديل إلى نموذج عقلي غير مألوف تماما. بالإضافة إلى ذلك ، يجب أن تستمر التطبيقات المتحجرة اليوم ولا يتم تحديثها في العمل بشكل جيد.

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

هذه المشاكل التي كانت تعاني منها مجتمع تطوير النواة الإثيريوم لسنوات عديدة، بما في ذلك مقترحات مثلإيجار سلسلة الكتل“ و “regenesisفي نهاية المطاف، جمعنا أفضل أجزاء الاقتراحات وتوصلنا إلى فئتين من "أسوأ الحلول المعروفة":

• حلول انتهاء جزئي للحالة
• مقترحات انتهاء الحالة بناءً على فترة العنوان.

انتهاء صلاحية الحالة الجزئي

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

أهم التمييزات بين هذه المقترحات هي: (أ) كيف نحدد "مؤخرًا"، و (ب) كيف نحدد "قطعة"؟ أحد المقترحات الملموسة هو EIP-7736، الذي يعتمد على تصميم "الساق والورقة" تم تقديمها لأشجار فيركل (على الرغم من توافقها مع أي شكل من أشكال انعدام الجنسية ، مثل الأشجار الثنائية). في هذا التصميم ، يتم تخزين فتحات الرأس والتعليمات البرمجية والتخزين المجاورة لبعضها البعض تحت نفس "الجذع". يمكن أن تكون البيانات المخزنة تحت جذع على الأكثر 256 * 31 = 7,936 بايت. في كثير من الحالات ، سيتم تخزين الرأس والرمز بالكامل ، والعديد من فتحات التخزين الرئيسية ، للحساب تحت نفس الجذع. إذا لم تتم قراءة البيانات الموجودة تحت جذع معين أو كتابتها لمدة 6 أشهر ، فلن يتم تخزين البيانات بعد ذلك ، وبدلا من ذلك يتم تخزين التزام 32 بايت فقط ("كعب روتين") بالبيانات. ستحتاج المعاملات المستقبلية التي تصل إلى تلك البيانات إلى "إحياء" البيانات ، مع دليل سيتم التحقق منه مقابل كعب الروتين.

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

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

مقترحات انتهاء الحالة على أساس العنوان الزمني

ماذا لو أردنا تجنب أي نمو دائم للحالة تمامًا، حتى 32 بايتا من القوالب؟ هذه مشكلة صعبة بسبب @vbuterin/ state_size_management # صراعات القيامة "> صراعات القيامة: ماذا لو تمت إزالة كائن حالة ، فإن تنفيذ EVM لاحقا يضع كائن حالة آخر في نفس الموضع بالضبط ، ولكن بعد ذلك يعود شخص يهتم بكائن الحالة الأصلي ويحاول استعادته؟ مع انتهاء صلاحية الحالة الجزئي ، يمنع "كعب الروتين" إنشاء بيانات جديدة. مع انتهاء صلاحية الدولة بالكامل ، لا يمكننا تخزين حتى كعب الروتين.

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

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

يحافظ هذا التصميم على معظم خصائص Ethereum الحالية ، وهو خفيف جدا على الحساب الإضافي ، ويسمح بكتابة التطبيقات كما هي اليوم تقريبا (ستحتاج ERC20s إلى إعادة الكتابة ، لضمان تخزين أرصدة العناوين مع فترة العنوان N في عقد فرعي يحتوي في حد ذاته على فترة عنوان N) ، ويحل مشكلة "المستخدم يذهب إلى كهف لمدة خمس سنوات". ومع ذلك ، فإن لديها مشكلة واحدة كبيرة: يجب توسيع العناوين إلى ما بعد 20 بايت لتناسب فترات العناوين.

تمديد مساحة العنوان

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

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

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

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

انكماش مساحة العنوان

يتبع نهج معاكس: نحظر على الفور بعض النطاق الفرعي بحجم 2128 عناوين (على سبيل المثال، جميع العناوين التي تبدأ ب 0xffffffff)، ثم نستخدم هذا النطاق لإدخال عناوين مع فترات عناوين وتجزئة بحجم 14 بايت.

0xfffffff000169125d5dFcb7B8C2659029395bdF

التضحية الرئيسية التي يقوم بها هذا النهج هي أنها يُدخِل مخاطر أمنية للعناوين المضادة التصورية: العناوين التي تحمل أصولًا أو أذونات، لكن لم يتم نشر كودها حتى الآن على السلسلة. ينطوي المخاطر على شخص ما يقوم بإنشاء عنوان يدعي أن لديه قطعة واحدة من الكود (الذي لم يتم نشره بعد)، ولكنه أيضًا يحتوي على قطعة أخرى صالحة من الكود التي تجعلها تؤشر إلى نفس العنوان. يتطلب حساب مثل هذا الاصطدام 2⁸⁰التجزئة اليومية؛ انكماش مساحة العنوان سيقلل هذا الرقم إلى 2 قابلة للوصول جداً⁵⁶التجزئة.

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

ما هي بعض الروابط للأبحاث الحالية؟

• مقترحات مبكرة
  • إيجار البلوكشين: https://github.com/إثيريوم/EIPs/issues/35
  • إعادة التكوين:https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582
• نظرية إدارة حجم حالة إثيريوم:@vbuterin/state_size_management"">https://hackmd.io/@vbuterin/state_size_management
• بعض المسارات الممكنة لانعدام الجنسية وانتهاء صلاحية الدولة: @vbuterin/state_expiry_paths"">https://hackmd.io/@vbuterin/state_expiry_paths
• مقترحات انتهاء الحالة الجزئي
  • EIP-7736: https://eips.ethereum.org/EIPS/eip-7736
• مستندات توسيع مساحة العنوان
  • المقترح الأصلي: https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
  • مراجعة ايبسيلون: @ipsilon/address-space-extension-exploration"">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
  • مراجعة منشور المدونة: @chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6">https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6
• ما الذي سيتعطل إذا فقدنا مقاومة التصادم:https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

ما الذي تبقى للقيام به، وما هي التنازلات؟

أرى أربعة مسارات ممكنة للمستقبل:

• نقوم بعدم وجود حالة، ولا نقوم بتقديم انتهاء الحالة. تزداد الحالة باستمرار (على الرغم من ببطء: قد لا نراها تتجاوز 8 تيرابايت لعقود)، ولكنها تحتاج إلى أن تكون محتفظة بواسطة فئة متخصصة نسبيًا من المستخدمين: حتى المحققين PoS لن يحتاجوا إلى الحالة.
  \
  الوظيفة الوحيدة التي تحتاج إلى الوصول إلى أجزاء من الولاية هي إنتاج قائمة التضمين ، ولكن يمكننا تحقيق ذلك بطريقة لامركزية: كل مستخدم مسؤول عن الحفاظ على جزء من شجرة الولاية الذي يحتوي على حساباته الخاصة. عندما يبثون معاملة ، يقومون ببثها مع إثبات كائنات الحالة التي تم الوصول إليها أثناء خطوة التحقق (يعمل هذا مع كل من حسابات EOAs و ERC-4337). يمكن للمدققين عديمي الجنسية بعد ذلك دمج هذه البراهين في إثبات لقائمة التضمين بأكملها.
• نحن نقوم بانتهاء صلاحية جزئي للحالة ، ونقبل معدلا أقل بكثير ولكنه لا يزال غير صفري لنمو حجم الدولة الدائم. يمكن القول إن هذه النتيجة تشبه الطريقة التي تقبل بها مقترحات انتهاء صلاحية التاريخ التي تتضمن شبكات نظير إلى نظير معدلا أقل بكثير ولكنه لا يزال غير صفري لنمو تخزين التاريخ الدائم من كل عميل يضطر إلى تخزين نسبة منخفضة ولكن ثابتة من البيانات التاريخية.
• نقوم بإنهاء الحالة ، مع توسع مساحة العنوان. سيتضمن ذلك عملية متعددة السنوات للتأكد من أن طريقة تحويل تنسيق العنوان تعمل وآمنة ، بما في ذلك للتطبيقات الحالية.
• نحن نقوم بتاريخ انتهاء الصلاحية، مع ضيق مساحة العنوان. سينطوي هذا على عملية متعددة السنوات للتأكد من التعامل مع جميع مخاطر الأمان المتعلقة بتعارض العناوين، بما في ذلك الحالات العابرة للسلاسل.

نقطة مهمة واحدة هي أن المسائل الصعبة المتعلقة بتوسيع وانكماش مساحة العناوين ستحتاج في النهاية إلى أن تُعالج بغض النظر عما إذا تم تنفيذ برامج انتهاء الصلاحية الحالية التي تعتمد على تغييرات تنسيق العناوين أم لا. اليوم، يستغرق حوالي 2⁸⁰يتجانس لتوليد تصادم عنوان، حمولة حسابية يمكن تنفيذها بالفعل من قبل الجهات ذات الموارد الجيدة للغاية: يمكن لوحدة المعالجة الرسومية أن تقوم بحوالي 2²⁷الهاشات ، لذا يمكنها حساب 2 خلال عام واحد^٥٢، لذلك جميع~2^30 بطاقة رسومات في العالميمكن أن يحسب اصطدامًا في ~ 1/4 من العام ، ويمكن لوحدات المعالجة المركزية المتجهة بالبرامج الثابتة والدوائر المتكاملة المسرعة تسريع هذا بشكل أكبر. في المستقبل ، ستصبح هذه الهجمات متاحة لعدد أكبر وأكبر من الأشخاص. وبالتالي ، قد لا يكون التكلفة الفعلية لتنفيذ انتهاء الحالة الكاملة كبيرة كما يبدو ، حيث يجب أن نحل هذه المشكلة العنوانية الصعبة جدًا بغض النظر عن ذلك.

كيف يتفاعل مع أجزاء أخرى من خريطة الطريق؟

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

تنظيف الميزات

ما المشاكل التي يحلها؟

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

ما هو وكيف يعمل؟

لا يوجد حل واحد كبير يمكن أن يقلل من تعقيد البروتوكول؛ فالطبيعة الجوهرية للمشكلة هي وجود العديد من الإصلاحات الصغيرة.

مثال واحد تم انجازه بالفعل بشكل كبير، ويمكن أن يكون كدليل لكيفية التعامل مع الآخرين، هو@vbuterin/selfdestruct">إزالة تعليمات SELFDESTRUCT. كانت تعليمات SELFDESTRUCT الوحيدة التي يمكن أن تعدل عددًا غير محدود من فتحات التخزين داخل كتلة واحدة، مما يتطلب من العملاء تنفيذ مزيد من التعقيد لتجنب هجمات DoS. الغرض الأصلي من التعليمات كان تمكين تطهير الحالة بشكل طوعي، مما يسمح بتقليل حجم الحالة مع مرور الوقت. في الواقع، انتهى قليل جدًا من استخدامها.تم تخفيض كود العمليةللسماح فقط بحسابات النفاد الذاتي التي تم إنشاؤها في نفس العملية في الشوكة الصعبة لـ Dencun. يحل هذا المشكلة DoS ويسمح بتبسيط كبير في كود العميل. في المستقبل ، من المرجح أن يكون من المنطقي إزالة العملية البرمجية بشكل كامل.

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

• انتقال RLP → SSZ: في الأصل، تم تسلسل كائنات إثيريوم باستخدام ترميز يسمى RLP. يعتبر RLP غير مكتمل النوع ومعقدًا بشكل غير ضروري. اليوم، يستخدم سلسلة البياناتSSZ، والذي هو أفضل بكثير في العديد من الطرق ، بما في ذلك دعم ليس فقط التسلسل ولكن أيضًا التجزئة. في نهاية المطاف ، نريد التخلص تمامًا من RLP ، ونقل جميع أنواع البيانات إلى أن تكون بنية SSZ ، مما سيجعل عملية الترقية أسهل بكثير. تشمل المواصفات الحالية لهذا الأمر، [1] [2] [3].
• إزالة أنواع المعاملات القديمة: هناك العديد من أنواع المعاملات اليوم ، ويمكن إزالة العديد منها. البديل الأكثر اعتدالا للإزالة الكاملة هو ميزة تجريد الحساب التي يمكن للحسابات الذكية من خلالها تضمين الرمز لمعالجة المعاملات القديمة والتحقق منها إذا اختاروا ذلك.
• إصلاح LOG: تنشئ السجلات عوامل تصفية bloom ومنطقا آخر يضيف تعقيدا إلى البروتوكول ، ولكن لا يستخدمه العملاء فعليا لأنه بطيء جدا. يمكننا إزالة هذه الميزاتوبدلاً من ذلك، ضع جهدًا في البدائل، مثل أدوات قراءة السجلات اللامركزية خارج البروتوكول التي تستخدم التكنولوجيا الحديثة مثل SNARKs.
• الإزالة النهائية لآلية لجنة مزامنة سلسلة البيانات: آلية لجنة المزامنةتم إدخالها في الأصل لتمكين التحقق من عميل خفيف لإثيريوم. ومع ذلك، فإنه يضيف تعقيدًا كبيرًا للبروتوكول. في نهاية المطاف، سنكون قادرين على الـالتحقق من طبقة الاتفاق الخاصة بإثيريوم مباشرة باستخدام SNARKs، والتي ستزيل الحاجة إلى بروتوكول التحقق من العميل الخفيف المخصص. في نظرية الأمر، قد تمكننا التغييرات في الاتفاق من إزالة لجان المزامنة حتى في وقت سابق، من خلال إنشاء بروتوكول عميل خفيف "أصلي" أكثر ينطوي على التحقق من التوقيعات من مجموعة عشوائية من محققي اتفاق إثيريوم.
• توحيد تنسيق البيانات: اليوم، يتم تخزين حالة التنفيذ في شجرة ميركل باتريشيا، ويتم تخزين حالة التوافق فيشجرة SSZ، وتتم التزامن الكتل والتدفقات إليها بـ@vbuterin/ proto_danksharding_faq # ما هو التنسيق هو blob-data-in-and-how-is-it-committed-to"> التزامات KZG. في المستقبل ، من المنطقي إنشاء تنسيق موحد واحد لبيانات الكتلة وتنسيق موحد واحد للحالة. ستغطي هذه التنسيقات جميع الاحتياجات المهمة: (i) البراهين السهلة للعملاء عديمي الجنسية ، (ii) ترميز التسلسل والمحو للبيانات ، (iii) هياكل البيانات الموحدة.
• إزالة لجان سلسلة المنارة: تم تقديم هذه الآلية في الأصل لدعم أ نسخة معينة من تجزئة التنفيذبدلاً من ذلك، انتهينا بعمل الشاردنجعبر L2s و blobs. وبالتالي ، فإن اللجان غير ضرورية ، وبالتالي هناك حركة جارية نحو إزالتهم.
• إزالة التباين المختلط: الـ EVM هو من طراز البت الكبير وطبقة الاتفاق هي من طراز البت الصغير. قد يكون من المنطقي إعادة المزامنة وجعل كل شيء بنفس الطراز (على الأرجح البت الكبير لأن الـ EVM أصعب في التغيير)

الآن، بعض الأمثلة التي توجد داخل إثيريوم:

• تبسيط ميكانيكا الغاز: قواعد الغاز الحالية ليست مُحسَّنة تمامًا لتوفير حدود واضحة لكمية الموارد المطلوبة للتحقق من كتلة. أمثلة رئيسية على ذلك تشمل (أ) تكاليف قراءة / كتابة التخزين ، التي تهدف إلى تحديد عدد قراءات / كتابات في كتلة ولكنها حاليًا غير منتظمة تمامًا ، و (ب) قواعد ملء الذاكرة ، حيث يصعب حاليًا تقدير استهلاك الذاكرة الأقصى لـ EVM. تشمل الإصلاحات المقترحة تغييرات تكلفة الغاز عدم الحالة، والتي توحد جميع تكاليف التخزين في صيغة بسيطة، وهذا الاقتراح لتسعير الذاكرة.
• إزالة الترجمات المسبقة: العديد من الترجمات المسبقة التي تمتلكها Ethereum اليوم معقدة بلا داع وغير مستخدمة نسبيا ، وتشكل نسبة كبيرة من فشل الإجماع الوشيك بينما لا يتم استخدامها فعليا من قبل أي تطبيقات. طريقتان للتعامل مع هذا هما (i) مجرد إزالة التحويل البرمجي المسبق ، و (ii) استبداله بقطعة (أكثر تكلفة حتما) من كود EVM الذي ينفذ نفس المنطق. هذا المشروع EIP يقترحللقيام بذلك لقوالب التحقق من الهوية كخطوة أولى؛ في وقت لاحق، قد تكون RIPEMD160 و MODEXP و BLAKE مرشحين للإزالة.
• إزالة قابلية المراقبة للغاز: جعل تنفيذ EVM غير قادر على رؤية كمية الغاز المتبقية لديه. سيؤدي ذلك إلى كسر بعض التطبيقات (على سبيل المثال ، المعاملات المرعية) ، ولكنه سيتيح ترقية أسهل في المستقبل (مثل الإصدارات المتقدمة أكثر من...غاز متعدد الأبعاد). The مواصفات نهاية الملفيجعل الفعل بالفعل الغاز غير مرئي، على الرغم من أنه يجب أن يصبح إي أو إف إلزمًا لتبسيط البروتوكول.
• تحسينات في التحليل الثابت: يعد رمز EVM الحالي صعبًا للتحليل الثابت ، لا سيما لأن القفزات يمكن أن تكون ديناميكية. يجعل ذلك أيضًا أمرًا أكثر صعوبة لإجراء تنفيذات محسنة لرمز EVM يقوم بتجميعه مسبقًا إلى لغة أخرى ما. يمكننا حل هذه المشكلة بشكل محتمل عن طريقإزالة القفزات الديناميكية(أو جعلها أكثر تكلفة، على سبيل المثال، تكلفة الغاز تتناسب خطيًا مع العدد الإجمالي لجمبديست في عقد). إن إي أو إف يفعل ذلك، على الرغم من أن الحصول على مكاسب بسيطة في البروتوكولات من هذا يتطلب جعل إي أو إف إلزاميًا.

ما هي بعض الروابط إلى الأبحاث الحالية؟

• الخطوات التالية في التطهير:https://notes.إثيريوم.org/I_AIhySJTTCYau_adoy2TA
• التدمير الذاتي: @vbuterin/selfdestruct"">https://hackmd.io/@vbuterin/selfdestruct
• تجميع SSZ EIPS: [1] [2][3]
• تغييرات تكلفة الغاز لعدم وجود حالة:https://eips.ethereum.org/EIPS/eip-4762
• تسعير الذاكرة الخطية:https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• إزالة البروتوكول المسبق: https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• إزالة مرشح بلوم: https://eips.إثيريوم.org/EIPS/eip-7668
• طريقة للقيام بجلب سجل آمن خارج السلسلة باستخدام الحساب القابل للتحقق تدريجيًا (اقرأ: STARKs متكررة):https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

ما الذي تبقى للقيام به، وما هي التنازلات؟

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

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

• الخطوة 1: ابدأ في التحدث عن إزالة الميزة X
• الخطوة 2: قم بتحليل لتحديد مدى تأثير إزالة X على التطبيقات، اعتمادًا على النتائج إما (i) التخلي عن الفكرة، (ii) المضي قدما كما هو مخطط، أو (iii) تحديد طريقة "أقل تأثيرًا" معدلة لإزالة X والمضي قدمًا بها
• الخطوة 3: قم بإصدار EIP رسمي لإلغاء X. تأكد من أن البنية التحتية على مستوى أعلى شعبية (على سبيل المثال اللغات البرمجية، المحافظ) تحترم هذا وتتوقف عن استخدام تلك الميزة.
• الخطوة 4: أخيرا ، قم بإزالة X فعليا

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

نهاية الملف

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

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

كيف يتفاعل مع أجزاء أخرى من خارطة الطريق؟

العديد من اقتراحات "التحسين" في بقية الخريطة الطريقة هي أيضًا فرص لتبسيط الميزات القديمة. لتكرار بعض الأمثلة من أعلاه:

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

نهج أكثر جرأة: تحويل أجزاء كبيرة من البروتوكول إلى رمز العقد

استراتيجية Vereinigung für eine radikalere Vereinfachung von Ethereum ist es, das Protokoll unverändert zu lassen, aber große Teile davon von Protokollfunktionen zu Vertragscode zu verlagern.

أقصى نسخة من ذلك ستكون جعل Ethereum L1 "فنيا" يكون فقط سلسلة البيكون، وإدخال آلة افتراضية بسيطة (مثل ريسك-V, القاهرة، أو شيء أكثر أصغر حتى تخصص لأنظمة الإثبات) الذي يسمح لأي شخص آخر بإنشاء لفهم الخاصة بهم. ثم سيتحول EVM إلى أول هذه اللفات. هذا هو بالضبط نفس النتيجة بشكل ساخر كما اقتراحات بيئة التنفيذ من 2019-20، على الرغم من أن SNARKs يجعل من الأكثر قابلية للتنفيذ بشكل كبير.

قد يكون النهج الأكثر اعتدالا هو الحفاظ على العلاقة بين سلسلة المنارة وبيئة تنفيذ Ethereum الحالية كما هي, ولكن قم بإجراء مبادلة موضعية ل EVM. يمكننا اختيار RISC-V أو Cairo أو VM آخر ليكون "Ethereum VM" الجديد ، ثم فرض تحويل جميع عقود EVM إلى رمز VM جديد يفسر منطق الكود الأصلي (عن طريق تجميعه أو تفسيره). من الناحية النظرية ، يمكن القيام بذلك حتى مع كون "الجهاز الظاهري المستهدف" إصدارا من EOF.

تنصل من المسؤولية:

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