Dans le monde de Web3, la gestion des clés privées est une question de vie ou de mort. Une fois que la clé privée du portefeuille est volée ou perdue, des millions de dollars d'actifs peuvent disparaître en un instant. Cependant, la grande majorité des gens ont l'habitude d'adopter une gestion des clés privées centralisée, ce qui est comme mettre tous ses œufs dans le même panier, risquant à tout moment de donner tous ses actifs à un hacker en cliquant sur un lien de phishing.
Pour faire face à ce problème, divers types de solutions ont émergé dans le domaine de la blockchain. Des portefeuilles multi-signatures à la MPC, en passant par le CRVA proposé par le projet DeepSafe, chaque avancée technologique ouvre de nouvelles voies pour la gestion des actifs. Cet article explorera les principes, caractéristiques et scénarios d'application des trois solutions de gestion d'actifs mentionnées ci-dessus, afin d'aider les lecteurs à choisir le chemin qui leur convient le mieux.
Portefeuille multi-signatures : acceptable, mais pas excellent
Le concept de portefeuille multi-signatures découle d'une sagesse simple : ne pas concentrer tous les pouvoirs en un seul endroit. Cette idée est déjà largement appliquée dans la réalité, comme la séparation des pouvoirs et le vote des conseils d'administration.
De même, dans Web3, un portefeuille multi-signatures crée plusieurs clés indépendantes pour répartir les risques. Le modèle le plus courant est le mode “M-of-N”, par exemple dans un paramétrage “2-of-3”, le système génère au total trois clés privées, mais tant que deux de ces clés privées signent, le compte désigné peut exécuter la transaction.
Ce design offre une certaine tolérance aux pannes - même si une clé privée est perdue, les actifs restent sécurisés et contrôlables. Si vous disposez de plusieurs dispositifs indépendants pour stocker les clés, une solution multi-signatures sera plus fiable.
En général, les portefeuilles multi-signatures se divisent techniquement en deux catégories. L'une est la multi-signature classique, qui utilise généralement des contrats intelligents sur la chaîne ou des composants d'infrastructure de la blockchain pour être mise en œuvre, et ne dépend souvent pas d'outils cryptographiques spécifiques. L'autre est le portefeuille multi-signature qui repose sur des algorithmes cryptographiques spéciaux, dont la sécurité dépend de l'algorithme spécifique, et parfois, il peut fonctionner sans aucune participation de contrats sur la chaîne. Nous allons maintenant discuter séparément des deux solutions.
Le plan de multi-signature standard représente : portefeuille Safe et Taproot Bitcoin
Le portefeuille Safe, en tant que l'une des solutions multi-signatures les plus populaires actuellement, utilise des contrats intelligents Solidity conventionnels pour mettre en œuvre la signature multiple. Dans l'architecture du portefeuille Safe, chaque participant à la multi-signature contrôle une clé indépendante, tandis que le contrat intelligent sur la chaîne agit en tant qu'“arbitre”, n'approuvant l'exécution des transactions par le compte associé à la multi-signature que lorsque suffisamment de signatures valides ont été collectées.
L'avantage de cette méthode réside dans la transparence et la vérifiabilité, toutes les règles de multi-signature étant clairement codées dans le contrat intelligent, permettant à quiconque d'auditer la logique du code. De plus, les utilisateurs peuvent ajouter des modules aux comptes multi-signatures, leur conférant des fonctionnalités plus riches, telles que la restriction du montant maximum pour chaque transaction. Cependant, cette transparence signifie également que les détails des portefeuilles multi-signatures sont complètement publics sur la blockchain, ce qui pourrait exposer la structure de gestion des actifs des utilisateurs.
En dehors des portefeuilles Safe, qui sont une solution de multisig bien connue dans l'écosystème Ethereum, il existe également des portefeuilles multisig construits sur le réseau Bitcoin utilisant des scripts BTC, comme les solutions basées sur l'opcode OP_CHECKMULTISIG. Cet opcode peut vérifier si le nombre de signatures inclus dans le script de déverrouillage UTXO satisfait aux exigences.
Il est important de noter que les algorithmes de multi-signature conventionnels décrits ci-dessus prennent tous en charge le “M-of-N”, mais certains des multi-signatures basés sur des algorithmes cryptographiques spécifiques présentés plus loin ne prennent en charge que le mode “M-of-M”, c'est-à-dire que l'utilisateur doit fournir toutes les clés pour effectuer une transaction.
Mise en œuvre de la multi-signature au niveau cryptographique
Au niveau cryptographique, il est possible d'implémenter l'effet de vérification multi-signature par des algorithmes cryptographiques spécifiques, et cette solution peut parfois se passer de l'intervention des contrats intelligents sur la chaîne. Nous avons souvent tendance à effectuer la classification suivante :
1.Algorithme de multisignatures (Multisignatures). Cet algorithme de signature ne prend en charge que le mode “M-of-M”, les utilisateurs doivent soumettre toutes les signatures correspondant aux clés en une seule fois.
Algorithme de signature de seuil (Signatures de seuil). Cet algorithme prend en charge le mode “M-of-N”, mais en général, la difficulté de construction est plus complexe que celle des algorithmes de signature multiple mentionnés ci-dessus.
Algorithme de partage de clé ( Secret sharing ). Dans la conception de cet algorithme, l'utilisateur peut diviser une clé privée unique en plusieurs morceaux, et lorsque l'utilisateur a collecté suffisamment de fragments de clés privées, il peut restaurer la clé privée d'origine et générer une signature.
Le Bitcoin a introduit l'algorithme Schnorr après la mise à niveau SegWit (, ce qui permet naturellement de réaliser des validations multi-signatures. La couche de consensus d'Ethereum utilise l'algorithme de seuil BLS pour réaliser la fonctionnalité de vote la plus essentielle au sein du système PoS.
Ce schéma de multi-signature qui repose uniquement sur des algorithmes cryptographiques a une meilleure compatibilité, car il peut être mis en œuvre sans dépendre de contrats intelligents, par exemple en utilisant une solution totalement hors chaîne.
Les signatures générées par un schéma de multi-signature purement cryptographique sont exactement identiques en termes de format à celles des signatures utilisant une seule clé privée, et peuvent être acceptées par toute blockchain supportant le format standard de signature, ce qui leur confère une grande polyvalence. Cependant, les algorithmes de multi-signature basés sur une cryptographie spécifique sont relativement complexes et leur mise en œuvre est très difficile, ce qui nécessite souvent de s'appuyer sur certaines infrastructures spécifiques lors de leur utilisation.
Les défis réels de la technologie multisignature
Bien que les portefeuilles multi-signatures courants améliorent considérablement la sécurité des actifs, ils introduisent également de nouveaux risques. Le problème le plus évident est l'augmentation de la complexité opérationnelle : chaque transaction nécessite une coordination et une confirmation de plusieurs parties, ce qui devient un obstacle majeur dans des scénarios sensibles au temps.
Plus grave encore, les portefeuilles multi-signatures transfèrent souvent le risque de la gestion des clés privées à la coordination et à la vérification des signatures. Comme l'a montré le récent vol chez Bybit, les attaquants ont réussi à tromper les gestionnaires multi-signatures de Bybit en injectant du code d'interface frontale Safe de phishing dans les installations AWS sur lesquelles Safe dépendait, les amenant à signer des transactions de phishing. Cela montre que, même avec des technologies multi-signatures avancées, la sécurité de l'interface frontale et des étapes de vérification et de coordination des signatures reste vulnérable.
De plus, tous les algorithmes de signature utilisés par les blockchains ne prennent pas en charge nativement les signatures multiples. Par exemple, l'algorithme sur la courbe secp 256 k 1 utilisé par la couche d'exécution d'Ethereum présente rarement des algorithmes de signatures multiples, ce qui limite l'application des portefeuilles multi-signatures dans différents écosystèmes. Pour les réseaux qui nécessitent la mise en œuvre de signatures multiples via des contrats intelligents, il existe également des considérations supplémentaires telles que les vulnérabilités des contrats et les risques de mise à niveau.
MPC : percée révolutionnaire
Si l'on considère que le portefeuille multi-signatures améliore la sécurité en répartissant les clés privées, la technologie MPC (calcul sécurisé multipartite) va encore plus loin en éliminant fondamentalement l'existence de la clé privée complète. Dans le monde de MPC, la clé privée complète n'apparaît jamais à un seul endroit, même pas durant le processus de génération de clés. De plus, le MPC prend souvent en charge des fonctions plus avancées, telles que le rafraîchissement des clés privées ou l'ajustement des permissions.
Dans le cadre des applications de la cryptomonnaie, le flux de travail de la MPC présente des avantages uniques. Lors de la phase de génération de clés, plusieurs parties génèrent chacune des nombres aléatoires, puis, via des protocoles cryptographiques complexes, chaque partie calcule son propre “fragment de clé”. Ces parts n'ont aucune signification individuelle, mais elles sont mathématiquement interconnectées et peuvent ensemble correspondre à une clé publique et une adresse de portefeuille spécifiques.
Lorsque vous devez signer une opération sur la chaîne, chaque partie impliquée peut utiliser ses propres fragments de clé pour générer une “signature partielle”, puis combiner habilement ces signatures partielles via le protocole MPC. La signature finale générée est identique en format à celle d'une clé privée unique, et les observateurs externes ne peuvent même pas distinguer qu'il s'agit d'une signature générée par l'installation MPC.
La révolution de ce design réside dans le fait que la clé privée complète n'est jamais apparue nulle part tout au long du processus. Même si un attaquant réussit à infiltrer le système d'une partie participante, il ne pourra pas obtenir la clé privée complète, car cette clé n'existe essentiellement nulle part.
La différence essentielle entre MPC et la signature multiple
Bien que le MPC et la signature multiple impliquent tous deux la participation de plusieurs parties, il existe des différences fondamentales entre les deux. D'un point de vue externe, les transactions générées par le MPC sont indiscernables des transactions ordinaires à signature unique, ce qui offre une meilleure confidentialité aux utilisateurs.
Cette différence se manifeste également en termes de compatibilité. Les portefeuilles multi-signatures nécessitent un soutien natif du réseau blockchain ou dépendent des contrats intelligents, ce qui limite leur utilisation dans certains endroits. En revanche, les signatures générées par MPC utilisent le format ECDSA standard, ce qui permet de les utiliser partout où cet algorithme de signature est pris en charge, y compris sur Bitcoin, Ethereum et diverses plateformes DeFi.
La technologie MPC offre également une plus grande flexibilité pour ajuster les paramètres de sécurité. Dans un portefeuille multi-signatures traditionnel, modifier le seuil de signature ou le nombre de participants nécessite généralement la création d'une nouvelle adresse de portefeuille, ce qui présente des risques. ) Bien sûr, un portefeuille multi-signatures basé sur des contrats intelligents peut facilement modifier les participants et leurs autorisations (, tandis que dans un système MPC, ces ajustements de paramètres peuvent être réalisés de manière plus flexible et simplifiée, sans avoir à modifier les comptes et le code des contrats sur la chaîne, offrant ainsi une plus grande commodité pour la gestion des actifs.
Défis auxquels est confronté le MPC
Cependant, bien que le MPC soit supérieur à une simple multi-signature, il présente néanmoins des défis correspondants. Tout d'abord, il y a la complexité de sa mise en œuvre. Le protocole MPC implique des calculs cryptographiques complexes et des communications multipartites, ce qui rend la mise en œuvre et la maintenance du système plus difficiles. Tout bug peut entraîner des vulnérabilités de sécurité graves. En février 2025, Nikolaos Makriyannis et d'autres ont découvert une méthode pour voler ses clés à l'intérieur d'un portefeuille MPC.
Les coûts de performance sont un autre défi. Le protocole MPC nécessite des calculs complexes et des échanges de données entre plusieurs parties, consommant plus de ressources informatiques et de bande passante réseau que les opérations de signature unique traditionnelles. Bien que ce coût soit acceptable dans la plupart des cas, il peut devenir un facteur limitant dans certaines situations où les exigences de performance sont extrêmement élevées. De plus, le système MPC nécessite toujours une coordination en ligne entre toutes les parties participantes pour compléter la signature. Bien que cette coordination soit transparente pour l'utilisateur, elle peut affecter la disponibilité du système en cas de connexion réseau instable ou si certaines parties sont hors ligne.
De plus, le MPC ne peut toujours pas garantir la décentralisation. Dans l'affaire Multichain de 2023, les 21 nœuds participant au calcul MPC étaient tous contrôlés par une seule personne, ce qui constitue une attaque de sorcière typique. Cela suffit à prouver que plusieurs nœuds en apparence ne peuvent pas offrir une garantie de décentralisation élevée.
DeepSafe : Construire le réseau de validation de sécurité de nouvelle génération
Dans un contexte où les technologies de multi-signatures et de MPC sont déjà relativement matures, l'équipe de DeepSafe propose une solution plus prospective : CRVA (Agent de Vérification Aléatoire Cryptographique). L'innovation de DeepSafe réside dans le fait qu'elle ne remplace pas simplement les technologies de signature existantes, mais qu'elle construit une couche de vérification de sécurité supplémentaire sur la base des solutions existantes.
Validation multi-facteurs de CRVA
La pensée centrale de DeepSafe est “double assurance” : les utilisateurs peuvent continuer à utiliser leurs solutions de portefeuille familières, comme le portefeuille Safe. Lorsqu'une transaction à signature multiple est soumise à la chaîne, elle est automatiquement envoyée au réseau CRVA pour une vérification supplémentaire, similaire à la vérification à deux facteurs 2FA d'Alipay.
Dans cette architecture, le CRVA agit en tant que gardien, vérifiant chaque transaction selon les règles définies à l'avance par l'utilisateur. Par exemple, des limites sur le montant des transactions individuelles, une liste blanche d'adresses cibles, des restrictions sur la fréquence des transactions, etc. En cas de situation anormale, la transaction peut être interrompue à tout moment.
L'avantage de cette authentification à deux facteurs (2FA) est que même si le processus de signature multiple est manipulé (comme lors de l'attaque de phishing frontale de l'événement Bybit), le CRVA, en tant qu'assurance, peut toujours refuser les transactions à risque selon des règles prédéfinies, protégeant ainsi la sécurité des actifs des utilisateurs.
Amélioration technologique basée sur des solutions MPC traditionnelles
Pour pallier les insuffisances des solutions de gestion d'actifs MPC traditionnelles, la solution CRVA de DeepSafe a apporté de nombreuses améliorations. Tout d'abord, les nœuds du réseau CRVA adoptent une forme d'admission par mise en gage d'actifs, et le réseau principal ne sera officiellement lancé qu'après avoir atteint environ 500 nœuds. Selon les estimations, les actifs mis en gage par ces nœuds resteront à long terme à plusieurs dizaines de millions de dollars ou plus ;
Deuxièmement, afin d'améliorer l'efficacité du calcul MPC/TSS, CRVA sélectionnera aléatoirement des nœuds par un algorithme de tirage au sort, par exemple en tirant 10 nœuds toutes les demi-heures, qui agiront en tant que validateurs pour vérifier si les demandes des utilisateurs doivent être approuvées, puis généreront la signature de seuil correspondante pour autoriser l'accès. Pour empêcher la collusion interne ou les attaques de hackers externes, l'algorithme de tirage au sort de CRVA utilise un VRF en anneau original, combiné avec ZK pour masquer l'identité des sélectionnés, de sorte que l'extérieur ne puisse pas observer directement les candidats sélectionnés.
Bien sûr, faire seulement cela n'est pas suffisant. Bien que le public ne sache pas qui a été sélectionné, la personne choisie le sait, il existe donc toujours une voie de complot. Pour éliminer davantage les conspirations, tous les nœuds de CRVA doivent exécuter le code source dans un environnement matériel TEE, ce qui équivaut à effectuer le travail principal dans une boîte noire. Ainsi, personne ne peut savoir s'il a été sélectionné, à moins qu'il ne puisse pirater le matériel de confiance TEE, ce qui est bien sûr très difficile à réaliser compte tenu des conditions techniques actuelles.
Ce qui a été mentionné ci-dessus est l'idée de base de la solution CRVA de DeepSafe. Dans le processus de travail réel, les nœuds au sein du réseau CRVA doivent effectuer un grand nombre de communications par diffusion et d'échanges d'informations. Le processus spécifique est le suivant :
Tous les nœuds doivent d'abord staker des actifs sur la chaîne avant d'entrer dans le réseau CRVA, en laissant une clé publique comme information d'enregistrement. Cette clé publique est également appelée « clé publique permanente ».
Chaque heure, le réseau CRVA sélectionne aléatoirement quelques nœuds. Mais avant cela, tous les candidats doivent générer localement une « clé publique temporaire » unique, tout en générant un ZKP pour prouver que la « clé publique temporaire » est liée à la « clé publique permanente » enregistrée sur la chaîne ; en d'autres termes, chacun doit prouver par ZK qu'il existe sur la liste des candidats sans révéler qui il est ;
Le rôle de la « clé publique temporaire » réside dans la protection de la vie privée. Si l'on tire directement au sort parmi l'ensemble des « clés publiques permanentes », lors de l'annonce des résultats, tout le monde saura directement qui a été élu. Si chacun ne dévoile qu'une « clé publique temporaire » unique, puis que l'on choisit quelques personnes parmi l'ensemble des « clés publiques temporaires », vous saurez au maximum que vous avez gagné, mais vous ne saurez pas à qui correspondent les autres clés publiques temporaires gagnantes.
Afin de prévenir davantage la divulgation d'identité, CRVA prévoit de faire en sorte que vous ne sachiez même pas ce qu'est votre « clé publique temporaire ». Le processus de génération de la clé publique temporaire se déroule dans l'environnement TEE du nœud, et vous, qui exécutez le TEE, ne pouvez pas voir ce qui se passe à l'intérieur.
Ensuite, dans le TEE, le texte en clair de la clé publique temporaire est chiffré en « caractères aléatoires » avant d'être envoyé à l'extérieur, seul des nœuds Relayer spécifiques peuvent le déchiffrer. Bien sûr, le processus de déchiffrement se déroule également dans l'environnement TEE du nœud Relayer, et le Relayer ne sait pas à quels candidats ces clés publiques temporaires correspondent.
Le Relayer, après avoir restauré toutes les « clés publiques temporaires », les regroupe et les soumet à la fonction VRF sur la chaîne, à partir de laquelle les gagnants sont tirés. Ces personnes vérifient les demandes de transaction envoyées par l'interface utilisateur, puis, en fonction des résultats de la vérification, génèrent une signature de seuil, qui est enfin soumise à la chaîne. (Il convient de noter que, ici, le Relayer est en réalité également masqué et sélectionné périodiquement.)
Il se peut que certaines personnes se demandent, puisque chaque nœud ne sait pas s'il a été sélectionné, comment le travail peut-il continuer ? En fait, comme mentionné précédemment, chacun générera une « clé publique temporaire » dans son environnement TEE local. Une fois que les résultats du tirage au sort sont disponibles, nous diffusons directement la liste. Il suffit que chacun transmette la liste dans le TEE, et à l'intérieur, il peut vérifier s'il a été sélectionné.
Le cœur de la solution DeepSafe réside dans le fait que presque toutes les activités importantes se déroulent à l'intérieur du matériel TEE, rendant impossible l'observation de ce qui se passe de l'extérieur du TEE. Chaque nœud ne sait pas qui sont les validateurs sélectionnés, ce qui empêche toute collusion malveillante et augmente considérablement le coût des attaques externes. Pour attaquer le comité CRVA basé sur DeepSafe, il faudrait théoriquement attaquer l'ensemble du réseau CRVA, d'autant plus que chaque nœud est protégé par TEE, rendant l'attaque beaucoup plus difficile.
En ce qui concerne les comportements malveillants de CRVA, étant donné que CRVA est un système de réseau de nœuds fonctionnant de manière automatisée, tant que le code lors de son démarrage initial ne contient pas de logique malveillante, il n'y aura pas de situation où CRVA refuse activement de coopérer avec l'utilisateur, donc cela peut être essentiellement ignoré.
Si le CRVA subit une panne d'électricité, une inondation ou d'autres événements de force majeure entraînant l'arrêt massif des nœuds, les utilisateurs ont toujours la possibilité de retirer leurs actifs en toute sécurité selon le processus mentionné dans le plan ci-dessus. L'hypothèse de confiance ici est que nous avons suffisamment confiance en la décentralisation du CRVA pour qu'il ne prenne pas l'initiative de nuire (la raison a déjà été suffisamment expliquée précédemment).
Résumé
L'évolution de la technologie de signature Web3 montre l'exploration incessante de l'humanité dans le domaine de la sécurité numérique. Des premières clés privées uniques, aux portefeuilles multisignatures, en passant par le MPC et les nouvelles solutions telles que le CRVA, chaque avancée ouvre de nouvelles possibilités pour la gestion sécurisée des actifs numériques.
Cependant, les avancées technologiques ne signifient pas l'élimination des risques. Chaque nouvelle technologie, tout en résolvant des problèmes existants, peut également introduire de nouvelles complexités et points de risque. L'événement de Bybit nous montre que même avec l'utilisation de technologies avancées de signature multiple, des attaquants peuvent toujours contourner les protections techniques par l'ingénierie sociale et des attaques de la chaîne d'approvisionnement. Cela nous rappelle que les solutions technologiques doivent être associées à de bonnes pratiques opérationnelles et à une sensibilisation à la sécurité.
Finalement, la sécurité des actifs numériques n'est pas seulement un problème technique, mais aussi un défi systémique. Que ce soit par la multi-signature, le MPC, ou le CRVA, ce ne sont que des solutions tentatives face aux risques potentiels. Avec le développement de l'industrie de la blockchain, il sera nécessaire à l'avenir de continuer à innover et à rechercher des solutions plus sûres et sans confiance.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Comparaison des solutions de gestion d'actifs Web3 : multisignature, MPC et CRVA
Rédaction : Shew, Xianrang
Dans le monde de Web3, la gestion des clés privées est une question de vie ou de mort. Une fois que la clé privée du portefeuille est volée ou perdue, des millions de dollars d'actifs peuvent disparaître en un instant. Cependant, la grande majorité des gens ont l'habitude d'adopter une gestion des clés privées centralisée, ce qui est comme mettre tous ses œufs dans le même panier, risquant à tout moment de donner tous ses actifs à un hacker en cliquant sur un lien de phishing.
Pour faire face à ce problème, divers types de solutions ont émergé dans le domaine de la blockchain. Des portefeuilles multi-signatures à la MPC, en passant par le CRVA proposé par le projet DeepSafe, chaque avancée technologique ouvre de nouvelles voies pour la gestion des actifs. Cet article explorera les principes, caractéristiques et scénarios d'application des trois solutions de gestion d'actifs mentionnées ci-dessus, afin d'aider les lecteurs à choisir le chemin qui leur convient le mieux.
Portefeuille multi-signatures : acceptable, mais pas excellent
Le concept de portefeuille multi-signatures découle d'une sagesse simple : ne pas concentrer tous les pouvoirs en un seul endroit. Cette idée est déjà largement appliquée dans la réalité, comme la séparation des pouvoirs et le vote des conseils d'administration.
De même, dans Web3, un portefeuille multi-signatures crée plusieurs clés indépendantes pour répartir les risques. Le modèle le plus courant est le mode “M-of-N”, par exemple dans un paramétrage “2-of-3”, le système génère au total trois clés privées, mais tant que deux de ces clés privées signent, le compte désigné peut exécuter la transaction.
Ce design offre une certaine tolérance aux pannes - même si une clé privée est perdue, les actifs restent sécurisés et contrôlables. Si vous disposez de plusieurs dispositifs indépendants pour stocker les clés, une solution multi-signatures sera plus fiable.
En général, les portefeuilles multi-signatures se divisent techniquement en deux catégories. L'une est la multi-signature classique, qui utilise généralement des contrats intelligents sur la chaîne ou des composants d'infrastructure de la blockchain pour être mise en œuvre, et ne dépend souvent pas d'outils cryptographiques spécifiques. L'autre est le portefeuille multi-signature qui repose sur des algorithmes cryptographiques spéciaux, dont la sécurité dépend de l'algorithme spécifique, et parfois, il peut fonctionner sans aucune participation de contrats sur la chaîne. Nous allons maintenant discuter séparément des deux solutions.
Le plan de multi-signature standard représente : portefeuille Safe et Taproot Bitcoin
Le portefeuille Safe, en tant que l'une des solutions multi-signatures les plus populaires actuellement, utilise des contrats intelligents Solidity conventionnels pour mettre en œuvre la signature multiple. Dans l'architecture du portefeuille Safe, chaque participant à la multi-signature contrôle une clé indépendante, tandis que le contrat intelligent sur la chaîne agit en tant qu'“arbitre”, n'approuvant l'exécution des transactions par le compte associé à la multi-signature que lorsque suffisamment de signatures valides ont été collectées.
L'avantage de cette méthode réside dans la transparence et la vérifiabilité, toutes les règles de multi-signature étant clairement codées dans le contrat intelligent, permettant à quiconque d'auditer la logique du code. De plus, les utilisateurs peuvent ajouter des modules aux comptes multi-signatures, leur conférant des fonctionnalités plus riches, telles que la restriction du montant maximum pour chaque transaction. Cependant, cette transparence signifie également que les détails des portefeuilles multi-signatures sont complètement publics sur la blockchain, ce qui pourrait exposer la structure de gestion des actifs des utilisateurs.
En dehors des portefeuilles Safe, qui sont une solution de multisig bien connue dans l'écosystème Ethereum, il existe également des portefeuilles multisig construits sur le réseau Bitcoin utilisant des scripts BTC, comme les solutions basées sur l'opcode OP_CHECKMULTISIG. Cet opcode peut vérifier si le nombre de signatures inclus dans le script de déverrouillage UTXO satisfait aux exigences.
Il est important de noter que les algorithmes de multi-signature conventionnels décrits ci-dessus prennent tous en charge le “M-of-N”, mais certains des multi-signatures basés sur des algorithmes cryptographiques spécifiques présentés plus loin ne prennent en charge que le mode “M-of-M”, c'est-à-dire que l'utilisateur doit fournir toutes les clés pour effectuer une transaction.
Mise en œuvre de la multi-signature au niveau cryptographique
Au niveau cryptographique, il est possible d'implémenter l'effet de vérification multi-signature par des algorithmes cryptographiques spécifiques, et cette solution peut parfois se passer de l'intervention des contrats intelligents sur la chaîne. Nous avons souvent tendance à effectuer la classification suivante :
1.Algorithme de multisignatures (Multisignatures). Cet algorithme de signature ne prend en charge que le mode “M-of-M”, les utilisateurs doivent soumettre toutes les signatures correspondant aux clés en une seule fois.
Algorithme de signature de seuil (Signatures de seuil). Cet algorithme prend en charge le mode “M-of-N”, mais en général, la difficulté de construction est plus complexe que celle des algorithmes de signature multiple mentionnés ci-dessus.
Algorithme de partage de clé ( Secret sharing ). Dans la conception de cet algorithme, l'utilisateur peut diviser une clé privée unique en plusieurs morceaux, et lorsque l'utilisateur a collecté suffisamment de fragments de clés privées, il peut restaurer la clé privée d'origine et générer une signature.
Le Bitcoin a introduit l'algorithme Schnorr après la mise à niveau SegWit (, ce qui permet naturellement de réaliser des validations multi-signatures. La couche de consensus d'Ethereum utilise l'algorithme de seuil BLS pour réaliser la fonctionnalité de vote la plus essentielle au sein du système PoS.
Ce schéma de multi-signature qui repose uniquement sur des algorithmes cryptographiques a une meilleure compatibilité, car il peut être mis en œuvre sans dépendre de contrats intelligents, par exemple en utilisant une solution totalement hors chaîne.
Les signatures générées par un schéma de multi-signature purement cryptographique sont exactement identiques en termes de format à celles des signatures utilisant une seule clé privée, et peuvent être acceptées par toute blockchain supportant le format standard de signature, ce qui leur confère une grande polyvalence. Cependant, les algorithmes de multi-signature basés sur une cryptographie spécifique sont relativement complexes et leur mise en œuvre est très difficile, ce qui nécessite souvent de s'appuyer sur certaines infrastructures spécifiques lors de leur utilisation.
Les défis réels de la technologie multisignature
Bien que les portefeuilles multi-signatures courants améliorent considérablement la sécurité des actifs, ils introduisent également de nouveaux risques. Le problème le plus évident est l'augmentation de la complexité opérationnelle : chaque transaction nécessite une coordination et une confirmation de plusieurs parties, ce qui devient un obstacle majeur dans des scénarios sensibles au temps.
Plus grave encore, les portefeuilles multi-signatures transfèrent souvent le risque de la gestion des clés privées à la coordination et à la vérification des signatures. Comme l'a montré le récent vol chez Bybit, les attaquants ont réussi à tromper les gestionnaires multi-signatures de Bybit en injectant du code d'interface frontale Safe de phishing dans les installations AWS sur lesquelles Safe dépendait, les amenant à signer des transactions de phishing. Cela montre que, même avec des technologies multi-signatures avancées, la sécurité de l'interface frontale et des étapes de vérification et de coordination des signatures reste vulnérable.
De plus, tous les algorithmes de signature utilisés par les blockchains ne prennent pas en charge nativement les signatures multiples. Par exemple, l'algorithme sur la courbe secp 256 k 1 utilisé par la couche d'exécution d'Ethereum présente rarement des algorithmes de signatures multiples, ce qui limite l'application des portefeuilles multi-signatures dans différents écosystèmes. Pour les réseaux qui nécessitent la mise en œuvre de signatures multiples via des contrats intelligents, il existe également des considérations supplémentaires telles que les vulnérabilités des contrats et les risques de mise à niveau.
MPC : percée révolutionnaire
Si l'on considère que le portefeuille multi-signatures améliore la sécurité en répartissant les clés privées, la technologie MPC (calcul sécurisé multipartite) va encore plus loin en éliminant fondamentalement l'existence de la clé privée complète. Dans le monde de MPC, la clé privée complète n'apparaît jamais à un seul endroit, même pas durant le processus de génération de clés. De plus, le MPC prend souvent en charge des fonctions plus avancées, telles que le rafraîchissement des clés privées ou l'ajustement des permissions.
Dans le cadre des applications de la cryptomonnaie, le flux de travail de la MPC présente des avantages uniques. Lors de la phase de génération de clés, plusieurs parties génèrent chacune des nombres aléatoires, puis, via des protocoles cryptographiques complexes, chaque partie calcule son propre “fragment de clé”. Ces parts n'ont aucune signification individuelle, mais elles sont mathématiquement interconnectées et peuvent ensemble correspondre à une clé publique et une adresse de portefeuille spécifiques.
Lorsque vous devez signer une opération sur la chaîne, chaque partie impliquée peut utiliser ses propres fragments de clé pour générer une “signature partielle”, puis combiner habilement ces signatures partielles via le protocole MPC. La signature finale générée est identique en format à celle d'une clé privée unique, et les observateurs externes ne peuvent même pas distinguer qu'il s'agit d'une signature générée par l'installation MPC.
La révolution de ce design réside dans le fait que la clé privée complète n'est jamais apparue nulle part tout au long du processus. Même si un attaquant réussit à infiltrer le système d'une partie participante, il ne pourra pas obtenir la clé privée complète, car cette clé n'existe essentiellement nulle part.
La différence essentielle entre MPC et la signature multiple
Bien que le MPC et la signature multiple impliquent tous deux la participation de plusieurs parties, il existe des différences fondamentales entre les deux. D'un point de vue externe, les transactions générées par le MPC sont indiscernables des transactions ordinaires à signature unique, ce qui offre une meilleure confidentialité aux utilisateurs.
Cette différence se manifeste également en termes de compatibilité. Les portefeuilles multi-signatures nécessitent un soutien natif du réseau blockchain ou dépendent des contrats intelligents, ce qui limite leur utilisation dans certains endroits. En revanche, les signatures générées par MPC utilisent le format ECDSA standard, ce qui permet de les utiliser partout où cet algorithme de signature est pris en charge, y compris sur Bitcoin, Ethereum et diverses plateformes DeFi.
La technologie MPC offre également une plus grande flexibilité pour ajuster les paramètres de sécurité. Dans un portefeuille multi-signatures traditionnel, modifier le seuil de signature ou le nombre de participants nécessite généralement la création d'une nouvelle adresse de portefeuille, ce qui présente des risques. ) Bien sûr, un portefeuille multi-signatures basé sur des contrats intelligents peut facilement modifier les participants et leurs autorisations (, tandis que dans un système MPC, ces ajustements de paramètres peuvent être réalisés de manière plus flexible et simplifiée, sans avoir à modifier les comptes et le code des contrats sur la chaîne, offrant ainsi une plus grande commodité pour la gestion des actifs.
Défis auxquels est confronté le MPC
Cependant, bien que le MPC soit supérieur à une simple multi-signature, il présente néanmoins des défis correspondants. Tout d'abord, il y a la complexité de sa mise en œuvre. Le protocole MPC implique des calculs cryptographiques complexes et des communications multipartites, ce qui rend la mise en œuvre et la maintenance du système plus difficiles. Tout bug peut entraîner des vulnérabilités de sécurité graves. En février 2025, Nikolaos Makriyannis et d'autres ont découvert une méthode pour voler ses clés à l'intérieur d'un portefeuille MPC.
Les coûts de performance sont un autre défi. Le protocole MPC nécessite des calculs complexes et des échanges de données entre plusieurs parties, consommant plus de ressources informatiques et de bande passante réseau que les opérations de signature unique traditionnelles. Bien que ce coût soit acceptable dans la plupart des cas, il peut devenir un facteur limitant dans certaines situations où les exigences de performance sont extrêmement élevées. De plus, le système MPC nécessite toujours une coordination en ligne entre toutes les parties participantes pour compléter la signature. Bien que cette coordination soit transparente pour l'utilisateur, elle peut affecter la disponibilité du système en cas de connexion réseau instable ou si certaines parties sont hors ligne.
De plus, le MPC ne peut toujours pas garantir la décentralisation. Dans l'affaire Multichain de 2023, les 21 nœuds participant au calcul MPC étaient tous contrôlés par une seule personne, ce qui constitue une attaque de sorcière typique. Cela suffit à prouver que plusieurs nœuds en apparence ne peuvent pas offrir une garantie de décentralisation élevée.
DeepSafe : Construire le réseau de validation de sécurité de nouvelle génération
Dans un contexte où les technologies de multi-signatures et de MPC sont déjà relativement matures, l'équipe de DeepSafe propose une solution plus prospective : CRVA (Agent de Vérification Aléatoire Cryptographique). L'innovation de DeepSafe réside dans le fait qu'elle ne remplace pas simplement les technologies de signature existantes, mais qu'elle construit une couche de vérification de sécurité supplémentaire sur la base des solutions existantes.
Validation multi-facteurs de CRVA
La pensée centrale de DeepSafe est “double assurance” : les utilisateurs peuvent continuer à utiliser leurs solutions de portefeuille familières, comme le portefeuille Safe. Lorsqu'une transaction à signature multiple est soumise à la chaîne, elle est automatiquement envoyée au réseau CRVA pour une vérification supplémentaire, similaire à la vérification à deux facteurs 2FA d'Alipay.
Dans cette architecture, le CRVA agit en tant que gardien, vérifiant chaque transaction selon les règles définies à l'avance par l'utilisateur. Par exemple, des limites sur le montant des transactions individuelles, une liste blanche d'adresses cibles, des restrictions sur la fréquence des transactions, etc. En cas de situation anormale, la transaction peut être interrompue à tout moment.
L'avantage de cette authentification à deux facteurs (2FA) est que même si le processus de signature multiple est manipulé (comme lors de l'attaque de phishing frontale de l'événement Bybit), le CRVA, en tant qu'assurance, peut toujours refuser les transactions à risque selon des règles prédéfinies, protégeant ainsi la sécurité des actifs des utilisateurs.
Amélioration technologique basée sur des solutions MPC traditionnelles
Pour pallier les insuffisances des solutions de gestion d'actifs MPC traditionnelles, la solution CRVA de DeepSafe a apporté de nombreuses améliorations. Tout d'abord, les nœuds du réseau CRVA adoptent une forme d'admission par mise en gage d'actifs, et le réseau principal ne sera officiellement lancé qu'après avoir atteint environ 500 nœuds. Selon les estimations, les actifs mis en gage par ces nœuds resteront à long terme à plusieurs dizaines de millions de dollars ou plus ;
Deuxièmement, afin d'améliorer l'efficacité du calcul MPC/TSS, CRVA sélectionnera aléatoirement des nœuds par un algorithme de tirage au sort, par exemple en tirant 10 nœuds toutes les demi-heures, qui agiront en tant que validateurs pour vérifier si les demandes des utilisateurs doivent être approuvées, puis généreront la signature de seuil correspondante pour autoriser l'accès. Pour empêcher la collusion interne ou les attaques de hackers externes, l'algorithme de tirage au sort de CRVA utilise un VRF en anneau original, combiné avec ZK pour masquer l'identité des sélectionnés, de sorte que l'extérieur ne puisse pas observer directement les candidats sélectionnés.
Bien sûr, faire seulement cela n'est pas suffisant. Bien que le public ne sache pas qui a été sélectionné, la personne choisie le sait, il existe donc toujours une voie de complot. Pour éliminer davantage les conspirations, tous les nœuds de CRVA doivent exécuter le code source dans un environnement matériel TEE, ce qui équivaut à effectuer le travail principal dans une boîte noire. Ainsi, personne ne peut savoir s'il a été sélectionné, à moins qu'il ne puisse pirater le matériel de confiance TEE, ce qui est bien sûr très difficile à réaliser compte tenu des conditions techniques actuelles.
Ce qui a été mentionné ci-dessus est l'idée de base de la solution CRVA de DeepSafe. Dans le processus de travail réel, les nœuds au sein du réseau CRVA doivent effectuer un grand nombre de communications par diffusion et d'échanges d'informations. Le processus spécifique est le suivant :
Tous les nœuds doivent d'abord staker des actifs sur la chaîne avant d'entrer dans le réseau CRVA, en laissant une clé publique comme information d'enregistrement. Cette clé publique est également appelée « clé publique permanente ».
Chaque heure, le réseau CRVA sélectionne aléatoirement quelques nœuds. Mais avant cela, tous les candidats doivent générer localement une « clé publique temporaire » unique, tout en générant un ZKP pour prouver que la « clé publique temporaire » est liée à la « clé publique permanente » enregistrée sur la chaîne ; en d'autres termes, chacun doit prouver par ZK qu'il existe sur la liste des candidats sans révéler qui il est ;
Le rôle de la « clé publique temporaire » réside dans la protection de la vie privée. Si l'on tire directement au sort parmi l'ensemble des « clés publiques permanentes », lors de l'annonce des résultats, tout le monde saura directement qui a été élu. Si chacun ne dévoile qu'une « clé publique temporaire » unique, puis que l'on choisit quelques personnes parmi l'ensemble des « clés publiques temporaires », vous saurez au maximum que vous avez gagné, mais vous ne saurez pas à qui correspondent les autres clés publiques temporaires gagnantes.
Afin de prévenir davantage la divulgation d'identité, CRVA prévoit de faire en sorte que vous ne sachiez même pas ce qu'est votre « clé publique temporaire ». Le processus de génération de la clé publique temporaire se déroule dans l'environnement TEE du nœud, et vous, qui exécutez le TEE, ne pouvez pas voir ce qui se passe à l'intérieur.
Ensuite, dans le TEE, le texte en clair de la clé publique temporaire est chiffré en « caractères aléatoires » avant d'être envoyé à l'extérieur, seul des nœuds Relayer spécifiques peuvent le déchiffrer. Bien sûr, le processus de déchiffrement se déroule également dans l'environnement TEE du nœud Relayer, et le Relayer ne sait pas à quels candidats ces clés publiques temporaires correspondent.
Le Relayer, après avoir restauré toutes les « clés publiques temporaires », les regroupe et les soumet à la fonction VRF sur la chaîne, à partir de laquelle les gagnants sont tirés. Ces personnes vérifient les demandes de transaction envoyées par l'interface utilisateur, puis, en fonction des résultats de la vérification, génèrent une signature de seuil, qui est enfin soumise à la chaîne. (Il convient de noter que, ici, le Relayer est en réalité également masqué et sélectionné périodiquement.)
Il se peut que certaines personnes se demandent, puisque chaque nœud ne sait pas s'il a été sélectionné, comment le travail peut-il continuer ? En fait, comme mentionné précédemment, chacun générera une « clé publique temporaire » dans son environnement TEE local. Une fois que les résultats du tirage au sort sont disponibles, nous diffusons directement la liste. Il suffit que chacun transmette la liste dans le TEE, et à l'intérieur, il peut vérifier s'il a été sélectionné.
Le cœur de la solution DeepSafe réside dans le fait que presque toutes les activités importantes se déroulent à l'intérieur du matériel TEE, rendant impossible l'observation de ce qui se passe de l'extérieur du TEE. Chaque nœud ne sait pas qui sont les validateurs sélectionnés, ce qui empêche toute collusion malveillante et augmente considérablement le coût des attaques externes. Pour attaquer le comité CRVA basé sur DeepSafe, il faudrait théoriquement attaquer l'ensemble du réseau CRVA, d'autant plus que chaque nœud est protégé par TEE, rendant l'attaque beaucoup plus difficile.
En ce qui concerne les comportements malveillants de CRVA, étant donné que CRVA est un système de réseau de nœuds fonctionnant de manière automatisée, tant que le code lors de son démarrage initial ne contient pas de logique malveillante, il n'y aura pas de situation où CRVA refuse activement de coopérer avec l'utilisateur, donc cela peut être essentiellement ignoré.
Si le CRVA subit une panne d'électricité, une inondation ou d'autres événements de force majeure entraînant l'arrêt massif des nœuds, les utilisateurs ont toujours la possibilité de retirer leurs actifs en toute sécurité selon le processus mentionné dans le plan ci-dessus. L'hypothèse de confiance ici est que nous avons suffisamment confiance en la décentralisation du CRVA pour qu'il ne prenne pas l'initiative de nuire (la raison a déjà été suffisamment expliquée précédemment).
Résumé
L'évolution de la technologie de signature Web3 montre l'exploration incessante de l'humanité dans le domaine de la sécurité numérique. Des premières clés privées uniques, aux portefeuilles multisignatures, en passant par le MPC et les nouvelles solutions telles que le CRVA, chaque avancée ouvre de nouvelles possibilités pour la gestion sécurisée des actifs numériques.
Cependant, les avancées technologiques ne signifient pas l'élimination des risques. Chaque nouvelle technologie, tout en résolvant des problèmes existants, peut également introduire de nouvelles complexités et points de risque. L'événement de Bybit nous montre que même avec l'utilisation de technologies avancées de signature multiple, des attaquants peuvent toujours contourner les protections techniques par l'ingénierie sociale et des attaques de la chaîne d'approvisionnement. Cela nous rappelle que les solutions technologiques doivent être associées à de bonnes pratiques opérationnelles et à une sensibilisation à la sécurité.
Finalement, la sécurité des actifs numériques n'est pas seulement un problème technique, mais aussi un défi systémique. Que ce soit par la multi-signature, le MPC, ou le CRVA, ce ne sont que des solutions tentatives face aux risques potentiels. Avec le développement de l'industrie de la blockchain, il sera nécessaire à l'avenir de continuer à innover et à rechercher des solutions plus sûres et sans confiance.