はじめに

エンタープライズ企業がブロックチェーンを導入する際、開発・保守・運用の検討は避けては通れない。検討は様々な視点で行われるが、どのようなブロックチェーン特有の検討事項があるのだろうか。

本記事では、エンタープライズ企業がブロックチェーンを導入する際、開発・保守・運用において、どのような検討項目があるかについて紹介し、エンタープライズ企業がCordaでの開発を選択することに、どのようなメリットがあるかについて紹介する。

プログラミング言語

エンタープライズ企業は、ブロックチェーン導入のために、様々な方面でブロックチェーン基盤を比較するが、その中でも大きなポイントとなるのがプログラミング言語の比較だ。その理由はプログラミング言語そのものの信頼性の評価のため、エンジニアの単価の比較のためなど様々である。

ブロックチェーンの基盤によってスマートコントラクトを書くプログラミング言語は異なり、Solidity、Java、GOなど様々な言語がある。プログラミング言語自体の比較は本記事の趣旨とずれるため割愛させて頂くが、ブロックチェーン導入という文脈での例として、イーサリアムのSolidityとCordaのJavaを比較してみる。

※CordaはJavaの他にKotlinを使うことも可能。

まずはエンジニア確保のしやすさによる開発コストへの影響が挙げられる。ブロックチェーンのソリューションを導入したいエンタープライズ企業が開発を行う際、多くの場合ベンダー・SIerなどにお願いすることになる。場合によって開発のお願いをされたベンダー・SIerは更にフリーランスエンジニアや下請けの企業に開発の発注を行う。この際、比較的に新しいSolidityと長年多くのエンタープライズ企業が使ってきたJavaを比較すると、圧倒的に後者を使った開発の方がエンジニアを集めやすく、コストも低いはずである。

もう一つはエンタープライズ企業からの信頼度である。Javaはエンタープライズ企業における実績より、金融業界をはじめとする様々なエンタープライズ企業から厚い信頼がある。ここで特筆したいのは、決してSolidityが悪い言語と言いたいわけではなく、企業が意思決定を行う際には、過去実績も検討時の大きなポイントであり、そのようなことを気にするということだ。

サポートの有無

エンタープライズ企業がシステムを導入することに当たり、サポートの有無は非常に重要である。オープンソースが主流であるブロックチェーンの世界においては、Salesforce、Oracleのようなエンタープライズ向けのサービスのように、常にサポートがあるわけではない。

サービスに問題が生じた際、その問題はアプリ側にあるのか、それともブロックチェーン基盤にあるのか、はたまたプログラミング言語に脆弱性があったのかをエンドユーザーの企業だけで判断するのは難しい。また、システムを作ったベンダー・SIerはアプリ側の問題を解決できたとしても、ブロックチェーン基盤そのものの問題には対応しきれない場合がある。

仮に、ブロックチェーン基盤にバグがあった場合、パブリックチェーンの場合ではすぐバグの修正に取り掛かることができる保証はどこにもない。

エンドユーザーがCorda Enterpriseでアプリの開発を行う場合、アプリ側の問題はベンダー・SIerがサポートし、基盤の問題はCordaの開発を行うR3社がサポートし、プログラミング言語に問題がある場合、Javaを開発したプロバイダーが個別サポートを行う。エンタープライズ企業にブロックチェーンを導入する際、想定される問題の対応方法や責任を取る/取れる主体がいることで初めて実現可能だったりする。つまり、問題が発生した際、きちんと責任を持って解決してくれる主体が存在することが非常に重要ということである。

※Cordaにはオープンソース版とエンタープライズ版があり、後者は前者よりも非機能要件(上記で記したサポート体制等)が充実している。

エコシステム維持管理コスト

ブロックチェーン技術を活用したアプリケーションには、当然だが維持コストがかかる。その中でも考慮しなければならないのがトランザクションの処理費用だ。トランザクションを処理してもらうためには、処理費用を支払う必要があり、特にパブリックチェーンのケースにおいてはその費用はネイティブトークンの価値やネットワークの処理能力によって変わる。

簡単なシミュレーションをしてみよう。

ある基盤上で爆発に人気が出た一つのアプリがあるとする。このアプリによって多くのトランザクションが発生し、ブロックチェーン基盤の処理能力のキャパシティーを超えたため、トランザクションが詰まるようになったとする。この場合、トランザクション処理に払う手数料は、トランザクションの詰まり具合に比例して高くなる。また、ネイティブトークンの価格が上昇すれば、トランザクションの処理費用も追随して高くなることもある。

上記の例が意味することは、エンタープライズ企業がエコシステムの維持管理コストを予測できないし、コントロールすることもできないということである。つまり、企業はエコシステムの維持管理コストの予算をなかなか立てられないということであり、常に経費として計上していかなければならないということである。

現状、パブリックチェーンの場合ではどうしてもトランザクションの処理手数料は不安定であり、その手数料はネイティブトークンの価格変動に伴ったりする。一方、エンタープライズ企業にとって、ビジネスプラン上のコスト計算が容易になるプライベートブロックチェーンの方が、導入のハードルは大きく下がる。Cordaがまさにその一例である。

スマートコントラクトのアップグレード

新しいバグやセキュリティの問題が発見されれば、スマートコントラクトのアップグレードが必要になってくる時がある。しかし、ブロックチェーンでスマートコントラクトをアップグレードするのは簡単なことではない。

ブロックチェーン上に記録して改ざんできないようにしたいのに、コントラクトのロジックが頻繁に変更すると、ブロックチェーンを使う意味が薄れる。そのため、一般的にパブリックブロックチェーンや、パブリックブロックチェーン譲りのスマートコントラクト基盤を持つブロックチェーン基盤は、アップグレードすることは難しく、実用レベルにはならない。

Cordaでは個別のノード管理者にアプリアップグレードに関するコントローラブルな環境を与える署名制約の機能、データ構造とそのやり取りに関して、バージョン間の互換性を保証するCordaのシリアライゼーション機能を提供し、ネットワーク参加メンバーにアプリアップグレードをコントロール可能にし、場合によっては過去のバージョンを使用する事を可能にしている。

これはネットワーク参加者が一斉にアップグレードするのは現実的ではないということを理解しているからこそできる設計であり、エンタープライズ企業のレベルで使うのに欠かせない機能である。

詳細は以下の記事を確認してみるといいだろう。

Corda4の技術的特徴

FlowとContractの役割分担（Cordaのスマートコントラクト-その１）