Возможно, гигант DeFi избежал смертельной спирали, но эксплойты и проблемы с кодом, подобные тем, с которыми он недавно столкнулся, являются более распространенным явлением — и их можно предотвратить, — чем то, что признает индустрия.
Недавний опыт Curve Finance на грани смерти (и предотвращенное его распространение) может показаться размытым пятном в зеркале заднего вида Web3, но на самом деле это то, что продолжает происходить в отрасли. Это не первый случай, когда децентрализованный финансовый протокол — или любое децентрализованное приложение, если уж на то пошло, — подвергается атаке, которая абсолютно законна в рамках его собственного кода. Более того, кризис можно было бы предотвратить, если бы существовало сетевое управление рисками.
Все это указывает на более широкую проблему Web3. Это проблема ограниченной выразительности и ресурсов, существующих в его средах разработки, и того, как это влияет на безопасность в целом.
Взламывать или эксплуатировать?
Когда злоумышленник Curve Finance смог получить активы на сумму 61,7 миллиона долларов США по смарт-контрактам Curve Finance, многие СМИ и комментаторы назвали это событие “взломом”. Но это был не взлом — это был эксплойт. Разница здесь ключевая.
В этом контексте взлом произошел бы, если бы злоумышленник каким-то образом обошел или нарушил существующую меру безопасности. Но атака на Curve была эксплойтом. Не произошло ничего необычного с точки зрения того, что допускал Vyper-код протокола. Грабитель просто воспользовался тем, как работал дизайн протокола.
Кто виноват в этом? Никто. Vyper-код Curve, как и большая часть кода (Solidity), используемого в приложениях Web3, сильно ограничен в своей способности выражать сложность за пределами относительно простой логики транзакций.
Это затрудняет разработку мер безопасности, которые предотвратили бы эту или любые другие атаки. Что еще более тревожно, это также затрудняет надлежащую разработку инструментов для предотвращения их распространения по обширному и составному ландшафту ликвидности DeFi.
Анализ рисков в цепочке
Но это не означает, что Curve ничего не могла сделать, чтобы предотвратить эту атаку и ее распространение по DeFi. Простым примером решения может быть анализ рисков в цепочке.
Обобщенную версию проблемной схемы, которую можно было бы решить, можно обобщить в гипотетической ситуации, подобной этой:
- Плохой актер Боб покупает высоковолатильный токен $ RISKY стоимостью 5 миллионов долларов через флэш-кредит.
- Стоимость токена $ RISKY эффективно повышается Бобом после покупки.
- Боб берет кредит в размере 100 миллионов долларов под залог Naive Finance в размере $ RISKY.
- Naive Finance проверяет цену $ RISKY и подтверждает, что Боб “хорош” в отношении денег.
- Боб убегает.
- Когда Naive Finance ликвидирует $ RISKY, это стоит всего 5 миллионов долларов.
(Другой пример этой общей схемы можно найти в мартовском взломе Euler.)
Традиционно эта проблема решается с помощью решений для анализа рисков, которые определяют, насколько хорошей гарантией может быть актив. Если бы они существовали в сети, Naive Finance могла бы проверить статистические оценки, основанные на исторической цене токена, прежде чем одобрить кредит. Протокол раскусил бы памп и отказал Бобу в 100 миллионах долларов.
DeFi не хватает такого рода анализа и управления рисками в сети.
Возвращаясь к Curve Finance, распространения можно было бы предотвратить, если бы у Aave и Frax был автоматический сетевой лимит на одобрение кредита, когда они передают процент от оборотного предложения токена обеспечения. Это была бы более безопасная и менее стрессовая ситуация для всех.
Ограниченная выразительность и ресурсы
Реальная проблема здесь в том, что текущие экосистемы Web3 не могут поддерживать что-то вроде этого решения для анализа рисков в сети. Они ограничены типом библиотек и фреймворков, которые доступны на виртуальных машинах, таких как виртуальная машина Ethereum. Они также ограничены в ресурсах, имеющихся в их распоряжении.
Чтобы разработать что-то вроде этого решения для анализа рисков и управления ими, децентрализованному приложению необходимо было бы рассчитывать на библиотеки кодирования, которые имеют функции для по крайней мере базовых математических понятий, таких как логарифмы и другие.
В Web3 это не так, потому что у dApps нет доступа к NumPy, математическому модулю в Python, например. Типичного инструментария здесь нет, и разработчикам приходится изобретать велосипед.
Тогда у нас возникает другая проблема. Даже если бы у них были эти библиотеки, их было бы слишком дорого кодировать. Буквально дорого. Виртуальная машина Ethereum спроектирована так, что за каждое вычисление приходится платить.
Хотя для этого есть веские причины, такие как предотвращение бесконечных циклов и тому подобное, это также создает ограничение ресурсов для dApps, которым может потребоваться масштабирование в вычислительном отношении без неоправданных затрат. Можно легко увидеть, как запуск решения по управлению рисками обойдется дороже, чем то, что оно способно сэкономить в виде средств.
Сосредоточение внимания на правильных проблемах
На локальном уровне распространение тупика Curve Finance можно было предотвратить с помощью сетевого управления рисками. На общем уровне весь этот класс атак можно было бы предотвратить с помощью большей выразительности и ресурсов в Web3.
Это два аспекта масштабируемости блокчейна, которые долгое время упускались из виду, потому что они выходят за рамки предоставления большего общего пространства блоков для dApps. На самом деле они включают в себя создание сред разработки в Web3, которые эмулируют среды Web2. Речь идет о масштабируемости вычислений и программируемости, а не просто о масштабировании объема данных, доступных в сети.
Возможно, если бы разработчики протоколов в Curve, Aave или Frax могли рассчитывать на лучший инструментарий и больше ресурсов, этих и будущих эксплойтов можно было бы вообще избежать. Возможно, мы могли бы начать с управления рисками в цепочке.
" 
