Ну и шобы все понимали кто эти АА, давайте сравним АА в zk rollup-ах и AA для ETH-maxi девочек. Начнем с самого простого и основного тейка "AA это контракт", по сути тут можно уже заканчивать пост, но давайте прям глубже в этом покопаемся.
EIP 4337 - Link
В эталоне у нас два модуля как и в большинстве случаев, validate + execute. Чтобы убедиться, что validate всегда вызывается перед execute, EIP требует, чтобы оба вызывались онли из EntryPoint, который никогда не вызывает execute без valid EntryPoint.
Starknet c правилом "Validate and execute" - Link
То есть у нас условный User и нода, которая верифицирует до execute чтобы гарантировать безопасность.
Separating the __validate__ and __execute__ functions guarantees payment to sequencers for work completed and protects them from Denial of Service (DoS) attacks.
zkSync Абсолютно идентичный случай, validate->execute, все по канону - Link
Safe (prev. Gnosis Save) - Link
У Safe немного другая логика с 2/2, или >51%. Но главная суть не меняется:
Safe forwards the `validateUserOp` call to this contract, it validates the user operation and returns the result. It also executes a module transaction.
Также у Safe есть условный "бекдор" в виде ExecuteFromPlugin. То есть Safe выдает право у себя зарегистрированными модулями вызывать эту функцию, чтобы уже потом на execute. Но, это так, только если хотите немного кастомизации. Итого по АА мы имеем:
- Эти ваши АА в любом исполнении это контракт или другими словами wrapper
- Smart Account ничто иное как EOA с дополнительным слоем верификации
- Помним о правиле Validate then execute!
Мой главный тейк:
Нет смысла во всех этих Biconomy, Gelato, Safe, Alchemy в ближайшем будущем, сила за апчейнами с deep customisation самой сети, брат. Ибо Optimism/Polygon/ETH хуй покладет на такую модульность в основной сети и менять консенсус никто не планирует, но OP Stack это себе добавит, как и добавят или уже добавили в Cosmos SDK, Starknet Stack, Arbitrum Orbit и другую возможную вариацию appchain-ов. Модульность, прям как при сборке ПК👍