اتریوم باگ احتمالی مسیر سپرده اعتبارسنج ها را اصلاح کرد

اتریوم باگ احتمالی در مسیریابی سپرده اعتبارسنج‌ها را اصلاح کرد

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

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

ریشه اصلی مشکل

این آسیب‌پذیری از منطق جداسازی درون‌پروتکلی پیشنهاددهنده و سازنده، معروف به PBS، پدید آمد که در چارچوب گلمستردام برنامه‌ریزی شده است. PBS وظایف ساخت و پیشنهاد بلاک را تفکیک می‌کند: سازندگان تخصصی، محتوای بلاک را می‌سازند، در حالی که اعتبارسنج‌ها در سازوکار اجماع اثبات سهام اتریوم، بلاک‌ها را پیشنهاد می‌کنند و به آن‌ها گواهی می‌دهند. پژوهشگری با نام avsetsin در ۱۲ اکتبر گزارش داد که قواعد پردازش سپرده می‌تواند در شرایطی که هر دو نقش از یک کلید عمومی استفاده کنند، وجوه را به مسیر نادرست هدایت کند.

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

اثر احتمالی بر خدمات استیکینگ

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

بازبینی توسعه‌دهندگان، رد اولیه و تغییر تصمیم

خط زمانی تصمیم‌ها

پس از مطرح شدن مسئله، نگه‌داران اصلی درباره اصلاح پیشنهادی گفت‌وگو کردند. در ۱۹ اکتبر، جاستین تراگلیا، یکی از نگه‌داران، درخواست ادغام را با اشاره به نبود پشتیبانی کافی کلاینت‌ها از این تغییر در آن زمان بست. این تصمیم باعث تحلیل و آزمایش بیشتر شد و توسعه‌دهندگان در ۲۳ اکتبر دوباره پیشنهاد را باز کردند. بازبینی‌کننده‌ای با نام potuz موافقت خود را اعلام کرد، اما خواستار آزمون‌های رگرسیون بیشتری برای حالت‌هایی شد که سپرده‌های سازنده و اعتبارسنج کلید عمومی مشترک دارند. avsetsin این آزمون‌ها را در ۲۳ اکتبر اضافه کرد و پس از بازبینی بیشتر کلاینت‌ها، این تغییر در ۲۶ اکتبر در مشخصات اجماع ادغام شد.

اصلاح ادغام‌شده چه می‌کند

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

زمینه ماجرا: فعال‌سازی گلمستردام و تأخیرهای مرتبط

تعویق تست‌نت هودی و پیشنهاد EIP-8037

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

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

پیاده‌سازی کلاینت‌ها، آزمایش و گام‌های بعدی

تیم‌های کلاینت چه باید بکنند

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

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

توصیه‌هایی برای اپراتورهای استیکینگ و تیم‌های پروتکل

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

جمع‌بندی: ریسکی مرزی که به‌موقع مهار شد

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

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