Предложение Tempo TIP-1061 вводит собственный многоподписной аккаунт уровня протокола, без необходимости разворачивать контракты вроде Safe

Блокчейн уровня 1 Tempo, совместно разработанный Stripe и Paradigm, 31 мая представил предложение TIP-1061 о нативных мультиподписных аккаунтах. В планах — внедрить мультиподпись в качестве основного типа аккаунтов протокольного уровня, чтобы обеспечить мультиподписное управление без необходимости разворачивать смарт-контрактные кошельки вроде Safe. Основные целевые сценарии TIP-1061 — DAO, институциональные участники и валидирующие узлы, при этом предложение пока находится на стадии черновика.

Подтверждённые технические спецификации

Ключевой дизайн TIP-1061 включает следующие уже подтверждённые технические детали. Адрес мультиподписного аккаунта выводится из хэша начальной конфигурации (config_id); при последующих изменениях списка участников, весов подписи или порога адрес аккаунта остаётся неизменным.

Поддерживаются три типа подписи: Secp256k1, P256 и WebAuthn. Поддерживаются M-из-N мультиподписи (для каждого владельца weight=1) и взвешенные мультиподписи (несимметричное делегирование), например владелец с высоким весом (weight=100) может авторизовать отдельно, или два владельца со средним весом (каждый weight=50) могут авторизовать совместно. Каждый мультиподписный аккаунт максимум может иметь 10 владельцев (MAX_MULTISIG_OWNERS=10).

Ограничения дизайна: не поддерживаются AccountKeychain и EIP-7702

TIP-1061 однозначно предписывает, что нативный мультиподписный аккаунт не поддерживает доступ к ключам через AccountKeychain; если msg.sender — нативный мультиподписный аккаунт, то вызов AccountKeychain modifier должен быть отклонён. Обоснование в рамках предложенного дизайна следующее: разрешение вызывать от имени родительского аккаунта с помощью одного ключа авторизации приведёт к тому, что исходный приватный ключ станет постоянной возможностью выступать в роли мультиподписного адреса в любом допустимом диапазоне авторизации, что не соответствует принципу проектирования «контролируемой законом численности участников».

Кроме того, после бутстрапинга нативный мультиподписный аккаунт не должен устанавливать EVM-байткод или делегат-код EIP-7702.

Статус черновика: остаются вопросы, требующие уточнения

В настоящее время предложение остаётся черновиком. Схема подсчёта газа (в документе помечена как «to-do») и адреса предкомпилированных контрактов мультиподписи (они будут назначены до выхода предложения из стадии черновика) пока не окончательно определены. Предложение также устанавливает, что до активации вступления TIP-1061 в силу любые транзакции, содержащие TempoSignature::Multisig, должны быть отклонены; а любые транзакции с полем multisig_init также должны быть отклонены до запуска предложения.

Часто задаваемые вопросы

В чём принципиальная разница между нативной мультиподписью TIP-1061 и контрактными кошельками вроде Safe?

TIP-1061 повышает уровень верификации мультиподписи до протокольного уровня: чтобы получить такую же возможность контроля по порогу, не нужно разворачивать на блокчейне смарт-контрактные кошельки вроде Safe. Это устраняет затраты на деплой контрактов, а адрес аккаунта после вывода из начальной конфигурации остаётся стабильным и не меняется при обновлениях состава участников.

Почему адрес мультиподписного аккаунта может оставаться неизменным после обновления участников?

Адрес мультиподписного аккаунта выводится из хэша config_id, а config_id вычисляется на основе начального набора владельцев (включая адреса, типы подписей и веса) и порога; в течение существования аккаунта он не изменяется. Последующие вызовы updateMultisigConfig обновляют только сохранённую текущую конфигурацию, не меняя сам config_id и, следовательно, не меняя производный адрес аккаунта.

Каковы основные целевые сценарии использования TIP-1061?

В мотивационной части предложения прямо указано, что целевые сценарии — это случаи, когда пользователям нужно, чтобы «ни один одиночный приватный ключ не мог в одностороннем порядке переводить средства или менять конфигурацию операций». В частности, это команды (Teams), финансовые подразделения (Treasury), валидирующие узлы (Validators) и институциональные операторы (Institutional Operators).