توسعهدهندگان اتریوم به صورت موقت تاریخ ارتقای گلمستردام (Glamsterdam) را برای فعالسازی در سپولیا (Sepolia) در تاریخ 6 اکتبر 2026، ساعت 13:53 به وقت جهانی (UTC)، برنامهریزی کردهاند، در حالی که قبل از شروع فورک شبکه آزمایشی عمومی، یک آزمایش دیگر در شبکه توسعه خصوصی ضروری است.
یادداشتهای نشست ACDC #186 و گزارشهای بعدی از کریستین دی. کیم، پژوهشگر پروتکل اتریوم، نشان میدهد که این تاریخ همچنان مشروط است. توسعهدهندگان، هنگام انتخاب برنامه سپولیا، فعالسازی پایدار گلمستردام را در یک شبکه توسعه خصوصی تکمیل نکرده بودند.
برنامه آزمایشی از آن زمان یک مرحله دیگر پیش رفته است. کیم در 11 سپتامبر گفت که توجه به Glamsterdam-Devnet-11 معطوف شده است که انتظار میرود دوشنبه، 14 سپتامبر راهاندازی شود. برنامههای قبلی Devnet-10 را به عنوان آزمایش اصلی بعدی شناسایی کرده بودند.
هیچ تاریخ فعالسازی برای شبکه آزمایشی هودی (Hoodi) یا شبکه اصلی اتریوم تأیید نشده است. توسعهدهندگان درباره انتشار احتمالی شبکه اصلی در دسامبر بحث کردهاند، اما نتایج آزمایشها تعیین خواهد کرد که آیا این برنامه عملی باقی میماند یا خیر.
در طول جلسه اجماع توسعهدهندگان اصلی در 3 سپتامبر، شرکتکنندگان بر اپوک 351232 سپولیا برای فعالسازی پیشنهادی توافق کردند. کیم گزارش داد که زمان مربوطه 6 اکتبر ساعت 13:53 به وقت جهانی (UTC) خواهد بود. این جلسه قبل از آن برگزار شد که توسعهدهندگان عملکرد پایدار را در شبکههای آزمایشی خصوصی مورد استفاده برای گلمستردام نشان دهند.
انتخاب اپوک یک هدف برنامهریزی مشترک برای تیمهای کلاینت، اپراتورهای زیرساخت و توسعهدهندگان اپلیکیشن فراهم میکند. این امر فعالسازی را نهایی نمیکند. توسعهدهندگان میتوانند فورک را به تعویق بیندازند اگر فاز بعدی آزمایش، نقص بزرگی را کشف کند یا اگر تیمهای کلاینت نتوانند نسخههای قابل اعتماد آماده کنند.
این هشدار پس از آنکه Devnet-9 مشکلات قطعیت را تجربه کرد، همچنان مرتبط است. طبق مواد جلسه، این شبکه شامل تقریباً 1000 گره اعتبارسنج بود که آن را در آن مرحله به بزرگترین Devnet گلمستردام از نظر تعداد اعتبارسنجها تبدیل میکرد.
قطعیت مستلزم آن است که تعداد کافی اعتبارسنج در مورد وضعیت زنجیره توافق کنند. هنگامی که یک شبکه آزمایشی در نهایی کردن شکست میخورد، توسعهدهندگان باید تعیین کنند که آیا علت شامل نرمافزار کلاینت، مشارکت اعتبارسنج، پیکربندی شبکه یا تعامل بین تغییرات پروتکلی جداگانه است.
برنامه اولیه پس از بروز خطاها در آزمایشهای قبلی، Devnet-10 را درخواست کرده بود. بهروزرسانی اخیر کیم اکنون Devnet-11 را به عنوان آزمایش بعدی که توسعهدهندگان در حال مشاهده آن هستند، شناسایی میکند که نشان میدهد توالی آزمایش خصوصی فراتر از برنامه قبلی پیش رفته است.
یک Devnet-11 پایدار محیط دیگری را برای تیمهای کلاینت اتریوم برای آزمایش مشخصات ترکیبی گلمستردام فراهم میکند. تیمهای لایه 2، ارائهدهندگان استیکینگ و سایر اپراتورهای زیرساخت قبل از اینکه بتوانند با خیال راحت سیستمهای خود را در برابر فورک پیشنهادی آزمایش کنند، به پیادهسازیهای کلاینت کارآمد نیاز دارند.
تنوع کلاینت فرآیند را پیچیدهتر میکند. اتریوم از طریق چندین کلاینت اجرای و اجماع توسعهیافته مستقل عمل میکند و ارتقا باید در ترکیبهای مختلف کلاینت کار کند. یک خطای محدود به یک پیادهسازی میتواند همچنان شبکه آزمایشی را مختل کند اگر اعتبارسنجهای تحت تأثیر وزن کافی داشته باشند.
دستور کار ACDC #186 درخواستهایی از لیدو (Lido) و اپتیمیسم (Optimism) برای حداقل یک روز پایدار قبل از فورک را ثبت میکند. دستور کار، اصلاحات کلاینت و قابلیت همکاری موفق را به عنوان مسائلی که قبل از سپولیا نیاز به تأیید دارند، فهرست کرده است.
یک Devnet-11 ناموفق یا ناپایدار به طور خودکار فعالسازی 6 اکتبر را لغو نمیکند. توسعهدهندگان باید علت و زمان مورد نیاز برای تعمیرات را ارزیابی کنند. یک مشکل جدی میتواند باعث شود که آنها در طول جلسه توسعهدهندگان اصلی، تاریخ را بازنگری کنند.
آزمایشهای قبلی گلمستردام نقصهایی را در هر دو طرف معماری اتریوم آشکار کرد. استفان استارفلینگر، مهندس عملیات توسعه بنیاد اتریوم، گزارش داد که Devnet-8 یک مشکل لایه اجماع را شامل بلوکهایی که هش والد را تکرار میکردند، فاش کرد.
استارفلینگر در توضیح سناریوی آزمایش گفت: «شما میتوانستید کل شبکه را متوقف کنید.»
این مشکل بر سیستمی که مسئول توافق بلوک بود، تأثیر گذاشت. سپس Devnet-9 دچار عدم قطعیت شد و مهندسان را وادار کرد تا موارد گوشهای بیشتری را در مجموعه بزرگتری از اعتبارسنجها بررسی کنند.
در بخش اجرا، ماریا سیلوا، پژوهشگر بنیاد اتریوم، یک مشکل پیادهسازی مربوط به EIP-8037 را گزارش کرد. این پیشنهاد نحوه محاسبه گس اتریوم را برای ایجاد وضعیت جدید، شامل حسابهای جدید، قراردادها و ورودیهای ذخیرهسازی، تغییر میدهد.
EIP-8037 هزینههای ایجاد وضعیت را از هزینههای اجرای عادی از طریق یک مدل گس چندبعدی جدا میکند. مشخصات منتشر شده آن میگوید که این طراحی به دنبال کنترل رشد وضعیت است زیرا اتریوم حد گس بلوک خود را افزایش میدهد. این پیشنهاد همچنان تحت بررسی همتا است.
مشکل کشف شده نیازمند بازنگری کلاینتهای اجرا در پیادهسازیهای خود و منجر به کار مشخصات شد. همانطور که crypto.news در پوشش پیشرفتهای قبلی Devnet گلمستردام گزارش داد، EIP-8037 در کنار سایر تغییرات پروتکلی ارتقا مورد آزمایش قرار گرفته است.
آزمایش هدف متفاوتی از تأیید جداگانه هر پیشنهاد دارد. توسعهدهندگان باید تأیید کنند که تمام تغییرات انتخاب شده با هم در چندین کلاینت، پیکربندی اعتبارسنجها و الگوهای تراکنش کار میکنند.
توسعهدهندگان از برنامهریزی گلمستردام در هودی خودداری کردهاند در حالی که سپولیا مشروط باقی مانده است. انتظار میرود هودی به عنوان مرحله دوم شبکه آزمایشی عمومی عمل کند و محیط دیگری را برای اپراتورهای استیکینگ و تیمهای پروتکل فراهم کند که شرایط شبکه اصلی را دقیقتر نشان میدهد.
انریکو دل فانته، توسعهدهنده تکو (Teku)، از انتظار قبل از تعیین تاریخ هودی حمایت کرد. در طول ACDC #186، او به مشکلات اخیر Devnet-9 اشاره کرد و از اختصاص زمان بیشتر برای آزمایش پس از تصمیمگیری سپولیا حمایت کرد.
فعالسازی شبکه اصلی در دسامبر همچنان یک هدف ممکن است، نه یک بازه زمانی راهاندازی تأیید شده. برنامهریزی سپولیا برای اوایل اکتبر، زمان کافی در تقویم را برای یک فاز شبکه آزمایشی عمومی دیگر و آمادهسازی انتشار کلاینتها، در صورت پیشرفت آزمایش بدون تأخیر طولانی، حفظ میکند.
توسعهدهندگان اپوک شبکه اصلی، زمان فعالسازی یا برنامه نهایی انتشار کلاینت را منتشر نکردهاند. هیچ مهلت رسمی برای تصمیمگیری در مورد اینکه آیا 6 اکتبر برای سپولیا مناسب است، اعلام نشده است.
رویداد فوری رویهای، راهاندازی برنامهریزی شده Devnet-11 در 14 سپتامبر است. تیمهای کلاینت، قطعیت، رفتار بین کلاینتها و اصلاحات معرفی شده پس از آزمایشهای قبلی را بررسی خواهند کرد تا قبل از تصمیمگیری در مورد اینکه آیا سپولیا میتواند طبق برنامه فعلی پیش برود یا خیر.
ETH