Développement de smart contracts : vos règles métier, appliquées de façon vérifiable.

Pas à lui seul. Un smart contract exécute des règles ; les droits et les obligations des parties relèvent des contrats juridiques et du cadre réglementaire applicable. Le code et les documents juridiques doivent donc dire la même chose : c'est pourquoi la spécification s'appuie sur vos documents contractuels, et pourquoi les questions juridiques sont traitées avec vos conseils. Une divergence entre les deux crée un risque difficile à corriger, puisque le code aura déjà été exécuté.

Chaque opération qui modifie l'état du contrat paie des frais de transaction au réseau, souvent appelés « gas ». Leur montant dépend du réseau choisi, de son activité au moment de l'opération, ainsi que du calcul et du stockage demandés. La simple lecture des données est en général gratuite. Le choix du réseau, la conception du contrat (ce qui est stocké sur la chaîne, ce qui reste dans vos systèmes) et l'écriture du code permettent de maîtriser ces frais ; ils sont mesurés pendant les tests.

Le code d'un contrat déployé ne se modifie pas. Une évolution n'est possible que si elle a été prévue à la conception : logique remplaçable, mise à jour soumise à plusieurs signatures, délai avant application ou suspension d'urgence. Sans ces mécanismes, corriger une faille impose de déployer un nouveau contrat et d'y faire migrer les utilisateurs et, le cas échéant, les actifs. Chaque mécanisme a son revers : il crée des droits d'administration qu'il faut protéger. Ces choix se font donc avant le déploiement, avec vous.

Pas directement : un contrat ne lit que les données présentes sur la chaîne. Une information extérieure, comme un cours, une date de livraison ou le résultat d'une vérification d'identité, doit lui être transmise par une transaction, envoyée par votre application ou par un service spécialisé appelé oracle. Le contrat applique ses règles à cette information sans pouvoir en vérifier l'exactitude. La fiabilité de la source, le nombre de sources et la conduite à tenir si l'une d'elles est indisponible font donc partie de la conception.

La relecture fait partie du développement : elle vérifie que le code applique la spécification et repère les erreurs avant le déploiement. Un audit est une analyse menée par un intervenant indépendant, qui n'a pas écrit le code et remet son propre rapport sur les risques identifiés. Nous réalisons la relecture et préparons l'audit ; nous ne délivrons pas de rapport d'audit. Ni l'une ni l'autre ne garantit l'absence de faille : toutes deux réduisent le risque.