Дисклеймер: Данная публикация является переводом, выполненным участником сообщества Fuel. Была проведена вычитка, но возможны некоторые ошибки. Fuel Labs не несет ответственности за точность, актуальность или последовательность переведенной информации.
Оригинальная публикация: Account Abstraction For Everyone Else.
Многие люди описывают абстракцию аккаунта как средство "автоматического выполнения транзакций при выполнении некоторого условия". Только подмножество таких ситуаций возможно, если вы реализуете абстракцию аккаунта без статических условий - а вы должны это сделать!
Что представляет собой абстракция аккаунта?
В общем понимании, абстракция аккаунта - это возможность программно задавать условия достоверности транзакции.
Чем не является абстракция счета:
-
оплата газа пользователями
-
встроенный multi-sig
-
web3auth по принципу "social login"
Вы можете выполнять эти вещи в результате реализации абстракции аккаунта.
EIP-4337, о котором мы расскажем более подробно позже, написанный Виталиком и др., гласит: "Достижение ключевой цели абстракции аккаунта: позволить пользователям использовать кошельки смарт-контрактов, содержащие произвольную логику верификации, вместо EOA в качестве основного аккаунта".
В настоящее время в Ethereum транзакция действительна только если:
-
Достаточный баланс для оплаты газа.
-
Nonce является правильным.
-
Имеет валидную цифровую подпись.
Но что, если бы разработчики могли определить другой набор условий, при которых транзакции считаются действительными?
Абстракция аккаунта без состояния в сравнении с абстракцией с состоянием
Прежде чем мы продолжим, важно отметить, что существует два типа абстракции аккаунтов: stateless и stateful.
Многие люди описывают абстракцию аккаунта как средство "автоматического выполнения транзакций при выполнении некоторого условия". Только подмножество таких ситуаций возможно, если вы реализуете абстракцию аккаунта без статических условий - а вы должны это сделать!
Stateless = не зависит от внешнего состояния, не имеет побочных эффектов.
Stateful = может зависеть от внешнего состояния, имеет доступ к состоянию сети.
В реализации абстракции аккаунта с состоянием смарт-контракт (stateful), определяющий условия достоверности, имеет доступ к состоянию сети. Проблема заключается в том, что условие, которое истинно в одном случае, может быть не истинным в другом. На практике это выглядит так: когда нода отправляет транзакцию, которая в данный момент является действительной, а позже становится недействительной. Например, допустим, вы хотите автоматически выполнить транзакцию в блоке 1000000. В блоке 1000000 вы могли бы отправить пользовательскую операцию в mempool, которая на тот момент была бы действительной. Когда bundler попытается поместить ее в следующий блок, может оказаться, что она недействительна, потому что номер блока увеличился.
Принимающая нода вынуждена тратить ресурсы на проверку того, что никогда не появится в сети, и не может добавить транзакцию в черный список, потому что она была действительна на момент отправки.
В ERC4337, о котором мы расскажем подробнее позже, исследователи потратили много времени на то, чтобы понять, как этого избежать. Спецификация запрещает использование определенных опкодов, таких как blockNumber, по этой причине.
При абстракции аккаунта без состояния (stateless) вы никогда не рискуете изменить валидность - она однообразна.
Реализация АА без состояния в Fuel
О том, как другие экосистемы реализуют абстракцию аккаунта, мы поговорим чуть позже. На примере Fuel вы увидите контраст между созданием новой системы с нуля и модульным тезисом по сравнению с созданием для существующей системы.
Fuel реализует AA без состояния с помощью предикатов. Предикат - это просто условие, при котором вы можете провести UTXO. Предикаты - это скрипты, где главная функция возвращает булевое значение. Чистая функция, в которой активы под этим предикатом разблокированы и могут быть потрачены вызывающей стороной, если их значение равно true. Предикат владеет или управляет UTXO.
Примечание: UTXO означает неизрасходованный вывод транзакций. Основное фундаментальное понимание UTXO заключается в том, что при каждой транзакции весь баланс, или количество монет, расходуется. Сумма, которую вы отправляете своему адресату, попадает к нему, а остальное сжигается, затем снова чеканится, в результате чего образуется новая неизрасходованная сумма.
Ключевым моментом в предикатах Fuel является то, что вы можете интроспектировать, или исследовать, входы и выходы предикатов, что позволяет вам иметь соглашения, которые позволяют вам построить обмен книгой заказов или сделать атомарный своп между несколькими сторонами.
Транзакции UTXO на уровне транзакций описывают подмножество точных эффектов транзакции. Это подмножество эффектов может быть обусловлено в абстракции аккаунта без состояния. Fuel достигает этого с помощью проектного решения UTXO-модели. Именно это дает системе возможность знать о входах и выходах транзакции. В Ethereum вы знаете только о входах. В Fuel вы можете использовать выходы, чтобы написать логику, которая говорит, что если вы предоставите X, то Y.
С точки зрения практики
Вы можете зафиксировать монеты в предикате с программируемой действительностью, который говорит: "Эти монеты можно потратить, если в обмен на них на определенный адрес было отправлено X количество актива Y". Аналогично, вы можете иметь некую логику, которая говорит, что эта транзакция действительна, только если X обменивается по определенной цене. Загвоздка здесь не в том, что вы отправляете что-либо. Оно уже отправлено. Вы видите конечный эффект транзакции, в данном случае, когда монеты были отправлены.
Валидность предикатов
Предикаты не проверяются во время выполнения scoped. Они проверяются во время валидности транзакции. Предикат может проверить, что входы транзакции обладают определенными свойствами, но его не волнует, являются ли эти входы действительными (существующими, подписанными). Они должны быть действительными входами, чтобы транзакция была действительной, но не предикат обеспечивает эту действительность.
Soon™
В настоящее время предикаты Fuel ограничиваются количеством байтов как способ их измерения. В будущем команда собирается ограничить предикаты газом, что позволит использовать циклы. Это позволит выполнять криптографию, например, пользовательское хеширование и проверку подписи, которые обычно требуют циклов.
Преимущества реализации Fuel
Примечание*: Пропустите этот раздел, если вы хотите перейти к тому, что можно делать с AA*
Интроспекция UTXO
Как в Bitcoin, так и в Ethereum, и в других протоколах, использующих аналогичные способы реализации, вы не можете интроспектировать транзакции. Это означает, что вы не можете проанализировать транзакцию, потратив ее, и не можете программно установить, что делать на основе выходов.
По своей сути, реализация AA в Fuel предлагает разработчикам и, в свою очередь, пользователям большую гибкость, поскольку это не вещи, закодированные на уровне протокола. Абстракция аккаунта в Fuel позволяет разработчикам определять пользовательские схемы проверки на уровне приложения.
У команды Fuel Labs есть пример EC Recover для закрытого ключа Ethereum. Если вам нужен EC Recover для разных кривых, разработчик может написать его на уровне приложений! Посмотрите на эту реализацию BLS12-381 и Edwards25519 от Hashcloack, написанную на Sway.
EC RECOVER: Отправляя транзакцию в сеть Ethereum, вы должны подписать ее своим закрытым ключом. EC Recover переносит эту функцию проверки подписи в смарт-контракт вместо того, чтобы это мог делать только ноды Ethereum. Таким образом, вы можете проверить гораздо больше, чем просто подпись транзакции.
Отсутствие увеличения состояния
Абстракция аккаунта без состояния не увеличивает состояние (так сильно), потому что даже когда средства расходуются, они никогда не попадают в состояние блокчейна, только в историю.
В предикатах нет контрактов, состояний и хранилищ. У предикатов изначально нет состояния, а затем, если кто-то тратит от имени предиката, вы получаете только одну запись в базе данных, только для UTXO вместо дерева состояний.
Как другие команды используют абстракцию аккаунта
Как и большинство вещей в компьютерной науке, абстракция аккаунта может быть реализована множеством способов. Ни одна реализация не является стандартной для всей отрасли.
Ethereum
EIP-2938 был первоначальным EIP, позволяющим контракту быть top-level аккаунтом, который оплачивает комиссии и начинает выполнение транзакций. Реализация заключалась в введении нового опкода EVM для передачи сигнала о действительности, чтобы расширить условия транзакций при выполнении произвольного байткода EVM. Это предложение не вошло в протокол, потому что разработчики были заняты другими изменениями, такими как merge, и не могли рисковать изменением протокола такого масштаба.
ERC-4337 - это первое предложение/стандарт абстракции аккаунта, который вводит абстракцию аккаунта Ethereum, не требуя изменений основного протокола. Это происходит за счет переноса проверки транзакций из самого протокола на более высокий уровень - уровень смарт-контрактов с этой специальной "точкой входа".
В Ethereum EOA - это учетные записи на Ethereum, функциональность которых жестко прописана в протоколе. Определяется, как они оплачивают газ, как подписывают транзакции, как используют nonce и т. д. Этот стандарт позволяет отказаться от жестко закодированной структуры акаунтов, которую дают нам EOA.
Starknet
Starknet - это zk-rollup на Ethereum. Starkware реализует модифицированную версию модели EIP-4337 для Ethereum. Подробнее об этом можно прочитать здесь.
zkSync
zkSync - это zk-rollup на Ethereum. zkSync реализует модифицированную версию EIP-4337. Подробнее об их реализации можно прочитать здесь.
Biconomy AA
Biconomy - это платформа для разработчиков, ориентированная на инфраструктуру и инструментарий для экосистемы Ethereum. Biconomy реализует модифицированную версию EIP-4337 и предлагает такие функции, как оплата газа пользователями в рамках SDK. Подробнее об их реализации можно прочитать здесь.
Modular Design
Модульный подход заключается в том, чтобы не разрабатывать систему, тесно связанную с другой системой, что позволяет добиться большей гибкости. Реализация абстракции аккаунта в Fuel является проявлением этого. Реализация абстракции аккаунта в Fuel позволяет повысить гибкость и создать высоконастраиваемую среду, в которой разработчики могут на уровне приложения определять условия действительности, не завися от поддержки протокола Fuel.
Поскольку Fuel не был создан исключительно для Ethereum или какой-либо другой системы, реализация Fuel не имеет привязки к другой системы и имеет пространство для инноваций.
В то время как zkSync, Starkware и Biconomy реализуют модифицированную версию EIP-4337, Fuel реализовал более уникальную и высокопроизводительную абстракцию аккаунта. Поскольку Fuel будет развернут в виде роллапа на Ethereum, по некоторым оценкам, в Ethereum уже есть абстракция аккаунтов.
Что вы можете сделать с помощью абстракции аккаунта
Новые возможности, которые вы видите, создаются благодаря абстракции аккаунта, но не самой абстракции аккаунта. Такие вещи, как оплата газа для пользователей и Web3Auth - это вещи прикладного уровня, построенные поверх абстракции аккаунта. Эти вещи изначально возможны благодаря основному механизму абстракции аккаунта: возможности программно задавать условия валидности tx.
Примеры решений, построенных на основе абстракции аккаунта:
-
Web3auth
-
Оплата газа за других пользователей
-
Возможность выбора схемы проверки подписи
-
Проверка нескольких подписей (нативный multi-sig)
Ознакомьтесь с этими проектами, которые используют абстракцию аккаунта в Fuel:
-
Authsome - Walletless система входа. Этот кошелек затем используется в качестве основы для подключаемой инфраструктуры аутентификации, подобной Web3Auth.
-
Thunder - NFT площадка на Fuel, позволяющая осуществлять массовое исполнение транзакций одним кликом.
-
Poolshark - протокол для направленной ликвидности. Poolshark обеспечивает сопоставление условных ордеров, использующих абстракцию аккаунта Fuel, с объединенной ликвидностью для улучшения доступности и снижения комиссий для продвинутых трейдеров.
Улучшения UX
-
Социальное восстановление кошельков
-
Пакетные транзакции
-
Приложения могут оплачивать газ транзакций своих пользователей
-
Использование кошельков из разных экосистем (или одинаковых, использующих разные схемы подписи)
-
Walletless авторизация для Web3
-
Пользователям не нужны ETH в их "обычном" кошельке, чтобы совершать транзакции
-
Возможность разместить 100% средств в multisig и инициировать транзакции непосредственно с него
Открытие новых приложений
"Никто не знает, но это провокация. Это заставляет людей двигаться!"
Вот правда: мы не знаем до конца, какие новые типы приложений могут быть открыты (пока), но мы можем начать масштабные улучшения UX существующих приложений, и это отличное начало.
Обеспечение доступности блокчейна для всех
Пару лет назад UX-проблема блокчейн заключалась в том, что они были полностью финансово недоступны для большей части мира. С дальнейшим развитием и расширением L2-решений, мы подошли к новому рубежу: UX.
Оказалось, что мы можем снизить комиссию настолько, чтобы сделать блокчейн пригодным для использования, но UX приложений должен быть более приятным и надежным. В следующем цикле мы ожидаем, что все больше команд сосредоточатся на улучшении UX и потоков с помощью абстракции счетов. Это будет еще один инструмент, необходимый для создания опыта, подобного Web2, с хранительскими свойствами Web3.
Выражение благодарности
John Adler, Kristof Gazso, Yuan Han Li, James Prestwich, Ryan Sproule.
Следите за нами
О нас
Fuel – это самый быстрый уровень исполнения для модульного стека блокчейна. Технология, отличающаяся мощностью и изяществом, обеспечивает параллельное выполнение транзакций, предоставляя разработчикам высочайшую гибкую пропускную способность и максимальную безопасность, необходимую для масштабируемости. Разработчики предпочитают FuelVM за превосходный опыт разработки и возможность выйти за пределы ограничений EVM.