Le blockchain de couche 1 Tempo, co-développée par Stripe et Paradigm, a soumis le 31 mai une proposition TIP-1061 d’un compte multi-signature natif, visant à introduire la multi-signature comme principal type de compte au niveau du protocole sur le réseau. Il ne sera pas nécessaire de déployer des portefeuilles de contrats intelligents tels que Safe pour obtenir un contrôle multi-signature. La proposition TIP-1061 vise principalement des cas d’usage tels que les DAO, les institutions et les nœuds de validation ; elle reste toutefois à l’état de brouillon.
Spécifications techniques confirmées
Le cœur de la conception de TIP-1061 inclut les détails techniques suivants déjà confirmés. L’adresse du compte multi-signature est dérivée du hachage de la configuration initiale (config_id). Par la suite, lorsque la liste des membres, les poids de signature ou le seuil sont ajustés, l’adresse du compte demeure inchangée.
La prise en charge des types de signatures est au nombre de trois : Secp256k1, P256 et WebAuthn. Le protocole prend en charge la multi-signature M-of-N (pour chaque propriétaire weight=1) ainsi que la multi-signature pondérée (autorisations asymétriques). Par exemple, un propriétaire à poids élevé (weight=100) peut autoriser seul, ou deux propriétaires à poids moyens (chacun weight=50) peuvent autoriser conjointement. Chaque compte multi-signature permet au maximum 10 propriétaires (MAX_MULTISIG_OWNERS=10).
Limites de conception : pas de prise en charge d’AccountKeychain et de EIP-7702
TIP-1061 précise clairement que les comptes multi-signature natifs ne prennent pas en charge l’accès aux clés via AccountKeychain ; si msg.sender est un compte multi-signature natif, l’appel d’un modificateur AccountKeychain doit être refusé. La raison de la conception de la proposition est la suivante : autoriser une clé d’autorisation unique à appeler en tant qu’« account parent » transformerait une clé privée d’origine en capacité permanente à agir comme adresse multi-signature dans toute portée d’autorisation. Cela ne correspond pas au principe de conception d’une « identité contrôlée par un nombre légal de participants ».
En outre, après le bootstrap, les comptes multi-signature natifs ne doivent pas installer de bytecode EVM ni de code de délégation EIP-7702.
Statut du brouillon : points encore à confirmer
La proposition est encore à l’état de brouillon. Le schéma de comptage du gas (le document indique « à faire ») ainsi que l’adresse des contrats précompilés de la multi-signature (qui sera attribuée avant que la proposition ne sorte de l’état de brouillon) n’ont pas encore été finalisés. La proposition stipule que, avant l’entrée en vigueur du lancement de TIP-1061, toutes les transactions contenant TempoSignature::Multisig doivent être rejetées ; toutes les transactions portant le champ multisig_init doivent également être rejetées avant le lancement de la proposition.
Questions fréquentes
Quelle est la différence fondamentale entre la multi-signature native de TIP-1061 et des portefeuilles de contrats tels que Safe ?
TIP-1061 élève la validation de la multi-signature au niveau du protocole. Il n’est pas nécessaire de déployer des portefeuilles de contrats tels que Safe sur la chaîne pour obtenir les mêmes capacités de contrôle par seuil. Cela élimine les coûts de déploiement de contrats, et l’adresse du compte reste stable après dérivation à partir de la configuration initiale, sans changer avec la mise à jour des membres.
Pourquoi l’adresse du compte multi-signature peut-elle rester inchangée après des mises à jour des membres ?
L’adresse du compte multi-signature est dérivée du hachage de config_id. Or config_id est calculé à partir de l’ensemble initial de propriétaires (incluant l’adresse, le type de signature et le poids) ainsi que du seuil. Pendant toute la durée de vie du compte, cela ne change pas. Les appels updateMultisigConfig ultérieurs ne font que mettre à jour la configuration courante stockée, sans modifier config_id lui-même ni l’adresse du compte qui en est dérivée.
Quels sont les principaux cas d’usage visés par TIP-1061 ?
Dans la section « motivation », la proposition indique clairement que les cas visés sont ceux où l’on a besoin que « aucune clé privée unique ne puisse transférer des fonds de manière unilatérale ni modifier la configuration opérationnelle ». Cela inclut notamment les équipes (Teams), les départements financiers (Treasury), les nœuds de validation (Validators) et les opérateurs institutionnels (Institutional Operators).
