Автор оригинала: Yuxing, SevenX Ventures
Первоисточник: Новости Форсайта
Краткое содержание:
Будущая модель кошелька, скорее всего, будет похожа на модель B2B2C. Хотя кошелек существует как продукт C-конца, более важно предоставить зрелое решение SDK для других приложений, которые будут интегрированы в кошельки внутри приложений и затем ориентированы на пользователей C-конца. Среди них упаковщики и агрегаторы на первых порах в основном создавались централизованно. Однако позже можно сформировать модульную сеть. Однако, поскольку эта часть является ядром сбора стоимости, кошельки, использующие пакерные сети, созданные другими, должны уйти. через игру экономической выгоды.
По мере постоянного расширения и расширения сценариев применения Ethereum постепенно выявляются недостатки традиционного решения для внешних учетных записей (EOA) кошелька Ethereum. Его функции просты, а производительность средняя. Оно не поддерживает одновременные транзакции и имеет проблемы с управлением ключами. . проблема. Кошельки со смарт-контрактами используют контрактные учетные записи (CA) в качестве адресов кошельков. Это относительно новое решение для кошельков Ethereum, которое может решить недостатки кошельков EOA и предоставить более мощные функции. В будущем вы сможете отказаться от тщательной защиты своих закрытых ключей и наслаждаться почти тем же уровнем безопасности. Вы также сможете пользоваться удобством текущих централизованных бирж на децентрализованных биржах, но в то же время средства всегда будут доступны; в ваших руках, поэтому вам не придется беспокоиться о возможности грозы на бирже...
В новой версии дорожной карты Ethereum, выпущенной некоторое время назад, спецификация смарт-контракта абстракции учетной записи ERC-4337 была записана в The Splurge в качестве ключевого элемента для перехода кошельков EOA на кошельки со смарт-контрактами. Итак, что же такое смарт-контрактный кошелек и какова связь между абстракцией учетной записи и смарт-контрактными кошельками, как они реализованы, какова его будущая форма развития, каковы возможности и проблемы?
Типы учетных записей Ethereum
В Ethereum есть два типа учетных записей: внешние учетные записи (EOA) и контрактные учетные записи (CA). Внешняя учетная запись — это адрес учетной записи кошелька, который Ethereum изначально записывает балансы пользователей. Контрактная учетная запись изначально не была предназначена для записи баланса адреса кошелька пользователя.
внешний аккаунт
EOA — это концепция, уникальная для Ethereum и других EVM-совместимых цепочек (или EVM-подобных цепочек). Строго говоря, основные цепи, не относящиеся к EVM, включая BTC, не имеют этой настройки. Кошелек Metamask использует внешние учетные записи. Этот тип кошелька также называется «кошельком EOA» и управляется закрытым ключом пользователя. Правила его создания:
Закрытый ключ → Открытый ключ → хеш Keccak256 → Последние 20 байт → Шестнадцатеричная строка (адрес EOA)
Это правило генерации полностью получено в результате математического преобразования, и этот адрес не соответствует никакому смарт-контракту. При использовании этого типа адреса для транзакций правила проверки узла следующие:
Подпись транзакции → ec_recover → Открытый ключ → (сгенерированный с использованием вышеуказанных правил) адрес → Сравните адрес, который будет использоваться.
Если проверка пройдена, продолжайте последующий процесс, иначе транзакция будет отклонена. Основная настройка EOA в Ethereum — действовать в качестве инициатора транзакции и платить газ, то есть триггера транзакции. Независимо от того, сколько вызовов контракта следует за транзакцией, она должна быть инициирована EOA в начале и в дальнейшем. достаточно газа должно быть оплачено. Процесс транзакции адреса EOA показан на рисунке ниже.
Упрощенный механизм транзакций EOA Источник: Nethermind
Проблемы с внешним аккаунтом
В настоящее время учетные записи EOA являются наиболее распространенным типом кошельков, используемым пользователями. Сообщество Ethereum выразило некоторую обеспокоенность по поводу EOA, в том числе:
Управление ключами: единственный способ получить средства — это знать закрытый ключ. Самая большая проблема — это единственная точка отказа. Для пользователей закрытый ключ является активом. Для пользователей потеря или кража закрытого ключа означает потерю активов.
Положитесь на подписи ECDSA. Более простые и устойчивые к квантовым суммам подписи являются явным улучшением по сравнению с существующей ECDSA.
Транзакции соответствуют операциям: невозможность выполнять несколько операций одновременно приводит к ненужным затратам и ухудшению пользовательского опыта.
Благодаря постоянному расширению сценариев применения блокчейна пользователи управляют не только своими собственными активами в цепочке блоков, но также личными данными, социальными отношениями и даже кредитами в цепочке и т. д. В настоящее время большая часть этого контента просто сопоставляется псевдоанонимным лицам через кошельки. Не только пользователи сталкиваются с проблемами управления личными ключами кошелька EOA на основе мнемоники, но и приложения во многих приложениях из-за простоты кошельков EOA. Сцена ограничена.
Существует множество решений для кошельков, которые пытаются решить эти проблемы:
Кошельки MPC обеспечивают лучшее решение для управления закрытыми ключами, используя схему пороговой подписи (TSS), в то время как кошельки со смарт-контрактами могут решить эту проблему с помощью социального восстановления, мультиподписи и других решений.
Лучшее взаимодействие с пользователем, более мощные функции и масштабируемость, такие как пакетные транзакции, настраиваемая логика проверки и т. д., в основном обеспечиваются кошельками со смарт-контрактами.
Кошельки MPC и кошельки смарт-контрактов не являются полностью независимыми решениями. Кошельки смарт-контрактов также могут использовать технологию MPC+TSS для управления кошельками смарт-контрактов. Хорошим примером является Unipass.
Примечание. Кошелек MPC — это кошелек, в котором используется технология многосторонних безопасных вычислений. Это эквивалентно найму M управляющих для вашего хранилища активов. Каждый управляющий не может открыть хранилище самостоятельно, а использование схемы пороговой подписи (TSS) эквивалентно предоставлению. Ваше хранилище настроено с замком, для открытия которого требуется N ключей. Тогда решение кошелька MPC + TSS эквивалентно предоставлению многоролевого решения по управлению хранилищем. N управляющих из числа M должны одновременно предоставить ключи, которыми они управляют. время. Возможность открывать хранилища.
Контрактный счет
CA — это учетная запись Ethereum с внутренней логикой, которая может быть либо бизнес-логикой (контракт токена используется для учета, контракт залога используется для кредитования и ликвидации), либо логикой учетной записи (например, логикой мультиподписи gnosis Safe), и последняя Это кошелек/счет смарт-контракта (SCW). Кошелек Argent использует кошелек со смарт-контрактом, который стал пионером модели социального восстановления. Контракт управляется внутренним логическим кодом, а его правила генерации включают CREATE и CREATE2, которые здесь не обсуждаются.
В отличие от EOA, между CA и открытым ключом нет обязательного соответствия. Например, центр сертификации, созданный gnosis Safe, может установить любое количество открытых ключей для разблокировки активов, соответствующих его адресу, конечно, центр сертификации также не может устанавливать какие-либо ключи, но логика других центров сертификации определяет, можно ли его разблокировать; например, DeFi. С помощью кредитного договора вы можете вернуть заложенные активы, если вернете деньги.
Все активы в Ethereum, кроме ETH, принадлежат CA, а бизнес-логика, такая как DeFi, реализуется CA. Однако тот факт, что ЦА не может активно работать и платить за газ, также ограничивает ее возможности. Еще в 2016 году было предложение разрешить ЦА платить за газ самостоятельно.
Источник транзакции кошелька смарт-контракта: Nethermind
Поскольку транзакции могут начинаться только с EOA, для улучшения пользовательского опыта кошельки со смарт-контрактами обычно предоставляют услуги ретрансляции для получения подписанных сообщений от пользователей и отправки EOA от поставщика услуг в цепочку. Его специальный механизм комиссий может возвращать ETH пользователю. Кошелек EOA не взимает комиссию за газ.
В настоящее время не существует рабочего стандарта для кошельков со смарт-контрактами (ожидается, что EIP-4337 станет стандартом), поэтому каждый проект должен использовать решение для метатранзакций, такое как сеть заправочных станций Ethereum (GSN), или работать над созданием и управлением вашими владеть ретрансляционными службами, а также управлять механизмами комиссий и проверять свои сложные смарт-контракты.
Смарт-контрактный кошелек
Как следует из названия, смарт-контрактный кошелек/аккаунт (SCW) — это решение для кошелька, которое использует CA в качестве адреса. Он характеризуется внутренней логикой. Кошельки со смарт-контрактами могут реализовывать множество функций, которые не может реализовать EOA, например, оплата газа, пакетные транзакции. , несколько подписей, управление правами, автономная авторизация, социальное восстановление и многое другое.
Учетная запись контракта представляет собой смарт-контракт, отдельный от подписывающего лица (авторизатора) и может иметь собственную логику подписи и восстановления. Это означает, что если вы потеряете доступ к Signer, это не обязательно означает, что вы потеряете доступ к своей учетной записи. Опять же, отсюда и произошло название «Абстракция учетной записи». Счета абстрагируются от подписантов.
Абстракция аккаунта
Текущий статус Ethereum таков, что подавляющее большинство людей используют кошельки EOA, поскольку в настоящее время все транзакции в Ethereum должны начинаться с EOA, а EOA должно иметь некоторое количество ETH для оплаты газа, что делает невозможным быстрый вход новых пользователей. Нам нужно решение, которое позволит пользователям использовать кошельки со смарт-контрактами, которые содержат произвольную логику проверки. Это решение называется Account Abstract (AA). Проще говоря, результат абстракции учетной записи:
Раньше вы хранили деньги на адресе кошелька Ethereum EOA. Несмотря на различные ограничения на адрес EOA, вы также наслаждались простотой и удобством владения активами с помощью закрытого ключа;
Теперь, когда вы храните деньги на адресе смарт-контракта Ethereum, вы можете контролировать активы своего кошелька, не управляя закрытыми ключами. Разделение подписывающей стороны и самой учетной записи позволяет выполнять операции транзакции на более низком уровне безопасности. Сама учетная запись размещается. на более высоком уровне безопасности.
Цель «Абстракции учетных записей» — сократить количество типов учетных записей с 2 (EOA и контракт) до 1 (только контракт) и переместить такие функции, как проверка подписи, оплата газа и защита от повторных атак, из основного протокола в основной протокол. ЭВМ. Реализация абстракции учетных записей всегда была целью многих разработчиков Ethereum, как видно из истории EIP.
История ЭИП
Концепция абстракции аккаунтов была впервые предложена Виталиком в 2016 году, а первое предложение он инициировал в 2017 году. За прошедшие годы появилось множество предложений, связанных с абстракцией учетных записей, наиболее важными из которых являются EIP-3074 и EIP-4337. EIP-3074 был предложен на год раньше, чем EIP-4337, но EIP-4337 был включен в новую версию дорожной карты Ethereum. Основная причина заключается в том, что реализация EIP-4337 должна быть более легкой и не требует изменений. ядро протокола Ethereum, и нет никаких угроз безопасности, таких как EIP-3074. Проблемы миграции пользователей, проблемы с чрезмерным газом и потенциальные проблемы безопасности смарт-контрактов в EIP-4337 являются общими проблемами для кошельков смарт-контрактов. Виталик считает, что лучший реалистичный способ абстракции учетных записей — начать активно поддерживать ERC-4337 в краткосрочной перспективе. а затем, когда со временем был добавлен EIP, чтобы компенсировать его недостатки.
Абстрактная история EIP аккаунта
EIP-86: В 2017 году Виталик предложил EIP-86, пытаясь представить кошелек смарт-контракта, который можно рассматривать как «переадресационный контракт». Эти контракты на пересылку будут принимать транзакции только с адреса «точки входа», с которого каждый может отправлять транзакции, если они соответствуют определенному формату.
EIP-1014: Эти контракты пересылки будут развернуты по определенному адресу на основе их кода, что представляет собой идею, которая позже развилась в EIP-1014, предлагая код операции CREATE2. Поскольку EIP-86 потребовал значительных изменений в протоколе, он в конечном итоге не был объединен, а EIP-1014 был объединен в 2018 году.
EIP-2938: В сентябре 2020 года Виталик Бутерин, Ансгар Дитрихс и Мэтт Гарнетт предложили EIP-2938, который требует, чтобы специальные смарт-контракты, идентифицированные как кошельки смарт-контрактов, принимали только абстрактные транзакции учетной записи. Этот новый тип транзакций поддерживается EIP-2938. 2718 введено. Они будут программно устанавливать максимальный газ для транзакций и реализовывать произвольные методы проверки. EIP-2938 Чтобы сделать транзакции возможными, в EVM необходимо добавить два новых кода операции. Эти коды операций существенно меняют основной протокол, и процесс внесения таких изменений может быть длительным.
EIP-3074: В октябре 2020 года Ансгар Дитрихс, Мэтт Гарнетт и другие предложили EIP-3074, в котором были представлены два новых кода операции: AUTH и AUTHCALL. При совместном использовании они позволяют смарт-контрактам отправлять транзакции от имени EOA, делая возможными, например, мультиподписи, пакетные и спонсируемые транзакции, восстановление ключей и более доступные обменные депозиты CeFi. Однако этот EIP имел некоторые риски для безопасности и подвергся некоторой критике. Новый код операции также изменил основной протокол. Исследователи начали думать о лучшем решении, которое в конечном итоге было предложено как EIP-4337.
Источник процесса транзакции EIP-3074: Nethermind
Уровень 2: Впоследствии, поскольку L2 не имеет технического долга Ethereum L1, абстракция учетной записи может быть введена «из коробки». И Optimism, и Starknet имеют свои собственные реализации абстракции учетной записи ArgentX — это версия кошелька Argent в Starknet, основанная на EIP-4337. Реализация абстракции пользовательской учетной записи. Недавний пример — автоматические платежи Visa Crypto в StarkNet. Решение Visa для автоматизированных платежей Ethereum использует концепцию абстракции учетной записи и создает новый тип контракта учетной записи — делегированную учетную запись. Основная идея состоит в том, чтобы расширить программируемые правила действительности транзакций до включения. предварительно утвержденные списки разрешений. Проще говоря, абстракция учетной записи может делегировать автоматические платежные операции, инициированные учетными записями пользователей, предварительно утвержденным смарт-контрактам автоматических платежей. Модель учетной записи StarkNet — это то, что Visa в настоящее время называет абстракцией учетной записи. Ее реализация основана на ERC-4337, и абстрактная учетная запись проверяет, пришла ли транзакция с заданного адреса.
Visa реализует абстракцию учетных записей в StarkNet
EIP-4337: В сентябре 2021 года Виталик Бутерин и исследователи Ethereum из OpenGSN и Nethermind извлекли уроки из предыдущих усилий и предложили EIP-4337. EIP-4337 добавляет новый мемпул UserOperation в надежде полностью заменить текущий мемпул транзакций, позволяя абстрагировать учетные записи. Пользователи отправляют объекты UserOperation на узлы Ethereum и вместо транзакций упаковывают набор этих объектов в транзакцию, которая включается в цепочку Ethereum. Эта упакованная транзакция называется смарт-контрактом «точки входа», который обрабатывает объект UserOperation и развертывает для него кошелек смарт-контракта.
Источник процесса транзакции ERC-4337: Nethermind
EIP-5003: в марте 2022 года Дэн Финли и Сэм Уилсон предложили EIP-5003, позволяющий перейти от ECDSA путем развертывания кода вместо внешних учетных записей. В этом EIP представлен новый код операции, который развертывает код по адресу авторизации EIP-3074 AUTHUSURP. Для внешних учетных записей (EOA) вместе с EIP-3607 это фактически отменяет разрешения исходного ключа подписи. Это дополнение к EIP-3074, который может только предоставлять дополнительные разрешения участникам, но не может их отозвать.
EIP-5792: В октябре 2022 года компания Moody Salem предложила EIP-5792, который добавляет метод JSON-RPC для отправки нескольких вызовов функций из пользовательского кошелька и проверки его статуса. Новый подход является более абстрактным с точки зрения базовых транзакций, чем существующий API отправки транзакций, что позволяет учитывать различия между реализациями кошельков, такими как кошельки со смарт-контрактами, использующие EIP-4337, или кошельки EOA, поддерживающие объединенные транзакции через EIP-3074. Децентрализованные приложения могут использовать этот более абстрактный интерфейс для поддержки различных типов кошельков без дополнительной работы и обеспечения лучшего взаимодействия с пользователем при отправке пакетов вызовов функций (например, EIP-20#approveс последующим вызовом контракта).
Подробное объяснение EIP-4337
В EIP-4337 всего 6 компонентов: контракт EntryPoint, контракт Paymaster, UserOperation, Bundler, контракт отправителя и агрегатор (Aggregator).
EntryPoint: контракт точки входа управляет выполнением и проверкой переданных ему транзакционных операций. Контракт глобальной точки входа получает упакованные транзакции от различных бандлеров и запускает циклы проверки и выполнения через каждую пользовательскую операцию.
Paymaster: это необязательный контракт, по которому можно оплачивать газ за транзакции от имени пользователя. Вместо того, чтобы полагаться на свои кошельки, пользователи получают комиссию за транзакцию, спонсируемую кассиром.
UserOperations: это объекты транзакций, созданные для выполнения транзакций от имени пользователей. Исполнение происходит после подтверждения контракта отправителя. Эти действия генерируются Dapps.
Bundlers: Bundler получает UserOperations из пула памяти и объединяет их вместе, чтобы отправить их в контракт EntryPoint для выполнения.
Контракт отправителя: это учетные записи кошельков пользователей в форме смарт-контрактов.
Агрегатор: Агрегатор — это вспомогательный контракт, которому доверяет кошелек и который используется для проверки совокупных подписей.
Рабочая логика всего стандарта ERC-4337 состоит из двух циклов: цикла проверки и цикла выполнения, которые объединяются для завершения логики абстракции учетной записи.
Цикл проверки: контракт точки входа проходит через каждую пользовательскую операцию и вызывает «функцию проверки» в контракте отправителя. Контракт отправителя запускает эту функцию, чтобы проверить подпись UserOperation и выплатить компенсацию связывателю, который упаковал эти транзакции.
Цикл выполнения: отправьте данные вызова в каждой пользовательской операции в контракт отправителя. Кошелек запускает операцию выполнения для выполнения транзакций, указанных в операции. Контракт отправителя затем вернет оставшийся газ после выполнения операции.
Цикл проверки и цикл выполнения. Источник: EIP-4337.
Введенная роль кассира позволяет разработчикам приложений субсидировать сборы для своих пользователей. Когда paymaster не равен нулевому адресу, точка входа выполняет другой процесс:
Представляем цикл проверки и цикл выполнения для кассиров. Источник: EIP-4337.
В цикле проверки, помимо вызова «функции проверки», контракт точки входа также должен проверить, заложен ли платежный мастер и достаточно ли ETH хранится в контракте точки входа для оплаты комиссии за операцию, а затем вызвать «проверку» function» на кассире, чтобы проверить, готов ли кассир платить.
В цикле исполнения контракт точки входа должен вызвать пост-операцию на paymaster после основного вызова исполнения. Он должен гарантировать выполнение Post-op, выполняя основное выполнение во внутренней вызывающей среде, и если внутренняя вызывающая среда откатывается, попытаться снова вызвать Post-op во внешней вызывающей среде (газ должен быть оплачен, даже если пользовательская операция откатывает стоимость).
Виталик пришел к выводу, что ERC-4337 может многое сделать как чисто добровольный ERC. Однако в некоторых ключевых областях оно слабее истинного внутрипротокольного решения:
Проблема миграции пользователей: существующие пользователи не могут выполнить обновление без перемещения всех своих активов и действий в новые учетные записи;
Дополнительные накладные расходы на газ (~42 тыс. для базовой UserOperation и ~21 тыс. для базовой транзакции);
Проблемы безопасности смарт-контрактов, которые меньше выигрывают от методов, устойчивых к внутрипротокольной цензуре (таких как crLists), которые нацелены на транзакции и игнорируют операции пользователя.
Реалистичный путь к достижению оптимальных результатов — начать активно поддерживать ERC-4337 в краткосрочной перспективе, а затем со временем добавлять EIP для устранения его недостатков. Это не обязательно требует конкретного обязательства соблюдать ERC-4337. Вместо этого внутрипротокольная поддержка могла бы быть более общей и поддерживать ERC-4337, а также его альтернативы и улучшения. Текущие решения по реализации ERC-4337 включают Biconomy, Soul Wallet и eth-infinitiism. Все они написали свои собственные решения по реализации контракта точки входа, и контракт точки входа является основой безопасности смарт-контракта в соответствии с этим стандартом.
Виталик предложил возможный план абстракции аккаунтов.
Возможная дорожная карта
короткий срок
Запуск ERC-4337 в полномасштабное производство. В идеале это можно было бы расширить, используя возможности агрегирования сигнатур для достижения удобства объединения.
Должны быть простые в использовании браузерные кошельки, совместимые с ERC-4337.
Рассмотрите возможность реализации агрегации и сжатия сигнатур, чтобы сделать ERC-4337 более дружественным к L2;
Направляйте экосистему ERC-4337 в протокол L2, где проблем со стоимостью газа будет меньше;
Средняя степень
Внедрить дерево Веркле, добавить EIP для снижения стоимости газа;
Добавьте дополнительное преобразование EOA в ERC-4337;
Добавьте логику crList одновременно или вскоре после запуска разделения предложений и разработчиков (PBS);
длинный
Рассмотрите возможность принудительного перехода, выполнения нерегулярных переходов состояний, развертывания байт-кода для каждой учетной записи, которая может быть EOA, но недостатками этого подхода являются необходимость изменения основного протокола и высокие затраты для майнеров/валидаторов.
Скан проекта
SevenX просто просканировал кошельки со смарт-контрактами, представленные на рынке, и собрал некоторые из наиболее популярных проектов кошельков со смарт-контрактами, представленных на рынке. Общая ситуация выглядит следующим образом:
Мы выбрали два проекта для ознакомления, проанализировали их функции и соответствующие принципы реализации. Среди них Unipass является типичным представителем традиционных кошельков со смарт-контрактами, а Candide Wallet — типичным представителем кошельков, использующих стандарт ERC-4337. У них есть богатые общедоступные документы, которые подробно объясняют реализацию функций их продукта.
Вариант реализации — Unipass
UniPass Wallet — это смарт-контрактный кошелек, который поддерживает социальное восстановление электронной почты. С помощью UniPass Wallet разработчики могут обеспечить удобство использования продукта без приватных ключей и газа, тем самым быстро привлекая большое количество пользователей Web2. Его функции: отсутствие личных ключей, устойчивость к цензуре, отсутствие газа, восстановление электронной почты, защита конфиденциальности, поддержка нескольких платформ и нескольких цепочек.
Функции отсутствия личных ключей, устойчивости к цензуре, восстановления электронной почты и защиты конфиденциальности в основном обеспечиваются решением Unipass для управления ключами. Контрактная учетная запись UniPass Wallet позволяет пользователям устанавливать несколько типов ключей. К уже поддерживаемым типам ключей относятся:
Мы часто используем внешние адреса для учетных записей контрактов, поддерживающих протокол EIP-1271 (стандартный метод проверки подписи контрактов).
Пользователи UniPass также могут использовать свой адрес электронной почты в качестве ключа. Смарт-контракты, которые мы развертываем в цепочке, могут криптографически проверять право собственности пользователя на почтовый ящик в Интернете через DKIM (почта, идентифицированная ключом доменного имени). В процессе проверки UniPass использует технологию доказательства с нулевым разглашением, чтобы обеспечить конфиденциальность и безопасность информации электронной почты пользователя.
В будущем UniPass Wallet также рассмотрит возможность поддержки более эффективных и простых алгоритмов подписи, чем secp256k1 (таких как Schnorr, BLS), алгоритмов постквантовой безопасной подписи (таких как Lamport, Winternitz) и т. д.
Секретные ключи выполняют три основные роли:
Владелец — владелец аккаунта. Владелец контролирует развертывание, обновление, уничтожение и другие основные функции учетной записи и является высшим контролером учетной записи.
Оператор является исполнителем активов счета. Оператор отвечает за передачу активов учетной записи, вызов контрактов, авторизацию и другие функции и является ключом, используемым пользователями каждый день.
Guardian – хранитель аккаунта. Когда ключ в учетной записи поврежден или утерян и пользователь теряет контроль над учетной записью, для восстановления учетной записи можно использовать Guardian. Основная функция, предоставляемая UniPass, — это социальное восстановление электронной почты по цепочке.
В смарт-контракте UniPass Wallet пользователи управляют своими учетными записями с помощью серии ключей с весами ролей. В дополнение к главному ключу, реализованному в схеме безопасных многосторонних вычислений (MPC), пользователи также могут устанавливать многие другие типы ключей. Каждая клавиша имеет соответствующую роль и вес. Пользователь может получить авторизацию для этой роли только после сбора ключей, общий порог веса роли которых превышает требования.
Ключу можно назначить одну или несколько ролей. Когда ключу назначается роль, одновременно устанавливается соответствующий вес. Когда пользователь хочет начать выполнять операции, связанные с определенной личностью, ему необходимо подписать один или несколько ключей с общим весом 100 или более для роли. Например, при первоначальной регистрации учетной записи пользователи могут пропустить настройку опекуна. Соответствующие параметры могут быть установлены следующим образом:
Функция без газа реализуется через сторонний ретранслятор. Когда пользователь инициирует транзакцию, ретранслятор необходим, чтобы помочь пользователю инициировать транзакцию. В этом процессе ретранслятор может помочь пользователям использовать любой токен для оплаты газа и даже может полностью помочь пользователям оплачивать газ от их имени, обеспечивая отсутствие газа. Relayer — это серверная программа с открытым исходным кодом, UniPass будет запускать ретранслятор по умолчанию, а партнеры или третья сторона также могут запускать ретрансляторы.
Вариант реализации — Кандид
CANDIDE — это общедоступный продукт, созданный совместно и открыто группой участников, и ни одна организация или компания не контролирует его разработку. Candide Wallet Beta — это автономный мобильный кошелек со смарт-контрактами. В настоящее время он развернут в тестовой сети Goerli. Теперь он доступен на Android Test и IOS Testflight.
Технической основой Candide Beta является реализация форка Stackup ERC-4337 и среда Gnosis Safe с открытым исходным кодом. Его функции включают отсутствие слов памяти, социальное восстановление, пакетные транзакции, отсутствие платы за газ и т. д.
Среди них логика реализации таких функций, как слова без примечаний, пакетные транзакции и отсутствие платы за газ, такая же, как у ERC-4337, и завершается с использованием контракта точки входа, разработанного eth-infinitism. Candide запускает собственный упаковщик для упаковки UserOperation как сервиса для своего кошелька. В этом решении большая часть безопасности заключается в контракте точки входа, а не в конструкции самого кошелька.
Кроме того, функция социального восстановления появилась благодаря использованию Candide Safe для своего базового контракта с кошельком. Это позволяет Candide использовать наиболее надежные контракты DAO для управления цифровыми токенами. Candide будет использовать модульную конструкцию Gnosis Safe для реализации своих основных функций, включая социальное восстановление, а также будущих функций, таких как временные блокировки и ограничения на снятие средств. Этот модуль социального восстановления имеет ту же логику, что и Unipass, за исключением того, что Unipass в основном предназначен для восстановления электронной почты, но опекуном Candide может быть любой подписавшийся человек с публичным адресом, например, друзья семьи, учреждения и аппаратные кошельки.
Мысли о контрактных кошельках
Ранние кошельки со смарт-контрактами были разработаны на основе очень специфических проблем, таких как мультиподпись Gnosis Safe и функция социального восстановления Argent. Эти ранние продукты имели сложную конструкцию, часто не были открытыми и прозрачными и не формировали единых стандартов, что затрудняло их вставку в другие приложения в качестве промежуточного программного обеспечения. Для этого типа продукта критерии оценки должны в большей степени основываться на сценарии использования и на том, отражает ли он основные потребности пользователей. Например, функция мультиподписи Safe отражает одну из основных потребностей пользователей.
С появлением ERC-4337 стало очень удобно быстро создавать кошелек без слов, пакетных транзакций и без комиссий за газ. Единый стандарт также делает комплект разработки, построенный на основе этого стандарта, компонуемым и может служить промежуточным звеном. программное обеспечение подключается к различным приложениям и остается совместимым.
Поэтому при рассмотрении первых решений для интеллектуальных кошельков очень важно обеспечить совместимость с ERC-4337. Для решений на базе ERC-4337, поскольку большинство технологий имеют открытый исходный код, при рассмотрении рекомендуется сосредоточиться на следующих моментах:
Технология: как создавать контракты точек входа, упаковщики и агрегаторы (если таковые имеются), а также как создавать функции, выходящие за рамки тех, которые предусмотрены ERC-4337, такие как функции социального восстановления;
Операции: как построить сообщество, вывести на рынок и привлечь пользователей;
Опыт: достаточно ли хорош пользовательский опыт использования кошелька, например плавность, стабильность и т. д.;
И основная логика проверки некоторых других продуктов C.
Будущая модель кошелька, скорее всего, будет похожа на модель B2B2C. Хотя кошелек существует как продукт C-конца, более важно предоставить зрелое решение SDK для других приложений, которые будут интегрированы в кошельки внутри приложений и затем ориентированы на пользователей C-конца. Среди них упаковщики и агрегаторы на первых порах в основном создавались централизованно. Однако позже можно сформировать модульную сеть. Однако, поскольку эта часть является ядром сбора стоимости, кошельки, использующие пакерные сети, созданные другими, должны уйти. через игру в экономические выгоды.
(Вышеуказанный контент взят и перепечатан с разрешения партнера MarsBit, исходная текстовая ссылка | Источник: Foresight News)
Заявление: статья представляет только личные взгляды и мнения автора и не отражает объективные взгляды и позиции блокчейна. Все содержание и мнения предназначены только для справки и не представляют собой инвестиционные рекомендации. Инвесторы должны принимать собственные решения и транзакции, а автор и Клиент Blockchain не несут ответственности за любые прямые или косвенные убытки, вызванные транзакциями инвесторов.
Эта статья Изменения в кошельках Ethereum: возможности и проблемы абстракции учетных записей и ERC-4337 впервые появились в блокчейне.