Smart Contract Entwicklung für Regeln, die Ihr Team prüfen kann

Wo sollte der Bau eines Smart Contracts beginnen?

Beginnen Sie mit den Aktionen, die Ihre Nutzer ausführen müssen, und den Regeln, die jede einzelne bestimmen. Wir nutzen diese Details, um das Vertragsverhalten zu beschreiben, bevor wir Code schreiben.

1. Nennen Sie die Nutzeraktion. Beschreiben Sie, was jemand tun muss, z. B. eine Zuteilung beanspruchen oder einen Vermögenswert einzahlen.
2. Legen Sie die Bedingungen fest. Halten Sie fest, wann die Aktion erlaubt ist und was passieren soll, wenn sie nicht erlaubt ist.
3. Listen Sie die Rollen auf. Identifizieren Sie, wer jede Funktion nutzen kann und wer, falls vorhanden, Einstellungen verwalten kann.
4. Markieren Sie die Abhängigkeiten. Notieren Sie zugehörige Verträge, Vermögenswerte, Dienste oder Schnittstellenarbeiten.
5. Prüfen Sie das Verhalten. Stimmen Sie Testfälle ab, die die normale Nutzung und eingeschränkte Aktionen widerspiegeln.

Dies gibt Ihrem Team eine gemeinsame Beschreibung zur Prüfung vor der Implementierung. Es hilft uns auch, unentschiedene Produktregeln frühzeitig zu erkennen, während Änderungen noch leichter zu besprechen sind. Für verbundene Token-Arbeiten siehe Token-Erstellung und Deployment.

Wenn Nutzer eine On-Chain-Schnittstelle benötigen, kann die dApp-Entwicklung Teil desselben Plans sein. Sie müssen nicht jede technische Entscheidung vor dem Gespräch mit uns getroffen haben. Bringen Sie die getroffenen Entscheidungen mit, markieren Sie die offenen, und wir helfen, Produktfragen von Implementierungsdetails zu trennen.

Halten Sie den Vertrag nah an der Arbeitsweise Ihrer Community

Ein Vertrag ist einfacher zu planen, wenn seine Regeln mit den tatsächlichen Aktionen übereinstimmen, die Menschen ausführen müssen. Ein wenig Kontext über Ihre Nutzer hilft uns, diese Verbindung herzustellen, ohne ein Standard-Token- oder Belohnungsmodell anzunehmen.

Stellen Sie sich einen Discord-Server mit einem Teilzeit-Admin vor, der entscheidet, mit welchem Kanal er beginnen soll. Das Team arbeitet auch daran, wie Mitwirkende im Laufe der Zeit eine Token-Zuteilung erhalten. Wir würden zuerst helfen, die Zuteilungsregeln zu beschreiben, wer beanspruchen kann und wofür der Admin verantwortlich ist. Dann würden wir diese Vertragsregeln von Entscheidungen darüber trennen, wie die Community Updates teilt.

Angenommen, Ihr Produkt benötigt Staking neben einem Token. Wir würden fragen, wie Ein- und Auszahlungen funktionieren sollen, wie Belohnungen dargestellt werden und auf welche Vermögenswerte oder anderen Dienste der Plan angewiesen ist. Wir halten die Antworten als zu prüfendes Verhalten fest, nicht als angenommenes wirtschaftliches Design.

Diese Grenzen sind wichtig, wenn angrenzende Arbeiten beteiligt sind. Wir können Vertragsanforderungen mit einer Web3-Website und Landing Page koordinieren oder die Übergabe an die Crypto-Wallet-Entwicklung abbilden. Wenn Ihr Team bereits Entwickler hat, können wir vereinbaren, wer vor Arbeitsbeginn für jeden verbundenen Teil verantwortlich ist.

Eine Übergabe, der Ihr Team folgen kann

Sie erhalten den Code und die Arbeitsnotizen, die nötig sind, um das vereinbarte Vertragsverhalten zu verstehen. Wir bestätigen den Inhalt vor der Entwicklung mit Ihnen, damit die Übergabe zum Produkt passt und nicht einer generischen Checkliste folgt. Für breitere Produktanforderungen siehe Web3-Entwicklung.

Ein Vesting-Vertrag benötigt möglicherweise eine klare Beschreibung der Zuteilungs- und Beanspruchungsbedingungen. Ein Staking-Bau benötigt möglicherweise die Aufzeichnung des Einzahlungs-, Auszahlungs- und Belohnungsverhaltens. Wir gestalten die schriftlichen Materialien um die von Ihnen genehmigten Funktionen, sodass Prüfer die festgelegten Regeln mit den Tests und dem Code vergleichen können. Das kann Ihrem Team auch helfen, die Schnittstellenarbeit mit der dApp-Entwicklung zu planen.

Wenn der Vertrag Teil eines größeren Produkts ist, vermerken wir auch, wo seine Verantwortlichkeiten enden. Das erleichtert die Planung verbundener Arbeiten.

Was passiert zwischen der ersten Prüfung und dem Release?

Wir gehen von Produktentscheidungen zu einer geprüften Spezifikation über, dann bauen wir, testen und bereiten die vereinbarte Übergabe vor. Ihr Team hat klare Punkte, um das Verhalten zu prüfen, bevor ein Release in Betracht gezogen wird.

Wir beginnen mit der Prüfung des Produktziels, der Chain, der Nutzer und der verbundenen Systeme. Eine Kickoff-Checkliste hilft uns, die Vertragsregeln zu sammeln, offene Wahlmöglichkeiten zu identifizieren und zu bestätigen, wer sie genehmigen wird. Sobald Sie das schriftliche Verhalten genehmigen, implementieren wir die vereinbarten Funktionen und teilen den Fortschritt mit Ihrem technischen Ansprechpartner.

Das Testen folgt den während des Designs vereinbarten Fällen. Wenn die Audit-Koordination enthalten ist, bereiten wir die Prüfungsmaterialien vor, leiten technische Fragen weiter und organisieren Antworten auf die Ergebnisse. Wenn Änderungen vereinbart sind, aktualisieren wir den relevanten Code und führen die zugehörigen Tests erneut aus. Wir halten Entscheidungen in einer schriftlichen Fortschrittsnotiz sichtbar, sodass Ihr Team sehen kann, was fertig ist und was noch geprüft werden muss.

Die Chain und das Vertragsdesign bestimmen, welche Release-Kontrollen verfügbar sind. Tests decken nur die Fälle ab, die sie beschreiben. Ein unabhängiges Audit ist auf seine vereinbarte Prüfung beschränkt. Nach dem Deployment hängt es vom Design und der Chain ab, ob Code geändert werden kann.

Planen Sie verbundene Web3-Arbeiten um die Vertragsgrenze herum

Bauen Sie verbundene Komponenten gemeinsam, wenn der Vertrag von einem Token, einer Schnittstelle oder einem Wallet-Fluss abhängt. Die Vereinbarung, wer für jeden Teil verantwortlich ist, hilft Ihrem Team, Lücken zwischen dem On-Chain-Verhalten und dem Produkt darum herum zu vermeiden.

Eine nützliche erste Prüfung ist, die bereits geplanten Teile aufzulisten und für jeden einen Verantwortlichen zu nennen. Ihr Vertrag kann mit einem Token Launch, einer Benutzeroberfläche, einem Wallet-Fluss oder einem anderen Dienst verbunden sein. Wir können diese Verbindungen mit Ihren Entwicklern abbilden und dann die Vertragsarbeit von dem trennen, was ein anderes Team bauen wird.

Wir geben Ihrem Projekt einen technischen Ansprechpartner und eine schriftliche Fortschrittsnotiz. Diese Person verfolgt offene Fragen, teilt Arbeiten zur Prüfung und hält die nächste Entscheidung klar. Bringen Sie uns diese 3 Ausgangspunkte:

• Ihre Produktskizze und die Nutzeraktionen, die der Vertrag unterstützen soll.
• Die Ziel-Chain, falls gewählt, plus vorhandenen Code oder technische Notizen.
• Ihre aktuellen Vesting-, Staking- oder Token-Regeln, einschließlich unbeantworteter Fragen.

Senden Sie diese Materialien an Brand Community. Wir prüfen sie mit Ihnen, identifizieren zu treffende Entscheidungen und erstellen einen klaren Plan für den Vertragsbau.

So funktioniert's

1. Vertragsgrenze abbildenWir prüfen das Produktziel, die Nutzer, die Ziel-Chain und verbundene Teile. Sie identifizieren die Entscheidungen, die eine Antwort des Produktverantwortlichen benötigen.
2. Schriftliches Verhalten vereinbarenWir halten die Funktionen, Rollen, Bedingungen und Testfälle fest. Ihr Team prüft die Beschreibung vor Beginn der Implementierung.
3. Funktionen bauen und testenWir implementieren das vereinbarte Verhalten und erstellen Tests für erwartete und eingeschränkte Aktionen. Wir teilen Fortschritt und offene Fragen mit Ihrem technischen Ansprechpartner.
4. Unabhängige Prüfung koordinierenWenn die Audit-Koordination enthalten ist, bereiten wir Prüfungsmaterialien vor und organisieren Antworten auf Ergebnisse. Wir nehmen vereinbarte Änderungen vor und führen zugehörige Tests erneut aus.
5. Release und Übergabe vorbereitenWir stellen den vereinbarten Code, Testnotizen und Deployment-Materialien bereit. Ihr Team bestätigt die Release-Verantwortung und prüft die Deployment-Details.