Corda勉強資料 その1 概要編

この資料はゼタント社内の勉強資料ですが、speaker deckでも公開します。
内容の正確性を完璧には保証はできませんのでご承知おきください。
誤り等を見つけた方はご連絡いただければ幸いです。

Transcript

1. 1 Corda勉強資料 その１︓概要編 Jul 2020 株式会社ゼタント @tkzettant
2. この資料について • この資料はゼタント社内の勉強資料です • ですが、speaker deckでも公開します • 内容の正確性を完璧には保証はできませんのでご承知おきください • 誤り等を⾒つけた⽅はご連絡いただければ幸いです • 資料内には私の主観が混じることがありますが、そういう部分はなるべく 独⽴したスライドにするようにします • 分散台帳（DLT）やブロックチェーンといった⽤語がありますが、明確な 定義があるようでないので、本書ではすべてDLTに統⼀します 2
3. DLTと流⾏ ブームと現実 • DLTやブロックチェーン技術は⼀世を⾵靡した（今もしている︖） • 「とにかくブロックチェーンだ︕」的な • 現実にはなかなか思ったように実⽤できず、ハイプサイクルの幻滅期に⼊った • そんな中、⾦融系や物流（トレーサビリティ）は着々と検討、実証実験、サー ビス化が進みつつある 技術が流⾏る理由 • ⾯⽩い、みんなが注⽬している → これだけだと、そのうち廃れてしまう • 本当に困っていた問題が解決できる • 実は⾒えていなかった問題を解決できる 3 この要素はあるのか︖
4. DLTとDX DLTは価値交換の基盤技術として注⽬を集めている • 価値を保存し、流通できるようにしたい • ⾃動的に価値交換契約を執⾏したい その前提としてデジタル化およびDX (Digital transformation)がある • 効率化されていなかった紙ベースの仕組みをシステム化する • 企業や業界をまたぐような協調作業・ビジネスを可能にする DLTが必要なのか、デジタル化やDXを実現したいだけなのか⾒極めが重要 • そうしないと、むやみに難しい、コスト⾼、オーバーキルなシステムを作るこ とになってしまう 4 でもごちゃ混ぜにして考 えると⽬的を⾒失うかも
5. Cordaとは オープンソースのDLTプラットフォーム 特徴 • ⽶国の複数の銀⾏によって設⽴されたR3社が開発を主導 • 企業間取引を想定したエンタープライズ向けのプラットフォーム • 予め承認された参加者のみで形成するコンソーシアム型DLT • オープンソース版と有償のエンタープライズ版がある • 基本的な機能は同じで、⾮機能要件が異なる（マルチコアによるフローの実⾏など） • 開発⾔語はJava/Kotlin Webサイト • 本家URL: https://www.corda.net • ドキュメント: https://docs.corda.net/docs/corda-os/4.5.html 5
6. Cordaのキーコンセプト ここ（https://docs.corda.net/docs/corda-os/4.5/key-concepts.html）にまとめられている 6 Notary (サーバ) Node (サーバ) Node (サーバ) Map service (サーバ) State State State State State State State State transaction transaction State State State State このようなシステム全体のことを Networkと呼んでいる Vault (⼊れ物=DB) Contract、Flow (cordapp)を持つ Vault (⼊れ物=DB) Transactionをやり取りし てStateを更新していく仕 組みのことをLedgerと呼 んでいる Contract、Flow (cordapp)を持つ Contract、 Flow を持つ
7. Cordaのキーコンセプト • Network • システム全体を指している • State • 取り扱う資産がどのような状態であるかの記述 • Transaction • Stateをどのように変更するかの提案 • 関係者に受理されると、Stateがその提案のとおりに更新される • Contract • Transactionの有効性を検証するプログラム • Flow • ビジネスロジック（Stateを更新するために必要な⼿続き）をステップ・バイ・ス テップで実⾏する際の、その⼀連の処理およびそのプログラム 7 Notary (サーバ) Node (サーバ) Node (サーバ) Map service (サーバ) State State State State State State State State transaction transaction State State State State Vault (⼊れ物=DB) Contract、Flow (cordapp)を持つ Vault (⼊れ物=DB) Contract、Flow (cordapp)を持つ Contract、 Flow を持つ
8. Cordaのキーコンセプト • Node • アプリケーション(Cordapp)を実⾏する • CordappがFlow(前ページ参照)を実⾏する • WebサーバやRPC機能を持ち、外部からのCordap起動要請などをを受け付ける • Notary • 最新のStateだけがTransactionに利⽤されているかを確認する • 規定の時間内の取引かどうかを確認する • このような確認が取れた場合にTransactionに署名することで、取引がファイナライ ズされたとみなす • Notaryは1つのサーバだけでなく、複数のサーバでクラスタ化してもよい • Vault • Node上に実装されるStateなどの情報を格納するデータベース • State以外にも任意の情報をoff-ledger情報として保持できる • Network Map Service • ノードがどこで稼働しているかを管理する • Flowの中で通信相⼿を⾒つけるためなどに利⽤する 8 Notary (サーバ) Node (サーバ) Node (サーバ) Map service (サーバ) State State State State State State State State transaction transaction State State State State Vault (⼊れ物=DB) Contract、Flow (cordapp)を持つ Vault (⼊れ物=DB) Contract、Flow (cordapp)を持つ Contract、 Flow を持つ
9. Cordaの技術的特徴 • Transaction＝ブロック • 他の多くのブロックチェーンのようなブロックは構成しない • TransactionやStateは、必要なノードにしか配布されない • システム全体がすべて同じ情報を持とうとするブロックチェーンとは考え⽅が異なる • メリット︓プライバシとスケーラビリティが向上する • デメリット︓完全にトラストレスな状況では運⽤できない • Contractはスマートコントラクトではない • CordaのContractはトランザクションに署名が正しくついているか、⼆重消費になっ ていないかを確認する⾏為なので、検証と考えたほうがいい • Notaryはすべての情報を保つ必要はない(non-validatingの場合) • 最新のStateを含むTransactionのハッシュを記録しておくだけで、⼆重消費になっ ていないことを確認できるため • コンセンサスアルゴリズムは必ずしも必要ない • 複数のNotaryでクラスタを作りたい場合などには、⼀般的なコンセンサスアルゴリ ズムを⽤いれば良い 9
10. まとめと次回予告 DLTで⼀体何をしたいのかを⾒極めることが⼤切 • DXを実現したいだけではないのか︖ Cordaは、DLTの中では少し特殊で、ブロックもないし、必ずしもすべて のノードで情報を共有するわけでもない • 私が開発に携わったBBc-1も同じ思想（違いはまたいずれ） 他のDLTと思想が違うので⽤語の意味も異なる • ⽤語の意味をちゃんと理解すると、Cordaへの理解が深まると思われる 次回はFlowの流れ、というかトランザクションに関わる⼀連の処理につい てまとめます 10
11. 宣伝です コミュニケーションロスによる損失をなくす 11 そのために サービスやプラットフォームの開発 コンサルティングや受託開発 を提供しています ゼタントが⽬指すもの
12. こういうお役に⽴てます • システム化、デジタル化によって実現したい • しかし、まだ⾻⼦が固まっていない • 問題を洗い出したり、周辺との関連を整理しなければならない 12 新規事業 実証実験 業務フロー改⾰ ちなみに、このような状況に役⽴つツールも開発中です （いずれお披露⽬させていただきます） こういういった状況から寄り添い、分析や提案を織り交ぜ ながら、システム設計から開発までお⼿伝いできます
13. 案件例 13 トークン系のサービスを開発したい 資源、電力、物流などの トレーサビリティシステムを開発したい 双方向コミュニケーションが可能な Webアプリケーションを開発したい ID基盤を開発したい サービスを実現するためのシステムを どう作ればいいかわからない 複雑化した業務フローなどを整理して、 課題を抽出し、改善につなげたい 契約や権利を管理する サービスを開発したい インセンティブ設計およびサービス設計 要件定義、システム設計、開発 • 実証実験システムの開発、システム提案など、大 規模〜小規模まで経験のあるメンバーが在籍し ています • 通信キャリアでの経験などを活かし、多岐にわた る分野に対応できます • ブロックチェーン技術も利用できます 要件定義、システム設計、開発 各種コンサル経験あり • plugin-jmeeという技術基盤を保有しています お問い合わせ：inquiry@zettant.com
14. 14 https://www.zettant.com