Stockage à froid vs multisig vs MPC pour RWA tokenisés

Ce qui change lorsque l’actif est un RWA tokenisé, et non de simples ETH

La question de la conservation semble identique à première vue : vous avez une clé privée, vous voulez la garder en sécurité, vous voulez signer des transactions. Les actifs du monde réel tokenisés (RWA), comme l’OUSG d’ONDO, le BUIDL de BlackRock ou les produits de trésorerie libellés en MNT de Mantle, ne changent pas la cryptographie. Ce qu’ils changent, c’est la charge opérationnelle qui repose dessus.

Un fonds monétaire ou un fonds de trésorerie tokenisé émet et rachète généralement selon un calendrier. OUSG, par exemple, règle les rachats en T+1. BUIDL distribue le rendement en continu et prend en charge les transferts au niveau du token ainsi que le rachat via l’émetteur. Ce rythme signifie qu’une équipe de trésorerie ne peut pas laisser une seule transaction non signée en attente pendant une semaine comme peut le faire un détenteur de BTC à long terme. La file de signature doit être vidée dans la journée ouvrée, souvent dans l’heure si une fenêtre de rachat est sur le point de se fermer.

Le deuxième changement est l’auditabilité. Avec des ETH classiques, l’enregistrement on-chain suffit généralement à une équipe financière interne. Avec un RWA réglementé, la partie off-chain implique des auditeurs, des agents de transfert, et parfois un régulateur qui exigera la preuve qu’un rachat a été autorisé par des personnes nommées dans le cadre d’une politique documentée. Cette exigence transforme la conservation, car « qui a signé » compte autant que « la signature est valide ».

Le troisième changement est que la clé opérationnelle est rarement la seule clé. La plupart des produits RWA séparent une clé de politique, une clé d’opérations quotidiennes et une clé de gardien, chacune étant soumise à des contrôles différents. Les traiter comme un seul problème de signature est l’une des raisons pour lesquelles de nombreuses architectures de trésorerie échouent.

Le compromis entre latence opérationnelle et coût pour l’attaquant

La conservation n’est pas une seule décision, c’est un compromis entre deux nombres. Le premier est le temps nécessaire pour produire une signature valide lorsque l’entreprise en a besoin. Le second est ce qu’un attaquant doit dépenser, ou le nombre de défaillances indépendantes qu’il doit provoquer, avant de pouvoir produire une signature frauduleuse.

Le stockage à froid, au sens strict, pousse très haut le coût pour l’attaquant, et la latence avec lui. La clé réside sur un appareil qui n’a jamais été connecté à internet, idéalement dans un coffre, et signer implique de le récupérer physiquement. C’est excellent pour une trésorerie BTC à long terme, et très pénible pour un fonds qui doit racheter des ONDO ou des BUIDL chaque jour ouvré. Le coût de la lenteur n’est pas abstrait : des fenêtres de rachat manquées peuvent déclencher des frais de pénalité, vous repousser au cycle suivant ou, dans les cas extrêmes, bloquer la position jusqu’à la prochaine coupure de l’émetteur.

Le multisig modifie le compromis en répartissant la confiance entre plusieurs signataires et appareils. Une configuration 3 sur 5 signifie qu’un attaquant doit compromettre trois signataires indépendants, ce qui est nettement plus difficile que d’en compromettre un seul, tandis que la latence correspond à la vitesse de vos trois signataires les plus rapides. Le piège est que le mot « indépendants » porte une grande partie de la sécurité. Si trois de vos signataires sont gérés par la même personne, sur le même système d’exploitation, avec le même schéma de sauvegarde, le multisig ne vous a pas acheté une difficulté équivalente à trois attaquants. Il vous en a acheté une seule.

Le MPC, c’est-à-dire les schémas de signature à seuil comme GG20, GG20+, Lindell17 ou les implémentations FROST plus récentes, déplace le calcul du coût pour l’attaquant dans le protocole lui-même. La clé de signature n’existe jamais en un seul endroit. Chaque participant détient un fragment, et un seuil d’entre eux produit conjointement une signature sans jamais reconstruire la clé complète. La latence peut être très faible, comparable à celle d’un portefeuille chaud à signataire unique, et l’attaquant doit compromettre un seuil de participants dans une fenêtre de signature étroite.

Ce que fait aussi le MPC, et c’est la partie dont on ne parle pas assez, c’est réduire le coût des erreurs opérationnelles. Avec le multisig, perdre un signataire est agaçant mais récupérable tant que vous restez au-dessus du seuil. Avec le MPC, le scénario de récupération dépend entièrement de la manière dont les fragments ont été générés, de qui les détient, et de l’existence continue du dépositaire. Si vous effacez un ordinateur portable et que le fragment ne se trouvait que sur cet ordinateur, la politique peut simplement devenir irrécupérable, et l’actif est effectivement gelé jusqu’à ce que la cérémonie sous-jacente de fragments de clé puisse être relancée avec les participants restants.

Pourquoi les dépositaires institutionnels de RWA utilisent des HSM, et non des portefeuilles matériels grand public

Un portefeuille matériel grand public, qu’il s’agisse de Ledger, Trezor, GridPlus ou Keystone, est un petit appareil à élément sécurisé qui stocke une seed et signe les transactions hors ligne. Pour une réserve personnelle en BTC ou une position en ETH à cinq chiffres, c’est excellent. Pour une trésorerie qui signe opérationnellement des rachats sur un portefeuille institutionnel de RWA, les lacunes commencent à s’accumuler.

La première lacune concerne l’exportation et le clonage des clés. Les portefeuilles matériels sont conçus pour que l’utilisateur, et non le fabricant de l’appareil, contrôle la seed. D’un point de vue institutionnel, c’est un passif : un employé qui part avec la phrase de récupération et une sauvegarde dans un coffre bancaire représente un risque de personne clé difficile à corriger. Les dépositaires institutionnels veulent des clés qu’ils peuvent faire tourner, mettre sous séquestre ou détruire selon une politique écrite, et ils veulent que ce processus soit auditable de bout en bout.

C’est à cela que servent les HSM, les modules matériels de sécurité. Des appareils comme AWS CloudHSM, Thales Luna, Utimaco ou YubiHSM 2 sont validés FIPS, prennent en charge l’accès fondé sur les rôles et s’intègrent à des moteurs de politique qui enregistrent chaque tentative de signature, qui l’a initiée et selon quelle règle. Les clés ne quittent jamais l’appareil en clair, la rotation des clés est un flux de travail documenté, et un auditeur peut consulter une piste propre.

La deuxième lacune concerne ce qui est signé. Un portefeuille matériel grand public vous affiche une transaction sur un minuscule écran et vous demande de l’approuver. Une équipe de trésorerie qui opère avec OUSG ou BUIDL doit faire appliquer la politique avant même que le signataire voie la transaction : limites par actif, contreparties sur liste d’autorisation, plafonds de rachat par jour, double contrôle pour tout montant au-dessus d’un seuil. Cette logique doit résider dans un moteur de politique de transaction ou dans une couche de compte intelligent comme Safe (anciennement Gnosis Safe) avec des modules, et non dans un humain qui fixe un écran de 128x64 pixels.

La troisième lacune est le débit opérationnel. Un portefeuille matériel est conçu pour un usage occasionnel, pas pour les dizaines d’approbations qu’un flux RWA quotidien peut produire lorsque l’on inclut les balayages de rendement, les paiements de frais, les attestations d’oracle et les écritures de rapprochement. L’ergonomie s’effondre bien avant la sécurité.

Les pièges de récupération multisig qui semblent acceptables jusqu’à ce qu’ils ne le soient plus

Le multisig sur ETH est le plus souvent déployé sous forme de portefeuille Safe (anciennement Gnosis Safe), avec des signataires conservés sur des portefeuilles matériels et un scénario de récupération documenté. En théorie, c’est robuste. En pratique, trois pièges apparaissent régulièrement.

Le premier est l’homogénéité des signataires. Un 5 sur 9 semble sûr jusqu’à ce que vous réalisiez que les neuf signataires utilisent le même logiciel de portefeuille, la même version de firmware, la même procédure de sauvegarde, et que trois d’entre eux ont été configurés par la même personne le même après-midi. La sécurité du multisig augmente avec l’indépendance des signataires. Le chiffre 9 est décoratif. Le chiffre qui compte est le nombre de vecteurs de compromission réellement indépendants.

Le deuxième est la disponibilité des signataires. Un multisig ne fonctionne que si vous pouvez atteindre le seuil. Si vos signataires sont un mélange de contractuels répartis sur trois fuseaux horaires, d’un dirigeant qui voyage et d’un portefeuille conservé dans un coffre nécessitant deux jours d’accès, vous pouvez vous retrouver incapable de signer un rachat ONDO urgent parce que trois de vos cinq signataires les plus rapides sont dans des avions. La solution consiste généralement en une combinaison de signataires froids et tièdes, avec une politique indiquant que les signataires chauds ne peuvent approuver que de petits montants. Cela fonctionne, mais ajoute un autre multisig à gérer, et vous revenez au problème de récursion.

Le troisième est la garde de la clé de récupération. Chaque Safe a un scénario de récupération, généralement lié à la manière dont les signataires ont été générés. Si la récupération repose sur une phrase de récupération écrite sur papier dans un coffre, vous avez désormais une seule feuille de papier dont la compromission donne à un attaquant un signataire fonctionnel. Si la récupération repose sur une récupération sociale via des gardiens, vous avez déplacé la confiance vers les gardiens, qui pourraient ne plus être ceux que vous pensez dans cinq ans. Aucun de ces points n’est bloquant, mais chacun est un endroit où le 3 sur 5 d’apparence nette devient discrètement un 2 sur 5 avec un signataire dans un tiroir.

Le risque de disparition des parts de clé MPC, en termes simples

La caractéristique déterminante de MPC, à savoir que la clé complète n’existe jamais en un seul endroit, est aussi son risque déterminant. La politique de signature réside dans les participants, et les participants peuvent disparaître.

La disparition du fournisseur est le risque le plus souvent cité. Si vous confiez la garde à Fireblocks, Anchorage, BitGo, Fordefi ou à un fournisseur MPC similaire, vos parts sont réparties entre vous et eux. Si le fournisseur est acquis, quitte le marché, subit une panne grave ou abandonne simplement votre niveau de service, vous pourrez peut-être migrer vos actifs, mais seulement si les outils de migration sont disponibles et si vous avez le temps. Dans le pire des cas, vous détenez une part, le fournisseur détient une part, et le seuil n’est plus atteignable parce que le côté fournisseur est hors ligne ou non coopératif.

La perte d’appareils participants est le risque suivant. Les parts MPC sont généralement conservées dans des HSM, des nœuds de signature dédiés ou des ordinateurs portables durcis. Chaque appareil a sa propre logique de garde des clés, notamment la manière dont les parts sont sauvegardées et l’endroit où elles le sont. Perdez deux de ces appareils et vous avez un problème de récupération sur les bras, pas seulement un désagrément. L’atténuation consiste à sauvegarder les parts, mais la sauvegarde des parts est elle-même une décision de garde : où résident les parts de sauvegarde, qui peut les déchiffrer, et comment prouvez-vous à un auditeur qu’aucune personne seule ne peut reconstituer la clé à partir des sauvegardes ?

Le risque de protocole et d’implémentation est le troisième risque. Les schémas de signature à seuil relèvent d’une cryptographie complexe, et leurs implémentations ont connu des bogues. La divulgation en 2022 d’une vulnérabilité dans certaines implémentations GG20, les découvertes plus récentes autour de threshold EdDSA et un flux régulier de problèmes dans les SDK de portefeuilles rappellent que « la clé n’existe jamais » est une affirmation plus forte que « la clé n’existe jamais et le code de signature est exempt de bogues ». Pour une opération de trésorerie RWA, la bonne approche consiste à exiger des audits de sécurité indépendants de la pile du fournisseur MPC et à conserver la possibilité de migrer vers un autre schéma, même si cela coûte cher.

Une nuance mérite d’être nommée : la sécurité de MPC s’applique par événement de signature. Une fois qu’un seuil de participants signe, la signature est valide pour toujours, même si les parts des participants sont détruites par la suite. Le risque de disparition concerne donc la capacité de signature future, et non les signatures passées. C’est le bon cadrage à présenter à un conseil : nous ne risquons pas qu’une transaction passée soit falsifiée, nous risquons de ne plus pouvoir gérer la position.

Une pile de garde pratique pour des RWA à rachat quotidien

Compte tenu de la charge de travail, une configuration viable pour un fonds ou une trésorerie de protocole détenant des RWA tokenisés ressemble davantage à une architecture en couches qu’à une solution pure.

La couche de base est un dépositaire institutionnel avec des HSM validés FIPS pour la réserve de long terme. C’est là que se trouve l’essentiel de la position, avec une signature contrôlée par politique et une séparation des rôles. Pour une allocation OUSG ou BUIDL qui n’a pas besoin de bouger souvent, c’est le bon endroit, car le coût de latence lié à l’accès au coffre est rarement payé et le coût pour l’attaquant est très élevé.

La couche de travail est un Safe multisig ou un cluster MPC utilisé pour les opérations courantes : petits rachats, balayages de rendement, paiements de frais, attestations d’oracle. Le choix entre multisig et MPC dépend ici du volume de signature, de la répartition des signataires et de la tolérance de l’équipe au risque opérationnel. Le multisig est plus facile à auditer et plus facile à récupérer. MPC est plus rapide et gère mieux les volumes de signature élevés. Beaucoup d’équipes utilisent les deux : un Safe pour la gouvernance et un cluster MPC plus petit pour l’exécution.

La couche de politique se trouve au-dessus des deux. Un moteur de politique de transaction applique des limites par actif, des contrats sur liste d’autorisation, des plafonds quotidiens et des règles de double contrôle. Les signataires ne voient pas de transactions brutes ; ils voient des intentions préapprouvées, et le moteur construit et soumet les transactions réelles. C’est là que la majeure partie du risque opérationnel est réellement contrôlée, et là que les portefeuilles matériels grand public sont insuffisants pour un usage institutionnel, puisqu’ils ne peuvent pas faire appliquer cette politique devant le signataire.

La couche de réserve froide est un multisig isolé d’Internet pour la gouvernance et les changements de politique : modification des signataires, rotation des clés, mise à niveau du moteur de politique, déplacement de montants importants hors de la couche de travail. La latence est acceptable ici parce que ces événements sont rares, et le coût pour l’attaquant est très élevé parce que les clés vivent dans un coffre.

Le résumé honnête est que « cold storage vs multisig vs MPC » est le mauvais cadre pour les RWA institutionnels. Le bon cadre consiste à déterminer quelle charge de travail va sur quelle couche, et quel est le scénario de récupération lorsqu’une part, un signataire ou un fournisseur disparaît.

Comment suivre intelligemment les évolutions de la conservation des RWA

La conservation des RWA évolue rapidement, car les produits, les dépositaires et les régulateurs changent tous en même temps. Suivre manuellement les rachats d’OUSG, les mécanismes de distribution de BUIDL, les migrations de fournisseurs MPC et les avis sur les firmwares HSM est une bataille perdue d’avance. Zippfeed fait remonter les actualités sur les RWA tokenisés avec une notation du sentiment (bullish, neutral ou bearish) et une note d’importance, afin que vous puissiez vous concentrer sur les événements qui affectent réellement votre conception de conservation au lieu de vous noyer dans le bruit.