Смарт-аккаунты Pali
Смарт-аккаунты Pali — это контрактные аккаунты, которые Pali может создать, подключить и использовать для пользователя. Для обычного пользователя это выглядит как привычный кошелек: проверить запрос dapp, подтвердить passkey или ключом кошелька, и Pali отправит транзакцию. Технически аккаунт модульный: валидаторы разрешают действия, а executor-модули добавляют функции, например восстановление.
Простая модель
- Один адрес аккаунта хранит средства и виден dapp.
- Аккаунт может использовать passkey, ECDSA или composite-политику.
- Guardian recovery может заменить активный валидатор после задержки.
wallet_sendCallsможет выполнить несколько calls как одно атомарное действие.
Техническая модель
PaliSmartAccount выполняет calls и проверяет подписи через модули в стиле ERC-7579. PaliSmartAccountFactory выводит детерминированные адреса и деплоит аккаунты. Pali готовит исполнения в стиле ERC-4337 и использует EIP-1271 для контрактных подписей.
Две роли: валидаторы подписывают, guardians восстанавливают
ERC-7579 разделяет роли модулей, и Pali намеренно опирается на это разделение:
- Валидаторы — это полномочия подписания. Валидатор решает, авторизует ли данное подтверждение (passkey-доказательство, ECDSA-подпись, результат composite-политики) действие аккаунта. Только валидаторы могут одобрять транзакции.
- Executors добавляют поведение аккаунта, не являющееся подписью. Модуль guardian recovery в Pali — это executor: guardians не могут подписывать или перемещать средства, они могут лишь запланировать замену активного валидатора с timelock.
Именно разделение этих ролей делает восстановление безопасным, чтобы его рекомендовать. Компрометация guardian не дает атакующему полномочий подписания — она дает ему отложенную, видимую и отменяемую попытку восстановления.
Composite-политики подписания
Composite-валидатор объединяет дочерние валидаторы под threshold, что превращает один аккаунт в policy engine:
- 1-of-N — одобрить может любой из нескольких аутентификаторов. Удобно для личных аккаунтов с passkey на каждом устройстве.
- t-of-N — одобрить должен кворум. Естественная форма для общих казн, trading desks и аккаунтов под контролем команды.
- N-of-N — одобрить должен каждый настроенный валидатор. Аккаунты с максимальными гарантиями.
Composites могут вкладываться: дочерний элемент composite сам может быть composite, поэтому иерархические политики — например, «ключ CFO И (любые 2 из 3 desk passkeys)» — выражаются без кастомных контрактов. Guardian recovery остается независимым от того, какая политика валидаторов активна.
Гибкость валидаторов и постквантовая готовность
Поскольку авторизация живет в заменяемых модулях, аккаунт не привязан ни к одной схеме подписи. Сегодня Pali поставляет ECDSA (wallet-owned по умолчанию), P-256 WebAuthn passkeys и composite-валидатор. Когда будут развернуты новые типы валидаторов — включая постквантовые схемы подписи — они устанавливаются на тот же аккаунт по тому же адресу. С этого момента авторизация отдельных транзакций может выполняться вообще без ECDSA. Средства, история и интеграции никогда не перемещаются; развиваются только полномочия подписания.
Та же гибкость распространяется и на восстановление. Модуль guardian recovery проверяет одобрения стандартной проверкой подписи — обычный ECDSA для обычных адресов, ERC-1271 для контрактных аккаунтов — поэтому guardian сам может быть смарт-аккаунтом, управляемым composite-, кастомным или постквантовым валидатором. Развернутый контрактный guardian заставляет путь восстановления наследовать схему подписи этого аккаунта; именно так и подписание, и восстановление со временем могут работать без какой-либо зависимости от классического ECDSA. Текущий guardian-UX Pali собирает одобрения на основе ключей; флоу для контрактных guardians можно добавить в кошелек позже, потому что on-chain модуль их уже поддерживает.
Для институций и команд
Институциям следует воспринимать Pali smart accounts как инфраструктуру аккаунта, а не только как passkey-login. Используйте passkeys для удобного onboarding, ECDSA или composite validators для командного или hardware-wallet контроля, guardian recovery для замены с задержкой и funded gas-payer accounts для deployment и execution.
Pali отдельно предупреждает, если dapp запрашивает внешних ECDSA owners, потому что эти адреса смогут подтверждать будущие действия аккаунта.
Метод dapp
const account = await window.ethereum.request({
method: 'wallet_prepareSmartAccount',
params: [{ label: 'Trading account', authenticator: { id: 'p256-webauthn' } }],
});
Поддерживаемые сети
Смарт-аккаунты Pali работают в совместимых EVM-сетях, где factory и модули Pali существуют по адресам, которые ожидает Pali. Это не ограничено сетями, которые разворачивает Pali: если активная сеть предоставляет canonical CREATE2 deployer, Pali может развернуть недостающую настройку смарт-аккаунта прямо из кошелька. Откройте Pali Settings, перейдите в Advanced и используйте кнопку Deploy в Smart account setup.
Passkey-валидаторам нужна поддержка P-256 WebAuthn verification. Многие современные EVM-среды предоставляют ее через P-256/passkey precompile, но интеграторам следует проверить поддержку сети перед использованием passkey-валидаторов.
Контроль пользователя
Перед подтверждением пользователь видит запрашивающий сайт, метку аккаунта, запрошенный authenticator и любые внешние адреса ECDSA owners. Браузер или операционная система показывает WebAuthn-запрос, когда Pali нужна новая passkey credential. Pali показывает прогресс деплоя, установки модулей и подтверждения, прежде чем смарт-аккаунт будет подключен к dapp.