この記事はMichael G. Solomon, PhD CISSP PMP CISMによるゲスト投稿です。
ブロックチェーン技術はビジネスパートナー間のレジリエントで信頼性の高い情報交換を可能にすることから、ここ数年、あらゆる分野の企業でブロックチェーンへの関心が増しています。
ブロックチェーンは暗号通貨を主流に押し出す手段として始まったものですが、ブロックチェーン技術の比較的新しいアプローチがビジネスのさまざまな面に影響を与えるようになってきています。それがエンタープライズブロックチェーンです。
エンタープライズブロックチェーンの実装は、より一般的なパブリックブロックチェーンとは異なります。エンタープライズレベルへのスケールアップは、ブロックチェーン技術に対して独自の要求を提示します。新しいアプリケーションは、さまざまな契約を確実に果たせるよう、アプリケーション開発およびテストへのアプローチを刷新することを要求します。
それでは、エンタープライズブロックチェーンアプリがどのような点でパブリックなコンシューマーブロックチェーンアプリと異なるか、またこの新たな種類のアプリケーションをどのようにテストするのが最適かを説明していきます。
企業がブロックチェーンに課す新たな要求
ブロックチェーン技術は、Satoshi Nakamotoを名乗る著者（あるいは著者たち）による2009年の論文で提案されたのが始まりです。Nakamotoはトラストレスな分散型台帳を使用して暗号通貨ビットコインを実装する革命的なアプローチを提案しました。この新しい技術は、分散化された非中央集権型ストレージおよび処理技術において大きな飛躍でしたが、ビットコインはブロックチェーンの本当の可能性のほんの表面に触れただけでした。
ブロックチェーンの実装が急速に成熟し、暗号通貨の交換だけでなく、さまざまなトランザクションをサポートするようになると、第1世代のビットコインのアプローチでは、ブロックチェーンの制限が大きすぎることも明白になりました。ビットコインの実装には、複雑なトランザクションを自動でサポートするのに十分な機能がありませんでした。
ブロックチェーン革命の口火を切ったNakamotoの論文発表からたった4年後には、Vitalik Buterinが第2世代のブロックチェーン実装であるEthereumを提案しました。Ethereum は、ブロックチェーンネットワーク上のすべてのノードがブロックチェーンデータにアクセスする際に従うべきルールを定義するスマートコントラクトを導入しました。スマートコントラクトのおかげで、ブロックチェーンはエンタープライズ環境での実用にまた1歩近づきました。
あとは、エンタープライズユーザーがブロックチェーン技術を使い始めるために必要な新機能は、機密データを処理する方法、より高いパフォーマンス、そしてブロックチェーンアプリが従来のエンタープライズアプリケーションと共存できる能力でした。これは第3世代のエンタープライズブロックチェーンにおいて実現しました。
以降、いくつかのブロックチェーン実装が登場したり、次のリリース日を発表したりして、このようなニーズに対応しています。たとえばLinux FoundationのHyperledger Fabric、Enterprise Ethereum Allianceの次期Enterprise Ethereumなどです。これらの製品は以前のブロックチェーン実装の限界に対処し、エンタープライズITソリューションの一部としてブロックチェーン技術を組み込むことを可能にします。
エンタープライズITソリューションは、どんな技術にも独自の要求を提示します。個別の対応をほとんど必要とせずに他のITコンポーネントと統合できなければなりませんし、高頻度のアクティビティでも、割り当てられた機能をタイムリーに実行し、ダウンタイムは最小限でなければなりません。簡単に言うと、エンタープライズITソリューションは人間によるメンテナンスをそれほど必要とせずに稼働し、機能する必要があります。レジリエンス、可用性、自律性、透明性は、すべてエンタープライズブロックチェーンアプリケーションをテストする際にきちんと対処するべき目標です。
これらの要件は一般的なアプリケーションテストの目標と同じように見えるかもしれませんが、エンタープライズブロックチェーン環境では、それぞれに今までにない困難があり、異なる点に注意が必要です。データおよびコードのコピーは複数の場所に永続的に存在します。スマートコントラクトの実行時間はすべてのノードで同じではない一方、結果は同じでなければなりません。一般的に、ブロックチェーン環境のトランザクションは、おなじみのデータベースアプリケーションと同じルールには従いません。ブロックチェーンのデータは本質的に不変であり、時系列順に格納されます。
このようなブロックチェーンアプリケーションの根本的な性質により、従来のアプリケーションより厳密なテストアプローチが必要になります。
エンタープライズブロックチェーンアプリケーションテストのタイプ
エンタープライズブロックチェーンアプリケーションのテストといっても、まったく新しいやり方があるわけではありません。すでに知っていることの拡張です。基本的に、従来型のアプリケーションで行っているテストはすべてブロックチェーンアプリケーションにも有効です。ただ、エンタープライズブロックチェーンアプリケーションをテストするとき、追加で検討すべきことがいくつかあります。
アプリケーションの非中央集権型という性質が動作にマイナスの影響を及ぼさないよう保証する必要があるでしょう。それは確実なテスト管理によって可能になります。エンタープライズブロックチェーンアプリケーションのテストで一般的なテストをいくつか見てみましょう。
機能テスト
機能テストはソフトウェアが意図したとおりに動作するかを検証します。経験の長いアプリケーションテスターにとっては最もなじみのあるテストのタイプでしょう。
違いは、エンタープライズブロックチェーンアプリケーションは、ほぼ常に、より大きなエコシステムの一部として動作することです。つまり、データの入力および出力は明確でなく、シミュレートが難しい場合があります。できるだけ多くの通常条件および境界条件をカバーするテストケースを作成することが重要です。通常、ブロックチェーンアプリケーションは自律性に依存しており、人間の介入なしで例外を処理できる必要があります。
すべてのスマートコントラクトはブロックチェーンに存在することを思い出してください。つまり、スマートコントラクトコードは、ブロックチェーンデータと同様に、本質的に変更不可能です。デプロイされたスマートコントラクトコードは、バグやなにかもを含めてそのまま存在し続けます。欠陥のあるスマートコントラクトがデプロイされないようにするには、ブロックチェーンアプリケーションのテストが極めて重要です。デプロイされてしまった欠陥は、従来型アプリケーションの場合よりも修正が困難であり、欠陥によってブロックチェーンに配置された不正なデータの処理も厄介な問題になる可能性があります。テストはそのような問題を防ぐのに役立ちます。
セキュリティテスト
エンタープライズブロックチェーンアプリケーションの特徴の1つに、ビジネスパートナー間で安全にデータを共有できるという点があります。クローズドなブロックチェーンでは、パートナーはすべて単一の組織に所属する場合もあります。コンソーシアム型ブロックチェーンでは、パートナーは多数の組織にわたる可能性があります。どちらにしても、ブロックチェーンの一部のデータを認可されたユーザーだけに制限する必要がある可能性は高いでしょう。
エンタープライズブロックチェーンの実装は、さまざまなアクセス制御手段および暗号化機能を提供し、制限付きのデータアクセスをサポートしていますが、テスト時にそのような機能を検証する必要があります。テストには、中央集権型のアクセス制御オーソリティから非中央集権型（あるいは一部非中央集権型）モデルに移行したとき、データのセキュリティ保証が低下しないことの検証を含めるべきです。
インテグレーションテスト
一般的に、エンタープライズブロックチェーンアプリケーションは、情報共有およびインテグレーションレイヤーで動作します。たとえば、多くのサプライチェーン型ブロックチェーンアプリケーションは、製品がプロデューサーからコンシューマーへと移動するのを追跡するメカニズムを備えています。参加コンシューマーはデータを処理し、場合によっては新たなデータをブロックチェーンに追加するいっぽうで、自社の独自のITシステムおよびアプリケーションも維持します。
各参加者はアプリケーションプログラミングインターフェイス (API)を通じて自社のITアプリケーションとブロックチェーンを統合する必要があります。APIはブロックチェーンのデータおよび機能へのエンタープライズアクセスにとって重要であり、外部アプリケーションとのスムーズで透過的な統合を保証するため、すべてのAPI機能をテストする必要があります。
パフォーマンステスト
現在、ブロックチェーン技術の課題としてよく言及されるものの1つが、スケーラブルなパフォーマンスの不足です。エンタープライズブロックチェーンの実装は、この批判に応えようと改善を続けています。第1世代と第2世代のブロックチェーンはコンセンサスメカニズムを使用しており、これが全体的なスループットに制限を加えます。
最も一般的なコンセンサスメカニズムであるプルーフオブワーク (PoW)は、リソースの要求が極度に高く、比較的低速です。PoWはまったく信頼性のない環境で問題なく動作しますが、持続可能ではありません。多くのエンタープライズブロックチェーンの実装は、プルーフオブステーク(PoS) やプルーフオブアクティビティ（PoA)などのより新しいコンセンサスメカニズムを使用します。エンタープライズ環境では、多くの場合、一定レベルの認証が存在するため、基本的なレベルの信頼性があり、計算だけによるコンセンサスの必要性はなくなります。
エンタープライズアプリケーションにはパフォーマンスやレスポンスの基準が設けられていることがよくあります。したがって、ブロックチェーンアプリケーションも、統合先の従来型のアプリケーションに課せられた最小限の基準を満たしている必要があります。パフォーマンステストは、ブロックチェーンアプリケーションが基準を満たしているかを確認するのに役立ちます。基準を満たしていなければ、別のコンセンサスメソッドを使う、スマートコントラクトを変更する、あるいはネットワークノードの構成を変更するといった対策を探る必要があるでしょう。パフォーマンステストを行えば、ブロックチェーンアプリケーションの改善のためのさまざまな変更につながる可能性があります。
ピアおよびノードテスト
非中央集権型の処理とストレージは、すべてのノードでブロックチェーンデータのコピーが同一になることを要求します。すべてのスマートコントラクトコードは確定的でなければなりません。つまり、すべてのノードでスマートコントラクトが同じ結果を生成する必要があります。異なる結果を生成するスマートコントラクトがあると、そのブロックチェーンのコピーと他のコピーに相違が発生します。
重要なのは、ノード間で異なる可能性があるローカルな入力がないようにすることです。そこでピアテストおよびノードテストの出番です。
テストでピアおよびノードの違いがスマートコントラクトの動作にどの程度の影響を与えるかを検証するべきです。すべてのスマートコントラクトコードは確定的でなければならず、同程度のパフォーマンスを発揮するべきです。パフォーマンステストでは、ブロックチェーンアプリケーションの全体的なパフォーマンスに着目するいっぽう、ピアおよびノードテストでは、複数のノードの相対的なパフォーマンスを比較するべきです。遅いノードをより早期に分離できれば、ブロックチェーンネットワークの全体的なパフォーマンスをより効果的に改善できます。
このタイプのアプリケーションテストは、従来型のIT環境では、デプロイメント後のアセスメントやメンテナンスの一部であるケースが一般的です。しかし、エンタープライズブロックチェーンでは、デプロイメント前のテストに含めることが重要です。
エンタープライズブロックチェーンアプリケーションテストの障害とベストプラクティス
エンタープライズブロックチェーンアプリケーションのテストに関する多くの領域は、従来型のソフトウェアアプリケーションのテストと似ていますが、ブロックチェーン技術固有の特性がいくつかの障害をもたらします。ブロックチェーン固有の細かな差異によって、テストはいくらか難しくなります。
スマートコントラクトは豊富な機能を備えていますが、多くの動作はサイレントです。一般的に、ブロックチェーンは自動化されたデータ処理および永続的ストアのコンポーネントとして実装されます。ブロックチェーンは、人間の介入はわずか、またはまったくなしでサイレントにデータを処理します。そのため、テストは少し難しくなります。ブロックチェーンが自律性を持つということは、できるだけ幅広いシナリオをカバーするよう、注意深くテストケースを設計する必要があることを意味します。
ブロックチェーンアプリケーションのテストでもう１つ異なることは、テストデータも含め、すべてのデータが永続的であるという点です。テストスイートをセットアップし、テストを実行した後、テストデータを削除するということはできません。データストアはブロックチェーンそのものであり、アプリケーションと一体化しています。従来のアプリケーションであれば、ソフトウェアとデータベースのあいだには、もっと明確に定義された区分があります。エンタープライズブロックチェーン環境でも「使い捨て」は可能であり、テスト用ブロックチェーンを新たに開始することもできますが、それは初めてデプロイする前にだけ可能な選択肢です。
最良の選択肢は、テスト用ブロックチェーンを作成し、徹底的にテストを行った後でスマートコントラクトコードを本番環境にデプロイすることです。これは一般的なソリューションですが、この場合、テスターは本番のネットワークをシミュレートできるだけで、実際の本番環境で動かすことはできません。
新規エンタープライズブロックチェーンを検証する際に気を付けるべきベストプラクティスは次のとおりです。
- 積極的にテストを行うことに対するトップレベルのサポートを取り付ける: ブロックチェーンのテストは従来型アプリケーションのテストよりも範囲が広いため、追加のテストを行うことに対して確実に意思決定者のサポートを得られるようにします。
- 早期に繰り返しテストする: 目新しいことではありませんが、早期にテストをすれば、対処が容易でコストが低いうちに問題や欠陥を発見できます。
- スマートコントラクトとセットでテストケースを設計する: 各スマートコントラクト機能のコードを作成するとき、テストケースも作成するよう開発者に推奨—あるいは要求—します。実際、機能するコードを記述する前にテストケースを作成するのはよいプラクティスです。コードを記述してから作成するテストケースは必ずと言っていいほど次善のテストケースにとどまります。
- 反復的テストを自動化する: 開発環境のテストツールを活用しましょう。たいていのエンタープライズブロックチェーン開発環境は、テストを手厚くサポートしています。
- 視覚表現とサービスを活用する: テスト結果のテキスト出力だけに頼らないようにしましょう。開発環境のツールや外部フレームワークを使用して、テストがどの程度目標に適っているかを視覚化します。テスト結果を視覚的に表現すると、傾向をつかんだり、プロジェクトの後半になってからでは取り返すのが難しい大きな過ちを防ぐことで開発コストを抑制したりするのに役立ちます。
ブロックチェーンがエンタープライズ環境に抱かせる期待はますます大きくなっています。新世代のアプリケーションが期待に応えるためには、ブロックチェーンアプリケーション製品を積極的にテストすることが必要です。
ブロックチェーン技術はあらゆる問題に対する解決策ではありませんが、確かに魅力的な利点があります。ブロックチェーン技術がエンタープライズレベルで受け入れられるには、ユーザーの肯定的な認識が不可欠であり、その肯定的な認識の鍵はテストにあります。
著者: Michael Solomon PhD CISSP PMP CISM, Professor of Information Systems Security and Information Technology at University of the Cumberlands
（この記事は、開発元Gurock社の Blog 「Testing Strategies for Enterprise Blockchain Apps」2020年1月14日の翻訳記事です。）