Revue pratique par Bitcoin.com.
Vultisig est un coffre-fort cryptographique sans graine, multi-appareils, basé sur la technologie Threshold Signature Scheme (TSS). Au lieu de générer une phrase de récupération traditionnelle, le portefeuille répartit l’autorité de signature entre plusieurs appareils, nécessitant un seuil défini pour autoriser les transactions.
Pour évaluer la performance de ce modèle en conditions réelles, nous avons installé Vultisig sur plusieurs appareils et testé à la fois la configuration Secure Vault et la configuration Fast Vault. Des transactions ont été effectuées sur plusieurs réseaux supportés, y compris l’envoi et la réception d’actifs, l’exécution d’échanges, l’interaction avec l’onglet DeFi, et l’installation de plugins. Nous avons également évalué la coordination de signature multi-appareils en utilisation normale et simulé des scénarios d’interruption, ainsi que les procédures de récupération via l’importation de vault-shares sur de nouveaux appareils.
Configuration d’un coffre-fort : pas de phrase de récupération, contrôle distribué
Nous avons commencé par créer deux configurations de coffre-fort :
- Un Secure Vault utilisant deux appareils (seuil 2-sur-2)
- Un Fast Vault utilisant un appareil plus le co-signataire Vultiserver
Aucune phrase de récupération n’a été générée lors de la configuration. À la place, chaque appareil a créé une part de coffre-fort unique. Ces parts agissent comme des fragments cryptés de l’autorité de signature et doivent être sauvegardées individuellement sous forme de fichiers .vult. Lors de la sauvegarde, les parts de coffre-fort sont cryptées avec le mot de passe du coffre avant d’être exportées pour stockage.
Nous avons également vérifié le processus de sauvegarde des vault-shares. L’exportation des parts vers un stockage sécurisé était simple, et le portefeuille insiste clairement sur l’importance de préserver ces sauvegardes. La réimportation d’une part de coffre-fort sur un nouvel appareil a fonctionné comme prévu, confirmant que les sauvegardes de vault-shares servent de mécanisme principal de récupération en l’absence d’une phrase de récupération.
Le processus de configuration semblait réfléchi mais clair. Dans la configuration Secure Vault, les deux appareils ont participé à la création du coffre et de ses parts associées. Dans la configuration Fast Vault, le serveur a agi comme co-signataire pour simplifier l’utilisation quotidienne.
Les transactions ne s’exécutaient qu’après approbation par les appareils requis. En configuration 2-sur-2, les deux appareils devaient participer au processus de signature avant que la transaction ne soit diffusée. Cela reflète la conception threshold du portefeuille, où aucun appareil seul ne peut autoriser une transaction de manière indépendante.
Gestion multi-chaînes d’actifs en pratique
L’onglet Wallet regroupe les actifs de plus de 30 chaînes supportées, dont Bitcoin, Ethereum, Solana, réseaux Cosmos, et chaînes compatibles EVM.
La réception de fonds générait des adresses fraîches par chaîne avec un étiquetage clair. La différenciation des réseaux était cohérente, aidant à réduire le risque d’envoi vers la mauvaise chaîne. Les fonds apparaissaient rapidement après confirmation sur les réseaux respectifs.
Nous avons testé l’envoi de :
- Petits montants
- Montants plus importants
- Transactions répétées en succession rapide
Pour observer le comportement sous charge accrue, nous avons lancé plusieurs transactions successives sur différentes chaînes supportées. Le portefeuille a géré ces envois consécutifs sans créer d’états incohérents. La génération d’adresses est restée correcte sur tous les réseaux, et le flux de signature est resté prévisible même lors d’une activité transactionnelle rapide.
L’estimation des frais était visible avant la signature. Le processus de signature nécessitait la coordination entre les appareils participants avant qu’une transaction ne soit approuvée. La vitesse de signature variait légèrement selon la réactivité des appareils et les conditions réseau, mais restait cohérente tout au long des tests.
Échanges cross-chain et interaction DeFi
Vultisig inclut une fonctionnalité native d’échange avec un modèle de frais initial de 50 points de base pour les swaps cross-chain. Nous avons effectué des échanges de jetons à jetons et testé les flux cross-chain supportés.
Les paramètres de slippage étaient visibles, et les détails de l’échange étaient présentés avant l’approbation finale. La co-signature multi-appareils était appliquée aux swaps, comme pour les envois standards, renforçant un modèle de signature cohérent pour toutes les actions du portefeuille.
Nous avons également exploré la réponse du portefeuille lorsque les swaps ne peuvent pas être complétés, par exemple lorsque les seuils de slippage sont dépassés ou la liquidité indisponible. Dans ces cas, l’interface indiquait clairement que la transaction ne pouvait pas continuer et empêchait son exécution incomplète. Le message d’échec du swap permettait d’ajuster les paramètres avant de réessayer.
L’onglet DeFi permettait d’interagir avec le staking et d’autres fonctions supportées dans l’interface du portefeuille. Les approbations de contrats intelligents déclenchaient le même flux de signature threshold utilisé pour les transferts standards. Les prompts de transaction présentaient les détails de l’interaction avec le contrat avant approbation, aidant à clarifier l’action autorisée.
Signature multi-appareils sous stress
Pour tester la fiabilité de la coordination, nous avons simulé plusieurs scénarios :
- Un appareil hors ligne en cours de signature
- Un appareil rejetant une transaction
- L’application passant en arrière-plan pendant la session de signature
- Des tentatives de signature rapides en succession
Pour évaluer davantage la coordination entre appareils, nous avons lancé plusieurs demandes de signature en peu de temps. Même lors de ces multiples prompts, les appareils se sont synchronisés de manière fiable et n’ont pas produit d’états de signature bloqués ou de transactions en double.
Des interruptions réseau temporaires ont également été simulées lors des sessions de signature. Lors de la restauration de la connectivité, les appareils ont repris le processus de signature sans créer d’états incohérents de transaction.
Lorsqu’un appareil se déconnectait en cours de session, la demande de signature restait simplement incomplète jusqu’à ce que la participation threshold soit rétablie. Aucune diffusion en double ni exécution partielle n’a été observée.
Scénarios de récupération et de perte
La récupération est un élément critique de tout portefeuille en auto-garde. Nous avons simulé deux scénarios principaux.
Scénario 1** : Perte d’un appareil dans un coffre-fort 2-sur-3**
Avec le seuil de signature toujours atteignable, les transactions ont continué à fonctionner normalement.
Scénario 2** : Perte de la majorité des appareils**
Nous avons testé la réimportation de vault-shares sur de nouveaux appareils. La récupération nécessitait l’accès aux parts sauvegardées du seuil requis.
Du point de vue de l’utilisabilité, le flux de récupération suivait une séquence claire d’instructions guidant la réinitialisation des appareils et la reconstruction du coffre. Le processus renforçait le modèle de sécurité du portefeuille tout en permettant la restauration d’accès lorsque les parts nécessaires étaient disponibles.
Marketplace de plugins et achats récurrents
Nous avons exploré le marketplace de plugins, en nous concentrant sur le flux d’installation et la clarté des permissions. L’activation des plugins était simple, et leur désinstallation ne nécessitait pas d’étapes complexes.
Le plugin Achats Récurrents a été testé en :
- Configurant des achats programmés
- Annulant des achats programmés
- Simulant des échecs
Le timing d’exécution était conforme au calendrier configuré. L’annulation empêchait toute nouvelle exécution comme prévu.
Nous avons aussi observé le comportement du plugin lorsque les transactions programmées ne peuvent pas être complétées, par exemple en cas de fonds insuffisants. Dans ces cas, la transaction échouait simplement sans déclencher d’achats involontaires répétés, et le portefeuille communiquait clairement le résultat.
Les permissions associées aux plugins étaient affichées dans le contexte de la transaction, clarifiant les actions demandées par le plugin.
Infrastructure et modèle de signature
Le modèle de sécurité de Vultisig repose sur une signature distribuée plutôt que sur une clé privée unique stockée sur un seul appareil.
En mode Fast Vault, le Vultiserver agit comme co-signataire pour permettre une expérience de signature sur un seul appareil pour les transactions quotidiennes. En mode Secure Vault, l’autorisation de transaction nécessite la participation de plusieurs appareils contrôlés par l’utilisateur.
Cette architecture permet aux utilisateurs de choisir entre commodité et un contrôle distribué accru, tout en évitant le stockage centralisé de clés et le point de défaillance unique associé aux portefeuilles à phrase de récupération traditionnels.
Évaluation finale
Dans la configuration, les transactions, les échanges, l’interaction DeFi, la coordination de signature et les simulations de récupération, Vultisig a toujours respecté son architecture de sécurité documentée.
Le design sans graine, basé sur un seuil, modifie le modèle mental habituel de sécurité de portefeuille. Au lieu de protéger une seule phrase de récupération, les utilisateurs gèrent des parts de coffre-fort distribuées et la participation des appareils. Cela introduit des étapes procédurales supplémentaires mais répartit le contrôle sur plusieurs appareils.
Pour les utilisateurs privilégiant l’autorisation distribuée et la coordination multi-appareils, Vultisig offre une approche structurée de l’auto-garde. Son support multi-chaînes, ses échanges intégrés, son extensibilité via plugins et ses outils de récupération explicites forment un environnement de portefeuille orienté sécurité.
Pour ceux prêts à dépasser les limitations des portefeuilles à phrase de récupération traditionnels, Vultisig propose un modèle innovant et convaincant pour sécuriser et gérer les actifs numériques.
_________________________________________________________________________
Bitcoin.com décline toute responsabilité, directe ou indirecte, et ne saurait être tenu responsable, pour toute perte, dommage, réclamation, coût ou dépense de quelque nature que ce soit, qu’elle soit réelle, alléguée ou consécutive, découlant de ou en lien avec l’utilisation ou la confiance accordée à tout contenu, produit ou service mentionné dans cet article. Toute reliance à ces informations se fait aux risques et périls du lecteur.
