EIP-3074

Улучшенное и безопасное использование

EIP-3074 позволяет EOA (External Owned Accounts) передавать контроль указанному контракту, тем самым получая те же широкие возможности исполнения, что и контракт. До EIP-3074 EOA мог выполнять только одну операцию на транзакцию, например, утверждение ERC20 или обмен на Uniswap. После EIP-3074 EOA может выполнять несколько операций одновременно или даже выполнять ранее невообразимые задачи. Проще говоря, EIP-3074 значительно улучшает пользовательский опыт, а привычный метод авторизации токенов будет изменен, повышая безопасность без изменения пользовательского опыта.

Более того, благодаря EIP-3074 EOA лонгующий не нужно отправлять транзакции в цепочку самостоятельно, что избавляет от необходимости собирать ETH для оплаты комиссий за транзакции.

Контракт инициатора

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

Содержимое подписи EOA будет четко указывать, какой контракт Invoker (адрес инициатора) и авторизовать операции этого контракта Invoker (коммит)

Фактический процесс выполнения, вероятно, будет выглядеть следующим образом:

1. Алиса подписывается своим закрытым ключом EOA, а затем передает содержимое подписи и подпись Relayer Relayer
2. приводит цепочку к исполнению контракта
3. Invoker Invoker проверяет подпись. После прохождения проверки он может выполнять операции в качестве EOA, такие как одобрение USDC, затем переход в Uniswap на биржу и, наконец, перевод USDC в Relayer в качестве платы за обработку.

Примечание 1: Ретранслятор не требуется. Алиса также может принести в цепочку свой фирменный контент и печать.

После того, как Invoker проверит подпись и начнет выполнять операцию, она будет выполнена как Alice EOA, что похоже на получение (ограниченного) контроля над EOA.

Однако следует отметить, что nonce значение EOA не будет увеличено после выполнения, поэтому одна и та же подпись может быть использована повторно (так лонг nonce EOA остается неизменной), поэтому Invoker должен реализовать свой собственный механизм nonce, чтобы избежать повторного воспроизведения.

Если контракт Invoker не защищен от повторного воспроизведения, одна и та же авторизация может выполняться постоянно.

Для ознакомления с фактическим механизмом работы EIP-3074, пожалуйста, обратитесь к разделу: Введение в EIP3074

application

Batchcall

Позволяет пользователям объединять выполнение нескольких транзакций в одну, экономя на процессе нескольких авторизованных подписей и некоторых затратах на газ.

Примечание: Это потребует от dApp также поддержку функции Batchcall, такой как EIP-5792, которая в настоящее время продвигается сообществом. В противном случае dApp будет предлагать пользователю подписать подпись только один раз для каждой операции, если он рассматривает пользователя как обычного EOA.

Ключ сеанса

Пользователи также могут разрешить третьему лицу действовать от их имени при определенных условиях. Ключ делегата на схеме ниже — это авторизованная третья сторона; политика доступа — это ограничение выполнения, например, ограничение только для работы с Uniswap, перевод максимум 1 ETH в день, срок действия авторизации и т. д. Эти условия разрабатываются и проверяются в рамках контракта Invoker. После лонг прохождения проверки третья сторона может выполнять операции в качестве EOA пользователя.

Telegram-боту могут быть предоставлены определенные разрешения на выполнение операций от имени EOA пользователя

Native ETH Permit

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

Лимитный ордер

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

Когда Алиса выполнит ордер, она одновременно выполнит утверждение, устраняя необходимость в предварительном утверждении.

Если условие задумано как более общее, оно станет похожим на контракт Intent: по мере лонг выполнение условий, указанных пользователем, любой может выполнить намерение от имени своего EOA.

Если лонг условие Intent выполнено, любой может инициировать выполнение от имени EOA пользователя

Социальное восстановление

Когда пользователь теряет закрытый ключ EOA, он (Алиса) может использовать авторизацию EIP-3074, которую она подписала, вместе с подписями своего уполномоченного лица (мужа и доверительного агента) для передачи всех активов EOA. На самом деле взыскиваются (передаваемые) активы, а не контроль над счетами. После того, как закрытый ключ EOA утерян, EOA не может быть использован в лонгующий период.

Когда пользователь теряет закрытый ключ EOA, другие уполномоченные лица могут подписать и авторизовать передачу активов EOA.

Влияние EIP-3074

Улучшение методов авторизации маркеров и потенциальная замена утверждения/разрешения?

В настоящее время dApps разрабатываются исходя из предположения, что пользователь является EOA: пользователь должен «предварительно одобрить» и «одобрить достаточную сумму денег» для контракта dApp. Это означает, что пользователям не нужно постоянно оставаться в сети, ждать, пока dApp выполнится, или постоянно повторно одобрять, что значительно улучшает пользовательский опыт. Для приложений, запускаемых условиями, таких как лимитные ордера или DCA, пользователи могут не быть в сети, когда условия выполнены, поэтому им необходимо предварительно одобрить достаточно большую сумму денег для выполнения контракта dApp, и это может быть повторяющимся процессом.

Пользователь должен заранее одобрить достаточно большую сумму для dApp, чтобы dApp мог работать со своими деньгами.

Но также необходимо доверять dApp или избегать одобрения поддельного dApp, и иметь возможность немедленно удалить одобрение

Режимы разрешений, появившиеся позже, такие как нативный токен EIP-2612 или ненативный Permit2, призваны улучшить опыт использования и безопасность режима одобрения: пользователям не нужно лонгующий одобрять большую сумму денег для каждого контракта dApp (и каждый токен должен быть одобрен один раз). Вместо этого пользователю нужно только «подписать имя», чтобы авторизовать контракт dApp на «вывод указанной суммы» в течение «указанного времени». Это не только значительно сокращает поверхность атаки, но и значительно улучшает пользовательский опыт.

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

Но на самом деле режим разрешения часто использовался в качестве метода мошеннической атаки (1,2,3): жертвы по ошибке подписывали то, что они считали разрешением на dApp, но на самом деле было передано злоумышленнику.

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

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

Тем не менее, EIP-3074 дает возможность для изменений: когда разработчики dApp знают, что EOA может выполнять различные сложные операции через Invoker, дизайн взаимодействия с dApp не лонгующий должен жертвовать безопасностью в ордер для улучшения пользовательского опыта, например, «пользователи предварительно одобряют большую сумму денег» и «пользователи подписывают сообщение о разрешении на вывод средств». Вместо этого пользователи связывают операции dApp для утверждения и выполнения атомарного выполнения через Invoker: либо операции approve и dApp успешно выполняются вместе, либо они завершаются сбоем вместе. Вероятность успешного утверждения сама по себе невозможна, поэтому пользователи могут быть уверены в том, что это утверждение предназначено для данной операции. Кроме того, пользователи используют авторизацию подписей вне блокчейна, поэтому пользовательский опыт такой же, как и при разрешении! Это означает, что dApp лонгующий не будет нуждаться в режиме разрешения! В будущем кошельки могут напрямую запрещать или проводить более строгие проверки запросов на подпись разрешений, не беспокоясь о том, что это приведет к тому, что пользователи не будут использовать некоторые децентрализованные приложения (но, в свою очередь, будут использоваться для мошенничества).

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

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

Как Кошелек обрабатывает одноразовые номера EOA

Текущий дизайн EIP-3074 будет включать значение nonce EOA в содержимое подписи, так лонг, как EOA отправит транзакцию в цепочку для выполнения и изменит значение nonce, все первоначальные авторизации EIP-3074 будут недействительными.

Если пользователь разрешает кому-то другому управлять EOA, например, с помощью ключа сеанса или метода Social Recovery, упомянутого выше, изменение nonce EOA должно быть предотвращено. В противном случае необходимо заново подписывать все разрешения и передавать их доверенному лицу, что оказывает значительное влияние на пользовательский опыт и надежность механизма.

Если пользователь авторизован для самостоятельной работы, нет необходимости специально препятствовать изменению nonce EOA, поскольку подпись EIP-3074 по-прежнему должна быть выполнена до определенного срока, как и транзакция. Просто кошельку нужно управлять большим количеством транзакций EIP-3074 EOA: если есть подписи EIP-3074, ожидающие загрузки в цепочку, то транзакции самого EOA придется подождать.

Примечание: Сам контракт Invoker будет (и должен) поддерживать набор механизмов nonce, поэтому после использования подписи его все равно нужно будет подписать снова, независимо от того, изменится ли EOA nonce.

Session Key и Social Recovery, скорее всего, придется подождать, пока EIP-3074 не изменит правила, чтобы удалить nonce EOA из содержимого подписи, прежде чем они могут быть приняты в больших масштабах. Таким образом, кошельку нужно сосредоточиться только на варианте использования «авторизованных пользователем операций» и рассматривать подпись EIP-3074 как транзакцию. Нет необходимости беспокоиться о том, чтобы избежать отправки транзакций EOA или изменить nonce EOA.

Однако следует отметить, что если пользователь захочет привнести в цепочку свой собственный контент подписи EIP-3074, будет два недостатка:

1. Пользователю необходимо подписать дважды: один раз для подписи EIP-3074 и один раз для подписи транзакции в блокчейне.
2. Поскольку в блокчейне транзакция добавит 1 к nonce EOA до начала выполнения транзакции, nonce EOA в подписи EIP-3074 пользователя необходимо предварительно добавить 1, чтобы соответствовать nonce EOA +1, вызванному самой цепочкой.

Поскольку цепочка сначала добавит 1 к nonce EOA, проверка подписи EIP-3074 завершится ошибкой из-за несоответствия nonce EOA.

Если пользователи добавят 1 к nonce EOA в подписи EIP-3074 перед тем, как добавить его в цепочку, проверка может пройти гладко.

Итоги и основные моменты

• EIP-3074 позволяет EOA получить те же богатые возможности исполнения, что и контракты, открывая множество новых сценариев применения.
• Это не только значительно улучшит пользовательский опыт, но и изменит текущий метод авторизации токенов, сделав его более безопасным при сохранении того же пользовательского опыта.
• Более того, EIP-3074 — это простая подпись, и пользователям не обязательно вносить подпись в цепочку для выполнения, поэтому нет необходимости беспокоиться о сборе ETH для оплаты комиссий за транзакции.
• Использование EIP-3074 включает пакетный вызов, ключ сеанса, собственное разрешение ETH, лимитный ордер и социальное восстановление. Многие из них ранее были невозможны для EOA, а некоторые, такие как лимитный ордер, требовали использования небезопасных методов предварительной авторизации.
• EIP-3074 также изменит текущий метод авторизации токенов. Метод approve напрямую разрешает определенному адресу иметь право выводить токены на неограниченный срок, и он требует, чтобы EOA пользователя отправлял транзакцию для выполнения утверждения, поэтому пользовательский опыт и безопасность не являются хорошими; Метод разрешения требует, чтобы пользователь только подписывал, и в каждой подписи будет указана сумма и срок действия, что значительно улучшает взаимодействие с пользователем и безопасность по сравнению с утверждением.
• Тем не менее, разрешение по-прежнему часто используется в мошеннических целях. При подписании пользователи могут только знать, кому авторизоваться, сколько и срок действия, но они не знают, для чего эта авторизация. «Для чего это нужно» будет еще одной подписью (или транзакцией). Обычные dApps позволяют пользователям подписывать разрешение и «для чего оно нужно», но это все равно будут две разные подписи, поэтому, когда пользователя просят подписать разрешение, ни пользователь, ни кошелек не могут знать, для чего это разрешение будет использоваться.
• С EIP-3074 пользователям (1) не нужно заранее одобрять большую сумму денег в dApp, а нужно одобрять только тогда, когда есть операция, которая имеет тот же эффект, что и разрешение; (2) это просто простая подпись, и вам не нужно беспокоиться о сборе ETH для оплаты комиссии за транзакцию, которая такая же, как и разрешение; (3) Каждое одобрение привязано к конкретной операции и подписано вместе, поэтому пользователи могут четко знать, для чего это одобрение, что будет безопаснее, чем разрешение!
• Есть надежда, что EIP-3074 сможет успешно заменить текущие режимы утверждения и разрешения и предоставить пользователям более безопасный метод авторизации.

Отказ от ответственности:

1. Эта статья перепечатана из [imToken Labs]. Все авторские права принадлежат первоначальному автору [Nothing]. Если у вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они оперативно разберутся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются какими-либо инвестиционными рекомендациями.
3. Переводом статьи на другие языки занимается команда Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.