Единственный поток курса в этом году
Многие участники канала знают, что я уже достаточно долго развиваюсь в сфере безопасности смарт контрактов, участвую в конкурсных аудитах и даже веду закрытую группу, в которой мы обсуждаем уязвимости и сам процесса аудита.
И на этот год я планирую уделить туда еще больше сил и внимания, поэтому будет всего лишь один поток курса в этом году. Он же единственный с поддержкой.
Если вы сейчас опоздаете с заходом на этот модуль, то придется ждать еще один год или выбирать обучение намного дороже этого!
Наш курс один из немногих в ру сегменте доступный для каждого и рассчитанный на ученика без каких-либо знаний в программировании.
Вы можете в своем неспешном темпе проходить каждый урок и выполнять задания. Час-два в день и к концу лета у вас будет достаточно знаний для первой работы!
Осталось всего два дня до конца продаж! Купить первый модуль вы не сможете вплоть до Нового года вообще.
Мы начинает уже в этот понедельник!
Программа курса Условия оплаты
#курс
Многие участники канала знают, что я уже достаточно долго развиваюсь в сфере безопасности смарт контрактов, участвую в конкурсных аудитах и даже веду закрытую группу, в которой мы обсуждаем уязвимости и сам процесса аудита.
И на этот год я планирую уделить туда еще больше сил и внимания, поэтому будет всего лишь один поток курса в этом году. Он же единственный с поддержкой.
Если вы сейчас опоздаете с заходом на этот модуль, то придется ждать еще один год или выбирать обучение намного дороже этого!
Наш курс один из немногих в ру сегменте доступный для каждого и рассчитанный на ученика без каких-либо знаний в программировании.
Вы можете в своем неспешном темпе проходить каждый урок и выполнять задания. Час-два в день и к концу лета у вас будет достаточно знаний для первой работы!
Осталось всего два дня до конца продаж! Купить первый модуль вы не сможете вплоть до Нового года вообще.
Мы начинает уже в этот понедельник!
Программа курса Условия оплаты
#курс
👍6🌭5🔥3👎2🤬1
Планы и темы канала на ближайшее время
Фух, спасибо всем кто присоединился к новому потоку и всем, кто остался на канале, не смотря на активные продажные посты. Прекрасно понимаю, что многих это может напрягать (да и отписались некоторые), но этого всего на неделю, и сейчас я продолжаю вести канал в обычном формате.
Вообще у меня на этот год в планах хорошо прокачаться с DeFi и аудитами. Сейчас все больше протоколов внедряют к себе какие-либо финансовые механики, большинство из которых просто взяты из популярных протоколов, типа того же Uniswap или Aave. И уязвимости новых форматов все чаще появляются в отчетах на конкурсных площадках. Поэтому придется нам разбирать все материалы "на молекулы".
В ближайших планах перевести некоторые статьи с RareSkills, и там присутствует много показательных графиков и я все думаю как это оформлять в посты. В том смысле, что не хочу делать пост и прикреплять кучу картинок к нему, так сложно будет воспринимать информацию. Скорее всего будет несколько постов с одним скрином к каждому... Но еще экспериментирую с этим...
Кстати, если вам интересны какие-то особенные темы, то дайте знать в комментариях, я постараюсь включить их в темы постов в скором будущем.
Всем еще раз спасибо и приятной недели!
#offtop
Фух, спасибо всем кто присоединился к новому потоку и всем, кто остался на канале, не смотря на активные продажные посты. Прекрасно понимаю, что многих это может напрягать (да и отписались некоторые), но этого всего на неделю, и сейчас я продолжаю вести канал в обычном формате.
Вообще у меня на этот год в планах хорошо прокачаться с DeFi и аудитами. Сейчас все больше протоколов внедряют к себе какие-либо финансовые механики, большинство из которых просто взяты из популярных протоколов, типа того же Uniswap или Aave. И уязвимости новых форматов все чаще появляются в отчетах на конкурсных площадках. Поэтому придется нам разбирать все материалы "на молекулы".
В ближайших планах перевести некоторые статьи с RareSkills, и там присутствует много показательных графиков и я все думаю как это оформлять в посты. В том смысле, что не хочу делать пост и прикреплять кучу картинок к нему, так сложно будет воспринимать информацию. Скорее всего будет несколько постов с одним скрином к каждому... Но еще экспериментирую с этим...
Кстати, если вам интересны какие-то особенные темы, то дайте знать в комментариях, я постараюсь включить их в темы постов в скором будущем.
Всем еще раз спасибо и приятной недели!
#offtop
👍18🌭3🤬2👎1
Как Uniswap V2 вычисляет mintFee?
В нескольких постах попробует разобрать всю ту ересь, которую вы можете увидеть на скрине выше. К слову сказать, изучив статью, я сам разобрался как рассчитывает комиссия, но вот дословно разобрать всю формулу... уффф, вряд ли смогу. У меня вообще не математический склад ума, как я уже не однократно писал. Но поехали по порядку.
Uniswap V2 был разработан для сбора 1/6 части комиссии за своп в протоколе. Так как комиссия за своп составляет 0,3%, 1/6 часть от этой суммы равна 0,05%; то есть 0,05% от каждой сделки должно идти в протокол.
Ранее мы уже обсуждали, что сама процедура взимания комиссии за своп еще не активирована. Одной из причин может быть то, что это крайне не эффективное занятие. Посудите сами, при каждом свопе требовался бы дополнительный перевод токенов в пул (комиссия) и обновление переменных. И это при условии, что в одном пуле есть оба необходимых для свопа токена. А если нужно использовать несколько пулов? В общем, в V2 посчитали это трудоемким процессом.
Именно поэтому комиссия взимается, когда поставщик ликвидности вызывает функции burn или mint. Поскольку эти операции происходят нечасто по сравнению с обменом токенов, это приведет к экономии газа и стоимости самой транзакции.
Для того чтобы собрать mintFee, контракт вычисляет сумму комиссий, собранных с момента последней операции, и чеканит на адрес получателя достаточное количество токенов LP, чтобы вкладчик имел право на 1/6 часть самого сбора.
P.S. Во избежание путаницы в терминологии, мы обозначаем "fee" как 0,3%, взимаемые с трейдеров во время свопа, а "mintFee" - как 1/6 часть от 0,3%. Да, наличие комиссии в обоих терминах - не самая лучшая номенклатура, но это то, с чем нам приходится работать.
P.P.S. Также в данном контексте "ликвидность" - это квадратный корень из произведения остатков токенов в пуле. В некоторых источниках она обозначается как √𝑘, где 𝑘 = 𝑥𝑦, а 𝑥 и 𝑦 - остатки токенов.
Что еще нужно держать в уме для дальнейшего разбора?
В этой работе расчетов Uniswap V2 опирается на следующие два инварианта:
1. Если mint и burn не вызываются, ликвидность пула может только увеличиваться;
2. Увеличение ликвидности происходит исключительно за счет комиссий;
Таким образом, измеряя увеличение ликвидности с момента последнего mint или burn, пул понимает, сколько сборов было собрано.
Давайте разберем на примере, чтобы было чуть нагляднее.
Предположим, что в t₁ пул начинается с 10 токенов_0 и 10 токенов_1.
После множества торгов и сбора комиссии новый баланс пула составляет 40 токенов_0 и 40 токенов_1 в t₂.
Ликвидность измеряется как квадратный корень из произведения двух токенов, то есть ликвидность = sqrt(xy). Ликвидность составляла 10 на t₁ и 40 на t₂, sqrt(100) и sqrt(1600) соответственно. Мы собираемся взимать комиссию за рост с 10 до 40.
То есть 3/4, или 30 единиц ликвидности пула, приходится на комиссию. Мы хотим сминтить достаточное количество токенов LP, "mintFee", чтобы бенефициар получал 1/6 часть "комиссионной части" пула. То есть он должен иметь право на 5 единиц ликвидности (30 / 6).
Для формулы на скрине мы используем следующие обозначения:
s - количество LP токенов до сбора комиссии
η - комиссия
ℓ1 - ликвидность до сбора комиссии
ℓ2 - ликвидность после сбора комиссии
И ключевой инвариант:
η / p = s / d
То есть? если mintFee η может выкупить (redeem) количество ликвидности в протоколе 𝑝, то первоначальное предложение LP s может выкупить (redeem) оставшуюся часть пула d.
Именно этот расчет и показан на скрине.
Но если вам это еще ни о чем не говорит, то дальше мы посмотрим уже в код контракта, и вам точно станет понятнее.
#uniswap #v2 #mintfee
В нескольких постах попробует разобрать всю ту ересь, которую вы можете увидеть на скрине выше. К слову сказать, изучив статью, я сам разобрался как рассчитывает комиссия, но вот дословно разобрать всю формулу... уффф, вряд ли смогу. У меня вообще не математический склад ума, как я уже не однократно писал. Но поехали по порядку.
Uniswap V2 был разработан для сбора 1/6 части комиссии за своп в протоколе. Так как комиссия за своп составляет 0,3%, 1/6 часть от этой суммы равна 0,05%; то есть 0,05% от каждой сделки должно идти в протокол.
Ранее мы уже обсуждали, что сама процедура взимания комиссии за своп еще не активирована. Одной из причин может быть то, что это крайне не эффективное занятие. Посудите сами, при каждом свопе требовался бы дополнительный перевод токенов в пул (комиссия) и обновление переменных. И это при условии, что в одном пуле есть оба необходимых для свопа токена. А если нужно использовать несколько пулов? В общем, в V2 посчитали это трудоемким процессом.
Именно поэтому комиссия взимается, когда поставщик ликвидности вызывает функции burn или mint. Поскольку эти операции происходят нечасто по сравнению с обменом токенов, это приведет к экономии газа и стоимости самой транзакции.
Для того чтобы собрать mintFee, контракт вычисляет сумму комиссий, собранных с момента последней операции, и чеканит на адрес получателя достаточное количество токенов LP, чтобы вкладчик имел право на 1/6 часть самого сбора.
P.S. Во избежание путаницы в терминологии, мы обозначаем "fee" как 0,3%, взимаемые с трейдеров во время свопа, а "mintFee" - как 1/6 часть от 0,3%. Да, наличие комиссии в обоих терминах - не самая лучшая номенклатура, но это то, с чем нам приходится работать.
P.P.S. Также в данном контексте "ликвидность" - это квадратный корень из произведения остатков токенов в пуле. В некоторых источниках она обозначается как √𝑘, где 𝑘 = 𝑥𝑦, а 𝑥 и 𝑦 - остатки токенов.
Что еще нужно держать в уме для дальнейшего разбора?
В этой работе расчетов Uniswap V2 опирается на следующие два инварианта:
1. Если mint и burn не вызываются, ликвидность пула может только увеличиваться;
2. Увеличение ликвидности происходит исключительно за счет комиссий;
Таким образом, измеряя увеличение ликвидности с момента последнего mint или burn, пул понимает, сколько сборов было собрано.
Давайте разберем на примере, чтобы было чуть нагляднее.
Предположим, что в t₁ пул начинается с 10 токенов_0 и 10 токенов_1.
После множества торгов и сбора комиссии новый баланс пула составляет 40 токенов_0 и 40 токенов_1 в t₂.
Ликвидность измеряется как квадратный корень из произведения двух токенов, то есть ликвидность = sqrt(xy). Ликвидность составляла 10 на t₁ и 40 на t₂, sqrt(100) и sqrt(1600) соответственно. Мы собираемся взимать комиссию за рост с 10 до 40.
То есть 3/4, или 30 единиц ликвидности пула, приходится на комиссию. Мы хотим сминтить достаточное количество токенов LP, "mintFee", чтобы бенефициар получал 1/6 часть "комиссионной части" пула. То есть он должен иметь право на 5 единиц ликвидности (30 / 6).
Для формулы на скрине мы используем следующие обозначения:
s - количество LP токенов до сбора комиссии
η - комиссия
ℓ1 - ликвидность до сбора комиссии
ℓ2 - ликвидность после сбора комиссии
И ключевой инвариант:
η / p = s / d
То есть? если mintFee η может выкупить (redeem) количество ликвидности в протоколе 𝑝, то первоначальное предложение LP s может выкупить (redeem) оставшуюся часть пула d.
Именно этот расчет и показан на скрине.
Но если вам это еще ни о чем не говорит, то дальше мы посмотрим уже в код контракта, и вам точно станет понятнее.
#uniswap #v2 #mintfee
🌭6🔥4🤯2👍1
Как Uniswap V2 вычисляет mintFee? Часть 2
После последнего разбора, должны быть понятны основные моменты. Теперь же посмотрим, как это все организовано в самой функции. Ее вы можете увидеть на скрине выше.
Вот некоторые пояснения к выделениям на скрине:
1. rootK - текущая ликвидность после комиссий ℓ₂;
2. kLast - предыдущая ликвидность;
3. totalSupply - количество LP токенов до разбавления S;
4. Отметка синим - функция изменяет состояние контракта; она майнит mintFee внутри самой функции, а не просто возвращает расчет mintFee;
5. Fee могут быть как включены, так и выключены с флагом feeOn (об этом позже)
Мы рассмотрим эту функцию подробнее, но сначала посмотрим, где обновляется kLast.
#uniswap #v2 #mintfee
После последнего разбора, должны быть понятны основные моменты. Теперь же посмотрим, как это все организовано в самой функции. Ее вы можете увидеть на скрине выше.
Вот некоторые пояснения к выделениям на скрине:
1. rootK - текущая ликвидность после комиссий ℓ₂;
2. kLast - предыдущая ликвидность;
3. totalSupply - количество LP токенов до разбавления S;
4. Отметка синим - функция изменяет состояние контракта; она майнит mintFee внутри самой функции, а не просто возвращает расчет mintFee;
5. Fee могут быть как включены, так и выключены с флагом feeOn (об этом позже)
Мы рассмотрим эту функцию подробнее, но сначала посмотрим, где обновляется kLast.
#uniswap #v2 #mintfee
Как Uniswap V2 вычисляет mintFee? Часть 3
В приведенном выше коде kLast не устанавливается, если feeOn равен true.
Он устанавливается при завершении вызовов функция mint и burn, но не самого swap, поскольку мы заинтересованы в измерении роста комиссий из-за свопов между событиями ввода и вывода ликвидности.
Места, где устанавливается kLast, отмечены желтым.
#uniswap #v2 #mintfee
В приведенном выше коде kLast не устанавливается, если feeOn равен true.
Он устанавливается при завершении вызовов функция mint и burn, но не самого swap, поскольку мы заинтересованы в измерении роста комиссий из-за свопов между событиями ввода и вывода ликвидности.
Места, где устанавливается kLast, отмечены желтым.
#uniswap #v2 #mintfee
Как Uniswap V2 вычисляет mintFee? Часть 4
Теперь, когда мы поняли, как обновляется kLast, мы можем полностью объяснить разобрать функцию _mintFee.
Тут нужно взглянуть на скрин, иначе будет ничего не понятно. Следуйте за мной:
1. feeOn равен false, ничего не сминчено (зеленое выделение);
2. feeOn равен false, kLast равен нулю (желтое выделение);
3. feeOn равен false, kLast НЕ равен нулю (желтое выделение);
4. feeOn равен true, но роста ликвидности не произошло (оранжевое выделение);
5. feeOn равен true, но был рост ликвидности (оранжевое выделение), поэтому применяется mint fee (синее выделение);
Ниже будет представлен древовидный ход выполнения функции для лучшего визуального восприятия.
#uniswap #v2 #mintfee
Теперь, когда мы поняли, как обновляется kLast, мы можем полностью объяснить разобрать функцию _mintFee.
Тут нужно взглянуть на скрин, иначе будет ничего не понятно. Следуйте за мной:
1. feeOn равен false, ничего не сминчено (зеленое выделение);
2. feeOn равен false, kLast равен нулю (желтое выделение);
3. feeOn равен false, kLast НЕ равен нулю (желтое выделение);
4. feeOn равен true, но роста ликвидности не произошло (оранжевое выделение);
5. feeOn равен true, но был рост ликвидности (оранжевое выделение), поэтому применяется mint fee (синее выделение);
Ниже будет представлен древовидный ход выполнения функции для лучшего визуального восприятия.
#uniswap #v2 #mintfee
❤1
Как Uniswap V2 вычисляет mintFee? Часть 5
Разбирая такие технические части протоколов, неизбежно получается много коротких постов со скринами. Как вам вообще?
Если больше зашел описательный первый пост, то остановимся на его формате, если несколько мелких тоже норм, то буду делать полное описание и перевод.
#uniswap #v2 #mintfee
Разбирая такие технические части протоколов, неизбежно получается много коротких постов со скринами. Как вам вообще?
Если больше зашел описательный первый пост, то остановимся на его формате, если несколько мелких тоже норм, то буду делать полное описание и перевод.
#uniswap #v2 #mintfee
🔥2
Архитектура Uniswap V2
Думаю, разбор Uniswap контрактов нужно было начинать именно с этого поста, но как-то дошел до не в самом конце. Поэтому в общей сводке всех постов по теме, поставлю его в самом начале.
Архитектура Uniswap V2 удивительно проста.
В ее основе лежит контракт UniswapV2Pair, в котором хранятся два токена ERC20. Через него трейдеры могут менять токены один на другой, а поставщики ликвидности - предоставлять эти самые токены.
Для каждой возможной пары UniswapV2Pair существует свой одноименный контракт, который управляет ею. Если нужный контракт UniswapV2Pair не существует, новый может быть создан из контракта UniswapV2Factory.
Контракты UniswapV2Pair также являются токенами ERC20 (и наследуют от ERC20). Этот токен используется для отслеживания депозитов аналогично тому, как работает ERC4626.
Хотя продвинутые трейдеры или смарт-контракты могут напрямую взаимодействовать с контрактом пары, большинство пользователей будут взаимодействовать с токенами через контракт Router, который имеет несколько удобных функций, например, торговля между парами в одной транзакции и создание «синтетической» пары, если таковой не существует.
Паттерн "core - periphery"
Обратите внимание, что контракт маршрутизатора находится в репозитории под названием «v2 periphery», а пара - в репозитории «v2 core».
Uniswap V2 следует шаблону проектирования «ядро / периферия», где наиболее важная логика находится в ядре, а «необязательная» логика - на периферии.
Это делается для того, чтобы основные контракты содержали как можно меньше кода, что снижает вероятность возникновения ошибок в основной бизнес-логике.
Как определить адрес пула через токены?
Вместо того чтобы обращаться к маппингу пар токенов с адресом пула, смарт-контракты вычисляют адрес пула, предсказывая адрес через create2, как функцию от адресов токенов и адреса фабрики.
Поскольку при этом не происходит обращения к хранилищу, это очень экономит газ. Ниже приведена вспомогательная функция из UniswapV2Library для вычисления адреса парного контракта:
Почему не использовать клоны контрактов через EIP1167?
Многие знают, что иногда копии контрактов создаются с помощью стандарта EIP1167, так почему же Uniswap не использует данную логику?
На самом деле все также просто.
Не смотря на то, что через EIP1167 развертывание контракта копии будет дешевле, но приводит к дополнительным тратам 2300 газа за транзакцию, так как используется delegatecall. И поскольку пулы предназначены для частого использования, экономия от развертывания будет потеряна после нескольких сотен транзакций, поэтому по итогу проще создавать новый контракт с нуля.
Надеюсь, вам понравились наши небольшие разборы Uniswap V2. На этой неделе выйдет еще пара постов про AMM, а потом перейдем к AAVE и Compound.
#uniswap #core #periphery
Думаю, разбор Uniswap контрактов нужно было начинать именно с этого поста, но как-то дошел до не в самом конце. Поэтому в общей сводке всех постов по теме, поставлю его в самом начале.
Архитектура Uniswap V2 удивительно проста.
В ее основе лежит контракт UniswapV2Pair, в котором хранятся два токена ERC20. Через него трейдеры могут менять токены один на другой, а поставщики ликвидности - предоставлять эти самые токены.
Для каждой возможной пары UniswapV2Pair существует свой одноименный контракт, который управляет ею. Если нужный контракт UniswapV2Pair не существует, новый может быть создан из контракта UniswapV2Factory.
Контракты UniswapV2Pair также являются токенами ERC20 (и наследуют от ERC20). Этот токен используется для отслеживания депозитов аналогично тому, как работает ERC4626.
Хотя продвинутые трейдеры или смарт-контракты могут напрямую взаимодействовать с контрактом пары, большинство пользователей будут взаимодействовать с токенами через контракт Router, который имеет несколько удобных функций, например, торговля между парами в одной транзакции и создание «синтетической» пары, если таковой не существует.
Паттерн "core - periphery"
Обратите внимание, что контракт маршрутизатора находится в репозитории под названием «v2 periphery», а пара - в репозитории «v2 core».
Uniswap V2 следует шаблону проектирования «ядро / периферия», где наиболее важная логика находится в ядре, а «необязательная» логика - на периферии.
Это делается для того, чтобы основные контракты содержали как можно меньше кода, что снижает вероятность возникновения ошибок в основной бизнес-логике.
Как определить адрес пула через токены?
Вместо того чтобы обращаться к маппингу пар токенов с адресом пула, смарт-контракты вычисляют адрес пула, предсказывая адрес через create2, как функцию от адресов токенов и адреса фабрики.
Поскольку при этом не происходит обращения к хранилищу, это очень экономит газ. Ниже приведена вспомогательная функция из UniswapV2Library для вычисления адреса парного контракта:
function pairFor(address factory, address tokenA, address tokenB) internal pure returns (address pair) {
(address token0, address token1) = sortTokens(tokenA, tokenB);
pair = address(uint(keccak256(abi.encodePacked(
hex'ff',
factory,
keccak256(abi.encodePacked(token0, token1)),
hex'96e8ac4277198ff8b6f785478aa9a39f403cb768dd02cbee326c3e7da348845f'
))));
}Почему не использовать клоны контрактов через EIP1167?
Многие знают, что иногда копии контрактов создаются с помощью стандарта EIP1167, так почему же Uniswap не использует данную логику?
На самом деле все также просто.
Не смотря на то, что через EIP1167 развертывание контракта копии будет дешевле, но приводит к дополнительным тратам 2300 газа за транзакцию, так как используется delegatecall. И поскольку пулы предназначены для частого использования, экономия от развертывания будет потеряна после нескольких сотен транзакций, поэтому по итогу проще создавать новый контракт с нуля.
Надеюсь, вам понравились наши небольшие разборы Uniswap V2. На этой неделе выйдет еще пара постов про AMM, а потом перейдем к AAVE и Compound.
#uniswap #core #periphery
🌭4👍2👌1
Погружение в DeFi. Все о Uniswap V2
Пора подвести некоторые итоги нашего разбора Uniswap V2 и обозначить все посты, где мы говорили про эту платформу.
Сводный пост про основные DeFi
Гайд по изучению Uniswap (2 части)
Архитектура Uniswap V2
Как Uniswap V2 вычисляет mintFee? (5 частей)
Разбор Uniswap V2: Router контракты (3 части)
Uniswap V2: UniswapV2Library (2 части)
Как работает TWAP в Uniswap V2 (3 части)
Разбор Uniswap V2: mint() & burn() (3 части)
Uniswap V2: swap() (5 частей)
Сборник ресурсов по Uniswap V2/V3
Всего было написано 26 постов! Ух, даже самому не верится!
Далее в планах пара слов о Sushiswap и Aave, а также более детальное погружение в Compound.
Будет сложно, но интересно!
#defi
Пора подвести некоторые итоги нашего разбора Uniswap V2 и обозначить все посты, где мы говорили про эту платформу.
Сводный пост про основные DeFi
Гайд по изучению Uniswap (2 части)
Архитектура Uniswap V2
Как Uniswap V2 вычисляет mintFee? (5 частей)
Разбор Uniswap V2: Router контракты (3 части)
Uniswap V2: UniswapV2Library (2 части)
Как работает TWAP в Uniswap V2 (3 части)
Разбор Uniswap V2: mint() & burn() (3 части)
Uniswap V2: swap() (5 частей)
Сборник ресурсов по Uniswap V2/V3
Всего было написано 26 постов! Ух, даже самому не верится!
Далее в планах пара слов о Sushiswap и Aave, а также более детальное погружение в Compound.
Будет сложно, но интересно!
#defi
🔥14🌭2👍1🤔1
Введение в Automated Market Makers (AMM)
Uniswap, который мы так старательно разбирали ранее, это приложение DeFi, позволяющее трейдерам обменивать один токен на другой. По сути, он был одним из первых автоматизированных маркет-мейкеров (AMM) для торговли, хоть и не первый.
P.S.Автоматические маркет-мейкеры - это альтернатива книге заявок, о которой мы поговорим чуть позже.
Как работают АММ?
Автоматический маркет-мейкер хранит в пуле (смарт-контракте) два токена (токен X и токен Y). Он позволяет любому вывести токен X из пула, но при этом он должен внести такое количество токена Y, чтобы «общая сумма» активов в пуле не уменьшилась.
«Общая сумма» - это произведение сумм двух активов:
Здесь 𝒳′ и 𝒴′ - остатки токенов в пуле после сделки, а 𝒳 и 𝒴 - количество токенов в пуле до сделки.
Это гарантирует, что активы пула могут либо оставаться неизменными, либо увеличиваться.
Большинство пулов также взимают определенную комиссию. В этом случае произведение балансов должно не только увеличиться, но и вырасти на определенную сумму, с учетом комиссии.
Активы предоставляются пулу поставщиками ликвидности, которые получают так называемые LP-токены, представляющие их долю в пуле.
Балансы поставщиков ликвидности отслеживается аналогично тому, как это работает в ERC4626.
Разница между AMM и ERC4626 заключается в том, что ERC4626 поддерживает только один актив, а AMM работает с двумя токенами. Поэтому как и в vault, доля поставщиков ликвидности в пуле остается прежней, при этом сам продукт 𝒳𝒴 может становиться больше, увеличивая долю поставщиков.
Преимущества АММ
1. В АММ определение цены актива происходит автоматически. Оно определяется соотношением активов в пуле.
В частности, если у нас есть токен 𝒳 и токен 𝒴, цена определяется следующим образом:
price (x) = poolHoldings_Y / poolHoldings_X
И наоборот для 𝒴. То есть, чем больше актива 𝒳 попадает в пул, тем больше его «изобилие», и цена 𝒳 снижается.
2. Также у нас нет необходимости ждать, пока появится подходящий ордер «бид» или «аск». Он существует всегда.
3. Если существует несоответствие между ценой в AMM и на другой бирже, то трейдер будет арбитражировать разницу, возвращая цены в равновесие.
Следует подчеркнуть, что речь идет о «спотовой» или «маржинальной» цене. Если вы купите любое количество 𝒳, фактическая цена, которую вы заплатите, будет хуже, чем результат этого расчета.
4. АММ удваивается как оракул.
Поскольку цена активов определяется автоматически, другие смарт-контракты могут использовать AMM в качестве ценового оракула. Однако ценами AMM можно манипулировать с помощью флэш-кредитов, поэтому при использовании AMM таким образом необходимо предусмотреть меры предосторожности.
5. AMM отличаются высокой газовой эффективностью по сравнению с книгами заявок.
Книги заявок требуют значительного объема бухгалтерского учета. В AMM нужно хранить только два токена и передавать их в соответствии с простыми правилами. Это делает их более эффективными в применении.
На этом пока все, а в следующем посты мы поговорим про недостатки AMM.
#amm
Uniswap, который мы так старательно разбирали ранее, это приложение DeFi, позволяющее трейдерам обменивать один токен на другой. По сути, он был одним из первых автоматизированных маркет-мейкеров (AMM) для торговли, хоть и не первый.
P.S.Автоматические маркет-мейкеры - это альтернатива книге заявок, о которой мы поговорим чуть позже.
Как работают АММ?
Автоматический маркет-мейкер хранит в пуле (смарт-контракте) два токена (токен X и токен Y). Он позволяет любому вывести токен X из пула, но при этом он должен внести такое количество токена Y, чтобы «общая сумма» активов в пуле не уменьшилась.
«Общая сумма» - это произведение сумм двух активов:
𝒳𝒴 ≤ 𝒳′𝒴′
Здесь 𝒳′ и 𝒴′ - остатки токенов в пуле после сделки, а 𝒳 и 𝒴 - количество токенов в пуле до сделки.
Это гарантирует, что активы пула могут либо оставаться неизменными, либо увеличиваться.
Большинство пулов также взимают определенную комиссию. В этом случае произведение балансов должно не только увеличиться, но и вырасти на определенную сумму, с учетом комиссии.
Активы предоставляются пулу поставщиками ликвидности, которые получают так называемые LP-токены, представляющие их долю в пуле.
Балансы поставщиков ликвидности отслеживается аналогично тому, как это работает в ERC4626.
Разница между AMM и ERC4626 заключается в том, что ERC4626 поддерживает только один актив, а AMM работает с двумя токенами. Поэтому как и в vault, доля поставщиков ликвидности в пуле остается прежней, при этом сам продукт 𝒳𝒴 может становиться больше, увеличивая долю поставщиков.
Преимущества АММ
1. В АММ определение цены актива происходит автоматически. Оно определяется соотношением активов в пуле.
В частности, если у нас есть токен 𝒳 и токен 𝒴, цена определяется следующим образом:
price (x) = poolHoldings_Y / poolHoldings_X
И наоборот для 𝒴. То есть, чем больше актива 𝒳 попадает в пул, тем больше его «изобилие», и цена 𝒳 снижается.
2. Также у нас нет необходимости ждать, пока появится подходящий ордер «бид» или «аск». Он существует всегда.
3. Если существует несоответствие между ценой в AMM и на другой бирже, то трейдер будет арбитражировать разницу, возвращая цены в равновесие.
Следует подчеркнуть, что речь идет о «спотовой» или «маржинальной» цене. Если вы купите любое количество 𝒳, фактическая цена, которую вы заплатите, будет хуже, чем результат этого расчета.
4. АММ удваивается как оракул.
Поскольку цена активов определяется автоматически, другие смарт-контракты могут использовать AMM в качестве ценового оракула. Однако ценами AMM можно манипулировать с помощью флэш-кредитов, поэтому при использовании AMM таким образом необходимо предусмотреть меры предосторожности.
5. AMM отличаются высокой газовой эффективностью по сравнению с книгами заявок.
Книги заявок требуют значительного объема бухгалтерского учета. В AMM нужно хранить только два токена и передавать их в соответствии с простыми правилами. Это делает их более эффективными в применении.
На этом пока все, а в следующем посты мы поговорим про недостатки AMM.
#amm
❤7
Введение в Automated Market Makers (AMM). Часть 2
И раз уж мы в прошлом посте обозначили достоинства АММ, то самое время поговорить и о его недостатках.
У автоматических маркет-мейкеров есть два основных недостатка:
1. цена всегда движется и
2. постоянные потери для поставщиков ликвидности
Даже небольшие ордера двигают цену в АММ.
Если вы разместите ордер на покупку 100 акций Apple, ваш ордер не приведет к движению цены, потому что существуют тысячи акций, доступных для продажи по указанной вами цене. С автоматическим маркет-мейкером дело обстоит иначе. Каждая сделка, какой бы маленькой она ни была, приводит цену в движение.
И это имеет свои последствия.
Ордера на покупку или продажу обычно сталкиваются с большим проскальзыванием, а механизмы свапов уязвимы к сэндвич атакам.
Сэндвич атаки, в значительной степени, неизбежны в любом AMM.
Поскольку каждый ордер будет двигать цену, трейдеры MEV (Maximal Extractable Value) будут ждать, пока поступит достаточно большой ордер, затем сразу за ним выставят ордер на покупку, а сразу после него - на продажу. Опережающий ордер на покупку поднимет цену для первоначального трейдера, что обеспечит ему худшее исполнение. Это и называется «сэндвич-атакой», поскольку сделка жертвы «зажата» между атакующими.
Грубо говоря:
1) Первая покупка атакующего (frontrun): повышает цену для жертвы;
2) Покупка жертвы: рост цены еще больше;
3) Продажа атакующего: продажа первой покупки с прибылью;
Также поставщики ликвидности не могут контролировать цену, по которой продаются их активы.
По причинам, которые мы обсудим позже, поставщики ликвидности могут предоставлять активы только пропорционально текущему соотношению токенов в пуле. Например, если есть 100 токенов 𝒳 и 200 токенов 𝒴, новый поставщик ликвидности должен предоставить в два раза больше токенов 𝒴, чем 𝒳.
В традиционной книге заявок маркет-мейкер может размещать лимитные ордера на уровнях, которые, по его мнению, отражают желательную цену покупки или продажи (например, размещать ордер на покупку ниже текущей рыночной цены или ордер на продажу выше текущей рыночной цены), но это невозможно в случае с автоматизированным маркет-мейкером.
Помните, что автоматические маркет-мейкеры используют формулу для установления цен на основе соотношения активов в пуле, в результате чего маркет-мейкеры не могут устанавливать конкретные цены, по которым они хотят продать свои активы.
Именно поэтому поставщики ликвидности для АММ могут пострадать от непостоянных убытков.
Допустим, в гипотетическом сценарии Эфир начинается с $10 и позже будет стоить $1000.
Если у кого-то есть портфель из 1 Ether и 10 USD, то его портфель начинается с 20 долларов и заканчивается 1010 долларами (1 ETH + 10 долларов). Их прибыль составит $990.
Если бы они хранили деньги в AMM, то упустили бы большую часть прибыли. После изменения цены в AMM осталось бы 0,1 ETH и 100 долларов США. Это правильно оценивает ETH в 1000 долларов, но чистая стоимость пула составляет менее 990 долларов.
Вот как будут выглядеть холдинги пула до и после изменения цены:
Хотя количество стейблкоинов выросло в 10 раз, количество Эфира снизилось. В итоге стоимость наших активов в пуле выросла меньше, чем если бы мы держали их по отдельности.
Думаю, мы частенько будет возвращаться к этим темам в течение наших разборов DeFi, поэтому не расстраивайтесь, если мало что поняли из этого поста. Дальше будет проще.
#amm
И раз уж мы в прошлом посте обозначили достоинства АММ, то самое время поговорить и о его недостатках.
У автоматических маркет-мейкеров есть два основных недостатка:
1. цена всегда движется и
2. постоянные потери для поставщиков ликвидности
Даже небольшие ордера двигают цену в АММ.
Если вы разместите ордер на покупку 100 акций Apple, ваш ордер не приведет к движению цены, потому что существуют тысячи акций, доступных для продажи по указанной вами цене. С автоматическим маркет-мейкером дело обстоит иначе. Каждая сделка, какой бы маленькой она ни была, приводит цену в движение.
И это имеет свои последствия.
Ордера на покупку или продажу обычно сталкиваются с большим проскальзыванием, а механизмы свапов уязвимы к сэндвич атакам.
Сэндвич атаки, в значительной степени, неизбежны в любом AMM.
Поскольку каждый ордер будет двигать цену, трейдеры MEV (Maximal Extractable Value) будут ждать, пока поступит достаточно большой ордер, затем сразу за ним выставят ордер на покупку, а сразу после него - на продажу. Опережающий ордер на покупку поднимет цену для первоначального трейдера, что обеспечит ему худшее исполнение. Это и называется «сэндвич-атакой», поскольку сделка жертвы «зажата» между атакующими.
Грубо говоря:
1) Первая покупка атакующего (frontrun): повышает цену для жертвы;
2) Покупка жертвы: рост цены еще больше;
3) Продажа атакующего: продажа первой покупки с прибылью;
Также поставщики ликвидности не могут контролировать цену, по которой продаются их активы.
По причинам, которые мы обсудим позже, поставщики ликвидности могут предоставлять активы только пропорционально текущему соотношению токенов в пуле. Например, если есть 100 токенов 𝒳 и 200 токенов 𝒴, новый поставщик ликвидности должен предоставить в два раза больше токенов 𝒴, чем 𝒳.
В традиционной книге заявок маркет-мейкер может размещать лимитные ордера на уровнях, которые, по его мнению, отражают желательную цену покупки или продажи (например, размещать ордер на покупку ниже текущей рыночной цены или ордер на продажу выше текущей рыночной цены), но это невозможно в случае с автоматизированным маркет-мейкером.
Помните, что автоматические маркет-мейкеры используют формулу для установления цен на основе соотношения активов в пуле, в результате чего маркет-мейкеры не могут устанавливать конкретные цены, по которым они хотят продать свои активы.
Именно поэтому поставщики ликвидности для АММ могут пострадать от непостоянных убытков.
Допустим, в гипотетическом сценарии Эфир начинается с $10 и позже будет стоить $1000.
Если у кого-то есть портфель из 1 Ether и 10 USD, то его портфель начинается с 20 долларов и заканчивается 1010 долларами (1 ETH + 10 долларов). Их прибыль составит $990.
Если бы они хранили деньги в AMM, то упустили бы большую часть прибыли. После изменения цены в AMM осталось бы 0,1 ETH и 100 долларов США. Это правильно оценивает ETH в 1000 долларов, но чистая стоимость пула составляет менее 990 долларов.
Вот как будут выглядеть холдинги пула до и после изменения цены:
(ETH_before)(USD_before) <= (ETH_after)(USD_after)
(1 ETH)(10 USD) <= (0.1 ETH)(100 USD)
10 <= 10
Хотя количество стейблкоинов выросло в 10 раз, количество Эфира снизилось. В итоге стоимость наших активов в пуле выросла меньше, чем если бы мы держали их по отдельности.
Думаю, мы частенько будет возвращаться к этим темам в течение наших разборов DeFi, поэтому не расстраивайтесь, если мало что поняли из этого поста. Дальше будет проще.
#amm
🔥2
Что такое книги заявок (ордеров)?
В постах про АММ несколько раз упоминались книги ордеров, и сегодня хотел бы сказать пару слов о них.
Итак, термин "книга заявок" означает электронный список заявок на покупку и продажу конкретной ценной бумаги или финансового инструмента, организованный по ценовому уровню.
В книге заявок указывается количество акций, выставленных на продажу или предлагаемых по каждой цене. В нем также указываются участники рынка, стоящие за ордерами на покупку и продажу, хотя некоторые из них предпочитают оставаться анонимными. Эти списки помогают трейдерам, а также повышают прозрачность рынка, поскольку предоставляют ценную торговую информацию.
Книги заявок используются почти на каждой бирже для размещения заявок на различные активы, такие как акции, облигации и валюты - даже криптовалюты, такие как биткойн. Эти ордера могут быть как ручными, так и электронными. Хотя в целом они содержат одну и ту же информацию, в зависимости от источника она может немного отличаться.
Книга заявок динамична, то есть она постоянно обновляется в режиме реального времени в течение дня. Такие биржи, как Nasdaq, называют ее "непрерывной книгой". Ордера, которые предполагают исполнение только при открытии или закрытии рынка, хранятся отдельно. Они известны как "книга открытия (ордеров)" и "книга закрытия (ордеров)" соответственно.
Например, при открытии рынка Nasdaq книги открытия и непрерывные книги объединяются, чтобы создать единую цену открытия. То же самое происходит при закрытии рынка, когда книга закрытия и непрерывная книга консолидируются для создания единой цены закрытия.
Как читают книги заявок?
Обычно книга заявок состоит из трех частей: заявок на покупку, заявок на продажу и истории заявок.
Ордера на покупку содержат информацию о покупателях и их заявки.
Ордера на продажу похожи на ордера на покупку, но вместо этого включают все предложения (или цены спроса) или то, сколько люди готовы продать.
История рыночных ордеров показывает все сделки, которые были совершены в прошлом.
В верхней части книги вы найдете самые высокие цены покупки и самые низкие цены продажи. Они указывают на преобладающий рынок и цену, по которой должен быть исполнен ордер. К книге часто прилагается свечной график, который предоставляет полезную информацию о текущем и прошлом состоянии рынка.
Книга ордеров помогает трейдерам принимать более обоснованные торговые решения. Они могут увидеть, какие брокерские компании покупают или продают акции, и определить, кто движет рынком - розничные инвесторы или институциональные. Книга заявок также показывает дисбаланс заявок, который может дать подсказку о направлении движения акций в краткосрочной перспективе.
Некоторые нюансы с книгами
Хотя книга заявок призвана обеспечить прозрачность для участников рынка, есть некоторые детали, которые не включены в список. К ним относятся "темные пулы". Это группы скрытых ордеров, которые хранятся у крупных игроков, не желающих, чтобы их торговые намерения были известны другим.
Без "темных пулов" биржи столкнулись бы со значительным обесцениванием цен. Когда информация о крупной сделке крупного учреждения становится достоянием общественности до ее совершения, это обычно приводит к падению цены на ценную бумагу. Но если информация о сделке становится известна после ее совершения, влияние на рынок может значительно снизиться.
Наличие "темных пулов" в определенной степени снижает полезность книги заявок, поскольку нет возможности узнать, отражают ли заявки, показанные в книге, реальный спрос и предложение на акции.
Пример типичной книги, вы можете увидеть на скрине выше.
Вообще, это достаточно сложная тема финансового рынка бирж, но нам нужно будет делать обще информационные посты, чтобы вы могли ухватить суть того, что делают современные смарт контракты в сфере DeFi.
#orderbook
В постах про АММ несколько раз упоминались книги ордеров, и сегодня хотел бы сказать пару слов о них.
Итак, термин "книга заявок" означает электронный список заявок на покупку и продажу конкретной ценной бумаги или финансового инструмента, организованный по ценовому уровню.
В книге заявок указывается количество акций, выставленных на продажу или предлагаемых по каждой цене. В нем также указываются участники рынка, стоящие за ордерами на покупку и продажу, хотя некоторые из них предпочитают оставаться анонимными. Эти списки помогают трейдерам, а также повышают прозрачность рынка, поскольку предоставляют ценную торговую информацию.
Книги заявок используются почти на каждой бирже для размещения заявок на различные активы, такие как акции, облигации и валюты - даже криптовалюты, такие как биткойн. Эти ордера могут быть как ручными, так и электронными. Хотя в целом они содержат одну и ту же информацию, в зависимости от источника она может немного отличаться.
Книга заявок динамична, то есть она постоянно обновляется в режиме реального времени в течение дня. Такие биржи, как Nasdaq, называют ее "непрерывной книгой". Ордера, которые предполагают исполнение только при открытии или закрытии рынка, хранятся отдельно. Они известны как "книга открытия (ордеров)" и "книга закрытия (ордеров)" соответственно.
Например, при открытии рынка Nasdaq книги открытия и непрерывные книги объединяются, чтобы создать единую цену открытия. То же самое происходит при закрытии рынка, когда книга закрытия и непрерывная книга консолидируются для создания единой цены закрытия.
Как читают книги заявок?
Обычно книга заявок состоит из трех частей: заявок на покупку, заявок на продажу и истории заявок.
Ордера на покупку содержат информацию о покупателях и их заявки.
Ордера на продажу похожи на ордера на покупку, но вместо этого включают все предложения (или цены спроса) или то, сколько люди готовы продать.
История рыночных ордеров показывает все сделки, которые были совершены в прошлом.
В верхней части книги вы найдете самые высокие цены покупки и самые низкие цены продажи. Они указывают на преобладающий рынок и цену, по которой должен быть исполнен ордер. К книге часто прилагается свечной график, который предоставляет полезную информацию о текущем и прошлом состоянии рынка.
Книга ордеров помогает трейдерам принимать более обоснованные торговые решения. Они могут увидеть, какие брокерские компании покупают или продают акции, и определить, кто движет рынком - розничные инвесторы или институциональные. Книга заявок также показывает дисбаланс заявок, который может дать подсказку о направлении движения акций в краткосрочной перспективе.
Некоторые нюансы с книгами
Хотя книга заявок призвана обеспечить прозрачность для участников рынка, есть некоторые детали, которые не включены в список. К ним относятся "темные пулы". Это группы скрытых ордеров, которые хранятся у крупных игроков, не желающих, чтобы их торговые намерения были известны другим.
Без "темных пулов" биржи столкнулись бы со значительным обесцениванием цен. Когда информация о крупной сделке крупного учреждения становится достоянием общественности до ее совершения, это обычно приводит к падению цены на ценную бумагу. Но если информация о сделке становится известна после ее совершения, влияние на рынок может значительно снизиться.
Наличие "темных пулов" в определенной степени снижает полезность книги заявок, поскольку нет возможности узнать, отражают ли заявки, показанные в книге, реальный спрос и предложение на акции.
Пример типичной книги, вы можете увидеть на скрине выше.
Вообще, это достаточно сложная тема финансового рынка бирж, но нам нужно будет делать обще информационные посты, чтобы вы могли ухватить суть того, что делают современные смарт контракты в сфере DeFi.
#orderbook
👍2
Востребованный Solidity разработчик и DeFi
Участвуя в различных конкурсах по аудиту протоколов, я стал замечать кардинальное усиление современных протоколов в финансовых и биржевых продуктах. Если раньше было очень много проектов связанных с обменом, продажей и игрой NFT, а также простые контракты с покупкой/продажей токенов (они же и мемтокены, и алькоины, и т.д.), то сейчас уже протоколы внедряют сложные деривативные и опционные торги, сложные ликвидации позиций и продуманные механики рестейкинга.
EigenLayer, Uniswap Staker, Renzo, Ethena, Venus, Morpho - это одни из топовых DeFi протоколов, которые выходили на аудиты за последние полгода и привлекали к себе много внимания. Даже сейчас Euler собирается запустить свой конкурс на $ 1 250 000!!! И почему-то мне кажется, что многие протоколы позже возьмут его контракты на форк и будут внедрять в свою базу.
Современному Solidity разработчику уже не достаточно иметь навыков написания простых контрактов токенов / NFT и уметь загружать их в разные сети (коих развелось сейчас...). Необходимо понимать и уметь разбираться в архитектуре и механизмах DeFi протоколов, таких как: стейкинг и рестейкинг, ликвидации и награды, деривативы и опционы, perpetual futures и многое другое. При этом также, в случае необходимости, разбираться с подключением своего контракта к нужному DeFi протоколу!
Это огромная область знаний, на которую уйдет не один час обучения!
На канале мы потихоньку начали разбирать DeFi протоколы, недавно прошли и Uniswap V2 и скоро будем продвигаться дальше. Я хочу вместе с вами еще раз просмотреть контракты популярных контрактов и разобраться в суть их функционирования. Это будет сложно и долго, но мы справимся.
Практически за два года ведения канала, я ни разу не повторился с темами (не было репостов или повторов) и выпускал новые посты практически каждый день. Теперь же моей целью является собрать здесь всю самую "мясную" инфу по DeFi.
Это будет очень интересное полугодие!
#defi
Участвуя в различных конкурсах по аудиту протоколов, я стал замечать кардинальное усиление современных протоколов в финансовых и биржевых продуктах. Если раньше было очень много проектов связанных с обменом, продажей и игрой NFT, а также простые контракты с покупкой/продажей токенов (они же и мемтокены, и алькоины, и т.д.), то сейчас уже протоколы внедряют сложные деривативные и опционные торги, сложные ликвидации позиций и продуманные механики рестейкинга.
EigenLayer, Uniswap Staker, Renzo, Ethena, Venus, Morpho - это одни из топовых DeFi протоколов, которые выходили на аудиты за последние полгода и привлекали к себе много внимания. Даже сейчас Euler собирается запустить свой конкурс на $ 1 250 000!!! И почему-то мне кажется, что многие протоколы позже возьмут его контракты на форк и будут внедрять в свою базу.
Современному Solidity разработчику уже не достаточно иметь навыков написания простых контрактов токенов / NFT и уметь загружать их в разные сети (коих развелось сейчас...). Необходимо понимать и уметь разбираться в архитектуре и механизмах DeFi протоколов, таких как: стейкинг и рестейкинг, ликвидации и награды, деривативы и опционы, perpetual futures и многое другое. При этом также, в случае необходимости, разбираться с подключением своего контракта к нужному DeFi протоколу!
Это огромная область знаний, на которую уйдет не один час обучения!
На канале мы потихоньку начали разбирать DeFi протоколы, недавно прошли и Uniswap V2 и скоро будем продвигаться дальше. Я хочу вместе с вами еще раз просмотреть контракты популярных контрактов и разобраться в суть их функционирования. Это будет сложно и долго, но мы справимся.
Практически за два года ведения канала, я ни разу не повторился с темами (не было репостов или повторов) и выпускал новые посты практически каждый день. Теперь же моей целью является собрать здесь всю самую "мясную" инфу по DeFi.
Это будет очень интересное полугодие!
#defi
👍15🔥7🌭3
Канал разбора конкурсных отчетов
Кстати, я продолжаю вести закрытый канал, где мы разбираем баги с конкурсных аудитов. В день выкладываю по два небольших разбора, иногда делаю посты по нюансам в безопасности СК, на которые стоит обращать внимание, задачки, а также иногда "заходим" в небольшой конкурс и рассматриваем его в течение нескольких дней.
Сейчас уже разобрали более 100 различных уязвимостей и 3 конкурсных протокола. Дальше будем смотреть на проблемы с defil протоколами и сетями l2.
Если хотите прокачать свои навыки в поиске багов и начать чуть лучше разбираться в безопасности протоколов, то приглашаю присоединиться к нам.
Доступ в группу идет по месячной оплате в 1000 рублей, чтобы в ней оставались только те, кому интересная и актуальна тема.
Буду рад новым участникам!
#security
Кстати, я продолжаю вести закрытый канал, где мы разбираем баги с конкурсных аудитов. В день выкладываю по два небольших разбора, иногда делаю посты по нюансам в безопасности СК, на которые стоит обращать внимание, задачки, а также иногда "заходим" в небольшой конкурс и рассматриваем его в течение нескольких дней.
Сейчас уже разобрали более 100 различных уязвимостей и 3 конкурсных протокола. Дальше будем смотреть на проблемы с defil протоколами и сетями l2.
Если хотите прокачать свои навыки в поиске багов и начать чуть лучше разбираться в безопасности протоколов, то приглашаю присоединиться к нам.
Доступ в группу идет по месячной оплате в 1000 рублей, чтобы в ней оставались только те, кому интересная и актуальна тема.
Буду рад новым участникам!
#security
👍5🔥1
Алгоритм стейкинга в Sushiswap MasterChef и Synthetix. Часть 1
Алгоритмы сnейкинга в MasterChef и Synthetix распределяют фиксированный пул вознаграждений между пользователями в соответствии с их взвешенными по времени вкладами в пул. Для того чтобы сэкономить на газе, алгоритмы используют кумулятивный счетчик вознаграждений на уровне токенов и откладывают распределение вознаграждений.
Представьте, что у нас есть фиксированный пул из 100 000 токенов REWARD, который мы хотим справедливо распределить между пользователями в период от блока 1 по 100 блок.
Например, на момент конкретного блока стейкинг у пользователей был следующим:
| Name | Amount Staked | % of Pool |
| :-——-- | :------———-----: | --——-----: |
| Alice | 100 | 25 |
| Bob | 100 | 25 |
| Chad | 200 | 50 |
Тогда токены Rewards распределятся следующим образом:
| Name | Amount Staked | % of Pool | Rewards distribited |
| :-——-- | :----————-----: | --——-----: | ---———--------------: |
| Alice | 100 | 25 | 250 |
| Bob | 100 | 25 | 250 |
| Chad | 200 | 50 | 500 |
P.S. Токен Reward и токен стейкинга (тот же WETH или USDT) могут быть разными или одними и теми же в разных случаях. Для ясности, мы будет называть их именно Reward и просто Token.
Прежде чем рассказывать дальше о том, как же идет подсчет токенов для распределения, необходимо сказать, что отправлять транзакцию каждый блок для распределения вознаграждения вообще непрактично.
Обычно для авто запросов в блокчейн используют ботов (программы, которые могут в заданный момент отправлять транзакцию). Однако это хреновое решение.
Как минимум, потому что нет достаточно надежного способа обеспечить включение транзакций в каждый блок. Если бот пропустит один блок, то пользователи получат меньшее вознаграждение, чем ожидают.
Эта стратегия также повлечет за собой большие транзакционные сборы.
Отказавшись от этой системы, мы можем создавать «догоняющие» вознаграждения за блоки, в которых вознаграждения не были распределены.
Предположим, мы храним переменную в lastUpdateBlockNumber, которая отслеживает последний раз, когда выдавалось вознаграждение. Мы могли бы вычислять количество блоков с момента последнего вознаграждения как
Другими словами, мы можем пропустить несколько блоков, в которых мы распределяем вознаграждение, и «догнать» их, когда мы действительно делаем это.
Но даже при этом способе, у нас до сих пор нет хорошего способа распределить награды, которые мы только что сминтили, между всеми стейкерами в соответствии с их процентной долей.
Кроме того, мы не знаем, были ли балансы токенов постоянными в течение предыдущего интервала, с момента последнего распределения вознаграждения.
Например, что если Чад знал, что мы собираемся измерить остатки на блоке 100, и сделал большой депозит на блоке 99, чтобы получить большую долю вознаграждения?
Эту проблему оказалось легко решить. Как? Узнает в следующем посте цикла.
#Sushiswap #MasterChef #staking
Алгоритмы сnейкинга в MasterChef и Synthetix распределяют фиксированный пул вознаграждений между пользователями в соответствии с их взвешенными по времени вкладами в пул. Для того чтобы сэкономить на газе, алгоритмы используют кумулятивный счетчик вознаграждений на уровне токенов и откладывают распределение вознаграждений.
Представьте, что у нас есть фиксированный пул из 100 000 токенов REWARD, который мы хотим справедливо распределить между пользователями в период от блока 1 по 100 блок.
Например, на момент конкретного блока стейкинг у пользователей был следующим:
| Name | Amount Staked | % of Pool |
| :-——-- | :------———-----: | --——-----: |
| Alice | 100 | 25 |
| Bob | 100 | 25 |
| Chad | 200 | 50 |
Тогда токены Rewards распределятся следующим образом:
| Name | Amount Staked | % of Pool | Rewards distribited |
| :-——-- | :----————-----: | --——-----: | ---———--------------: |
| Alice | 100 | 25 | 250 |
| Bob | 100 | 25 | 250 |
| Chad | 200 | 50 | 500 |
P.S. Токен Reward и токен стейкинга (тот же WETH или USDT) могут быть разными или одними и теми же в разных случаях. Для ясности, мы будет называть их именно Reward и просто Token.
Прежде чем рассказывать дальше о том, как же идет подсчет токенов для распределения, необходимо сказать, что отправлять транзакцию каждый блок для распределения вознаграждения вообще непрактично.
Обычно для авто запросов в блокчейн используют ботов (программы, которые могут в заданный момент отправлять транзакцию). Однако это хреновое решение.
Как минимум, потому что нет достаточно надежного способа обеспечить включение транзакций в каждый блок. Если бот пропустит один блок, то пользователи получат меньшее вознаграждение, чем ожидают.
Эта стратегия также повлечет за собой большие транзакционные сборы.
Отказавшись от этой системы, мы можем создавать «догоняющие» вознаграждения за блоки, в которых вознаграждения не были распределены.
Предположим, мы храним переменную в lastUpdateBlockNumber, которая отслеживает последний раз, когда выдавалось вознаграждение. Мы могли бы вычислять количество блоков с момента последнего вознаграждения как
block.number - lastUpdateBlockNumber;
Другими словами, мы можем пропустить несколько блоков, в которых мы распределяем вознаграждение, и «догнать» их, когда мы действительно делаем это.
Но даже при этом способе, у нас до сих пор нет хорошего способа распределить награды, которые мы только что сминтили, между всеми стейкерами в соответствии с их процентной долей.
Кроме того, мы не знаем, были ли балансы токенов постоянными в течение предыдущего интервала, с момента последнего распределения вознаграждения.
Например, что если Чад знал, что мы собираемся измерить остатки на блоке 100, и сделал большой депозит на блоке 99, чтобы получить большую долю вознаграждения?
Эту проблему оказалось легко решить. Как? Узнает в следующем посте цикла.
#Sushiswap #MasterChef #staking
👍2🔥1
Алгоритм стейкинга в Sushiswap MasterChef и Synthetix. Часть 2
Решением проблемы из предыдущего поста является простое утверждение: нет транзакций, нет изменения балансов.
Вместо того чтобы заставлять оффчейн бота проводить транзакции каждые 20 блоков или что-то типа того, мы можем просто ждать, пока пользователь начнет взаимодействует с контрактом через функции изменения состояния, такие как deposit() или withdraw().
В промежутках между вызовами этих функций мы можем быть уверены, что ничей баланс не изменился.
Например, если между блоком 10 и блоком 15 у Алисы было 50% стейкинга и у Боба - 50%, то мы можем выдать 5 000 REWARD (5 блоков умножить на 1 000) и дать каждому из них по 50%.
У Чада или Боба нет возможности «вскочить» и увеличить свой баланс, потому что когда они вызовут функцию deposit(), то вызовут распределение вознаграждения. А функция распределения вознаграждения запрограммирована так, чтобы не учитывать их недавний депозит.
Посмотрите на график на скрине выше, показывающий изменения баланса с течением времени.
Единственный способ, чтобы эти изменения произошли - это вызвать транзакцию со смарт-контрактом.
Однако это решение не масштабируется.
#Sushiswap #MasterChef #staking
Решением проблемы из предыдущего поста является простое утверждение: нет транзакций, нет изменения балансов.
Вместо того чтобы заставлять оффчейн бота проводить транзакции каждые 20 блоков или что-то типа того, мы можем просто ждать, пока пользователь начнет взаимодействует с контрактом через функции изменения состояния, такие как deposit() или withdraw().
В промежутках между вызовами этих функций мы можем быть уверены, что ничей баланс не изменился.
Например, если между блоком 10 и блоком 15 у Алисы было 50% стейкинга и у Боба - 50%, то мы можем выдать 5 000 REWARD (5 блоков умножить на 1 000) и дать каждому из них по 50%.
У Чада или Боба нет возможности «вскочить» и увеличить свой баланс, потому что когда они вызовут функцию deposit(), то вызовут распределение вознаграждения. А функция распределения вознаграждения запрограммирована так, чтобы не учитывать их недавний депозит.
Посмотрите на график на скрине выше, показывающий изменения баланса с течением времени.
Единственный способ, чтобы эти изменения произошли - это вызвать транзакцию со смарт-контрактом.
Однако это решение не масштабируется.
#Sushiswap #MasterChef #staking
👍4
Алгоритм стейкинга в Sushiswap MasterChef и Synthetix. Часть 3
В дополнение к предыдущему посту.
Распределять каждому стейкеру его REWARD каждый раз, когда кто-то вызывает deposit() или withdraw(), будет очень дорого, если стейкеров десятки. Трансфер токена ERC20 стоит недешево, а делать это десятки раз в цикле - непомерно дорого.
Для того чтобы сделать стейкинг эффективнее, можно придумать систему, когда пользователи получают свое вознаграждение, только тогда, когда вызывают функции изменения состояния.
Для тех, кто не требует вознаграждения, оно откладывается. Вознаграждения остаются в контракте и ждут, когда они будут востребованы.
Это избавит нас от необходимости делать кучу переводов ERC 20.
Из этого следует:
- мы можем обновлять только переменные аккаунта, связанные с адресом, инициирующим транзакцию;
- мы можем обновлять только одну глобальную переменную, которая отслеживает увеличение распределения вознаграждения для всех остальных, не обновляя каждый аккаунт по отдельности;
Кроме всего прочего, вместо того чтобы отслеживать начисление вознаграждения на счетах, мы отслеживаем прибыль от одного поставленного токена.
Предположим, мы можем точно отследить, сколько один токен накопил вознаграждения «с начала времен» (когда контракт начал распределять вознаграждения).
Если это так, то отследить, сколько вознаграждения накопил аккаунт, можно просто умножив его баланс на то, сколько Rewards он накопил с начала времени.
Если звучит запутано, но просто нужно прочитать медленнее и вдуматься в общую схему.
Предположим, мы знаем, что токен с начала времени до текущего момента, собрал 12 Rewards. Поэтому если Алиса сделала депозит в 100 токенов, то ей причитается 1 200 Rewards.
Это все равно что сказать: «Доллар, который вы положили на счет в нашем банке, заработал 0,40 доллара в виде процентов с момента открытия банка. Если вы открыли счет, когда мы открыли банк, и с тех пор не пополняли и не снимали деньги, то вы заработали 40%».
Это приводит нас к двум вопросам:
1. Как отследить начисление вознаграждения за один токен с начала времени?
2. Что, если Алиса не делала депозит с начала времени, а только недавно пополнила счет?
Об этом в следующем посте.
#Sushiswap #MasterChef #staking
В дополнение к предыдущему посту.
Распределять каждому стейкеру его REWARD каждый раз, когда кто-то вызывает deposit() или withdraw(), будет очень дорого, если стейкеров десятки. Трансфер токена ERC20 стоит недешево, а делать это десятки раз в цикле - непомерно дорого.
Для того чтобы сделать стейкинг эффективнее, можно придумать систему, когда пользователи получают свое вознаграждение, только тогда, когда вызывают функции изменения состояния.
Для тех, кто не требует вознаграждения, оно откладывается. Вознаграждения остаются в контракте и ждут, когда они будут востребованы.
Это избавит нас от необходимости делать кучу переводов ERC 20.
Из этого следует:
- мы можем обновлять только переменные аккаунта, связанные с адресом, инициирующим транзакцию;
- мы можем обновлять только одну глобальную переменную, которая отслеживает увеличение распределения вознаграждения для всех остальных, не обновляя каждый аккаунт по отдельности;
Кроме всего прочего, вместо того чтобы отслеживать начисление вознаграждения на счетах, мы отслеживаем прибыль от одного поставленного токена.
Предположим, мы можем точно отследить, сколько один токен накопил вознаграждения «с начала времен» (когда контракт начал распределять вознаграждения).
Если это так, то отследить, сколько вознаграждения накопил аккаунт, можно просто умножив его баланс на то, сколько Rewards он накопил с начала времени.
Если звучит запутано, но просто нужно прочитать медленнее и вдуматься в общую схему.
Предположим, мы знаем, что токен с начала времени до текущего момента, собрал 12 Rewards. Поэтому если Алиса сделала депозит в 100 токенов, то ей причитается 1 200 Rewards.
Это все равно что сказать: «Доллар, который вы положили на счет в нашем банке, заработал 0,40 доллара в виде процентов с момента открытия банка. Если вы открыли счет, когда мы открыли банк, и с тех пор не пополняли и не снимали деньги, то вы заработали 40%».
Это приводит нас к двум вопросам:
1. Как отследить начисление вознаграждения за один токен с начала времени?
2. Что, если Алиса не делала депозит с начала времени, а только недавно пополнила счет?
Об этом в следующем посте.
#Sushiswap #MasterChef #staking
👍3❤1