Layer Cakeプロジェクトの実装と歴史、CorDappデザインへの影響、そして独立した層を使ったユースケース構築について説明
ご挨拶と自己紹介
昨年12月からSBI R3 Japan株式会社にインターンでお邪魔しております大学3年の井本翔太と申します。昨年からブロックチェーンに興味を持ち始め、その仕組みや活用方法を学ぶ過程でCordaと出会いました。私にとってCordaは社会にブロックチェーンという存在を浸透させる上で大きな役割を果たすと考えております。現在は、エンジニア業務や記事の翻訳、報告会の準備などありがたいことに様々な業務を担当させていただいております。貴重な経験の中で多くの学びを得る機会があり、学生としても社会人としても日々精進しております。
はじめに
ようこそ。前回の記事では、新しいCorda 5のAPIがCorDappの開発にどのような影響を与えるかについて、時間をかけて説明しました。Developer Previewでは、複数の新しいインターフェースベースのモジュラーAPIをリリースしました。この複数のモジュラーAPIにより、効果的にビルドとテストが可能となり、より速く開発することができます。そして、APIをモジュール化し、Cordaをネットワーク層、ワークフロー層、台帳層、 コントラクト層という層に分けるLayer Cake projectについて簡単に触れました。
それでは、Cordaではどのような価値を提供できるのでしょうか？Corda は以下の事が可能です。
- 信頼できる参加者のネットワークを形成し、参加者間で情報を受け渡す。
- 複雑な分散ワークフローを調整する。
- ” WYSIWIS — What You See Is What I see”の保証に基づいて台帳のデータを記録し、蓄える。
- 強制力のあるルールに基づき、発行者の承認なしに価値を安全に移転する。
このブログでは、Layer Cake projectがどのように前述の複数の項目を実現するのか、またその背景にある歴史を探り、これがCorDappのデザインプロセスにとってどのような意味を持つのかをお伝えしたいと思います。また、ユーザーがこれらの独立した層を使って構築できることを想定しているいくつかのユースケースについても説明します。
オリジン・ストーリー
私たちは2020年3月、世界中がロックダウンの渦中にいる中、Cordaの有用性をめぐる疑問について調査を開始しました。Cordaをどのように説明し、開発者がこのプラットフォームを最大限に活用したアプリを設計できるように導くことができるかといった疑問に答えるために、いくつかの質問をもとに自己分析しました。入手できる限り多くのCorDappをレビューし、私たちR3の考えやそれを伝える方法を向上させるためにパターンやプラクティスを抽象化しようとしました。中でも最も重要となったのは、APIをどのように進化させるかという項目です。その項目に取り組むにあたって、以下の素朴な疑問から取り掛かりました。
この問いを指針に1ヶ月間にわたり、開発者がどのようにCordaを使用し、プラットフォームと彼らの成功にどのような関係があるのかを理解するための小規模で時間枠を定め、Layer Cake projectを実施しました。この取り組みでは、Layer Cake projectを通してビジネスパートナーや技術パートナーにCordaの概念を簡潔に理解してもらうための方法を明らかにすることを目的としました。
全ての新規のプラットフォームと同様に、その新規性ゆえに生じる複数の課題を見つけました。さほど重要ではないと思っていた事柄が、実際は非常に重要で骨格を成す部分であることが判明し、その逆もまた然りです。例を挙げるとすると、 CorDappの中には、不必要なスマートコントラクトの高度な機能を使用しているなど、CorDappの目的に対して複雑すぎるアプリケーションが存在することに気づきました。この発見はいくつかのプロジェクトを単純化させる良い機会となりました。その他のケースでは、私たち、が単に補助機能とみなす機能をアプリケーションのコアとして捉え、その機能を限界まで追求している開発者もいました。このケースは特にFlowのフレームワークで見られ、アプリの根幹を成す部分でした。これらの問題は、私たちが製品の説明やドキュメントの中で言及しなかった事に原因があるのでしょか？また、低水準の開発実体を高水準に昇華させる責任があるということでしょうか？
私たちは今後の優先順位を決定するために、仕様パターンの新たな理解を廃止し、プラットフォームでの開発者のエクスペリエンスを向上させる方法を取りました。その結果、Layer Cake projectを用いて、Cordaの全ての機能が一連の細分化されたコンポーネントにグループ化されました。Layer Cake projectの取り組みの中で、これらのコンポーネントはネットワーク層、ワークフロー層、台帳層、コントラクト層と個々の1つの層として表すことが可能だと判明しました。これらの階層化はあくまでイメージです。
開発促進となる要素
ここで前回の記事からの引用を振り返りたいと思います。
“原文: Organisations, especially start-ups, want to build something quickly and easily without having to worry too far about the future.”
“訳: スタートアップのような組織は将来性についてあまり心配することなく、素早く簡単に何かを作りたいと考えている。”
この言葉の意味を紐解いていてみましょう。デモを主要ステークホルダーに行う場合、時間は非常に限られており、デモを行うことはビジネスの持続性には必要不可欠です。デモは、審査から資金調達、さらにその先まで組織にとって重要なさまざまな初期段階の成果の成功に貢献します。特に既存の価値あるネットワークの信頼モデルを再構築しようとする場合や、前例にない根本的に新しいものを見せようとする場合は、迅速に開発し、フィードバックを得ることが重要です。
私たちは初期開発段階においては、Cordaがどのようにお客様のユースケースを手助けできるのか可能な限り早く調査することが重要であると考えています。時間をかけてビジネスロジックをすべて組み込んだ本格的な分散型ソリューションが完成した頃には、市場のニーズを把握するのに手遅れとなっている可能性があります。R3では、お客様が迅速に開発を進め、後に将来のロードマップに取り組めるようにしたいと考えています。Layer Cake projectから得た重要な発見の１つは、アプリケーションは複数の層に分けて構築できるということです。特にテストで扱うような数日間で完成する製品の場合、単純な階層化で十分でしょう。階層で考え、アプリケーションを構築することで開発速度を維持しながら、柔軟な設計が可能となります。
以下ではCordaの各層が何を表しているか簡単にまとめてみました。
- (P2P)ネットワーク層 — 安全なネットワークとノード間の対等な関係、場所を問わないメッセージング、強力な暗号鍵
- ワークフロー層 — データに依存しない、当事者間でアクションを調整する分散型アプリのAPI
- 台帳層 — 当事者間の信頼性の高いデータ合意
- コントラクト層 — ビジネスロジックを非中央集権的に実行し、デジタルbearerトークンのような概念を実現可能
Layer Cake projectのアプローチは、様々なユースケースを懐疑的または批判的な視点から考えることを可能にします。ビジネスニーズを解決するために、Cordaが提供するサポートの全てを使用したいと考える方もいらっしゃると思います。しかし、必要最低限の機能も持つアプリケーションであれば、Layer Cakeの考えを用いれば十分でしょう。
ガイディングクエスチョン
ここまで、Cordaをどのように活用できるかを判断するためのモデルであるLayer Cakeを提案させていただきました。 このモデルは、実際のアプリケーションで考慮すべき全ての項目を考慮したものではありませんが、特定の問題を解決するために必要なプラットフォーム層を決定するための良い判断材料と考えます。
Layer Cakeでは3つの簡単な質問を通して、どの階層に割り当てるか判断しています。
- 多くのノードオペレーターが関与するのか？
- CordaはSoR(System of Record)となるのか？
- Cordaは更新を自動化するか、またstateを進化させるか？
これらの質問は順番通りに行われる必要があり、質問に対し「はい」と答える度に、プラットフォームの機能が追加されます。Layer Cakeは、必要な時に必要なだけ機能と複雑なアーキテクチャーを導入する考え方です。この3つの質問を用いることで、複雑さを最小限に抑え、徐々に機能を付け足すことで、ソリューションに最適なソフトウェアパターンを開発することができます。
ユースケース
私たちが行った自己分析の中で見つけたもう1つの重要な発見は、多くのお客様がCorDappの開発時に、ほぼ全てのCordaのすべての機能を使用しているという事です。場合によっては、アプリケーションを複雑にしてしまっています。中にはブロックチェーンを使ったアプリケーションであることを宣伝するために全ての機能を使用している場合もありますが、主に私たちR3のプラットフォームの説明の不十分さやAPIの作り方に原因があると考えられます。実際、私たちの全てのサンプルアプリケーションは、ほぼ全ての機能を活用する形で動作していました。これらの事から、各層が何のためにあり、いつ使うべきかをよりに伝える必要があると結論付けました。
Cordaの階層化がどのようなユースケースを実現する可能性があるのか、先ほどのガイディングクエスチョンを検討した上で、簡単に見てみましょう。サンプルアプリを自分で動かしてみて、階層化されたCordaアプリで何ができるのか見てみるのはいかがでしょうか？
Flowとネットワーク
データを2つ以上の組織間で共有する場合、データは複数の組織間にまたがるため、セキュリティ、プライバシー、信頼性について考慮する必要があります。Cordaのネットワーク層はこれらの懸念を解決します。ネットワーク層とワークフロー層は、信頼が担保されていない当事者間で処理を行うことができ、実世界のアイデンティティを確実に確保します。これにより、組織はデータをシームレスに取引することができます。
/w=1080,quality=90,fit=scale-down)
Flowとネットワークの機能を紹介するために、私たちは簡単なソーラーシステムのデモを設計しました。このシミュレーションでは、惑星のソーラーシステム間の通信を試みています。
↑このデモをKotlinやJavaで試してみてください。
Flow、ネットワーク、共有された台帳(合意状態)のCorDapp
複数の当事者が記録を共有し、コンセンサスを維持したい場合、従来のトランザクション機能の一部が必要となることがあります。Consensual Statesは、私たちが実装したpluggableな台帳モデルで、詳細は前回のブログをご覧ください。
/w=1080,quality=90,fit=scale-down)
Flow、ネットワーク、台帳、コントラクトのCorDapp
Corda本来のメッセージや価値はCorda 5でも引き続きご利用いただけます。プライバシー保証は依然としてstateのライフサイクルを制御することができ、信頼できないエンティティ間で交互に行われる承認の連鎖を規制できます。
/w=1080,quality=90,fit=scale-down)
Cordaの全機能を紹介するために、ソーラーシステムのデモを進化させ、スマートコントラクト機能を追加しました。今回はコントラクトを使って、冥王星を除く惑星のみに通信を制限しています。
↑このデモをKotlinやJavaで試してみてください。
まとめ
Cordaが提供する幅広い機能についてご理解いただけたと思います。Corda 5で導入されたモジュラーAPIは、ビジネスニーズに合わせて利用でき、階層化という視点でCorDappを考えることができます。Cordaはもはや単なる許可型分散台帳プラットフォームではありません。このことを念頭に置いて構築と運用を行うことが、ビジネスロジックを円滑に行うために非常に重要となります。Cordaは許可型の分散型ソリューションを実装するための包括的なフレームワークを提供するために設計・構築されていますが、トランザクションのファイナリティとプライバシー機能を備えているため、ビジネスアプリケーションに利用しやすくなっています。しかし、Cordaの機能を実現する階層化は、より広い範囲で適用可能です。特に、信頼性の高いメッセージング、ベースとなるワークフロー層、分散処理ロジックの統合機能は、それ自体が非常に強力です。
私たちはCordaをその機能層とそれぞれが提供する機能という観点から説明したいと思います。その一部は今後数ヶ月間、私たちの公式ドキュメントサイトやCorda 5シリーズで見ることができるでしょう。Layer Cake projectは「開発促進となる要素」で述べた通り、柔軟性を持つため少ない層で構成することは勿論、さらに多くの層で構成することが可能です。Corda 5の次のリリースに向けて努力を続けながら、このトピックに関する最新情報をお伝えしていきたいと思います。
謝辞: Layer Cake projectは当初R3貢献者のMatthew Nesbit、Mark Oldfield、Richard Brown、Roger Willisから成る小さなコアチームから構成されていました。このブログでは、その内容を抜粋してご紹介しました。
＜ご質問・ご要望の例＞
- Corda Portalの記事について質問したい
- ブロックチェーンを活用した新規事業を相談したい
- 企業でのブロックチェーン活用方法を教えて欲しい 等々
SBI R3 Japanインターン エンジニアリング部所属
Corda 5の技術検証や記事翻訳など多岐に渡ります
趣味：英語学習（まだまだですが…）・テニス・映画鑑賞