Guide de Sécurité de l'Écosystème Pharos : Gestion des Risques de la Chaîne Complète pour l'Intégration d'Actifs RWA

Cet article vise à fournir aux développeurs de l'écosystème Pharos une référence plus pratique et approfondie pour l'intégration des RWA. Nous tentons de restituer, sous l'angle de la logique métier et de l'architecture de gestion des risques, les défis complexes et les solutions associées à la mise en chaîne des actifs du monde réel (RWA).

Introduction

L'écosystème Pharos s'efforce de devenir une infrastructure connectant les actifs financiers traditionnels au monde Web3. Contrairement aux actifs cryptographiques natifs, les actifs du monde réel (RWA) combinent des droits de propriété physiques hors chaîne et des attributs de transaction sur chaîne. Cette double nature implique que leur périmètre de sécurité ne peut se limiter au niveau du smart contract, mais doit s'étendre à chaque interstice de la validation des droits de propriété, de la synchronisation des données et de la conformité réglementaire.

Basée sur une analyse approfondie des principaux projets RWA [1], nous abordons trois dimensions – les modèles architecturaux, les zones de risque clés et les stratégies d'intégration – pour tracer aux développeurs Pharos le chemin critique de construction d'applications RWA robustes.

I. Pourquoi Pharos est-il adapté aux RWA ?

Pharos est une couche 1 (Layer 1) conçue pour une échelle de type Internet. Pour les développeurs RWA, il n'est pas nécessaire de maîtriser les détails du consensus sous-jacent ; l'attention doit se porter sur le règlement des actifs et les calculs complexes.

1. Exécution parallèle et confirmation en moins d'une seconde (Block-STM) L'EVM traditionnel traite les transactions en série, ce qui peut provoquer des congestions lors de distributions de dividendes ou de rééquilibrages importants de RWA. Pharos introduit le moteur d'exécution parallèle Block-STM, permettant une finalité en moins d'une seconde.

• Cela signifie que le décaissement des fonds hors chaîne et le règlement sur chaîne peuvent être quasi simultanés, éliminant les risques de fluctuation des taux de change et de slippage liés au "T+1".

2. Architecture Dual-VM (EVM + WASM) Pharos prend nativement en charge les environnements d'exécution EVM et WASM.

• Couche EVM : Responsable de la connexion. Les protocoles de prêt, codes de DEX Solidity existants peuvent être déployés directement pour accueillir les actifs RWA.

• Couche WASM : Responsable du calcul. Les RWA impliquent une logique complexe de calcul des intérêts, de fiscalité, de gestion des risques stratifiée et de listes blanches de conformité. Exécuter cela sur EVM est très gourmand en Gas et inefficace. Cette logique intensive en calculs peut être migrée vers des modules WASM, permettant une gestion des risques sur chaîne performante et à faible coût.

https://docs.pharosnetwork.xyz

II. Les deux logiques opérationnelles des RWA

Avant de concevoir un protocole RWA sur Pharos, les développeurs doivent comprendre les deux principaux modes de circulation des actifs et leurs circuits financiers :

1. Mode On-chain vers Off-chain

C'est le mode le plus courant actuellement, essentiellement du financement participatif (crowdfunding) sur chaîne et de la gestion d'actifs hors chaîne. Les investisseurs bloquent des stablecoins (comme l'USDC) sur chaîne → Le porteur de projet consolide et convertit en monnaie fiduciaire (USD) → Investit dans des actifs hors chaîne à haute liquidité (comme les obligations d'État américaines) → Les intérêts perçus sont renvoyés sur chaîne et distribués aux détenteurs de jetons.

Cas : Le $STBT de Matrixdock. Les investisseurs accrédités frappent du $STBT (ancré 1:1 aux obligations à court terme du Trésor américain), les fonds sont utilisés par le porteur de projet pour acheter des obligations d'État, les détenteurs sur chaîne bénéficient d'un rendement annuel d'environ 4,8%.

2. Mode Mise en Chaîne d'Actifs (Asset Onboarding)

Ce mode se concentre sur la titrisation et la fragmentation d'actifs spécifiques. Le porteur de projet verrouille un actif hors chaîne spécifique (comme un bien immobilier) et l'évalue → Émet des jetons ERC-20 représentant des parts correspondantes → Les investisseurs souscrivent avec des stablecoins → Le porteur de projet est responsable de la maintenance et de l'exploitation de l'actif hors chaîne → Les flux de trésorerie générés (comme les loyers) sont distribués périodiquement sous forme de dividendes sur chaîne.

Cas : La tokenisation immobilière de RealT. Par exemple, un bien d'une valeur de 65 900 $ à Détroit est divisé en 1300 jetons, les investisseurs achètent des jetons et obtiennent ainsi des droits aux dividendes des loyers de ce bien.

III. Cartographie des Risques et Stratégie d'Intégration sur Pharos

Les risques mortels des RWA ne se trouvent souvent pas dans le code, mais dans les maillons de connexion entre le hors chaîne et le sur chaîne. Les projets RWA existants présentent des lacunes structurelles significatives en matière de vérification d'identité, d'ancrage des actifs et de transparence des données. En construisant des applications sur Pharos, les développeurs doivent se prémunir contre les risques suivants, véritables "rhinocéros gris".

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

1. Conformité Identitaire Transversale

Les projets prétendent être conformes, mais en réalité, cela reste superficiel. Selon les statistiques, moins de la moitié des projets mettent en œuvre une KYC efficace, et même des projets connus (comme RealT) ont eu des processus de vérification vidéo qui pouvaient être facilement trompés par une simple photo. Certains projets, bien qu'insistant sur l'AML dans leur livre blanc, ne nécessitent en pratique qu'une connexion de portefeuille pour trader, sans aucune possibilité de tracer l'origine des fonds.

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

Recommandation de développement pour Pharos :

• Ne faites pas de vérification d'identité uniquement sur le front-end web. Il est impératif d'intégrer un mécanisme de liste blanche au niveau du smart contract, garantissant que seules les adresses vérifiées par DID (Identité Décentralisée) ou KYC hors chaîne peuvent appeler les fonctions de mint ou transfer. Prenons l'exemple du $STBT : réécrivez les fonctions transfer et transferFrom d'ERC-20 pour que seules les listes blanches certifiées puissent les appeler.

https://etherscan.io/address/0x530824da86689c9c17cdc2871ff29b058345b44a#code

• Pour les transactions sur actifs à haute valeur, introduisez un mécanisme 2FA (Authentification Facteurs) pour prévenir le vol d'actifs dû à la compromission de clés privées ; des études montrent que seuls une minorité de projets l'ont mis en œuvre à ce jour.

2. Dépendance aux Stablecoins et Disjonction (Depeg)

Les stablecoins sont le sang des RWA, près de 90% des projets en dépendent pour le règlement. Mais les développeurs négligent souvent le risque de déconnexion (depeg) des stablecoins eux-mêmes, comme le dépeg de l'USDC dû à l'incident SVB ou les risques de dépeg de l'USDe [2]. Si un dépeg se produit, le projet dispose-t-il d'une réserve de risque dédiée pour gérer la crise ?

https://x.com/ethena_labs/status/1976773136294224071

Recommandation de développement pour Pharos :

• Les oracles ne servent pas seulement à fournir des prix, ils doivent aussi agir comme déclencheurs de gestion des risques. Lorsque le prix du stablecoin utilisé comme monnaie de règlement (ex: USDC/USDT) s'écarte de sa valeur ancrée au-delà d'un seuil (ex: 5%), le contrat doit automatiquement suspendre le minting et le rachat (redeem) pour empêcher les attaques par arbitrage contre le protocole.

• Lors de la conception des pools de liquidités, envisagez de supporter plusieurs stablecoins, voire un panier de devises, pour réduire l'impact du risque systémique d'un actif unique. Évitez également, dans le choix des stablecoins, ceux à mécanisme complexe (algorithmiques), car ils sont les plus sujets au dépeg.

3. Pontage des Données et Vérification de l'Authenticité

La plus grande boîte noire des RWA est de savoir si l'actif sur chaîne correspond vraiment à un actif physique hors chaîne. De nombreux projets se contentent de mettre quelques fichiers PDF en guise de divulgation d'informations, il y a même eu le cas absurde d'une vidéo en boucle utilisée pour冒充 (prétendre être) une surveillance en temps réel. Les rapports de valeur nette d'actif (NAV) d'OpenEden ont également accusé un retard d'un mois par le passé.

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

Recommandation de développement pour Pharos :

• Utilisez des réseaux d'oracles comme Chainlink pour se connecter directement aux API des banques dépositaires ou des cabinets d'audit hors chaîne. Les développeurs Pharos doivent viser une mise à jour minute par minute (minutage) de la valeur nette d'actif (NAV) sur chaîne, plutôt que de dépendre des rapports mensuels ou trimestriels du porteur de projet.

• Le risque d'écart d'évaluation des projets survient fréquemment. Lors du développement, introduisez l'alimentation par prix (feed) de multiples sources d'oracles pour que le prix sur chaîne reflète le plus fidèlement possible le marché hors chaîne.

4. Isolation et Transparence des Entités Légales

Le défaut de paiement sur actifs hors chaîne est un risque des RWA à ne pas négliger, comme Goldfinch qui a subi un défaut de crédit de 5,9 millions de dollars [4]. La clé pour isoler le risque réside dans les SPV (Sociétés à Objet Spécial), mais seule une minorité de projets déclarent publiquement utiliser une structure SPV, et la plupart ne divulguent pas le nom légal spécifique de l'entité enregistrée. Prenons l'exemple de la crise de Goldfinch : elle a directement causé une chute de 20% du jeton $GFI, les investisseurs subissant des pertes importantes de manière incompréhensible.

Recommandation de développement pour Pharos :

• Dans les métadonnées du projet ou la documentation, imposez la divulgation du nom légal et du lieu d'enregistrement du SPV détenant les actifs.

• Assurez-vous que chaque pool d'actifs corresponde à un SPV indépendant. Dans la conception des contrats sur Pharos, les fonds de différents pools d'actifs doivent être logiquement complètement isolés pour éviter qu'un défaut sur un seul actif n'épuise la liquidité de l'ensemble du protocole.

5. Assèchement de la Liquidité après une Prospérité Illusoire

La liquidité est l'aspect le plus facile à falsifier mais aussi le plus susceptible de s'effondrer dans un projet RWA [2]. La profondeur du carnet d'ordres à la mise en ligne de nombreux projets RWA dépend fortement des subventions aux market makers. Une fois les protocoles de market making arrivés à expiration ou les subventions arrêtées, la profondeur du marché secondaire connaît souvent une chute vertigineuse, les ordres d'achat disparaissant instantanément. De plus, il existe un décalage temporel naturel entre la faible fréquence d'évaluation des actifs hors chaîne (généralement mensuelle ou trimestrielle pour le NAV) et la haute fréquence des transactions sur chaîne (blocs à la seconde). Lorsqu'une vente importante se produit sur chaîne, le pool AMM (Market Maker Automatique), faute d'indication en temps réel de la juste valeur, ne peut souvent pas se realimenter rapidement, ce qui entraîne un écart important entre le prix et la valeur nette, créant un trou noir de liquidité. Prenons l'exemple de l'$USDR ci-dessous : en raison d'une ruée (bank run), le prix du jeton est rapidement passé de 1 dollar à 0,5 dollar en quelques heures [5].

https://www.blocktempo.com/not-so-tangible-usdr-stablecoin-collapses/

Recommandation de développement pour Pharos :

• Ne pariez pas entièrement sur la liquidité du marché secondaire DEX ou CEX. Les développeurs peuvent intégrer nativement dans le contrat une fonction de file d'attente de rachat/remboursement. Lorsque le prix du marché secondaire est nettement inférieur à la NAV (par exemple, une décote de plus de 3%), permettez aux détenteurs de contourner le marché secondaire et de soumettre directement au protocole une demande de remboursement adossée aux actifs sous-jacents du SPV, en utilisant un smart contract pour gérer la file d'attente de remboursement et la distribution des fonds.

• Calquez le système de réserves obligatoires des banques traditionnelles : lors de l'étape de Mint, retenez obligatoirement un certain pourcentage (par exemple 5%-10%) de stablecoins comme tampon de liquidité sur chaîne. Ces fonds ne sont pas utilisés pour acheter des actifs hors chaîne, mais sont spécifiquement destinés à exécuter automatiquement des rachats instantanés via un smart contract lorsque la liquidité du marché secondaire s'assèche, afin de défendre un plancher de prix.

6. Risque Hérité des Vulnérabilités Natives de l'EVM

Pharos offre une compatibilité totale avec l'EVM, ce qui signifie qu'en profitant de l'écosystème Solidity, les développeurs héritent également de tous ses vecteurs d'attaque classiques. Les contrats RWA, en raison des besoins de conformité, contiennent généralement un grand nombre de fonctions à haut niveau de privilège (comme blacklist, forceTransfer, pause), ce qui rend la gestion des autorisations et la mise à niveau par proxy des points de défaillance critiques bien plus sensibles que dans les protocoles DeFi.

https://owasp.org/www-project-smart-contract-top-10/

Recommandation de développement pour Pharos :

• Respect des bibliothèques standards : Ne réinventez pas la roue. Pour le contrôle d'accès, utilisez impérativement AccessControl ou Ownable2Step d'OpenZeppelin. Si la clé privée administrateur d'un RWA est volée à cause d'une vulnérabilité dans une logique personnalisée, cela signifie que la propriété des actifs physiques hors chaîne pourrait faire l'objet d'un litige juridique.

• Gestion des risques de mise à niveau par proxy : Les contrats RWA sont souvent de type pouvant être mis à niveau (UUPS/Transparent). Lors du déploiement des mises à jour, il est impératif de vérifier strictement les conflits d'emplacement de stockage (Storage Slot) pour éviter qu'un chevauchement de variables ne provoque une corruption de la table de mappage (Mapping) des actifs.

• Défense contre les attaques de réentrance : Lors du traitement de la logique de distribution des bénéfices (Distribute Yield) ou de remboursement, même pour les utilisateurs en liste blanche, il est nécessaire d'ajouter ReentrancyGuard à tous les appels externes (Call) pour empêcher les contrats malveillants de vider le pool de fonds en utilisant des fonctions de rappel (callback).

IV. Résumé

En revenant sur le développement de la niche RWA, nous avons vu trop de prospérités illusoires reposant sur un habillage de conformité via l'UI et le maintien de liquidité par market making. Dans l'écosystème Pharos, nous préconisons un paradigme de développement plus résilient.

En tant que développeur, il faut clairement comprendre que : les risques de sécurité des RWA n'existent pas seulement au niveau de l'implémentation du code des smart contracts, mais il faut également accorder de l'importance aux défaillances de validation des droits de propriété des actifs hors chaîne et aux inadéquations de liquidité, entre autres problèmes de sécurité. La finalité en moins d'une seconde de Pharos nous donne l'assurance nécessaire pour traiter des opérations financières complexes, mais cela exige des développeurs une rigueur accrue dans les stratégies d'intégration : écrire la KYC/AML dans la logique de base, faire appliquer strictement par le code un système de réserve de risque, et pousser la transparence des données d'actifs à l'extrême.

À l'avenir, la concurrence entre les protocoles RWA ne sera plus un jeu de chiffres sur le TVL, mais une compétition sur l'authenticité des actifs et la robustesse du système. Boucler cette dernière boucle de sécurité est une leçon obligatoire pour chaque constructeur de l'écosystème Pharos.