Développement d'applications financières sur Arc: quatre points qui fonctionnent différemment

Quicknode

8 octobre 2026 — 6 min de lecture

Partager

Ajouter comme source préférée

Arc est conçu pour des applications qui génèrent de la valeur dans le monde réel. Il conserve l'environnement d'exécution EVM, ce qui permet de continuer à utiliser les contrats Solidity existants et les outils d'Ethereum s habituels, tout en intégrant les frais de transaction, le règlement et d'autres exigences financières au sein même du réseau.

Ces choix modifient les systèmes liés au contrat. Deux des quatre différences présentées ci-dessous sont déjà disponibles sur Arc ; les deux autres font partie de notre feuille de route et doivent être considérées comme des orientations et non comme des fonctionnalités existantes.

1. L'USDC comme « gas »

Une application de stablecoin nécessite souvent deux actifs pour effectuer une action : le stablecoin transféré et un jeton distinct servant à payer les frais d'exécution. Cela crée un solde supplémentaire à approvisionner, un actif supplémentaire à valoriser, ainsi qu'un autre cas d'échec mode lorsque l'utilisateur dispose de fonds mais pas de suffisamment de « gas ».

Arc supprime cette distinction en faisant de l'USDC son actif de gaz natif. Les frais de transaction et la valeur de l'application partagent la même unité de compte, ce qui permet aux utilisateurs d'effectuer des transactions sans avoir à acquérir un jeton de gaz distinct. Les systèmes de trésorerie et de comptabilité peuvent également enregistrer le transfert et son coût d'exécution en dollars sans avoir à passer par une étape supplémentaire de conversion des prix. La conception des frais de Arc lisse les fluctuations de la demande sur le réseau afin de faciliter l'estimation des coûts, tandis que les méthodes RPC de frais standard permettent aux applications de lire les valeurs actuelles lors de l'exécution.

Un détail d’intégration mérite une attention particulière. L’USDC natif utilise 18 décimales pour les transferts de gaz et de valeurs EVM, tandis que son interface ERC-20 utilise la représentation familière de l’USDC à 6 décimales. Il s’agit de deux représentations d’un même solde, et non de deux actifs distincts. Les portefeuilles et les registres doivent donc normaliser ces représentations plutôt que de les afficher ou de les additionner toutes les deux. Les indexeurs doivent faire preuve de la même rigueur, car une activité ERC-20 peut générer à la fois un événement système natif et un événement d’interface pour un même mouvement, tandis que les envois natifs ne produisent que l’événement système. Un exemple d’ mainnet , présenté dans notre guide d’indexation USDCArc , montre quatre enregistrements de type « transfert » correspondant à deux mouvements USDC réels. Conclusion : la norme « Arc » supprime l’actif « gas » distinct, mais ne supprime pas la nécessité d’une vue canonique de l’USDC.

2. Finalité déterministe

Sur de nombreux réseaux, le fait qu'une transaction apparaisse dans un bloc ne signifie pas pour autant qu'une application puisse la considérer en toute sécurité comme finalisée. Les services attendent davantage de confirmations, traitent les activités récentes comme provisoires et conservent des chemins de retour en arrière au cas où la chaîne se réorganiserait.

ArcLe consensus Malachite BFT supprime cet état intermédiaire. Une transaction est soit non confirmée, soit définitive, et un bloc validé ne peut pas être réorganisé. Les applications peuvent agir dès la validation du bloc, sans avoir à convertir la profondeur de confirmation en un score de confiance.

Cela simplifie les flux de travail qui débutent ailleurs après un résultat sur la chaîne : mise à jour d’un grand livre, déblocage de stocks, notification à un autre service ou lancement de la transaction suivante. Les seuils de confirmation et la logique de retour en arrière en cas de réorganisation peuvent sortir du cadre de la machine à états de l’application. Le document « Arc » présente le règlement irréversible en moins d’une seconde comme une propriété de conception du réseau, et non comme un accord de niveau de service mesuré en production ; les équipes doivent donc continuer à mesurer le parcours complet de leurs utilisateurs.

La finalité ne remplace pas la fiabilité opérationnelle. Les connexions peuvent être interrompues, les consommateurs redémarrent, les livraisons sont relancées et les bases de données peuvent expirer. L'ingestion durable, les écritures idempotentes, les effets sans risque de relecture et la réconciliation restent essentiels. La « finalité de la chaîne » ( Arc ) rend la réponse de la chaîne définitive. L'application doit néanmoins traiter cette réponse de manière fiable.

3. La confidentialité en tant que modèle d'exécution distinct

Les applications financières ont souvent besoin de garantir la confidentialité sans pour autant transférer les opérations vers un système déconnecté. Les conditions des transactions, les soldes, les positions ou les contreparties peuvent nécessiter une divulgation contrôlée, tandis que les variations de valeur qui en résultent doivent tout de même s'inscrire dans le cadre de l'activité publique sur la blockchain.

Arc Le secteur « Privacy » (APS) est la réponse envisagée par Arc. Il figure dans la feuille de route et n'est pas encore disponible ; il devrait donc servir de base à l'architecture future plutôt que de constituer une promesse de produit actuelle.

APS est conçu comme un environnement d'exécution confidentiel pour les contrats Solidity, fonctionnant parallèlement à l'EVM publique. Les états publics et privés seraient enregistrés dans le même bloc, ce qui permettrait aux contrats des deux environnements d'interagir de manière atomique. Un workflow pourrait ainsi préserver la confidentialité d'un état sensible tout en gérant un effet public associé, sans avoir recours à une passerelle distincte ni à une couche de messagerie différée.

La limite de confidentialité serait explicite. Les fonctions, le stockage et les événements sont masqués par défaut, et ce sont les applications qui décident de ce qui peut être exposé et quels contrats peuvent interagir. La confidentialité fait ainsi partie intégrante de la conception de l'exécution, plutôt que de constituer une couche visant à masquer les données publiques après leur production. L'APS n'est pas encore disponible à l'heure actuelle, mais son avantage visé est clair : garantir la confidentialité sans renoncer à Solidity ni à la composition atomique.

4. Signatures de portefeuille post-quantiques

Les systèmes de signature qui protègent aujourd'hui les portefeuilles pourraient ne plus être sûrs face à des ordinateurs quantiques suffisamment puissants. Pour les applications dont la valeur s'inscrit dans la durée, se préparer à cette éventualité relève d'un problème de migration, et non d'une simple mise à jour logicielle de dernière minute.

ArcLa feuille de route post-quantique de commence par une prise en charge bêta, accessible sur option, des signatures de portefeuille SLH-DSA-SHA2-128s sur mainnet. Un portefeuille qui active cette option peut utiliser ce nouveau schéma pour autoriser les transactions. Cette protection s'applique au portefeuille. Elle ne s'étend pas aux signatures des validateurs et ne rend pas le consensus d'Arc post-quantique.

La prise en charge du protocole n'est qu'une première étape. Les portefeuilles matériels, les services de signature, les SDK, les politiques de conservation, les systèmes de récupération et les outils de transaction doivent tous prendre correctement en charge ce système. Les normes étant encore en pleine évolution, Arc s'attend à ce que l'adoption se fasse progressivement, plutôt que par un changement immédiat.

La feuille de route prévoit une extension progressive de la protection. Le chiffrement post-quantique pour l’exécution privée et les mises à niveau de l’infrastructure hors chaîne feront suite aux travaux sur les portefeuilles, tandis que les signatures des validateurs restent un objectif à long terme. L’intérêt pratique de la version bêta est donc bien précis : elle offre aux portefeuilles participants un moyen précoce de tester et d’adopter un système d’autorisation post-quantique sans pour autant surestimer le niveau de protection disponible sur le reste du réseau.

De la conception du réseau au comportement des applications

Ces différences ont un objectif commun. Le protocole « Arc » rapproche les exigences financières récurrentes du réseau : une unité stable pour la valeur et les frais, une limite de règlement claire, une voie vers une exécution confidentielle et un moyen de faire évoluer l’autorisation des portefeuilles. La compatibilité EVM permet aux développeurs d’utiliser cette base sans renoncer aux contrats et aux outils qu’ils connaissent déjà.

Les applications nécessitent toujours une comptabilité rigoureuse, des flux de données fiables, des contrôles d'accès bien définis et une infrastructure de portefeuilles sécurisée. La « Arc » modifie les fondements mêmes de ces systèmes, éliminant certaines complications habituelles tout en introduisant de nouvelles limites qu'il convient de bien comprendre.

Quicknode prend en charge Arc via des points de terminaison JSON-RPC et WSS, un accès complet aux archives avec des espaces de noms de débogage et de traçage, des abonnements WebSocket, Webhooks, ainsi que Streams. Commencez dès aujourd’hui à développer sur Arc Quicknode dès aujourd’hui.