CordaのFlowとは?概要や目的を説明

CordaのFlowとは?概要や目的を説明

はじめに

CordaではFlowという概念が登場するのですが、他のブロックチェーンでは出てこない概念なので少し理解しづらい部分があります。

何故Flowが必要なのか、Flowはどのようなプロセスでデプロイ・実行されるのか、ContractとFlowの違いなど概要を説明していきます。

公式の説明を読みたい方は以下の動画を参考にするとよいです。
Key Concepts 8 – Flows

CordaのFlowとは

Flowは契約の提案⇒契約内容の精査⇒契約への合意⇒契約への署名といった現実の契約の一連の流れをプログラム化して自動化するための仕組みです。

何故CordaではFlowが必要なのか

CordaはEthereumなどと契約をどのような構造で扱うかの考え方が異なっており、Cordaの方がより現実世界のモデルを反映したものになっています。

おおまかにはEthereumのなどのスマートコントラクトは、コントラクトが作成されたタイミングで全てのルールが確定されており、ルールの中であれば全ての契約が自動で締結されるという考え方をとっていると言えます。

一方Cordaでは、コントラクトの内容を定義する時に決めるルールの他に、契約の締結タイミング毎にもお互いの承認を必要とします。

例えば債権の売買契約をEthereumで扱う場合、事前に債権を売買できる金額や数量などの全てのルールが定義され、最初に決められたルールに従う限り自動で債権が売買され、事後的に何らかの理由で債権の販売を拒否するといったことができません。

一方でこれがCordaの場合、事前に決められるのは債権と現金を売買できるというところだけで、実際にいくらで売買されるか、売買を拒否できるかといったことは契約毎に交渉して判断するという考え方をモデルにしています。

そして、この契約の交渉プロセスを自動化するためにFlowが必要になってきます。

以下、もう少し具体的にFlowの動きを確認していきましょう。

Flowが自動化するプロセス

以下のGif動画と図はAliceとBobによる台帳更新手順のイメージを表したものです。

https://docs.corda.net/docs/corda-os/4.5/key-concepts-flows.html
flow sequence
https://docs.corda.net/docs/corda-os/4.5/key-concepts-flows.html



上の図では省略されている部分もありますが、以下のような手順で台帳が更新されます。

  1. Aliceが契約を提案する
  2. Aliceが署名し、Bobに署名をするようにリクエストする。
  3. Bobは契約内容が妥当か確認する。
  4. Bobは内容が妥当だと確認したら署名を記述しAliceにレスポンスを返す。
  5. Aliceは受け取ったレスポンスでBob署名を確認できたらNotaryに署名をリクエストする。
  6. Notaryは署名し、Aliceにレスポンスを返す。
  7. AliceはNotaryの署名を確認したら自身の台帳を更新する。
  8. AliceはBobに再度Notaryの署名付きデータを送信する。
  9. BobはNotaryの署名を確認し、自身のデータを更新する。

これらの手順を毎回マニュアルで指定するのではなく自動化するためにあるのがFlowです。

Flowを構築する流れ

契約には契約の提案側と、契約の提案を受けて合意の判断をする側が存在します。Flowには契約の提案側のプロセスを表すInitiator Flowと、契約の提案を受ける側のResponder Flowが存在します。

契約の提案側はInitiator Flowを自分のNodeにデプロイします。契約を受け入れる側はInitiator Flowのコードをを契約の提案側から共有してもらった上で、契約の受け入れ条件を設定したResponder Flowを作り自分のNodeにデプロイします。

これで両者間でのビジネスフローの準備が整います。以後、契約の提案側はInitiator Flowを起動することで契約を相手方に打診し、契約内容がResponder Flowで定められていた条件に適合する場合には自動で契約が合意され、両者の共有台帳が更新されます。

FlowとContractの役割の違い

Flowは契約を検証するプロセスを自動化すると説明しました。しかし、契約ロジックを検証するのはFlowだけでなくContractも契約ロジックを検証します。

両者にはいくつか違いがあります。

Contractは契約の当事者に依存しない検証を実行し、Flowは当事者毎に異なった検証を行う

Contractは契約の当事者に依存しない検証を行います。例えばりんごの販売などで、在庫の数以上の販売を行えないなどが当事者に依存しないルールです。

このようなルールはContractに含まれます。しかし、りんご100個を10000円で購入したいという契約の提案をしたいとき、11000円以上じゃないと受け入れたくないなどの判断をするのは当事者に依存したロジックです。

このような契約の関係者毎に異なるロジックはFlowに含まれます。

このような目的の差異の背後にある技術的な差異として、Flowと違いContractが検証するロジックは非決定性のあるデータを含むことができません。
つまり、どの当事者が実行しても結果が変わらない検証内容がContractに含まれることになります。

まとめ

今回はCordaのFlowについて概要を紹介しました。当メディアでは、CordaのFlowを含め、CorDappを作成する手順についても紹介しています。

以下の記事では、KotlinのCorDappテンプレートを利用したIOUコントラクト(借用コントラクト)を実装していますので、興味のある方はぜひご覧ください。

Flowのコードレベルでの詳細はこちらのリンクから

参考

Flows
API:Flows

製造業におけるブロックチェーン活用方法とは?

CTA-IMAGE 【ホワイトペーパー】製造業における業務変革をテーマに、業界の課題に対してブロックチェーンを活用する方法を紹介します。

ブロックチェーンカテゴリの最新記事