شرکت Aave Labs در صدد است پیش از وقوع هرگونه مشکل، تدابیر امنیتی لازم را اتخاذ کند. این تیم در تاریخ ۲۱ اکتبر ۲۰۲۶، پیشنهادی برای ارتقاء Aave V3.8 منتشر کرد که تمرکز اصلی آن بر افزودن یک مکانیزم محافظت در برابر حملات بازگشتی (reentrancy guard) به بخش حسابداری Pool است.
این پیشنهاد شامل ۱۶ نمونه فعال Aave V3، از جمله استقرارها بر روی شبکه‌های Ethereum، Avalanche، BNB و Polygon می‌شود. هنوز هیچ تغییری اعمال نشده و هیچ سوءاستفاده‌ای منجر به این اقدام نشده است. Aave در حال رفع یک ریسک بالقوه است، نه پاکسازی پس از وقوع آن.
تغییر اصلی، اعمال یک مکانیزم محافظت در برابر حملات بازگشتی بر روی عملیات Pool در طول فراخوانی‌های خارجی است. این موضوع ممکن است کمی پیچیده به نظر برسد، بنابراین با یک مثال ساده آن را توضیح می‌دهیم.
تصور کنید یک دستگاه خودپرداز (ATM) قبل از به‌روزرسانی موجودی حساب شما، پول نقد را تحویل می‌دهد. یک مشتری زیرک می‌تواند در این فاصله زمانی کوتاه، درخواست پول بیشتری کند، در حالی که دستگاه هنوز معتقد است حساب پر است. حملات بازگشتی در قراردادهای هوشمند به همین شکل عمل می‌کنند.
یک قرارداد، کنترل را به کد خارجی واگذار می‌کند که قبل از تسویه سوابق، دوباره قرارداد اصلی را فراخوانی می‌کند. اگر سوابق در میانه به‌روزرسانی باشند، فراخوانی دوم می‌تواند اعداد قدیمی و نادرست را مشاهده کند. نتیجه این امر می‌تواند از خطاهای حسابداری تا برداشت غیرمجاز وجوه متغیر باشد.
پیشنهاد Aave دقیقاً به این شکاف پرداخته است. بر اساس یافته‌های تحقیقاتی، این مکانیزم محافظتی برای حفظ ثبات حسابداری در زمانی طراحی شده است که یک تراکنش واحد بیش از یک بار با Pool تعامل داشته باشد.
این مکانیزم بر پایه EIP-1153، یک استاندارد اتریوم برای ذخیره‌سازی موقت (transient storage)، بنا شده است. ذخیره‌سازی موقت مانند یک صفحه یادداشت است که فقط در طول یک تراکنش باقی می‌ماند و پس از اتمام آن پاک می‌شود.
این موضوع از نظر هزینه اهمیت دارد. یک مکانیزم محافظت در برابر حملات بازگشتی نیاز دارد که به طور موقت به خاطر بسپارد که Pool در حال حاضر مشغول است. نوشتن این یادداشت در حافظه دائمی پرهزینه خواهد بود، در حالی که ذخیره‌سازی موقت به Aave اجازه می‌دهد تا این حفاظت را با حفظ هزینه‌های گس (gas) پایین اعمال کند.
Aave V3.8: ارتقایی برای استحکام بلندمدت
Aave Labs، V3.8 را یک انتشار جزئی و غیرتهاجمی توصیف می‌کند. هدف اعلام شده، دستیابی به استحکام بلندمدت است، نه ارائه ویژگی‌های جدید یا بازطراحی نحوه عملکرد وام‌دهی و وام‌گیری.
این یک پیشنهاد است، نه یک ارتقاء نهایی. Aave Labs آن را در انجمن حاکمیت Aave به عنوان یک ARFC (Aave Request for Final Comment) منتشر کرده است.
از این مرحله به بعد، این طرح هنوز باید سه مانع را پشت سر بگذارد. این طرح نیازمند بازخورد جامعه، ممیزی‌های امنیتی و رأی‌گیری AIP (Aave Improvement Proposal) است، به این معنی که یک پیشنهاد رسمی بهبود Aave که توسط دارندگان توکن به صورت آن‌چین (on-chain) تصمیم‌گیری می‌شود.
دامنه این تغییر نیز قابل توجه است. اعمال یکسان تغییر در ۱۶ شبکه به معنای هماهنگی استقرارها در زنجیره‌هایی با محیط‌ها و مجموعه‌های اعتبارسنج متفاوت است. یک مکانیزم محافظت یکپارچه در همه آن‌ها، به Aave یک خط پایه امنیتی سازگار می‌دهد، به جای مجموعه‌ای از نسخه‌های پراکنده.
V3.8 اولین تلاش Aave برای حل این مشکل نیست. یافته‌های تحقیقاتی نشان می‌دهند که این پیشنهاد به دنبال کارهای امنیتی قبلی Aave V3، از جمله رفع‌های قبلی حملات بازگشتی و به‌روزرسانی‌های چارچوب مدیریت ریسک گسترده‌تر پروتکل است.
عدم وجود یک سوءاستفاده افشا شده، نکته کلیدی در اینجاست. Aave Labs به هیچ آسیب‌پذیری که علیه پروتکل مورد استفاده قرار گرفته باشد، اشاره نکرده است. این مکانیزم محافظتی به عنوان “دفاع در عمق” (defense in depth) معرفی شده است، یک لایه اضافی که به دلیل بالا بودن هزینه اشتباه، اضافه شده است.
برای افرادی که در Aave تأمین مالی یا وام‌گیری می‌کنند، در صورت تصویب این ارتقاء، تأثیر کوتاه‌مدت باید حداقل باشد. یک انتشار غیرتهاجمی که بر ذخیره‌سازی موقت تکیه دارد، برای جلوگیری از تغییر جریان‌های کاربری یا افزودن سربار گس قابل توجه طراحی شده است.
آنچه در ادامه باید دنبال کرد، روشن است. بحث‌های انجمن را برای یافتن اعتراضات یا تغییرات درخواستی پیگیری کنید، سپس نتایج ممیزی و زمان‌بندی رأی‌گیری AIP را بررسی کنید. اگر این پیشنهاد هر سه مرحله را با موفقیت پشت سر بگذارد، استقرار در ۱۶ شبکه نشان خواهد داد که آیا Aave می‌تواند یک انتشار امنیتی هماهنگ را به همان تمیزی که برنامه‌ریزی کرده است، ارائه دهد.
یک نکته دیگر که باید به آن توجه کرد: نحوه تعامل این مکانیزم محافظتی با ادغام‌هایی است که به فراخوانی‌های بازگشتی به Pool متکی هستند. هر پروتکلی که بر روی Aave ساخته شده است، می‌خواهد تأیید کند که این حفاظت جدید، تراکنش‌های چند مرحله‌ای قانونی را مسدود نمی‌کند. این نوع موارد خاص، دقیقاً همان چیزی است که مراحل ممیزی و بازخورد برای شناسایی آن‌ها وجود دارد.
