スマートコントラクト開発、コード着手前の確認

最初のコントラクトチェックでは何を比較しますか？

1回のプレビルドチェックでは、お送りいただいたルールと、コントラクトが強制する必要のある動作を比較します。実装前に未決定の判断事項を特定し、どの作業をオンチェーンで行うかを合意します。

この表は、1つのプロジェクトに含めることのできる4つの作業領域を区分しています。どの領域を適用するかは、お客様のルールが決定します。1つのコントラクトが1つの機能を提供する場合もあります。接続されたコントラクトには、より多くのインターフェース判断が必要です。

各アクションについて、誰が開始するか、どの条件が適用されるか、何が変更されるかを記録します。また、拒否されたアクションと期待されるユーザーアウトカムも記録します。これにより、コードが前提をコントラクト動作に変換する前に、チームが具体的にレビューできるようになります。

トークンが設計に含まれる場合は、この作業をトークン作成とデプロイと連携させてください。

コントラクトの判断を可視化する7つのインプット

7つのインプットが、コントラクト仕様書の実用的な出発点となります。お持ちのものをお送りください。未回答の項目は、推測を承認済みルールとして扱わずにマークしてください。

• プロダクトの目的：コントラクトが実行すべき役割。
• ユーザーフロー：開始から完了までのアクション。
• ロール：ユーザー、管理者、およびそれぞれに必要な権限。
• ビジネスルール：条件、タイミング、例外ケース。
• ネットワークの希望：ターゲットネットワーク（既に選択されている場合）。
• インターフェース：既存のコントラクトとアプリケーションの要件。
• レビューニーズ：既知の運用上、法律上、または監査上の要件。

ベスティングの場合は、以下を含めてください：

• 割り当て元、受益者、開始条件。
• リリースパターンと請求プロセス。
• スケジュールを変更できる者と、そのアクションを承認できる者。

ステーキングの場合は、以下を記述してください：

• 預入と引出の手順。
• 報酬の入力と請求ルール。
• 一時停止の動作。

レビューでは、依存関係と未決定の判断事項を明示します。その後、チームに承認基準を承認していただきます。その承認により、実装の明確な参照点が得られます。

作業がコントラクトコードを超える場合は、Web3開発がより広範なプロダクトをカバーできます。dApp開発はアプリケーション層を扱います。

ルールからリリースまでの3つのビルドウィンドウ

3つの作業ウィンドウにより、プロダクトの判断、コード、リリース準備を明確に区別します。正確なカレンダーは、合意されたコントラクト動作、統合、レビューニーズに従います。

1. ルールウィンドウ：ロール、アクション、条件、エッジケースをマッピングします。チームはコントラクト動作に影響する判断を解決します。
2. 仕様ウィンドウ：承認された動作と承認基準を記録します。実装開始前にドキュメントをレビューしていただきます。
3. ビルドウィンドウ：合意されたコントラクトロジックを実装します。コードをレビュー済み仕様に沿って維持します。
4. テストウィンドウ：期待されるパス、権限、無効な入力、指定されたエッジケースをチェックします。調査結果と未解決のプロダクト選択はレビューのために記録されます。
5. リリースウィンドウ：設定ノートと引継ぎ詳細を準備します。独立したレビューが含まれる場合は、その資料と質問を調整します。

各ウィンドウは、想定された承認ではなく、レビュー可能な成果物または判断で終了します。何が準備できていて、何にまだ回答が必要かがわかります。接続されたプロダクトの場合は、どのチームがアプリケーション統合を担当するかを確認してください。また、どのコントラクトインターフェースを使用するかも確認してください。

コントラクトテストと監査から何がわかりますか？

テストは、コントラクトがその仕様で合意された動作に従っているかどうかを示します。独立した監査は、独自の評価と調査結果を持つ別個のレビューです。

各コア動作を特定のチェックにリンクさせます：

• ユーザーアクション。
• 権限。
• 無効な入力。
• 計画に含まれるコントラクト部分間の相互作用。

テスト実行を要約し、未解決項目を平易な言葉で記録します。これにより、チームはコードの問題と、まだ判断が必要なプロダクトルールを区別できます。

外部レビューの場合は、正確なソースバージョン、簡潔なコントラクトフローの説明、既知の前提条件、依存関係、テスト手順を準備してください。これらの資料を整理し、レビューアの質問を追跡し、チームが合意された修正を検証するのを支援できます。開発テストと監査調整は、レビューア自身の作業とは別のものです。

テスト実行では、デプロイされたコントラクトがあらゆるネットワーク条件下でどのように動作するかを確定することはできません。選択された監査プロバイダーがその調査結果を管理します。ウォレットの動作やサードパーティとの統合も、私たちが構築するコントラクトコードの範囲外です。リリース判断では、仕様、テスト記録、レビュー調査結果とともに、これらの境界を考慮してください。

ビルドからリリースに引き継ぐ3つの記録

3つの記録が、チームに実用的な引継ぎを提供します：承認済みルール、テストエビデンス、デプロイノートです。作業開始前に内容を合意するため、チームは何を期待すべきか把握できます。

• 監査記録：監査作業は明確に区別します。外部監査が計画に含まれる場合、そのプロバイダーが評価を担当し、当社は資料と回答を調整します。
• トークンまたはアプリケーション：トークン作成とデプロイまたはdApp開発とインターフェース判断を連携させてください。
• Webサイト：Web3 Webサイトは、別のプロダクトコンポーネントとして計画できます。

DigitalMedia1では、実装前にルールとインターフェースをチェックします。そして、テストをそれらの承認された動作に結びつけます。プロダクト概要、希望ネットワーク、既存のコントラクト資料をお送りください。レビュー後、2営業日以内に書面による見積書をお送りします。

仕組み

1. 1 — プロダクトルールを送付ウィンドウ：仕様作成前。ユーザーフロー、ロール、ネットワークの希望、既存コード、既知のレビューニーズをお送りください。
2. 2 — コントラクト境界をレビューウィンドウ：計画レビュー。依存関係、未決定の判断事項、承認が必要な動作を特定します。
3. 3 — 仕様書を承認ウィンドウ：実装前。チームがロール、フロー、エッジケース、承認基準をチェックします。
4. 4 — ビルドとテストウィンドウ：実装とテスト。合意されたロジックを構築し、指定された動作に対するチェックを記録します。
5. 5 — 引継ぎ準備ウィンドウ：リリース準備。デプロイノートを提供し、含まれる外部監査作業があれば調整します。