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

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

Некоторые основные моменты этого нового протокола включают в себя:

• Динамический расчет результатов для устранения необходимости выкупа
• Гибкое добавление и удаление ликвидности
• Быстрые кредиты и мгновенные свопы
• Настройки динамических комиссий
• Полная компоновка и интероперабельность
• Дополнительные проверки безопасности
• Улучшена читаемость контракта

Tinyman AMM V2 не имеет разрешений

Tinyman AMM V2 неизменен (не подлежит обновлению)

Tinyman AMM V2 не имеет ключей администратора для приостановки активности или слива пулов

Tinyman AMM V2 прозрачен и имеет открытый исходный код

Tinyman AMM V2 прошел аудит

Tinyman AMM V2 по-прежнему невероятно быстр и дешев в использовании.

Нет больше выкупа

Одним из наиболее важных улучшений протокола Algorand за последний год стало введение внутренних транзакций. Они позволяют контрактам программно создавать транзакции. Это позволяет Tinyman динамически рассчитывать выходы подкачки и выполнять транзакцию на полную сумму выхода. Контракты по-прежнему надежно гарантируют получение минимальной ожидаемой суммы.

Это устранит основной источник трений и путаницы и сразу же улучшит взаимодействие с пользователем.

Больше никаких подписок на приложения

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

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

Более гибкое управление ликвидностью

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

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

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

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

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

Компонуемость и интероперабельность

Мы снова воспользовались преимуществами последних улучшений протокола Algorand, чтобы разработать протокол V2, чтобы он был полностью компонуемым и совместимым. Это означает, что транзакции Tinyman V2 могут быть помещены в те же атомарные группы, что и другие транзакции, и что Tinyman V2 можно вызывать из других контрактов.

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

Флэш-кредиты и свопы

Одной из функций, которая использует эту компонуемость, являются Flash Loans. Теперь у нас есть поддержка этого, встроенная в протокол, поэтому пользователи могут брать ссуду с нулевым залогом из пула, если они погашают ее в рамках одной и той же группы транзакций. Это может показаться бесполезной функцией, но благодаря совместимому характеру протокола и развивающемуся пространству Algorand DeFi появится множество возможностей для получения прибыли в рамках одного блока. Это сложная функция, предназначенная для использования только людьми, хорошо знакомыми с протоколами и стратегиями DeFi, и поэтому не будет включена в веб-интерфейс. Включение этой функции обусловлено нашей основной философией предоставления финансовых инструментов всем, независимо от их благосостояния.

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

Регулируемые сборы

Tinyman AMM V1 имеет фиксированную комиссию за своп в размере 30 базисных пунктов, которая делится 5:1 между пулерами и протоколом. До сих пор это хорошо служило пользователям, но бывают случаи, когда другие варианты оплаты были бы более подходящими. Для привязанных/стабильных активов более низкая комиссия, оказывающая меньшее влияние на цену, будет выгодна обменникам. Увеличение объема из-за более низких комиссий также должно принести пользу пулерам. Вместо того, чтобы фрагментировать ликвидность между несколькими пулами для разных уровней комиссий одних и тех же пар активов, протокол V2 позволяет корректировать комиссию пула с течением времени. Все пулы будут начинаться со значений по умолчанию (таких же, как V1), но ставка комиссии может быть изменена учетной записью, устанавливающей комиссию, в допустимых пределах.

Намерение здесь состоит в том, что установщик комиссий изначально будет учетной записью, контролируемой основной командой Tinyman, и комиссии будут корректироваться только для стабильных/привязанных пар. Позже мы намерены ввести функцию, позволяющую участникам пула коллективно принимать решения о комиссиях для своего пула. В конечном итоге мы намерены, чтобы все сборы контролировались Tinyman DAO, когда он существует. Протокол спроектирован так, чтобы быть гибким в этом отношении, поэтому ответственность за установление и сбор комиссий может быть делегирована смарт-контрактам или внешним учетным записям и может быть отозвана при необходимости. Это позволяет со временем изменять правила и механизмы, касающиеся комиссий, не затрагивая какие-либо другие аспекты протокола. Дополнительная информация будет предоставлена ​​перед запуском политики, связанной с изменением сборов.

Более безопасный и прозрачный протокол

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

Существует ряд математических/логических инвариантов, которые должны соблюдаться в протоколе. В Tinyman V2 они явно проверяются после каждой операции, чтобы гарантировать, что даже при очень неожиданном поведении пулы не потеряют свою ценность.

Протокол может быть безопасным только в том случае, если он может быть легко прочитан, понят и проверен несколькими независимыми людьми. Чтобы помочь в этом отношении, мы провели работу по ряду направлений:

• Читаемый исходный код контракта. Мы разработали новый язык для Algorand, Tealish , который позволяет нам ясно выражать нашу логику и намерения на высоком уровне при компиляции в читаемый низкоуровневый Teal. Фергал Уолш (Tinyman CTO) расскажет о Tealish и о том, как он использовался для V2 на Decipher 2022 .

• Аудиты, подлежащие аудиту. Спецификации протоколов и контракты были проанализированы и проверены на нескольких уровнях, чтобы попытаться выявить множество различных проблем. Это включает в себя анализ и моделирование спецификаций, исходный код Tealish и сгенерированный код Teal, который в конечном итоге выполняется на AVM. Мы работали с аудиторами, чтобы сделать процесс аудита более прозрачным, чем обычно. В ближайшие недели мы опубликуем еще одну запись в блоге об этом со ссылками на отчеты и все вспомогательные материалы.
• Bug Bounty — мы работали с Algorand Foundation и Immunefi над созданием программы Bug Bounty с вознаграждением до 250 000 долларов США за критические проблемы. Эта программа запущена сразу и останется активной после запуска основной сети.
• Публичные контракты и спецификации с открытым исходным кодом — мы опубликовали контракты с исходным кодом, сгенерированный Teal и окончательный байт-код вместе с проектным документом и спецификацией протокола. Это позволяет любому просмотреть детали протокола, чтобы убедиться, что его реализация соответствует их ожиданиям.

Нас регулярно спрашивают, почему у Tinyman нет большой красной кнопки, чтобы приостановить контракты, если что-то пойдет не так. Этот вопрос был поднят еще больше после досадного инцидента в январе. При разработке V2 мы много думали над этим вопросом. Можем ли мы реализовать функцию паузы? Как это будет работать? Кто может это контролировать? Кто несет ответственность за его вызов? Что происходит после паузы? Мы подробнее остановимся на этом в следующем посте о проблемах безопасности, но в конечном итоге пришли к тому же выводу, что и при разработке V1; нет безопасного и полезного механизма паузы, который не поставил бы под угрозу основные ценности Tinyman и DeFi в целом. Механизм паузы без обновляемых контрактов не очень полезен, а обновляемые контракты — это другая сторона линии, которую мы не хотим пересекать. Обновляемые контракты позволят команде Tinyman (или злоумышленнику) изменить правила протокола и потенциально завладеть ликвидностью. Основная цель DeFi — избежать таких возможностей.

Ваши средства, ваше решение

Мы, как команда, в восторге от нового протокола и были заняты созданием нового и улучшенного пользовательского интерфейса на его основе. Мы считаем, что в целом у пользователей будет гораздо лучший опыт работы с новым протоколом, но в конечном итоге это ваше решение как пользователя протокола. Когда вы размещали свои средства в V1, вы соглашались с тем, что они будут связаны правилами и логикой контрактов V1. Мы не можем изменить эти правила, чтобы перенести вашу ликвидность на V2. Это должно быть ваше решение. Мы рекомендуем всем участникам пула на V1 ознакомиться с подробностями протокола и независимым аудиторским отчетом и решить для себя, хотят ли они перенести свою ликвидность на V2. Протокол V1 будет вечно жить в основной сети Algorand, и мы продолжим поддерживать существующие пулы в веб-интерфейсе в обозримом будущем.

Следующие шаги

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

У нас также будут дополнительные сообщения о плане миграции перед запуском.

А пока предлагаем вам ознакомиться с деталями протокола и задать вопросы в наших сообществах.

использованная литература

Документация и спецификация протокола V2

Репозиторий контрактов V2

Отчет об аудите контрактов V2

Тилиш Репо

Программа Immunefi Bug Bounty (ссылка будет добавлена)