Хто має платити за «за замовчуванням»? Після нападу на rsETH півмісяця тому, генеральний директор LayerZero «усвідомлено взяв на себе відповідальність»

Нуль

Автор: Янз, Techub News

У світі Web3, який ніколи не спить, 18 квітня спочатку був звичайним днем. Однак для сектору повторного залучення ліквідності та всьої екосистеми DeFi сталася подія, яка може увійти до історії — «землетрус», що тихо розгортався у ланцюгу. Менше ніж за годину хакери (згідно з повідомленнями, група Lazarus) використали міжланцюговий міст Kelp DAO для безкоштовного створення 116 500 rsETH, вартістю приблизно 292 мільйони доларів. Враховуючи, що rsETH широко використовується як заставна застава, хакери не поспішали продавати ці безцінні «повітряні сертифікати», а замість цього перепродали їх у провідних кредитних протоколах, таких як Aave, отримавши близько 236 мільйонів доларів ETH, що фактично занурило провідні протоколи, такі як Aave, у боргову яму.

Це не перша атака на міжланцюговий міст, але цього разу вона розірвала давно існуючу рану у галузі Web3: коли базова інфраструктура (протокольний рівень) і верхній рівень (додатки) залишаються без зв’язку, хто має платити за зниклі мільярди активів?

Протягом наступних півтора місяця ця криза перетворилася на відкриту боротьбу за технології, відповідальність і владу. Від початкового «звинувачення один одного» до сьогоднішнього «активного взяття відповідальності» керівником LayerZero, ця боротьба нарешті поставила крапку у суперечці про межі відповідальності.

Фатальний «1/1 DVN»

Щоб зрозуміти цю суперечку, потрібно розібратися з методами атаки хакерів. Цікаво, що ця атака не була викликана складною уразливістю смарт-контрактів, а корінь проблеми — у конфігураційному параметрі: 1-із-1 DVN.

Це так званий DVN, тобто децентралізована мережа валідаторів, яка відповідає за перевірку міжланцюгових повідомлень у архітектурі LayerZero V2. Конфігурація 1-із-1 означає, що достатньо підпису одного валідатора, щоб вважати міжланцюгове повідомлення легітимним і виконати його. Ще гірше, що контроль над «ключем» не був цілком у руках Kelp, а залежав від нижчого рівня — RPC-нодів. Хакери через підміну даних у RPC-нодах і DDoS-атаки захопили єдиного валідатора, підсунувши йому фальшивий «запис про знищення на джерелі». Валідатор повірив і підписав, і ця велика сума активів з’явилася ні з чого.

Отже, хто ж має нести відповідальність за цю «1/1 DVN»?

Обвинувачення і конфлікт логік

У перші години після атаки громадськість переважно звинувачувала LayerZero. У соцмережах лунали кепкування з Kelp DAO: як провідний протокол із мільярдними обсягами, вони використовують «паперові» замки з одним валідатором — це майже непрощенно.

Однак 21 квітня, коли Kelp опублікував «офіційний звіт», сталася драматична зміна настроїв. Основний аргумент Kelp зводився до того, що якщо офіційна документація і стандартні налаштування самі по собі небезпечні, відповідальність лежить на тих, хто їх створював і налаштовував. Це не помилка користувача, а «помилка у дизайні» продукту. Хоча керівник LayerZero Браян Пеллегріно у відповідях наголошував, що це — вибір додатку, а не вразливість протоколу, звинувачення змістилося з «безпомічності» Kelp на «системну зарозумілість» LayerZero — усвідомлюючи ризики стандартних налаштувань, вони все одно зробили їх прикладом швидкого старту.

Крім того, голоси сторонніх розробників ще більше посилили суперечку. Основний розробник Yearn banteg у технічному аналізі виявив, що швидкий старт LayerZero V2 на Ethereum, BNB Chain, Polygon, Arbitrum і Optimism використовує цю небезпечну односерверну валідацію за замовчуванням. Лідер спільноти Chainlink Zach Rynes різко критикував: він звинуватив LayerZero у тому, що вони використовують своїх користувачів як «козлів відплати», щоб приховати власну вразливість у інфраструктурі при атаках високого рівня.

Отже, хто ж правий? Насправді — і ті, і інші частково праві. Суть суперечки — у конфлікті двох логік. Перша — «етика гіків»: інструменти нейтральні, користувачі несуть відповідальність за свої вибори. Друга — «принцип безпечних налаштувань»: продукт має бути у найбезпечнішому стані за замовчуванням. Користувачі можуть зручності заради зручності знижувати рівень безпеки, але продукт не повинен спрямовувати їх у небезпечний напрямок.