Gbec finance and blockchain
1 like932 views
ブロックチェーン技術による金融システムの課題と可能性
Gbec finance and blockchain
- 9. 英国の「暗号資産」の概念 英国暗号資産タスクフォース最終報告書（2018年10⽉） l 暗号資産の３分類 ⾼橋郁夫弁護⼠（駒澤綜合法律事務所） ブログより https://itresearchart.securesite.jp/?p=1504&fbclid=IwAR1LoLyagAlvkVEJNoOLL6Ugshs UBIZDSAY_6V-sNwV7h1A5J8F90L8lfTw Her Majesty's Treasury（⼤蔵省） the Financial Conduct Authority（⾦融⾏動監視機構） the Bank of England （英国銀⾏）
- 10. EBA(欧州銀⾏協会)によるCrypto Assetの分類 2019年１⽉公開 暗号資産の３分類 ●Payment/Exchange/Currency Token Virtusl Currency Crypto Currency ●Investment Token ●Utility Token
- 11. Exchange(決済)トークン／Currencyトークン l いわゆる「仮想通貨」 security(証券)トークン／investment(投資)トークン l それ⾃体は価値をもたず、価値との交換を前提とした引換証書 utilityトークン l モノ・サービスとの交換証書、アクセス権 Crypto Asset の３分類 (英国、EBAの定義) energy token(電⼒) ParkinGO (駐⾞場)
- 12. ⽇本の改正資⾦決済法、改正⾦商法等における 「暗号資産」関連⽤語の外延 暗号資産（「仮想通貨」を単純に置換）→ 改正資⾦決済法 l Exchange(決済)トークン／Currencyトークン 電⼦記録移転権利 → 改正⾦商法 l 電⼦情報処理組織を⽤いて移転することができる財産的価値 l Securityトークン Utilityトークンは︖
- 13. Security（証券）トークン 電⼦記録移転権利 l 第⼀項有価証券（株券など）として扱われる︖ 取扱業者 l 第⼀種⾦融商品取引業者（証券会社など）︖ 合法的運⽤にはトークンにメタ情報の付与が必要 l メタ情報の標準化が必要になる l ERC1400などの標準 メタ情報 所有者情報 メタ情報 所有者情報
- 14. 分散台帳によるトークンの表現
- 15. トークンの台帳表現 実際にはトークン（コインのようなもの）は存在しない ブロックチェーン上にあるのは台帳記録 l 例︓Bitcoinの三式簿記 しかし台帳としての記述⼒には限界がある l Bitcoinの三式簿記には、現⾦勘定の記述しかできない output 仮想通貨 input 仮想通貨 現⾦勘定 トランザクション
- 16. input 債務 ブロックチェーン上の台帳表現の拡張 トークンを実現する台帳記録技術の⾼度化 l ERC20 (Etherumアセットの勘定のための標準API） l OpenAssets Protocol (Bitcoin にアセットの勘定を追加） chaintope社の inazuma （仮想通貨の）現⾦勘定＋債権／債務勘定 output 仮想通貨 output 債権 input 仮想通貨 input 債権 output 債務 トランザクション 現⾦勘定 アセット勘定 債権／債務
- 17. 総量保存則 トランザクションの正統性検証の重要項⽬ l 送⾦の前後で（貨幣的）価値の総量が変化していない l 債権／債務勘定も総量保存則が維持される input 債務 100 output 仮想通貨 output 債権 70 input 仮想通貨 input 債権 100 output 債務 50 input 債務 50 output 仮想通貨 output 債権 input 仮想通貨 input 債権 30 output 債務 input 債務 50 output 仮想通貨 output 債権 input 仮想通貨 input 債権 70 output 債務 債権 30 債務50
- 18. トークンの⽣成とメタ情報 アセット⽣成トランザクション l 通貨発⾏のためのコインベーストランザクションに類似 l input部が無くoutput部のみ l input部はメタ情報を参照し、そのメタ情報は送⾦後も伝播 トランザクション output 仮想通貨 output 債権 100 input 仮想通貨 output 債務 100 メタ情報 発⾏者 譲渡条件 精算条件 ...
- 21. DeFi (⾮集中型⾦融） トークンによる⾦融 l トラストレス l 集団投資スキーム ブロックチェーン DeFi (⾮集中型⾦融） 仮想通貨 セキュリティトークン ユーティリティトークン トークンによるインセンティブ設計
- 23. なぜトラストレスな運⽤が可能なのか︖ l 参加者がデポジットした資⾦の分配をめぐるゲームだから l 不正を⾏うとデポジットした資⾦を失う トークン l ゲームに参加し活動するために必要 プロトコル l トークンの利得をめぐる合理的⾏動 ゲーム論的プロトコルとしてのDeFi 利得⾏列ゲーム⽊ ブロックチェーン トークン
- 28. ギャンブラーの悲劇の有⽤な利⽤法 公平なゲームは所持⾦が50%より多い⽅が必ず勝つ Satoshi Nakamoto が発明した Proof of work法 l Bitcoin の健全性を望むマイナーが所持する計算量が全体の 50%以上なら、台帳記録は⼀貫性を持つようになる DeFiにはもっとクレバーなインセンティブ設計が必要
- 29. 創造的⾦融の時代とDeFi 創造的⾦融 l ⼈間だけが可能な「驚き」にもとづく投資 AIと巨⼤データセンターの時代 l 「⼈々の驚き＝エントロピー」を光速で検知 l 計算速度の優位性により利益を獲得し、リスクを撒き散らす 「⼈間による」創造的⾦融 l 光の速度を超えて「驚く」ことができる⼈間の能⼒ DeFiで⼀番最初に「驚いた」⼈が勝つゲームをつくれるか︖
- 30. 「銀⾏」の登場
- 31. 「銀⾏」と登場⼈物 「銀⾏」におけるローンの借り⼊れ l 銀⾏が借⼊⼈に融資した資⾦は消費される l 銀⾏は債権を持ち、借⼊⼈は債務を持つ l 時間の経過とともに⾦利が発⽣する 預⾦者 借⼊⼈ 「銀⾏」 ⼝座 債権 ⾦利 法定通貨 債務
- 32. 「銀⾏」による融資の台帳表現 総量保存則を維持している l 債権+債務=0 input 債務 output 通貨 100 output 債権 100 input 通貨 input 債権 output 債務-100 input 債務-100 output 通貨 output 債権 input 通貨 100 input 債権 output 債務 input 債務 output 通貨 output 債権 input 通貨 input 債権 100 output 債務 借⼊⼈ メタ情報 発⾏者 譲渡条件 精算条件 ... 債権 100 債務 -100
- 33. 通貨発⾏者としての「銀⾏」 通貨＝転々譲渡可能な債権 l 総量保存則を維持した通貨発⾏ input 債務 output 通貨 100 output 債権 100 input 通貨 input 債権 output 債務 100 input 債務 100 output 通貨 output 債権 input 通貨 100 input 債権 output 債務 input 債務 output 通貨 output 債権 input 通貨 output 債務 借⼊⼈ メタ情報 発⾏者 譲渡条件 精算条件 ... input 債権 100 銀⾏発⾏通貨
- 36. 時間の経過と債務の残⾼に応じてロック状態解除 l 債務＋債権＝０ は維持される 利息も「銀⾏」による通貨発⾏ input 債務 output 通貨 1 output 債権 1 input 通貨 input 債権 output 債務 1 output 通貨 output 債権 input 通貨 input 債権 output 債務 input 債務 output 通貨 output 債権 input 通貨 output 債務 借⼊⼈ input 債権 1 input 債務 input 通貨 input 債務 output 通貨 output 債権 1 input 通貨 input 債権 output 債務 1 input 債務 input 通貨 input 債務 output 通貨 output 債権 1 input 通貨 input 債権 output 債務 1 input 債務 1 ロック時間1年 時間軸 ロック時間2年 ロック時間3年
- 39. オッカム主義の台頭 マッキンゼーの報告書 「Blockchain's Occam problem」(2019年1⽉) l これまで数⼗億ドルの投資があったが、ブロックチェーンの実 ⽤的⽤途はまだ存在しない l 投資家の視点からは、ブロックチェーンの技術的進歩は緩慢で 幼稚な段階から抜け出せない l ブロックチェーンのPoCとして離陸したプロジェクトがDBベー スで着地する
- 40. NISTの６条件 ⽶国国⽴標準技術研究所によるブロックチェーン利⽤指針 l NISTIR 8202 Blockchain Technology Overview ６条件 l ⼀貫性の維持が必須なデータ共有が必要か︖ l 複数の主体がデータの提供者になりえるか︖ l 書き込まれた記録への修正や削除が不可能でよいか︖ l 機微な個⼈情報が記録されることがないか︖ l データ提供主体に書き込み権限を与えるために信⽤な どの管理は不要か︖ l 改ざん不可能な追跡可能な記録がどうしても必要か︖
- 41. NISTの６条件とトークン 現実資産のトークン化 l ERC-20などによるトークンで資産を管理するプロジェクト 登録情報の⼀貫性保証をどうするのか︖ （分散している）複数の主体の主張を信頼する⽅法は︖ l 例 信頼できるIoTデバイスの利⽤︖ nayutaの Lightning Shield for Arduino＋スマートメータ スマートメータトークン
- 42. 法規制 ⼯場排⽔への規制 l 被害者の救済、補償 l 科学的基準 l 信頼できる測定と評価などの法規制の運⽤ 法規制 被害者
- 43. 法規制 ⾦融サービスへの規制 l 被害者の救済、補償、利⽤者保護 l 合理的な規則と基準 l 信頼できる監査などの法規制の運⽤ 法規制 資⾦洗浄 投資被害 被害者