Développement de smart contracts, vérifié avant le code

Que compare la première vérification du contrat ?

1 vérification pré-développement compare les règles que vous envoyez avec le comportement que le contrat doit appliquer. Nous identifions les décisions manquantes avant l'implémentation, puis convenons de ce qui appartient à la chaîne.

Le tableau sépare 4 domaines de travail qui peuvent se trouver dans un même projet. Vos règles déterminent lesquels s'appliquent. Un contrat peut remplir une fonction. Les contrats connectés nécessitent davantage de décisions d'interface.

Pour chaque action, nous enregistrons qui la lance, quelles conditions s'appliquent et quels changements se produisent. Nous notons également les actions rejetées et les résultats attendus pour l'utilisateur. Cela donne à votre équipe un examen concret avant que le code ne transforme les hypothèses en comportement contractuel.

Si un token fait partie de la conception, reliez ce travail à la création et au déploiement de token.

7 éléments d'entrée qui maintiennent les décisions du contrat visibles

7 éléments d'entrée nous donnent un point de départ pratique pour le cahier des charges du contrat. Envoyez ce que vous avez ; marquez les éléments sans réponse au lieu de traiter des suppositions comme des règles approuvées.

• Objectif du produit : la tâche que le contrat doit accomplir.
• Flux utilisateur : actions de l'entrée à la réalisation.
• Rôles : utilisateurs, administrateurs et chaque permission dont ils ont besoin.
• Règles métier : conditions, délais et cas exceptionnels.
• Préférence de réseau : le réseau cible, s'il est déjà sélectionné.
• Interfaces : contrats existants et exigences de l'application.
• Besoins d'examen : exigences opérationnelles, juridiques ou d'audit connues.

Pour le vesting, incluez :

• Source d'allocation, bénéficiaire et condition de déclenchement.
• Schéma de libération et processus de réclamation.
• Si quelqu'un peut modifier un calendrier, et qui peut autoriser cette action.

Pour le staking, notez :

• Étapes de dépôt et de retrait.
• Entrées de récompenses et règles de réclamation.
• Comportement en pause.

Nous signalons les dépendances et les décisions ouvertes dans l'examen. Ensuite, nous demandons à votre équipe d'approuver les critères d'acceptation. Cette approbation donne à l'implémentation une référence claire.

Si votre travail s'étend au-delà du code du contrat, le développement Web3 peut couvrir le produit plus large. Le développement dApp traite de la couche applicative.

3 fenêtres de développement, des règles à la mise en production

3 fenêtres de travail maintiennent distinctes les décisions produit, le code et la préparation à la mise en production. Le calendrier exact suit les comportements convenus du contrat, les intégrations et les besoins d'examen.

1. Fenêtre des règles : nous cartographions les rôles, actions, conditions et cas limites. Votre équipe résout les décisions qui affectent le comportement du contrat.
2. Fenêtre du cahier des charges : nous enregistrons les comportements approuvés et les critères d'acceptation. Vous examinez le document avant le début de l'implémentation.
3. Fenêtre de développement : nous implémentons la logique convenue du contrat. Nous maintenons le code aligné sur le cahier des charges examiné.
4. Fenêtre de test : nous vérifions les chemins attendus, les permissions, les entrées invalides et les cas limites spécifiés. Les constats et les choix produit non résolus sont enregistrés pour examen.
5. Fenêtre de mise en production : nous préparons les notes de configuration et les détails de passation. Si un examen indépendant est inclus, nous coordonnons ses supports et ses questions.

Chaque fenêtre se termine par un artefact ou une décision examinable, pas par une approbation présumée. Vous pouvez voir ce qui est prêt et ce qui nécessite encore une réponse. Pour un produit connecté, confirmez quelle équipe est responsable de l'intégration applicative. Confirmez également quelles interfaces de contrat elle utilisera.

Que peuvent vous apprendre les tests et audits de contrat ?

Les tests montrent si le contrat suit les comportements convenus dans son cahier des charges. Un audit indépendant est un examen séparé, avec sa propre évaluation et ses propres constats.

Nous lions chaque comportement central à des vérifications spécifiques :

• Actions utilisateur.
• Permissions.
• Entrées invalides.
• Interactions entre les parties du contrat incluses dans le plan.

Nous résumons l'exécution des tests et enregistrons les éléments ouverts en langage clair. Cela aide votre équipe à distinguer un problème de code d'une règle produit qui nécessite encore une décision.

Pour un examen externe, préparez la version source exacte, une brève description du flux du contrat, les hypothèses connues, les dépendances et les instructions de test. Nous pouvons organiser ces supports, suivre les questions du réviseur et aider l'équipe à vérifier les correctifs convenus. Les tests de développement et la coordination d'audit sont séparés du propre travail du réviseur.

Un test ne peut pas déterminer comment un contrat déployé se comportera dans toutes les conditions réseau. Le fournisseur d'audit sélectionné contrôle ses constats. Le comportement du wallet et les intégrations tierces se situent également en dehors du code du contrat que nous développons. Gardez ces limites dans la décision de mise en production, aux côtés du cahier des charges, du rapport de test et des constats de l'examen.

3 enregistrements à transmettre du développement à la mise en production

3 enregistrements donnent à votre équipe une passation utilisable : les règles approuvées, les preuves de test et les notes de déploiement. Nous convenons de leur contenu avant le début du travail, afin que votre équipe sache à quoi s'attendre.

• Enregistrement d'audit : nous gardons le travail d'audit distinct. Si un audit externe fait partie du plan, son fournisseur est responsable de son évaluation ; nous coordonnons les supports et les réponses.
• Token ou application : alignez les décisions d'interface avec la création et le déploiement de token ou le développement dApp.
• Site web : un site web Web3 peut être planifié comme un composant produit séparé.

Chez DigitalMedia1, nous vérifions les règles et les interfaces avant l'implémentation. Ensuite, nous lions les tests à ces comportements approuvés. Envoyez-nous votre brief produit, votre réseau préféré et vos supports de contrat existants. Nous les examinerons et vous enverrons un devis écrit sous 2 jours ouvrés.

Comment ça marche

1. 1 — Envoyer les règles produitFenêtre : avant le cahier des charges. Envoyez les flux utilisateur, les rôles, la préférence de réseau, le code existant et les besoins d'examen connus.
2. 2 — Examiner le périmètre du contratFenêtre : examen du plan. Nous identifions les dépendances, les décisions ouvertes et les comportements qui nécessitent une approbation.
3. 3 — Approuver le cahier des chargesFenêtre : avant l'implémentation. Votre équipe vérifie les rôles, les flux, les cas limites et les critères d'acceptation.
4. 4 — Développer et testerFenêtre : implémentation et test. Nous développons la logique convenue et enregistrons les vérifications par rapport au comportement spécifié.
5. 5 — Préparer la passationFenêtre : préparation à la mise en production. Nous fournissons les notes de déploiement et coordonnons tout travail d'audit externe inclus.