تهدف الدورات الأصلية (EIP-8079) إلى تبسيط اللف المعادل في EVM بشكل كبير. حاليا، لا يفهم أحد تقريبا خارج فريق الجمع الأصلي بشكل كامل نظام الجمع الكامل، وحتى داخل الفريق قلة هم على دراية كبيرة بها. مع التركيبات الأصلية، طالما هناك أشخاص يفهمون المستوى الأول، سيكون هناك أيضا من يفهمون الدورات الأصلية. وطالما تم تحديث وترقية مستوى L1، سيتم تحديث وترقية الrollup الأصلية، حتى لو انسحب فريق rollup الأصلي.
vitalik.eth
vitalik.ethمنذ 22 ساعةً
جانب مهم، ودائما ما يستهان به، من "عدم الثقة"، و"اجتياز اختبار الانسحاب"، و"السيادة الذاتية" هو بساطة البروتوكول. حتى لو كان البروتوكول لامركزيا للغاية مع مئات الآلاف من العقد، ولديه تحمل أخطاء بيزنطي بنسبة 49٪، والعقد تتحقق بالكامل من كل شيء باستخدام بيردا وستارك آمن للكم، إذا كان البروتوكول فوضى معقدة من مئات الآلاف من أسطر الشيفرة وخمسة أشكال من التشفير على مستوى الدكتوراه، فإن ذلك البروتوكول يفشل في الاختبارات الثلاثة في النهاية: * ليس بلا ثقة لأنك يجب أن تثق بطبقة صغيرة من الكهنة الكبار الذين يخبرونك بخصائص البروتوكول * لا تجتاز اختبار الخروج لأنه إذا اختفت فرق العملاء الحالية، يصبح من الصعب جدا على الفرق الجديدة الوصول إلى نفس مستوى الجودة * ليس سيادة ذاتية لأنه إذا لم يستطع حتى أكثر الأشخاص تقنية فحص وفهم الشيء، فهو ليس ملكك بالكامل كما أنه أقل أمانا، لأن كل جزء من البروتوكول، خاصة إذا كان يمكنه التفاعل مع أجزاء أخرى بطرق معقدة، يحمل خطر انقطاع البروتوكول. أحد مخاوفي في تطوير بروتوكولات إيثيريوم هو أننا قد نكون متحمسين جدا لإضافة ميزات جديدة لتلبية احتياجات محددة للغاية، حتى لو كانت تلك الميزات تضخم البروتوكول أو أضافت أنواعا جديدة كاملة من المكونات المتفاعلة أو التشفير المعقد كتبعيات حرجة. قد يكون هذا جيدا لتحقيق مكاسب وظيفية قصيرة الأمد، لكنه مدمر للغاية للحفاظ على السيادة الذاتية طويلة الأمد، وخلق بنية فائقة لامركزية تمتد لمئة عام تتجاوز صعود وسقوط الإمبراطوريات والأيديولوجيات. المشكلة الأساسية هي أنه إذا تم تقييم تغييرات البروتوكول من منظور "حجم التغييرات على البروتوكول الحالي"، فإن الرغبة في الحفاظ على التوافق مع الإصدارات السابقة تعني أن الإضافات تحدث أكثر بكثير من الطرح، ويتضخم البروتوكول حتما مع مرور الوقت. لمواجهة ذلك، تحتاج عملية تطوير إيثيريوم إلى وظيفة "تبسيط" / "جمع القمامة" بشكل صريح. "التبسيط" له ثلاثة مقاييس: * تقليل إجمالي أسطر الشيفرة في البروتوكول. البروتوكول المثالي يتناسب مع صفحة واحدة - أو على الأقل بضع صفحات * تجنب الاعتمادات غير الضرورية على المكونات التقنية المعقدة جوهريا. على سبيل المثال، بروتوكول يعتمد أمنه فقط على التجزئة (والأفضل من ذلك: على دالة تجزئة واحدة بالضبط) أفضل من البروتوكول الذي يعتمد على التجزئة والشبكات. إضافة الإيزوجينيز هو الأسوأ من كل ذلك، لأنه (عذرا على المهووسين المجتهدين الذين اكتشفوا هذه الأمور) لا أحد يفهم الإيزوجينيز. * إضافة المزيد من _الثواب_: الخصائص الأساسية التي يمكن للبروتوكول الاعتماد عليها، مثل EIP-6780 (إزالة التدمير الذاتي) أضاف خاصية أنه في أقصى حد يمكن تغيير N فتحة تخزين لكل فتحة، مما يبسط تطوير العميل بشكل كبير، وEIP-7825 (الحد الأقصى للغاز لكل شحنة) أضاف الحد الأقصى لتكلفة معالجة معاملة واحدة، مما يساعد بشكل كبير في ZK-EVMs والتنفيذ المتوازي. جمع القمامة يمكن أن يكون مجزأ، أو واسع النطاق. يحاول النهج الجزئي أخذ الميزات الموجودة وتبسيطها لتصبح أبسط وأكثر منطقية. أحد الأمثلة هو إصلاحات تكلفة الغاز في غلامستردام، التي جعلت العديد من تكاليف الغاز التي كانت تعسفية سابقا تعتمد بدلا من ذلك على عدد قليل من المعايير المرتبطة بوضوح باستهلاك الموارد. كانت إحدى مجموعات القمامة واسعة النطاق تستبدل PoW ب PoS. ومن المرجح أن يحدث شيء آخر كجزء من توافق Lean، مما يفتح المجال لتصحيح عدد كبير من الأخطاء في نفس الوقت ( ). نهج آخر هو "التوافق العكسي على طريقة روزيتا"، حيث تبقى الميزات المعقدة لكنها قليلة الاستخدام قابلة للاستخدام لكنها "تخفض" من كونها جزءا من البروتوكول الإلزامي وتصبح بدلا من ذلك كود العقود الذكية، بحيث لا يحتاج مطورو العملاء الجدد للانشغال بها. أمثلة: * بعد أن نطور إلى تجريد الحساب الأصلي بالكامل، يمكن سحب جميع أنواع المعاملات القديمة، ويمكن تحويل EOA إلى محافظ عقود ذكية يمكن لكودها معالجة جميع أنواع المعاملات * يمكننا استبدال الترجمات المسبقة الموجودة (باستثناء تلك التي _ضرورية حقا) ب EVM أو كود RISC-V لاحقا * يمكننا في النهاية تغيير الجهاز الافتراضي من جهاز إلكتروني إلكتروني إلى RISC-V (أو أي جهاز افتراضي أبسط)؛ يمكن تحويل EVM إلى عقد ذكي في الجهاز الافتراضي الجديد. أخيرا، نريد الابتعاد عن شعور مطوري العملاء بالحاجة إلى التعامل مع جميع الإصدارات القديمة من بروتوكول الإيثيريوم. يمكن ترك ذلك لإصدارات العميل القديمة التي تعمل في حاويات Docker. على المدى الطويل، آمل أن يكون معدل التغير في إيثيريوم أبطأ. أعتقد لأسباب مختلفة أن هذا _يجب أن يحدث_ في النهاية. يجب أن ينظر إلى هذه السنوات الخمسة عشر الأولى جزئيا كمرحلة مراهقة حيث استكشفنا الكثير من الأفكار ورأينا ما ينجح وما هو مفيد وما ليس كذلك. يجب أن نسعى لتجنب أن تكون الأجزاء غير المفيدة عبئا دائما على بروتوكول الإيثيريوم. ببساطة، نريد تحسين الإيثيريوم بطريقة تشبه هذا:
EIP: الكتاب:
‏‎893‏