AI به عنوان «شرور»، بیمه DeFi به یک آزمایش فشار نیاز دارد

آزمایش برخورد برای خزانه‌های DeFi: Firelight قصد دارد با استفاده از AI «حادثه بعدی» را شناسایی کند.

نویسنده: @jrdothoughts

ترجمه: AididiaoJP، Foresight News

نقاط کور بیمه DeFi: عدم وقوع حادثه به معنای ایمنی نیست

ابتدا یک بخش از تبلیغ با طنز سیاه را بشنوید: «هواپیمای جدید ما کاملاً ایمن است و هرگز سقوط نکرده است.»

«چقدر پرواز کرده است؟»

«...... تقریباً دو بار.»

اگر هواپیما را با خزانه DeFi عوض کنیم، داستان بسیار آشنا می‌شود: شش ماه برداشت بدون مشکل، هیچ حمله‌ای نداشته و بازدهی خوبی دارد. این البته مدرکی است. اما در این شش ماه، آیا با ازدحام شبکه مواجه شده، وثیقه‌ها از اعتبار افتاده، تأمین‌کنندگان نقدینگی (LP) به سرعت خارج شده‌اند و اوراکل‌ها به‌روز نشده‌اند؟ احتمالاً نه.

تاریخ تمیز فقط می‌تواند بگوید یک سیستم چه چیزی را تحمل کرده است. بیمه باید بپرسد: آن ممکن است با چه چیزی برخورد کند.

این فرصتی است که Firelight می‌بیند: قیمت‌گذاری بر اساس نحوه شکل‌گیری خسارت، نه فقط اینکه آیا خسارت قبلاً رخ داده است. تاریخ مسئول تثبیت است، شبیه‌سازی مسئول کاوش سناریوهای جایگزین است، AI مسئول یافتن نقاط ضعف است و سرمایه مسئول تضمین است.

تاریخ یک عکس فوری است، اما سیستم تغییر می‌کند

داده‌های خسارت تاریخی، عکس فوری از عملکرد یک ماشین در یک شرایط خاص هستند. وقتی ماشین تغییر می‌کند، عکس فوری نیاز به بازنگری دارد.

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

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

بنابراین، برای Firelight، واقعاً سوال این نیست که «آیا این پروتکل هک شده است»، بلکه این است: چه مجوزهایی وجود دارد؟ کدام وابستگی‌ها واقعاً مهم هستند؟ وقتی همه به طور همزمان به سمت خارج می‌شتابند، کدام مسیرهای تصفیه هنوز قابل استفاده هستند؟ چارچوب عمومی Firelight به‌طور واضح نقاط ضعف فنی و آسیب‌پذیری‌های اقتصادی را جدا کرده است، نه اینکه آنها را به یک نمره ایمنی ترکیب کند.

بیمه به ساختار و روابط وابستگی‌های فعلی سیستم مربوط می‌شود، نه به نام برند آن که تا به امروز ادامه دارد.

بیمه بلایای طبیعی قبلاً سناریوها را نوشته است

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

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

مدل بلایای طبیعی می‌پرسد: طوفان چگونه بر یک شهر تأثیر می‌گذارد؟ مدل DeFi می‌پرسد: یک خرابی چگونه در طول نمودار وابستگی گسترش می‌یابد؟

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

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

چگونه آزمایشگاه تست برخورد مالی را بسازیم

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

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

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

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

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

AI را به «صندلی شرور» بنشانید، اما قوانین فیزیک را تغییر ندهید

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

جالب‌تر این است که AI را به‌طور فعال به جستجوی سناریوهای مختلف وادار کنید. شبیه‌سازی مونت کارلو از توزیع‌های تعیین‌شده نمونه‌برداری می‌کند، که البته مفید است؛ اما ترکیب‌های واقعاً بد ممکن است بسیار نادر باشند و نمونه‌برداری تصادفی بیشتر اوقات فقط در حال تکرار کشف شرایط عادی است.

آزمایش فشار خودتنظیم معکوس است: نماینده در شبیه‌ساز عوامل اختلال را انتخاب می‌کند و به‌طور فعال به دنبال مسیرهای شکست قابل اعتماد می‌گردد. در آزمایش‌های خودران، این رویکرد با یادگیری تقویتی نشان داده شده است. نماینده می‌تواند آب و هوا را تغییر دهد، اما نمی‌تواند قوانین فیزیک را تغییر دهد.

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

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

سرعت نیز مهم است. روش‌های تقریبی با هزینه کم ابتدا تعداد زیادی سناریو را غربال می‌کنند و آزمایش‌های پرهزینه بعدی در چندین محیط آزمایش مستقل، سناریوهای مهم را دوباره پخش می‌کنند. اما میانبرها باید تأیید شوند. سرعت بخشیدن به شبیه‌سازهای نادرست فقط باعث می‌شود که آنها سریع‌تر و با اعتماد به نفس بیشتری اشتباه کنند.

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

از زنجیره خسارت به شرایط پوشش

یک خزانه وام‌دهی فرضی را تصور کنید: قیمت وثیقه کاهش می‌یابد، LP‌ها به سرعت خارج می‌شوند و به‌روزرسانی اوراکل به تأخیر می‌افتد. اگرچه تصفیه‌کنندگان وارد می‌شوند، اما لغزش ارزش بازیابی را می‌بلعد و در نهایت بدهی وام‌گیرنده از قیمت واقعی که وثیقه می‌تواند فروخته شود، بیشتر می‌شود.

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

فرض کنید یک اجرای نمونه 2 میلیون دلار خسارت واجد شرایط ایجاد کند، خودنگهداری 500 هزار دلار و حداکثر پوشش 1 میلیون دلار. لایه خودنگهداری 500 هزار دلار را جذب می‌کند، فرض کنید پوشش 1 میلیون دلار خسارت پرداخت کند، 500 هزار دلار باقی‌مانده در خارج از حد مجاز قرار می‌گیرد.

اینها شرایط فرضی هستند و نه قیمت‌گذاری Firelight و نه نتایج شبیه‌سازی واقعی. واجد شرایط بودن، بازیابی، استثنائات و پوشش‌های همپوشانی باید روشن شوند.

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

پیدا کردن مسیرهای شکست به معنای محاسبه احتمال نیست

فرض کنید یک نماینده مقابله‌ای در 30% از آزمایش‌ها سیستم را شکسته است. آیا این به این معناست که سیستم 30% احتمال شکست دارد؟ نه لزوماً. این نماینده به‌طور خاص برای یافتن نقاط ضعف طراحی شده است.

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

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

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

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

چه کسی «آزمایش فشار» را آزمایش می‌کند؟

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

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

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

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

نتیجه‌گیری: یادگیری قبل از وقوع خسارت

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

تاریخ پرداخت خسارت پس از وقوع است. شبیه‌سازی به Firelight کمک می‌کند تا زودتر بفهمد: این سیستم ممکن است چگونه دچار خرابی شود.

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