مع استمرار تطور شبكة Ethereum ونضجها ، يصبح مفهوم الأنواع المختلفة من العقد مهما بشكل متزايد لفهمه. ومع ذلك ، فإن الحقيقة هي أن معظم المستخدمين ليسوا على استعداد لبذل الجهد لتشغيل عقدة ، على الرغم من أن متطلبات الأجهزة قابلة للتحقيق بالنسبة للكثيرين. في "نهاية اللعبة" لتطوير Ethereum ، من الأهمية بمكان أن يتمكن المستخدمون من التحقق من سلامة الحالة وتوافر البيانات دون الحاجة إلى معرفة أو موارد تقنية واسعة. إن blockchain بدون إمكانية التحقق هو ، بعد كل شيء ، مجرد قاعدة بيانات غير فعالة.
في هذه المقالة، سنتعرض لثلاثة أنواع رئيسية من العقد التي ستشكل مستقبل شبكة Ethereum: العقد اللاحالة، العقد الحالة، والعقد الكامل / الأرشيف. سندرس كيف يمكن للعقد اللاحالة تمكين التحقق من الكتل الجديدة باستخدام الأدلة بدون ثقة، كيف يمكن للعقد الحالة توفير الوصول السريع وغير المتكلف إلى الحالة الحالية لـ Ethereum، وكيف يمكن للعقد الكامل / الأرشيف تخزين تاريخ السلسلة بأكملها حتى Genesis. من خلال فهم أدوار وتضحيات كل نوع من العقد، يمكننا العمل نحو بيئة Ethereum أكثر لامركزية وآمنة ومقيدة النطاق.
كما رأينا بالفعل اليوم ، فإن معظم المستخدمين ليسوا على استعداد لبذل الكثير من الجهد لتشغيل أي نوع من العقد على الرغم من أنه بالنسبة لكل من Bitcoin و Ethereum ، يمكن تحقيق متطلبات الأجهزة لمعظم المستخدمين الثقيلين لكلتا السلسلتين. يتم تعريف "المستخدم الثقيل" هنا على أنه شخص لديه حجم لائق من الأصول في السلسلة ، فكر في الأمر على أنه أي مستخدم لا تكون فيه تكلفة تشغيل العقدة هي المانع.
السبب الرئيسي ربما يكون مزيجًا من حقيقة أن الغالبية العظمى من المستخدمين لا يهتمون بذلك، أو لا يرغبون في إنفاق بضعة مئات من الدولارات على الأجهزة أو ليس لديهم المعرفة التقنية حول كيفية تشغيلها. على الرغم من أن كل من بيتكوين وإيثريوم قد أحرزا تقدمًا كبيرًا في جعل الأمر أسهل. لا يزال هذا مهمة معقدة نسبيًا للمستخدم غير الفني.
رؤية لإيثيريوم بلا دولة
أعتقد أن في نهاية المطاف لكل سلسلة كتلة، سيتعين على المستخدمين التحقق من سلامة الحالة وتوافر البيانات دون الحاجة إلى معرفة أي من هاتين الأمور بالضبط. الخبر الجيد هو أن هذا الرؤية قابلة للتحقيق تمامًا بما فيه الكفاية مع التكنولوجيا الصفرية المعرفة وقليل منعينة توفر البيانات).
في هذه المرحلة النهائية ، وبشكل أساسي جميع المحافظ التي تستحق الاستخدام ستحتوي على عقدة غير مرتبطة بالحالة والتي لكل كتلة جديدة يتم إضافتها إلى السلسلة يمكن استعلام أي عقدة كاملة على طبقة الند للند عن آخر blockheader وzk-proof الذي تم تنفيذ تغييرات الحالة من blockheader السابق بشكل صحيح ، طلب بعض عينات البيانات العشوائية من بعض النظراء للحصول على ثقة تقترب من 100 ٪ بأن جميع البيانات (blobs و execution block data) تم نشرها وأيضًا دليل zk-proof يثبت أن الشبكة قد توصلت إلى توافق وأكدت الكتلة.
نطاق النطاق / الحسابات للقيام بذلك صغير جدًا ويمكن القيام به تمامًا على الهاتف (أو حتى ساعة ذكية مثل@drakefjustin""> يحب @drakefjustin أن يذكر). سيتم تصنيف هذا النوع من العقدة المذكورة أعلاه كنوع من العقدة "الخالية من الحالة" حيث يمكن للعقدة التحقق من الكتل الجديدة دون الحاجة إلى الحالة الحالية محليًا وبدلاً من ذلك الاعتماد على أنواع مختلفة من البراهين للتحقق من الكتل الجديدة.
هذه الأدلة لا يجب أن تكون zk-proofs. سنحصل على التحقق اللاحدودي لتنفيذ الطريقة قبل أن نتمكن من القيام بما وصفته أعلاه ب zk-proofs للتنفيذ. في الواقع ، يمكن تنفيذ التنفيذ اللاحدودي اليوم ولكنه غير كفء للغاية مع تركيبة Merkle-Patricia-Tree الحالية ، فإن أدلة الشاهد كبيرة للغاية لتكون عملية. (انظر @peter_szilagyi's tweet).
انظر إلى حجم "الشاهد" هنا. هذه هي المشكلة الرئيسية التي يصادفها التنفيذ اللاحالة مع شجرة Merkle-Patricia الحالية، حيث إن العديد من الكتل في هذا اللقطة الشاشة تقل بشكل جيد عن 100 كيلوبايت، والبرهان الذي يتطلبه السماح بالتحقق اللاحال للحالة غالبًا ما يكون أكبر بأكثر من 50 مرة من الكتلة نفسها.
هيكل MPT الخاص بـ Ethereum
ومع ذلك، ستقوم إيثريوم بتحديث هيكل شجرة حالتها إلى شيء آخر غير هيكل Merkle-Patricia-Tree الحالي في المستقبل. ربما سمع العديد منكم عن أشجار Verkle التي كانت موجودة على الخريطة الزمنية لسنوات (إذا لم تكن كذلك ، فاقرأ مقالتنا -أشجار فيركل لبقية منا: الجزء 1). سيسمحون بإنشاء عملاء غير متصلين بالدولة وعمليات عملية وذلك نظرًا لطبيعة هيكل شجرة Verkle التي تسمح بشهادات / أدلة صغيرة جدًا.
شجرة ميركل مقابل شجرات فيركل
أحد المشاكل الرئيسية التي تواجهها أشجار Verkle هو أنها ليست آمنة كميائيًا، وهذا يعني أنها في أفضل الحالات ستكون حلاً مؤقتًا حتى تكون الحل النهائي لهيكل شجرة الحالة ناضجة و / أو كفاءة كافية. من المحتمل أن يكون الحل النهائي هو شجرة تجزئة ثنائية ثبتتها STARK ومن الممكن جدًا أن تتم تخطي أشجار Verkle لصالح بعض النكهة من شجرة تجزئة ثنائية ثبتتها STARK. (ميم مناسب من @VitalikButerin)
يمكن أن يكون خيارًا مثيرًا للاهتمام لعقدة غير متمثلة الحالة هو عدم تمام الخالية من الحالة. على سبيل المثال ، سيكون من الممكن تخزين الحالة المحلية التي تجدها ذات صلة بحالتك (بشرط دعم عميلك لمثل هذه الميزة).
قل أن لديك أصولك موزعة عبر عدة عناوين، وأصول وبروتوكولات ديفي، يمكنك في هذه الحالة أن تكون الحالة لكل ما هو ذو صلة بحالتك مكتوبة على القرص محلياً بينما تستخدم كمية صغيرة بشكل تافه فقط من مساحة القرص. حتى تتبع الحالة الكاملة لعدة بروتوكولات ديفي كبيرة سيكون فقط بضعة غيغابايت ونظرًا إلى أن جميع الهواتف الجديدة تأتي بتخزين 128 جيجابايت+ فمن الممكن لا يقل عن ذلك بتاتاً، ولكن من المحتمل عملياً للمستخدم الاحتفاظ بجميع الحالة التي يجدها مفيدة مكتوبة على تخزين الفلاش في هاتفه المحمول.
(مذكرة سريعة حول العملاء الخفيفين: في عالم حيث يمكن للعملاء الغير متصلين بالحالة التحقق بكفاءة من تحولات الحالة والتوافق بسهولة، أشعر وكأنه لن يكون هناك حقًا حالة استخدام للعميل الخفيف التقليدي الذي يعتمد على افتراضية الأغلبية الصادقة.)
العقدة ذات الحالة الواضحة تحتفظ فقط بالحالة الحالية والحالة الأخيرة جدًا ، وتقوم بتقليم كل شيء أقدم من سن معينة (انظرeip-4444مطلوب الحالة الحالية لبناء الكتل محليًا وبناء الكتل المحلية شيء لا يمكن للعقد الخاملة القيام به.
لا ينبغي أن يختلط العقد الذي يحتفظ بالحالة مع العقد الكامل، حيث لن يحتفظ العقد الذي يحتفظ بالحالة بتاريخ السلسلة الكاملة لأن ذلك سيكون مكثفًا جدًا من حيث البيانات في المستقبل. العقد الذي يحتفظ بالحالة مفيد لأي مستخدم يرغب في الوصول السريع والغير معتمد على الثقة إلى الحالة الحالية لإيثيريوم، سواء كان ذلك للاستعلام عن البيانات من الحالة، أو بناء الكتل أو استخدام هذا النوع من العقد للرهان.
الحفاظ على إمكانية تشغيل العقد الحالية على الأجهزة الاستهلاكية هو هدف مهم جدا أعتقد أننا في مجتمع إيثيريوم يجب الحفاظ عليه حتى عندما تصبح العقد الخالية من الحالة خفيفة وناضجة جدا. واحدة من الأسباب الرئيسية لذلك هو أن جميع العقد الخالية من الحالة تعتمد على العقد الحالية لإنشاء الشاهد الذي يُحتاج إليه للتحقق من العقد الجديدة.
من الضروري أيضًا الوصول إلى الحالة الحالية لمعرفة ما إذا كانت عملية تجارية في mempool صالحة أم لا ، وبالتالي فمن المهم جدًا أن يكون لدينا مجموعة متمحورة جدًا من العقد الحالية على الشبكة التي يمكن أن تضمن ضمانات قوية جداً ضد الرقابة مع تصميم قائمة الاستثناء بأي شكل من الأشكال.
الخبر الجيد هو أنه مع انتهاء الحالة ، يمكننا أن نجعل تشغيل العقدة متعددة الحالات أسهل بشكل كبير حيث يمكن حذف الحالة التي لم يتفاعل بها أحد لفترة طويلة من قرص العقدة ، وسيكون على أي شخص يرغب في التفاعل مع الحالة التي انتهت صلاحيتها أن يحضر شاهدًا (بشكل أساسي دليل ميركل) لإعادة الحالة المنتهية إلى الحالة الحالية. أي شخص لديه وصول إلى تاريخ السلسلة يمكنه بطريقة غير قابلة للثقة بناء هذه الأنواع من البراهين لإعادة الحالة المنتهية. حتى كتابة هذا النص ، يقترب حجم حالة Ethereum من 300 جيجابايت ، وحتى يتم تنفيذ بعض أشكال انتهاء الحالة ، ستستمر حجم الحالة في النمو باتجاه أعلى تقريبًا.
(هنا هو مقال رائع جدًا من @paradigmوهو يغوص أعمق في موضوع النمو الحالة وانتهاء الحالة)
لأغراض هذه المقالة ، سأقوم بتجميع العقد الكاملة والأرشفة معا نظرا لأن العقدة الكاملة العادية يمكنها بالمعلومات التي كتبتها على القرص محليا حساب جميع البيانات التي كتبتها عقدة أرشيفية على القرص. الاختلافات هي أن حالة تقليم العقدة الكاملة لم تعد الحالة الأحدث / الحديثة. لا يمكنك الاستعلام على سبيل المثال "ما هو رصيد ETH للحساب X في الكتلة Y منذ حوالي 5 سنوات" من عقدة كاملة عادية بينما تجيب عقدة أرشيفية على هذا الاستعلام في ميلي ثانية.
دليل سهل حول العقد الكامل للإيثيريوم مقابل العقد الأرشيفي بواسطة @0xZeeve
ومع ذلك ، يكون من الممكن نظريًا حساب إجابة هذا الاستعلام من البيانات التي قام العقدة الكاملة بكتابتها على القرص (تاريخ السلسلة بأكمله) ولكن ليس العديد من عملاء التنفيذ يدعمون هذه الميزة. أعتقد أنه غير معقول أن نعتقد أن العديد من المستخدمين ، حتى المتطورين ، سيقومون بتشغيل عقدة كاملة / أرشيفية في 10 سنوات ، لكي تكون هذه خيارًا معقولًا ، يجب أن نقيد إنتاجية L1 إلى مستويات غير معقولة تمامًا عندما يمكننا الحصول على إنتاجية أكبر بكثير على L1 مع تضحيات أدنى. عندما يتمكن معظم المستخدمين من التحقق بسهولة من الكتل الجديدة بواسطة دليل zk ، أعتقد أنه يستحق المضي قدمًا عندما تكون الفوائد كبيرة جدًا.
ربما يمكننا الحصول على Execution-clients القادرة على العمل بكفاءة على HDD وجعلها عملية لتخزين حتى مئات من TB من الحالة المؤرشفة بأسعار معقولة نسبيًا. يمكن أن يتيح ذلك للمستخدمين الذين يرغبون في الأرشفة لأي سبب من الأسباب أن يفعلوا ذلك، أعلم أن أحد أهداف Erigon هو السماح بتشغيل Full-archival node على HDD.
في النهاية، سيتم تشكيل مستقبل إثريوم من قبل العقد التي تشكل شبكتها. من خلال تبني العقد اللا حالة كخيار الأكثر واقعية لمعظم المستخدمين، ولكن مع الاعتراف بالقيمة القوية للعقد الحالية والكاملة/الأرشيفية على الشبكة، يمكننا خلق توازن مثالي بين اللامركزية والأمان والقابلية للتوسع التي تعود بالفائدة على جميع المستخدمين.
مع استمرار تطور شبكة Ethereum ونضجها ، يصبح مفهوم الأنواع المختلفة من العقد مهما بشكل متزايد لفهمه. ومع ذلك ، فإن الحقيقة هي أن معظم المستخدمين ليسوا على استعداد لبذل الجهد لتشغيل عقدة ، على الرغم من أن متطلبات الأجهزة قابلة للتحقيق بالنسبة للكثيرين. في "نهاية اللعبة" لتطوير Ethereum ، من الأهمية بمكان أن يتمكن المستخدمون من التحقق من سلامة الحالة وتوافر البيانات دون الحاجة إلى معرفة أو موارد تقنية واسعة. إن blockchain بدون إمكانية التحقق هو ، بعد كل شيء ، مجرد قاعدة بيانات غير فعالة.
في هذه المقالة، سنتعرض لثلاثة أنواع رئيسية من العقد التي ستشكل مستقبل شبكة Ethereum: العقد اللاحالة، العقد الحالة، والعقد الكامل / الأرشيف. سندرس كيف يمكن للعقد اللاحالة تمكين التحقق من الكتل الجديدة باستخدام الأدلة بدون ثقة، كيف يمكن للعقد الحالة توفير الوصول السريع وغير المتكلف إلى الحالة الحالية لـ Ethereum، وكيف يمكن للعقد الكامل / الأرشيف تخزين تاريخ السلسلة بأكملها حتى Genesis. من خلال فهم أدوار وتضحيات كل نوع من العقد، يمكننا العمل نحو بيئة Ethereum أكثر لامركزية وآمنة ومقيدة النطاق.
كما رأينا بالفعل اليوم ، فإن معظم المستخدمين ليسوا على استعداد لبذل الكثير من الجهد لتشغيل أي نوع من العقد على الرغم من أنه بالنسبة لكل من Bitcoin و Ethereum ، يمكن تحقيق متطلبات الأجهزة لمعظم المستخدمين الثقيلين لكلتا السلسلتين. يتم تعريف "المستخدم الثقيل" هنا على أنه شخص لديه حجم لائق من الأصول في السلسلة ، فكر في الأمر على أنه أي مستخدم لا تكون فيه تكلفة تشغيل العقدة هي المانع.
السبب الرئيسي ربما يكون مزيجًا من حقيقة أن الغالبية العظمى من المستخدمين لا يهتمون بذلك، أو لا يرغبون في إنفاق بضعة مئات من الدولارات على الأجهزة أو ليس لديهم المعرفة التقنية حول كيفية تشغيلها. على الرغم من أن كل من بيتكوين وإيثريوم قد أحرزا تقدمًا كبيرًا في جعل الأمر أسهل. لا يزال هذا مهمة معقدة نسبيًا للمستخدم غير الفني.
رؤية لإيثيريوم بلا دولة
أعتقد أن في نهاية المطاف لكل سلسلة كتلة، سيتعين على المستخدمين التحقق من سلامة الحالة وتوافر البيانات دون الحاجة إلى معرفة أي من هاتين الأمور بالضبط. الخبر الجيد هو أن هذا الرؤية قابلة للتحقيق تمامًا بما فيه الكفاية مع التكنولوجيا الصفرية المعرفة وقليل منعينة توفر البيانات).
في هذه المرحلة النهائية ، وبشكل أساسي جميع المحافظ التي تستحق الاستخدام ستحتوي على عقدة غير مرتبطة بالحالة والتي لكل كتلة جديدة يتم إضافتها إلى السلسلة يمكن استعلام أي عقدة كاملة على طبقة الند للند عن آخر blockheader وzk-proof الذي تم تنفيذ تغييرات الحالة من blockheader السابق بشكل صحيح ، طلب بعض عينات البيانات العشوائية من بعض النظراء للحصول على ثقة تقترب من 100 ٪ بأن جميع البيانات (blobs و execution block data) تم نشرها وأيضًا دليل zk-proof يثبت أن الشبكة قد توصلت إلى توافق وأكدت الكتلة.
نطاق النطاق / الحسابات للقيام بذلك صغير جدًا ويمكن القيام به تمامًا على الهاتف (أو حتى ساعة ذكية مثل@drakefjustin""> يحب @drakefjustin أن يذكر). سيتم تصنيف هذا النوع من العقدة المذكورة أعلاه كنوع من العقدة "الخالية من الحالة" حيث يمكن للعقدة التحقق من الكتل الجديدة دون الحاجة إلى الحالة الحالية محليًا وبدلاً من ذلك الاعتماد على أنواع مختلفة من البراهين للتحقق من الكتل الجديدة.
هذه الأدلة لا يجب أن تكون zk-proofs. سنحصل على التحقق اللاحدودي لتنفيذ الطريقة قبل أن نتمكن من القيام بما وصفته أعلاه ب zk-proofs للتنفيذ. في الواقع ، يمكن تنفيذ التنفيذ اللاحدودي اليوم ولكنه غير كفء للغاية مع تركيبة Merkle-Patricia-Tree الحالية ، فإن أدلة الشاهد كبيرة للغاية لتكون عملية. (انظر @peter_szilagyi's tweet).
انظر إلى حجم "الشاهد" هنا. هذه هي المشكلة الرئيسية التي يصادفها التنفيذ اللاحالة مع شجرة Merkle-Patricia الحالية، حيث إن العديد من الكتل في هذا اللقطة الشاشة تقل بشكل جيد عن 100 كيلوبايت، والبرهان الذي يتطلبه السماح بالتحقق اللاحال للحالة غالبًا ما يكون أكبر بأكثر من 50 مرة من الكتلة نفسها.
هيكل MPT الخاص بـ Ethereum
ومع ذلك، ستقوم إيثريوم بتحديث هيكل شجرة حالتها إلى شيء آخر غير هيكل Merkle-Patricia-Tree الحالي في المستقبل. ربما سمع العديد منكم عن أشجار Verkle التي كانت موجودة على الخريطة الزمنية لسنوات (إذا لم تكن كذلك ، فاقرأ مقالتنا -أشجار فيركل لبقية منا: الجزء 1). سيسمحون بإنشاء عملاء غير متصلين بالدولة وعمليات عملية وذلك نظرًا لطبيعة هيكل شجرة Verkle التي تسمح بشهادات / أدلة صغيرة جدًا.
شجرة ميركل مقابل شجرات فيركل
أحد المشاكل الرئيسية التي تواجهها أشجار Verkle هو أنها ليست آمنة كميائيًا، وهذا يعني أنها في أفضل الحالات ستكون حلاً مؤقتًا حتى تكون الحل النهائي لهيكل شجرة الحالة ناضجة و / أو كفاءة كافية. من المحتمل أن يكون الحل النهائي هو شجرة تجزئة ثنائية ثبتتها STARK ومن الممكن جدًا أن تتم تخطي أشجار Verkle لصالح بعض النكهة من شجرة تجزئة ثنائية ثبتتها STARK. (ميم مناسب من @VitalikButerin)
يمكن أن يكون خيارًا مثيرًا للاهتمام لعقدة غير متمثلة الحالة هو عدم تمام الخالية من الحالة. على سبيل المثال ، سيكون من الممكن تخزين الحالة المحلية التي تجدها ذات صلة بحالتك (بشرط دعم عميلك لمثل هذه الميزة).
قل أن لديك أصولك موزعة عبر عدة عناوين، وأصول وبروتوكولات ديفي، يمكنك في هذه الحالة أن تكون الحالة لكل ما هو ذو صلة بحالتك مكتوبة على القرص محلياً بينما تستخدم كمية صغيرة بشكل تافه فقط من مساحة القرص. حتى تتبع الحالة الكاملة لعدة بروتوكولات ديفي كبيرة سيكون فقط بضعة غيغابايت ونظرًا إلى أن جميع الهواتف الجديدة تأتي بتخزين 128 جيجابايت+ فمن الممكن لا يقل عن ذلك بتاتاً، ولكن من المحتمل عملياً للمستخدم الاحتفاظ بجميع الحالة التي يجدها مفيدة مكتوبة على تخزين الفلاش في هاتفه المحمول.
(مذكرة سريعة حول العملاء الخفيفين: في عالم حيث يمكن للعملاء الغير متصلين بالحالة التحقق بكفاءة من تحولات الحالة والتوافق بسهولة، أشعر وكأنه لن يكون هناك حقًا حالة استخدام للعميل الخفيف التقليدي الذي يعتمد على افتراضية الأغلبية الصادقة.)
العقدة ذات الحالة الواضحة تحتفظ فقط بالحالة الحالية والحالة الأخيرة جدًا ، وتقوم بتقليم كل شيء أقدم من سن معينة (انظرeip-4444مطلوب الحالة الحالية لبناء الكتل محليًا وبناء الكتل المحلية شيء لا يمكن للعقد الخاملة القيام به.
لا ينبغي أن يختلط العقد الذي يحتفظ بالحالة مع العقد الكامل، حيث لن يحتفظ العقد الذي يحتفظ بالحالة بتاريخ السلسلة الكاملة لأن ذلك سيكون مكثفًا جدًا من حيث البيانات في المستقبل. العقد الذي يحتفظ بالحالة مفيد لأي مستخدم يرغب في الوصول السريع والغير معتمد على الثقة إلى الحالة الحالية لإيثيريوم، سواء كان ذلك للاستعلام عن البيانات من الحالة، أو بناء الكتل أو استخدام هذا النوع من العقد للرهان.
الحفاظ على إمكانية تشغيل العقد الحالية على الأجهزة الاستهلاكية هو هدف مهم جدا أعتقد أننا في مجتمع إيثيريوم يجب الحفاظ عليه حتى عندما تصبح العقد الخالية من الحالة خفيفة وناضجة جدا. واحدة من الأسباب الرئيسية لذلك هو أن جميع العقد الخالية من الحالة تعتمد على العقد الحالية لإنشاء الشاهد الذي يُحتاج إليه للتحقق من العقد الجديدة.
من الضروري أيضًا الوصول إلى الحالة الحالية لمعرفة ما إذا كانت عملية تجارية في mempool صالحة أم لا ، وبالتالي فمن المهم جدًا أن يكون لدينا مجموعة متمحورة جدًا من العقد الحالية على الشبكة التي يمكن أن تضمن ضمانات قوية جداً ضد الرقابة مع تصميم قائمة الاستثناء بأي شكل من الأشكال.
الخبر الجيد هو أنه مع انتهاء الحالة ، يمكننا أن نجعل تشغيل العقدة متعددة الحالات أسهل بشكل كبير حيث يمكن حذف الحالة التي لم يتفاعل بها أحد لفترة طويلة من قرص العقدة ، وسيكون على أي شخص يرغب في التفاعل مع الحالة التي انتهت صلاحيتها أن يحضر شاهدًا (بشكل أساسي دليل ميركل) لإعادة الحالة المنتهية إلى الحالة الحالية. أي شخص لديه وصول إلى تاريخ السلسلة يمكنه بطريقة غير قابلة للثقة بناء هذه الأنواع من البراهين لإعادة الحالة المنتهية. حتى كتابة هذا النص ، يقترب حجم حالة Ethereum من 300 جيجابايت ، وحتى يتم تنفيذ بعض أشكال انتهاء الحالة ، ستستمر حجم الحالة في النمو باتجاه أعلى تقريبًا.
(هنا هو مقال رائع جدًا من @paradigmوهو يغوص أعمق في موضوع النمو الحالة وانتهاء الحالة)
لأغراض هذه المقالة ، سأقوم بتجميع العقد الكاملة والأرشفة معا نظرا لأن العقدة الكاملة العادية يمكنها بالمعلومات التي كتبتها على القرص محليا حساب جميع البيانات التي كتبتها عقدة أرشيفية على القرص. الاختلافات هي أن حالة تقليم العقدة الكاملة لم تعد الحالة الأحدث / الحديثة. لا يمكنك الاستعلام على سبيل المثال "ما هو رصيد ETH للحساب X في الكتلة Y منذ حوالي 5 سنوات" من عقدة كاملة عادية بينما تجيب عقدة أرشيفية على هذا الاستعلام في ميلي ثانية.
دليل سهل حول العقد الكامل للإيثيريوم مقابل العقد الأرشيفي بواسطة @0xZeeve
ومع ذلك ، يكون من الممكن نظريًا حساب إجابة هذا الاستعلام من البيانات التي قام العقدة الكاملة بكتابتها على القرص (تاريخ السلسلة بأكمله) ولكن ليس العديد من عملاء التنفيذ يدعمون هذه الميزة. أعتقد أنه غير معقول أن نعتقد أن العديد من المستخدمين ، حتى المتطورين ، سيقومون بتشغيل عقدة كاملة / أرشيفية في 10 سنوات ، لكي تكون هذه خيارًا معقولًا ، يجب أن نقيد إنتاجية L1 إلى مستويات غير معقولة تمامًا عندما يمكننا الحصول على إنتاجية أكبر بكثير على L1 مع تضحيات أدنى. عندما يتمكن معظم المستخدمين من التحقق بسهولة من الكتل الجديدة بواسطة دليل zk ، أعتقد أنه يستحق المضي قدمًا عندما تكون الفوائد كبيرة جدًا.
ربما يمكننا الحصول على Execution-clients القادرة على العمل بكفاءة على HDD وجعلها عملية لتخزين حتى مئات من TB من الحالة المؤرشفة بأسعار معقولة نسبيًا. يمكن أن يتيح ذلك للمستخدمين الذين يرغبون في الأرشفة لأي سبب من الأسباب أن يفعلوا ذلك، أعلم أن أحد أهداف Erigon هو السماح بتشغيل Full-archival node على HDD.
في النهاية، سيتم تشكيل مستقبل إثريوم من قبل العقد التي تشكل شبكتها. من خلال تبني العقد اللا حالة كخيار الأكثر واقعية لمعظم المستخدمين، ولكن مع الاعتراف بالقيمة القوية للعقد الحالية والكاملة/الأرشيفية على الشبكة، يمكننا خلق توازن مثالي بين اللامركزية والأمان والقابلية للتوسع التي تعود بالفائدة على جميع المستخدمين.