チームでレビューできるルールを実現するスマートコントラクト開発

スマートコントラクト開発はどこから始めるべきですか？

ユーザーが実行する必要のあるアクションと、各アクションを管理するルールから始めます。それらの詳細を使用して、コードを書く前にコントラクトの動作を記述します。

1. ユーザーアクションに名前を付ける。 アロケーションの請求やアセットの預け入れなど、ユーザーが何をする必要があるかを説明します。
2. 条件を設定する。 アクションが許可されるタイミングと、許可されない場合に何が起こるべきかを記述します。
3. ロールを列挙する。 各機能を使用できる人と、設定を管理できる人（いる場合）を特定します。
4. 依存関係をマークする。 関連するコントラクト、アセット、サービス、またはインターフェース作業を記録します。
5. 動作をレビューする。 通常の使用と制限されたアクションを反映したテストケースに合意します。

これにより、実装前にチームがレビューできる共有の記述が得られます。また、まだ変更が議論しやすいうちに、未決定のプロダクトルールを早期に発見するのにも役立ちます。関連するトークン作業については、トークンの作成とデプロイメントを参照してください。

ユーザーがオンチェーンインターフェースを必要とする場合、dApp開発が同じプランの一部になる可能性があります。すべての技術的な選択を決めてからご連絡いただく必要はありません。決定済みの事項をお持ちいただき、未決定の事項をマークしてください。プロダクトに関する質問と実装の詳細を分けるお手伝いをします。

コントラクトをコミュニティの実際の運用に近づける

コントラクトのルールが、人々が実際に行うアクションと一致していると、計画が立てやすくなります。ユーザーに関する少しの背景情報があれば、標準的なトークンや報酬モデルを前提とせずに、その関連性を見出すことができます。

例えば、非常勤の管理者がいるDiscordサーバーで、どのチャンネルから始めるかを決めている状況を想像してください。チームはまた、コントリビューターがどのように時間をかけてトークンアロケーションを受け取るかを検討しています。まず、アロケーションのルール、誰が請求できるか、管理者の責任範囲を明確にします。その後、コントラクトのルールと、コミュニティがアップデートを共有する方法に関する決定を分離します。

例えば、プロダクトがトークンと一緒にステーキングを必要とする場合、預け入れと引き出しの仕組み、報酬の表現方法、計画が依存するアセットや他のサービスについて質問します。その回答を、仮定の経済設計ではなく、レビュー用の動作として記録します。

これらの境界は、関連する作業が関わる場合に重要です。Web3サイトとLPとのコントラクト要件の調整、または仮想通貨ウォレット開発への引継ぎのマッピングが可能です。すでに開発者がいるチームの場合は、作業開始前に各関連部分の担当者を合意できます。

チームが追跡できる引継ぎ資料

合意されたコントラクトの動作を理解するために必要なコードと作業ノートを受け取ります。開発前に内容を確認するため、汎用的なチェックリストではなく、プロダクトに適合した引継ぎが可能です。より広範なプロダクトニーズについては、Web3開発を参照してください。

ベスティングコントラクトでは、アロケーションと請求条件の明確な記述が必要になる場合があります。ステーキングの構築では、預け入れ、引き出し、報酬の動作を記録する必要があります。承認された機能に合わせて文書を構成するため、レビューアは記載されたルールとテストおよびコードを比較できます。これは、dApp開発とのインターフェース作業を計画する際にも役立ちます。

コントラクトがより大きなプロダクトの一部である場合、その責任範囲がどこで終わるかも明記します。これにより、関連作業の計画が容易になります。

最初のレビューからリリースまでの間には何が行われますか？

プロダクトの決定からレビュー済み仕様書の作成、構築、テスト、そして合意された引継ぎの準備へと進みます。チームはリリースを検討する前に、動作を確認する明確なポイントを得られます。

まず、プロダクトの目標、チェーン、ユーザー、および接続されたシステムをレビューします。キックオフチェックリストを使用してコントラクトのルールを収集し、未決定の選択肢を特定し、それらを承認する担当者を確認します。書面による動作を承認いただいた後、合意された機能を実装し、技術窓口と進捗を共有します。

テストは、設計時に合意されたケースに従います。監査調整が含まれている場合は、レビュー資料を準備し、技術的な質問を整理し、調査結果への対応をまとめます。変更が合意された場合は、関連するコードを更新し、関連するテストを再実行します。決定事項は書面の進捗ノートで可視化し、チームが何が準備完了で、何がまだレビューを必要としているかを確認できるようにします。

チェーンとコントラクトの設計によって、利用可能なリリース管理手段が決まります。テストは、記述されたケースのみをカバーします。独立した監査は、合意されたレビューの範囲に限定されます。デプロイメント後、コードを変更できるかどうかは、設計とチェーンに依存します。

コントラクトの境界を考慮した関連Web3作業の計画

コントラクトがトークン、インターフェース、またはウォレットフローに依存する場合は、関連コンポーネントを一緒に構築します。各部分の担当者を合意することで、オンチェーン動作とその周辺のプロダクトとの間のギャップを回避できます。

最初の確認として、すでに計画されている部分をリストアップし、それぞれに担当者を割り当てると便利です。コントラクトは、トークンローンチ、ユーザーインターフェース、ウォレットフロー、または別のサービスに接続される可能性があります。お客様の開発者とそれらの接続をマッピングし、コントラクト作業を他のチームが構築するものと明確に区別します。

プロジェクトには1人の技術窓口と書面による進捗ノートを提供します。その担当者が未解決の質問を追跡し、レビュー用に作業を共有し、次の決定を明確にします。以下の3つの開始点をお持ちください。

• プロダクトの概要と、コントラクトがサポートすべきユーザーアクション。
• 選択済みのターゲットチェーン（ある場合）、および既存のコードや技術ノート。
• 現在のベスティング、ステーキング、またはトークンルール（未回答の質問を含む）。

これらの資料をBrand Communityまでお送りください。一緒にレビューし、解決すべき決定事項を特定し、コントラクト構築の明確な計画を準備します。

仕組み

1. コントラクトの境界をマッピングするプロダクトの目標、ユーザー、ターゲットチェーン、および関連部分をレビューします。プロダクトオーナーの回答が必要な決定事項を特定します。
2. 書面による動作に合意する機能、ロール、条件、テストケースを記録します。実装開始前にチームが記述をレビューします。
3. 機能を構築しテストする合意された動作を実装し、期待されるアクションと制限されたアクションのテストを準備します。技術窓口と進捗状況や未解決の質問を共有します。
4. 独立したレビューを調整する監査調整が含まれている場合、レビュー資料を準備し、調査結果への対応を整理します。合意された変更を加え、関連テストを再実行します。
5. リリースと引継ぎを準備する合意されたコード、テストノート、デプロイメント資料を提供します。チームがリリースの責任を確認し、デプロイメントの詳細をチェックします。