توسعه‌دهندگان اتریوم حفره امنیتی در ارتقای Glamsterdam را برطرف کردند
توسعه‌دهندگان اتریوم با موفقیت یک آسیب‌پذیری را در ارتقای Glamsterdam ترمیم کردند که می‌توانست به اپراتورها اجازه دهد تا اتریوم (ETH) که برای اعتبارسنجان جدید در نظر گرفته شده بود را برداشت کنند. این فرآیند رفع اشکال در ابتدا با مشکلاتی مواجه شد، اما در نهایت در زمان تعویق تست‌ها به نتیجه رسید و هیچ خسارت مالی گزارش نشده است.
برای درک مشکل، باید ابتدا دو عنصری که Glamsterdam قصد جداسازی آن‌ها را دارد، درک کنیم. در حال حاضر، سازندگان (builders) که تراکنش‌ها را در بلوک‌ها بسته‌بندی می‌کنند و اعتبارسنجان (validators) که با استیک کردن ETH، بلوک‌ها را انتخاب و تأیید می‌کنند، در برخی مراحل به هم گره خورده‌اند. پس از ارتقا، این دو نقش به هویت‌های مستقل تبدیل می‌شوند و هر دو می‌توانند ETH را واریز کنند، در حالی که حساب‌ها باید به طور جداگانه ثبت شوند.
این آسیب‌پذیری در نحوه پردازش “سپرده‌های در انتظار” که هنوز به حساب واریز نشده‌اند، توسط خود ارتقا رخ داد.
محقق Avsetsin (که در سازمان GitHub Lido فهرست شده است) سناریویی را ترسیم کرد: اگر یک اپراتور ابتدا با یک کلید عمومی به عنوان سازنده ثبت‌نام کند و سپس سرویس استیکینگ با همان کلید عمومی ETH را واریز کند تا یک اعتبارسنج را راه‌اندازی کند، قوانین پیش‌نویس آن زمان هر دو سپرده را به نام سازنده ثبت می‌کرد. Avsetsin نوشت: “اپراتور می‌تواند وجوه پروتکل را برداشت کند.” مشکل بزرگتر این بود که اعتبارسنج اصلاً ایجاد نمی‌شد، بنابراین سرویس استیکینگ هیچ مدرکی برای اثبات و در نتیجه پیگیری وجوه نداشت.
او سپس بررسی کرد که Lido، Origin و Rocket Pool چگونه تحت تأثیر قرار می‌گیرند و این را “تحقیق سریع هوش مصنوعی” نامید. او تأکید کرد که “این‌ها کشفیات کد شرطی هستند، نه حملات واقعی تأیید شده.” بازرسی‌های موجود می‌توانستند با رد کردن سپرده‌های قبلی سازنده، این مسیر را مسدود کنند و هیچ خسارت پس از آن گزارش نشد.
پیشنهاد رفع اشکال در واقع یک بار بسته شد. جاستین ترالیا، که مسئول نگهداری مشخصات اجماع اتریوم است، در ۱۹ اکتبر نوشت که “پشتیبانی فعلی کلاینت‌ها کافی نیست” و بنابراین این تغییر به تعویق افتاد. کلاینت‌ها به برنامه‌های نرم‌افزاری مختلفی اشاره دارند که اعتبارسنجان برای مشارکت در شبکه از آن‌ها استفاده می‌کنند. پس از بررسی بیشتر، پیشنهاد دوباره باز شد و Avsetsin در ۲۳ اکتبر تست‌ها را تکمیل کرد. ترالیا سپس آن را در روز دوشنبه ادغام کرد.
قوانین جدید سپرده‌های در انتظار را بر اساس گواهی برداشت مرتب می‌کنند. گواهی برداشت تعیین می‌کند که یک سپرده در نهایت به کجا هدایت می‌شود. به این ترتیب، حتی اگر سازنده از کلید یکسانی استفاده کند، سپرده اعتبارسنج همچنان به نام اعتبارسنج باقی می‌ماند. این تغییر اکنون در مشخصات اجماع اتریوم گنجانده شده است، اما تیم‌های کلاینت هنوز باید آن را در نرم‌افزار خود پیاده‌سازی کنند تا کامل شود.
Glamsterdam قبلاً در شبکه آزمایشی Sepolia اجرا شده بود، اما راه‌اندازی آن در دومین شبکه آزمایشی، Hoodi، در ۲۶ اکتبر به تعویق افتاد. برنامه اصلی به تاریخ جدید Hoodi بستگی دارد.
اهمیت این رفع اشکال در این است که پس از جداسازی Glamsterdam سازندگان و اعتبارسنجان به هویت‌های مستقل، مرزهای “یک کلید، دو هویت” به طور ناگهانی افزایش می‌یابد و خطر چنین سردرگمی حساب‌ها با تفکیک ساختار افزایش می‌یابد.
شایان ذکر است که این مشکل توسط یکی از اعضای جامعه Lido در سمت سرویس استیکینگ کشف شد، نه تیم اصلی کلاینت. این نشان می‌دهد که بررسی خارجی ریسک‌های ارتقا به طور فزاینده‌ای توسط پروتکل‌های استیکینگ بزرگ پر می‌شود. در مقایسه با گزارش قبلی ChainSecurity که ۱۳ قرارداد تحت تأثیر را شناسایی کرد و تعویق شبکه آزمایشی Hoodi، بدهی امنیتی انباشته شده Glamsterdam در حال حاضر به نظر می‌رسد که در مسیر “سپرده و واریز” متمرکز شده است.
چندین نکته مشاهده‌ای مشخص در ادامه وجود دارد. اول، اینکه آیا کلاینت‌ها واقعاً قوانین جدید مرتب‌سازی سپرده را پیاده‌سازی کرده‌اند، که تعیین می‌کند آیا برنامه اصلی می‌تواند زمان‌بندی شود. دوم، تاریخ راه‌اندازی جدید Hoodi چه زمانی تعیین می‌شود، زیرا Glamsterdam باید ابتدا یک بار در Hoodi اجرا شود تا برنامه اصلی مشخص شود. سوم، اینکه آیا پروتکل‌های استیکینگ جریان ثبت کلید را تنظیم می‌کنند تا از استفاده همزمان سازندگان و اعتبارسنجان از یک کلید عمومی جلوگیری شود.
