この記事で学べること

Corda 5におけるAPIのモジュール化の意味を理解する

目次

• はじめに
• APIをモジュール化する理由
• 新しいAPIを構築したモチベーション
• （階層化されたAPIの）構成要素
• 関心の分離
• まとめ

はじめに

前回まで、（1回目、2回目）：Corda5の概要、（3回目）：アーキテクチャの紹介を行なってきました。４回目の今日はAPIのご紹介になります。Corda5が提供する新しいAPIは、インターフェースベースになり、実装毎に別パッケージで提供されることになります。

Corda 5 Developer Previewは、アルファリリースとも言えるもので、新しいモジュール式のAPI群を評価し、それが開発速度にどのような影響を与えるか確認することができます。この記事では、APIのモジュール化が開発者にとってどのような意味を持つのかを深く掘り下げ、その背景にある私たちの動機を説明します。

APIをモジュール化する理由

新しいAPIは、以下のような利点があります。

• 開発時間の短縮新しいAPIは、CorDappのテスト性を向上させます。開発者は、モックを活用することでワークフローの機能をテストしたり、Flowのビジネスロジックだけを分離してテストできるようになります。実際にDeveloper Previewで作成した太陽系デモCorDappで作った単体テストケースをご覧ください。
• 独自の台帳モデルを構築可能ご存知の通り、Cordaは、Corda独自のトランザクションモデル（UTXOと、DB、スマートコントラクト、Notaryを組み合わせた独自のアトミック性確保）を使用しています。しかし、新しいAPIによって、開発者がデータモデルの各要素に対して独自のソリューションを提供できるようになります。例えば、Flowを使用しつつも、UTXOではなくて他のデータモデルでデータを保存することができるようになります。
• R3の生産性向上これは内部的な利点ですが、APIのメンテナンス性が向上し、エンジニアリングチームがバグをより早く修正できるようになります。現在、ベースモジュールが緊密に結合しているため、1つの変更が波及的に変化してしまうことがあります。しかし、モジュラー化したAPIでは、コンポーネントが分離されており、エンジニアリングチームはAPIを容易に維持管理できるようになります。

新しいAPIを構築したモチベーション

Cordaは、トランザクションのファイナリティを保証し、プライバシー機能を組み込んだ許可型分散台帳（Permissioned DLT）です。

しかし、Cordaにこれらの機能を支えるアーキテクチャの各階層は、それぞれ単独で幅広い応用が可能だと考えています。各層を独立して使用できるようにすると、例えば

・ネットワークの参加者との安全なコミュニケーションを自動化する。

・組織を跨いだワークフロープロセスを構築する。

といった能力を得ることができます。これらの機能は、それだけで強力なものです。

昨年、R3は、お客様がより早く市場に参入できるようにする方法を探すべく、Cordaコミニュティに対して、Cordaをどのように使用しているかを評価する調査を行いました。「Project Layer Cake」と呼ばれたこのプロジェクトの結果をうけ、R3はCordaのAPIを階層上に再定義することにしました。Project Layer Cakeは、CordaのAPIをモジュール化し、より多くの価値を引き出すための重要な原動力となりました。

次回の記事では、Project Layer Cakeについて、ユースケースや一般的な開発パターンをご紹介しますのでお楽しみに。

（階層化されたAPIの）構成要素

Project Layer Cakeにより、CordaのAPIを4つの論理的なレイヤーに分割しました。

各レイヤーがCordaのコアバリューを表しています。開発者は、ユースケースに応じてどのコンポーネントを必要としているのか、また、各レイヤーがどんな機能を提供してくれるのかを明確にしたことで、開発者がどのレイヤーを最初に深く掘り下げればよいのかを識別できるようになりました。

・(P2P Network) ネットワークデータや資産（トークン）がCordaネットワーク内を安全に移動し、参加者と通信できるようにします。このレイヤーはアイデンティティスタックの基盤であり、よく知られたアイデンティティ証明書を使って、当事者を確実に表現することができます。ネットワークについての詳細は、次回のブログ記事で紹介します。

・（Flow）フロー

FLowはビジネスプロセスを自動化するもので、データやタスクが一連の手続き上のルールに基づいて相互に調整され、実行されます。Flowを用いれば、一つのサーバ上で複数のワークフローを同時多発的（concurrently）に、かつ確実に実行することができます。

・（Ledger）台帳

トランザクションを介して各社にコミットされたStateを同期及び保存する機能です。台帳層は、データの一貫性を提供し、Cordaの「What you see is what I see」（WYSIWIS）を保証します。

・（Contract）コントラクト

Stateを作成/更新する際に、どのノードにおいても一貫して適用されなければならないビジネスロジックを定義する機能です。Stateは、UTXOモデルを使用しています。Contract層によって、すべての参加者による確認なしに将来のStateに対する制約をかけることができます。

関心の分離

上図は、Corda 5での新しいAPIの相互関係を示しています。

もしかすると、ある組織内のワークフロー（同じ会社の部署間でのワークフロー）のためのワークフローエンジンを構築することはできるかもしれません。が、このようなタイプのユースケースではCordaの価値はほとんどありません。ワークフロー層は、P2Pネットワーク層と一緒に使用される可能性が高いです。この２階層を使うことで、ネットワーク内の当事者と安全にやり取りできるようになります。

さまざまなユースケースに対するパターンに対しては、次のブログ記事で詳しく説明しますので、ベースレイヤーとしてお考えください。

現在、すべてのCordaのStateはコントラクトに依存しており、コントラクト層は通常、Cordaの台帳にStateを保存する前の検証として使用されます。

しかし、新しいAPIでは、コントラクトを必要としない独自の台帳層を実装することができます。これは、R3としてかなり期待している機能です。この独自実装を前提とした台帳は、Cordaを高可用システムに適したものにするためのアーキテクチャの変更（Kafka利用）が完了した時点で導入したいと考えています（詳細は前のブログをご覧ください）。Corda5においてこの機能を実現するために、台帳層のAPIを大きく書き換えることになります。この独自実装可能な台帳というアプローチを活用するために、Corda 5シリーズでは、新しいステートタイプ「Consensual States」が導入される予定です。当事者間で交渉したり、合意を進化させたりするシナリオでは、コントラクトの検証やバックチェーンの検証は必ずしも必要ではありません。Corda 5で導入されるこのConsensual Statesについての記事も近日公開予定です。

まとめ

R3は、Corda開発者の希望に沿ったCorDappを構築できるようにしたいと考えており、新しいAPIはそのための重要な役割を果たします。また、開発速度を速めるために、デザイン思考のコンテンツやベストデザインプラクティスのデザインマトリクスをリリースすることを目指しています。

モジュール化されたAPIは、プラットフォームのテスト性を向上させ、開発者がより効率よくCorDappを構築できるようにします。

APIの変更は、Cordaをネットワーク、Flow、台帳、Contractといった個別に価値を持つ階層構造であると再定義したProject Layer Cakeが動機となっています。Cordaを階層構造で考えることで、開発者はCordaのどの機能が必要か容易に理解することができます。

組織、特にスタートアップ企業は、将来のことをあまり心配せずに、素早く簡単に何かを作りたいと思っています。ユースケースによっては、Cordaの一つのレイヤーしか必要ないかもしれません。あるいは、MVP(ミニマムビアブルプロダクト）の場合には全てを必要としないかもしれません。

こうした柔軟性を持つプラットフォームであれば、開発者は将来に向けて段階的に開発を進めることができます。

翻って、最初のブログ記事では、漸進的分散化について述べました。今回紹介した階層化は漸進的開発を可能にし、開発者はソリューションをシンプルにして、より速いスピードで構築することができます。

✍️

Translated by 生永 雄輔 (Yusuke Ikunaga)

SBI R3 Japan エンジニアリング部長

書籍出してます：https://amzn.asia/d/c0V31Vd　

趣味：サッカー、ガンプラ、ドライブ、キャンプ

→筆者の記事一覧