スマートコントラクト開発：コードを書く前にルールを書き留める

コントラクト案件が提供すべきものとは

クイックテスト： 各コントラクト関数を、開発者でなくとも理解できる一文で説明してみてください。できない場合、そのルールはまだ明確ではありません。

スマートコントラクト開発は、製品の合意されたルールを、選択したブロックチェーン上でテスト可能かつリリース準備可能なコードに変換します。有用な成果物とは、コード単体ではなく、その実装の期待される動作、境界、引き継ぎが製品チームにとって明確であることです。

このサービスは、トークン関連コントラクト、権利確定スケジュール、ステーキングフロー、dAppが呼び出すコントラクト関数など、カスタムのオンチェーンロジックが必要なプロジェクトに適しています。コントラクトがより広範な製品の一部である場合、Web3開発やdApp開発と計画を連携させ、インターフェースとコントラクトが入力、権限、ユーザーアクションについて一致するようにします。

実装前に以下を準備してください：

• 各ユーザーアクションとその期待される結果を平易な言葉で記述したもの。
• 使用予定のブロックチェーン、および既存のコントラクトや製品の依存関係。
• アクセス、タイミング、変更、例外的なケースに関するルール。
• 未解決の製品に関する質問を解決できる、指名された意思決定者。

ルールをまだ明確に指定できない場合は、暗黙のエンジニアリング上の選択にせず、「未決定」としてマークしてください。未解決の質問をレビューリストにまとめ、開発開始前にコントラクト計画を確認します。

要件はどのようにテスト済みの動作になるのか？

各要件を観察可能なコントラクト動作とテストにマッピングしてから、リリース可能と見なします。これにより、プロジェクトチームは「ステーキングをサポートする」といった大まかな説明に頼るのではなく、実装が意図したルールに合致しているかを実用的に確認できます。

作業の流れは単純です。ユーザーの役割と許可されたアクションを明確にし、期待される状態変化を定義し、無効または不完全な入力を特定し、合意されたケースを実装してテストします。各関数について、合格基準は、有効な呼び出しが何を行うか、誰がそれを実行できるか、条件が満たされない場合に何が起こるべきかを示す必要があります。これらの基準をプロダクトオーナーとレビューし、開発の基礎とします。

有用な計画上の区別は、コントラクトの動作と製品体験の間です。コントラクトは割り当てられたルールを処理し、接続されたアプリは状態を説明したり、データを表示したり、トランザクションをガイドしたりする必要があるかもしれません。両方が計画に含まれる場合、dApp開発とその境界を調整します。作成とデプロイだけでなくカスタムロジックも必要なトークンについては、コントラクト要件をトークン作成とデプロイと連携させてください。

合意された動作と対応するテストの記録を受け取ります。これにより、後の製品変更の評価が容易になります。チームは更新を承認する前に、どの既存ルールが影響を受けるかを特定できます。

コントラクト仕様のための7項目チェックリスト

コードを書く前に、以下の7項目を書き留めてください。これらが、すべてのテストが照合される合格基準となります。チェック済みのリストは記録として保管してください。後で何が合意されたかを説明する最も迅速な方法です。

1. 各コントラクトとその役割を1つ挙げる。
2. 各関数を呼び出せるのは誰かを記述する。
3. 権利確定とステーキングのスケジュールを正確な数値で定義する。
4. コントラクトがアップグレード可能かどうか、また誰がそれを行うかを決定する。
5. 失敗ケースとそれぞれの期待される結果を列挙する。
6. チェーンとトークン規格を選択する。
7. リリース前に独立したレビューを計画する。

用語を一言で

権利確定（ベスティング）：固定スケジュールに従って、トークンを段階的に保有者に解放すること。

アップグレード可能なコントラクト（平たく言えば、デプロイ後にロジックを置き換えられるコントラクト）。

権利確定とステーキングのルールを指定する

権利確定とステーキングのコントラクトには、資格、タイミング、ユーザーアクション、製品が表示する結果に関する明示的なルールが必要です。機能に名前を付けるだけでは不十分です。コントラクト計画は、実装がサポートすべきケースと拒否すべきケースを記述する必要があります。

権利確定については、誰が割り当てを受け取るか、何がスケジュールを開始するか、リリースがどのように計算されるか、スケジュール設定後に変更が許可されるかどうかを決定します。ユーザーが割り当てを確認したり、利用可能なリリースを要求したりする場合に、製品がどのように処理すべきかを確認します。ステーキングについては、参加者が取れるアクション、エントリーとイグジットに適用される条件、コントラクトが関連する残高や状態をどのように表現するかを定義します。これらは、チームと確認すべき要件であり、私たちが黙って選択するデフォルト設定ではありません。

以下の準備チェックリストを使用してください：

• 各コントラクト関数を作成、管理、または使用できる役割を特定する。
• タイミングルールと、有効なアクションと見なされるものを書き留める。
• 例外的なケースをどのように処理し、伝達するかを決定する。
• 確定した製品ルールと、まだレビュー中のポリシーやトークンに関する決定を分離する。

トークンの供給または配布が同じリリースの一部である場合は、トークン作成とデプロイと計画を連携させてください。ユーザーが専用ウォレット体験を通じて操作する場合は、仮想通貨ウォレット開発と早期に連携し、コントラクトとインターフェースの要件を一緒にレビューすることを検討してください。

この案件に含まれるもの

経験則： テストはあなたが考えたことを示します。独立したレビューはあなたが考えていなかったことを示します。

この案件には、合意されたコントラクト計画と、チームがその作業をレビュー、テスト、リリース準備するために必要な資料が含まれます。キックオフ時に受け取るものを確認し、完了の共通定義を確立します。これには、チームまたは外部監査人に依存する作業も含まれます。

承認された計画に応じて、受け取るものには以下が含まれます：

• コントラクト要件と合格基準の文書による概要。
• 選択されたブロックチェーンと合意された機能のためのカスタムコントラクト実装。
• 計画中に定義された動作とエッジケースをカバーするテスト。
• ビルドとリリースノート。何がレビュー可能で、何が未解決かを説明します。
• 独立した監査の調整。合意された資料のパッケージ化と、調査結果への対応の整理を含みます。

監査調整とは、チームが明確なレビューの引き継ぎを準備し、フィードバックをコード変更に追跡できるように支援することです。これは、監査が実施されたこと、または監査人がコードを承認したことを表明するものとは異なります。製品にコントラクトの動作を説明するウェブサイトやランディングページが必要な場合、技術計画はWeb3ウェブサイトおよびランディング開発と連携させることができます。

強力な引き継ぎにより、社内チームは何が構築され、何がテストされ、どの決定が自分たちに残されているかを理解できます。プロジェクトオーナーと受け取るものをレビューし、承認された変更を記録し、作業が完了と見なされる前にリリースステータスを明確にします。

プロジェクトはどのように計画され、レビューされるのか？

プロジェクトは、要件から実装へと、名前付きのレビューポイントを通じて進行し、タイミングは確定した計画から設定されます。小さく明確に定義されたコントラクトと、複数の機能を持つシステムでは同じ計画は必要ないため、まず何を構築するのか、誰が決定を下すのかを確立します。

キックオフでは、選択されたブロックチェーン、コントラクトの依存関係、製品ルール、既存のコード、承認責任者を確認します。開発中は、合意された要件に対する進捗を共有し、動作を変える可能性のある質問を、土壇場の驚きになる前に提起します。合格基準に照らして実装をレビューし、要求された変更を確認用の具体的な項目として記録します。

スケジュールは、要求に応じて外部レビューも考慮します。資料の準備ができた時点で調整を行い、監査人のフィードバックを関連する要件に結び付け、合意された計画にどの変更が含まれるかを確認します。チームは、製品やアクセスに関する質問に迅速に回答できるように計画してください。未解決の決定は、実装やリリース準備を遅らせる可能性があります。

作業の評価を容易にするために、完了した項目、未解決の決定、テストステータス、次のアクションを分けた進捗状況を定期的に確認することをお勧めします。MarketingExtraは、エンジニアからクライアントへの直接的な合格基準とテストカバレッジのレビューを採用しており、製品動作を承認する人々が各テストの意図を確認できます。結果として得られる納品計画は、ビルドを進める前に確認されます。

コードをリリースする前に知っておくべきこと

注意深い開発プロセスはレビュー可能性を向上させますが、テストと監査調整があらゆるリリースリスクを排除するわけではありません。テストはカバーするケースのみをチェックでき、独立した監査人は問題を特定したり変更を要求したりする可能性があります。デプロイは、チームが正確なリリースとターゲットネットワークを承認するまで待つべきです。

責任ある引き継ぎのために、デプロイされたバージョンがチームがレビューしたバージョンと一致すること、リリース権限が理解されていること、プロジェクトにリリース後の質問に対応する担当者がいることを確認してください。承認された要件、テスト結果、該当する場合は監査人のフィードバック、最終的なリリース決定の記録を保管してください。これらの資料は、チームが検証済みの作業と、開発計画の範囲外にある決定や運用責任を区別するのに役立ちます。

コントラクト開発がより大規模な構築の一部である場合は、コントラクトを独立したゴールとして扱うのではなく、リリース計画をより広範なWeb3開発計画と連携させてください。ターゲットブロックチェーン、コントラクトの目的の簡単な説明、および既存の仕様やコードをMarketingExtraと共有してください。資料をレビューし、未回答の製品決定を特定し、作業のための文書化された計画を返します。

3つのことを送ってください：製品ルール、ターゲットチェーン、レビューのタイムライン。

仕組み

1. 製品ルールを共有する意図するコントラクトの動作、ターゲットブロックチェーン、既存のコードや仕様、既知の依存関係を送ってください。未解決の決定は明確にマークしてください。
2. 計画と合格基準を確認する役割、アクション、例外的なケース、受け取るものを意思決定者とレビューします。合意された基準が、開発とテストがカバーする範囲を確立します。
3. 合意された動作を構築しテストするエンジニアが計画されたコントラクトを実装し、承認されたテストケースに照らしてチェックします。動作に影響を与える質問は、決定のために差し戻されます。
4. 独立したレビューを調整する監査調整が含まれる場合、合意された資料を準備し、フィードバックを整理し、要求された変更をチームと追跡します。
5. リリースの引き継ぎをレビューする最終的な受け取り物、テスト記録、未解決項目をレビューしてから、選択されたネットワークへのリリース計画を承認します。