Обобщенные тесты свойств для хранилищ ERC4626

По мере роста и развития DeFi масштабируемая инфраструктура и компонуемость становятся приоритетом для разработчиков. Ethereum Requests for Comment (или ERC) — стандартизированные наборы инструментов для создания приложений на основе Ethereum, такие как широко используемый стандарт токенов. ERC20 - выполнять важную роль предоставления последовательных рекомендаций для разработчиков по внесению вклада в экосистему, не начиная с нуля. Ранее в этом году, стандарт токенизированного хранилища ERC4626 был создан для поощрения перекрестной совместимости между токенами, приносящими доход. Стандартизация деталей реализации также может решить насущные проблемы компоновки, упрощая интеграцию протоколов и, в конечном счете, уменьшая вероятность ошибок.

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

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

Сначала немного предыстории стандарта ERC4626.

Завершено в марте, ERC4626 является стандартом для токенизированных хранилищ. Он был введен для того, чтобы расширить широко используемый ERC20 стандарт (в настоящее время является базой для сотен токенов), поощрять стандартизацию хранилищ, приносящих доход, и обеспечивать возможность компоновки для приложений и протоколов (например, агрегаторов дохода), которые должны взаимодействовать с ними. Это означает, что любое приложение, созданное в хранилище ERC4626, можно легко расширить для работы с любым другим хранилищем ERC4626. 

Токенизированные хранилища позволяют пользователям свободно вносить активы в акции хранилища, а затем выкупать эти доли для снятия основной суммы и процентов из хранилища. Эти акции хранилища являются токенами ERC20, и поэтому их можно легко продать или использовать в качестве залога для заимствования других активов. Например, пользователи могут размещать свои активы в хранилищах Yearn для чеканки токенов yVault, которые затем можно продавать на Uniswap, делать ставки для получения дополнительной прибыли или использовать в качестве залога для протоколов кредитования.

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

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

Проблемы соответствия стандарту (и подводные камни несоответствия)

Следовать новому стандарту не всегда просто. Каждое хранилище ERC4626 должно добросовестно (и точно) соответствовать описанным требованиям стандарта. В противном случае интеграция хранилищ ERC4626 становится все более сложной из-за различных вариантов. Эта сложность делает интеграцию изначально подверженной ошибкам; а поскольку они недостаточно рассчитаны на будущее, со временем они могут привести к уязвимостям в системе безопасности.

Нестандартные токены ERC20 (например, Tether USD) требуют, чтобы многие системы DeFi использовали дополнительную библиотеку (например, SafeERC20) при выполнении передачи токенов, чтобы безопасно справляться с расходящимся поведением (например, ничего не возвращая при успешном переводе вместо возврата true). Это означает, что любые системы, взаимодействующие с этими токенами, могут стать уязвимыми, если система не предназначена для надлежащей обработки случаев «отсутствующих возвратов». Эти сценарии потенциально могут создать общую ловушку безопасности и увеличить общие затраты на разработку и обслуживание (с учетом дополнительной логики и зависимостей, необходимых для устранения проблем). Поэтому соответствие стандарту имеет решающее значение не только для отдельных реализаций, но и для безопасности всей экосистемы. Одна уязвимость в одной системе или зависимости может вызвать широко распространенные проблемы.

В идеале стандарты должны быть официально определены без двусмысленности (например, формальная спецификация ERC20), и каждая реализация может быть формально проверена на соответствие стандартной спецификации. На практике, однако, этого нелегко добиться за короткий период времени из-за затрат и усилий, требуемых от сообщества.

Представляем исполняемые свойства ERC4626 для выявления проблем соответствия 

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

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

Мы выбрали тесты на основе свойств, написанные на Foundry и готовые к запуску его фаззером, чтобы сделать свойства исполняемыми (и, следовательно, тестируемыми). В будущем они также могут запускаться с помощью инструментов символьного выполнения или проверки модели, чтобы формально проверить, что данное хранилище удовлетворяет свойствам для всех возможных входных данных и условий.

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

Например, следующее свойство соответствует одному из требований convertToShares() функция, "НЕ ДОЛЖЕН показывать какие-либо варианты в зависимости от вызывающего абонента». Учитывая два адреса счета и сумму, он заставляет каждый из счетов вызывать convertToShares() с той же суммой и гарантирует, что два возвращаемых значения равны. Это свойство не зависит от деталей реализации convertToShares(), который зависит от хранилища и должен удовлетворять всем хранилищам, реализующим ERC4626. Это свойство можно выполнить, предоставив определенные входные значения (для модульного тестирования), множество случайных входных данных (для нечеткого тестирования) или символические значения (для символьного выполнения и формальной проверки). Его также можно запустить локально или на форке основной сети (для интеграционного тестирования).

Пример использования: свойства, проверяющие ошибки округления.

Ошибки округления, например, являются важным классом (на первый взгляд незначительных) ошибок, которые могут иметь некоторые последствия для серии. Базовая логика учета ERC4626, например, расчет количества акций, которые должны быть выпущены, или суммы активов, которые необходимо изъять, реализована с использованием арифметики с фиксированной точкой — ошибки округления неизбежны. За безопасность, однако стандарт явно указывает предпочтительное направление округления для каждой функции интерфейса, оставляя границы ошибки неуказанными и зависящими от реализации. В частности, deposit() и redeem() функции должны возвращать под-приближение точного значения, в то время как mint() и withdraw() функции должны возвращать за-приближение. Например, если текущая цена акции (т. е. сумма активов на акцию) равна 2, то deposit() с 3 wei активов должны чеканить только до 1 wei акций (т.е. floor(3/2)), в то время как withdraw() с 3 wei активов должны сжечь не менее 2 wei акций (т.е. ceil(3/2)).

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

Действительно, мы обнаружили, что несколько хранилищ ERC4626 в основной сети не удовлетворяют вышеуказанному свойству из-за ошибок округления. Это означает, что любой может заработать, например, пару сатоши BTC (1 сатоши ~= 0.02 цента на момент написания статьи), просто (и неоднократно) выпуская и выводя, медленно опустошая хранилище. На самом деле это может принести прибыль сетям с очень низкой платой за газ (например, Fantom), или если цена актива станет достаточно высокой в ​​будущем.

Тестирование стандарта ERC4626 в реальных условиях

Мы проверили наши свойства на ~100 хранилищах ERC4626 в основной сети и обнаружили много хранилищ, которые не соответствовали стандартным требованиям — в основном из-за ошибок округления (например, использование округления пола там, где желателен потолок, как мы описали). В частности, некоторые хранилища не смогли отчеканить точное количество акций, запрошенное mint() функция, хотя стандарт явно требует этой. Некоторые из них также испускали непоследовательный Deposit событие, при котором зарегистрированные данные отличаются от того, что было фактически отчеканено. К нашему удивлению, некоторые хранилища вообще не чеканились на месте; вместо этого они просто помещают запросы монетного двора в очередь и обрабатывают их позже в пакете как отдельную транзакцию.

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

Использование наших тестов свойств и другие практические шаги для обеспечения соответствия стандарту.

Точное соблюдение стандарта может предотвратить нестандартное поведение (в идеале еще до того, как оно будет развернуто). Мы надеемся, что наши свойства помогут, наряду с несколькими дополнительными действиями. Для тех, кто разрабатывает и/или интегрирует хранилища ERC4626:

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

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

По мере того, как мы работаем над достижением идеального состояния (где разные хранилища одинаково компонуемы), можно запускать тесты свойств ERC4626, чтобы легче обнаруживать стандартные нарушения в реализациях хранилищ. Все тесты свойств (с документацией и примерами) общедоступны на нашем Github. хранилище. Мы приветствуем ваши отзывы и вклад!

Мнения, выраженные здесь, принадлежат отдельным цитируемым сотрудникам AH Capital Management, LLC («a16z») и не являются мнением a16z или ее аффилированных лиц. Определенная информация, содержащаяся здесь, была получена из сторонних источников, в том числе от портфельных компаний фондов, управляемых a16z. Хотя информация взята из источников, считающихся надежными, a16z не проводила независимую проверку такой информации и не делает никаких заявлений о текущей или неизменной точности информации или ее уместности в данной ситуации. Кроме того, этот контент может включать стороннюю рекламу; a16z не просматривал такие рекламные объявления и не поддерживает какой-либо рекламный контент, содержащийся в них.

Этот контент предоставляется только в информационных целях и не может рассматриваться как юридическая, деловая, инвестиционная или налоговая консультация. Вы должны проконсультироваться со своими советниками по этим вопросам. Ссылки на любые ценные бумаги или цифровые активы предназначены только для иллюстративных целей и не представляют собой инвестиционную рекомендацию или предложение предоставить консультационные услуги по инвестициям. Кроме того, этот контент не предназначен и не предназначен для использования какими-либо инвесторами или потенциальными инвесторами, и ни при каких обстоятельствах на него нельзя полагаться при принятии решения об инвестировании в какой-либо фонд, управляемый a16z. (Предложение инвестировать в фонд a16z будет сделано только в меморандуме о частном размещении, договоре о подписке и другой соответствующей документации любого такого фонда, и их следует читать полностью.) Любые инвестиции или портфельные компании, упомянутые, упомянутые или описанные не являются репрезентативными для всех инвестиций в транспортные средства, управляемые a16z, и нет никаких гарантий, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь аналогичные характеристики или результаты. Список инвестиций, сделанных фондами, управляемыми Andreessen Horowitz (за исключением инвестиций, в отношении которых эмитент не предоставил разрешение на публичное раскрытие информации a16z, а также необъявленных инвестиций в публично торгуемые цифровые активы), доступен по адресу https://a16z.com/investments. /.

Диаграммы и графики, представленные в нем, предназначены исключительно для информационных целей, и на них не следует полагаться при принятии каких-либо инвестиционных решений. Прошлые показатели не свидетельствуют о будущих результатах. Содержание говорит только по состоянию на указанную дату. Любые прогнозы, оценки, прогнозы, цели, перспективы и/или мнения, выраженные в этих материалах, могут быть изменены без предварительного уведомления и могут отличаться или противоречить мнениям, выраженным другими. Пожалуйста, посетите https://a16z.com/disclosures для получения дополнительной важной информации.