🚨 اتریوم باگ امنیتی ارتقای Glamsterdam را برطرف کرد؛ خطر انتقال ETH کاربران به سازندگان بلاک!

این اصلاحیه که قوانین پردازش سپرده‌های اعتبارسنج‌ها را تغییر می‌دهد، روز دوشنبه در کدهای اصلی پروژه ادغام شد؛ آن هم یک هفته پس از آنکه توسعه‌دهندگان ابتدا با این تغییر مخالفت کرده بودند. 🛠️⛓️

ارتقای Glamsterdam دو وظیفه‌ای را که در حال حاضر با یکدیگر ترکیب شده‌اند، از هم جدا می‌کند. سازندگان بلاک (Builders) مجموعه‌ای از تراکنش‌ها را برای تشکیل بلاک آماده می‌کنند و اعتبارسنج‌ها (Validators) که با استیک‌کردن ETH به امنیت شبکه کمک می‌کنند، بلاک‌ها را انتخاب و تأیید می‌کنند.

هر دو گروه می‌توانند ETH سپرده‌گذاری کنند، اما دارایی‌های آن‌ها باید به‌صورت جداگانه ثبت و مدیریت شود. 💎

🔍 چگونه این نقص می‌توانست باعث از دست رفتن دارایی‌ها شود؟

این مشکل در جریان اجرای خود ارتقا ظاهر می‌شد؛ زمانی که اتریوم سپرده‌هایی را پردازش می‌کرد که هنوز اعتبار آن‌ها ثبت نشده بود.

پژوهشگری با نام avsetsin سناریویی را شناسایی کرد که در آن، یک اپراتور ابتدا با استفاده از یک کلید عمومی مشخص به‌عنوان سازنده بلاک ثبت‌نام می‌کرد. کلید عمومی شناسه‌ای است که به یک اعتبارسنج یا سازنده بلاک اختصاص داده می‌شود. 🔑

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

avsetsin در توضیح این مشکل نوشت: «اپراتور می‌تواند وجوه متعلق به پروتکل را برداشت کند.»

در چنین شرایطی، هیچ اعتبارسنجی ایجاد نمی‌شد؛ بنابراین سرویس استیکینگ نیز نمی‌توانست مدرک لازم برای بازیابی دارایی‌های خود را ارائه دهد. 🚨💸

🤖 بررسی تأثیر احتمالی بر پروتکل‌های استیکینگ

avsetsin که نام او به‌عنوان یکی از اعضای سازمان GitHub پروژه Lido ثبت شده است، بررسی کرد که این نقص چگونه می‌تواند بر پروتکل‌های Lido، Origin و Rocket Pool تأثیر بگذارد. این پژوهشگر بررسی خود را نوعی «تحقیق سریع با هوش مصنوعی» توصیف کرد. 🤖🔬

یافته‌ها به نحوه مدیریت سپرده‌ها در هر یک از این پروتکل‌ها بستگی داشتند.

بااین‌حال، avsetsin تأکید کرد که این موارد، یافته‌هایی مشروط در بررسی کد هستند و به معنای تأیید وقوع حمله در شبکه واقعی نیستند.

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

تاکنون هیچ گزارشی از زیان مالی ناشی از این نقص منتشر نشده است. 🛡️

🔄 ابتدا رد شد؛ سپس اصلاحیه تأیید شد

توسعه‌دهندگان اتریوم در تاریخ ۱۹ اکتبر، پیشنهاد اصلاح این مشکل را بستند.

جاستین تراگلیا (Justin Traglia)، مسئول نگهداری مشخصات اجماع اتریوم، در آن زمان نوشت: «در حال حاضر، حمایت کافی از سوی کلاینت‌ها برای اعمال این تغییر وجود نداشت.»

کلاینت‌ها نرم‌افزارهای مستقلی هستند که اعتبارسنج‌ها برای مشارکت در شبکه اتریوم از آن‌ها استفاده می‌کنند. 💻⛓️

به گفته avsetsin، این پیشنهاد پس از بررسی‌های بیشتر دوباره باز شد. او در ۲۳ اکتبر آزمایش‌های بیشتری به آن اضافه کرد و تراگلیا روز دوشنبه اصلاحیه را در کدهای پروژه ادغام کرد.

⚙️ اصلاحیه جدید چگونه از سپرده‌های ETH محافظت می‌کند؟

بر اساس قوانین جدید، سپرده‌های در انتظار پردازش بر مبنای اطلاعات برداشت (Withdrawal Credentials) مرتب می‌شوند؛ تنظیماتی که مشخص می‌کنند دارایی‌های سپرده‌گذاری‌شده در نهایت به کجا می‌توانند منتقل شوند.

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

این تغییر اکنون به مشخصات اجماع اتریوم اضافه شده است، اما تیم‌های توسعه‌دهنده کلاینت‌ها همچنان باید آن را در نرم‌افزارهای خود پیاده‌سازی کنند.

🧪 تأخیر در آزمایش‌های Glamsterdam

ارتقای Glamsterdam پیش‌تر روی شبکه آزمایشی Sepolia اجرا شده بود؛ اما راه‌اندازی برنامه‌ریزی‌شده آن در تاریخ ۲۶ اکتبر روی Hoodi، دومین شبکه آزمایشی اتریوم، به تعویق افتاد. ⏳🧪

برای تعیین زمان عرضه این ارتقا روی شبکه اصلی اتریوم (Mainnet)، ابتدا باید تاریخ جدیدی برای اجرای آن روی Hoodi مشخص شود.

بنابراین، با وجود ادغام اصلاحیه امنیتی، زمان‌بندی عرضه نهایی Glamsterdam همچنان به تکمیل آزمایش‌ها و بررسی‌های بیشتر وابسته است. 🛡️📊

📌 بیشتر بخوانید: اتریوم آزمایش Glamsterdam را پس از هشدار توسعه‌دهندگان امنیتی درباره خطر برای قراردادهای هوشمند موجود به تعویق انداخت.