Пропозиція Tempo щодо TIP-1061 запроваджує нативні мультипідписні акаунти протоколу на рівні протоколу, без необхідності розгортати контракти на кшталт Safe

Layer 1 блокчейн Tempo, який спільно розробляють Stripe і Paradigm, 31 травня подав пропозицію TIP-1061 щодо нативних мультипідписних облікових записів, прагнучи запровадити мультипідпис як основний тип облікових записів на рівні протоколу в мережі. Для реалізації контролю мультипідпису не потрібно розгортати, наприклад, Safe чи інші смартконтракти-гаманці. TIP-1061 насамперед орієнтований на сценарії використання на кшталт DAO, інституцій та валідаційних вузлів, і наразі перебуває на етапі чернетки.

Уже підтверджені технічні специфікації

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

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

Обмеження дизайну: не підтримуються AccountKeychain і EIP-7702

TIP-1061 однозначно визначає, що нативні мультипідписні облікові записи не підтримують доступ до ключів через AccountKeychain; якщо msg.sender є нативним мультипідписним обліковим записом, виклик модифікатора AccountKeychain має бути відхилений. Аргументом у дизайні пропозиції є те, що дозвіл одній авторизаційній ключовій сутності робити виклики від імені батьківського облікового запису перетворює один первинний приватний ключ на сталу здатність діяти як мультипідписна адреса в межах будь-якого авторизаційного діапазону, що не відповідає принципу дизайну «контроль ідентичності законною кількістю людей».

Крім того, нативний мультипідписний обліковий запис після ініціалізації (Bootstrap) не може встановлювати EVM байткод або делегований код EIP-7702.

Стан чернетки: питання, що ще належить уточнити

Наразі пропозиція все ще є чернеткою: схема обліку gas (у документі позначена як «потрібно визначити») і адреса попередньо скомпільованих контрактів для мультипідпису (її буде призначено перед виходом пропозиції з чернетки) — обидва ще не фіналізовані. Пропозиція також встановлює, що до моменту запуску й набрання чинності 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).