Недавний опыт близкой гибели Curve Finance (и его предотвращенное распространение) может показаться размытым в зеркале заднего вида Web3, но на самом деле это то, что постоянно происходит в индустрии. Это не первый случай, когда децентрализованный финансовый протокол - или любое другое децентрализованное приложение - пострадал от атаки, которая вполне легальна в рамках его собственного кода. Более того, кризис можно было бы предотвратить, если бы существовало управление рисками на цепочке.

Все это указывает на более широкую проблему Web3 - проблему ограниченности возможностей и ресурсов, существующих в средах разработки, и того, как это влияет на безопасность в целом.

Взлом или эксплуатация?

Когда злоумышленнику удалось получить 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 млн. долл.

(Еще один пример такой общей схемы можно найти в мартовском хаке Эйлера).

Традиционно эта проблема решается с помощью решений по анализу рисков, которые определяют, насколько хорошей гарантией может быть тот или иной актив. Если бы они существовали в цепочке, Naive Finance могла бы проверять статистические оценки, основанные на исторической цене токена, прежде чем одобрить кредит. Протокол увидел бы, что это просто насос, и отказал бы Бобу в получении 100 млн долл.

DeFi не хватает такого анализа и управления рисками на цепочке.

Возвращаясь к ситуации с Curve Finance, можно было бы предотвратить спрэд, если бы в Aave и Frax был установлен автоматический внутрицепочечный лимит на выдачу кредитов, когда они превышают определенный процент от оборота залогового токена. Это была бы более безопасная и менее стрессовая ситуация для всех.

Ограниченная выразительность и ресурсы

Настоящая проблема заключается в том, что существующие экосистемы Web3 не могут поддерживать подобное решение для анализа рисков на цепочке. Они ограничены теми библиотеками и фреймворками, которые доступны в виртуальных машинах, таких как Ethereum Virtual Machine. Они также ограничены с точки зрения имеющихся в их распоряжении ресурсов.

Для разработки подобного решения по анализу и управлению рисками децентрализованное приложение должно опираться на библиотеки кодирования, содержащие функции хотя бы для базовых математических понятий, таких как логарифмы и др.

В Web3 это не так, поскольку Dapp не имеют доступа, например, к NumPy, математическому модулю в Python. Типичный набор инструментов отсутствует, и разработчикам приходится изобретать колесо.

Тогда возникает другая проблема. Даже если бы у них были эти библиотеки, их было бы слишком дорого кодировать. В буквальном смысле дорого. Виртуальная машина Ethereum устроена так, что за каждое вычисление приходится платить.

Хотя для этого есть веские причины, такие как предотвращение бесконечных циклов и т.п., это также создает ограничение по ресурсам для dApp, которым необходимо масштабировать вычисления без неоправданных затрат. Можно легко представить, как решение по управлению рисками будет обходиться дороже, чем экономия средств.

Фокусировка на правильных проблемах

На локальном уровне распространение тупиковой ситуации с Curve Finance можно было предотвратить с помощью внутрицехового управления рисками. На общем уровне весь этот класс атак можно было бы предотвратить с помощью большей выразительности и ресурсов Web3.

Это два аспекта масштабируемости блокчейна, которые долгое время оставались без внимания, поскольку они выходят за рамки предоставления большего общего пространства блоков для dApp. Они связаны с созданием в Web3 среды разработки, аналогичной Web2. Речь идет о масштабируемости вычислений и программировании, а не только о масштабировании объема данных, доступных на цепочке.

Возможно, если бы разработчики протоколов в компаниях Curve, Aave или Frax могли рассчитывать на более совершенный инструментарий и большие ресурсы, этих и будущих эксплойтов удалось бы избежать. Возможно, начать следует с управления рисками на цепочке.

Источник