Google Cloud classe son service de garde Multi-Party Compute (MPC) en Preview : ses règles de transaction empêchent la signature automatique après un refus, mais des signataires assez nombreux peuvent encore autoriser la transaction. Le 28 octobre 2026, CoinDesk rapportait que plusieurs institutions financières testaient le service en privé et qu’Alphabet l’utilisait pour des actifs sur Ethereum et Solana.
Comment Multi-Party Compute répartit les clés
Multi-Party Compute est une plateforme de garde des clés de signature d’actifs numériques. Elle associe la signature à seuil, des règles appliquées aux transactions et des contrôles de gouvernance. Avec une signature à seuil, plusieurs parties détiennent des parts de clé isolées et les combinent pour signer, sans reconstituer la clé privée complète en un seul endroit. Google décrit ces parties comme indépendantes et protégées par du matériel.
La politique de clé détermine quelles équipes et quels utilisateurs détiennent les parts, combien doivent participer à une signature et où les parts sont conservées : dans Google Cloud, sur les systèmes du client ou sur des appareils mobiles. Une organisation peut, par exemple, demander à deux membres sur trois de son équipe trésorerie de participer. Les rôles distinguent les administrateurs, les auteurs de politiques et les signataires. Google détaille cette architecture dans la présentation officielle de Multi-Party Compute.
Ce qu’un DENY permet encore aux signataires
Les règles de transaction sont évaluées avant l’utilisation des parts de clé. Elles peuvent notamment fixer une limite de dépenses ou autoriser certaines destinations. En l’absence de règle d’autorisation applicable, la transaction est refusée par défaut ; une règle d’interdiction qui correspond à la transaction l’emporte sur une règle d’autorisation.
Un verdict DENY empêche l’instance de signer automatiquement la transaction. Celle-ci reste en attente d’autorisations, et les signataires peuvent l’autoriser malgré le refus si leur nombre atteint le seuil défini par la politique de clé. Le résultat de l’évaluation reste attaché à la transaction pour l’audit. Google explique ce fonctionnement dans sa documentation sur l’évaluation des politiques.
Une limite documentée pour certaines transactions Bitcoin
Une transaction Bitcoin comportant plusieurs destinataires peut être considérée comme une charge utile non reconnue. Dans ce cas, l’instance la refuse sans évaluer les règles de transaction. Le refus intervient donc avant que ces règles puissent accorder ou refuser une autorisation.
Réseaux pris en charge et calendrier envisagé
Google indique ECDSA avec la courbe secp256k1 pour Bitcoin, Ethereum et les réseaux compatibles EVM. La prise en charge de Solana avec EdDSA et Ed25519 est indiquée comme « à venir ». CoinDesk rapportait séparément qu’Alphabet utilisait Multi-Party Compute pour des actifs sur Solana et Ethereum.
La documentation de Google classe le produit en Preview. CoinDesk rapportait également que Google visait une disponibilité commerciale au début de 2027.
