مروری جامع بر Hegotá EIP: آینده سخت‌افزاری بعدی اتریوم به کجا می‌رود؟

Ethlabs به تشریح منطق انتخاب و رد EIP ها می‌پردازد.

نویسنده: Ethlabs

ترجمه: Chopper، Foresight News

جهت‌گیری توسعه اتریوم به همه کسانی که برنامه‌ها را می‌سازند، از شبکه استفاده می‌کنند، ETH را نگه می‌دارند و به پتانسیل آینده اتریوم ایمان دارند، مربوط می‌شود. مسیر طولانی‌مدت اتریوم در نهایت توسط شرکت‌کنندگانی که روزانه بر روی آن محصولات می‌سازند، برنامه‌ها را اجرا می‌کنند و در جامعه فعال هستند، تعیین می‌شود، اما ارتقاء شبکه یک ابزار کلیدی برای تکرار پروتکل و تطابق با نیازهای کاربران است. Hegotá پس از Glamsterdam، ارتقاء بعدی برنامه‌ریزی شده اتریوم است. این مقاله به بررسی جهت‌گیری‌هایی می‌پردازد که Ethlabs معتقد است باید در این ارتقاء به آن‌ها توجه شود و دلایل آن‌ها را توضیح می‌دهد.

در حال حاضر، دامنه ارتقاء Hegotá به‌طور اولیه از طریق فرآیند فنی عمومی اتریوم تعیین می‌شود. پیشنهادات ذکر شده در زیر، نتایج بسیاری از توسعه‌دهندگان، تیم‌های تحقیقاتی و تیم‌های کلاینت را گردآوری کرده است. این مقاله به‌وضوح جهت‌گیری‌هایی را که Ethlabs پیشنهاد می‌کند، ارائه می‌دهد و نظراتی که هنوز به نتیجه نرسیده‌اند را بیان می‌کند. ما از همه بخش‌های صنعت دعوت می‌کنیم که این پیشنهادات را ارزیابی، نقد و بهبود دهند؛ در روزها و هفته‌های آینده، با ادامه بحث و به‌روزرسانی اطلاعات، ما نیز نظرات خود را به‌روزرسانی خواهیم کرد.

برای ارتقاء Hegotá، با توجه به همه EIP های پیشنهادی، ما معتقدیم که حوزه‌های زیر اولویت‌های اصلی اتریوم هستند:

• توانایی قوی‌تر در برابر سانسور: هر کسی، بدون توجه به هویت و هدف، باید بتواند معاملات را در بلوک‌ها ثبت کند؛
• اتریوم سریع‌تر: زمان‌های بلوک سریع‌تر به معنای تأیید سریع‌تر معاملات، قیمت‌های زنده در زنجیره و زمان‌های نهایی کوتاه‌تر است؛
• انتزاع حساب بومی: حساب‌ها از کلیدهای عمومی، حمایت از معاملات، پرداخت گس با توکن‌ها، معاملات گروهی، حفاظت از حریم خصوصی قوی‌تر و مسیر ارتقاء کلیدهای پساکوانتومی پشتیبانی می‌کنند؛
• گسترش مداوم L1: حتی در زمان‌های اوج تقاضا، برنامه‌ها باید ظرفیت شبکه‌ای پایدار و قابل تحمل داشته باشند.

توضیحات مقدماتی: فرآیند پیشبرد EIP چگونه کار می‌کند؟

قبل از تفسیر رسمی پیشنهادات، باید زمینه‌های کلیدی را روشن کنیم، دامنه ارتقاء Hegotá در مرحله دوم به تازگی آغاز شده است. مرحله اول FOCIL را به‌عنوان پیشنهاد اصلی ارتقاء Hegotá تعیین کرده است. مهلت پیشنهادات EIP غیر اصلی تا 6 آگوست است و پس از آن، جلسه ACD به‌طور کامل طرح کلی ارتقاء Hegotá را ارزیابی خواهد کرد.

تمام EIP های زیر در حال حاضر در مرحله PFI (پیشنهاد برای گنجاندن) قرار دارند. ارسال EIP به پیشنهاد ارتقاء نیازی به مجوز ندارد، اما بیشتر پیشنهادات در نهایت نمی‌توانند به ارتقاء رسمی وارد شوند.

با پیشرفت توسعه، پیشنهادات چندین دور ارزیابی را طی می‌کنند، مراحل به تدریج ارتقا می‌یابند و قطعیت اجرایی افزایش می‌یابد:

PFI (پیشنهاد برای گنجاندن): پیشنهاد به این ارتقاء ارسال می‌شود. این مرحله هیچ آستانه ورودی ندارد، به معنای حمایت کلاینت نیست و تضمینی برای راه‌اندازی نهایی نیست؛

CFI (در نظر گرفتن گنجاندن): تیم‌های کلاینت بررسی را کامل کرده و برنامه‌ریزی برای توسعه و آزمایش پروتوتایپ را آغاز می‌کنند؛

SFI (تعیین گنجاندن): طرفین به‌طور کلی موافقت می‌کنند که گنجانده شود، به شرطی که توسعه و آزمایش به‌خوبی پیش برود.

برای درک کامل فرآیند، تماشای ویدیوی توضیحی Tim Beiko را توصیه می‌کنیم. (https://www.youtube.com/watch?v=-S4blFZl28g)

راهنمای مطالعه

این مقاله از استانداردهای درجه‌بندی Forkcast استفاده می‌کند تا اولویت‌های Ethlabs را در مورد EIP های مختلف Hegotá بیان کند. برای ساده‌سازی تصمیم‌گیری، تمام پیشنهادات ارزیابی شده به پنج دسته تقسیم می‌شوند:

• 【S درجه】 به شدت پیشنهاد می‌شود که گنجانده شود
• 【A درجه】 اگر موانع توسعه، ارزیابی تأثیر و پیاده‌سازی اکوسیستم حل شود، پیشنهاد می‌شود که گنجانده شود
• 【B درجه】 دارای ارزش است، اما گنجاندن آن در این ارتقاء دشواری بالایی دارد
• 【D درجه】 در شرایط فعلی، پیشنهاد نمی‌شود که به Hegotá گنجانده شود
• 【نظرات در حال شکل‌گیری】 ما هنوز در حال ارزیابی این EIP هستیم

⚠️ توجه: موارد فوق تنها پیشنهادات Ethlabs است. ما عمدتاً بر اساس اهداف پیشنهاد، مشخصات فنی و پیچیدگی توسعه پیش‌بینی شده ارزیابی می‌کنیم؛ برای پروژه‌های عمیقاً درگیر (مانند Frames، Quick Slots) اطلاعات بیشتری داریم. در آینده، ما نظرات خود را با توجه به بازخورد تیم‌های ethPandaOps، تیم‌های آزمایشی و کلاینت‌ها به‌روزرسانی خواهیم کرد. علامت【CL】 نمایانگر تأثیر بر کلاینت‌های لایه اجماع است؛ 【EL】 نمایانگر تأثیر بر کلاینت‌های لایه اجرایی است.

علاوه بر این، Ethlabs در نوشتن چندین EIP (از جمله FOCIL، Frame Transactions، Quick Slots) مشارکت داشته است. ما تلاش می‌کنیم تا همه پیشنهادات را به‌طور عینی ارزیابی کنیم و تحت تأثیر میزان مشارکت خود قرار نگیریم، اما خوانندگان می‌توانند به این زمینه توجه کنند.

لیست اولویت CL

لیست اولویت EL

بدون مقدمه، در ادامه نظرات فعلی Ethlabs در مورد ارتقاء Hegotá آورده شده است.

چهار جهت اصلی Hegotá

FOCIL: تقویت توانایی در برابر سانسور

EIP-7805 FOCIL به مرحله SFI وارد شده و به‌طور رسمی به‌عنوان پیشنهاد اصلی Hegotá تعیین شده است. سه عضو Ethlabs (Francesco، Barnabé، Julian) نویسندگان مشترک این پیشنهاد هستند و ما به‌طور کامل از پیاده‌سازی آن حمایت می‌کنیم. با توجه به اینکه طرح نهایی شده است، در اینجا فقط به‌طور مختصر توضیح می‌دهیم: تنها بلاک‌چینی که برای همه بی‌طرف باشد، می‌تواند پایه‌ای برای اعتماد همه باشد. این سنگ بنای گسترش اتریوم و تبدیل آن به لایه واقعی تسویه اقتصادی جهانی است که به هر شرکت‌کننده خدمت می‌کند.

Quick Slots: اتریوم سریع‌تر

زمان‌های 12 ثانیه‌ای اتریوم در حال حاضر تأخیر بالایی را به همراه دارد و تجربه کاربری را تحت تأثیر قرار می‌دهد. بنابراین ما به‌طور قاطع پیشنهاد می‌کنیم که EIP-8198 Quick Slots【S درجه】 در Hegotá گنجانده شود، دلایل اصلی چهار مورد است:

• سرعت تأیید معاملات کاربران L1 افزایش می‌یابد و تجربه بهینه می‌شود؛
• بازارهای زنجیره‌ای L1 قیمت‌های به‌روزتری را دریافت می‌کنند و تفاوت قیمت و سود تأمین‌کنندگان نقدینگی بهبود می‌یابد؛
• قطعیت نهایی، قوانین تأیید سریع و مدت زمان زمان‌های بلوک به هم مرتبط است، بلوک‌های سریع‌تر به بهبود تعامل‌پذیری بین زنجیره‌ای اتریوم کمک می‌کند؛
• تعداد پیشنهاددهندگان بلوک در هر ثانیه افزایش می‌یابد و توانایی در برابر سانسور را تقویت می‌کند، از جمله توانایی اقتصادی در برابر سانسور: هزینه‌ای که برای اجرای سانسور از طریق خالی کردن مداوم بلوک‌ها باید پرداخت شود، بالاتر می‌رود.

کاهش فاصله بین بلوک‌ها بدون از دست دادن ویژگی‌های غیرمتمرکز اتریوم، می‌تواند ارزش فضای بلوک اتریوم را افزایش دهد و سود به شبکه و خود ETH بازگردد. هر بار که تأخیر کاهش می‌یابد، به‌طور مستقیم برای کاربران ارزش ایجاد می‌کند. همچنین، تسریع یکی از پرطرفدارترین جهت‌گیری‌های بهبود از سوی توسعه‌دهندگان برنامه است.

شروع اصلاحات در حال حاضر منطقی است، زیرا تنظیم زمان‌های بلوک نمی‌تواند به‌طور یکباره انجام شود. مشابه رویکرد گسترش، بهینه‌سازی‌های تجربی که به‌طور واقعی پیاده‌سازی می‌شوند، به مراتب بیشتر از وعده‌های صرفاً در نقشه‌راه، به توسعه‌دهندگان برنامه قطعیت می‌دهد. دستیابی به زمان‌های زیر 6 ثانیه هدف بلندمدت است و مسیر به دو مرحله تقسیم می‌شود:

• بازسازی یک‌باره: اجازه دادن به مشخصات و کد کلاینت برای تغییر انعطاف‌پذیر زمان‌های بلوک؛
• در Hegotá اولین کاهش انجام می‌شود و پس از آن، سخت‌افزار به‌طور مداوم کاهش می‌یابد و داده‌های ایمنی جمع‌آوری می‌شود.

Hegotá زمان مناسبی برای تحمل هزینه‌های بازسازی یک‌باره است. ارتقاء ePBS در ارتقاء Glamsterdam قبلاً منطق مربوط به زمان‌های بلوک را بازسازی کرده است؛ تغییرات لایه اجماع در این ارتقاء نسبتاً قابل کنترل است. به محض ورود به پنجره ارتقاء اجماع، منابع توسعه لایه اجماع به شدت تحت فشار قرار می‌گیرند و در آینده، چندین ارتقاء سخت‌افزاری دیگر به‌راحتی چنین پنجره‌ای نخواهند داشت.

به‌طور ساده، یا باید حداقل به مدت دو سال زمان‌های 12 ثانیه‌ای را حفظ کنیم، یا در ارتقاء Hegotá یک زمان 10 ثانیه‌ای را پیاده‌سازی کنیم و امیدوار باشیم که در دور بعدی به زیر 10 ثانیه برسیم. این دو تسریع نه تنها بهینه‌سازی نظری هستند، بلکه می‌توانند به‌طور مستقیم ارزش کاربران را افزایش دهند و مدل اقتصادی شبکه را بهینه‌سازی کنند. ما معتقدیم که زمان مناسب است.

پاسخ به نگرانی‌های اصلی

ما چهار نگرانی اصلی را که در ارتباطات اولیه با تیم‌های توسعه کلاینت و تیم پروتکل بنیاد اتریوم مطرح شده است، جمع‌آوری کرده‌ایم:

خلاصه (متن خالی ممکن است باشد):

• پیچیدگی توسعه. منطق زمان‌بندی با دقت میلی‌ثانیه به‌طور کامل به استاندارد توافقی ePBS ادغام شده است؛ پیش‌نویس استاندارد لایه توافق EIP-8198 و لایه اجرایی به پایان رسیده است و محاسبات هزینه پایه، حداکثر Gas و زمان‌بندی Blob به‌طور کامل انجام شده است تا رفتار شبکه در هر ثانیه پایدار باشد. کار باقی‌مانده بر روی ابزارهای مختلف کلاینت که فرضیات زمان‌بندی ثابت را سازگار می‌کنند و آزمایش سناریوهای مرزی متمرکز شده است. پس از اتمام این بازسازی یک‌باره، برای کاهش زمان‌بندی‌های آینده تنها نیاز به تنظیم پارامترها وجود دارد.
• فشار اثبات zkEVM. نگرانی‌های اصلی شامل دو مورد است: مدت زمان اثبات نسبی و هزینه ثابت اثبات. 1) مدت زمان اثبات نسبی: نسبت زمانی که می‌توان برای اثبات در یک زمان‌بندی استفاده کرد. سازندگان بلوک فعلی می‌توانند بلافاصله پس از دریافت بار بلوک قبلی شروع به ساخت کنند؛ بلوک‌های نشانه‌گذاری بار زمان‌بندی فعلی را تأیید می‌کنند. بار باید قبل از انتشار بلوک توسط پیشنهاد‌دهنده نشانه‌گذاری بعدی اثبات شود. حداقل زمان لازم برای اثبات تقریباً برابر با یک زمان‌بندی منهای تأخیر انتشار بلوک نشانه‌گذاری است. تأخیر انتشار به سختی قابل کاهش است، اما خود عدد نسبتاً کوچک است و در حال حاضر به عنوان یک گلوگاه اصلی محسوب نمی‌شود. سازندگان بلوک بهینه‌شده می‌توانند در حین جمع‌آوری بار، به‌طور موازی اثبات را انجام دهند و نیازی به انتظار برای تأیید بار برنده توسط بلوک نشانه‌گذاری ندارند. 2) هزینه اثبات zkEVM: زمان صرف‌شده برای اثبات به‌طور کلی با اندازه بلوک به‌صورت خطی مرتبط است، اما هزینه ثابت وجود دارد. سریع‌تر شدن تولید بلوک به معنای افزایش فراوانی فعال‌سازی هزینه ثابت است و در نتیجه تأخیر در حجم مشابه افزایش می‌یابد. در بودجه تأخیر ثابت، باید اطمینان حاصل شود که حجم تحت تأثیر قابل توجهی قرار نگیرد. در صنعت دو مسیر برای بهبود وجود دارد: تکرار مهندسی برای کاهش مداوم زمان صرف‌شده برای عملیات ثابت؛ EIP-7862 محاسبات ریشه وضعیت تأخیری، که کارهای اثبات زیادی را از مسیر کلیدی خارج می‌کند. پیشرفت همزمان این دو مسیر به این معنی است که زمان‌بندی‌های سریع‌تر مانع از رشد مداوم حجم در آینده نخواهند شد.
• مسیر به‌روزرسانی پساکوانتومی. طرح توافقی جداشده به اندازه کافی حمایت دریافت کرده و به سمت ثبات در ساختار توافق آینده تبدیل شده است. جداشدن به معنای انتقال رأی‌گیری تأیید نهایی از مسیر کلیدی تولید بلوک است. امضای پساکوانتومی و منطق STARK بازگشتی به‌طور گسترده از مسیر کلیدی خارج خواهند شد. تولید بلوک و قوانین انتخاب انشعاب تنها به گروهی متکی است که شامل 512 تأییدکننده (که امیدواریم به 256 نفر کاهش یابد) باشد. حجم امضای پساکوانتومی بزرگ‌تر است، اما می‌تواند در زمان‌بندی 10 ثانیه‌ای (که در آینده امیدواریم کوتاه‌تر شود) به‌راحتی منتشر شود.
• سازگاری قراردادهای هوشمند و زیرساخت. تیم در حال تحقیق جامع در مورد سناریوهای قوی مرتبط با زمان‌بندی و قراردادهای هوشمند است. ما به‌طور مشترک با Sourcify به تحلیل تمام قراردادهای تأییدشده پرداخته‌ایم؛ همچنین تأثیر تغییر زمان‌بندی بر EIP-4788 (ریشه بلوک‌های نشانه‌گذاری در EVM) و ذخیره تاریخچه ریشه‌های بلوک‌های نشانه‌گذاری را ارزیابی می‌کنیم. در سطح زیرساخت، Etherscan بازخورد داده است: تغییر زمان‌بندی احتمالاً بار سرور را افزایش می‌دهد، اما زیرساخت در دوره PoW به‌طور طبیعی با زمان‌های تولید متغیر سازگار بوده است، بنابراین دامنه تغییرات قابل کنترل است.

انتزاع حساب: بهینه‌سازی تجربه، امنیت و حریم خصوصی

اکوسیستم اتریوم مدت‌هاست که به انتزاع حساب بومی (AA) نیاز دارد تا تجربه‌هایی مانند کیف پول کلید عمومی، حمایت از معاملات، پرداخت Gas با ERC20 و معاملات گروهی را بهبود بخشد. اما مسیر تحقق انتزاع حساب بومی به‌طرز غیرمعمولی دشوار بوده است: AA به تمام لایه‌های اتریوم مربوط می‌شود و شامل کلاینت‌ها، L2، کیف پول‌ها، RPC و ابزارهای توسعه است که نیاز به همکاری چندجانبه دارد. این نه تنها باعث می‌شود که EIPهای مربوطه به سختی بتوانند فرآیند توسعه را از طریق توافق پیش ببرند، بلکه پس از راه‌اندازی نیز با چالش‌های پیاده‌سازی در اکوسیستم مواجه می‌شوند.

بنابراین ما پیشنهاد Hegotá برای AA بومی به نام Frame Transactions را در سطح A قرار داده‌ایم. این به این معنا نیست که از نظر فنی نتوان به استاندارد S رسید، بلکه نیاز به در نظر گرفتن کامل ریسک‌های پیاده‌سازی در مقیاس بزرگ اکوسیستم و هماهنگی کارهای عظیم دارد. با تکیه بر تجربیات تیم در زمینه انتزاع حساب، Ethlabs برنامه‌ریزی کرده است تا به‌طور عمیق به پیاده‌سازی Frame Transactions کمک کند و با L2، کیف پول‌ها و سایر ذینفعان همکاری کند تا اطمینان حاصل شود که AA بومی به‌خوبی راه‌اندازی می‌شود.

اکنون به بررسی پیشنهادات مرتبط با انتزاع حساب Hegotá می‌پردازیم.

【EL】EIP-8141 Frame Transactions【سطح A】

ما بر این باوریم که Frame Transactions بهترین راه‌حل برای انتزاع حساب بومی اتریوم است. در مقایسه با سایر راه‌حل‌های AA بومی، چندین ویژگی با اصول توسعه CROPS اتریوم همخوانی دارد:

• نوآوری حساب بدون مجوز: منطق تأیید توسط کد EVM اجرا می‌شود و توسعه‌دهندگان می‌توانند هرگونه قانون تأیید دلخواه را سفارشی کنند؛ برخی از طرح‌های AA منطق تأیید لیست سفید را به‌طور اجباری اعمال می‌کنند که انعطاف‌پذیری کافی ندارد؛
• سازگاری بومی با پروتکل‌های حریم خصوصی: بر اساس نکته قبلی، پروتکل‌های حریم خصوصی مانند Railgun می‌توانند منطق تأیید معاملات Frame را تحمل کنند، کاربران می‌توانند معاملات حریم خصوصی را بدون وابستگی به واسطه‌های متمرکز ارسال کنند و به‌طور قابل توجهی حریم خصوصی و مقاومت در برابر سانسور را افزایش دهند؛
• طراحی با امنیت پساکوانتومی: از ابتدا با نقشه‌راه پساکوانتومی اتریوم مطابقت دارد. از تجمیع امضا پشتیبانی می‌کند، حتی اگر هزینه تأیید یک امضای پساکوانتومی بالا باشد، تجمیع می‌تواند هزینه Gas کمتری را به‌دست آورد.

نقطه ضعف اصلی Frame Transactions نیز از انعطاف‌پذیری آن ناشی می‌شود: منطق تأیید به کد EVM واگذار شده و هزینه تأیید به‌طور دینامیک تغییر می‌کند که برای L2 که به دنبال TPS بالا هستند، چالش‌برانگیز است.

ما خوشبین هستیم که می‌توان با استانداردهای EIP/ERC همراه (مانند EIP-7819) این مشکل را حل کرد، منطق تأیید را به‌طور ایستا در معاملات اعلام کرد و مرتب‌کننده می‌تواند فرآیند تأیید را با کد بومی بهینه‌سازی کند. در عین حال، ما با L2 و بنیاد اتریوم همکاری خواهیم کرد تا آزمایش‌های مرجع انجام دهیم و گلوگاه‌های عملکرد را شناسایی و حل کنیم.

【CL】【EL】اجزای اضافی Frame Transactions

بسیاری از EIPها می‌توانند به‌عنوان گسترش معاملات Frame در نظر گرفته شوند و بر اساس آن قابلیت‌های آن را تقویت کنند.

【EL】EIP-8250 کلید تصادفی معاملات Frame【سطح A】

ما این پیشنهاد را به‌عنوان بخشی ارگانیک از EIP-8141 در نظر می‌گیریم و پیشنهاد می‌کنیم که به‌طور همزمان راه‌اندازی شود. با معرفی Nonce دو بعدی، حساب‌ها می‌توانند چندین معامله را به‌طور موازی به حافظه معاملات ارسال کنند؛ پروتکل‌های حریم خصوصی نیز می‌توانند مقادیر خالی را در Nonce دو بعدی ذخیره کنند. هزینه‌های خواندن و نوشتن Nonce دو بعدی بسیار پایین است و در مقایسه با الگوی فعلی که مقادیر خالی را به حافظه معمولی می‌نویسد، معاملات حریم خصوصی می‌توانند به‌طور قابل توجهی هزینه Gas را صرفه‌جویی کنند. این موضوع به‌ویژه در زمینه افزایش هزینه Gas ذخیره‌سازی در Glamsterdam (EIP-8037) اهمیت دارد.

【EL】EIP-8272 ریشه جدید معاملات Frame【سطح B】

به‌طور بیشتر تجربه استفاده از معاملات Frame را برای پروتکل‌های حریم خصوصی بهینه می‌کند. فرآیند تأیید پروتکل‌های حریم خصوصی نیاز به خواندن جدیدترین ریشه تعهد دارد، اگر در حافظه معمولی ذخیره شود، نه تنها هزینه بالاست بلکه با قوانین استخر معاملات عمومی Frame نیز در تضاد است. این پیشنهاد از یک بافر حلقوی قرارداد سیستم برای ذخیره داده‌های ریشه استفاده می‌کند و به‌طور خودکار داده‌های قدیمی را پاک می‌کند. دلیل اینکه در سطح B قرار گرفته این است که به‌طور قابل توجهی پیچیدگی Frame را برای یک سناریوی کاربردی واحد افزایش می‌دهد و ما مطمئن نیستیم که آیا راه‌حل‌های عمومی‌تر و ساده‌تری وجود دارد یا خیر.

【CL】EIP-8369 پیکربندی VOPS واجد شرایط FOCIL【سطح B】

تعامل بین Frame و VOPS (تنها اعتباردهی بدون حالت) را حل می‌کند. طرح VOPS به گره‌های حافظه اجازه می‌دهد تنها حداقل وضعیت تأیید معاملات را ذخیره کنند و از این طریق مقاومت استخر حافظه در برابر سانسور را در آینده در محیط بدون حالت zkEVM تضمین می‌کند. در سطح B قرار گرفته است زیرا این طرح به شدت به یک مجموعه از مسیرهای بدون حالت که هنوز توافق اجتماعی شکل نگرفته است، وابسته است.

【EL】EIP-7906 انجام تأیید معاملات از طریق کد عملیاتی تفاوت وضعیت【سطح B】

قابلیت حسابرسی نتایج معاملات را به‌طور ایستا افزایش می‌دهد. کاربران در حال حاضر می‌توانند نتایج مثبت را تأیید کنند، اما نمی‌توانند «عدم وجود تغییرات وضعیت دیگر» را محدود کنند. برای اثبات عدم وجود تغییرات وضعیت اضافی، نیاز به افزودن کد عملیاتی جدید است. تأیید مثبت (مانند افزایش حداقل 1.5 در موجودی WETH) به همراه تأیید منفی (عدم وجود تغییرات وضعیت دیگر) می‌تواند بدون شبیه‌سازی تمام تأثیرات معامله را قفل کند و کیف پول‌های سخت‌افزاری اصلی‌ترین صحنه‌های بهره‌مند هستند. این پیشنهاد پیچیدگی بالایی دارد و نیاز به احتیاط در گنجاندن در هارد فورک دارد. پیشنهاد می‌شود که دو شرط را برآورده کند: ① تیم کلاینت تمام جزئیات و تأثیرات زنجیره‌ای را به‌خوبی درک کند؛ ② دامنه آزمایش و ارزیابی ریسک‌های بالقوه کامل باشد.

【EL】مهاجرت EOA【سطح B】

EIP-7851 و EIP-8151 باید به‌طور مشترک در نظر گرفته شوند و به‌طور مشترک طرح مهاجرت حساب‌های خارجی به حساب‌های هوشمند را تشکیل دهند. مسیر به این صورت است: EOA ابتدا از طریق EIP-7702 به حساب هوشمند واگذار می‌شود؛ EIP-7851 کد عملیاتی جدیدی را اضافه می‌کند که رابطه واگذاری را به‌طور دائمی تثبیت می‌کند و کلید ECDSA اصلی را غیرفعال می‌کند؛ EIP-8151 به ecRecover اجازه می‌دهد تا شناسایی کند که کلید غیرفعال شده است و از سرقت دارایی‌ها توسط کلیدهای قدیمی از طریق معاملات Permit جلوگیری می‌کند. رتبه‌بندی سطح B به این دلیل است که این تنها یکی از طرح‌های مهاجرت EOA است و هنوز ارزیابی و توافق اجتماعی گسترده‌ای دریافت نکرده است. بزرگ‌ترین خطر در سازگاری چند زنجیره‌ای است: کاربران باید عملیات مهاجرت را در هر L2 تکرار کنند، از جمله زنجیره‌هایی که هنوز ایجاد نشده‌اند، که تجربه کاربری ضعیفی را به همراه دارد. ما امیدواریم که یک طرح مبتنی بر L1 به‌عنوان ریشه اعتماد وجود داشته باشد که یک عملیات برای تمام زنجیره‌های EVM مناسب باشد، این نوع طرح‌ها می‌توانند به سطح A/S ارتقا یابند.

【EL】استاندارد امضای پساکوانتومی【سطح A】

Hegotá باید مسیر روشنی برای پیاده‌سازی امضای پساکوانتومی تعیین کند، اما نیاز به تعیین مکانیزم بهینه قبل از پیاده‌سازی رسمی دارد. EIP-8355 قرارداد پیش‌کامپایل ML-DSA را اضافه می‌کند: با همکاری معاملات Frame، امنیت حساب‌های پساکوانتومی را به‌دست می‌آورد. گزینه‌های جایگزین: پیش‌ثبت نام برای پشتیبانی از امضای پساکوانتومی اما هنوز فعال نشده، یا تعریف فرمت استخراج کلیدهای سازگار با پساکوانتوم.

【EL】EIP-7819 دستور SETDELEGATE【سطح A】

زمانی که AA بومی در Hegotá پیاده‌سازی شود، کاهش هزینه‌های استقرار حساب‌های هوشمند بسیار مهم است. اما EIP-8037 در Glamsterdam هزینه‌های ایجاد حساب را افزایش می‌دهد. EIP-7819 به حساب‌های جدید اجازه می‌دهد از اشاره‌گرهای واگذاری سبک‌وزن استفاده کنند، به‌جای قراردادهای نمایندگی، به‌طور قابل توجهی ذخیره‌سازی وضعیت جدید را کاهش می‌دهد و هزینه‌های استقرار را کاهش می‌دهد. رتبه‌بندی سطح A به این دلیل است که هزینه‌های پایین‌تر استقرار حساب می‌تواند به‌طور قابل توجهی مانع ورود به AA را کاهش دهد.

بهینه‌سازی عملکرد: ادامه گسترش L1

Glamsterdam نشانه‌ای از تغییر در تفکر توسعه اتریوم است: عملکرد به محدودیت اصلی طراحی پروتکل و توسعه کلاینت تبدیل شده است. تأخیر در اجرا، تنظیم قیمت منابع و بهینه‌سازی کلاینت‌های بزرگ‌مقیاس، در دو سال ظرفیت شبکه را از 30 میلیون Gas به حداقل 200 میلیون Gas افزایش داده است. بهینه‌سازی عملکرد انتخاب را به همراه دارد و ظرفیت آزاد شده می‌تواند برای گسترش، کاهش زمان‌بندی، کاهش آستانه سخت‌افزاری گره‌ها یا همزمان به‌دست آوردن چندین هدف استفاده شود.

نیاز به گسترش همچنان فوری است. انتخاب محل پروژه نه تنها به قیمت‌های فعلی Gas بستگی دارد، بلکه باید دید آیا اتریوم می‌تواند به‌طور پایدار و مداوم فضای بلوک را گسترش دهد. ادامه پیاده‌سازی به‌روزرسانی‌های گسترش، بسیار بیشتر از نقشه‌راه‌های کاغذی می‌تواند به توسعه‌دهندگان اطمینان دهد. شبکه اصلی هنوز فاصله‌ای برای پذیرش پایدار اوج ترافیک دارد: در روز یازدهمین سالگرد اتریوم، میانه Gas تنها حدود 0.1 gwei بود، و یک فعالیت ضرب NFT Gas را به محدوده 10 gwei رساند و هزینه میانه معاملات از 1 دلار فراتر رفت. روند گسترش آغاز شده در Glamsterdam باید تا Hegotá ادامه یابد.

به طور کلی، EIP های زیر به گسترش Glamsterdam ادامه می‌دهند و در عین حال اصول گسترده‌تری را که پشت آن‌ها وجود دارد، تقویت می‌کنند: عملکرد باید همیشه در طراحی پروتکل و کار در سمت کلاینت در اولویت باشد.

【EL】EIP-8131 & EIP-8279【سطح S】

پیشنهاد ترکیب قیمت‌گذاری داده‌ها پس از ارتقاء Glamsterdam، گلوگاه‌های اصلی شبکه به بارگذاری بلوک تبدیل شده است. ریشه این مشکل در عدم یکپارچگی استانداردهای محاسبه گاز برای انواع مختلف منابع بایت است و حتی برخی از آن‌ها هزینه‌ای ندارند. EIP-8131 حداقل هزینه‌های پایه معاملات را یکپارچه می‌کند: این قانون حداقل هزینه‌های معاملات موجود را به داده‌هایی که قبل از اجرا می‌توانند تأیید شوند، گسترش می‌دهد؛ EIP-8279 حداقل بایت‌های لیست دسترسی بلوک را تعیین می‌کند: هزینه بایت‌های لیست دسترسی که به صورت دینامیک در حین اجرا تولید می‌شوند.

مکانیزم محاسبه دینامیک باعث می‌شود EIP-8279 پیچیدگی بیشتری داشته باشد، اما این دو باید به صورت ترکیبی مورد بررسی قرار گیرند. این طرح ترکیبی محاسبه بایت‌های مرتبط با معاملات را یکپارچه می‌کند و بدترین حالت بارگذاری بلوک را محدود می‌کند، در حالی که اکثر معاملات عادی و کم‌حجم تحت تأثیر قرار نمی‌گیرند. این امر شکاف‌های محاسبه منابع را پر می‌کند و موانع را برای افزایش بیشتر حد بالای گاز در آینده برطرف می‌کند.

【CL】【EL】EIP-8146 【سطح A】

EIP-8146 با جدا کردن BAL و بار مفید، مسیر کلیدی را بهبود می‌بخشد و مکانیزم قیمت‌گذاری مجدد را کامل می‌کند. این نه تنها کارایی انتشار را افزایش می‌دهد، بلکه به کلاینت‌های اجرایی در محاسبات پیش‌دریافت وضعیت و ریشه وضعیت برتری می‌دهد. ما این را به عنوان یک بهینه‌سازی با آستانه پایین که نباید از دست برود، می‌دانیم. کار انجام شده عمدتاً بر اساس مکانیزم gossip CL آشنا است، بنابراین این یک EIP با سرمایه‌گذاری کم و ارزش بالا است، به ویژه در یک شاخه با حجم کد EL بزرگتر.

پیشنهادات دیگر مرتبط با گسترش

【EL】CPSB تنظیم مجدد【سطح A】

تغییرات ساده است. ما پیشنهاد می‌کنیم که ادامه دهیم و بر اساس برنامه، حد بالای گاز را افزایش دهیم و وضعیت زنجیره‌ای و استفاده از گاز اجرایی را در نظر بگیریم. EIP-8368 تنظیم CPSB متناسب با حد بالای جدید گاز: طرح‌های مکمل پس از EIP-8037. هزینه بایت‌های وضعیت از تنظیم دینامیک با حد بالای گاز به یک مقدار ثابت تغییر می‌کند و توسعه و آزمایش را ساده می‌کند. CPSB فعلی بر اساس حد بالای 150 میلیون گاز محاسبه شده است و پس از افزایش حد بالای گاز، احتمالاً Hegotá نیاز به تنظیم دارد. EIP-8372 استانداردسازی حد بالای گاز وضعیت: بخشی از طرح توسعه EIP-8368 است که دقت تنظیم را بیشتر می‌کند و به سناریوهایی که هدف رشد وضعیت و انحراف از اهداف گاز معمولی را دارند، پاسخ می‌دهد.

【EL】EIP-7862 تأخیر در ریشه وضعیت【سطح B】

خود استاندارد بسیار ساده است، اما به آنچه که ما می‌دانیم، پیچیدگی پیاده‌سازی کلاینت به طور کامل درک نشده است. ریشه وضعیت به طور گسترده‌ای در کدبیس وجود دارد. منافع کوتاه‌مدت محدود است و ارزش اصلی در بلندمدت (طولانی‌تر کردن مدت زمان قابل استفاده برای اثبات ریشه وضعیت) متمرکز است. فشار تغییرات لایه اجرایی Hegotá در حال حاضر زیاد است.

【CL】EIP-8341 تعهد بار مفید اجرایی جزئی【سطح D】

پیشنهاد می‌شود که در نظر گرفته نشود. منافع محدود (کمی تأخیر در محاسبه ریشه وضعیت) و نیاز فوری وجود ندارد و EIP-7862 می‌تواند اثرات قوی‌تری را ایجاد کند و می‌تواند به طور مستقیم جایگزین شود.

بحث‌های دسته‌بندی EIP باقی‌مانده

در ادامه، پیشنهادات باقی‌مانده را بر اساس موضوع گروه‌بندی می‌کنیم. برخی از پیشنهادات هنوز در حال شکل‌گیری دیدگاه ما هستند و در آینده با تیم کلاینت و نویسندگان به‌روزرسانی‌های مداوم خواهیم داشت.

Hegotá انتظار می‌رود که یک هارد فورک با تمرکز بر تغییرات لایه اجرایی باشد و ما باید به شدت در مورد آستانه پذیرش EIP لایه اجرایی کنترل داشته باشیم. به جز FOCIL و Quick Slots، سعی کنیم دامنه تغییرات لایه اجماعی را کنترل کنیم: دامنه ارتقاء را کاهش دهیم و زمان کافی برای تیم کلاینت برای پاسخ به تحولات بزرگ آینده فراهم کنیم.

【CL】مکانیزم انتشار مرتبط

ما به EIP-8363 انتشار تدریجی و اولویت‌بندی نابودی را نمی‌دهیم. سیاست انتشار تورمی نباید به طور یک‌جانبه توسط توسعه‌دهندگان اصلی تعیین شود و لیست اولویت‌ها معادل ارائه پیشنهادات مشخص به توسعه‌دهندگان اصلی است. اکثریت EIP‌ها به سمت تصمیم‌گیری‌های فنی متمایل هستند و جامعه حق تصمیم‌گیری را به تیم توسعه اصلی واگذار می‌کند؛ اما مکانیزم انتشار بخشی از سیاست پولی است که نیاز به توافق گسترده جامعه دارد. نظرات توسعه‌دهندگان اصلی تنها به عنوان مرجع بحث عمومی در نظر گرفته می‌شود. اگر آن را با EIP‌های عادی هم‌ردیف کنیم، معادل این است که آن را به عنوان یک تصمیم‌گیری فنی ACD معمولی در نظر بگیریم.

از نظر فنی، EIP-8363 دارای ارزش است. با افزایش مجموع ETH استیک شده، اعتبار مکانیزم جریمه کاهش می‌یابد؛ در نرخ استیک بالا، پاداش‌های جدید عمدتاً تورم را جبران می‌کنند؛ اثر مقیاس به طور مداوم فاصله بین اپراتورهای بزرگ و استیک‌کنندگان مستقل را افزایش می‌دهد. اما تغییرات همچنین با ریسک همراه است: الگوی توزیع استیک کردن نامشخص است و روند تثبیت سیاست پولی دوباره آغاز خواهد شد. پست بحث منتشر شده توسط Ansgar به طور کامل نظرات مثبت و منفی را فهرست می‌کند و با موضع ما هم‌راستا است. برخی از اعضای تیم قبلاً از تغییر مکانیزم انتشار حمایت کرده‌اند و در حال حاضر همچنان این قضاوت را حفظ می‌کنند.

ما پیشنهاد می‌کنیم که پس از تعیین همه دامنه‌های دیگر Hegotá، در مورد تغییر مکانیزم انتشار بحث کنیم. زمان کافی برای بحث جامعه فراهم کنیم تا از اختلال در تعیین دامنه ارتقاء جلوگیری کنیم.

【CL】بهینه‌سازی عملکرد استیک کردن

بهبود استیک کردن دارای ارزش است، اما اولویت باید به بهینه‌سازی‌های مربوط به کاربران نهایی داده شود و تغییرات زیرساختی صرفاً در صورت لزوم باید انجام شود.

【CL】EIP-8015 حذف فیلدهای سپرده و eth1data【سطح A】

پاکسازی سبک بدهی‌های تاریخی فنی. با تکیه بر EIP-7688 به ساختار داده‌های اجماعی سازگار است و مدارک غیر مرتبط بر اثبات مرکل تأثیر نمی‌گذارد و بر خواندن داده‌های زنجیره‌ای تأثیری نخواهد داشت.

【EL】【CL】EIP-8237 همگام‌سازی مستقل لایه اجماعی / لایه اجرایی【سطح B】

بر اساس جداسازی ePBS بلوک‌های نشانه و بار، اجازه می‌دهد CL و EL به طور مستقل همگام‌سازی شوند و امیدواریم که منطق پیچیده کلاینت را ساده‌تر کند.

【CL】EIP-8205 پیش‌ثبت رسید برداشت【سطح D】

پیشنهاد می‌شود که در نظر گرفته نشود. اگرچه این مشکل واقعی استیک کردن را حل می‌کند، اما طرح‌های سپرده‌گذاری موجود قبلاً قادر به پاسخگویی هستند و پیچیدگی ناشی از مکانیزم پروتکل جدید در حال حاضر با منافع مطابقت ندارد.

【CL】EIP-8148 آستانه تسویه‌ حساب سفارشی برای تأییدکنندگان【سطح D】

پیشنهاد می‌شود که در نظر گرفته نشود. مکانیزم پیچیده است (قراردادهای سیستم جدید، درخواست‌های اجرایی، منطق لایه اجماعی) و منافع محدود است و تنها به طور جزئی ادغام استیک‌کنندگان خرد را پیش می‌برد. با توجه به الگوی توزیع استیک کردن فعلی، تغییر قابل توجهی در روند تمرکز تأییدکنندگان در شبکه ایجاد نخواهد کرد.

【CL】EIP-8372 نابودی اجباری پاداش‌های اجرایی ePBS【سطح D】

پیشنهاد می‌شود که در نظر گرفته نشود. احتمالاً فقط منجر به ایجاد کانال‌های بیشتر خارج از زنجیره خواهد شد. بحث‌های نابودی MEV در سال‌های اخیر به توافق گسترده‌ای نرسیده است.

【CL】EIP-7716 مجازات اثبات ضد مرتبط【سطح D】

پیشنهاد می‌شود که در نظر گرفته نشود. شواهد کافی برای حمایت از تغییرات عمده در مکانیزم انگیزشی استیک کردن وجود ندارد و جداسازی ارتقاء اجماعی نیاز به طراحی مجدد سیستم انگیزشی استیک کردن خواهد داشت.

【CL】EIP-8333 هم‌راستایی نقاط عطف با بلوک‌های مرزی دوره【سطح D】

پیشنهاد می‌شود که در نظر گرفته نشود. این بهینه‌سازی بخشی از کار پاکسازی است و می‌تواند به تأخیر بیفتد تا با ارتقاء بزرگ‌تر جداسازی اجماعی پیش برود.

【CL】EIP-8359 فیلد گزارش بلوک نشانه【دیدگاه در حال شکل‌گیری】

【CL】کارهای مقدماتی ارتقاء پساکوانتومی

پیشنهادات زیر وابستگی به امضای BLS را کاهش می‌دهند و راه را برای انتقال پساکوانتومی در آینده هموار می‌کنند.

【CL】EIP-8365 حذف رسید برداشت BLS【سطح A】

حذف رسید برداشت قدیمی، ساده‌سازی پروتکل و هموار کردن راه برای انتقال پساکوانتومی در آینده. تغییرات ساده است و برای پیاده‌سازی فعلی مناسب است.

【CL】EIP-8367 حذف مکانیزم انقضای موجودی تأییدکننده BLS【سطح D】

پیشنهاد می‌شود که در نظر گرفته نشود. اکثریت تأییدکنندگان با گواهی 0x0 قبل و بعد از راه‌اندازی EIP-8365 به احتمال زیاد مهاجرت خواهند کرد، وجوه را برداشت یا به استیک کردن ادامه خواهند داد. نیازی به مکانیزم جدید برای مدیریت موجودی باقی‌مانده نیست، ابتدا EIP-8365 را پیاده‌سازی کرده و وضعیت واقعی را مشاهده کنید.

【CL】EIP-8321 زنجیره هش RANDAO【سطح D】

پیشنهاد می‌شود که در نظر گرفته نشود. تنها پیاده‌سازی RANDAO پساکوانتومی به تنهایی معنای زیادی ندارد و کلید BLS تأییدکننده هنوز در معرض خطر است؛ همچنین هر تأییدکننده 32 بایت داده اضافی را اضافه می‌کند و منطق مدیریت کلید جدیدی را ایجاد می‌کند که کاربردی واحد دارد. طرح کامل اجماع پساکوانتومی هنوز پیاده‌سازی نشده است. ما از ارتقاء تدریجی حمایت می‌کنیم، اما اولین قدم باید از یک نقشه‌راه یکپارچه پیروی کند تا از جایگزینی طرح‌ها با استاندارد نهایی جلوگیری شود.

【EL】【CL】بهینه‌سازی سازگاری zkEVM

بیشتر بهینه‌سازی‌های مقدماتی zkEVM منافع کوتاه‌مدت محدودی دارند و تنها برای گروه خاصی از افراد برای اجرای نودهای کامل راحت‌تر می‌شوند و در عین حال منابع توسعه را اشغال می‌کنند و ممکن است هزینه‌های اجرای EVM را افزایش دهند. تنها پیشنهاداتی که ارزش بلندمدت به‌طور قابل توجهی بالاتر از هزینه‌های کوتاه‌مدت دارند، مناسب برای گنجاندن هستند.

【CL】EIP-8025 اثبات اجرایی اختیاری【سطح D】

این ارتقاء نباید گنجانده شود. خود پیشنهاد به طور اجباری هارد فورک نیست و پیوست به Hegotá تنها یک درخواست اولویت است که ما با آن موافق نیستیم. قبل از پیاده‌سازی اثبات اختیاری، باید شکل نهایی بلندمدت به وضوح مشخص شود و به آرامی پیش برود و نباید قبل از تثبیت مدل تأییدکننده / وضعیت به سرعت راه‌اندازی شود. مسئله اصلی که باید حل شود: آیا تأییدکنندگان باید بخشی از وضعیت را حفظ و ذخیره کنند یا کاملاً بدون وضعیت باشند. تأییدکنندگان گروه مهمی از نودها هستند که منابع سخت‌افزاری و شبکه‌ای دارند و تغییراتی که نقش آن‌ها را تضعیف می‌کند نیاز به استانداردهای پذیرش بالاتری دارد.

【EL】EIP-7666 پیش‌کامپایل هویت به EVM【سطح A】

تغییرات کوچک و دارای ارزش عملی است.

【EL】EIP-8200 پیش‌کامپایل به EVM【سطح B】

استفاده از بایت‌کد EVM برای جایگزینی سه نوع پیش‌کامپایل بومی. دو نوع استفاده کم و دشواری کم در مهاجرت؛ نوع سوم به طور گسترده‌ای در اثبات SNARK استفاده می‌شود. نیاز به ارزیابی تأثیر دارد تا هزینه‌های مهاجرت قابل کنترل باشد، یا نوع سوم را از دامنه خارج کنیم، سپس ما آن را به سطح A افزایش خواهیم داد.

【EL】EIP-7709 خواندن BLOCKHASH از ذخیره و تنظیم گاز【سطح D】

افزایش گاز نسبتاً زیاد است و اختلال قابل توجهی دارد و نیاز فوری وجود ندارد. برای کاهش ریسک می‌توان ارزیابی تأثیر را انجام داد یا با مکانیزم پیش‌گرم بلوک به تأخیر انداخت.

【EL】EIP-8268 گنجاندن لیست دسترسی بلوک در ریشه ذخیره【سطح B】

نیاز به ارزیابی تأثیر واقعی بر حجم لیست دسترسی و هزینه گاز معاملات دارد (EIP-8279 هزینه بایت‌های لیست دسترسی را محاسبه خواهد کرد)، هر ورودی حساب اضافی به همراه ریشه مرکل ذخیره می‌شود.

【EL】عملکرد بومی EVM

هگوتا هنوز هم برخی از بهبودهای پراکنده EVM را پیاده‌سازی خواهد کرد. ما بر این باوریم که پس از این به‌روزرسانی، اتریوم باید با همکاری کل اکوسیستم EVM یک نقشه راه توسعه بلندمدت برای EVM تدوین کند و Ethlabs در این زمینه مشارکت خواهد کرد.

【EL】EIP-5920 کد عملیاتی PAY【رده A】

منطق ساده‌ای دارد و یکی از زیرساخت‌های با ارزش EVM است. هنوز نیاز به روشن‌سازی بیشتر در مورد سناریوهای واقعی کاربرد دارد.

【EL】EIP-8163 کد عملیاتی EXTENSION (0xae)【رده A】

برای L2 بسیار کاربردی است و برای L1 تقریباً هیچ هزینه‌ای ندارد و فقط به عنوان یک علامت رزرو شده است.

【EL】بازاستفاده از کد قرارداد【رده B】

EIP-8058 تخفیف در حذف کدهای بایت قرارداد و EIP-8298 دستورالعمل بازاستفاده SETCODEFROM بر اساس مدل ذخیره‌سازی کلاینت: کد قرارداد به‌طور مستقل ذخیره می‌شود و حساب‌ها فقط از طریق هش کد به کد اشاره می‌کنند. هر دو پیشنهاد یک کد مشابه را تنها یک بار ذخیره می‌کنند و هزینه‌های استقرار را کاهش می‌دهند. این ایده جذاب است، اما نیاز به ارزیابی تأثیر آن بر سازگاری پیشرفته ساختار ذخیره‌سازی درختی دارد. در حال حاضر هیچ ترجیح واضحی برای این دو پیشنهاد وجود ندارد.

【EL】اصلاح قیمت‌گذاری حافظه【رده B】

ما هنوز نتوانسته‌ایم تعیین کنیم که آیا اصلاح حافظه در هگوتا مناسب است یا خیر. در حال حاضر درک ما از فضای طراحی کافی نیست.

EIP-7686 حداکثر حافظه خطی EVM: تغییرات جزئی، هزینه‌های گسترش حافظه دو مرحله‌ای حذف شده است؛

EIP-7923 قیمت‌گذاری حافظه خطی مبتنی بر صفحه‌بندی: قوانین زیرساخت را بازسازی می‌کند و کامل‌تر است، اما پیچیدگی بیشتری دارد.

【EL】EIP-8219 کد عملیاتی حساب‌های ریاضی با بررسی سرریز【رده B】

افزودن قابلیت محاسبات ایمن به EVM ارزشمند است. نیاز به آزمایش‌های پایه برای تأیید قیمت‌گذاری معقول دارد؛ پس از تکمیل ارزیابی تأثیر (مقیاس معاملات سودآور، وضعیت سازگاری کامپایلر) احتمالاً به سطح A ارتقا خواهد یافت.

【EL】EIP-8360 کد عملیاتی TCREATE【رده B】

از ایجاد قراردادهای موقت در طول چرخه حیات معاملات پشتیبانی می‌کند، اما پیچیدگی پیشنهاد بالاست و پس از ارزیابی دشواری توسعه و آزمایش می‌توان دوباره درجه‌بندی کرد.

【EL】EIP-7645 اشاره‌گر ORIGIN به SENDER【رده D】

پیشنهاد می‌شود که در نظر گرفته نشود. این یک تغییر مخرب است و معنای ORIGIN را سوءاستفاده می‌کند.

【EL】EIP-8182 انتقال ETH و ERC20 خصوصی بومی【رده D】

پیشنهاد می‌شود که در نظر گرفته نشود. مقیاس تغییرات بسیار بزرگ است و وابستگی به ZK را معرفی می‌کند. اگر در آینده پیاده‌سازی شود، باید به عنوان پیشنهاد اصلی به‌روزرسانی در نظر گرفته شود.

【EL】EIP-2488 حذف کد عملیاتی CALLCODE【نظر در حال شکل‌گیری】

【EL】EIP-4758 توقف SELFDESTRUCT【نظر در حال شکل‌گیری】

【EL】EIP-7979 کدهای عملیاتی فراخوانی و بازگشت EVM【نظر در حال شکل‌گیری】

【EL】EIP-8173 پایه‌های جریان کنترل EVM【نظر در حال شکل‌گیری】

【EL】EIP-8253 افزایش خودکار Nonce حساب‌های ذخیره‌سازی صفر【نظر در حال شکل‌گیری】

【EL】EIP-8030 افزودن پشتیبانی از الگوریتم P256【نظر در حال شکل‌گیری】

【EL】مکانیزم قیمت‌گذاری EVM

Glamsterdam هزینه‌های گاز عملیاتی را که محدودکننده توان عملیاتی است، افزایش داده است. پیشنهادات قیمت‌گذاری مرتبط با هگوتا در جهت مخالف است: کاهش هزینه‌های عملیاتی که به طور غیرضروری بالا است و مانع از پیاده‌سازی برنامه‌ها می‌شود، اما سهم کمی در گسترش شبکه دارد و به عنوان بهینه‌سازی‌های اضافی در نظر گرفته می‌شود. ما از تنظیم قیمت هدفمند حمایت می‌کنیم، اما پیشنهادات مدل‌های جدید قیمت‌گذاری باید به‌خوبی طراحی شده و دارای پیش‌برندگان قوی برای تأیید کامل ریسک‌ها باشند تا قابل پذیرش باشد.

【EL】EIP-8358 محاسبه خالص گاز تغییرات حساب【رده B】

سود مشکوک است. نمونه‌ای از 900 بلوک شبکه اصلی و 400000 معامله نشان می‌دهد: تنها 2.07% معاملات صرفه‌جویی در گاز دارند و مجموع صرفه‌جویی در گاز بلوک تنها 1.14% است.

【EL】EIP-7973 محاسبه نوشتن حساب‌های داغ【نظر در حال شکل‌گیری】

【EL】EIP-7609 کاهش گاز پایه TLOAD/TSTORE【نظر در حال شکل‌گیری】

【EL】EIP-7971 حداکثر سخت‌افزاری ذخیره‌سازی لحظه‌ای【نظر در حال شکل‌گیری】

【EL】EIP-3298 حذف بازپرداخت گاز【نظر در حال شکل‌گیری】

【EL】EIP-8374 حفظ مجموعه دسترسی داغ پس از بازگشت【نظر در حال شکل‌گیری】

【EL】EIP-8115 دریافت اولویت هزینه به صورت انبوه در انتهای بلوک【نظر در حال شکل‌گیری】

【EL】EIP-8188 ثبت آخرین نوشتن بلوک حساب و محل ذخیره‌سازی【نظر در حال شکل‌گیری】

【EL】【CL】داده‌های اجرایی و نمایه‌سازی

【EL】【CL】EIP-7668 حذف فیلترهای بلوم【نظر در حال شکل‌گیری】

【EL】【CL】EIP-7807 بلوک‌های اجرایی با فرمت SSZ【نظر در حال شکل‌گیری】

【EL】EIP-8116 ساده‌سازی فیلدهای رسید انباشته【نظر در حال شکل‌گیری】

【EL】EIP-8304 نمایه‌سازی معاملات و لاگ‌های بدون نیاز به اعتماد【نظر در حال شکل‌گیری】

【EL】【CL】لایه شبکه

شبکه P2P اتریوم هنوز فضای بهینه‌سازی هدفمند دارد، به ویژه در زمینه معاملات، Blob و مکانیزم انتشار پیام‌های اثبات.

【CL】EIP-8371 بازسازی توزیع شده Blob RowDAS【رده A】

از بازسازی کامل و میزبانی نودهای کامل به عنوان گلوگاه گسترش Blob جلوگیری می‌کند. در بلندمدت، مکانیزم بازسازی توزیع شده به طور حتم باید در پروتکل گنجانده شود و می‌تواند الزامات میزبانی Blob را برای تأییدکنندگان برطرف کند. هنوز نیاز به ارزیابی بیشتر در مورد پیچیدگی پیاده‌سازی وجود دارد.

【CL】EIP-8142 بلوک‌های BiB درون‌ساخت Blob【رده D】

زمان مناسب نیست، فوریت کافی وجود ندارد و مسائل زیادی باقی مانده است (آیا KZG را استفاده کنیم، موضوع پخش جدید ایجاد کنیم). نمی‌خواهیم مکانیزم KZG را به مسیر کلیدی تولید بلوک وارد کنیم و جایگزین‌های آن هنوز مشخص نیستند.

【CL】EIP-8243 پخش انبوه اثبات از منبع【رده D】

نمی‌توان به وضوح تضمین کرد که زمان تأیید نهایی را کاهش می‌دهد و حداکثر بار نامشخص است؛ توانایی دفاع در برابر DoS مکانیزم نیاز به تأیید دارد.

【EL】EIP-8077 معاملات مبتنی بر Nonce با eth/XX【نظر در حال شکل‌گیری】

【EL】EIP-8094 پروتکل استخر معاملات Blob با eth/vhash【نظر در حال شکل‌گیری】

【CL】EIP-8334 پخش انبوه اثبات【نظر در حال شکل‌گیری】

خاتمه

به‌روزرسانی اتریوم خطرات بسیار بالایی دارد و بنابراین پیچیدگی آن اجتناب‌ناپذیر است. هزاران گره در سراسر جهان باید در یک زمان مشخص قوانین را همزمان تغییر دهند و عملکرد شبکه نباید قطع شود. این دقت پشتیبان به‌روزرسانی‌های موفق اتریوم بوده و به یک شبکه غیرمتمرکز بدون قطعی 11 ساله دست یافته است.

این موارد نظر فعلی Ethlabs در مورد هگوتا است. با پیشرفت توسعه و عمیق‌تر شدن بحث‌ها، به محض ظهور شواهد جدید، ما نظرات خود را به‌روزرسانی خواهیم کرد. برخی از EIPها توسط اعضای Ethlabs رهبری می‌شوند و سایر پیشنهادات از محققان، توسعه‌دهندگان کلاینت و مشارکت‌کنندگان مستقل برجسته اتریوم ناشی می‌شوند. اما برای اینکه همه طرح‌ها به واقعیت بپیوندند، همکاری تیم‌های کلاینت، کیف پول‌ها، برنامه‌ها، L2، ارائه‌دهندگان زیرساخت، نهادها، اپراتورهای گره و کاربران نهایی ضروری است. اتریوم متعلق به کل جهان است و پیشرفت‌های بزرگ شبکه هرگز نتیجه یک سازمان واحد نیست.