Продовжуйте, як це робить бос Yishi. Насправді сама по собі вразливість у відкритому коді контрактів зустрічається не так часто. І команди, які мають проблеми з дисципліною на рівні контрактів, майже завжди проходять кілька раундів аудиту та формальне верифікацію — багато з них навіть мають достатньо добру дисципліну при запуску, але все одно не змогли запобігти інцидентам. Аудиторські компанії за це не несуть відповідальності. Більшість інцидентів безпеки насправді виникають через управління правами доступу та параметрами — і це стосується як інцидентів Drift, так і KELP. Тут виникає ключове питання: чи повинні DeFi-продукти прагнути до його припущення — «відсутності інцидентів»? Логіка більшості сучасних DeFi-проектів (а також CeFi) полягає в тому: «Оскільки я впровадив стільки шарів захисту, то у мене не буде інциденту». Це призводить до прямої наслідковості: коли інцидент відбувається, його важко виправити, бо всі рішення — це елегантні «профілактичні заходи». А що, якщо припустити, що інциденти неминучі? Тоді підхід до проектування змінюється: з «запобігання хворобам» на «лікування». З «захисних заходів» на «механізми зупинки збитків». Головні напрямки стануть такими: 1. Блокування часу оновлення контракту (це стара тема). 2. Моніторинг платоспроможності (підтримка співвідношення платоспроможності протоколу та покриття внесених коштів): Це саме та проблема, чому багато lending-проектів «заробляють гроші на капусті, але переживають як за наркотики». Незначний маржинальний дохід супроводжується надмірним TVL — протокол просто не зможе виплатити всі кошти. 3. Механізм аварійного зупинення при великих аномальних рухах. Цього майже немає в жодному протоколі, але це стандарт у CEX. При великих аномальних транзакціях, особливо при виведенні коштів, автоматично активується механізм затримки виведення — це дає час для втручання системи контролю ризиків. Будь-яка хакерська атака, як би вона не виникла, завжди закінчується великою аномальною вибуттям коштів. Тож, якщо не можна закрити вразливий канал — можна закрити останню ланку, де виникають збитки. Такий контроль ризиків можна реалізувати на рівні dApp-протоколу, стабільної монети чи мосту — і вплив на звичайних користувачів буде малим (навіть хай-фрик-арбітражери не будуть постійно масово виводити кошти). Це великий недолік для ETH, але для таких експериментальних блокчейн-платформ, як @BNBCHAIN — величезна перевага. Раніше BNB змогла знизити проблему MEV-рейсингу на 95% завдяки Goodwill Alliance на рівні вузлів — аналогічно можна додати такий же механізм затримки на рівні мосту. Навіть під час атаки мост стає останньою ланкою захисту — вони зупиняють втечу вкрадених коштів. Усі мульти-ланцюгові протоколи, що пов’язані з BNB, повинні дотримуватися однакових стандартів. Ефективність цього підходу була неодноразово підтверджена під час реагування на інциденти безпеки на Sui, Hyperliquid та інших CEX — за умови, що немає таких «пробелов» як невиконання USDC CCTP. Крім того, для стабільних монет потрібні часовий замок та чорний список для великих переказів — логіка така ж, як у мосту, але це може вплинути на прийняття. Загалом я вважаю, що це можливостями L1. Ключ — чотири слова: «автономний контроль». За таких умов блокчейн-рІвень навiть може забезпечити справжню «гарантiю компенсацiї за інцидентами», а не просто «комерцiйне страхування» на кшталт Umbrella. Хто зможе це зробити — той отримає частку TVL, яку втратив ETH.