RSA алгоритмы. Часть 1
Как и говорил ранее, мы разберем новую для канала тему, которая может быть кстати при изучении такого DeFi протокола, как Tornado Cash. Итак, поехали!
Введение в ECDSA и RSA
Создание контракта, предоставляющего определенным адресам прав, имеет несколько названий: airdrops, presale, whitelist, allowlist и так далее. Но суть идеи заключается в том, что есть набор адресов, которые имеют специальное разрешение на покупку токена высокого спроса по желаемой цене (иногда бесплатно). Для этого есть три устоявшихся решения: маппинги, деревья Меркла и ECDSA подписи.
Mapping presale работает следующим образом: продавец вводит адреса покупателей в маппинг, с аргументами от адреса к булеву, чтобы отметить, является ли адрес привилегированным или нет. После того как покупатель завершит транзакцию, в маппинге устанавливается значение false.
Таким образом, только адреса, отмеченные как true, могут совершить покупку. Это очень экономит газ для покупателя, но сам продавец может потратить очень много газа на составление этих allowlist для тысяч адресов (добавление каждого адреса в allowlist обойдется минимум в 22 100 газа). Поэтому деревья Меркла и подписи ECDSA (с использованием ecerecover) часто предпочитаются маппингам.
Стоимость газа (для покупателя) при выполнении проверки подписи ECDSA составляет 29 293 газа. Сюда входит 21 000 на инициирование транзакции, поэтому стоимость ECDSA составляет 8 293. Обратите внимание, что сюда входит чтение адреса подписи из хранилища, но эти затраты необходимы, иначе мы не сможем признать подпись недействительной.
Деревья Меркла различаются по стоимости в зависимости от размера дерева (большие деревья требуют больших доказательств), но если в древе более 1 000 адресов, то проверка адреса обойдется как минимум в 32 000 газа (или больше). Такая стоимость явно уступает ECDSA.
Итак, наша задача состоит в том, чтобы побить ECDSA, который стоит 8 293 газа. Для того, чтобы решения не отличались друг от друга, альтернативное решение должно:
1. Уметь обнулять адреса из списка разрешенных. Деревья Меркла могут менять свой корень, ECDSA - адрес подписи, а маппинги - устанавливать значения true/false;
2. Не налагать существенного бремени расходов на продавца, как это делают маппинги;
3. Стоить менее 8 200 единиц газа для покупателя (включая нагрузку на хранилище);
4. Не подвергаться риску в плане безопасности;
И далее мы поговорим о самом RSA алгоритме.
#rsa
Как и говорил ранее, мы разберем новую для канала тему, которая может быть кстати при изучении такого DeFi протокола, как Tornado Cash. Итак, поехали!
Введение в ECDSA и RSA
Создание контракта, предоставляющего определенным адресам прав, имеет несколько названий: airdrops, presale, whitelist, allowlist и так далее. Но суть идеи заключается в том, что есть набор адресов, которые имеют специальное разрешение на покупку токена высокого спроса по желаемой цене (иногда бесплатно). Для этого есть три устоявшихся решения: маппинги, деревья Меркла и ECDSA подписи.
Mapping presale работает следующим образом: продавец вводит адреса покупателей в маппинг, с аргументами от адреса к булеву, чтобы отметить, является ли адрес привилегированным или нет. После того как покупатель завершит транзакцию, в маппинге устанавливается значение false.
Таким образом, только адреса, отмеченные как true, могут совершить покупку. Это очень экономит газ для покупателя, но сам продавец может потратить очень много газа на составление этих allowlist для тысяч адресов (добавление каждого адреса в allowlist обойдется минимум в 22 100 газа). Поэтому деревья Меркла и подписи ECDSA (с использованием ecerecover) часто предпочитаются маппингам.
Стоимость газа (для покупателя) при выполнении проверки подписи ECDSA составляет 29 293 газа. Сюда входит 21 000 на инициирование транзакции, поэтому стоимость ECDSA составляет 8 293. Обратите внимание, что сюда входит чтение адреса подписи из хранилища, но эти затраты необходимы, иначе мы не сможем признать подпись недействительной.
Деревья Меркла различаются по стоимости в зависимости от размера дерева (большие деревья требуют больших доказательств), но если в древе более 1 000 адресов, то проверка адреса обойдется как минимум в 32 000 газа (или больше). Такая стоимость явно уступает ECDSA.
Итак, наша задача состоит в том, чтобы побить ECDSA, который стоит 8 293 газа. Для того, чтобы решения не отличались друг от друга, альтернативное решение должно:
1. Уметь обнулять адреса из списка разрешенных. Деревья Меркла могут менять свой корень, ECDSA - адрес подписи, а маппинги - устанавливать значения true/false;
2. Не налагать существенного бремени расходов на продавца, как это делают маппинги;
3. Стоить менее 8 200 единиц газа для покупателя (включая нагрузку на хранилище);
4. Не подвергаться риску в плане безопасности;
И далее мы поговорим о самом RSA алгоритме.
#rsa
2👍6
Упражнение для начинающих аудиторов
Сейчас проходит небольшой конкурс на платформе code4rena под названием LamboWin. Я потихоньку разбираю его, и вчера мне показалось, что он может стать прекрасным упражнением для начинающих аудиторов!
Во-первых, сам по себе он очень маленький, всего около 600 строк кода.
Во-вторых, там много "перекликаний" между контрактами.
В-третьих, есть интеграция с Uniswap V2.
И дело тут, скорее, не в том, чтобы найти какие-либо уязвимости (протокол хорошо написан), а в том, чтобы научиться понимать архитектуру протокола, внутренние вызовы, перетекания токенов и Эфира из контракта в контракт и т.д.
Если захотите потренироваться сами, то вот репо протокола:
https://github.com/code-423n4/2024-12-lambowin
И вам нужно будет ответить на следующие вопросы:
1. Что такое Lambo токен и Veth?
2. Как происходит создание Lambo токена?
3. Как происходит покупка Lambo токена?
4. Где хранятся Lambo токены?
5. Как на Uniswap v2 появляется ликвидность?
***
1. От чего зависит цена Lambo токена?
Также нарисуйте схемы:
1. Создание нового Lambo токена;
2. От отправки пользователем Эфира до получения токена;
3. Кто является msg.sender в каждом внутреннем вызове при покупке токена;
4. Процесс вывода токена с Uniswap v2 - что пользователю нужно отправить и что получит в конце;
Протокол не такой нудный и мне было интересно разбирать его и копаться в вызовах. Давно не встречал конкурс, чтобы в минимальном коде было столько общих тем по работе с токенами!
В общем, если вы хотите начать принимать участие в конкурсах, то это станет прекрасным упражнением!
#audit
Сейчас проходит небольшой конкурс на платформе code4rena под названием LamboWin. Я потихоньку разбираю его, и вчера мне показалось, что он может стать прекрасным упражнением для начинающих аудиторов!
Во-первых, сам по себе он очень маленький, всего около 600 строк кода.
Во-вторых, там много "перекликаний" между контрактами.
В-третьих, есть интеграция с Uniswap V2.
И дело тут, скорее, не в том, чтобы найти какие-либо уязвимости (протокол хорошо написан), а в том, чтобы научиться понимать архитектуру протокола, внутренние вызовы, перетекания токенов и Эфира из контракта в контракт и т.д.
Если захотите потренироваться сами, то вот репо протокола:
https://github.com/code-423n4/2024-12-lambowin
И вам нужно будет ответить на следующие вопросы:
1. Что такое Lambo токен и Veth?
2. Как происходит создание Lambo токена?
3. Как происходит покупка Lambo токена?
4. Где хранятся Lambo токены?
5. Как на Uniswap v2 появляется ликвидность?
***
1. От чего зависит цена Lambo токена?
Также нарисуйте схемы:
1. Создание нового Lambo токена;
2. От отправки пользователем Эфира до получения токена;
3. Кто является msg.sender в каждом внутреннем вызове при покупке токена;
4. Процесс вывода токена с Uniswap v2 - что пользователю нужно отправить и что получит в конце;
Протокол не такой нудный и мне было интересно разбирать его и копаться в вызовах. Давно не встречал конкурс, чтобы в минимальном коде было столько общих тем по работе с токенами!
В общем, если вы хотите начать принимать участие в конкурсах, то это станет прекрасным упражнением!
#audit
👍9🔥3
RSA алгоритмы. Часть 2
Алгоритм RSA
Если мы хотим существенно превзойти ECDSA, нам нужно найти другой криптографический алгоритм, позволяющий доказать принадлежность к членству. ECDSA - это фактически новая, более "клевая" версия оригинального алгоритма цифровой подписи RSA. ECDSA опирается на то, что дискретные логарифмы над эллиптическими кривыми являются жесткими (отсюда и название - алгоритм цифровой подписи на эллиптических кривых). RSA (названный по имени его авторов - Ривеста, Шамира и Адлемана) основан на том, что большие целые числа трудно считать. По возрасту RSA был опубликован в 1970-х годах, а ECDSA стал общепринятым в начале 2000-х.
Мы не будем супер подробно разбирать RSA, но некоторые предварительные условия необходимы. Подписывающий выбирает два больших простых числа p и q и перемножает их вместе, чтобы получить n. Этот n - первая часть открытого ключа. Во-вторых, подписывающий выбирает небольшое простое число e (для нашего случая можно зафиксировать 3) и публикует пару (n, e) в качестве открытого ключа. За кулисами подписывающий вычисляет
Число d является закрытым ключом. Если бы кто-то мог разложить n на p и q, то вычисление d было бы простым делом. Но известно, что целочисленная факторизация сложна. Чтобы подписать сообщение, подписывающий хэширует сообщение m, получая h, и возводит h в степень d. То есть,
Подписант публикует (m, s) как сообщение и подпись. Верификатор хэширует m и возводит его в степень e mod n. Помните, что e и n - это открытый ключ. Если и только если
то подпись действительна для открытого ключа (n, e). Обратите внимание, что если n очень велико, то вероятность того, что s == s ^ e % n по случайному стечению обстоятельств исчезающе мала. Если равенство подтверждается, то мы знаем, что подпись действительна для открытого ключа. Чтобы сделать это в Ethereum, мы просто подпишем адрес как
и смарт-контракт будет проверять
Понимаю эти вычисления для нашего канала не свойственны, но в них можно разобраться, только если сами запишите все на бумаге. У меня, при чтении статьи, вообще "мозг вылетел", так как я с математикой не в ладах, поэтому переписать все на листик бумаги будет куда эффективнее.
На следующей неделе поговорим уже с меньшим количеством математики в постах.
#rsa
Алгоритм RSA
Если мы хотим существенно превзойти ECDSA, нам нужно найти другой криптографический алгоритм, позволяющий доказать принадлежность к членству. ECDSA - это фактически новая, более "клевая" версия оригинального алгоритма цифровой подписи RSA. ECDSA опирается на то, что дискретные логарифмы над эллиптическими кривыми являются жесткими (отсюда и название - алгоритм цифровой подписи на эллиптических кривых). RSA (названный по имени его авторов - Ривеста, Шамира и Адлемана) основан на том, что большие целые числа трудно считать. По возрасту RSA был опубликован в 1970-х годах, а ECDSA стал общепринятым в начале 2000-х.
Мы не будем супер подробно разбирать RSA, но некоторые предварительные условия необходимы. Подписывающий выбирает два больших простых числа p и q и перемножает их вместе, чтобы получить n. Этот n - первая часть открытого ключа. Во-вторых, подписывающий выбирает небольшое простое число e (для нашего случая можно зафиксировать 3) и публикует пару (n, e) в качестве открытого ключа. За кулисами подписывающий вычисляет
t = (p - 1) * (q - 1)
d = t^(-1) % n
Число d является закрытым ключом. Если бы кто-то мог разложить n на p и q, то вычисление d было бы простым делом. Но известно, что целочисленная факторизация сложна. Чтобы подписать сообщение, подписывающий хэширует сообщение m, получая h, и возводит h в степень d. То есть,
s = h(m) ^ d % n
Подписант публикует (m, s) как сообщение и подпись. Верификатор хэширует m и возводит его в степень e mod n. Помните, что e и n - это открытый ключ. Если и только если
s == s ^ e % n
то подпись действительна для открытого ключа (n, e). Обратите внимание, что если n очень велико, то вероятность того, что s == s ^ e % n по случайному стечению обстоятельств исчезающе мала. Если равенство подтверждается, то мы знаем, что подпись действительна для открытого ключа. Чтобы сделать это в Ethereum, мы просто подпишем адрес как
s = buyerAddress ^ d % n
и смарт-контракт будет проверять
msg.sender == s ^ e % n
Понимаю эти вычисления для нашего канала не свойственны, но в них можно разобраться, только если сами запишите все на бумаге. У меня, при чтении статьи, вообще "мозг вылетел", так как я с математикой не в ладах, поэтому переписать все на листик бумаги будет куда эффективнее.
На следующей неделе поговорим уже с меньшим количеством математики в постах.
#rsa
👍6🤯1
RSA алгоритмы. Часть 3
На этой неделе постараюсь уже закончить с RSA подписями, так как со следующей планирую уйти в долгий и долгожданный отпуск, о чем писал уже ранее. А пока что, продолжаем!
Использование только 256 бит небезопасно
Для прояснения ситуации: количество «бит» относится к размеру открытого ключа. Поэтому, когда мы говорим «RSA 2048», это означает, что число n, модуль, имеет 2048 бит. Сравнивая размеры ключей, важно помнить, что каждый дополнительный бит удваивает размер числа. Таким образом, 700 бит экспоненциально более безопасны, чем 350 бит, но не в два раза.
Самый большой ключ, который удалось взломать (разложить) на данный момент, состоял из 829 бит, и для этого потребовался современный суперкомпьютер. Команда использовала примерно 2700 процессорных ячеек в год, используя процессор Intel Xeon Gold 6130 с частотой 2,1 ГГц. Стоимость самого дешевого 16-ядерного процессора на AWS составляет 0,40 цента в час, поэтому стоимость взлома этого ключа составляет порядка 9,4 миллиона долларов. Даже при условии щедрых скидок от облачного провайдера стоимость будет исчисляться миллионами.
Модульная арифметика с более чем 256 битами в Solidity
Ethereum поддерживает только 32-байтовые типы данных, поэтому по умолчанию мы не можем выполнить:
К счастью, блокчейн ethereum добавил в EIP-198 прекомпилированный контракт специально для поддержки модульной арифметики.
Для его использования необходимо загрузить в память базу, экспоненту и модуль в кодированном формате abi. Затем вызывается контракт, находящийся по адресу 0x05. Хранение открытого ключа становится некоторой проблемой, если вы используете безопасное количество бит. Если размер ключа составляет 1024 бита, то для хранения потребуется 4 слота. Чтобы посчитать открытый ключ из хранилища, потребуется четыре операции SLOAD, что в общей сложности составит 8 400 газа.
Это само по себе уже менее эффективно, чем решение ECDSA, приведенное выше. Если мы используем неизменяемые переменные, эти затраты в значительной степени устраняются, но это создает слабое место, если мы не можем задним числом удалить кого-то из предварительной продажи аирдропа.
В традиционных ECDSA или деревьях Меркла мы бы просто заменили адрес подписи или корень Меркла. Это невозможно, если мы используем неизменяемую переменную. Однако ключевой идеей является хранение открытого ключа в байткоде, а не в памяти. Чтение байткода внешнего контракта (EXTCODECOPY) стоит 2 600 газа, что гораздо меньше, чем 8 400 газа при чтении каждой части открытого ключа в четырех экземплярах. Чтобы аннулировать открытый ключ, мы могли бы просто создать новый контракт и обновить переменную хранения, чтобы она указывала на новый адрес. Но это добавляет еще 2100 газа. И оказывается, что можно хранить адрес внешнего контракта (в байткоде которого хранится открытый ключ) в неизменяемой переменной, но при этом сделать открытый ключ недействительным, изменив байткод внешнего смарт-контракта.
Сложно, но интересно! Дальше больше!
#rsa
На этой неделе постараюсь уже закончить с RSA подписями, так как со следующей планирую уйти в долгий и долгожданный отпуск, о чем писал уже ранее. А пока что, продолжаем!
Использование только 256 бит небезопасно
Для прояснения ситуации: количество «бит» относится к размеру открытого ключа. Поэтому, когда мы говорим «RSA 2048», это означает, что число n, модуль, имеет 2048 бит. Сравнивая размеры ключей, важно помнить, что каждый дополнительный бит удваивает размер числа. Таким образом, 700 бит экспоненциально более безопасны, чем 350 бит, но не в два раза.
Самый большой ключ, который удалось взломать (разложить) на данный момент, состоял из 829 бит, и для этого потребовался современный суперкомпьютер. Команда использовала примерно 2700 процессорных ячеек в год, используя процессор Intel Xeon Gold 6130 с частотой 2,1 ГГц. Стоимость самого дешевого 16-ядерного процессора на AWS составляет 0,40 цента в час, поэтому стоимость взлома этого ключа составляет порядка 9,4 миллиона долларов. Даже при условии щедрых скидок от облачного провайдера стоимость будет исчисляться миллионами.
Модульная арифметика с более чем 256 битами в Solidity
Ethereum поддерживает только 32-байтовые типы данных, поэтому по умолчанию мы не можем выполнить:
s ^ e % n
К счастью, блокчейн ethereum добавил в EIP-198 прекомпилированный контракт специально для поддержки модульной арифметики.
Для его использования необходимо загрузить в память базу, экспоненту и модуль в кодированном формате abi. Затем вызывается контракт, находящийся по адресу 0x05. Хранение открытого ключа становится некоторой проблемой, если вы используете безопасное количество бит. Если размер ключа составляет 1024 бита, то для хранения потребуется 4 слота. Чтобы посчитать открытый ключ из хранилища, потребуется четыре операции SLOAD, что в общей сложности составит 8 400 газа.
Это само по себе уже менее эффективно, чем решение ECDSA, приведенное выше. Если мы используем неизменяемые переменные, эти затраты в значительной степени устраняются, но это создает слабое место, если мы не можем задним числом удалить кого-то из предварительной продажи аирдропа.
В традиционных ECDSA или деревьях Меркла мы бы просто заменили адрес подписи или корень Меркла. Это невозможно, если мы используем неизменяемую переменную. Однако ключевой идеей является хранение открытого ключа в байткоде, а не в памяти. Чтение байткода внешнего контракта (EXTCODECOPY) стоит 2 600 газа, что гораздо меньше, чем 8 400 газа при чтении каждой части открытого ключа в четырех экземплярах. Чтобы аннулировать открытый ключ, мы могли бы просто создать новый контракт и обновить переменную хранения, чтобы она указывала на новый адрес. Но это добавляет еще 2100 газа. И оказывается, что можно хранить адрес внешнего контракта (в байткоде которого хранится открытый ключ) в неизменяемой переменной, но при этом сделать открытый ключ недействительным, изменив байткод внешнего смарт-контракта.
Сложно, но интересно! Дальше больше!
#rsa
1❤2
RSA алгоритмы. Часть 4
Аннулирование открытого ключа с помощью шаблона метаморфного контракта
Смарт контракт создается путем загрузки байткода в память и возврата runtime кода. Когда смарт контракт создается с помощью команды create2, адрес контракта можно предсказать заранее. Адрес вычисляется из комбинации соли, деплоера и байткода инициализации. Если контракт самоуничтожится, то можно развернуть новый контракт по тому же адресу.
Обратите внимание, что адрес зависит от кода инициализации, а не от развертываемого кода. Можно развернуть разные байткоды, если код инициализации использует другой runtime код. Таким образом, мы можем иметь смарт контракт, первые k байт которого предназначены для самоуничтожения при определенном условии, а остальные байты - это открытый ключ RSA.
Поскольку адрес определен заранее, мы можем хранить адрес этого метаморфического контракта в неизменяемой переменной. Когда нам понадобится открытый ключ, мы можем выполнить EXTCODECOPY с этого адреса. Чтобы заменить открытый ключ, мы дадим контракту команду на самоуничтожение, а затем развернем новый контракт по этому адресу.
Экономим еще 100 единиц газа с помощью access lists
В EIP2930 добавлен новый тип транзакций, который позволяет пользователю заранее указать, к каким адресам и слотам хранения будет осуществляться доступ. Это позволяет узлам предварительно извлекать эти значения из хранилища, тем самым ускоряя время выполнения. Использование транзакции с access lists при вызове внешнего контракта позволяет сэкономить 100 газа. Обратите внимание, что эта экономия не распространяется на случаи, когда смарт контракт обращается к собственной переменной хранилища. Поскольку этот дизайн RSA presale airdrop полагается на внешний контракт для хранения открытого ключа, то использование списка доступа вполне уместно.
Бенчмарки: Затраты на газ в зависимости от размера ключа
Большая часть затрат на газ возникает из-за очень больших данных вызова в результате использования больших подписей. Если размер ключа установлен на 1024 бита, то данные вызова составят 128 байт. Каждый байт стоит 16 газа, так что общая стоимость газа для таких больших данных составляет 2 048 газа. По сравнению с большинством других сценариев использования, наш использует значительный объем памяти, и Ethereum взимает за это плату.
Почему это экономит газ по сравнению с ECDSA?
Из бенчмарков ясно, что чем больше ключ (и, следовательно, подпись), тем больше затраты на газ. Наш дизайн использует тот факт, что прекомпиляция назначает низкую цену за увеличение числа до низкой мощности. Стоимость выполнения прекомпилированного контракта в этих условиях при 0x05 составляет всего несколько сотен газа по сравнению с тысячами для выполнения прекомпиляции для ECDSA.
Выбор размера ключа
Хотя ключ с 829 битами и был взломан, для этого потребовался современный суперкомпьютер. Для таких задач, как выпуск в эфир токенов меньшей стоимости или предварительная продажа NFT, у злоумышленника нет стимула тратить от шестизначной суммы до миллиона долларов на взлом открытого ключа и получение NFT в ходе аирдропа.
Контрольные показатели размера ключа
RSA-896 (газ: 26 850)
RSA-960 (газ: 26 925)
RSA-1024 (газ: 27 033)
RSA-2048 (газ: 29 271)
#rsa
Аннулирование открытого ключа с помощью шаблона метаморфного контракта
Смарт контракт создается путем загрузки байткода в память и возврата runtime кода. Когда смарт контракт создается с помощью команды create2, адрес контракта можно предсказать заранее. Адрес вычисляется из комбинации соли, деплоера и байткода инициализации. Если контракт самоуничтожится, то можно развернуть новый контракт по тому же адресу.
Обратите внимание, что адрес зависит от кода инициализации, а не от развертываемого кода. Можно развернуть разные байткоды, если код инициализации использует другой runtime код. Таким образом, мы можем иметь смарт контракт, первые k байт которого предназначены для самоуничтожения при определенном условии, а остальные байты - это открытый ключ RSA.
Поскольку адрес определен заранее, мы можем хранить адрес этого метаморфического контракта в неизменяемой переменной. Когда нам понадобится открытый ключ, мы можем выполнить EXTCODECOPY с этого адреса. Чтобы заменить открытый ключ, мы дадим контракту команду на самоуничтожение, а затем развернем новый контракт по этому адресу.
Экономим еще 100 единиц газа с помощью access lists
В EIP2930 добавлен новый тип транзакций, который позволяет пользователю заранее указать, к каким адресам и слотам хранения будет осуществляться доступ. Это позволяет узлам предварительно извлекать эти значения из хранилища, тем самым ускоряя время выполнения. Использование транзакции с access lists при вызове внешнего контракта позволяет сэкономить 100 газа. Обратите внимание, что эта экономия не распространяется на случаи, когда смарт контракт обращается к собственной переменной хранилища. Поскольку этот дизайн RSA presale airdrop полагается на внешний контракт для хранения открытого ключа, то использование списка доступа вполне уместно.
Бенчмарки: Затраты на газ в зависимости от размера ключа
Большая часть затрат на газ возникает из-за очень больших данных вызова в результате использования больших подписей. Если размер ключа установлен на 1024 бита, то данные вызова составят 128 байт. Каждый байт стоит 16 газа, так что общая стоимость газа для таких больших данных составляет 2 048 газа. По сравнению с большинством других сценариев использования, наш использует значительный объем памяти, и Ethereum взимает за это плату.
Почему это экономит газ по сравнению с ECDSA?
Из бенчмарков ясно, что чем больше ключ (и, следовательно, подпись), тем больше затраты на газ. Наш дизайн использует тот факт, что прекомпиляция назначает низкую цену за увеличение числа до низкой мощности. Стоимость выполнения прекомпилированного контракта в этих условиях при 0x05 составляет всего несколько сотен газа по сравнению с тысячами для выполнения прекомпиляции для ECDSA.
Выбор размера ключа
Хотя ключ с 829 битами и был взломан, для этого потребовался современный суперкомпьютер. Для таких задач, как выпуск в эфир токенов меньшей стоимости или предварительная продажа NFT, у злоумышленника нет стимула тратить от шестизначной суммы до миллиона долларов на взлом открытого ключа и получение NFT в ходе аирдропа.
Контрольные показатели размера ключа
RSA-896 (газ: 26 850)
RSA-960 (газ: 26 925)
RSA-1024 (газ: 27 033)
RSA-2048 (газ: 29 271)
#rsa
2👍2🤔1
Про подготовку к аудиту
Проведение максимально эффективного аудита ложится на плечи не только самого аудитора, но и команды, которая должна сделать все, чтобы дать аудитору максимум полезной информации. Я уже не раз писал об этом, и хочу поднять эту тему еще раз в ключе одного из конкурсов, который проходит в данную минуту.
Пару дней назад начался конкурс для протокола SecondSwap. Это единственный конкурс на моей памяти, который переносился 4 раза! Изначально он должен был запуститься 24 ноября, потом его перенесли на 29, потом на 5 декабря, потом на 9!
Мне были очень интересны причины этого. И после старта они стали понятны. Подготовка к конкурсу просто ужасная. Пошли по порядку:
1. Отсутствие документации. Кроме как описания протокола на два абзаца и быстро сделанной схемы контрактов больше ничего нет. По ссылке на сайте проекта находится простой лендинг, без дополнительных ссылок на документацию или хотя бы на whitepaper протокола.
Да, аудитору, в целом, достаточно кода для хорошей проверки. При этом с подробной документацией он может сравнить "задумку" разработчиков с фактической реализацией, найти несоответствия или подсказать лучшие паттерны. Довольно часто в отчетах я встречал High/Med баги с ссылкой на формулировки в документации протокола.
2. Протокол заказывал аудит в другой компании, но к его началу аудиторам не показали отчет. Многие вышли из конкурса, так как по правилам все находки, даже acknowledged, уже не валидны для данного конкурса. Т.е. аудитор мог подать репорт, не зная, что в отчете уже описан этот баг и его бы не засчитали. Другими словами, это просто потраченное время для аудитора с нулем пользы для протокола.
И только вчера вечером администраторы платформы написали, что отчет вообще не будет показан аудиторам, но схожие баги все таки будут засчитаны. Но это полная хрень, как для аудиторов, так и для протокола.
3. Много рабочих комментариев от разработчиков по проблемам из аудиторского отчета, который не будет показан. Т.е. есть функция, в которой описан потенциальный баг: в одном случае он исправлен, в другом может быть нет, так как acknowledged. Это очень сильно сбивает с процесса.
Комментарии к коду при аудите должны быть чистыми и выверенными, которые помогут аудитору понять смысл function flow. Именно поэтому нужно фиксировать отдельный репо для аудита, а рабочие заметки держать у себя.
4. Связь с командой. В первые дни команда вообще не появлялась в чате. Все вопросы аудиторов игнорировались. И только со вчерашнего вечера пошли первые отчеты. Это тоже в корне не правильный подход.
По идее, команда должна выделять одного-двух человек, которые будут ответственны за коммуникацию и ответы на вопросы. Люди читают "жопой", и многим проще задать вопрос в чате, даже самый банальный, чем пытаться понять документацию.
Протоколу нужно хорошо подготовиться к аудиту: соло, от компании или конкурсу. Это напрямую влияет на ваши расходы сейчас и в будущем, и на безопасность протокола в целом!
Вот есть отличный гайд о подготовке протокола к аудиту:
https://auditprofile.xyz/plan.php
Если хотите нанять аудитора, то убедитесь, что соответствуете требованиям.
#audit
Проведение максимально эффективного аудита ложится на плечи не только самого аудитора, но и команды, которая должна сделать все, чтобы дать аудитору максимум полезной информации. Я уже не раз писал об этом, и хочу поднять эту тему еще раз в ключе одного из конкурсов, который проходит в данную минуту.
Пару дней назад начался конкурс для протокола SecondSwap. Это единственный конкурс на моей памяти, который переносился 4 раза! Изначально он должен был запуститься 24 ноября, потом его перенесли на 29, потом на 5 декабря, потом на 9!
Мне были очень интересны причины этого. И после старта они стали понятны. Подготовка к конкурсу просто ужасная. Пошли по порядку:
1. Отсутствие документации. Кроме как описания протокола на два абзаца и быстро сделанной схемы контрактов больше ничего нет. По ссылке на сайте проекта находится простой лендинг, без дополнительных ссылок на документацию или хотя бы на whitepaper протокола.
Да, аудитору, в целом, достаточно кода для хорошей проверки. При этом с подробной документацией он может сравнить "задумку" разработчиков с фактической реализацией, найти несоответствия или подсказать лучшие паттерны. Довольно часто в отчетах я встречал High/Med баги с ссылкой на формулировки в документации протокола.
2. Протокол заказывал аудит в другой компании, но к его началу аудиторам не показали отчет. Многие вышли из конкурса, так как по правилам все находки, даже acknowledged, уже не валидны для данного конкурса. Т.е. аудитор мог подать репорт, не зная, что в отчете уже описан этот баг и его бы не засчитали. Другими словами, это просто потраченное время для аудитора с нулем пользы для протокола.
И только вчера вечером администраторы платформы написали, что отчет вообще не будет показан аудиторам, но схожие баги все таки будут засчитаны. Но это полная хрень, как для аудиторов, так и для протокола.
3. Много рабочих комментариев от разработчиков по проблемам из аудиторского отчета, который не будет показан. Т.е. есть функция, в которой описан потенциальный баг: в одном случае он исправлен, в другом может быть нет, так как acknowledged. Это очень сильно сбивает с процесса.
Комментарии к коду при аудите должны быть чистыми и выверенными, которые помогут аудитору понять смысл function flow. Именно поэтому нужно фиксировать отдельный репо для аудита, а рабочие заметки держать у себя.
4. Связь с командой. В первые дни команда вообще не появлялась в чате. Все вопросы аудиторов игнорировались. И только со вчерашнего вечера пошли первые отчеты. Это тоже в корне не правильный подход.
По идее, команда должна выделять одного-двух человек, которые будут ответственны за коммуникацию и ответы на вопросы. Люди читают "жопой", и многим проще задать вопрос в чате, даже самый банальный, чем пытаться понять документацию.
Протоколу нужно хорошо подготовиться к аудиту: соло, от компании или конкурсу. Это напрямую влияет на ваши расходы сейчас и в будущем, и на безопасность протокола в целом!
Вот есть отличный гайд о подготовке протокола к аудиту:
https://auditprofile.xyz/plan.php
Если хотите нанять аудитора, то убедитесь, что соответствуете требованиям.
#audit
👍3
Последний пост этого года
Уже около трех лет я в теме web3, solidity, сетей, аудита и хочу сказать, что до сих пор не могу назвать себя не то, что сеньором, а даже твердым мидлом. Каждый раз, когда я читаю статьи от RareSkills или ветки обсуждений каких-то нишевых особенностей сети или языка от зарубежных коллег, я всегда такой: "Вау! Я тоже хочу знать это, на том же уровне!". Это и дает мне заряд мотивации вести канал, делиться интересными постами, делать переводы и много чего еще.
Многие спрашивали, а сколько нужно времени, чтобы научиться всему этому, и я до сих пор не знаю ответа. Научиться создавать свой токен с нуля можно за час, писать смарт контракт - за неделю, осмысленные проекты - за месяц, стать про - бесконечно... В обучение web3 нет временных рамок и ограничений, если встаете на этот путь будьте готовы учиться постоянно.
На следующий год я для себя выделил три ключевых направления для собственного обучения:
1. Аудит и безопасность. Эта тема меня действительно зажигает! Мне нравится читать отчеты, порой участвовать в конкурсах и помогать делать протоколы более безопасными. Я хочу освоить скилл создания видео, где в формате коротких роликов показывал бы баги из репортов и моменты, на которые стоит обращать внимание при разработке смарт контрактов. Это поможет как развитию канала, так и начинающим web3 разработчикам совершать меньше ошибок.
2. Разбор DeFi протоколов. При том, что я понимаю и разбираюсь в общих чертах финансовых протоколов, например, могу рассказать, чем отличаются версии Balancer v1 и v2, у меня все равно пробелы в знаниях о том, как работает все на уровне кода, и, кроме того, в чем особенности экономической модели. В общем, буду подтягивать эту тему.
3. Видео... Долбанный видео формат, который мне никак не удается совместить с демонстрацией кода в вертикальном формате. У меня давно было желание записывать видео по темам Solidity, безопасность и какие-нибудь разборы. Получилось провести даже два стрима (большое спасибо за вашу поддержку еще раз!). Но этот формат все никак не дается мне: то код маленький, то не знаю, как нарисовать схему на экране, то нужно много переключений между вкладками... Поэтому буду учиться этому весь следующий год.
Также весной, по мере желающих, будет перезапуск нашего курса "Начинающий разработчик смарт контрактов". Это уже третий поток учеников! Планирую добавить туда больше видео материала и примеров кода.
Размышляю также провести небольшой практический интенсив по Foundry. Открытие уроки уже выложены на канале, поэтому на интенсиве будет больше практической части: как писать unit / fuzz тесты, как делать форк сетей и интеграции с другими протоколами, как оптимизировать сами тесты и setup функцию, чтобы и вам, и другим разработчикам было удобнее работать с ними.
Это такие - глобальные - задачи на следующий год. А по мелочи, все также будем разбираться в тонкостях Solidity и сетей, делать разборы всяких интересных штук и обучаться дальше!
Спасибо всем, кто был со мной весь этот год! Спасибо всем, кто подписался на канал и комментировал посты! Спасибо всем, кто делился своими находками и материалами!
Встретимся с вами уже в Новом году! А я иду в долгожданный длинный отпуск!
#offtop
Уже около трех лет я в теме web3, solidity, сетей, аудита и хочу сказать, что до сих пор не могу назвать себя не то, что сеньором, а даже твердым мидлом. Каждый раз, когда я читаю статьи от RareSkills или ветки обсуждений каких-то нишевых особенностей сети или языка от зарубежных коллег, я всегда такой: "Вау! Я тоже хочу знать это, на том же уровне!". Это и дает мне заряд мотивации вести канал, делиться интересными постами, делать переводы и много чего еще.
Многие спрашивали, а сколько нужно времени, чтобы научиться всему этому, и я до сих пор не знаю ответа. Научиться создавать свой токен с нуля можно за час, писать смарт контракт - за неделю, осмысленные проекты - за месяц, стать про - бесконечно... В обучение web3 нет временных рамок и ограничений, если встаете на этот путь будьте готовы учиться постоянно.
На следующий год я для себя выделил три ключевых направления для собственного обучения:
1. Аудит и безопасность. Эта тема меня действительно зажигает! Мне нравится читать отчеты, порой участвовать в конкурсах и помогать делать протоколы более безопасными. Я хочу освоить скилл создания видео, где в формате коротких роликов показывал бы баги из репортов и моменты, на которые стоит обращать внимание при разработке смарт контрактов. Это поможет как развитию канала, так и начинающим web3 разработчикам совершать меньше ошибок.
2. Разбор DeFi протоколов. При том, что я понимаю и разбираюсь в общих чертах финансовых протоколов, например, могу рассказать, чем отличаются версии Balancer v1 и v2, у меня все равно пробелы в знаниях о том, как работает все на уровне кода, и, кроме того, в чем особенности экономической модели. В общем, буду подтягивать эту тему.
3. Видео... Долбанный видео формат, который мне никак не удается совместить с демонстрацией кода в вертикальном формате. У меня давно было желание записывать видео по темам Solidity, безопасность и какие-нибудь разборы. Получилось провести даже два стрима (большое спасибо за вашу поддержку еще раз!). Но этот формат все никак не дается мне: то код маленький, то не знаю, как нарисовать схему на экране, то нужно много переключений между вкладками... Поэтому буду учиться этому весь следующий год.
Также весной, по мере желающих, будет перезапуск нашего курса "Начинающий разработчик смарт контрактов". Это уже третий поток учеников! Планирую добавить туда больше видео материала и примеров кода.
Размышляю также провести небольшой практический интенсив по Foundry. Открытие уроки уже выложены на канале, поэтому на интенсиве будет больше практической части: как писать unit / fuzz тесты, как делать форк сетей и интеграции с другими протоколами, как оптимизировать сами тесты и setup функцию, чтобы и вам, и другим разработчикам было удобнее работать с ними.
Это такие - глобальные - задачи на следующий год. А по мелочи, все также будем разбираться в тонкостях Solidity и сетей, делать разборы всяких интересных штук и обучаться дальше!
Спасибо всем, кто был со мной весь этот год! Спасибо всем, кто подписался на канал и комментировал посты! Спасибо всем, кто делился своими находками и материалами!
Встретимся с вами уже в Новом году! А я иду в долгожданный длинный отпуск!
#offtop
1🔥17❤5👍5
С Новым Годом 🎄🎄🎄
Каждый год встречаюсь с дилеммой: а когда же все таки слать поздравления: в канун Нового года, типа как "с наступающим", или уже когда он наступил, т.е. 1 января? И тем не менее...
Дорогие друзья, поздравляю вас всех с Новым годом! Желаю чтобы каждый из вас исполнил свои заветные желания, перестал делать то, что совершенно не хочется, и развивался бы в той сфере, которая приносит удовольствие и мотивацию!
Наш путь в web3 это небольшая жизнь за гранью понимания большинства людей (пока что). Многие просто не понимают, чем мы занимаемся, другие называют криптовалюту скамом, третьи знают, но боятся нового. Мы те, кто меняет представление наших близких и друзей, и делает свой, пусть даже маленький, вклад в развитие сферы. Мы те, кто заряжает других!
Пусть каждый из вас не испугается объёма знаний, их сложности и продолжительности обучения! Пусть найдет то, что мотивирует двигаться дальше и зарабатывать большие деньги!
С Новым годом, друзья! Будьте счастливы в 2025 году!
🎄🎄🎄
Каждый год встречаюсь с дилеммой: а когда же все таки слать поздравления: в канун Нового года, типа как "с наступающим", или уже когда он наступил, т.е. 1 января? И тем не менее...
Дорогие друзья, поздравляю вас всех с Новым годом! Желаю чтобы каждый из вас исполнил свои заветные желания, перестал делать то, что совершенно не хочется, и развивался бы в той сфере, которая приносит удовольствие и мотивацию!
Наш путь в web3 это небольшая жизнь за гранью понимания большинства людей (пока что). Многие просто не понимают, чем мы занимаемся, другие называют криптовалюту скамом, третьи знают, но боятся нового. Мы те, кто меняет представление наших близких и друзей, и делает свой, пусть даже маленький, вклад в развитие сферы. Мы те, кто заряжает других!
Пусть каждый из вас не испугается объёма знаний, их сложности и продолжительности обучения! Пусть найдет то, что мотивирует двигаться дальше и зарабатывать большие деньги!
С Новым годом, друзья! Будьте счастливы в 2025 году!
🎄🎄🎄
3❤23🎉8🔥3
Выходим из отпуска и возвращаемся к работе
Фух, это был самый длинный мой отпуск за последние три года. Целый месяц практически без Solidity, аудитов, блога, сайта и всего другого связанного с web3. Голова немного проветрилась, мысли прояснились и появилась мотивация к новым действиям!
Как я и писал ранее, в этом году у меня будет сделан упор на аудиты, создание видео и погружение в DeFi протоколы. Кстати по поводу конкурсных аудитов: если бы меня попросили дать один лишь совет для начинающих в этой стезе, я бы сказал:
"Отслеживайте движения токенов в протоколе: перемещения с контракта на контракт и между пользователями, балансы токенов, какой токен, за что отвечает".
Только благодаря этому прокаченному скиллу вы сможете добиться значительных результатов к концу года и заработать кучу денег. Практически в каждом протоколе, который выходил на конкурсную площадку был High/Med баг связанный с этим советом.
В буквальном смысле, забейте на поиск остальных багов и учитесь отслеживать токены: рисуйте схемы, делайте записи (очень сильно помогает) и подписывайте код.
Помимо этого, в январе я хочу написать интенсив по Foundry: обновить некоторую информацию из открытого курса и сформировать большое количество практических заданий. Я хочу показать, что Foundry может намного больше, чем все привыкли думать, что он уже давно вышел за рамки простой программы для тестирования и стал полноценным инструментом разработчика смарт контрактов. Рассчитываю в феврале собрать первую группу учеников.
Также на DeFi канале мы закончим с разбором протокола Tornado Cash и его деревьями Меркла и начнем погружаться в тему: что такое perpetuals. Я вижу, что все больше протоколов так или иначе используют эти наработки и хочу сам разобраться в деталях.
Вместе с этим на канале будет выходить много постов про Solidity и разработку в целом. Мы поговорим про: обновляемые контракты, delegatecall, метадату и реорганизацию сетей. А на этой неделе, для легкого старта, поговорим про разные типы DAO систем.
В общем, год будет интересным! Приятного обучения!
#start
Фух, это был самый длинный мой отпуск за последние три года. Целый месяц практически без Solidity, аудитов, блога, сайта и всего другого связанного с web3. Голова немного проветрилась, мысли прояснились и появилась мотивация к новым действиям!
Как я и писал ранее, в этом году у меня будет сделан упор на аудиты, создание видео и погружение в DeFi протоколы. Кстати по поводу конкурсных аудитов: если бы меня попросили дать один лишь совет для начинающих в этой стезе, я бы сказал:
"Отслеживайте движения токенов в протоколе: перемещения с контракта на контракт и между пользователями, балансы токенов, какой токен, за что отвечает".
Только благодаря этому прокаченному скиллу вы сможете добиться значительных результатов к концу года и заработать кучу денег. Практически в каждом протоколе, который выходил на конкурсную площадку был High/Med баг связанный с этим советом.
В буквальном смысле, забейте на поиск остальных багов и учитесь отслеживать токены: рисуйте схемы, делайте записи (очень сильно помогает) и подписывайте код.
Помимо этого, в январе я хочу написать интенсив по Foundry: обновить некоторую информацию из открытого курса и сформировать большое количество практических заданий. Я хочу показать, что Foundry может намного больше, чем все привыкли думать, что он уже давно вышел за рамки простой программы для тестирования и стал полноценным инструментом разработчика смарт контрактов. Рассчитываю в феврале собрать первую группу учеников.
Также на DeFi канале мы закончим с разбором протокола Tornado Cash и его деревьями Меркла и начнем погружаться в тему: что такое perpetuals. Я вижу, что все больше протоколов так или иначе используют эти наработки и хочу сам разобраться в деталях.
Вместе с этим на канале будет выходить много постов про Solidity и разработку в целом. Мы поговорим про: обновляемые контракты, delegatecall, метадату и реорганизацию сетей. А на этой неделе, для легкого старта, поговорим про разные типы DAO систем.
В общем, год будет интересным! Приятного обучения!
#start
1🔥21👍3
Самые популярные типы DAO. Часть 1
На первой рабочей неделе мы будем немного раскачиваться, поэтому начнем с чего-то более легкого, чем технический разбор какой-нибудь особенности Solidity или смарт контрактов в целом. Поэтому предлагаю поговорить про системы DAO и чем они отличаются.
По мере того как мир блокчейнов и криптовалют продолжает развиваться, создание децентрализованных автономных организаций (DAO) становится популярным вариантом управления комьюнити. Если вы хотите лучше понять, какие виды DAO существуют сегодня, то давайте разбираться вместе.
Первая децентрализованная автономная организация
Прежде чем мы погрузимся в различные виды DAO, необходимо провести краткий урок истории.
Первая децентрализованная автономная организация, получившая название «The DAO», была построена на основе смарт-контрактов, использовала фреймворк с открытым исходным кодом и была ориентирована на венчурный капитализм.
К сожалению, из-за ошибки в смарт-контракте The DAO потеряла 3,6 миллиона ETH и не смогла восстановиться в финансовом плане. Тем не менее, The DAO проложила путь для многих других успешных DAO.
Лето DeFi в 2018 году принесло на блокчейн Ethereum флагманские проекты децентрализованных финансов, такие как Compound Finance (COMP), Uniswap (UNI) и Aave (AAVE), которые предлагали участникам сообщества привлекательные способы продемонстрировать свою приверженность децентрализации с помощью токенов управления DAO.
В конечном итоге успех DAO стал результатом инноваций в технологии блокчейна, таких как смарт-контракты, управление onchain (голосование), расширение прав и возможностей членов сообщества, переопределяющих порядок принятия решений, и новые организационно-правовые структуры без центрального органа власти.
По мере развития экосистемы web3, эволюции технологии блокчейн и экспериментов новаторов с новыми видами моделей, вероятно, мы продолжим наблюдать, как DAO расширяют границы возможного.
Можно выделить следующий типы DAO:
1. Protocol DAOs
2. Grant DAOs
3. Philanthropy DAOs
4. Social DAOs
5. Collector DAOs
6. Venture DAOs
7. Media DAOs
8. SubDAOs
Поскольку новые типы DAO разрабатываются регулярно, мы не сможем охватить все категории. Тем не менее, если вы хотите узнать, как создать свою собственную DAO, то давайте рассмотрим наиболее распространенные виды и их цели.
Protocol DAOs
Протокольный DAO - это тип DAO, который предназначен для управления децентрализованным протоколом, таким как приложение для займов/кредитования, децентрализованная биржа или другой тип dapp.
Примеры протокольных DAO
Три наиболее заметных примера протокольных DAO - MakerDAO, Uniswap и Yearn Finance.
MakerDAO
Одно из приложений DeFi в сети Ethereum, MakerDAO использует смарт-контракты, чтобы позволить пользователям кредитовать и занимать криптовалюты с индивидуальными ставками кредитования и суммами погашения.
MakerDAO использует токены управления MKR, чтобы держатели могли голосовать за изменения в протоколе Maker, включая сумму обеспечения для залоговых долговых позиций (CDP), ежегодные займы и прекращение работы в случае краха Ethereum.
Держатели MKR также выступают в качестве покупателей последней инстанции для займов DAI (алгоритмический стейблкоин, созданный MakerDAO). Если стоимость ETH в хранилищах Maker Vaults не покрывает количество DAI в обращении, MKR создается и продается на долговом аукционе, чтобы привлечь необходимое количество средств.
Uniswap
Компания Uniswap запустила токен управления UNI, предоставляющий сообществу право голоса в развитии и операциях Uniswap. Владельцы токенов UNI контролируют управление Uniswap, казначейские средства сообщества UNI, переключатель платы за протокол и многое другое.
Если держатели токенов хотят изменить Uniswap или ввести новые функции, для дальнейшего обсуждения необходимо подать предложение, набрав не менее 25 000 голосов «за» UNI.
Yearn Finance
На первой рабочей неделе мы будем немного раскачиваться, поэтому начнем с чего-то более легкого, чем технический разбор какой-нибудь особенности Solidity или смарт контрактов в целом. Поэтому предлагаю поговорить про системы DAO и чем они отличаются.
По мере того как мир блокчейнов и криптовалют продолжает развиваться, создание децентрализованных автономных организаций (DAO) становится популярным вариантом управления комьюнити. Если вы хотите лучше понять, какие виды DAO существуют сегодня, то давайте разбираться вместе.
Первая децентрализованная автономная организация
Прежде чем мы погрузимся в различные виды DAO, необходимо провести краткий урок истории.
Первая децентрализованная автономная организация, получившая название «The DAO», была построена на основе смарт-контрактов, использовала фреймворк с открытым исходным кодом и была ориентирована на венчурный капитализм.
К сожалению, из-за ошибки в смарт-контракте The DAO потеряла 3,6 миллиона ETH и не смогла восстановиться в финансовом плане. Тем не менее, The DAO проложила путь для многих других успешных DAO.
Лето DeFi в 2018 году принесло на блокчейн Ethereum флагманские проекты децентрализованных финансов, такие как Compound Finance (COMP), Uniswap (UNI) и Aave (AAVE), которые предлагали участникам сообщества привлекательные способы продемонстрировать свою приверженность децентрализации с помощью токенов управления DAO.
В конечном итоге успех DAO стал результатом инноваций в технологии блокчейна, таких как смарт-контракты, управление onchain (голосование), расширение прав и возможностей членов сообщества, переопределяющих порядок принятия решений, и новые организационно-правовые структуры без центрального органа власти.
По мере развития экосистемы web3, эволюции технологии блокчейн и экспериментов новаторов с новыми видами моделей, вероятно, мы продолжим наблюдать, как DAO расширяют границы возможного.
Можно выделить следующий типы DAO:
1. Protocol DAOs
2. Grant DAOs
3. Philanthropy DAOs
4. Social DAOs
5. Collector DAOs
6. Venture DAOs
7. Media DAOs
8. SubDAOs
Поскольку новые типы DAO разрабатываются регулярно, мы не сможем охватить все категории. Тем не менее, если вы хотите узнать, как создать свою собственную DAO, то давайте рассмотрим наиболее распространенные виды и их цели.
Protocol DAOs
Протокольный DAO - это тип DAO, который предназначен для управления децентрализованным протоколом, таким как приложение для займов/кредитования, децентрализованная биржа или другой тип dapp.
Примеры протокольных DAO
Три наиболее заметных примера протокольных DAO - MakerDAO, Uniswap и Yearn Finance.
MakerDAO
Одно из приложений DeFi в сети Ethereum, MakerDAO использует смарт-контракты, чтобы позволить пользователям кредитовать и занимать криптовалюты с индивидуальными ставками кредитования и суммами погашения.
MakerDAO использует токены управления MKR, чтобы держатели могли голосовать за изменения в протоколе Maker, включая сумму обеспечения для залоговых долговых позиций (CDP), ежегодные займы и прекращение работы в случае краха Ethereum.
Держатели MKR также выступают в качестве покупателей последней инстанции для займов DAI (алгоритмический стейблкоин, созданный MakerDAO). Если стоимость ETH в хранилищах Maker Vaults не покрывает количество DAI в обращении, MKR создается и продается на долговом аукционе, чтобы привлечь необходимое количество средств.
Uniswap
Компания Uniswap запустила токен управления UNI, предоставляющий сообществу право голоса в развитии и операциях Uniswap. Владельцы токенов UNI контролируют управление Uniswap, казначейские средства сообщества UNI, переключатель платы за протокол и многое другое.
Если держатели токенов хотят изменить Uniswap или ввести новые функции, для дальнейшего обсуждения необходимо подать предложение, набрав не менее 25 000 голосов «за» UNI.
Yearn Finance
👍3
Как и вышеупомянутые DAO с токенами управления, Yearn DAO делегирует финансирование DAO Vaults. Держатели YFI могут предоставлять средства DAO, одобренным для приема финансирования в экосистеме хранилищ DAO. Восполняя пробел в традиционной системе управления персоналом и начисления заработной платы, основатель YFI Андре Кронье создал Coordinape для автономного распределения средств и вознаграждения вкладчиков.
Далее поговорим про остальные виды.
#dao
Далее поговорим про остальные виды.
#dao
👍3
Самые популярные типы DAO. Часть 2
Продолжаем разбирать разные форматы DAO.
Грантовые DAO
Грантовые DAO предназначены для облегчения некоммерческих пожертвований, стратегического размещения капитальных активов в экосистеме web3 и являются либо благотворительным продолжением более крупного проекта, либо совершенно отдельной организацией в пространстве DeFi.
Примеры грантовых DAO
Aave Grants DAO - это программа под руководством сообщества, направленная на финансирование идей и проектов, способствующих развитию протокола Aave, с упором на поддержку более широкой сети разработчиков сообщества.
Гранты Aave выделяют определенную сумму финансирования в квартал. В число приемлемых заявок на гранты входят, но не ограничиваются ими: разработка Aave, интеграции, инструменты для разработчиков и многое другое.
Одним из примеров грантовой DAO, которая является отдельной организацией, является MetaCartel, которая предоставляет финансирование проектам и оказывает операционную поддержку dapp на ранних стадиях.
Задавшись целью ускорить создание Web3, MetaCartel выделяет гранты от 1 000 до 10 000 долларов на dApp, построенные на Ethereum, новые эксперименты с потребительскими кейсами, создание новых DAO, инициативы, ориентированные на сообщество, и многое другое.
Филантропические DAO
Филантропические DAO стремятся содействовать развитию социальной ответственности, организуясь вокруг общей цели для создания влияния в мире Web3.
Примеры филантропических DAO
Первая некоммерческая филантропическая DAO, Big Green DAO, связана с Big Green, национальной благотворительной организацией 501(c3), занимающейся вопросами продовольственной справедливости, которая учит людей выращивать продукты для повышения безопасности питания, улучшения психического здоровья и воздействия на климат. Big Green DAO присоединилась к благотворительной организации с десятилетней историей, чтобы реструктурировать процесс предоставления грантов и привести некоммерческую организацию в выгодное финансовое положение.
Проще говоря, популярность криптовалюты в сочетании с простотой международных денежных переводов позволяет филантропическим DAO создавать значимые результаты с рекордной скоростью.
Социальные DAO
Социальные DAO, или DAO креаторов, ориентированы на аспект самоорганизующихся сообществ, объединяя единомышленников, таких как строители, художники и творческие личности.
Хотя социальные DAO ориентированы на сообщество, обычно они имеют барьер для входа, например, владение определенным количеством токенов, владение NFT или личное приглашение.
Примеры DAO создателей
Developer DAO - это коллектив разработчиков web3, нацеленный на создание будущего web3. Чтобы присоединиться к Developer DAO, участники должны обладать NFT Genesis или быть одним из счастливчиков, приглашенных на частный сервер Discord.
Friends With Benefits - это DAO создателей web3, ориентированная на создание сообщества и развитие творчества. Вход в Friends With Benefits стоит 75 токенов FWB, и после приема участники получают полный доступ к общению со строителями, художниками, креативщиками и посещению эксклюзивных мероприятий.
Хотя DeFi, вероятно, была построена на принципах доступности, многие социальные DAO извлекают ценность из эксклюзивности, сотрудничества и межличностных сетевых эффектов.
И в понедельник узнаем о еще четырех видах популярных DAO.
#dao
Продолжаем разбирать разные форматы DAO.
Грантовые DAO
Грантовые DAO предназначены для облегчения некоммерческих пожертвований, стратегического размещения капитальных активов в экосистеме web3 и являются либо благотворительным продолжением более крупного проекта, либо совершенно отдельной организацией в пространстве DeFi.
Примеры грантовых DAO
Aave Grants DAO - это программа под руководством сообщества, направленная на финансирование идей и проектов, способствующих развитию протокола Aave, с упором на поддержку более широкой сети разработчиков сообщества.
Гранты Aave выделяют определенную сумму финансирования в квартал. В число приемлемых заявок на гранты входят, но не ограничиваются ими: разработка Aave, интеграции, инструменты для разработчиков и многое другое.
Одним из примеров грантовой DAO, которая является отдельной организацией, является MetaCartel, которая предоставляет финансирование проектам и оказывает операционную поддержку dapp на ранних стадиях.
Задавшись целью ускорить создание Web3, MetaCartel выделяет гранты от 1 000 до 10 000 долларов на dApp, построенные на Ethereum, новые эксперименты с потребительскими кейсами, создание новых DAO, инициативы, ориентированные на сообщество, и многое другое.
Филантропические DAO
Филантропические DAO стремятся содействовать развитию социальной ответственности, организуясь вокруг общей цели для создания влияния в мире Web3.
Примеры филантропических DAO
Первая некоммерческая филантропическая DAO, Big Green DAO, связана с Big Green, национальной благотворительной организацией 501(c3), занимающейся вопросами продовольственной справедливости, которая учит людей выращивать продукты для повышения безопасности питания, улучшения психического здоровья и воздействия на климат. Big Green DAO присоединилась к благотворительной организации с десятилетней историей, чтобы реструктурировать процесс предоставления грантов и привести некоммерческую организацию в выгодное финансовое положение.
Проще говоря, популярность криптовалюты в сочетании с простотой международных денежных переводов позволяет филантропическим DAO создавать значимые результаты с рекордной скоростью.
Социальные DAO
Социальные DAO, или DAO креаторов, ориентированы на аспект самоорганизующихся сообществ, объединяя единомышленников, таких как строители, художники и творческие личности.
Хотя социальные DAO ориентированы на сообщество, обычно они имеют барьер для входа, например, владение определенным количеством токенов, владение NFT или личное приглашение.
Примеры DAO создателей
Developer DAO - это коллектив разработчиков web3, нацеленный на создание будущего web3. Чтобы присоединиться к Developer DAO, участники должны обладать NFT Genesis или быть одним из счастливчиков, приглашенных на частный сервер Discord.
Friends With Benefits - это DAO создателей web3, ориентированная на создание сообщества и развитие творчества. Вход в Friends With Benefits стоит 75 токенов FWB, и после приема участники получают полный доступ к общению со строителями, художниками, креативщиками и посещению эксклюзивных мероприятий.
Хотя DeFi, вероятно, была построена на принципах доступности, многие социальные DAO извлекают ценность из эксклюзивности, сотрудничества и межличностных сетевых эффектов.
И в понедельник узнаем о еще четырех видах популярных DAO.
#dao
👍2🤔1
Самые популярные типы DAO. Часть 3
С легкого поста мы начинаем неделю и заканчиваем рассказ про DAO, остались последние 4 вида.
Коллекционные DAO
Основная цель коллекционных DAO - объединение средств участников, чтобы коллективное сообщество могло инвестировать казенные средства в предметы искусства и другие коллекционные предметы, где каждый участник владеет долей, соответствующей его личным инвестициям.
Примеры коллекционных DAO
Такие известные DAO, как FlamingoDAO, возникли после бума NFT и собирали невероятно дорогие NFT от таких цифровых художников, как Pak, Hackatao, XCopy, а также CryptoPunk #2890 NFT, который был куплен в 2021 году за $760 тысяч долларов США.
Другая группа коллекционеров сформировала ConstitutionDAO в попытке купить Конституцию Соединенных Штатов. Примечательно, что ConstitutionDAO за одну неделю собрала ETH на сумму 47 миллионов долларов, чтобы попытаться купить копию Конституции США первого издания на аукционе Sotheby's.
Хотя не каждое коллекционное DAO окупится, это новая возможность для инвесторов получить финансовую поддержку в дорогих NFT, не рискуя большими суммами личного капитала.
Инвестиционные и венчурные DAO
Венчурные DAO объединяют капитал для инвестирования в стартапы ранней стадии web3, протоколы, offchain инвестиции и получают доступ к портфелям, недоступным в традиционном финансировании.
Примеры венчурных DAO
Krause House DAO - это венчурная DAO, которая пытается купить профессиональную команду NBA, состоящую из инвесторов и фанатиков баскетбола. Члены Krause House DAO будут участвовать в принятии решений, влияющих на операционные процедуры команды Национальной баскетбольной ассоциации, включая, помимо прочего, общее управление, продажу билетов, мерчендайзинг и партнерские отношения.
Среди других известных венчурных DAO можно отметить MetaCartel Ventures (MCV), которая является коммерческой DAO, созданной сообществом MetaCartel для инвестирования в децентрализованные приложения (DApps) на ранних стадиях, и BessemerDAO, которая была запущена венчурной фирмой Bessemer Venture Partners из Сан-Франциско для обсуждения тенденций в криптоиндустрии и обмена ресурсами.
Медиа DAO
В отличие от подхода «сверху вниз», когда контент создается в соответствии с центральной повесткой дня или под влиянием рекламодателей, медийные DAO заново изобретают традиционные медиаплатформы, создавая контент под влиянием сообщества.
Подумайте о социальных сетях, но вместо корпоративных организаций, управляющих прибылью, отдельные люди в медиасети активно зарабатывают часть прибыли децентрализованной организации.
Примеры медиа DAO
BanklessDAO - это децентрализованное сообщество для координации и распространения безбанковских СМИ, культуры и образования. Его цель - способствовать внедрению действительно безбанковской денежной системы.
Decrypt - еще один пример медиа DAO, который позволяет пользователям голосовать за то, какой контент они хотят видеть.
Медиа DAO особенно эффективны для новых сообществ, которые хотят вознаградить своих пользователей по мере развития криптосообщества и культуры Web 3.0.
SubDAO
SubDAO - это новый вид DAO, который представляет собой подмножество членов DAO, организованных для управления конкретными функциями, такими как операции, партнерство, маркетинг, казначейство и гранты.
Протокол Balancer увидел возможность в растущем членстве DAO и предложил создать subDAO для управления принятием решений, связанных с DAO, и облегчения исполнения, не требуя, чтобы каждое предложение принималось всем DAO.
В результате единогласного голосования Balancer DAO успешно интегрировал subDAO в свою структуру и теперь может двигаться более эффективно как децентрализованная автономная организация.
Креативность сообщества - это действительно предел того, что можно создать в рамках DAO.
Возможно, один из этих DAO натолкнет вас на новую идею своего проекта и позволить помочь развитию web3!
#dao
С легкого поста мы начинаем неделю и заканчиваем рассказ про DAO, остались последние 4 вида.
Коллекционные DAO
Основная цель коллекционных DAO - объединение средств участников, чтобы коллективное сообщество могло инвестировать казенные средства в предметы искусства и другие коллекционные предметы, где каждый участник владеет долей, соответствующей его личным инвестициям.
Примеры коллекционных DAO
Такие известные DAO, как FlamingoDAO, возникли после бума NFT и собирали невероятно дорогие NFT от таких цифровых художников, как Pak, Hackatao, XCopy, а также CryptoPunk #2890 NFT, который был куплен в 2021 году за $760 тысяч долларов США.
Другая группа коллекционеров сформировала ConstitutionDAO в попытке купить Конституцию Соединенных Штатов. Примечательно, что ConstitutionDAO за одну неделю собрала ETH на сумму 47 миллионов долларов, чтобы попытаться купить копию Конституции США первого издания на аукционе Sotheby's.
Хотя не каждое коллекционное DAO окупится, это новая возможность для инвесторов получить финансовую поддержку в дорогих NFT, не рискуя большими суммами личного капитала.
Инвестиционные и венчурные DAO
Венчурные DAO объединяют капитал для инвестирования в стартапы ранней стадии web3, протоколы, offchain инвестиции и получают доступ к портфелям, недоступным в традиционном финансировании.
Примеры венчурных DAO
Krause House DAO - это венчурная DAO, которая пытается купить профессиональную команду NBA, состоящую из инвесторов и фанатиков баскетбола. Члены Krause House DAO будут участвовать в принятии решений, влияющих на операционные процедуры команды Национальной баскетбольной ассоциации, включая, помимо прочего, общее управление, продажу билетов, мерчендайзинг и партнерские отношения.
Среди других известных венчурных DAO можно отметить MetaCartel Ventures (MCV), которая является коммерческой DAO, созданной сообществом MetaCartel для инвестирования в децентрализованные приложения (DApps) на ранних стадиях, и BessemerDAO, которая была запущена венчурной фирмой Bessemer Venture Partners из Сан-Франциско для обсуждения тенденций в криптоиндустрии и обмена ресурсами.
Медиа DAO
В отличие от подхода «сверху вниз», когда контент создается в соответствии с центральной повесткой дня или под влиянием рекламодателей, медийные DAO заново изобретают традиционные медиаплатформы, создавая контент под влиянием сообщества.
Подумайте о социальных сетях, но вместо корпоративных организаций, управляющих прибылью, отдельные люди в медиасети активно зарабатывают часть прибыли децентрализованной организации.
Примеры медиа DAO
BanklessDAO - это децентрализованное сообщество для координации и распространения безбанковских СМИ, культуры и образования. Его цель - способствовать внедрению действительно безбанковской денежной системы.
Decrypt - еще один пример медиа DAO, который позволяет пользователям голосовать за то, какой контент они хотят видеть.
Медиа DAO особенно эффективны для новых сообществ, которые хотят вознаградить своих пользователей по мере развития криптосообщества и культуры Web 3.0.
SubDAO
SubDAO - это новый вид DAO, который представляет собой подмножество членов DAO, организованных для управления конкретными функциями, такими как операции, партнерство, маркетинг, казначейство и гранты.
Протокол Balancer увидел возможность в растущем членстве DAO и предложил создать subDAO для управления принятием решений, связанных с DAO, и облегчения исполнения, не требуя, чтобы каждое предложение принималось всем DAO.
В результате единогласного голосования Balancer DAO успешно интегрировал subDAO в свою структуру и теперь может двигаться более эффективно как децентрализованная автономная организация.
Креативность сообщества - это действительно предел того, что можно создать в рамках DAO.
Возможно, один из этих DAO натолкнет вас на новую идею своего проекта и позволить помочь развитию web3!
#dao
👍2❤1
Безопасная крипта
Мне снова требуется помощь сообщества.
Когда я начал работать с криптой, то стабильно начали появляться вопросы от окружающих о том, как использовать ее, как не попасться на скам, как завести кошелек и принимать платежи и т.д. За последний год, вместе с ростом биткойна и вниманием прессы к этой теме, вопросов стало еще больше. В конце концов, я решил написать гайд для новичков, в котором были бы даны базовые правила для работы с криптовалютой.
Дело осложняется тем, что я не хочу рекламировать биржи, не популярные кошельки и волатильные токены. Также не хочу делать описания, как торговать на бирже, смотреть прогнозы, ловить айрдропы и мемы. Никакой торговли!
Задача стоит в том, чтобы рассказать базу про блокчейн, кошельки и крипту. В частности только про стейблкоины USDT/USDC, так как именно их лучше всего принимать в оплату.
И тут у меня самого возникли трудности с описанием популярных скамов и тем, на что нужно обращать внимание при работе с криптой. И было бы здорово, если бы вы накидали идей по этой теме.
Например, я хочу рассказать, что при покупке криптовалюты на сетях нужно быть аккуратным так как:
1. Токены с такими же инициалами и названием легко создать в любой сети и обмануть пользователя;
2. Не на каждой сети может быть нужный токен;
3. Существуют обертки токенов (eBTC, WETH);
4. Нужно минимум два токена на кошельке (один дл оплаты комиссии и один требуемый);
5. Как проверить адрес токена;
Или также про владение кошельком:
1. Нельзя покупать уже готовый кошелек;
2. Нужно хранить секретную фразу от всех;
3. Нельзя заходить в чужие кошельки, если где-то встретили сид-фразу;
И все в этом роде про базовую безопасность работы с криптовалютой.
Если у вас есть еще какие-то варианты своих правил, возможных скамов или предостережений, буду признателен, если поделитесь в комментариях.
С гайдом я хочу показать людям, что работа с криптовалютой и блокчейном не "типичное мошенничество", а уже простая обыденность, и можно не переживать за сохранность своих средств, если следовать простым правилам.
#safecrypto
Мне снова требуется помощь сообщества.
Когда я начал работать с криптой, то стабильно начали появляться вопросы от окружающих о том, как использовать ее, как не попасться на скам, как завести кошелек и принимать платежи и т.д. За последний год, вместе с ростом биткойна и вниманием прессы к этой теме, вопросов стало еще больше. В конце концов, я решил написать гайд для новичков, в котором были бы даны базовые правила для работы с криптовалютой.
Дело осложняется тем, что я не хочу рекламировать биржи, не популярные кошельки и волатильные токены. Также не хочу делать описания, как торговать на бирже, смотреть прогнозы, ловить айрдропы и мемы. Никакой торговли!
Задача стоит в том, чтобы рассказать базу про блокчейн, кошельки и крипту. В частности только про стейблкоины USDT/USDC, так как именно их лучше всего принимать в оплату.
И тут у меня самого возникли трудности с описанием популярных скамов и тем, на что нужно обращать внимание при работе с криптой. И было бы здорово, если бы вы накидали идей по этой теме.
Например, я хочу рассказать, что при покупке криптовалюты на сетях нужно быть аккуратным так как:
1. Токены с такими же инициалами и названием легко создать в любой сети и обмануть пользователя;
2. Не на каждой сети может быть нужный токен;
3. Существуют обертки токенов (eBTC, WETH);
4. Нужно минимум два токена на кошельке (один дл оплаты комиссии и один требуемый);
5. Как проверить адрес токена;
Или также про владение кошельком:
1. Нельзя покупать уже готовый кошелек;
2. Нужно хранить секретную фразу от всех;
3. Нельзя заходить в чужие кошельки, если где-то встретили сид-фразу;
И все в этом роде про базовую безопасность работы с криптовалютой.
Если у вас есть еще какие-то варианты своих правил, возможных скамов или предостережений, буду признателен, если поделитесь в комментариях.
С гайдом я хочу показать людям, что работа с криптовалютой и блокчейном не "типичное мошенничество", а уже простая обыденность, и можно не переживать за сохранность своих средств, если следовать простым правилам.
#safecrypto
🔥4🤔2👍1
Обновляемые контракты (Transparent proxy). Часть 1
Смотрел я тут несколько аудитов и отчетов, где присутствовал прокси паттерн и подумал, что вполне можно на канале повторить некоторый материал. Новички смогут что-то новое для себя найти и более продвинутые участники повторить материал.
Transparent Upgradeable Proxy (далее TUP) - это паттерн для обновления прокси контрактов, исключающий возможность столкновения селекторов функций.
Хороший прокси контракт должен обладать как минимум двумя следующими характеристиками:
- слотом для хранения адреса контракта Логики;
- механизмом, позволяющим администратору изменять адрес Логики;
Стандарт ERC1967 устанавливает, где должен находиться слот памяти, содержащий адрес контракта Логики, так, чтобы вероятность коллизии при хранении была минимальной. Однако он не определяет, как обновить сам контракт.
Столкновение селекторов функций (Function Selector Clashing)
Объявление публичных функций внутри прокси для обновления адреса Логики влечет за собой возможность столкновения селекторов функций.
Вот простой пример:
Помните, что fallback всегда проверяется в последнюю очередь?
Перед вызовом fallback контракт прокси проверит, совпадает ли 4-байтовый селектор функции с changeImplementation (или любой другой публичной функцией в прокси).
И если в прокси объявлена публичная функция, могут возникнуть два вида столкновений селекторов функций:
1. Если контракт Логики реализует функцию с той же подписью, что и функция в прокси, то эта функция не будет вызвана, так как вызов пойдет в сам прокси.
2. Если в контракте Логики есть функция с тем же селектором функций, что и публичная функция в прокси, она также будет невызываемой по той же причине. Этот сценарий представляет собой столкновение селекторов функций. Вероятность того, что у двух разных функций будет одинаковый селектор, равна 1 к 4,29 миллиарда; селектор функции состоит из 4 байт, поэтому существует 4,29 миллиарда возможностей. Это небольшая вероятность, но не нулевая. Например, у clash550254402() тот же селектор функции, что и у proxyAdmin().
А далее мы поговорим, как TUP помогает решить эту проблему.
#proxy #transparent
Смотрел я тут несколько аудитов и отчетов, где присутствовал прокси паттерн и подумал, что вполне можно на канале повторить некоторый материал. Новички смогут что-то новое для себя найти и более продвинутые участники повторить материал.
Transparent Upgradeable Proxy (далее TUP) - это паттерн для обновления прокси контрактов, исключающий возможность столкновения селекторов функций.
Хороший прокси контракт должен обладать как минимум двумя следующими характеристиками:
- слотом для хранения адреса контракта Логики;
- механизмом, позволяющим администратору изменять адрес Логики;
Стандарт ERC1967 устанавливает, где должен находиться слот памяти, содержащий адрес контракта Логики, так, чтобы вероятность коллизии при хранении была минимальной. Однако он не определяет, как обновить сам контракт.
Столкновение селекторов функций (Function Selector Clashing)
Объявление публичных функций внутри прокси для обновления адреса Логики влечет за собой возможность столкновения селекторов функций.
Вот простой пример:
contract ProxyUnsafe {
function changeImplementation(
address newImplementation
) public {
// some code...
}
fallback(bytes calldata data) external payable (bytes memory) {
(bool ok, bytes memory data) = getImplementation().delegatecall(data);
require(ok, "delegatecall failed");
return data;
}
}
contract Implementation {
// an identical function is declared here -- they will clash
function changeImplementation(
address newImplementation
) public {
}
//...
}Помните, что fallback всегда проверяется в последнюю очередь?
Перед вызовом fallback контракт прокси проверит, совпадает ли 4-байтовый селектор функции с changeImplementation (или любой другой публичной функцией в прокси).
И если в прокси объявлена публичная функция, могут возникнуть два вида столкновений селекторов функций:
1. Если контракт Логики реализует функцию с той же подписью, что и функция в прокси, то эта функция не будет вызвана, так как вызов пойдет в сам прокси.
2. Если в контракте Логики есть функция с тем же селектором функций, что и публичная функция в прокси, она также будет невызываемой по той же причине. Этот сценарий представляет собой столкновение селекторов функций. Вероятность того, что у двух разных функций будет одинаковый селектор, равна 1 к 4,29 миллиарда; селектор функции состоит из 4 байт, поэтому существует 4,29 миллиарда возможностей. Это небольшая вероятность, но не нулевая. Например, у clash550254402() тот же селектор функции, что и у proxyAdmin().
А далее мы поговорим, как TUP помогает решить эту проблему.
#proxy #transparent
1👍4🔥3👏1
Обновляемые контракты (Transparent proxy). Часть 2
Transparent Upgradeable Proxy - это паттерн, полностью исключающий возможность столкновения селекторов функций.
В частности, TUP предписывает, что в прокси контракте не должно быть никаких публичных функций, кроме fallback.
Но если есть только функция fallback, как нам вызвать функцию для обновления прокси?
Ответ заключается в том, чтобы определить, является ли отправитель msg.sender администратором.
Из этого следует, что администратор не может напрямую использовать прокси, поскольку его вызовы всегда направляются в сторону if. Однако, используя немного другой механизм, который мы обсудим позже, администратор все же может делать вызовы прокси, а тот делегировать вызов в Логику.
Изменение неизменяемого администратора
В приведенном выше фрагменте кода администратор является неизменяемым. Это означает, что контракт технически не соответствует стандарту ERC-1967, который гласит, что администратор должен храниться в слоте хранения 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 или bytes32(uint256(keccak256('eip1967.proxy.admin')) - 1).
Для того, чтобы стать совместимым со стандартом, TUP должен хранить адрес администратора в этом слоте памяти, но не использовать его для других целей.
Наличие адреса в этом слоте будет сигнализировать другим программам, что контракт является прокси (одна из целей ERC-1967). Однако чтение из хранилища при каждом обращении к прокси добавляет к вызову еще 2100 газа. Поэтому желательно использовать неизменяемую переменную.
«Смена» администратора
Однако все же желательно иметь возможность обновлять адрес администратора - но изначально это кажется невозможным.
TUP позволяет изменять админский контракт прокси двумя способами. Во-первых, он назначает другой контракт, известный как ProxyAdmin, администратором прокси.
Во-вторых, владелец ProxyAdmin является «истинным» администратором. ProxyAdmin просто направляет вызовы от владельца к прокси. «Истинный» администратор вызывает ProxyAdmin, а ProxyAdmin вызывает Transparent Proxy. Изменив владельца ProxyAdmin, мы можем изменить, кто имеет возможность обновлять Transparent Proxy.
Далее поговорим об этом интересном контракте.
#proxy #transparent
Transparent Upgradeable Proxy - это паттерн, полностью исключающий возможность столкновения селекторов функций.
В частности, TUP предписывает, что в прокси контракте не должно быть никаких публичных функций, кроме fallback.
Но если есть только функция fallback, как нам вызвать функцию для обновления прокси?
Ответ заключается в том, чтобы определить, является ли отправитель msg.sender администратором.
contract Proxy is ERC1967 {
address immutable admin;
constructor(address admin_) {
admin = admin_
}
fallback() external payable {
if (msg.sender == admin) {
// upgrade logic
} else {
// delegatecall to implementation
}
}
}
Из этого следует, что администратор не может напрямую использовать прокси, поскольку его вызовы всегда направляются в сторону if. Однако, используя немного другой механизм, который мы обсудим позже, администратор все же может делать вызовы прокси, а тот делегировать вызов в Логику.
Изменение неизменяемого администратора
В приведенном выше фрагменте кода администратор является неизменяемым. Это означает, что контракт технически не соответствует стандарту ERC-1967, который гласит, что администратор должен храниться в слоте хранения 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 или bytes32(uint256(keccak256('eip1967.proxy.admin')) - 1).
Для того, чтобы стать совместимым со стандартом, TUP должен хранить адрес администратора в этом слоте памяти, но не использовать его для других целей.
Наличие адреса в этом слоте будет сигнализировать другим программам, что контракт является прокси (одна из целей ERC-1967). Однако чтение из хранилища при каждом обращении к прокси добавляет к вызову еще 2100 газа. Поэтому желательно использовать неизменяемую переменную.
«Смена» администратора
Однако все же желательно иметь возможность обновлять адрес администратора - но изначально это кажется невозможным.
TUP позволяет изменять админский контракт прокси двумя способами. Во-первых, он назначает другой контракт, известный как ProxyAdmin, администратором прокси.
Во-вторых, владелец ProxyAdmin является «истинным» администратором. ProxyAdmin просто направляет вызовы от владельца к прокси. «Истинный» администратор вызывает ProxyAdmin, а ProxyAdmin вызывает Transparent Proxy. Изменив владельца ProxyAdmin, мы можем изменить, кто имеет возможность обновлять Transparent Proxy.
Далее поговорим об этом интересном контракте.
#proxy #transparent
1👍4
Обновляемые контракты (Transparent proxy). Часть 3
AdminProxy
Ниже приведен код из OpenZeppelin AdminProxy. Обратите внимание, что есть только одна функция upgradeAndCall(), которая может вызывать upgradeToAndCall() только на прокси.
Существует распространенное заблуждение, что администратор Transparent proxy не может использовать контракт, потому что его вызовы переадресуются на upgrade. Однако владелец AdminProxy может использовать Proxy без проблем, как показано на диаграмме на скрине.
На самом деле, существует механизм, позволяющий администратору ProxyAdmin сделать произвольный вызов прокси, как следует из названия функции upgradeToAndCall().
Сделать прокси non-upgradeable?
Если владелец будет изменен на нулевой адрес или другой смарт-контракт, который не сможет правильно использовать функцию upgradeAndCall() (или изменить владельца), то Transparent proxy больше не будет обновляемым. Это может произойти, например, если владельцем AdminProxy будет установлен другой контракт AdminProxy.
TUP от OpenZeppelin реализует стандарт с помощью трех контрактов:
1. Proxy.sol
2. ERC1967Proxy.sol (наследует Proxy.sol)
3. TransparentUgradeableProxy.sol (наследует ERC1967Proxy.sol)
Базовым контрактом является Proxy.sol. Получив адрес реализации, он отправляет delegate call в Логику. Функция _implementation() не реализована в Proxy - она переопределена и реализована его дочерним ERC1967Proxy, что позволяет ему вернуть соответствующий слот хранения.
ERC1967Proxy.sol наследует от Proxy.sol. Он добавляет (и переопределяет) внутреннюю функцию _implementation(), которая возвращает адрес реализации, хранящийся в слоте, указанном ERC-1967. Однако Transparent proxy не будет использовать эту функцию - вместо этого он использует свою собственную неизменяемую переменную.
А о самом TransparentUpgradeableProxy.sol мы поговорим в следующий раз.
#proxy #transparent
AdminProxy
Ниже приведен код из OpenZeppelin AdminProxy. Обратите внимание, что есть только одна функция upgradeAndCall(), которая может вызывать upgradeToAndCall() только на прокси.
pragma solidity ^0.8.20;
import {ITransparentUpgradeableProxy} from "./TransparentUpgradeableProxy.sol";
import {Ownable} from "../../access/Ownable.sol";
contract ProxyAdmin is Ownable {
string public constant UPGRADE_INTERFACE_VERSION = "5.0.0";
constructor(address initialOwner) Ownable(initialOwner) {}
function upgradeAndCall(
ITransparentUpgradeableProxy proxy,
address implementation,
bytes memory data
) public payable virtual onlyOwner {
proxy.upgradeToAndCall{value: msg.value}(implementation, data);
}
}
Существует распространенное заблуждение, что администратор Transparent proxy не может использовать контракт, потому что его вызовы переадресуются на upgrade. Однако владелец AdminProxy может использовать Proxy без проблем, как показано на диаграмме на скрине.
На самом деле, существует механизм, позволяющий администратору ProxyAdmin сделать произвольный вызов прокси, как следует из названия функции upgradeToAndCall().
Сделать прокси non-upgradeable?
Если владелец будет изменен на нулевой адрес или другой смарт-контракт, который не сможет правильно использовать функцию upgradeAndCall() (или изменить владельца), то Transparent proxy больше не будет обновляемым. Это может произойти, например, если владельцем AdminProxy будет установлен другой контракт AdminProxy.
TUP от OpenZeppelin реализует стандарт с помощью трех контрактов:
1. Proxy.sol
2. ERC1967Proxy.sol (наследует Proxy.sol)
3. TransparentUgradeableProxy.sol (наследует ERC1967Proxy.sol)
Базовым контрактом является Proxy.sol. Получив адрес реализации, он отправляет delegate call в Логику. Функция _implementation() не реализована в Proxy - она переопределена и реализована его дочерним ERC1967Proxy, что позволяет ему вернуть соответствующий слот хранения.
ERC1967Proxy.sol наследует от Proxy.sol. Он добавляет (и переопределяет) внутреннюю функцию _implementation(), которая возвращает адрес реализации, хранящийся в слоте, указанном ERC-1967. Однако Transparent proxy не будет использовать эту функцию - вместо этого он использует свою собственную неизменяемую переменную.
А о самом TransparentUpgradeableProxy.sol мы поговорим в следующий раз.
#proxy #transparent
1👍5
Обновляемые контракты (Transparent proxy). Часть 4
TransparentUpgradeableProxy.sol наследует от ERC1967Proxy.sol. В конструкторе этого контракта разворачивается ProxyAdmin и устанавливается как адрес неизменяемого admin (первая переменная в контракте).
Рассмотрим случай, когда отправителем msg.sender является _proxyAdmin. В этом случае вызов направляется в _dispatchUpgradeToAndCall(), но _fallback() сначала проверяет, что предоставленный селектор функций является селектором функций для upgradeToAndCall.
«Селектор» здесь не является "настоящим" селектором, поскольку Transparent Upgradeable Proxy не имеет публичных функций. Однако, чтобы позволить ProxyAdmin сделать вызов интерфейса (вызов высокого уровня), он должен принять от ProxyAdmin кодированные ABI calldata для upgradeToAndCall().
Напомн, что ProxyAdmin делает интерфейсный вызов upgradeToAndCall в прокси, хотя у прокси нет публичных функций, кроме fallback (код ProxyAdmin показан далее):
Выше представлено видео, демонстрирующее все три блока кода рядом друг с другом и то, как различные контракты в цепочке наследования (Proxy, ERC1967Proxy и TransparentUpgradeableProxy) взаимодействуют друг с другом.
В следующем посте поговорим о том, почему функция называется upgradeToAndCall(), а не просто upgradeTo().
#proxy #transparent
TransparentUpgradeableProxy.sol наследует от ERC1967Proxy.sol. В конструкторе этого контракта разворачивается ProxyAdmin и устанавливается как адрес неизменяемого admin (первая переменная в контракте).
contract TransparentUpgradeableProxy is ERC1967Proxy {
address private immutable _admin;
error ProxyDeniedAdminAccess();
constructor(address _logic, address initialOwner, bytes memory _data) payable ERC1967Proxy(_logic, _data) {
_admin = address(new ProxyAdmin(initialOwner));
// Set the storage value and emit an event for ERC-1967 compatibility
ERC1967Utils.changeAdmin(_proxyAdmin());
}
function _proxyAdmin() internal view virtual returns (address) {
return _admin;
}
function _fallback() internal virtual override {
if (msg.sender == _proxyAdmin()) {
if (msg.sig != ITransparentUpgradeableProxy.upgradeToAndCall.selector) {
revert ProxyDeniedAdminAccess();
} else {
_dispatchUpgradeToAndCall();
}
} else {
super._fallback();
}
}
function _dispatchUpgradeToAndCall() private {
(address newImplementation, bytes memory data) = abi.decode(msg.data[4:], (address, bytes));
ERC1967Utils.upgradeToAndCall(newImplementation, data);
}
}
Рассмотрим случай, когда отправителем msg.sender является _proxyAdmin. В этом случае вызов направляется в _dispatchUpgradeToAndCall(), но _fallback() сначала проверяет, что предоставленный селектор функций является селектором функций для upgradeToAndCall.
«Селектор» здесь не является "настоящим" селектором, поскольку Transparent Upgradeable Proxy не имеет публичных функций. Однако, чтобы позволить ProxyAdmin сделать вызов интерфейса (вызов высокого уровня), он должен принять от ProxyAdmin кодированные ABI calldata для upgradeToAndCall().
Напомн, что ProxyAdmin делает интерфейсный вызов upgradeToAndCall в прокси, хотя у прокси нет публичных функций, кроме fallback (код ProxyAdmin показан далее):
contract ProxyAdmin is Ownable {
string public constant UPGRADE_INTERFACE_VERSION = "5.0.0";
constructor(address initialOwner) Ownable(initialOwner) {}
function upgradeAndCall(
ITransparentUpgradeableProxy proxy,
address implementation,
bytes memory data
) public payable virtual onlyOwner {
@> proxy.upgradeToAndCall{value: msg.value}(implementation, data);
}
}Выше представлено видео, демонстрирующее все три блока кода рядом друг с другом и то, как различные контракты в цепочке наследования (Proxy, ERC1967Proxy и TransparentUpgradeableProxy) взаимодействуют друг с другом.
В следующем посте поговорим о том, почему функция называется upgradeToAndCall(), а не просто upgradeTo().
#proxy #transparent
👍6