チェーンのパーティ名を指定すると、その状態を数値として返す関数を示しています。マップに格納されます。変数が有効な長さであること、およびその名前のパーティが存在することを確認します。それ以外の場合は、グローバル定数として定義された既定の状態を返します。このコードは完全に動作し、失敗することはないように見えますが、実際にはそうではありません。問題は、これらの条件を満たさない場合、既定値が返されることです。この動作では、呼び出し元からのエラーが隠されてしまう可能性があります。エラーが隠されてしまうと、それらのエラーはコードの他の部分に伝播し、トレースが困難な不整合が発生する恐れがあります。適切な手法を次に示します。パターンになっています。前提条件の確認が分離され、それぞれの失敗は個別に処理されます。これらの確認の一部、特に内部状態に依存するものは、関数修飾子を使用して実装できます。修飾子を使用して関数の動作を変更できます。関数を実行する前に自動的に条件を確認できます。つの修飾子が定義されています。つの修飾子を宣言の一部として適用しています。修飾子内のアンダースコア記号は、関数の本体が挿入される場所です。要求句を渡すことによって条件が満たされた場合は関数が実行され、それ以外の場合は例外がスローされます。スメルは、支払いが関与している場合に発生します。関数の呼び出しは関数の途中で行われます。関数は別のコントラクトでのコードの実行をトリガーできるので、この方法は安全ではありません。ここで、入金されるたびにエラーがスローされるだけのアドレスから、ある人物が入札する状況を考えてみましょう。別の人物がより高値を付けようとしたらどうなるでしょうか。関数は例外をスローします。関数呼び出しがエラーで終了すると、すべての変更がロールバックされるので状態は変化しません。他の誰も入札できず、コントラクトは破損します。ロジックから独立してユーザーに送金要求させることです。実装方法を示しています。refund;}ここでは、マップを使用して、より高値を付けた各入札者の払戻金の値を格納し、返金する関数を提供します。関数の呼び出しに問題があっても、影響を受けるのはその入札者だけです。トークンを送信するときには、プッシュ型支払いよりもプル型支払いを優先するようにしてください。コントラクトの設計パターンのほんの一部です。このような取り組みを簡単に実践するにはどうすればよいでしょうか。コントラクトを開発するためのライブラリです。標準の実装が提供されており、そのまま展開するか、ニーズに合わせて拡張できます。コンポーネントも提供されます。用意されていることです。バージョンにアップグレードするときもコントラクトが予期せず中断することはありません。パイプラインでプロジェクトを運用する方法について説明しています。テストネットに自動デプロイするためのフレームワークが提供されます。基本コントラクトをインポートし、継承を通じて拡張するだけです。プロジェクトと同様です。それらの変更をテストし、作業の増分をソース管理システムとソリューションのビルドに反映します。コードを共通のブランチに結合する要求では、さまざまな種類のテストが成功することが条件となるゲート承認が必要になる場合があります。以上のシステム環境にデプロイされます。アプローチでプロビジョニングできます。システム環境のデプロイを自動化して、コンポーネント、トポロジ、構成の一貫性を確保し、変更を手動でシステムに直接適用したときに発生することがある環境の差異が生じないようにします。アプローチを定義する際には、ブロックチェーン固有の一連の考慮事項を評価する必要があります。ストアよりも複雑です。ステートメントで事前にデータを追加することができます。スクリプトでブロックチェーンにデータを追加する作業は、より複雑になります。ブロックが時系列で接続されたものです。ネットワーク内のすべてのノード間でブロックが検証された後に、シーケンス内の最後のノードに追加されます。その後、有効なブロックがネットワークにブロードキャストされます。ノードにブロックが伝播し、それらのノードにあるデジタル台帳のコピー内に格納されます。スクリプトを使用してブロックチェーンに自動的にデータを追加することはできますが、それにはトランザクションの協調と順序付けが必要です。複数のパーティが関与する状況に対処する必要があります。このような処理を実現するために、既存のブロックチェーンの「フォーク」と呼ばれるスナップショットを作成する手法が使われるようになっています。これにより、多くの場合、代理トランザクションを作成して台帳にデータを追加するシステムを構築するという複雑な作業を行わなくても、同様の結果を得られます。ネットワーク内の一時的または永続的な分岐です。つのブランチに分割されるときにフォークが発生します。これは、合意アルゴリズムやその他のソフトウェアの変更によって発生する場合があります。フォークのいずれかに分類できます。フォークのしくみを示します。フォークは、ブロックチェーンの以前のバージョンからの永続的な分岐です。以前のバージョンを実行しているノードは、最新バージョンでは承認されなくなります。フォークは、プロトコルの根本的な変更であり、以前に有効であったブロックやトランザクションは無効になります。チェーン上のすべてのトランザクションは、古いチェーン上では有効になりません。ソフトウェアにアップグレードする必要があります。これにより、実質的にブロックチェーンのフォークが作成されます。アップグレードされた新しいブロックチェーンに続くパスと、古いブロックに沿って続くパスに分かれます。プロトコルが変更されても下位互換性が保たれます。フォーク済みの新しいチェーンでは新しいルールに従い、古いルールも受け入れられます。元のチェーンは引き続き古いルールに従います。フォークこの違いを考慮して、要件に応じてフォーク戦略を決定できます。フォークを選択します。フォークが適しているでしょう。プロセスでは、テスト環境と運用環境の違いをなくすか最小限に抑えようとします。ツールを使用してフォークを実現できます。(bit.ly/2Yab0ld)。指定するだけで、必要な操作が実行されます。ラインの例を次に示します。公開され、フォーク前に存在していた状態の読み取りで元のチェーンが参照されます。チェーンの長さに関係なく、フォークが発生しても明らかな遅延はありません。新しいブランチは既存のチェーンの最後のブロックから開始するためです。消費したり、既存のチェーンの状態を変更したりする必要はありません。ブロックを破棄することもできます。メンバーによるテストを含める必要があります。コントラクトのテストをさまざまなレベルで自動化するために役立ちます。台帳にデプロイできるようにする拡張機能です。シームレスに連携します。プロビジョニングできます。項目を選択するだけで、準備が完了します。コンソーシアムをわずかな手順でプロビジョニングしたり、既存のコンソーシアムに参加したりできます。コントラクトの開発を開始できます。コントラクトのフォルダーと名前を選択します。デプロイするために必要なすべてのファイルが含まれています。ファイルで使用できるようになります。コントラクトをデプロイできます。コントラクトのデバッグとテストを行う機能がまもなく提供されます。