007Développement de contrats intelligents

Entreprise de développement de contrats intelligents fondée sur la rigueur en ingénierie

Webisoft conçoit, code et teste des contrats intelligents qui font circuler de la valeur réelle sans incident. Un studio d'ingénierie montréalais fort de plusieurs années de travail blockchain en production, pour les équipes qui ne peuvent pas se permettre une faille.

Blkch002

001/

Ce que nous construisons

Des contrats pour chaque usage on-chain sérieux

D'un simple contrat de jeton à un protocole complet, nous gérons la conception, l'implémentation, les tests et le déploiement. Tout est écrit pour être audité, car le code on-chain est permanent et public.
  1. Contrats de protocoles DeFi

    Prêt, staking, coffres-forts, AMM et logique de rendement conçus autour d'invariants économiques clairs. Les flux de valeur sont modélisés et testés avant qu'une seule ligne de Solidity ne soit écrite.
  2. Contrats de jetons et d'actifs

    ERC-20, ERC-721, ERC-1155 et normes de jetons personnalisées avec vesting, contrôles de mint et logique d'approvisionnement. La tokenomics est implémentée exactement comme spécifiée, sans mauvaise surprise d'accès administrateur cachée.
  3. Tokenisation d'actifs du monde réel

    Contrats pour fonds tokenisés, immobilier et instruments financiers, incluant restrictions de transfert et whitelisting pour les contextes réglementés. La logique de conformité est appliquée on-chain, là où elle doit être.
  4. Systèmes DAO et de gouvernance

    Vote, gestion de trésorerie, timelocks et exécution de propositions bâtis sur des schémas éprouvés. Une gouvernance difficile à capturer et facile à vérifier.
  5. Évolutivité et architecture

    Modèles proxy, systèmes modulaires et chemins de migration choisis délibérément, avec les risques de chacun expliqués. Certains contrats doivent être immuables, et nous vous dirons lesquels.
  6. Tests et préparation à l'audit

    Tests unitaires, tests de fork, fuzzing et tests d'invariants avec une couverture élevée par défaut. Nous préparons la documentation dont les auditeurs ont besoin et corrigeons les constats rapidement au retour de l'audit.

Notre méthode de travail

De l'idée de protocole au mainnet

(4)
  1. 1

    Spécification et modélisation des menaces

    Nous transformons votre livre blanc ou votre idée de produit en une spécification technique précise, incluant les acteurs, les invariants et les façons dont un attaquant pourrait en profiter. L'ambiguïté dans la spécification est le terreau des failles, alors nous l'éliminons d'abord.
  2. 2

    Architecture et conception des contrats

    Nous choisissons la chaîne, les normes et la stratégie de mise à niveau, et concevons le système de contrats avec une surface d'attaque minimale. Vous validez l'architecture et les implications de coûts de gas avant l'implémentation.
  3. 3

    Implémentation et tests

    Des ingénieurs seniors écrivent les contrats avec une suite de tests complète, du fuzzing et des simulations de fork contre des protocoles réels avec lesquels vous vous intégrez. Le code est écrit pour l'auditeur et le prochain développeur, pas seulement pour le compilateur.
  4. 4

    Support à l'audit, déploiement et surveillance

    Nous coordonnons avec votre auditeur externe, corrigeons les constats et exécutons le déploiement avec code source vérifié et clés administrateur documentées. Après le lancement, nous mettons en place une surveillance pour détecter les anomalies avant qu'elles ne deviennent des incidents.
003/

Pourquoi Webisoft

Un travail blockchain soumis aux standards du génie logiciel

Webisoft livre des systèmes blockchain depuis les débuts du travail Ethereum en production, comme une pratique au sein d'un studio d'ingénierie plus large. Cela signifie que vos contrats bénéficient de la même rigueur que les logiciels bancaires, en plus des applications web et des back-ends construits par la même équipe.
  1. La sécurité avant la vitesse

    La modélisation des menaces, les tests d'invariants et la préparation à l'audit font partie du processus de base, pas d'une option payante. Les erreurs on-chain sont irrécupérables, alors le processus part du principe qu'un adversaire existe.
  2. Des ingénieurs seniors nord-américains

    Votre protocole est conçu et écrit par des ingénieurs expérimentés à Montréal, dans votre fuseau horaire et sur vos appels. Aucune sous-traitance anonyme.
  3. Livraison full-stack

    Les contrats sont rarement livrés seuls. Nous construisons les indexeurs, les API et les interfaces qui les entourent, afin qu'une seule équipe responsable détienne l'ensemble du système.
  4. Un conseil technique honnête

    Si votre cas d'usage n'a pas besoin de blockchain, ou si une fonctionnalité ajoute du risque sans valeur, nous le disons avant que vous ne dépensiez. Vous obtenez une opinion d'ingénieur, pas un argumentaire de vente.

FAQ

Questions que se posent les équipes avant d'écrire des contrats

(4)
  1. Le coût varie selon le nombre de contrats, la complexité de la logique économique et la profondeur des tests requis. Un jeton standard avec vesting est un petit mandat, tandis qu'un protocole de prêt avec oracles et liquidations est un projet de plusieurs mois. Les frais d'audit externe sont distincts, et nous vous aidons à définir et à planifier l'audit tôt, car les bons auditeurs sont réservés des semaines à l'avance.
  2. La majorité de notre travail se fait en Solidity sur Ethereum et les chaînes EVM comme Arbitrum, Base et Polygon, où l'outillage et la couverture des auditeurs sont les plus solides. Nous conseillons aussi sur les options non-EVM lorsqu'il y a une raison réelle de les utiliser. Le choix de chaîne est une décision d'affaires liée aux utilisateurs, à la liquidité et aux coûts, et nous vous accompagnons dans cette réflexion durant la phase de spécification.
  3. Nous testons de manière rigoureuse en interne avec des tests unitaires, du fuzzing et des simulations de fork, mais un audit doit être indépendant, alors nous recommandons toujours une firme tierce réputée pour la révision finale. Nous préparons le dossier d'audit, répondons aux questions des auditeurs et corrigeons les constats. Un code auto-audité est un signal d'alarme dans cette industrie, et nous le traitons comme tel.
  4. Le code source complet des contrats sous votre propriété, la suite de tests complète, les scripts de déploiement, les contrats vérifiés sur l'explorateur de blocs, et la documentation de chaque fonction et clé administrateur. Nous remettons aussi la surveillance et un plan d'intervention en cas d'incident. Votre équipe, ou toute firme compétente, peut maintenir le système sans nous.
005/

Là où nous ajoutons de la valeur

Une ingénierie de contrats intelligents qui résiste au mainnet

Les contrats sont immuables une fois déployés et détiennent des fonds réels, donc le niveau de rigueur se rapproche de l'aérospatiale plus que du développement web classique. Voici les domaines où notre travail change le résultat.
  1. Une architecture axée d'abord sur la sécurité

    Nous concevons en fonction des classes de failles connues avant d'écrire le code : réentrance, manipulation d'oracle, lacunes de contrôle d'accès, cas limites d'entiers et risques de mise à niveau. La modélisation des menaces se fait à l'étape de conception, là où les corrections coûtent des heures plutôt qu'un effort de récupération de fonds après incident. Chaque appel externe, rôle privilégié et transition d'état est cartographié et justifié.
  2. Une optimisation du gas basée sur des preuves

    Nous profilons chaque fonction avec des instantanés de gas dans Foundry et optimisons l'agencement du stockage, l'usage des calldata et la structure des boucles là où cela compte. L'optimisation est appliquée de façon sélective, car compacter les emplacements de stockage d'une fonction appelée une fois par an est un effort gaspillé, alors qu'un chemin de mint ou de swap très sollicité mérite une attention au niveau assembleur. Vous obtenez des chiffres avant et après, pas des affirmations.
  3. Déploiement multi-chaînes

    Nous déployons sur Ethereum mainnet, sur des L2 comme Arbitrum, Optimism et Base, et sur des chaînes non-EVM lorsque le cas d'usage l'exige. Chaque chaîne a des mécaniques de gas, des garanties de finalité et un support de précompilés différents, alors nous adaptons la conception du contrat plutôt que de redéployer aveuglément le même bytecode. Les hypothèses sur les ponts et la messagerie sont documentées explicitement.
  4. Une évolutivité gérée avec soin

    Les modèles proxy résolvent un problème et en créent trois, incluant les collisions de stockage, le risque lié aux clés administrateur et les questions de confiance des utilisateurs. Nous vous aidons à choisir entre contrats immuables, proxies UUPS ou transparents et modèles diamant selon votre modèle de gouvernance réel. Lorsque l'évolutivité est retenue, les fonctions administrateur reposent sur des timelocks et des multisigs, pas sur un seul EOA.
  5. Des tests au-delà des tests unitaires

    Les contrats en production reçoivent des tests de fuzzing, des tests d'invariants et des tests de fork contre l'état réel du mainnet, pas seulement une couverture de tests unitaires du chemin idéal. Nous écrivons des invariants comme la conservation de l'approvisionnement total ou les seuils de collatéralisation, et laissons le fuzzer les attaquer pendant des millions d'exécutions. Les tests de fork détectent les échecs d'intégration avec des protocoles réels comme Uniswap ou Chainlink avant que le déploiement ne le fasse.
  6. Préparation et réponse à l'audit

    Nous préparons les bases de code pour que les audits tiers soient productifs : documentation NatSpec complète, modèles de menaces, listes de problèmes connus et couverture de tests élevée avant que les auditeurs ne commencent. Pendant l'audit, nous trions les constats, les corrigeons avec des tests de régression et documentons les risques acceptés. Cela raccourcit les cycles d'audit et réduit le nombre de tours de révision payants.

Notre approche

Comment se déroule un mandat de contrat intelligent

(4)
  1. 1

    Spécification et modèle de menaces

    Nous commençons par écrire ce que le contrat doit faire, qui peut appeler quoi, et ce qu'un attaquant gagnerait en brisant chaque hypothèse. Le livrable est un document de spécification couvrant les rôles, les machines à états, les hypothèses économiques et les dépendances externes. La plupart des vulnérabilités que nous voyons en révision remontent à une décision qui n'a jamais été écrite.
  2. 2

    Développement avec tests continus

    Les contrats sont construits dans Foundry ou Hardhat avec des tests écrits en parallèle de chaque fonction, visant une couverture de branches complète plus des suites de fuzzing et d'invariants. Le code suit des schémas établis comme checks-effects-interactions et utilise des bibliothèques auditées comme OpenZeppelin lorsque c'est pertinent. Vous voyez le dépôt dès le premier jour, avec l'intégration continue qui fait tourner la suite complète à chaque commit.
  3. 3

    Révision interne et audit externe

    Avant tout audit externe, un second ingénieur qui n'a pas écrit le code effectue une révision interne structurée selon une liste de vérification des vulnérabilités. Nous soutenons ensuite l'audit tiers de votre choix, répondons aux constats avec des correctifs et des tests, et produisons un rapport final des éléments résolus et acceptés. Rien n'est déployé sur le mainnet avec des constats critiques ou élevés non résolus.
  4. 4

    Déploiement et surveillance

    Les scripts de déploiement sont testés sur des forks et des testnets, avec les transferts de propriété, les paramétrages et la vérification sur les explorateurs de blocs traités comme des étapes scriptées et reproductibles. Après le lancement, nous mettons en place une surveillance des événements anormaux, des transferts importants et des appels privilégiés, ainsi qu'un plan d'intervention. Nous pouvons rester en soutien pour les changements de paramètres, les mises à niveau et le support d'intégration après le lancement.

FAQ

Questions que les acheteurs posent avant d'embaucher une équipe de contrats intelligents

(6)
  1. La complexité de la machine à états et la valeur en jeu influencent le coût plus que le nombre de lignes de code. Un jeton simple représente quelques jours de travail, tandis qu'un protocole de prêt ou un système inter-chaînes implique des mois de conception, de tests et de cycles d'audit. Les audits externes sont un poste budgétaire distinct, généralement facturé par semaine de temps d'auditeur, et les protocoles complexes peuvent nécessiter deux firmes. Prévoyez que la phase d'audit et de correction dure aussi longtemps que le développement initial pour les systèmes à forte valeur.
  2. Si le contrat détiendra des fonds tiers significatifs, oui. Les tests et révisions internes détectent la plupart des problèmes, mais une firme indépendante avec un regard neuf et des outils différents constitue une couche de défense distincte, et de nombreux partenaires, plateformes d'échange et utilisateurs institutionnels exigeront le rapport. Pour les contrats à moindre enjeu, une révision interne plus légère combinée à une analyse automatisée peut être un compromis raisonnable. Nous vous aidons à déterminer le niveau d'assurance réellement nécessaire pour le déploiement.
  3. Cela dépend de qui sont vos utilisateurs et de ce qu'ils doivent pouvoir faire confiance. Les contrats immuables sont plus simples à comprendre et plus faciles à présenter à des utilisateurs avertis, mais un bug signifie une migration. Les proxies évolutifs permettent de corriger, mais concentrent le pouvoir chez celui qui détient les clés administrateur, ce qui devient une question de sécurité et parfois de réglementation. Un compromis courant est un contrat évolutif avec timelock et multisig, évoluant vers l'immuabilité ou la gouvernance on-chain à mesure que le protocole mûrit.
  4. Partez de l'endroit où se trouvent vos utilisateurs et votre liquidité, puis évaluez les frais, la finalité et la maturité de l'outillage. Ethereum mainnet offre la liquidité la plus profonde et la sécurité la plus forte, mais des coûts de gas élevés pour des interactions fréquentes. Les L2 comme Arbitrum, Base et Optimism réduisent considérablement les frais avec un outillage EVM quasi identique, ce qui convient aux applications grand public. Le déploiement multi-chaînes est possible mais multiplie la surface d'audit et la charge opérationnelle, donc nous recommandons généralement de valider le produit sur une seule chaîne d'abord.
  5. Aucun contrat en production ne devrait être contrôlé par une seule clé privée sur un ordinateur portable. Nous utilisons des portefeuilles matériels ou des services de gestion de clés pour les déploiements, transférons la propriété à un multisig comme Safe immédiatement, et plaçons les changements de paramètres sensibles derrière des timelocks. Les scripts de déploiement sont répétés sur des forks afin que l'exécution sur le mainnet ne comporte aucune improvisation. Nous documentons aussi exactement quelles adresses détiennent quels pouvoirs afin que votre équipe puisse auditer le contrôle à tout moment.
  6. Une description claire du mécanisme économique souhaité, même en langage simple, ainsi que toute documentation existante, modèle de tokenomics ou code antérieur. À partir de cela, nous produisons une spécification technique et une estimation cadrée avant le début du développement. Si vous avez déjà une base de code, nous commençons habituellement par une révision pour établir son état avant de l'étendre. La révision légale et réglementaire de la conception du jeton ou du protocole relève de vos conseillers, mais nous signalons les choix de conception qui attirent généralement un examen minutieux.