ارتقای اتریوم گلمستردام نامحدود به تعویق افتاد؛ ۱۳ قرارداد تحت تأثیر شناسایی شد

توسعه‌دهندگان اتریوم، راه‌اندازی هارد فورک Glamsterdam را به تعویق انداختند

توسعه‌دهندگان اتریوم در جلسه ACDE #248 که در تاریخ ۲۲ اکتبر برگزار شد، تصمیم گرفتند راه‌اندازی هارد فورک Glamsterdam را که قرار بود در ۲۶ اکتبر در شبکه آزمایشی Hoodi آغاز شود، به طور نامحدود به تعویق بیندازند. دلیل اصلی این تصمیم، گزارش شرکت امنیتی ChainSecurity بود که نشان می‌داد تغییرات مربوط به کارمزد (gas) در EIP-8037 و EIP-8038 ممکن است حفاظت قراردادهای هوشمند را در برابر حملات “insufficient gas griefing” تضعیف کند. ChainSecurity موفق به شناسایی ۱۳ قرارداد واقعی تحت تأثیر این مشکل شده و در حال هماهنگی با پروژه‌های مربوطه برای افشای مسئولانه یافته‌های خود است. این موضوع باعث عدم قطعیت در زمان‌بندی راه‌اندازی شبکه اصلی نیز شده است.

تعویق نامحدود راه‌اندازی در شبکه آزمایشی Hoodi

توسعه‌دهندگان اتریوم، تاریخ راه‌اندازی ارتقاء Glamsterdam را در شبکه آزمایشی Hoodi به طور نامحدود به تعویق انداختند. بنیاد اتریوم در اطلاعیه‌ای در تاریخ ۲۲ اکتبر اعلام کرد که فورک که قرار بود در ساعت ۱۷:۴۲ UTC روز ۲۶ اکتبر (epoch 132,352) فعال شود، لغو شده و تاریخ جدیدی برای آن تعیین نشده است. این تصمیم در جلسه All Core Devs Execution (ACDE) #248 همان روز اتخاذ شد، جایی که توسعه‌دهندگان اصلی ترجیح دادند به جای پایبندی به برنامه زمانی، ابتدا نحوه تعامل EIP-8037 با قراردادهای هوشمند شبکه اصلی را بررسی کنند.

لغو همزمان رویدادهای دیگر و تنظیمات شبکه Hoodi

همزمان با تعویق راه‌اندازی، دو رویداد دیگر نیز لغو شدند: فعال‌سازی لایه اجرایی Amsterdam، فعال‌سازی لایه اجماع Gloas، و زمان‌بندی افزایش سقف کارمزد Hoodi به ۲۰۰ میلیون. اطلاعیه تأکید کرد که این اقدام صرفاً “پیکربندی ارتقاءهای آینده” را بازگردانده و تاریخچه موجود در زنجیره Hoodi را پاک نمی‌کند. تاریخ ۲۶ اکتبر مستقیماً از پیکربندی حذف شده و هیچ epoch یا timestamp جایگزینی تعیین نشده است. از اپراتورهای گره‌ها و اعتبارسنجان Hoodi خواسته شده است تا کلاینت‌های لایه اجرایی و اجماع خود را بررسی کرده و هرگونه نرم‌افزار یا تنظیمات شبکه سفارشی که بر اساس برنامه زمانی قدیمی تنظیم شده‌اند را به‌روزرسانی کنند.

ریشه‌یابی مشکل: سرنوشت کارمزد پس از شکست

هسته‌ی مشکل به “سرنوشت کارمزد پس از شکست” بازمی‌گردد. شرکت امنیتی بلاکچین ChainSecurity در مقاله‌ای تحلیلی در تاریخ ۱۳ اکتبر، اثرات ترکیبی EIP-8037 (تغییر در محاسبه هزینه ایجاد وضعیت و معرفی مخزن کارمزد مستقل) و EIP-8038 (بازتعیین قیمت دسترسی به وضعیت) را بررسی کرد. تحت قوانین جدید، پس از شکست یک فراخوانی، کارمزد ممکن است به قرارداد فراخوان‌کننده بازگردد و به منطق پردازش شکست که در ابتدا به دلیل کمبود کارمزد متوقف شده بود، اجازه دهد تا کامل شود، و حتی یک “شکست قابل تلاش مجدد” را به طور دائمی به عنوان “شکست غیرقابل بازگشت” ثبت کند.

حمله “insufficient gas griefing” و پیامدهای آن

ChainSecurity این نوع حملات را “insufficient gas griefing” نامیده است: یک فراخوان‌کننده مخرب به طور عمدی کارمزد بسیار کمی برای یک عملیات قانونی فراهم می‌کند تا عملیات با شکست مواجه شود، اما کارمزد کافی باقی می‌گذارد تا قرارداد بتواند “شکست” را در وضعیت ثبت کند. قراردادهای تحت تأثیر ممکن است به دلیل این موضوع، واجد شرایط بودن کاربران برای دریافت پاداش را حذف کنند یا گزینه‌های تلاش مجدد را غیرفعال کنند، و در نتیجه یک عملیات که در حالت عادی معتبر بوده، به طور دائمی غیرقابل انجام شود. این مقاله همچنین اشاره کرد که تمام بررسی‌های امنیتی مربوط به کارمزد نامعتبر نخواهند شد و بخشی از حفاظت‌ها همچنان مؤثر خواهند بود، اما توسعه‌دهندگان باید به صورت جداگانه بررسی کنند که آیا قراردادهایشان به فرضیات قدیمی کارمزد متکی هستند یا خیر.

واکنش جامعه اتریوم و افشای مسئولانه

این یافته‌ها واکنش‌های زنجیره‌ای در جامعه اتریوم ایجاد کرد. محقق امنیتی pcaversaccio در بحث GitHub مربوط به ACDE #248 در تاریخ ۲۱ اکتبر، این ریسک را “جدی” توصیف کرد و خواستار ارزیابی مجدد هارد فورک شد. ChainSecurity در تاریخ ۲۳ اکتبر در پلتفرم X تأیید کرد که “۱۳ نمونه واقعی” را شناسایی کرده و در حال انجام افشای مسئولانه با پروژه‌های تحت تأثیر است، بدون اینکه جزئیات را منتشر کند، اما مستقیماً از توسعه‌دهندگان خواست تا قراردادهای خود را به سرعت بررسی کنند. بنیاد اتریوم نیز به طور همزمان در حال بررسی این موضوع است که چه تعداد قرارداد و به چه شکلی تحت تأثیر قرار گرفته‌اند.

سابقه مشکلات Glamsterdam و توقف در مرحله آزمایشی

این اولین بار نیست که Glamsterdam با مشکل مواجه می‌شود. بنیاد اتریوم پیش از این هشدار داده بود که مدل کارمزد Glamsterdam، کیف پول‌ها، ایندکسرها و ابزارهای تخمین کارمزد که به فرضیات ثابت متکی هستند را مختل خواهد کرد. خود Glamsterdam نیز در تاریخ ۶ اکتبر در شبکه آزمایشی Sepolia راه‌اندازی شده بود. توقف Hoodi به معنای ترمز کشیدن در مرحله دوم فرآیند “پیشرفت تدریجی در شبکه‌های آزمایشی” است.

عدم قطعیت در زمان‌بندی شبکه اصلی

بر اساس دستور جلسه ACDE #248، تاریخ‌های کاندید برای راه‌اندازی Glamsterdam در شبکه اصلی شامل ۱ دسامبر، ۸ دسامبر و ۹ دسامبر بود و قرار بود پس از موفقیت‌آمیز بودن آزمایش Hoodi، در جلسه بعدی ACDC نهایی شود. تعویق نامحدود Hoodi به معنای حذف این نقطه اتکا است و زمان‌بندی شبکه اصلی اکنون کاملاً به نتایج تحقیقات تأثیر قراردادهای EIP-8037 بستگی دارد. برای اکوسیستم، این بدان معناست که برنامه‌های کاربردی و ابزارهایی که به مدل کارمزد جدید Glamsterdam متکی هستند، باید دوره بیشتری را در عدم قطعیت سپری کنند.

نکات کلیدی برای رصد و اقدامات عملی

دو نکته کلیدی برای رصد در آینده وجود دارد: اول، زمان انتشار لیست ۱۳ قرارداد تحت تأثیر ChainSecurity و اینکه آیا دامنه تحقیقات بنیاد اتریوم به دسته‌های بیشتری از قراردادها گسترش خواهد یافت. دوم، نحوه مدیریت تاریخ راه‌اندازی شبکه اصلی در جلسات ACDC؛ اگر تحقیقات تا نوامبر به طول انجامد، پنجره زمانی راه‌اندازی در پایان سال فشرده‌تر شده و حتی ممکن است به اوایل سال ۲۰۲۷ موکول شود. برای توسعه‌دهندگان قرارداد، اقدام عملی فعلی بررسی این موضوع است که آیا به فرضیات ثابت gasleft() متکی هستند، به خصوص در مسیرهایی که “وضعیت را پس از شکست فراخوانی ثبت می‌کنند”؛ این نوع منطق تحت EIP-8037/8038 بیشترین آسیب‌پذیری را دارد. انتخاب تیم اتریوم برای توقف در مرحله شبکه آزمایشی به جای انتقال مشکل به شبکه اصلی، سیگنال مثبتی برای امنیت بلندمدت است، اما هزینه آن، عدم قطعیت مجدد در کل جدول زمانی ارتقاء است.