Модульность учетной записи смарт-контракта: решение проблемы сложной реализации и возможность широкомасштабного внедрения Web3

Сценарист: Руи С. (SevenX Ventures)

Составил: Deep Wave TechFlow

представлять

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

Одним из наиболее важных преимуществ абстракции учетных записей (AA) является возможность настройки функциональности с помощью кода. Однако серьезной инженерной проблемой является несовместимость функций AA, и эта фрагментация препятствует интеграции и открывает двери для привязки к поставщику. Кроме того, обеспечение безопасности при одновременном обновлении и объединении функций может оказаться сложной задачей.

Модульная абстракция учетных записей возникла как часть более широкого движения АА — инновационного подхода к отделению смарт-аккаунтов от их пользовательских функций. Цель — создать модульную структуру для разработки безопасных, легко интегрированных кошельков с разнообразными функциями. В будущем он может реализовать бесплатную учетную запись смарт-контракта «магазин приложений», чтобы кошельки и dApps больше не сосредотачивались на создании функций, а фокусировались на пользовательском опыте.

АА Краткое описание

Традиционный EOA создает множество проблем, таких как начальные фразы, газ, кроссчейн и множественные транзакции. Мы никогда не собирались привносить сложность, но реальность такова, что блокчейн — непростая игра для масс.

Абстракция учетной записи использует учетные записи смарт-контрактов, обеспечивая программируемую проверку и выполнение, позволяя пользователям утверждать серию транзакций одновременно, вместо того, чтобы подписывать и транслировать каждую транзакцию, а также обеспечивает дополнительную функциональность. Это приносит преимущества с точки зрения пользовательского опыта (например, абстракция газа и сеансовые ключи), стоимости (например, пакетные транзакции) и безопасности (например, социальное восстановление, мультиподпись). В настоящее время существует два способа реализации абстракции учетной записи:

• Уровень протокола: некоторые протоколы сами по себе обеспечивают поддержку абстракции локальных учетных записей.Транзакции ZKsync, будь то из EOA или SCA, следуют одному и тому же процессу, используя один пул памяти и процесс транзакций для поддержки AA, который Starknet удалил EOA, все учетные записи являются SCA, и у них есть собственные кошельки со смарт-контрактами, такие как Argent.
• Уровень контракта. Для Ethereum и его эквивалента L2 ERC4337 вводит отдельную запись транзакции для поддержки AA без изменения уровня консенсуса. Такие проекты, как Stackup, Alchemy, Etherspot, Biconomy, Candide и Plimico, создают инфраструктуру сборщиков, а такие проекты, как Safe, Zerodev, Etherspot и Biconomy, создают стеки и SDK.

Дилеммы внедрения SCA

Тема абстракции учетных записей (AA) обсуждается с 2015 года и в этом году была в центре внимания ERC4337. Однако количество развернутых учетных записей смарт-контрактов по-прежнему намного меньше, чем у EOA.

Давайте углубимся в эту дилемму:

Влияние медвежьего рынка:

Хотя AA представил такие преимущества, как беспрепятственный вход в систему и абстракция Gas, люди, которые в настоящее время испытывают медвежий рынок, в основном состоят из образованных пользователей EOA, а не из новых пользователей, поэтому нет стимула для dApps и кошельков. Несмотря на это, некоторые ведущие приложения все еще постепенно внедряют AA, например, Cyberconnect, которая выполнила около 360 000 UserOps (транзакций AA) всего за один месяц, представив свою систему AA и решение без газа.

Барьеры для миграции:

Для кошельков и приложений, накопивших пользователей и активы, безопасная и удобная миграция активов остается проблемой. Однако такие инициативы, как EIP-7377, позволяют EOA инициировать одноразовые транзакции миграции.

Проблема с подписью:

Сам смарт-контракт естественным образом не может подписывать сообщения, поскольку у него нет закрытого ключа, такого как EOA. Такие усилия, как ERC1271, делают такую подпись возможной, но подпись сообщения не работает до первой транзакции, что создает проблему для кошельков, использующих контрфактические развертывания. ERC-6492, предложенный Ambire, является обратно совместимым преемником ERC-1271 и может решить предыдущие проблемы.

Газовые надбавки:

Развертывание, моделирование и выполнение SCA требует более высоких затрат, чем стандартное EOA. Это становится препятствием для усыновления. Однако были проведены некоторые тесты, такие как отделение создания учетной записи от действий пользователя и рассмотрение возможности устранения солей учетных записей и проверок существования, чтобы снизить эти затраты.

Инженерные трудности:

Команда ERC-4337 создала репозиторий eth-infinitiism, чтобы предоставить разработчикам базовые реализации. Однако по мере того, как мы переходим к более детальным или конкретным функциональным возможностям в различных случаях использования, интеграция и декодирование становятся сложными.

В этой статье мы углубимся в пятый вопрос: инженерные проблемы.

Модульные учетные записи смарт-контрактов для решения инженерных задач

Дальнейшее объяснение инженерных проблем заключается в следующем:

• Фрагментация. Различные функции теперь включаются по-разному: через определенные SCA или независимые системы плагинов. Каждый из них следует своим собственным стандартам, заставляя разработчиков решать, какие платформы поддерживать. Это может привести к привязке к платформе или дублированию усилий.
• Безопасность. Хотя гибкость между учетными записями и функциями дает преимущества, она также может усугубить проблемы безопасности. Функции могут проверяться коллективно, но отсутствие независимой оценки может увеличить риск взлома учетной записи.
• Возможность обновления. По мере развития функциональности важно сохранять возможность добавлять, заменять или удалять функции. Повторное развертывание существующих функций с каждым обновлением усложняет работу.

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

Эти термины сходятся в общей концепции: построение модульной архитектуры абстракции учетных записей (Modular AA).

Модульный AA — это ниша в рамках более широкого движения AA, которое предполагает модульность смарт-аккаунтов для адаптации услуг к пользователям и позволяет разработчикам плавно расширять функциональность с минимальными ограничениями.

Однако установление и продвижение новых стандартов является огромной проблемой в любой отрасли. На начальных этапах может возникнуть множество различных решений, прежде чем все примут основное решение. Однако отрадно, что и 4337 SDK, и разработчики кошельков, и команды по инфраструктуре, и разработчики протоколов работают вместе, чтобы ускорить этот процесс.

Модульная структура: основной аккаунт и модули

Звонок делегирования и агентский договор

Внешние вызовы и вызовы делегатов:

Хотя вызов делегата аналогичен вызову, вместо выполнения целевого контракта в его собственном контексте он выполняет целевой контракт в текущем состоянии вызывающего контракта. Это означает, что любые изменения состояния, внесенные целевым контрактом, будут применены к хранилищу вызывающего контракта.

Для реализации составных и обновляемых структур необходимы базовые знания, называемые «агентскими контрактами».

1. Агентский контракт. Обычные контракты сохраняют свою логику и статус и не могут быть обновлены после развертывания. Прокси-контракт использует делегата для вызова другого контракта. Реализуйте функцию по ссылке, которая выполняется в текущем состоянии агентского контракта.
2. Сценарий использования. Хотя контракт прокси-сервера остается прежним, вы можете развертывать новые реализации за прокси-сервером. Прокси-контракты используются для возможности обновления, и их дешевле развертывать и поддерживать в публичных блокчейнах.

Архитектура безопасности

Safe — это ведущая модульная инфраструктура смарт-аккаунтов, предназначенная для обеспечения проверенной в боях безопасности и гибкости, позволяющая разработчикам создавать разнообразные приложения и кошельки. Стоит отметить, что многие команды используют Safe или вдохновляются им. Biconomy запускает свою учетную запись, расширяя встроенную мультиподпись 4337 и 1/1 в Safe. С более чем 164 000 развернутых контрактов и фиксированной стоимостью более 30,7 миллиардов долларов Safe, несомненно, является лучшим выбором в этой области.

Безопасная структура

Контракт безопасного аккаунта: Контракт главного агента (с отслеживанием состояния)

Учетная запись Safe является прокси-контрактом, поскольку она делегирует вызов одноэлементного контракта. Учетная запись Safe содержит владельца, пороговое значение и адрес реализации, которые устанавливаются как переменные для агента, тем самым определяя его состояние.

Единый договор: Центр интеграции (без гражданства)

Синглтон обслуживает учетную запись Safe, интегрирует и определяет различные интеграции, включая плагины, перехватчики, обработчики функций и средства проверки подписи.

Контракт модуля: пользовательская логика и функции

Модули очень мощные. Плагины модульного типа могут определять различные функции, такие как потоки платежей, механизмы восстановления и ключи сеанса, а также служить межцепочным мостом между Web2 и Web3, получая данные вне цепочки. Другие модули, такие как хуки, действуют как средства защиты, а обработчики функций реагируют на любые инструкции.

Что произойдет, если мы перейдём на Safe

Обновляемый контракт:

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

Компонуемые и многоразовые модули:

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

Алмазный агент ERC-2535

О ERC2535 и Diamond Agent

ERC2535 стандартизирует Diamond Agent, модульную систему смарт-контрактов, которую можно обновлять/расширять после развертывания и которая практически не имеет ограничений по размеру. До сих пор многие команды были вдохновлены этим, например, эксперименты Zerodev Kernel и Soul Wallet.

Что такое структура ромба

1. Алмазный контракт: Контракт главного агента (с состоянием). Алмазный контракт — это прокси-контракт, который вызывает функции из своей реализации посредством вызовов делегатов.
2. Модуль/подключаемый модуль/фасетный контракт: пользовательская логика и функциональность (без сохранения состояния). Модуль или так называемый фасет — это контракт без сохранения состояния, который может развертывать свои функциональные возможности в одном или нескольких алмазах. Это независимые контракты, которые могут совместно использовать внутренние функции, библиотеки и переменные состояния.

Что происходит, когда мы переходим на Diamond

1. Обновляемые контракты: Diamond предоставляет систематический способ изолировать различные плагины и соединять их вместе, а также напрямую добавлять, заменять или удалять любые плагины с помощью функции DiamondCut. Нет ограничений на количество плагинов, которые могут быть добавлены в Diamond с течением времени.
2. Модульные и многоразовые плагины. Развернутый плагин может использоваться любым количеством Diamond, что значительно снижает затраты на развертывание.

Разница между Safe Smart Account и Diamond Method

Между архитектурами Safe и Diamond существует много общего: обе архитектуры опираются на прокси-контракты в качестве ядра и ссылаются на логические контракты для обеспечения возможности обновления и модульности.

Однако основное отличие заключается в обработке логических контрактов. Вот более подробная инструкция:

1. Гибкость. При включении новых плагинов Safe необходимо повторно развернуть свой одноэлементный контракт, чтобы внести изменения в свой агент. Напротив, Diamond делает это напрямую через функцию DiamondCut в своем делегате. Эта разница в подходе означает, что Safe сохраняет более высокий уровень контроля, а Diamond обеспечивает большую гибкость и модульность.
2. Безопасность. В настоящее время в обеих структурах используется вызов делегата, который позволяет внешнему коду манипулировать хранилищем основного контракта. В безопасной архитектуре вызов делегата указывает на один логический контракт, тогда как Diamond использует вызов делегата между несколькими контрактами модулей (подключаемых модулей). Таким образом, вредоносный плагин может перезаписать другой плагин, тем самым создавая риск конфликтов хранилища, которые могут поставить под угрозу целостность агента.
3. **Стоимость.**Гибкость, присущая ромбовидному подходу, сопряжена с повышенными проблемами безопасности. Это добавляет фактор затрат и требует полного аудита каждый раз при добавлении нового плагина. Ключевым моментом является обеспечение того, чтобы эти плагины не мешали работе друг друга, что может стать проблемой для малого и среднего бизнеса, пытающегося поддерживать строгие стандарты безопасности.

«Метод безопасного смарт-аккаунта» и «Метод ромба» являются примерами различных структур, включающих агентов и модули. Как сбалансировать гибкость и безопасность имеет решающее значение, и эти два подхода, вероятно, будут дополнять друг друга в будущем.

Порядок модулей: валидатор, исполнитель и хук

Давайте расширим наше обсуждение, представив стандарт ERC6900, предложенный командой Alchemy, который был вдохновлен Diamond и специально адаптирован для ERC-4337. Он решает проблему модульности смарт-аккаунтов, предоставляя общий интерфейс и координируя работу между разработчиками плагинов и кошельков.

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

• Проверка. Убедитесь в подлинности звонящего и его полномочий над учетной записью.
• Выполнение: Выполнение любой пользовательской логики, разрешенной учетной записью.
• Привязка: Как модуль, который запускается до или после другой функции. Это может изменить состояние или привести к отмене всего вызова.

Разделение модулей на основе разной логики имеет решающее значение. Стандартизированный подход должен определять, как следует писать функции проверки, выполнения учетной записи смарт-контракта и функции перехвата. Будь то Safe или ERC6900, стандартизация помогает снизить потребность в уникальных усилиях по разработке для конкретной реализации или экосистемы и предотвращает привязку к поставщику.

Обнаружение и безопасность модулей

Одно из решений, которое сейчас набирает обороты, предполагает создание места, позволяющего пользователям находить проверяемые модули, то, что мы могли бы назвать «реестром». Этот реестр похож на «магазин приложений», созданный для упрощения, но процветания модульного рынка.

Безопасный{основной}протокол

Протокол Safe{Core} — это совместимый протокол учетных записей смарт-контрактов с открытым исходным кодом, предназначенный для повышения доступности для различных поставщиков и разработчиков посредством четко определенных стандартов и правил, сохраняя при этом высокий уровень безопасности.

1. Учетная запись. В протоколе Safe{Core} концепция учетной записи является гибкой и не ограничена конкретной реализацией. Это позволяет участвовать различным поставщикам услуг по работе с учетными записями.
2. **Менеджер: **Менеджер выступает в роли координатора между учетными записями, реестрами и модулями. Он также отвечает за безопасность, выступая в качестве уровня разрешений.
3. Реестр. Реестр определяет атрибуты безопасности и обеспечивает соблюдение стандартов модулей, таких как ERC6900, с целью создания открытой среды «магазина приложений» для обнаружения и безопасности.
4. **Модули: **Модули управляют функциональностью и предоставляются в различных начальных типах, включая плагины, перехватчики, средства проверки подписи и обработчики функций. Разработчики могут этому способствовать, если они соответствуют установленным стандартам.

Дизайн со стразами

Процесс разворачивается следующим образом:

• Создать определение схемы. Схемы служат предопределенными структурами данных для использования в доказательствах. Предприятия могут настраивать шаблон в соответствии со своими конкретными сценариями использования.
• Создание модуля на основе шаблона: Смарт-контракт регистрируется как модуль, получает байт-код и выбирает идентификатор шаблона. Эти данные затем сохраняются в реестре.
• Получить подтверждение модуля: Испытатель/аудитор может предоставить доказательства модуля на основе схемы. Эти сертификаты могут включать уникальные идентификаторы (UID) и ссылки на другие сертификаты для связывания. Их можно распространять по цепочке и проверять соответствие определенным пороговым значениям в целевой цепочке.
• **Используйте анализаторы для реализации сложной логики: **Парсеры опционально устанавливаются в шаблонах. Их можно вызывать во время создания модуля, установления доказательства и демонтажа. Эти парсеры позволяют разработчикам включать сложную и разнообразную логику, сохраняя при этом структуру доказательства.
• **Удобный доступ к запросам: **Запросы предоставляют пользователям возможность доступа к защищенной информации из внешнего интерфейса. ЭИП можно найти здесь.

Хотя эта модель все еще находится на ранней стадии своего развития, у нее есть потенциал для установления стандарта децентрализованным и совместным образом. Их реестр позволяет разработчикам регистрировать свои модули, аудиторам проверять их безопасность, интегрировать кошельки, а пользователям легко находить модули и проверять их аттестационную информацию. В будущем могут быть следующие варианты использования:

• **Сертификаторы: **Доверенные организации, такие как Safe, могут работать с Rhinestone в качестве сертификаторов для внутренних модулей. В то же время к участию могут присоединиться и независимые испытатели.
• **Разработчики модулей: **С формированием открытого рынка разработчики модулей смогут коммерциализировать свою работу через реестр.
• Пользователи: Через удобные интерфейсы, такие как кошельки или децентрализованные приложения, пользователи могут просматривать информацию о модулях и делегировать доверие различным проверяющим.

Концепция «реестра модулей» предоставляет выгодные возможности разработчикам плагинов и модулей. Это также может проложить путь к «рынку модулей». Некоторые из этих аспектов могут контролироваться командой Safe, в то время как другие могут проявляться в виде децентрализованных торговых площадок, которые приглашают всех внести свой вклад и обеспечивают прозрачный контрольный журнал. Применяя такой подход, мы можем избежать привязки к поставщику и поддержать расширение EVM, обеспечив лучший пользовательский опыт, который понравится более широкой аудитории.

Хотя эти методы обеспечивают безопасность отдельных модулей, общая безопасность учетных записей смарт-контрактов не является абсолютно надежной. Объединение законных модулей и доказательство того, что они не имеют конфликтов хранения, может оказаться непростой задачей, подчеркивая важность кошельков или инфраструктуры AA в решении таких проблем.

Подведем итог

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

Однако модульные учетные записи смарт-контрактов (SCA) — это лишь часть головоломки внедрения. Для полной реализации потенциала SCA также требуется поддержка уровня протокола со стороны решений второго уровня, а также мощная инфраструктура связывания и одноранговые пулы памяти, более экономичные и осуществимые механизмы подписи SCA, межцепочечная синхронизация SCA. и управление, а также разработку удобных интерфейсов.

Мы предвидим будущее с широким участием, что поднимает некоторые интересные вопросы: как только процесс заказа SCA станет достаточно прибыльным, как традиционные механизмы извлечения ценности майнерами (MEV) войдут в эту сферу, создадут сборщики пакетов и получат прибыль? Когда инфраструктура станет более зрелой, как абстракция учетной записи (AA) сможет стать базовым уровнем для транзакций, основанных на намерениях? Пожалуйста, следите за обновлениями, поскольку эта область постоянно развивается.