Smart Contract Entwicklung, geprüft vor dem Code

Was vergleicht die erste Vertragsprüfung?

1 Pre-Build-Prüfung vergleicht die von Ihnen gesendeten Regeln mit dem Verhalten, das der Vertrag durchsetzen soll. Wir identifizieren fehlende Entscheidungen vor der Implementierung und legen dann fest, welche Arbeit on-chain gehört.

Die Tabelle trennt 4 Arbeitsbereiche, die in einem Projekt liegen können. Ihre Regeln entscheiden, welche zutreffen. Ein Vertrag kann eine Funktion erfüllen. Verbundene Verträge benötigen mehr Schnittstellenentscheidungen.

Für jede Aktion erfassen wir, wer sie startet, welche Bedingungen gelten und was sich ändert. Wir notieren auch abgelehnte Aktionen und erwartete Benutzerergebnisse. Dies gibt Ihrem Team eine konkrete Prüfung, bevor Code Annahmen in Vertragsverhalten verwandelt.

Wenn ein Token Teil des Designs ist, verbinden Sie diese Arbeit mit der Token-Erstellung und dem Deployment.

7 Eingaben, die Vertragsentscheidungen sichtbar halten

7 Eingaben geben uns einen praktischen Ausgangspunkt für die Vertragsspezifikation. Senden Sie, was Sie haben; markieren Sie unbeantwortete Punkte, anstatt Annahmen als genehmigte Regeln zu behandeln.

• Produktzweck: die Aufgabe, die der Vertrag erfüllen muss.
• Benutzerabläufe: Aktionen vom Einstieg bis zum Abschluss.
• Rollen: Benutzer, Administratoren und jede benötigte Berechtigung.
• Geschäftsregeln: Bedingungen, Zeitplan und Ausnahmefälle.
• Netzwerkpräferenz: das Zielnetzwerk, falls bereits ausgewählt.
• Schnittstellen: bestehende Verträge und Anwendungsanforderungen.
• Prüfungsbedarf: bekannte betriebliche, rechtliche oder Audit-Anforderungen.

Für Vesting fügen Sie hinzu:

• Zuteilungsquelle, Begünstigter und Startbedingung.
• Freigabemuster und Claim-Prozess.
• Ob jemand einen Plan ändern darf und wer diese Aktion autorisieren kann.

Für Staking notieren Sie:

• Einzahlungs- und Auszahlungsschritte.
• Belohnungseingaben und Claim-Regeln.
• Pausenverhalten.

Wir kennzeichnen Abhängigkeiten und offene Entscheidungen in der Prüfung. Dann bitten wir Ihr Team, die Abnahmekriterien zu genehmigen. Diese Genehmigung gibt der Implementierung eine klare Referenz.

Wenn Ihre Arbeit über Vertragscode hinausgeht, kann die Web3-Entwicklung das breitere Produkt abdecken. Die dApp-Entwicklung adressiert die Anwendungsschicht.

3 Build-Fenster, von Regeln bis zur Freigabe

3 Arbeitsfenster halten Produktentscheidungen, Code und Freigabevorbereitung getrennt. Der genaue Kalender folgt den vereinbarten Vertragsverhalten, Integrationen und Prüfungsanforderungen.

1. Regelfenster: Wir kartieren Rollen, Aktionen, Bedingungen und Randfälle. Ihr Team löst die Entscheidungen, die das Vertragsverhalten beeinflussen.
2. Spezifikationsfenster: Wir erfassen die genehmigten Verhaltensweisen und Abnahmekriterien. Sie prüfen das Dokument vor Beginn der Implementierung.
3. Build-Fenster: Wir implementieren die vereinbarte Vertragslogik. Wir halten den Code an der geprüften Spezifikation ausgerichtet.
4. Testfenster: Wir prüfen erwartete Pfade, Berechtigungen, ungültige Eingaben und spezifizierte Randfälle. Ergebnisse und ungelöste Produktentscheidungen werden zur Prüfung festgehalten.
5. Freigabefenster: Wir bereiten Konfigurationsnotizen und Übergabedetails vor. Wenn eine unabhängige Prüfung enthalten ist, koordinieren wir deren Materialien und Fragen.

Jedes Fenster endet mit einem prüfbaren Artefakt oder einer Entscheidung, nicht mit einer angenommenen Genehmigung. Sie können sehen, was bereit ist und was noch eine Antwort benötigt. Bestätigen Sie für ein verbundenes Produkt, welches Team die Anwendungsintegration übernimmt. Bestätigen Sie auch, welche Vertragsschnittstellen es verwenden wird.

Was können Vertragstests und Audits Ihnen sagen?

Tests zeigen, ob der Vertrag den in seiner Spezifikation vereinbarten Verhaltensweisen folgt. Ein unabhängiges Audit ist eine separate Prüfung mit eigener Bewertung und eigenen Ergebnissen.

Wir verknüpfen jedes Kernverhalten mit spezifischen Prüfungen:

• Benutzeraktionen.
• Berechtigungen.
• Ungültige Eingaben.
• Interaktionen zwischen Vertragsteilen, die im Plan enthalten sind.

Wir fassen die Testausführung zusammen und halten offene Punkte in einfacher Sprache fest. Das hilft Ihrem Team, ein Code-Problem von einer Produktregel zu unterscheiden, die noch eine Entscheidung benötigt.

Bereiten Sie für eine externe Prüfung die exakte Quellversion, eine kurze Vertragsablaufbeschreibung, bekannte Annahmen, Abhängigkeiten und Testanweisungen vor. Wir können diese Materialien organisieren, Prüferfragen verfolgen und dem Team helfen, vereinbarte Korrekturen zu verifizieren. Entwicklungstests und Audit-Koordination sind getrennt von der eigenen Arbeit des Prüfers.

Ein Testlauf kann nicht klären, wie sich ein deployed Vertrag unter allen Netzwerkbedingungen verhält. Der ausgewählte Audit-Anbieter kontrolliert seine Ergebnisse. Wallet-Verhalten und Integrationen von Drittanbietern liegen ebenfalls außerhalb des von uns erstellten Vertragscodes. Behalten Sie diese Grenzen in der Freigabeentscheidung, zusammen mit der Spezifikation, dem Testprotokoll und den Prüfungsergebnissen.

3 Aufzeichnungen, die vom Build in die Freigabe übergehen

3 Aufzeichnungen geben Ihrem Team eine brauchbare Übergabe: die genehmigten Regeln, die Testnachweise und die Deployment-Notizen. Wir vereinbaren ihre Inhalte vor Arbeitsbeginn, damit Ihr Team weiß, was es erwartet.

• Audit-Aufzeichnung: Wir halten die Audit-Arbeit getrennt. Wenn ein externes Audit Teil des Plans ist, gehört seine Bewertung dem ausgewählten Prüfanbieter; wir koordinieren Materialien und Antworten.
• Token oder Anwendung: Stimmen Sie Schnittstellenentscheidungen mit der Token-Erstellung und dem Deployment oder der dApp-Entwicklung ab.
• Website: Eine Web3-Website kann als separate Produktkomponente geplant werden.

Bei DigitalMedia1 prüfen wir die Regeln und Schnittstellen vor der Implementierung. Dann binden wir Tests an diese genehmigten Verhaltensweisen zurück. Senden Sie uns Ihr Produktbriefing, bevorzugtes Netzwerk und vorhandene Vertragsmaterialien. Wir prüfen sie und senden Ihnen innerhalb von 2 Werktagen ein schriftliches Angebot.

So funktioniert's

1. 1 — Senden Sie die ProduktregelnFenster: vor der Spezifikation. Senden Sie Benutzerabläufe, Rollen, Netzwerkpräferenz, vorhandenen Code und bekannte Prüfungsanforderungen.
2. 2 — Prüfen Sie die VertragsgrenzenFenster: Planprüfung. Wir identifizieren Abhängigkeiten, offene Entscheidungen und die Verhaltensweisen, die genehmigt werden müssen.
3. 3 — Genehmigen Sie die SpezifikationFenster: vor der Implementierung. Ihr Team prüft Rollen, Abläufe, Randfälle und Abnahmekriterien.
4. 4 — Bauen und testenFenster: Implementierung und Test. Wir bauen die vereinbarte Logik und halten Prüfungen gegen spezifiziertes Verhalten fest.
5. 5 — Übergabe vorbereitenFenster: Freigabevorbereitung. Wir stellen Deployment-Notizen bereit und koordinieren ggf. enthaltene externe Audit-Arbeit.