Чтобы запустить программу с меньшим количеством опкодов, чем фиксированное число, мы просто вставляем в нее NOP до тех пор, пока программа не достигнет максимального размера. Чтобы знать, когда «прекратить выполнение», пользователь должен предоставить вышеупомянутый аргумент steps, чтобы определить, когда будет возвращено значение в нижней части стека.
Несколько замечаний о нашей архитектуре:
- VM основана на стеке, как EVM, Java Virtual Machine или (для тех, кто знает) калькулятор Reverse Polish notation.
- Инструкций перехода нет, поэтому program counter только увеличивается.
- Все операционные коды принимают один аргумент, но ADD, MUL и NOP игнорируют переданный им аргумент. Это позволяет нам всегда увеличивать program counter на одну и ту же величину - нам не нужно обновлять его на 2 для PUSH, на 1 для ADD и так далее. Мы всегда сдвигаем счетчик на 2.
- Для того, чтобы прочитать аргумент PUSH, мы просто «смотрим вперед» на один индекс от program counter.
- Сложение и умножение выполняются с использованием модульной арифметики (по умолчанию в Circom). В качестве «размера слова» мы используем порядок поля по умолчанию в Circom - мы не пытаемся эмулировать виртуальные машины с традиционными размерами слов, такими как 64 или 256 бит. Эмуляция вычислений с битами фиксированного размера - тема следующей главы.
Вся статья тут - How a ZKVM Works.
#zkvm
Несколько замечаний о нашей архитектуре:
- VM основана на стеке, как EVM, Java Virtual Machine или (для тех, кто знает) калькулятор Reverse Polish notation.
- Инструкций перехода нет, поэтому program counter только увеличивается.
- Все операционные коды принимают один аргумент, но ADD, MUL и NOP игнорируют переданный им аргумент. Это позволяет нам всегда увеличивать program counter на одну и ту же величину - нам не нужно обновлять его на 2 для PUSH, на 1 для ADD и так далее. Мы всегда сдвигаем счетчик на 2.
- Для того, чтобы прочитать аргумент PUSH, мы просто «смотрим вперед» на один индекс от program counter.
- Сложение и умножение выполняются с использованием модульной арифметики (по умолчанию в Circom). В качестве «размера слова» мы используем порядок поля по умолчанию в Circom - мы не пытаемся эмулировать виртуальные машины с традиционными размерами слов, такими как 64 или 256 бит. Эмуляция вычислений с битами фиксированного размера - тема следующей главы.
Вся статья тут - How a ZKVM Works.
#zkvm
👍10
Как работает ZKVM. Часть 2
Мы можем внести несколько ключевых изменений в наш стековый код из предыдущего поста, чтобы собрать ZKVM, соответствующий спецификации, описанной выше.
- Мы удалили опкод POP, поскольку он больше не нужен;
- Мы добавили опкоды ADD и MUL;
Вспомните, что предыдущие правила копирования предыдущего стека были следующими:
- A. Если sp равен 1 или больше, а столбец j находится на 1 индекс ниже sp, и текущая инструкция - PUSH или NOP, мы должны скопировать столбец j;
- B. Если sp равно 2 или больше, и столбец j находится на 2 индекса ниже sp, а текущая инструкция - POP, мы должны скопировать столбец j;
Правило A остается неизменным, а вот B нужно обновить следующим образом:
- B. Если sp равно 2 или больше, а столбец j находится на 3 индекса ниже sp, и текущая инструкция - ADD или MUL, мы должны скопировать столбец j;
Причина этого изменения в том, что предыдущая инструкция POP не изменяла второй по счету элемент стека, а только удаляла верхний. Однако ADD дважды открывает стек и выводит сумму. Аналогично, MUL дважды открывает стек и вставляет произведение.
Предыдущая реализация стека только записывала новые значения в указатель стека. Однако новая реализация может записывать сумму или произведение на два индекса ниже указателя стека. Например, 12 в стеке ниже станет 15 после сложения, а это место находится на два индекса ниже указателя стека:
Перед добавлением:
После сложения:
Здесь у нас есть 12 в качестве нижней части стека и sp, указывающий на пустое пространство над стеком.
Поэтому нам нужен сигнал, указывающий на то, что определенный столбец находится на два элемента ниже указателя стека.
Приведенный в оригинальной статье код в значительной степени заимствован из стека предыдущей главы, но в нем реализованы обновления, описанные в этой главе. А именно:
- Мы заменили NOP, PUSH и POP на NOP, PUSH, ADD и MUL. ADD и MUL уменьшают указатель стека на единицу, NOP сохраняет указатель стека неизменным, а PUSH увеличивает указатель стека на единицу и копирует свой аргумент в вершину стека.
Если хотите покопаться в самом коде, то лучше перейти на оригинальную статью, где он представлен в развернутом виде - https://www.rareskills.io/post/zkvm.
Также его можно перенести в редактор кода с нейронными сетями и изучить, разбивая на небольшие сниппеты.
#zkvm
Мы можем внести несколько ключевых изменений в наш стековый код из предыдущего поста, чтобы собрать ZKVM, соответствующий спецификации, описанной выше.
- Мы удалили опкод POP, поскольку он больше не нужен;
- Мы добавили опкоды ADD и MUL;
Вспомните, что предыдущие правила копирования предыдущего стека были следующими:
- A. Если sp равен 1 или больше, а столбец j находится на 1 индекс ниже sp, и текущая инструкция - PUSH или NOP, мы должны скопировать столбец j;
- B. Если sp равно 2 или больше, и столбец j находится на 2 индекса ниже sp, а текущая инструкция - POP, мы должны скопировать столбец j;
Правило A остается неизменным, а вот B нужно обновить следующим образом:
- B. Если sp равно 2 или больше, а столбец j находится на 3 индекса ниже sp, и текущая инструкция - ADD или MUL, мы должны скопировать столбец j;
Причина этого изменения в том, что предыдущая инструкция POP не изменяла второй по счету элемент стека, а только удаляла верхний. Однако ADD дважды открывает стек и выводит сумму. Аналогично, MUL дважды открывает стек и вставляет произведение.
Предыдущая реализация стека только записывала новые значения в указатель стека. Однако новая реализация может записывать сумму или произведение на два индекса ниже указателя стека. Например, 12 в стеке ниже станет 15 после сложения, а это место находится на два индекса ниже указателя стека:
Перед добавлением:
[12 , 3, sp] (sp = 3)
После сложения:
[15, sp] (sp = 2)
Здесь у нас есть 12 в качестве нижней части стека и sp, указывающий на пустое пространство над стеком.
Поэтому нам нужен сигнал, указывающий на то, что определенный столбец находится на два элемента ниже указателя стека.
Приведенный в оригинальной статье код в значительной степени заимствован из стека предыдущей главы, но в нем реализованы обновления, описанные в этой главе. А именно:
- Мы заменили NOP, PUSH и POP на NOP, PUSH, ADD и MUL. ADD и MUL уменьшают указатель стека на единицу, NOP сохраняет указатель стека неизменным, а PUSH увеличивает указатель стека на единицу и копирует свой аргумент в вершину стека.
Если хотите покопаться в самом коде, то лучше перейти на оригинальную статью, где он представлен в развернутом виде - https://www.rareskills.io/post/zkvm.
Также его можно перенести в редактор кода с нейронными сетями и изучить, разбивая на небольшие сниппеты.
#zkvm
👍3
Как работает ZKVM. Часть 3
Ну, и заключительный перевод статьи о ZKVM.
Разве не неэффективно иметь ограничения для каждого опкода, если мы используем только один?
В нашем ZKVM мы выполняем сложение и умножение для каждого элемента стека, хотя на самом деле используем только один из них. Это не имеет значения для таких легких операций, как сложение или умножение. Однако если бы у нас был опкод для такой сложной операции, как хеширование, это создало бы значительно больше ограничений; нам пришлось бы заполнять схему хеширования для каждого элемента в стеке, хотя хешировать нужно только вершину стека. Все это приведет к ненужным вычислениям и большим вычислительным затратам.
Мы можем повысить эффективность, используя Quin selector (или два) для определения того, какие элементы стека будут входом для опкода, но это все равно означает, что каждая итерация стека нуждается в ограничениях для хэша, даже если он их не использует.
Эта низкая эффективность ненужного повторения неиспользуемых ограничений является серьезным недостатком ванильного R1CS, который не позволяет условно использовать ограничения.
Решения для повышения эффективности
Два современных подхода, позволяющих значительно повысить эффективность, - это ограничения, основанные на таблицах поиска, и рекурсивные доказательства.
1. Таблица поиска - это схема арифметизации, в которой только те ограничения, которые действительно используются, являются частью таблицы, а затем ZK-доказательство доказывает, что оно использовало правильную запись из таблицы для каждой инструкции.
2. Рекурсивное доказательство создает отдельное ZK-доказательство для каждой инструкции, а затем объединяет его с другим ZK-доказательством, которое проверяет правильность входных доказательств. Учтите, что алгоритм верификации в ZK сам по себе может быть смоделирован с помощью арифметической схемы.
#zkvm
Ну, и заключительный перевод статьи о ZKVM.
Разве не неэффективно иметь ограничения для каждого опкода, если мы используем только один?
В нашем ZKVM мы выполняем сложение и умножение для каждого элемента стека, хотя на самом деле используем только один из них. Это не имеет значения для таких легких операций, как сложение или умножение. Однако если бы у нас был опкод для такой сложной операции, как хеширование, это создало бы значительно больше ограничений; нам пришлось бы заполнять схему хеширования для каждого элемента в стеке, хотя хешировать нужно только вершину стека. Все это приведет к ненужным вычислениям и большим вычислительным затратам.
Мы можем повысить эффективность, используя Quin selector (или два) для определения того, какие элементы стека будут входом для опкода, но это все равно означает, что каждая итерация стека нуждается в ограничениях для хэша, даже если он их не использует.
Эта низкая эффективность ненужного повторения неиспользуемых ограничений является серьезным недостатком ванильного R1CS, который не позволяет условно использовать ограничения.
Решения для повышения эффективности
Два современных подхода, позволяющих значительно повысить эффективность, - это ограничения, основанные на таблицах поиска, и рекурсивные доказательства.
1. Таблица поиска - это схема арифметизации, в которой только те ограничения, которые действительно используются, являются частью таблицы, а затем ZK-доказательство доказывает, что оно использовало правильную запись из таблицы для каждой инструкции.
2. Рекурсивное доказательство создает отдельное ZK-доказательство для каждой инструкции, а затем объединяет его с другим ZK-доказательством, которое проверяет правильность входных доказательств. Учтите, что алгоритм верификации в ZK сам по себе может быть смоделирован с помощью арифметической схемы.
#zkvm
👍4
Вышла новая версия Solidity 0.8.30
Команда Solidity представила версию 0.8.30 компилятора. Этот релиз — техническое обновление, связанное с предстоящим обновлением сети Ethereum Pectra, которое вышло на прошлой неделе. Основное изменение — смена EVM-версии по умолчанию с Cancun на Prague.
Pectra — это масштабное обновление Ethereum, следующее за Dencun, которое вносит изменения как в execution layer, так и в consensus layer сети. Рассмотрим ключевые EIP, влияющие на Solidity.
EIP-7623: Увеличение стоимости calldata
EIP-7623 повышает стоимость calldata для транзакций, которые в основном отправляют данные. Это компенсирует увеличение пропускной способности из-за EIP-7691, уменьшая максимальный размер блока.
Изменение может повлиять на оптимизацию констант в компиляторе. Например, значение 2**256 - 1 можно закодировать как PUSH32 (3 газа, 33 байта) или PUSH0 NOT (5 газа, 2 байта). Оптимизатор выбирает вариант, исходя из стоимости calldata, но из-за нелинейного роста затрат точный расчет усложняется.
Команда Solidity не стала вносить изменения в алгоритмы оптимизации, так как учесть новый расчет стоимости на уровне отдельных opcode практически невозможно. Вместо этого рекомендуется настраивать параметры оптимизации вручную, например, через --optimizer-runs.
EIP-7702: Делегирование EOA контракту
EIP-7702 добавляет новый тип транзакции, позволяющий EOA временно делегировать управление контракту. Это важный шаг к полной account abstraction.
В версии 0.8.30 нет изменений, связанных с этим EIP, но предыдущий релиз (0.8.29) добавил контроль над storage layout, чтобы несколько пользователей могли безопасно использовать хранилище одного EOA.
EIP-2537: Прекомпиляция для операций с BLS12-381
EIP-2537 добавляет прекомпиляцию для верификации BLS-подписей на блокчейне. В отличие от ECDSA, BLS-подписи поддерживают агрегацию, что делает их полезными для консенсуса.
Пока Solidity не добавляет встроенную поддержку BLS, так как вызовы прекомпилированных контрактов можно реализовать через внешние функции. Команда рассматривает возможность включения этой функциональности в стандартную библиотеку в будущем.
Исправления и улучшения
1. Установлена EVM-версия по умолчанию prague.
2. NatSpec теперь фиксирует документацию enum в AST.
3. Исправлены ошибки в SMTChecker, включая ложные отчеты о постоянных условиях и внутренние ошибки компилятора.
Обновляйтесь и тестируйте свои контракты с выходом Pectra!
#solidity
Команда Solidity представила версию 0.8.30 компилятора. Этот релиз — техническое обновление, связанное с предстоящим обновлением сети Ethereum Pectra, которое вышло на прошлой неделе. Основное изменение — смена EVM-версии по умолчанию с Cancun на Prague.
Pectra — это масштабное обновление Ethereum, следующее за Dencun, которое вносит изменения как в execution layer, так и в consensus layer сети. Рассмотрим ключевые EIP, влияющие на Solidity.
EIP-7623: Увеличение стоимости calldata
EIP-7623 повышает стоимость calldata для транзакций, которые в основном отправляют данные. Это компенсирует увеличение пропускной способности из-за EIP-7691, уменьшая максимальный размер блока.
Изменение может повлиять на оптимизацию констант в компиляторе. Например, значение 2**256 - 1 можно закодировать как PUSH32 (3 газа, 33 байта) или PUSH0 NOT (5 газа, 2 байта). Оптимизатор выбирает вариант, исходя из стоимости calldata, но из-за нелинейного роста затрат точный расчет усложняется.
Команда Solidity не стала вносить изменения в алгоритмы оптимизации, так как учесть новый расчет стоимости на уровне отдельных opcode практически невозможно. Вместо этого рекомендуется настраивать параметры оптимизации вручную, например, через --optimizer-runs.
EIP-7702: Делегирование EOA контракту
EIP-7702 добавляет новый тип транзакции, позволяющий EOA временно делегировать управление контракту. Это важный шаг к полной account abstraction.
В версии 0.8.30 нет изменений, связанных с этим EIP, но предыдущий релиз (0.8.29) добавил контроль над storage layout, чтобы несколько пользователей могли безопасно использовать хранилище одного EOA.
EIP-2537: Прекомпиляция для операций с BLS12-381
EIP-2537 добавляет прекомпиляцию для верификации BLS-подписей на блокчейне. В отличие от ECDSA, BLS-подписи поддерживают агрегацию, что делает их полезными для консенсуса.
Пока Solidity не добавляет встроенную поддержку BLS, так как вызовы прекомпилированных контрактов можно реализовать через внешние функции. Команда рассматривает возможность включения этой функциональности в стандартную библиотеку в будущем.
Исправления и улучшения
1. Установлена EVM-версия по умолчанию prague.
2. NatSpec теперь фиксирует документацию enum в AST.
3. Исправлены ошибки в SMTChecker, включая ложные отчеты о постоянных условиях и внутренние ошибки компилятора.
Обновляйтесь и тестируйте свои контракты с выходом Pectra!
#solidity
👍11❤3
Погружение в EIP-7702. Часть 1
Уже столько всего слышал про обновление Pectra и данный новый стандарт, но все ждал, когда выйдет чуть больше информации с примерами и нюансами использования. Наконец, хочу сделать небольшой цикл постов на основе разных статей, где мы погрузимся в эту тему и разберемся, что к чему.
EIP-7702 - это важное обновление Ethereum, которое позволит аккаунтам, принадлежащим внешним пользователям (Externally Owned Accounts, EOA), напрямую выполнять код смарт-контрактов. Это изменение позволяет EOA получить функциональные возможности смарт-контрактов, что способствует продвижению Ethereum к полной абстракции аккаунтов (account abstraction).
Как обновление Pectra с помощью EIP-7702 повлияет на Account Abstraction Roadmap
Долгосрочная цель Ethereum - превратить каждый аккаунт, принадлежащий внешнему владельцу (Externally Owned Account, EOA), в смарт аккаунт. Хотя Account Abstraction все еще является хоть и не далекой, но все же перспективой, хард форк Pectra ознаменовал собой ключевой шаг вперед, представив EIP-7702. Это обновление позволяет любому EOA запускать код смарт-контракта непосредственно на своем адресе, эффективно расширяя его функциональность за счет возможностей, традиционно доступных только смарт-контрактам.
EIP-7702: Расширение EOA с помощью функций смарт-контракта
EOA и смарт-контракты исторически различались: EOA могут инициировать транзакции, но не могут выполнять код, в то время как смарт-контракты могут выполнять код при вызовах, но не могут начинать транзакции. EIP-7702 устраняет этот разрыв, позволяя EOA выполнять код, стирая границы между ними и смарт-контрактами. Это расширение открывает новые возможности для пользователей, позволяя им пользоваться функциями, подобными смарт-контрактам, без необходимости переходить на полноценные смарт-контракты.
Благодаря EIP-7702 EOA теперь могут хранить адрес, называемый «delegation designator», который указывает на смарт-контракт. Когда транзакция отправляется на EOA, он может выполнить код по этому назначенному адресу, как если бы он был его собственным, подобно тому, как работает «delegate call» в смарт-контрактах.
Если делегированный адрес включает функции смарт-аккаунта, то EOA может функционировать как смарт-аккаунт. Это означает, что он может поддерживать подписание транзакций несколькими владельцами, устанавливать пороговые значения, использовать passkey в качестве подписывающих лиц, а также добавлять различные модули для расширения своих возможностей.
Ключевое отличие от обычного смарт-аккаунта заключается в том, что приватный ключ EOA сохраняет полный контроль. Он может подписывать как транзакции в сети, так и сообщения вне ее, поэтому безопасность этого приватного ключа остается крайне важной. Даже при наличии функций смарт-аккаунта защита приватного ключа необходима для предотвращения несанкционированного доступа.
В конечном итоге это позволит пользователям интегрировать свои EOA в кошельки смарт-аккаунтов, такие как Safe Wallet, предоставляя им доступ к полному набору функций аккаунтов, с которыми они уже знакомы. Это означает, что теперь EOA могут воспользоваться преимуществами повышенной безопасности, удобства и гибкости без необходимости полностью переходить на новый кошелек.
Операция по добавлению «delegation designator» вводит новый тип транзакции, не поддерживаемый автоматически кошельками. Этот новый тип необходим для того, чтобы пользователи не могли непреднамеренно подписать ее и делегировать контроль над своей EOA. Кошельки должны будут реализовать поддержку этой транзакции, отображая специальный интерфейс, который четко объясняет последствия - аналогично интерфейсу, используемому при экспорте закрытого ключа. Из-за значительных рисков безопасности эта транзакция, скорее всего, будет осуществляться доверенными кошельками, а не децентрализованными приложениями (dapp).
Уже столько всего слышал про обновление Pectra и данный новый стандарт, но все ждал, когда выйдет чуть больше информации с примерами и нюансами использования. Наконец, хочу сделать небольшой цикл постов на основе разных статей, где мы погрузимся в эту тему и разберемся, что к чему.
EIP-7702 - это важное обновление Ethereum, которое позволит аккаунтам, принадлежащим внешним пользователям (Externally Owned Accounts, EOA), напрямую выполнять код смарт-контрактов. Это изменение позволяет EOA получить функциональные возможности смарт-контрактов, что способствует продвижению Ethereum к полной абстракции аккаунтов (account abstraction).
Как обновление Pectra с помощью EIP-7702 повлияет на Account Abstraction Roadmap
Долгосрочная цель Ethereum - превратить каждый аккаунт, принадлежащий внешнему владельцу (Externally Owned Account, EOA), в смарт аккаунт. Хотя Account Abstraction все еще является хоть и не далекой, но все же перспективой, хард форк Pectra ознаменовал собой ключевой шаг вперед, представив EIP-7702. Это обновление позволяет любому EOA запускать код смарт-контракта непосредственно на своем адресе, эффективно расширяя его функциональность за счет возможностей, традиционно доступных только смарт-контрактам.
EIP-7702: Расширение EOA с помощью функций смарт-контракта
EOA и смарт-контракты исторически различались: EOA могут инициировать транзакции, но не могут выполнять код, в то время как смарт-контракты могут выполнять код при вызовах, но не могут начинать транзакции. EIP-7702 устраняет этот разрыв, позволяя EOA выполнять код, стирая границы между ними и смарт-контрактами. Это расширение открывает новые возможности для пользователей, позволяя им пользоваться функциями, подобными смарт-контрактам, без необходимости переходить на полноценные смарт-контракты.
Благодаря EIP-7702 EOA теперь могут хранить адрес, называемый «delegation designator», который указывает на смарт-контракт. Когда транзакция отправляется на EOA, он может выполнить код по этому назначенному адресу, как если бы он был его собственным, подобно тому, как работает «delegate call» в смарт-контрактах.
Если делегированный адрес включает функции смарт-аккаунта, то EOA может функционировать как смарт-аккаунт. Это означает, что он может поддерживать подписание транзакций несколькими владельцами, устанавливать пороговые значения, использовать passkey в качестве подписывающих лиц, а также добавлять различные модули для расширения своих возможностей.
Ключевое отличие от обычного смарт-аккаунта заключается в том, что приватный ключ EOA сохраняет полный контроль. Он может подписывать как транзакции в сети, так и сообщения вне ее, поэтому безопасность этого приватного ключа остается крайне важной. Даже при наличии функций смарт-аккаунта защита приватного ключа необходима для предотвращения несанкционированного доступа.
В конечном итоге это позволит пользователям интегрировать свои EOA в кошельки смарт-аккаунтов, такие как Safe Wallet, предоставляя им доступ к полному набору функций аккаунтов, с которыми они уже знакомы. Это означает, что теперь EOA могут воспользоваться преимуществами повышенной безопасности, удобства и гибкости без необходимости полностью переходить на новый кошелек.
Операция по добавлению «delegation designator» вводит новый тип транзакции, не поддерживаемый автоматически кошельками. Этот новый тип необходим для того, чтобы пользователи не могли непреднамеренно подписать ее и делегировать контроль над своей EOA. Кошельки должны будут реализовать поддержку этой транзакции, отображая специальный интерфейс, который четко объясняет последствия - аналогично интерфейсу, используемому при экспорте закрытого ключа. Из-за значительных рисков безопасности эта транзакция, скорее всего, будет осуществляться доверенными кошельками, а не децентрализованными приложениями (dapp).
2❤3👍1👌1
Транзакция включает в себя такие данные, как nonce EOA, адрес delegation designator и идентификатор сети. Это влияет на ее кросс-сетевую функциональность. Пользователи могут включить идентификатор конкретной сети, ограничив действие транзакции только в ней.
В качестве альтернативы они могут установить идентификатор сети на ноль, что сделает транзакцию действительной для нескольких. Однако для того, чтобы это сработало, nonce EOA должен совпадать в разных сетях. Если nonce отличается - из-за того, что EOA проводит разное количество транзакций в разных блокчейнах, - транзакция будет успешной только в одной из них. Это означает, что EOA с нулевым nonce может создать транзакцию, действительную на всех сетях. И наоборот, EOA с историей транзакций в нескольких блокчейнах придется генерировать отдельные транзакции, каждая из которых будет иметь соответствующий nonce для соответствующей сети.
#eip7702
В качестве альтернативы они могут установить идентификатор сети на ноль, что сделает транзакцию действительной для нескольких. Однако для того, чтобы это сработало, nonce EOA должен совпадать в разных сетях. Если nonce отличается - из-за того, что EOA проводит разное количество транзакций в разных блокчейнах, - транзакция будет успешной только в одной из них. Это означает, что EOA с нулевым nonce может создать транзакцию, действительную на всех сетях. И наоборот, EOA с историей транзакций в нескольких блокчейнах придется генерировать отдельные транзакции, каждая из которых будет иметь соответствующий nonce для соответствующей сети.
#eip7702
1👍3❤2
Погружение в EIP-7702. Часть 2
Сегодня обозначим преимущества и недостатки EIP-7702.
EIP-7702 привносит функции Smart Account в EOA, в первую очередь позволяя им получить доступ к преимуществам Account Abstraction (ERC-4337), которые ранее были ограничены Smart Accounts. Основные преимущества включают:
1. Спонсируемые транзакции: Теперь EOA могут воспользоваться преимуществами спонсированных транзакций, при которых платежная система покрывает газовые сборы. Это позволяет EOA выполнять транзакции в сетях, где у них нет средств на газ, что упрощает использование новых сетей. Протоколы также могут покрывать расходы на газ для своих пользователей (например, они могут подать заявку на Safe Gas Station, что позволит Safe произвести оплату).
2. Пакетные транзакции (Batched Transactions): EOA могут отправлять несколько транзакций с одной подписью, что особенно полезно для межсетевых операций или транзакций, требующих объединения, таких как депозиты.
3. Passkeys: Пользователи могут легко подписывать транзакции с помощью ключей доступа, обеспечивая более быструю и надежную аутентификацию, что повышает удобство и безопасность.
4. Ключи сеансов: EOA могут «входить» в dapp и авторизировать транзакции в течение определенного периода времени (например, 24 часа), снижая необходимость для пользователей вручную подписывать каждую транзакцию. Эта функция идеально подходит для таких сценариев, как усреднение затрат в долларах или ограничение прав доступа к определенным активам или функциям, что повышает удобство использования и безопасность.
5. Возможность отзыва: Пользователи сохраняют полный контроль над своими EOA, имея возможность в любой момент отозвать или изменить назначение вызова.
6. Восстановление активов: Если закрытый ключ утерян, но функции восстановления настроены с помощью EIP-7702, пользователи могут восстановить активы, хранящиеся в учетной записи, что добавляет другой уровень безопасности.
7. Улучшенный межсетевой пользовательский интерфейс: теперь EOA, оснащенные функциями «умного аккаунта», могут использовать chain abstraction. Это позволяет осуществлять бесшовные транзакции в нескольких сетях без необходимости вручную переключаться между ними в кошельке или беспокоиться о том, где развернут протокол.
8. Бесшовная интеграция со смарт-кошельками: Пользователи смогут встраивать свои EOA в кошельки Smart Account, такие как Safe Wallet, что позволит им пользоваться полным набором функций Smart Account, к которым они уже привыкли. Такая интеграция повышает удобство использования и безопасность, сохраняя доступ к существующим активам без необходимости перехода на совершенно новый кошелек.
EIP-7702 значительно улучшает EOA, делая их более универсальными и удобными в использовании, с функциями, традиционно предназначенными для смарт-аккаунтов.
А теперь о недостатках.
Несмотря на то, что EIP-7702 является значительным шагом на пути перехода от EOA к Smart Accounts, он не является полной реализацией account abstraction, а также не полностью преобразует EOAs в Smart Accounts. С точки зрения абстракции учетной записи он имеет ряд ограничений:
1. Закрытый ключ EOA сохраняет полный контроль над учетной записью, действуя как черный ход, который может отменить функции Smart Account. Поэтому очень важно обеспечить защиту ключа, так как любой злоумышленник, получивший доступ, может получить полный контроль и украсть все активы.
2. В случаях, когда смарт-аккаунт с несколькими подписями создается на основе EOA, другие владельцы должны полностью доверять владельцу оригинальной EOA. Поскольку закрытый ключ EOA может уничтожить смарт-аккаунт в ходе одной транзакции, это подрывает безопасность и доверие, необходимые для мультисиговых систем, и делает нецелесообразным использование перенесенного EOA несколькими владельцами.
3. Если закрытый ключ утерян или скомпрометирован, восстановить полный контроль над EOA не представляется возможным. Единственным решением будет замена закрытого ключа, что может оказаться сложной задачей и не дает прямого механизма восстановления.
Сегодня обозначим преимущества и недостатки EIP-7702.
EIP-7702 привносит функции Smart Account в EOA, в первую очередь позволяя им получить доступ к преимуществам Account Abstraction (ERC-4337), которые ранее были ограничены Smart Accounts. Основные преимущества включают:
1. Спонсируемые транзакции: Теперь EOA могут воспользоваться преимуществами спонсированных транзакций, при которых платежная система покрывает газовые сборы. Это позволяет EOA выполнять транзакции в сетях, где у них нет средств на газ, что упрощает использование новых сетей. Протоколы также могут покрывать расходы на газ для своих пользователей (например, они могут подать заявку на Safe Gas Station, что позволит Safe произвести оплату).
2. Пакетные транзакции (Batched Transactions): EOA могут отправлять несколько транзакций с одной подписью, что особенно полезно для межсетевых операций или транзакций, требующих объединения, таких как депозиты.
3. Passkeys: Пользователи могут легко подписывать транзакции с помощью ключей доступа, обеспечивая более быструю и надежную аутентификацию, что повышает удобство и безопасность.
4. Ключи сеансов: EOA могут «входить» в dapp и авторизировать транзакции в течение определенного периода времени (например, 24 часа), снижая необходимость для пользователей вручную подписывать каждую транзакцию. Эта функция идеально подходит для таких сценариев, как усреднение затрат в долларах или ограничение прав доступа к определенным активам или функциям, что повышает удобство использования и безопасность.
5. Возможность отзыва: Пользователи сохраняют полный контроль над своими EOA, имея возможность в любой момент отозвать или изменить назначение вызова.
6. Восстановление активов: Если закрытый ключ утерян, но функции восстановления настроены с помощью EIP-7702, пользователи могут восстановить активы, хранящиеся в учетной записи, что добавляет другой уровень безопасности.
7. Улучшенный межсетевой пользовательский интерфейс: теперь EOA, оснащенные функциями «умного аккаунта», могут использовать chain abstraction. Это позволяет осуществлять бесшовные транзакции в нескольких сетях без необходимости вручную переключаться между ними в кошельке или беспокоиться о том, где развернут протокол.
8. Бесшовная интеграция со смарт-кошельками: Пользователи смогут встраивать свои EOA в кошельки Smart Account, такие как Safe Wallet, что позволит им пользоваться полным набором функций Smart Account, к которым они уже привыкли. Такая интеграция повышает удобство использования и безопасность, сохраняя доступ к существующим активам без необходимости перехода на совершенно новый кошелек.
EIP-7702 значительно улучшает EOA, делая их более универсальными и удобными в использовании, с функциями, традиционно предназначенными для смарт-аккаунтов.
А теперь о недостатках.
Несмотря на то, что EIP-7702 является значительным шагом на пути перехода от EOA к Smart Accounts, он не является полной реализацией account abstraction, а также не полностью преобразует EOAs в Smart Accounts. С точки зрения абстракции учетной записи он имеет ряд ограничений:
1. Закрытый ключ EOA сохраняет полный контроль над учетной записью, действуя как черный ход, который может отменить функции Smart Account. Поэтому очень важно обеспечить защиту ключа, так как любой злоумышленник, получивший доступ, может получить полный контроль и украсть все активы.
2. В случаях, когда смарт-аккаунт с несколькими подписями создается на основе EOA, другие владельцы должны полностью доверять владельцу оригинальной EOA. Поскольку закрытый ключ EOA может уничтожить смарт-аккаунт в ходе одной транзакции, это подрывает безопасность и доверие, необходимые для мультисиговых систем, и делает нецелесообразным использование перенесенного EOA несколькими владельцами.
3. Если закрытый ключ утерян или скомпрометирован, восстановить полный контроль над EOA не представляется возможным. Единственным решением будет замена закрытого ключа, что может оказаться сложной задачей и не дает прямого механизма восстановления.
🔥5
4. Для будущей защиты от угроз, связанных с квантовыми вычислениями, пользователям со временем придется перейти на полностью квантоустойчивые смарт-аккаунты. Смарт-аккаунты с расширенными функциональными возможностями все еще уязвимы для потенциальных алгоритмов, работающих на квантовых технологиях, которые могут скомпрометировать их закрытые ключи. Это подчеркивает необходимость постепенного перехода или экстренного обновления для обеспечения безопасности учетных записей в постквантовом мире.
5. Неспособность блокировать ресурсы или выступать в качестве Escrow: поскольку приватный ключ всегда имеет право передавать средства, смарт-контракты, построенные на EOA, не могут эффективно выступать в качестве escrow или надежно блокировать средства. Этот нюанс ограничивает использование функций смарт-аккаунтов, где требуется блокировка ресурсов.
Эти недостатки подчеркивают переходный характер EIP-7702, предлагающего дополнительные преимущества, но не обеспечивающего полной абстракции счета.
#eip7702
5. Неспособность блокировать ресурсы или выступать в качестве Escrow: поскольку приватный ключ всегда имеет право передавать средства, смарт-контракты, построенные на EOA, не могут эффективно выступать в качестве escrow или надежно блокировать средства. Этот нюанс ограничивает использование функций смарт-аккаунтов, где требуется блокировка ресурсов.
Эти недостатки подчеркивают переходный характер EIP-7702, предлагающего дополнительные преимущества, но не обеспечивающего полной абстракции счета.
#eip7702
👍4
Погружение в EIP-7702. Часть 3
Полный account abstraction предполагает, что каждый аккаунт в Ethereum будет представлять собой смарт-аккаунт, что приведет к существенным улучшениям как в плане безопасности, так и в плане удобства использования:
1. Больше схем подписи: В настоящее время EOA поддерживают только один тип подписи. С полной account abstraction станет возможным использование множества схем подписи, включая варианты, работающие со смартфонами и другими устройствами (например, passkeys). Это значительно повысит безопасность и удобство использования.
2. Опции восстановления по умолчанию: Смарт-аккаунты могли бы предлагать встроенные функции восстановления по умолчанию, или же пользователи могли бы легко отказаться от них. Это значительно снизит риск потери средств из-за ошибок или утери приватных ключей.
3. Спонсируемые транзакции: Каждый смарт-аккаунт будет иметь возможность подписывать спонсируемые транзакции. Это избавит пользователей от необходимости беспокоиться о комиссиях за газ и управлении цепочками, позволяя им сосредоточиться исключительно на удобстве и прибыльности dapp, с которой они взаимодействуют.
Пакетные транзакции и сеансовые ключи: Смарт-аккаунты могут «входить» в dapps, обеспечивая пользовательский опыт, схожий с централизованными приложениями. Это позволит быстро и без проблем осуществлять такие действия, как торговля и игры, без необходимости постоянного одобрения транзакций.
Шаги по достижению полной account abstraction
Для того, чтобы полностью реализовать АА, необходимо осуществить несколько ключевых изменений:
1. Интеграция ядра: АА должна быть полностью встроена в основной протокол Ethereum. В то время как ERC-4337 в настоящее время работает на прикладном уровне, усовершенствования на уровне протокола, такие как RIP-7560, сделают транзакции более газоэффективными и объединят все транзакции под одним мемпулом, устранив необходимость в отдельном мемпуле для операций ERC-4337.
2. Смарт-аккаунты по умолчанию: Все новые учетные записи Ethereum по умолчанию должны быть смарт-аккаунтами, при этом новые EOA создаваться не будут. Новые пользователи с самого начала смогут воспользоваться расширенными возможностями смарт-аккаунтов.
3. Перенос EOA на смарт-аккаунты: Существующие EOA необходимо преобразовать в Smart Accounts. Это особенно важно для пользователей, которые хотят сохранить свои оригинальные адреса из-за ценных непередаваемых активов, таких как soul-bound tokens. EIP-7702 играет решающую роль в этом переходе, но для удаления доступа к закрытому ключу EOA необходимы дополнительные меры. Ключевую роль здесь играет EIP-3607, который отменяет доступ к закрытому ключу, если аккаунт содержит код.
Проверка подписи
Смарт-аккаунты уже могут проверять подписи с помощью EIP-1271. Для завершения миграции необходимо обновить процессы проверки подписи, чтобы проверить, является ли подписант EOA или Смарт-аккаунтом. Если это Смарт-аккаунт, то подписи на основе закрытых ключей больше не должны валидироваться.
Соображения по поводу внесетевой проверки
Проверка подписи вне сети также должна учитывать возможность того, что учетная запись может быть EOA в одной сети, но Smart Account в другой. Верификаторы подписей должны быть ориентированы на конкретную сеть, обеспечивая правильную проверку подписей в зависимости от сети, из которой они были получены.
Такой оптимизированный путь к полной account abstraction в конечном итоге позволит создать бесшовную, безопасную и высокомасштабируемую экосистему Ethereum, в которой каждый аккаунт сможет воспользоваться расширенными возможностями смарт-аккаунтов.
#eip7702
Полный account abstraction предполагает, что каждый аккаунт в Ethereum будет представлять собой смарт-аккаунт, что приведет к существенным улучшениям как в плане безопасности, так и в плане удобства использования:
1. Больше схем подписи: В настоящее время EOA поддерживают только один тип подписи. С полной account abstraction станет возможным использование множества схем подписи, включая варианты, работающие со смартфонами и другими устройствами (например, passkeys). Это значительно повысит безопасность и удобство использования.
2. Опции восстановления по умолчанию: Смарт-аккаунты могли бы предлагать встроенные функции восстановления по умолчанию, или же пользователи могли бы легко отказаться от них. Это значительно снизит риск потери средств из-за ошибок или утери приватных ключей.
3. Спонсируемые транзакции: Каждый смарт-аккаунт будет иметь возможность подписывать спонсируемые транзакции. Это избавит пользователей от необходимости беспокоиться о комиссиях за газ и управлении цепочками, позволяя им сосредоточиться исключительно на удобстве и прибыльности dapp, с которой они взаимодействуют.
Пакетные транзакции и сеансовые ключи: Смарт-аккаунты могут «входить» в dapps, обеспечивая пользовательский опыт, схожий с централизованными приложениями. Это позволит быстро и без проблем осуществлять такие действия, как торговля и игры, без необходимости постоянного одобрения транзакций.
Шаги по достижению полной account abstraction
Для того, чтобы полностью реализовать АА, необходимо осуществить несколько ключевых изменений:
1. Интеграция ядра: АА должна быть полностью встроена в основной протокол Ethereum. В то время как ERC-4337 в настоящее время работает на прикладном уровне, усовершенствования на уровне протокола, такие как RIP-7560, сделают транзакции более газоэффективными и объединят все транзакции под одним мемпулом, устранив необходимость в отдельном мемпуле для операций ERC-4337.
2. Смарт-аккаунты по умолчанию: Все новые учетные записи Ethereum по умолчанию должны быть смарт-аккаунтами, при этом новые EOA создаваться не будут. Новые пользователи с самого начала смогут воспользоваться расширенными возможностями смарт-аккаунтов.
3. Перенос EOA на смарт-аккаунты: Существующие EOA необходимо преобразовать в Smart Accounts. Это особенно важно для пользователей, которые хотят сохранить свои оригинальные адреса из-за ценных непередаваемых активов, таких как soul-bound tokens. EIP-7702 играет решающую роль в этом переходе, но для удаления доступа к закрытому ключу EOA необходимы дополнительные меры. Ключевую роль здесь играет EIP-3607, который отменяет доступ к закрытому ключу, если аккаунт содержит код.
Проверка подписи
Смарт-аккаунты уже могут проверять подписи с помощью EIP-1271. Для завершения миграции необходимо обновить процессы проверки подписи, чтобы проверить, является ли подписант EOA или Смарт-аккаунтом. Если это Смарт-аккаунт, то подписи на основе закрытых ключей больше не должны валидироваться.
Соображения по поводу внесетевой проверки
Проверка подписи вне сети также должна учитывать возможность того, что учетная запись может быть EOA в одной сети, но Smart Account в другой. Верификаторы подписей должны быть ориентированы на конкретную сеть, обеспечивая правильную проверку подписей в зависимости от сети, из которой они были получены.
Такой оптимизированный путь к полной account abstraction в конечном итоге позволит создать бесшовную, безопасную и высокомасштабируемую экосистему Ethereum, в которой каждый аккаунт сможет воспользоваться расширенными возможностями смарт-аккаунтов.
#eip7702
👍3
Погружение в EIP-7702. Часть 4
Итак, как мы знаем, EIP-7702 представляет новый тип транзакции 0x04 в обновлении Pectra для Ethereum, который позволяет аккаунтами, принадлежащим внешним пользователям (EOA), выполнять временные функции смарт-контракта. Это усовершенствование Account Abstraction устраняет разрыв между EOA и смарт-контрактами, позволяя реализовать такие ключевые функции, как пакетные транзакции, спонсируемые платежи и контролируемое делегирование доступа.
EIP-7702 теперь активен в основной сети Ethereum, а также в тестовых сетях, таких как Sepolia, как часть обновления Pectra. Разработчики могут протестировать EIP-7702 в локальных средах Foundry - либо в свежей локальной сети, либо с помощью форка mainnet.
Транзакции EIP-7702
В то время как обычные транзакции Ethereum либо переводят средства, либо взаимодействуют со смарт-контрактами, новый тип транзакций 0x04 позволяет EOA выполнять код напрямую.
Благодаря новому стандарту EOA могут выполнять логику смарт-контракта непосредственно со своего собственного адреса, что делает возможным:
1. Пакетные транзакции: Объединять несколько действий в одну атомарную транзакцию (одобрение токенов, обмен, передача).
2. Делегирование ограниченного доступа: Предоставление временных, ограниченных полномочий без раскрытия ключей.
3. Спонсорство: Позволяет третьей стороне (например, paymaster) покрывать комиссию за газ для ваших транзакций.
4. Восстановление кошелька: Реализуйте механизм восстановления при потере приватного ключа.
Подписание авторизации
Пользователь (EOA) подписывает сообщение авторизации, которое включает в себя идентификатор цепочки, nonce, адрес делегирования и части подписи (y_parity, r, s). В результате генерируется подписанная авторизация, гарантирующая, что только утвержденный контракт может выполнять транзакции, и защищающая от атак повторного воспроизведения.
Для каждого разрешенного адреса делегирования пользователь (EOA) хранит обозначение делегирования - указатель на контракт реализации, которому EOA будет делегировать полномочия. Когда пользователь (или спонсор) выполняет транзакцию EIP-7702, он загружает и запускает код с адреса, указанного этим указателем.
Конструкция транзакции
В типичной транзакции Ethereum, если вы хотите вызвать функцию смарт-контракта, вы устанавливаете в поле to адрес этого контракта и включаете соответствующие данные для вызова его функции. В EIP-7702 вы устанавливаете в поле to адрес EOA и включаете данные для вызова функции контракта реализации в подписанное сообщение авторизации.
Анатомия транзакции EIP-7702
Приведенный ниже фрагмент кода демонстрирует, как с помощью клиента кошелька Viem создать пакетную транзакцию для смарт-аккаунта EIP-7702.
1. Он генерирует авторизационную подпись для определенного контракта.
2. Затем создается транзакция, в которой в поле to устанавливается собственный адрес смарт-счета.
3. Поле данных создается путем кодирования вызова функции execute с помощью массива из двух объектов call. Функция execute должна быть определена в контракте реализации и обрабатывать логику пакетной транзакции.
4. Наконец, транзакция включает подписанную авторизацию в authorizationList, что позволяет смарт-аккаунту делегировать выполнение контракту реализации.
Если другой кошелек (спонсор) захочет выполнить эту транзакцию (спонсируемая транзакция), он может использовать ту же подпись авторизации, чтобы делегировать выполнение контракту реализации.
Примечание: Контракты должны быть разработаны для обработки пакетных транзакций и других возможностей, предусмотренных EIP-7702. Кроме того, они должны включать механизмы защиты.
#eip7702
Итак, как мы знаем, EIP-7702 представляет новый тип транзакции 0x04 в обновлении Pectra для Ethereum, который позволяет аккаунтами, принадлежащим внешним пользователям (EOA), выполнять временные функции смарт-контракта. Это усовершенствование Account Abstraction устраняет разрыв между EOA и смарт-контрактами, позволяя реализовать такие ключевые функции, как пакетные транзакции, спонсируемые платежи и контролируемое делегирование доступа.
EIP-7702 теперь активен в основной сети Ethereum, а также в тестовых сетях, таких как Sepolia, как часть обновления Pectra. Разработчики могут протестировать EIP-7702 в локальных средах Foundry - либо в свежей локальной сети, либо с помощью форка mainnet.
Транзакции EIP-7702
В то время как обычные транзакции Ethereum либо переводят средства, либо взаимодействуют со смарт-контрактами, новый тип транзакций 0x04 позволяет EOA выполнять код напрямую.
Благодаря новому стандарту EOA могут выполнять логику смарт-контракта непосредственно со своего собственного адреса, что делает возможным:
1. Пакетные транзакции: Объединять несколько действий в одну атомарную транзакцию (одобрение токенов, обмен, передача).
2. Делегирование ограниченного доступа: Предоставление временных, ограниченных полномочий без раскрытия ключей.
3. Спонсорство: Позволяет третьей стороне (например, paymaster) покрывать комиссию за газ для ваших транзакций.
4. Восстановление кошелька: Реализуйте механизм восстановления при потере приватного ключа.
Подписание авторизации
Пользователь (EOA) подписывает сообщение авторизации, которое включает в себя идентификатор цепочки, nonce, адрес делегирования и части подписи (y_parity, r, s). В результате генерируется подписанная авторизация, гарантирующая, что только утвержденный контракт может выполнять транзакции, и защищающая от атак повторного воспроизведения.
Для каждого разрешенного адреса делегирования пользователь (EOA) хранит обозначение делегирования - указатель на контракт реализации, которому EOA будет делегировать полномочия. Когда пользователь (или спонсор) выполняет транзакцию EIP-7702, он загружает и запускает код с адреса, указанного этим указателем.
Конструкция транзакции
В типичной транзакции Ethereum, если вы хотите вызвать функцию смарт-контракта, вы устанавливаете в поле to адрес этого контракта и включаете соответствующие данные для вызова его функции. В EIP-7702 вы устанавливаете в поле to адрес EOA и включаете данные для вызова функции контракта реализации в подписанное сообщение авторизации.
Анатомия транзакции EIP-7702
Приведенный ниже фрагмент кода демонстрирует, как с помощью клиента кошелька Viem создать пакетную транзакцию для смарт-аккаунта EIP-7702.
1. Он генерирует авторизационную подпись для определенного контракта.
2. Затем создается транзакция, в которой в поле to устанавливается собственный адрес смарт-счета.
3. Поле данных создается путем кодирования вызова функции execute с помощью массива из двух объектов call. Функция execute должна быть определена в контракте реализации и обрабатывать логику пакетной транзакции.
4. Наконец, транзакция включает подписанную авторизацию в authorizationList, что позволяет смарт-аккаунту делегировать выполнение контракту реализации.
Если другой кошелек (спонсор) захочет выполнить эту транзакцию (спонсируемая транзакция), он может использовать ту же подпись авторизации, чтобы делегировать выполнение контракту реализации.
Примечание: Контракты должны быть разработаны для обработки пакетных транзакций и других возможностей, предусмотренных EIP-7702. Кроме того, они должны включать механизмы защиты.
#eip7702
👍6❤1
Погружение в EIP-7702. Часть 5
Вот представленный код из предыдущего поста и его визуальное представление.
А дальше мы поговорим, как все протестировать в Foundry.
#eip7702
Вот представленный код из предыдущего поста и его визуальное представление.
import { createWalletClient, http, parseEther } from 'viem'
import { anvil } from 'viem/chains'
import { privateKeyToAccount } from 'viem/accounts'
import { eip7702Actions } from 'viem/experimental'
import { abi, contractAddress } from './contract' // Assuming you have already deployed the contract and exported the ABI and contract address in a separate file
const account = privateKeyToAccount('0x...')
const walletClient = createWalletClient({
account,
chain: anvil,
transport: http(),
}).extend(eip7702Actions())
const authorization = await walletClient.signAuthorization({
contractAddress,
})
const hash = await walletClient.sendTransaction({
authorizationList: [authorization],
data: encodeFunctionData({
abi,
functionName: 'execute',
args: [
[
{
data: '0x',
to: '0xcb98643b8786950F0461f3B0edf99D88F274574D',
value: parseEther('0.001'),
},
{
data: '0x',
to: '0xd2135CfB216b74109775236E36d4b433F1DF507B',
value: parseEther('0.002'),
},
],
]
}),
to: walletClient.account.address,
})А дальше мы поговорим, как все протестировать в Foundry.
#eip7702
👍3
Погружение в EIP-7702. Часть 6
Сегодня начнем разбирать тему тестирования контрактов с EIP-7702 в Foundry. И для начала нам потребуется некоторая подготовительная работа.
Создадим проект и папку, установим зависимости и настроим remapping:
Теперь нам нужно обновить версию EVM для корректных тестов. Измените файл foundry.toml, чтобы обеспечить совместимость с EIP-7702, установив хардфорк Prague. Добавьте следующую строку в раздел [profile.default]:
Это необходимо, поскольку EIP-7702 доступен только с обновления Prague и далее.
Очистите преднастроенные контракты, тесты и скрипты. В папку src добавьте файл BatchCallAndSponsor, в папку test - файл BatchCallAndSponsor.t.sol, в папку noscript - файл BatchCallAndSponsor.s.sol из приложения к посту.
Контракт BatchCallAndSponsor - это простой контракт логики, который поддерживает пакетные транзакции и спонсорский газ.
P.S. Полный вариант реализации смотрите в файле BatchCallAndSponsor.sol. А в приведенных ниже контрактах дается краткий обзор возможностей.
Функция execute в контракте принимает массив структур Call, каждая из которых представляет отдельный вызов и указывает целевой адрес, значение (в Ether) и данные calldata.
Контракт проверяет подпись с помощью библиотеки OpenZeppelin ECDSA и MessageHashUtils. Подписанное сообщение содержит адрес вызывающей стороны, целевой контракт и вызовы.
В контракте поддерживается либо прямое, либо спонсируемое исполнение.
1. Прямое исполнение: Вызывающая сторона сама выполняет вызовы.
2. Спонсируемое исполнение: Спонсор выполняет вызовы от имени вызывающего абонента после проверки подписи, сделанной EOA.
Для предотвращения атак повторного воспроизведения в контракте используется nonce. После каждого успешного выполнения транзакции значение nonce увеличивается. Если бы nonce не был реализован, злоумышленник мог бы воспроизвести одну и ту же транзакцию несколько раз.
Далее поговорим о самих тестах.
#eip7702
Сегодня начнем разбирать тему тестирования контрактов с EIP-7702 в Foundry. И для начала нам потребуется некоторая подготовительная работа.
Создадим проект и папку, установим зависимости и настроим remapping:
forge init eip-7702-project
cd eip-7702-project
forge install foundry-rs/forge-std
forge install OpenZeppelin/openzeppelin-contracts
forge remappings > remappings.txt
Теперь нам нужно обновить версию EVM для корректных тестов. Измените файл foundry.toml, чтобы обеспечить совместимость с EIP-7702, установив хардфорк Prague. Добавьте следующую строку в раздел [profile.default]:
evm_version = «prague»
Это необходимо, поскольку EIP-7702 доступен только с обновления Prague и далее.
Очистите преднастроенные контракты, тесты и скрипты. В папку src добавьте файл BatchCallAndSponsor, в папку test - файл BatchCallAndSponsor.t.sol, в папку noscript - файл BatchCallAndSponsor.s.sol из приложения к посту.
Контракт BatchCallAndSponsor - это простой контракт логики, который поддерживает пакетные транзакции и спонсорский газ.
P.S. Полный вариант реализации смотрите в файле BatchCallAndSponsor.sol. А в приведенных ниже контрактах дается краткий обзор возможностей.
Функция execute в контракте принимает массив структур Call, каждая из которых представляет отдельный вызов и указывает целевой адрес, значение (в Ether) и данные calldata.
struct Call {
address to;
uint256 value;
bytes data;
}
function execute(Call[] calldata calls) external payable {
require(msg.sender == address(this), "Invalid authority");
_executeBatch(calls);
}
function _executeBatch(Call[] calldata calls) internal {
uint256 currentNonce = nonce;
nonce++;
for (uint256 i = 0; i < calls.length; i++) {
_executeCall(calls[i]);
}
emit BatchExecuted(currentNonce, calls);
}
function _executeCall(Call calldata callItem) internal {
(bool success,) = callItem.to.call{value: callItem.value}(callItem.data);
require(success, "Call reverted");
emit CallExecuted(msg.sender, callItem.to, callItem.value, callItem.data);
}Контракт проверяет подпись с помощью библиотеки OpenZeppelin ECDSA и MessageHashUtils. Подписанное сообщение содержит адрес вызывающей стороны, целевой контракт и вызовы.
bytes32 digest = keccak256(abi.encodePacked(nonce, encodedCalls));
require(ECDSA.recover(digest, signature) == msg.sender, "Invalid signature");
В контракте поддерживается либо прямое, либо спонсируемое исполнение.
1. Прямое исполнение: Вызывающая сторона сама выполняет вызовы.
2. Спонсируемое исполнение: Спонсор выполняет вызовы от имени вызывающего абонента после проверки подписи, сделанной EOA.
function execute(Call[] calldata calls) external payable {
// The caller executes the calls directly
}
function execute(Call[] calldata calls, bytes calldata signature) external payable {
// A sponsor executes the calls on behalf of the caller
}Для предотвращения атак повторного воспроизведения в контракте используется nonce. После каждого успешного выполнения транзакции значение nonce увеличивается. Если бы nonce не был реализован, злоумышленник мог бы воспроизвести одну и ту же транзакцию несколько раз.
function _executeBatch(Call[] calldata calls) internal {
uint256 currentNonce = nonce;
nonce++; // Increment nonce to protect against replay attacks
for (uint256 i = 0; i < calls.length; i++) {
_executeCall(calls[i]);
}
emit BatchExecuted(currentNonce, calls);
}Далее поговорим о самих тестах.
#eip7702
🔥7
Погружение в EIP-7702. Часть 7
А теперь пройдемся по тестовым контрактам.
Файл BatchCallAndSponsor.t.sol содержит тесты для контракта BatchCallAndSponsor. Они охватывают сценарии прямого и спонсорского выполнения, защиту от воспроизведения и обработку ошибок.
Тест прямого выполнения
Функция testDirectExecution проверяет прямое исполнение вызовов вызывающей стороной (т. е. Алисой). Она проверяет, что Алиса отправила 1 ETH и 100 токенов Бобу в одной транзакции.
В этом тесте Алиса уполномочивает контракт реализации выполнить транзакцию от ее имени. Мы используем чит-код signAndAttachDelegation, чтобы подписать сообщение авторизации и прикрепить его к транзакции.
Затем вызывается функция execute() на EOA Алисы с массивом вызовов, что невозможно без EIP-7702, самой Алисой.
Тест спонсированного выполнения
Функция testSponsoredExecution() проверяет спонсируемое выполнение вызовов спонсором (т. е. Бобом). Она проверяет, что третья сторона (Боб) может выполнить транзакцию от имени Алисы. Мы проверяем, что отправителем является Боб, а не Алиса, и что получатель получил средства.
В этом тесте Алиса подписывает сообщение, позволяющую реализации выполнять транзакции от ее имени. Боб прикрепляет его от имени Алисы и передает эфир.
Затем Алиса подписывает транзакцию, а Боб исполняет ее через временно назначенный контракт Алисы.
И наконец, функция execute() на EOA Алисы вызывается Бобом, а не Алисой.
Неверная подпись
Функция testWrongSignature() проверяет сценарий, в котором подпись неверна.
Тест защиты от воспроизведения
А теперь пройдемся по тестовым контрактам.
Файл BatchCallAndSponsor.t.sol содержит тесты для контракта BatchCallAndSponsor. Они охватывают сценарии прямого и спонсорского выполнения, защиту от воспроизведения и обработку ошибок.
Тест прямого выполнения
Функция testDirectExecution проверяет прямое исполнение вызовов вызывающей стороной (т. е. Алисой). Она проверяет, что Алиса отправила 1 ETH и 100 токенов Бобу в одной транзакции.
В этом тесте Алиса уполномочивает контракт реализации выполнить транзакцию от ее имени. Мы используем чит-код signAndAttachDelegation, чтобы подписать сообщение авторизации и прикрепить его к транзакции.
Затем вызывается функция execute() на EOA Алисы с массивом вызовов, что невозможно без EIP-7702, самой Алисой.
function testDirectExecution() public {
console2.log("Sending 1 ETH from Alice to Bob and transferring 100 tokens to Bob in a single transaction");
BatchCallAndSponsor.Call[] memory calls = new BatchCallAndSponsor.Call[](2);
// ETH transfer
calls[0] = BatchCallAndSponsor.Call({to: BOB_ADDRESS, value: 1 ether, data: ""});
// Token transfer
calls[1] = BatchCallAndSponsor.Call({
to: address(token),
value: 0,
data: abi.encodeCall(ERC20.transfer, (BOB_ADDRESS, 100e18))
});
vm.signAndAttachDelegation(address(implementation), ALICE_PK);
vm.startPrank(ALICE_ADDRESS);
BatchCallAndSponsor(ALICE_ADDRESS).execute(calls);
vm.stopPrank();
assertEq(BOB_ADDRESS.balance, 1 ether);
assertEq(token.balanceOf(BOB_ADDRESS), 100e18);
}Тест спонсированного выполнения
Функция testSponsoredExecution() проверяет спонсируемое выполнение вызовов спонсором (т. е. Бобом). Она проверяет, что третья сторона (Боб) может выполнить транзакцию от имени Алисы. Мы проверяем, что отправителем является Боб, а не Алиса, и что получатель получил средства.
В этом тесте Алиса подписывает сообщение, позволяющую реализации выполнять транзакции от ее имени. Боб прикрепляет его от имени Алисы и передает эфир.
Затем Алиса подписывает транзакцию, а Боб исполняет ее через временно назначенный контракт Алисы.
И наконец, функция execute() на EOA Алисы вызывается Бобом, а не Алисой.
function testSponsoredExecution() public {
// Arrange the call(s).
calls[0] = BatchCallAndSponsor.Call({to: recipient, value: 1 ether, data: ""});
// Alice signs a delegation allowing `implementation` to execute transactions on her behalf.
Vm.SignedDelegation memory signedDelegation = vm.signDelegation(address(implementation), ALICE_PK);
// Bob attaches the signed delegation from Alice and broadcasts it.
vm.startBroadcast(BOB_PK);
vm.attachDelegation(signedDelegation);
// Prepare the signature for the transaction.
(uint8 v, bytes32 r, bytes32 s) = vm.sign(ALICE_PK, MessageHashUtils.toEthSignedMessageHash(digest));
bytes memory signature = abi.encodePacked(r, s, v);
// Expect the event. The first parameter should be BOB_ADDRESS.
vm.expectEmit(true, true, true, true);
emit BatchCallAndSponsor.CallExecuted(BOB_ADDRESS, calls[0].to, calls[0].value, calls[0].data);
// As Bob, execute the transaction via Alice's temporarily assigned contract.
BatchCallAndSponsor(ALICE_ADDRESS).execute(calls, signature);
vm.stopBroadcast();
assertEq(recipient.balance, 1 ether);
}Неверная подпись
Функция testWrongSignature() проверяет сценарий, в котором подпись неверна.
function testWrongSignature() public {
// Bob attaches the signed delegation from Alice and broadcasts it.
vm.startBroadcast(BOB_PK);
vm.attachDelegation(signedDelegation);
// Sign with the wrong key (Bob's instead of Alice's).
(uint8 v, bytes32 r, bytes32 s) = vm.sign(BOB_PK, MessageHashUtils.toEthSignedMessageHash(digest));
bytes memory signature = abi.encodePacked(r, s, v);
vm.expectRevert("Invalid signature");
BatchCallAndSponsor(ALICE_ADDRESS).execute(calls, signature);
vm.stopBroadcast();
}Тест защиты от воспроизведения
🔥3
Функция testReplayProtection() тестирует механизм защиты от повторного воспроизведения. Она проверяет, откатывается ли исполнение, если одна и та же подпись используется несколько раз.
Далее поговорим о файле скрипта.
#eip7702
function testReplayAttack() public {
// Bob attaches the signed delegation from Alice and broadcasts it.
vm.startBroadcast(BOB_PK);
vm.attachDelegation(signedDelegation);
uint256 nonceBefore = BatchCallAndSponsor(ALICE_ADDRESS).nonce();
bytes32 digest = keccak256(abi.encodePacked(nonceBefore, encodedCalls));
(uint8 v, bytes32 r, bytes32 s) = vm.sign(ALICE_PK, MessageHashUtils.toEthSignedMessageHash(digest));
bytes memory signature = abi.encodePacked(r, s, v);
// First execution: should succeed.
BatchCallAndSponsor(ALICE_ADDRESS).execute(calls, signature);
vm.stopBroadcast();
// Attempt a replay: reusing the same signature should revert because nonce has incremented.
vm.expectRevert("Invalid signature");
BatchCallAndSponsor(ALICE_ADDRESS).execute(calls, signature);
}Далее поговорим о файле скрипта.
#eip7702
🔥3🙏1
Погружение в EIP-7702. Часть 8
Сегодня разберем скрипт деплоя для нашего теста.
Файл BatchCallAndSponsor.s.sol содержит тестовый скрипт для контракта BatchCallAndSponsor. Он делает деплой контракта, минтит токены и тестирует функции пакетного и спонсорского выполнения. Мы будем использовать этот скрипт для развертывания контракта и тестирования его функций в локальной сети.
Для начала запустим локальный блокчейн:
В другом терминале установим зависимости проекта и скомпилируем контракты:
Теперь можно запускать тесты:
В общем, у вас должно получиться следующее:
Теперь можно запустить наш скрипт. Тут мы используем команды:
--broadcast: Транслирует транзакции в вашу локальную сеть.
--rpc-url 127.0.0.1:8545: Подключается к вашей локальной сети.
--tc BatchCallAndSponsorScript: Указывает целевой контракт для сценария.
Может появиться предупреждающее сообщение, подобное следующему:
Это предупреждение ожидаемо, поскольку до применения EIP-7702, у EOA нет кода на блокчейн сети. Просто введите "y", чтобы продолжить.
После завершения работы скрипта вы увидите сообщения журнала, указывающие на то, что выполнение прошло успешно. Транзакции сохраняются в папке broadcast, а все конфиденциальные значения - в папке cache.
Вы можете просмотреть сохраненные транзакции, чтобы узнать больше о том, как выполняются транзакции EIP-7702. Например, в последней транзакции спонсируемого выполнения Боб является отправителем, а адрес контракта принадлежит Алисе. Кроме того, эта транзакция включает в себя список authorizationList, содержащий подписанные авторизации.
#eip7702
Сегодня разберем скрипт деплоя для нашего теста.
Файл BatchCallAndSponsor.s.sol содержит тестовый скрипт для контракта BatchCallAndSponsor. Он делает деплой контракта, минтит токены и тестирует функции пакетного и спонсорского выполнения. Мы будем использовать этот скрипт для развертывания контракта и тестирования его функций в локальной сети.
function run() external {
// Start broadcasting transactions with Alice's private key.
vm.startBroadcast(ALICE_PK);
// Deploy the delegation contract (Alice will delegate calls to this contract).
implementation = new BatchCallAndSponsor();
// Deploy an ERC-20 token contract where Alice is the minter.
token = new MockERC20();
// // Fund accounts
token.mint(ALICE_ADDRESS, 1000e18);
vm.stopBroadcast();
// Perform direct execution
performDirectExecution();
// Perform sponsored execution
performSponsoredExecution();
}Для начала запустим локальный блокчейн:
anvil --hardfork prague
В другом терминале установим зависимости проекта и скомпилируем контракты:
forge install
forge build
Теперь можно запускать тесты:
forge test -vvv
В общем, у вас должно получиться следующее:
Ran 4 tests for test/BatchCallAndSponsor.t.sol:BatchCallAndSponsorTest
[PASS] testDirectExecution() (gas: 128386)
Logs:
Sending 1 ETH from Alice to Bob and transferring 100 tokens to Bob in a single transaction
[PASS] testReplayAttack() (gas: 114337)
Logs:
Test replay attack: Reusing the same signature should revert.
[PASS] testSponsoredExecution() (gas: 110461)
Logs:
Sending 1 ETH from Alice to a random address while the transaction is sponsored by Bob
[PASS] testWrongSignature() (gas: 37077)
Logs:
Test wrong signature: Execution should revert with 'Invalid signature'.
Suite result: ok. 4 passed; 0 failed; 0 skipped;
Теперь можно запустить наш скрипт. Тут мы используем команды:
--broadcast: Транслирует транзакции в вашу локальную сеть.
--rpc-url 127.0.0.1:8545: Подключается к вашей локальной сети.
--tc BatchCallAndSponsorScript: Указывает целевой контракт для сценария.
forge noscript ./noscript/BatchCallAndSponsor.s.sol --tc BatchCallAndSponsorScript --broadcast --rpc-url 127.0.0.1:8545
Может появиться предупреждающее сообщение, подобное следующему:
Warning: Script contains a transaction to 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 which does not contain any code.
Do you wish to continue?
Это предупреждение ожидаемо, поскольку до применения EIP-7702, у EOA нет кода на блокчейн сети. Просто введите "y", чтобы продолжить.
После завершения работы скрипта вы увидите сообщения журнала, указывающие на то, что выполнение прошло успешно. Транзакции сохраняются в папке broadcast, а все конфиденциальные значения - в папке cache.
ONCHAIN EXECUTION COMPLETE & SUCCESSFUL.
Transactions saved to: /project-path/broadcast/...
Sensitive values saved to: /project-path/cache/...
Вы можете просмотреть сохраненные транзакции, чтобы узнать больше о том, как выполняются транзакции EIP-7702. Например, в последней транзакции спонсируемого выполнения Боб является отправителем, а адрес контракта принадлежит Алисе. Кроме того, эта транзакция включает в себя список authorizationList, содержащий подписанные авторизации.
#eip7702
👍6🔥1
Погружение в EIP-7702. Часть 9
Продолжаем разбирать этот необычный стандарт...
Хотя EIP-7702 привносит новую жизнь в экосистему Ethereum, введение новых сценариев применения также несет новые риски. Ниже приведены некоторые аспекты, с которыми участникам экосистемы следует быть осторожными во время практики.
Хранение приватного ключа
Несмотря на то, что EOA (Externally Owned Accounts) могут использовать встроенные в смарт-контракты механизмы социального восстановления для решения проблемы потери активов в результате утраты приватного ключа, они все равно не могут избежать риска самой утечки приватного ключа. Важно отметить, что после делегирования приватный ключ EOA по-прежнему имеет наивысший контроль над счетом; владение приватным ключом дает пользователю возможность свободно распоряжаться активами на аккаунте. Пользователи или поставщики услуг кошелька, завершив делегирование полномочий для EOA, не могут полностью исключить риск утечки закрытого ключа, особенно в случаях, когда возможны атаки на сеть.
Для пользователей защита приватного ключа всегда должна быть приоритетной. Очень важно помнить: Не ваши ключи, не ваши монеты.
Воспроизведение нескольких сетях
Когда пользователи подписывают разрешение на делегирование, они могут выбрать идентификатор сети, на которой будет действовать делегирование. Пользователи также могут выбрать идентификатор сети, равный 0, что позволяет воспроизводить делегирование на нескольких сетях.
Поставщики услуг кошелька должны проверять, соответствует ли блокчейн делегации текущей сети, и предупреждать пользователей о рисках, связанных с ними.
Пользователи также должны знать, что один и тот же адрес контракта в разных сетях не всегда может иметь один и тот же код. Важно понимать детали делегированной цели, прежде чем приступать к работе.
Проблема инициализации
Большинство основных кошельков смарт-контрактов используют прокси-модель, при которой прокси-кошелек вызывает функцию инициализации через DELEGATECALL для достижения атомарной инициализации и развертывания кошелька. Однако в EIP-7702 поле кода адреса будет только обновляться, а функция инициализации не может быть вызвана через делегированный адрес. Это ограничивает возможности EIP-7702 по инициализации кошелька по сравнению с прокси-контрактом ERC-1967, который может вызывать функцию инициализации во время развертывания.
Разработчикам следует обеспечить проверку прав доступа во время инициализации кошелька (например, с помощью ecrecover для проверки адреса подписи), чтобы избежать уязвимостей инициализации.
Управление хранилищем
При использовании делегирования EIP-7702 пользователям может потребоваться повторное делегирование на разные адреса контрактов в связи с изменениями в функциональности или обновлением кошелька. Разные контракты могут иметь разные структуры хранения (например, slot0 может представлять разные типы данных в разных контрактах), и повторное делегирование может привести к повторному использованию старых данных контракта, что приведет к блокировке аккаунта, потере активов и другим проблемам.
Пользователям следует внимательно относиться к ситуациям переделегирования.
Разработчики должны следовать формуле пространства имен, предложенной в ERC-7201, чтобы распределять переменные по определенным независимым местам хранения для уменьшения конфликтов хранения. Кроме того, ERC-7779 (draft) предлагает стандартный процесс повторного делегирования, специфичный для EIP-7702, включая предотвращение конфликтов хранения и проверку совместимости перед повторным делегированием.
Далее посмотрим на еще пару нюансов использования стандарта.
#eip7702
Продолжаем разбирать этот необычный стандарт...
Хотя EIP-7702 привносит новую жизнь в экосистему Ethereum, введение новых сценариев применения также несет новые риски. Ниже приведены некоторые аспекты, с которыми участникам экосистемы следует быть осторожными во время практики.
Хранение приватного ключа
Несмотря на то, что EOA (Externally Owned Accounts) могут использовать встроенные в смарт-контракты механизмы социального восстановления для решения проблемы потери активов в результате утраты приватного ключа, они все равно не могут избежать риска самой утечки приватного ключа. Важно отметить, что после делегирования приватный ключ EOA по-прежнему имеет наивысший контроль над счетом; владение приватным ключом дает пользователю возможность свободно распоряжаться активами на аккаунте. Пользователи или поставщики услуг кошелька, завершив делегирование полномочий для EOA, не могут полностью исключить риск утечки закрытого ключа, особенно в случаях, когда возможны атаки на сеть.
Для пользователей защита приватного ключа всегда должна быть приоритетной. Очень важно помнить: Не ваши ключи, не ваши монеты.
Воспроизведение нескольких сетях
Когда пользователи подписывают разрешение на делегирование, они могут выбрать идентификатор сети, на которой будет действовать делегирование. Пользователи также могут выбрать идентификатор сети, равный 0, что позволяет воспроизводить делегирование на нескольких сетях.
Поставщики услуг кошелька должны проверять, соответствует ли блокчейн делегации текущей сети, и предупреждать пользователей о рисках, связанных с ними.
Пользователи также должны знать, что один и тот же адрес контракта в разных сетях не всегда может иметь один и тот же код. Важно понимать детали делегированной цели, прежде чем приступать к работе.
Проблема инициализации
Большинство основных кошельков смарт-контрактов используют прокси-модель, при которой прокси-кошелек вызывает функцию инициализации через DELEGATECALL для достижения атомарной инициализации и развертывания кошелька. Однако в EIP-7702 поле кода адреса будет только обновляться, а функция инициализации не может быть вызвана через делегированный адрес. Это ограничивает возможности EIP-7702 по инициализации кошелька по сравнению с прокси-контрактом ERC-1967, который может вызывать функцию инициализации во время развертывания.
Разработчикам следует обеспечить проверку прав доступа во время инициализации кошелька (например, с помощью ecrecover для проверки адреса подписи), чтобы избежать уязвимостей инициализации.
Управление хранилищем
При использовании делегирования EIP-7702 пользователям может потребоваться повторное делегирование на разные адреса контрактов в связи с изменениями в функциональности или обновлением кошелька. Разные контракты могут иметь разные структуры хранения (например, slot0 может представлять разные типы данных в разных контрактах), и повторное делегирование может привести к повторному использованию старых данных контракта, что приведет к блокировке аккаунта, потере активов и другим проблемам.
Пользователям следует внимательно относиться к ситуациям переделегирования.
Разработчики должны следовать формуле пространства имен, предложенной в ERC-7201, чтобы распределять переменные по определенным независимым местам хранения для уменьшения конфликтов хранения. Кроме того, ERC-7779 (draft) предлагает стандартный процесс повторного делегирования, специфичный для EIP-7702, включая предотвращение конфликтов хранения и проверку совместимости перед повторным делегированием.
Далее посмотрим на еще пару нюансов использования стандарта.
#eip7702
👍5
Погружение в EIP-7702. Часть 10
И еще несколько нюансов, на которые следует обратить внимание.
Ложное пополнение
После делегирования полномочий EOA также могут выступать в качестве смарт-контрактов, что может привести к тому, что централизованные биржи (CEX) столкнутся с широко распространенными рисками пополнения счета смарт-контрактами.
CEX должны использовать проверку трассировки для мониторинга каждой транзакции пополнения, чтобы снизить риск фальшивых пополнений с помощью смарт-контрактов.
Конвертация аккаунта
С помощью делегирования EIP-7702 аккаунт пользователя может свободно конвертироваться между EOA и смарт-контрактом, что позволяет ему инициировать транзакции и быть вызванным. Это означает, что когда аккаунт вызывает сам себя или совершает внешний вызов, его msg.sender также будет tx.origin, что нарушает предположение о безопасности, согласно которому участвуют только EOA.
Разработчики контрактов не должны предполагать, что tx.origin всегда будет EOA. Аналогично, использование msg.sender == tx.origin в качестве защиты от атак реентранси больше не будет эффективным.
Разработчикам следует предположить, что в процессе разработки все будущие участники могут оказаться смарт-контрактами.
Совместимость с контрактами
Существующие токены ERC-721 и ERC-777 имеют хуковые функции при передаче токенов, то есть получатель должен реализовать соответствующую функцию обратного вызова, чтобы успешно получить токены.
Разработчики должны убедиться, что целевой контракт для делегирования пользователя реализует необходимые функции обратного вызова для обеспечения совместимости с основными токенами.
Фишинговые проверки
После реализации делегирования EIP-7702 активы в аккаунте пользователя могут контролироваться смарт-контрактами. Если пользователь делегирует свой счет вредоносному контракту, злоумышленники могут легко похитить активы.
Поставщики услуг кошельков должны оперативно поддерживать транзакции EIP-7702 и, когда пользователи подписывают делегирование, на видном месте отображать целевой контракт, чтобы снизить риск фишинговых атак.
Кроме того, глубокий автоматизированный анализ (проверка открытых источников, проверка разрешений и т. д.) делегированных целевых контрактов может помочь пользователям избежать подобных рисков.
#eip7702
И еще несколько нюансов, на которые следует обратить внимание.
Ложное пополнение
После делегирования полномочий EOA также могут выступать в качестве смарт-контрактов, что может привести к тому, что централизованные биржи (CEX) столкнутся с широко распространенными рисками пополнения счета смарт-контрактами.
CEX должны использовать проверку трассировки для мониторинга каждой транзакции пополнения, чтобы снизить риск фальшивых пополнений с помощью смарт-контрактов.
Конвертация аккаунта
С помощью делегирования EIP-7702 аккаунт пользователя может свободно конвертироваться между EOA и смарт-контрактом, что позволяет ему инициировать транзакции и быть вызванным. Это означает, что когда аккаунт вызывает сам себя или совершает внешний вызов, его msg.sender также будет tx.origin, что нарушает предположение о безопасности, согласно которому участвуют только EOA.
Разработчики контрактов не должны предполагать, что tx.origin всегда будет EOA. Аналогично, использование msg.sender == tx.origin в качестве защиты от атак реентранси больше не будет эффективным.
Разработчикам следует предположить, что в процессе разработки все будущие участники могут оказаться смарт-контрактами.
Совместимость с контрактами
Существующие токены ERC-721 и ERC-777 имеют хуковые функции при передаче токенов, то есть получатель должен реализовать соответствующую функцию обратного вызова, чтобы успешно получить токены.
Разработчики должны убедиться, что целевой контракт для делегирования пользователя реализует необходимые функции обратного вызова для обеспечения совместимости с основными токенами.
Фишинговые проверки
После реализации делегирования EIP-7702 активы в аккаунте пользователя могут контролироваться смарт-контрактами. Если пользователь делегирует свой счет вредоносному контракту, злоумышленники могут легко похитить активы.
Поставщики услуг кошельков должны оперативно поддерживать транзакции EIP-7702 и, когда пользователи подписывают делегирование, на видном месте отображать целевой контракт, чтобы снизить риск фишинговых атак.
Кроме того, глубокий автоматизированный анализ (проверка открытых источников, проверка разрешений и т. д.) делегированных целевых контрактов может помочь пользователям избежать подобных рисков.
#eip7702
👍6
Проект на виду. Часть 6. Нейронки не доступны
Сегодня хочу отвлечься от темы EIP-7702 и снова поговорить о нейронных сетях, AI, агентах и том, как они будут заменять программистов...
Понемногу каждый день я продолжаю изучать модели, обучение нейронок и как это может быть полезно в моей работе. И с каждым днем я прихожу к мысли, что полноценные нейронные сети одновременно и доступны и недостижимы для простых людей.
Да, мы в любой момент можем зайти в DeepSeek, GTP, Grok - написать хороший промт и получить прекрасный результат. Claude и Gemini все лучше пишут код, и казалось бы от оно счастье...
Пока вы не задумаете попробовать самому выбрать локальную нейронку для своих задач и попробовать обучить ее. Тут начинаются проблемы, а именно загвоздка в мощностях.
Для работы маломальски нормальной нейронки, не обрезанной\облегченной\нишевой, вам потребуется мощная видеокарта уровня 3090, а лучше 4090, и процессор минимум i7. И это будет "в целом ок" для моделей среднего уровня на 13-15 млрд параметров. А более хорошие модели на 32-36 млрд потребуют мощностей куда выше обозначенных. Кроме того, современные модели, например тот же DeepSeek может затянуть на 200 +млрд параметров и вообще запредельных мощностей, которые просто не организовать в домашних условиях.
И, если я правильно понял, то такие мощности требуются только для комфортной работы модели, а для ее переобучения нужно больше...
К чему я веду?
Нейронки (DeepSeek, chatGPT, etc) обучаются на огромных массивах данных, включая все языки, всю документацию, все примеры кода и т.д. Нет четкого фокуса - главное быть лучше и функциональнее конкурента. У разработчиков этих моделей нет задачи сделать их мастерами в React, Solidity или Python. Отсюда у нас идет хороший, но порой "не тот" код.
А дообучить\переобучить нейронку для определенного языка - у обычных пользователей нет ресурсов.
Вот и получается, что сейчас возможен период, когда компании будут формировать свои ресурсы вокруг опенсорсных моделей, нишево дообучать их для определенной цели и продавать доступ по подписке.
В ближайшие лет 5 текущие нейронки выйдут на хороший уровень по коду, но появится много надстроек, которые будут продавать фокусные решения. И пользователи будут платить за модель, которая отлично пишет код Solidity с акцентом на безопасности, чем брать просто хорошие основные сети для "всего".
Вот такой пятничный поток мыслей. А вы что думаете по этому поводу?
#offtop
Сегодня хочу отвлечься от темы EIP-7702 и снова поговорить о нейронных сетях, AI, агентах и том, как они будут заменять программистов...
Понемногу каждый день я продолжаю изучать модели, обучение нейронок и как это может быть полезно в моей работе. И с каждым днем я прихожу к мысли, что полноценные нейронные сети одновременно и доступны и недостижимы для простых людей.
Да, мы в любой момент можем зайти в DeepSeek, GTP, Grok - написать хороший промт и получить прекрасный результат. Claude и Gemini все лучше пишут код, и казалось бы от оно счастье...
Пока вы не задумаете попробовать самому выбрать локальную нейронку для своих задач и попробовать обучить ее. Тут начинаются проблемы, а именно загвоздка в мощностях.
Для работы маломальски нормальной нейронки, не обрезанной\облегченной\нишевой, вам потребуется мощная видеокарта уровня 3090, а лучше 4090, и процессор минимум i7. И это будет "в целом ок" для моделей среднего уровня на 13-15 млрд параметров. А более хорошие модели на 32-36 млрд потребуют мощностей куда выше обозначенных. Кроме того, современные модели, например тот же DeepSeek может затянуть на 200 +млрд параметров и вообще запредельных мощностей, которые просто не организовать в домашних условиях.
И, если я правильно понял, то такие мощности требуются только для комфортной работы модели, а для ее переобучения нужно больше...
К чему я веду?
Нейронки (DeepSeek, chatGPT, etc) обучаются на огромных массивах данных, включая все языки, всю документацию, все примеры кода и т.д. Нет четкого фокуса - главное быть лучше и функциональнее конкурента. У разработчиков этих моделей нет задачи сделать их мастерами в React, Solidity или Python. Отсюда у нас идет хороший, но порой "не тот" код.
А дообучить\переобучить нейронку для определенного языка - у обычных пользователей нет ресурсов.
Вот и получается, что сейчас возможен период, когда компании будут формировать свои ресурсы вокруг опенсорсных моделей, нишево дообучать их для определенной цели и продавать доступ по подписке.
В ближайшие лет 5 текущие нейронки выйдут на хороший уровень по коду, но появится много надстроек, которые будут продавать фокусные решения. И пользователи будут платить за модель, которая отлично пишет код Solidity с акцентом на безопасности, чем брать просто хорошие основные сети для "всего".
Вот такой пятничный поток мыслей. А вы что думаете по этому поводу?
#offtop
❤6🤔3👍2