ブロックチェーン、分散型台帳、スマートコントラクトに関する勉強会発表資料（初心者向け） Ethererum及びR3CEVのCordaを取り上げる。

1. Blockchain WG
2017/8/3
Tomokazu Hatate

2. 価値のネットワーク
• ブロックチェーン技術とは、P2Pネットワーク上において複数のノード間で同じ台
帳を共有することを実現する仕組み。
• ノード同士は互いに知り合っておく必要もなく、信頼を前提とすることなく、価値を
交換することが出来る。
• 信頼を前提としない為、価値の交換を保証する第三者機関は不要となる。
• 第三者機関が不要となる代わりに、ネットワーク全体で価値を保証する仕組み
が必要。（コンセンサスアルゴリズム）
• ブロックチェーンを使用する場合、価値を定義しその価値がどう動き、どのように
保管されるか、の観点で考える。
Don't trust. Verify.

3. Ethereum

4. Ethereum
• Ethereumとは、ブロックチェーン技術を用いた分散型台帳の一種。
• 主な特徴として、Ethereumブロックチェーン基盤上にDappsと呼ばれる分散型
アプリケーションを作成することができる。
• ブロックチェーン基盤とDappを媒介する実行プログラムをSmart Contractと呼
び、Smart Contractを介してアプリケーションからデータをブロックチェーンに記
録したり、呼び出すことができる。
• Ethereumには2タイプのアカウントがある。通常のアカウント（EOA: externally
owned accounts）とコントラクト用のアカウント（Contract Account）。
• Ethereumにおいて、暗号通貨Ether（ETH）は送金手段や売買の手段としてで
はなく、Smart Contractを実行するための燃料（gas）の位置付けとなっている。
• EtherをEthereumにおける基軸通貨としてDapps上でトークン（独自通貨）を発
行し、トークンをやり取りすることで分散型自律組織（DAO）と呼ばれる独自の
経済圏を作ることも可能。

5. Ethereum
• Ethereumブロックチェーンネットワーク構造
geth
Contract
DL
EOA
Dapp
Node 1
Node 2
Node 3
A B
C D
E
Dapp
Dapp
Ethereum Network
参考：『ブロックチェーン イーサリアムへの入り口』（Kindle版）
「図11:処理の流れ」を基に作成。

6. Smart Contract
• Smart Contract（賢い契約）とは、元々、1990年代にNick Zsaboによって提唱
された概念。（※Bitcoinよりも先に誕生している。）
• プログラミングされた契約という考え方で、Zsaboによれば自動販売機もSmart
Contractの一形態と言うことになる。
• Smart Contractの主な特徴としては、（１）仲介者を介さず直接的に契約、（２）
一定条件を満たせば契約は必ず実行、を挙げることができる。

7. EthereumにおけるSmart Contract
• Ethereumでは、Smart Contractを実装しやすいようSolidityと呼ばれるJava
Scriptライクな言語が用意されている。（※Solidity以外にもある。）
• Solidityは初心者向けにも優しい言語で、Mistと呼ばれるEthereum Projectが
提供するEthereum用Walletにも標準実装されている。
• Ethrereumでは、Smart Contractは通常の送金トランザクションと同様にマイニ
ングによってブロックチェーン上に登録され、Cotract Accountを通じて呼び出す
形となる。
• Smart Contractのブロックチェーンへの登録時及び実行時には一定量のgasを
手数料としてマイナーに支払う必要がある。（※プログラム暴走や悪意ある攻撃
への対策としての効果もある。）

8. Smart Contract実装例
• お試しに触る場合、Ethereum公式によるBrowser-Solidityを使用すると良い。
• Browser-Solidity : https://remix.ethereum.org/
• デプロイまでの基本的な流れ： http://qiita.com/tomohata/items/27d3cf2f5400ebab6f51
• 実装例：寄付の自動化： http://qiita.com/tomohata/items/637e5b8715e217796d3b

9. バグ
• 現状、Ethereum上で実際に作成されているSmart Contractにはバグが多い。
• 前提としてプログラムにバグは付き物。
• 如何に致命的なバグのないSmart Contractを作成するかが重要。

10. Corda

11. Corda
• CordaとはR3CEVにより提案されているDLT（分散型台帳技術）基盤。
• 金融を中心としたDLTプラットフォーム構築を目指し、R3CEVの開発者も金融
機関のシステム部門出身者が多い。（金融分野以外も対応可能。）
• Cordaネットワーク上にCorDappと呼ばれる分散型アプリケーションを通じて各
種金融取引を実現可能とする。
• ブロックチェーンではなく、各々の取引記録はネットワーク全体にブロードキャス
トされず、一部のノード同士のみで共有する。従って、秘匿性が保証されている。
• 各ノードが保有する台帳はそれぞれ異なっている。
• "Code is not law"、すなわちCordaにおいては、Ethereumで言うところの
Smart Contractは実質的には存在せず、補完的な役割を果たすに過ぎない。
※CorDappを作成するチュートリアルをR3CEVが公開しているので、
試しに検証しながら学んでみるのが一番。
＜チュートリアルをまとめているので、以下参考。＞
http://qiita.com/tomohata/items/8dec420744c72b029425

12. 分散型データベース ≠ DLT

13. 分散型データベース
出典：「分散データベースと分散台帳」（Corda.net、2016年）
• 単一のエンティティ内で複数ノードが合意形成して一意のデータべースを共有。
• 単一のエンティティによって運営されるものである以上、中央管理者が必要となる。
• また、エンティティ内で動作する為、ノード同士による互いの信頼が前提とされる。

14. DLT（分散型台帳）
出典：「分散データベースと分散台帳」（Corda.net、2016年）
Cordaの定義では、
• 互いに信頼することなく、共有レコードを他ノードと共に維持することを可能にする。
• ノードは異なる組織により運営され、また互いに信頼できない。
• 従って、受け取ったデータを個別に検証し、公開して良い範囲内でデータを共有する。

15. Corda ≠ ブロックチェーン
• 一意の台帳を共有することなく、取引をするノード間のみで個々のデータを共有。
出典：Corda Keyconsepts - The ledger ( https://docs.corda.net/key-concepts-ledger.html )

16. Corda 3つの特徴
出典：Corda Keyconsepts ( https://docs.corda.net/key-concepts.html )
Cordaでは以下3点の技術要素を抑えておくことが重要。
• State
• Contract
• Flow
※何れもCorDapp作成時に要件に合わせてコーディングする。

17. State
• Stateは状態を示すものでState自身は更新されない。
• 現在のStateは過去のStateをインプットとし、次のStateへのアウトプットとなる。
• 一連のStateは繋がっており、未使用Stateと共にVaultという領域に格納される。
• Stateには、Contract、関与ノード情報、金額等の遷移情報が格納されている。
出典： Corda -Keyconcepts - State ( https://docs.corda.net/key-concepts-states.html )

18. Contract
• ContractはCordaではSmart Contractのことではない。
• Stateが遷移する際にTransactionが生成されるが、それを検証する機能の位置づけ。
出典： Corda -Keyconcepts - Contract ( https://docs.corda.net/key-concepts-contracts.html)

19. Flow
• Flowはノード同士のやり取り制御する機能を担う。
• Cordaでは、P2Pネットワーク上にTransactionがブロードキャストしない為、Flow
を利用してコミット（台帳を更新）までのルートを定義する。
出典： Corda -Keyconcepts - Contract ( https://docs.corda.net/key-concepts-contracts.html)

20. 終わりに

21. ブロックチェーンが必要とされる場面
（例）
• デジタル化できる資産である。
• 互いに信頼できないエンティティが複数存在している。
• 各エンティティは別リージョン内で活動している。
• 各エンティティは一意のデータを共有する必要がある。
• データは改竄されてはならない。
• データに対するトレーサビリティが必要である。
• どういうケースでブロックチェーン基盤が使用されるか想定することで、ブロック
チェーンが真に必要とされるユースケースをより効果的に考えていくことができ
る。