self-сustody кошелек — это когда пользователь сам менеджит свои пароли, то есть если пароль потерялся, забылся, сгорел, кошелек никак не поможет его восстановить и доступ к средствам утерян (звучит не user-friendly)
Философско-практическое вступление
Сегодня в разных чатах и твиттерах бытует мнение что если убрать сид фразу из некастодиального кошелька (или добавить функцию восстановления), это сразу задрайвит масс-адопшн до небес. Я не думаю, что это сразу же сильно повысит масс-адопшн (или как-то повысит его вообще, потому что юзер (в его массовом смысле) не хочет знать что такое кастодильный а что такое не-кастодиальный, он вообще не хочет ничего знать, он хочет решать какую-то свою конкретно взятую проблему, для решения которой ему возможно понадобится кошелек) я это к чему: это точно не панацея и не волшебная таблетка, но в долгосроке — это важный (очень важный) элемент. кстати за что я люблю криптоиндустрию с ее криптозимами — остаются только те, кто готов играть в долгую.
Так вот, Account Abstraction
Есть два вида аккаунтов:
EOA — Externally Owned Accounts — аккаунт который менеджит некто владеющий приватным ключом
СA — Contract Accounts — смарт-контракт задеплоинный на сети который менеджит код
Состояние (state) EOA аккаунта может быть модифицировано только через новую транзакцию, а новая транзакция может быть инициирована только каким-то EOA. То есть, когда EVM (Ethereum Virtual Machine) исполняет транзакцию, первый EOA с которым EVM соприкасается и есть инициатор транзакции (за банкет газ платит именно этот аккаунт).
Когда EVM получает запрос на проведение транзакции, она проверяет валидность подписи (приватного ключа) отправителя, а также проверяет что элемент nonce* транзакции соответствует элементу nonce аккаунта, после этого исполняет транзакцию, после этого списывает плату за проведение транзакции с аккаунта отправителя.
*nonce — abbreviation for the phrase ‘number used once’, рандомно сгенерированное число, доказывающее, что функция или значение были использованы только один раз.
у аккаунта на эфире есть:
стейт (state): баланс + nonce
способность валидировать и исполнять транзакции
адрес (fyi: адрес кошелька это последние 20 байт публичного ключа) связанный (спаренный?) с приватным ключом
И тут важно уточнить такое свойство: если у Васи есть приватный ключ, значит у вас есть аккаунт (независимо от того сколько и каких аппов он использует для этого аккаунта и использует ли аппы вообще). Но если один и тот же приватный ключ есть у Васи и у Кати, то они оба владеют аккаунтом.
Это мы описали логику ЕОА аккаунтов as it is на сегодняшний день
Главная проблема которую эта логика рождает:
если у Васи был приватный ключ от аккаунта, а потом Вася сходил на крипторейв и потерял там приватный ключ, то у Васи больше нет аккаунта (и всех средств которые были у Васи на аккаунте у Васи тоже нет). Зато если Стивен нашел Васин приватный ключ на крипторейве, то теперь бывший Васин аккаунт стал нынешним аккаунтом Стивена (и все средства тоже)
Какая альтернатива предлагается:
Еще раз, в случае с EOA: аккаунт = подпись
Account Abstarction предлагает эти два элемента разделить, то есть хранение активов отдельно, а подпись транзакций отдельно
Как такое возможно
Вместо аккаунта появляется смарт-контракт, который будет проверять валидность транзакции и исполнять ее. Благодаря чему появляется возможность "кастомизировать" аккаунт под разные нужды: использовать другую модель шифрования (в эфире сегодня используется ECDSA), мультисиг (для авторизации транзакции она должна быть подписана определенным количеством аккаунтов, скажем 3 из 5), вплоть до того, что новый подписант транзакций назначается каждую неделю
На сегодняшний день есть два ключевых игрока работающие с Account Abstraction: StarkNet and zkSync 2.0, самый звучащий из каждого утюга смарт-контракт-воллет — Argent, другой смарт-контракт-воллет — Ambire (вероятно есть еще, это первое что приходит в голову).
Больше о веб3 простыми словами в канале миллениалы делают веб3