Recommandé
Contenu connexe
Similaire à ブロックチェーンの基礎及びNEM / Symbolブロックチェーンのご紹介
Similaire à ブロックチェーンの基礎及びNEM / Symbolブロックチェーンのご紹介 (20)
Dernier
Dernier (8)
ブロックチェーンの基礎及びNEM / Symbolブロックチェーンのご紹介
- 1. ブロックチェーンの基礎及びNEM / Symbolブロックチェーンのご紹 介 2023/01/23 11:00～11:45 NPO法人 NEM技術普及推進会 NEMTUS 松岡靖典
- 2. 自己紹介 ● 松岡靖典 ○ @salaryman_tousi ● 趣味 ○ 旅、山登り(100名山制覇してその証をブ ロックチェーンに刻みたいという野望があ る)、スキー ● 職歴 ○ ものづくりの会社: 10年 ○ Web＆ブロックチェーン開発の会社 : 2年 ○ NPO法人 NEM技術普及推進会 NEMTUS: 今 ● フロントエンド ○ TypeScript/Angular/Nuxt(Vue.js)/React ● ブロックチェーン ○ NEM/Symbol/Cosmos SDK/Ethereum
- 3. NPO法人 NEM技術普及推進会 NEMTUSについて ● 日本のコミュニティメンバーで設立 … 現在12名 ● ミッション=技術普及推進 ○ ブロックチェーンそのもの ○ NEMブロックチェーン ○ Symbolブロックチェーン(=NEMの新バージョン) ● 取組 … コミュニティイベント(大規模負荷テスト、寄付イベント、お祭り、ハッ カソン、勉強会)～開発(SDK、イベント用Webサイト、Webアプリの作成) 「ねむたす」 @NemtusOfficial
- 4. アジェンダ 1. ブロックチェーンの基礎 a. ブロックチェーンとは？ b. ブロックチェーンのデータ構造とは？ c. コンセンサスアルゴリズムとは？ d. ファイナリティとは？ 2. どのようなブロックチェーンがあるのか？ a. Bitcoin b. Ethereum c. NEM/Symbol d. Cosmos SDKやPolkadot 3. ブロックチェーンを使ったサービス利用や開 発は？ 4. NEM/Symbolブロックチェーン紹介 a. 概要 b. 技術的特徴 5. ブロックチェーンの実社会での活用にむけて a. どのような課題を解決できるか b. 活用における課題は何か 6. (時間があれば) a. NPO法人NEMTUSのこれまでの取組 の紹介 b. 今後開催予定のイベントの紹介 i. ハッカソン、お祭り
- 7. 管理主体となる個人・組織へ依存しないP2Pネットワーク ● クライアント/サーバー ○ サーバーが中央集権的にクライアント にサービスを提供 ● P2P(Peer to Peer) ○ コンピューター同士が対等に通信を行うこ とでサービスが成立 サーバー クライアント Peer(≒ノード) もしサーバーがダウンしたら ... × サービスは利用不能に ... そうならないよう管理する責務がサー ビス提供者に発生=管理主体となる個 人・組織が必要 × ノードが1台ダウンしても... それ以外のノードでサービス が成立する 管理主体となる個人・組織へ の依存なしに堅牢な仕組みを 実現可能 全体としては冗 長性が高い分 非効率だが各 ノードの負荷は 低め 全体としては効 率的だがサー バー周りの負荷 は高い 絶対的ではない トレードオフ
- 8. ブロックチェーンのデータ構造の概要と名前の由来 ● ブロック a. 一つ前のブロックハッシュ b. トランザクション c. ナンス … a, bの値と関連して 暗号学的に定められたルール を満たす必要あり d. ブロックハッシュ... cが見つ かったら算出可能＆次のブ ロックへ含まれる→連鎖的な データ Block m Tx List Tx 1 Tx n(m) ・ ・ ・ Reward Nonce Block Hash Previous Block Hash Block m+1 Tx List Tx 1 Tx n(m+1) ・ ・ ・ Reward Nonce Block Hash Previous Block Hash … … ブロック間でハッシュを連鎖的に連ねた データ構造→ブロックチェーン ネットワーク参加者 全員で競争的にこ の値を見つける 競争の勝者が報酬 をもらえる
- 9. PoW: ブロックチェーンを維持するインセンティブを生み出す競争原理 PoW (Proof of Work) … 参考記事 ● 暗号パズルの早押しクイズの勝者が 報酬を得る(とともに次のブロックをブロックチェーンに刻む権利を 獲得する) ● 暗号パズルを総当たり的に解くため のコンピューティングリソースが豊富 な参加者が有利 ● パズルの難しさが自動的に調整され ブロック生成間隔が一定に保たれる ● 正解を探すのは大変だが答えが正 解かはすぐわかる→適当に間違った 答えを送っても意味がない × × × 〇 ↑ 嘘 × × × × 検証 ↓ 不正！ ↓ 却下！ 検証 ↓ 不正！ ↓ 却下！ 検証 ↓ 正解 検証 ↓ 正解 〇 × ×
- 10. PoS: ブロックチェーンを維持するインセンティブを生み出す競争原理 PoS (Proof of Stake) ● 暗号パズルの仕組みがPoWと違う ○ 暗号パズルの答えは各ブロック毎にランダムに 決まっている (1) ○ それに対し各参加者毎に回答可能な答えもラン ダムに決まっている (2) ○ (1)の答えに対し、各参加者の回答 (2)が正解か どうかを判定する当たり判定の緩さが時間とと もに緩くなっていき (3)、一番最初に当たり判定 を得た参加者が報酬を得る ○ (3)のスピードがステーキング額が大きい参加者 程早く、当たり判定をもらいやすく有利 ○ 参加者全体のステーキング総量に応じて (3)の スピードが調整されブロック生成間隔が一定に 保たれるような仕組みになっている (1) (1) (2) (2) Hit! Stake≒残高 大きいと有利 Stake≒残高 小さいと不利 Stake 大 Stake 小
- 12. 一般的なコンセンサスアルゴリズムまとめ 1. 誰が次のブロックのデータをブロックチェーンに追加できるか a. PoW: 暗号パズルの総当たり計算の勝者がパズルの答えの証明を提示して その権利＆報酬を獲得 b. PoS: 時間とともにStake(≒保有残高)の大きなユーザーほど有利となる抽選 ゲームの勝者が結果の証明を提示してその権利＆報酬を獲得 2. ネットワーク内で異なるチェーンが存在した場合にどのチェーンを正 とするか a. 最長のチェーンを正とする※ ※ネットワーク内でどのチェーンを正とするかの決め方は他にもある 以下のようなルール (≒仕様)で非中央集権的な参加者同士で (、一時的にはネットワーク内で異なるデータが併 存する状況は許容しつつ、最終的には )同一のデータへ収束し、それを維持していくことができる
- 13. 確率的ファイナリティについて ● 最長チェーンを正とする場合、短かったチェーンは無かったこと になり、短かったチェーンに含まれていたトランザクションが無 かったことになる ● ではブロックに含まれたトランザクションが確定したとどうやって 判断すればいいか？ ● 確率的にそのブロックが覆らないであろうと十分判断できるだけ 待って確定したものと見なす 考え方=確率的ファイナリティ あるブロック(1)が生成され、その後、数ブロック新たにブロックが生成された後で、ブロック (1)のブ ロック高さのブロックが別のものに変わったチェーンが最長となる確率は、一定以上のブロック数 が生成された後には確率的に極めて低くなる ただしブロックが 覆らない可能性 を厳密にゼロに はできないことに 注意が必要 可能性低い⇒
- 14. 即時確定的ファイナリティ ● 確率的ファイナリティの弱さ ○ 取引を即座に確定と見なせないのは不便 ● 事前投票的なプロセスでブロック生成前に次のブロックをネット ワーク内で合意形成して決めておく方法 ○ ブロックを各ノードが新たに生成する前に ○ ノード間で投票のようなプロセスを行い、 ○ 次のブロックを事前にネットワーク内で合意形成してから ○ 各ノードが同じブロックを刻む ○ 刻まれたブロックは覆らず、 ○ ブロックに組み込まれると同時に即時にファイナリティを獲得 ● ただしこの方法には弱点も ○ ノード間で合意を取るプロセスで ○ 参加者数=ノード数が増えると ○ ノード間の通信量が爆発的に増加するため、 ○ ノード数を無制限に増やすことは難しい × ←こういう別 のブロックが 作られないよ うに 事前に ネット ワーク間 で合意 形成して おき→
- 15. チェックポイントによる確定的ファイナリティ(≠即時) ● 毎ブロック毎の即時ファイナリティの弱点 ○ 参加者が増えると合意形成に必要な通信量が激増 ○ 結果として毎ブロック毎の合意形成が難しい ● 毎ブロック毎でなければいけるのでは？ ○ 一定ブロック毎にチェックポイントを設け合意形成を行い ○ 合意形成取れたブロックは覆らない運用で実現 合意 形成 ↓ 確定 毎回合意形成はし んどい... 即時のファイナリ ティは得られず待 ち時間は必要 合意 形成 ↓ 確定 合意 形成 ↓ 確定 合意 形成 ↓ 確定 合意 形成 ↓ 確定 合意 形成 ↓ 確定 定められたブロック数や時間だけ間隔をあけてネットワーク間での合意形 成を行ってそこまでのブロックを確定させるのを繰り返す 確定 確定 確定 確定
- 16. ビットコイン 確率的ファイナリティ 代表例 NEM/Symbol はこれ ブロック生成 確率的 ファイナリティ Cosmos SDK製 独自ブロックチェーン等 NEM/Symbol チェックポイント 確定的ファイナリティ コンセンサスアルゴリズムとファイナリティのまとめ ● 確率的なファイナリティ ○ PoW+最長チェーン選択でのブロック生成 ■ ビットコイン ● トランザクションがブロックに組 み込まれていくつか追加ブロッ ク承認をまって決済確定と見な す場合が多い ● 確率的なもの ● 100%ではない(とはいえ無視 できるほど十分小さい) ○ PoS+最長チェーン選択でのブロック生成 ■ NEM / Symbolでは新規ブロック生成 はPoS的なメカニズム ■ PoS的なブロック生成メカニズムでも、 ビットコインと同様に確率的なファイナ リティしか得られない ● 確定的なファイナリティ ○ ある種の投票によって実現される ● 即時かつ確定的ファイナリティ ○ 概要 ■ 毎ブロック毎に投票 ■ 分散されたネットワーク間で ■ 有効な投票を集めて合意形成する ○ 合意形成できなかったら ■ 即座にチェーン止まる ○ 参加者が増えると... ■ 合意に必要なリソースが大きくなりすぎる ■ ので参加者数の上限を制限する場合が多い ● 即時ではなくかつチェックポイントを設けることで実 現した確定的ファイナリティ ○ チェックポイント経過時に確定的な投票が行われて合 意形成する ■ 見える範囲のネットワーク全体 ● NEM ■ ネットワーク全体 ● Symbol
- 17. 2. ブロックチェーンの代表例
- 18. BTC Bitcoin ビットコイン … ブロックチェーン元祖 ● ナカモトコンセンサス … 確率的ファイナリティ ○ Sybilアタック耐性としてのPoW ○ 最長チェーン選択によりネットワーク内のデータの一貫性を 保つ ● トークン残高等は、未使用のトランザクション出力 =UTXO(Unspent Transaction Output)をツリー上に束 ねた構造として扱われる ● ブロック生成間隔10分 ● 機能少なくシンプル ● 近年はライトニングネットワークを通じた待ち時間不要な 仕組みを利用したマイクロペイメントのユースケースが 広がりを見せている
- 19. ETH Ethereum イーサリアム … スマートコントラクト ● 以前PoWだったが昨年にPoSへの移行を完了 ● ビットコインのUTXOと異なりデータ構造はさらに柔軟な状態を表現で きるものとなっている ● ブロック生成間隔15秒 ● 圧倒的な自由度 ○ 開発者自身でスマートコントラクトを実装してブロックチェーンに デプロイすることで、ユーザーからのコントラクト呼び出しによっ て、ブロックチェーンのノード上で自動的に処理が実行されそ の結果をブロックチェーンの状態として保持しておくようなこと が可能 ● デプロイ済のコントラクトを変更するのは原理的に困難 / 新たな独自 実装をセキュリティ的に問題なく実装する難しさも ● 非中央集権的な領域ではDeFiのエコシステムが発展 ● それ以外の領域でもNFTの認知が高まり多くのNFT関連サービスが 生まれた ● 近年は更なる拡張性を求めLayer2, ZKP関連の取組がさかんに見え る
- 20. NEM ネム (NEMはNew Economy Movementの略) ● REST APIやWebSocket等の既存のWeb開発の延長線上 で、スマートコントラクト無しでもブロックチェーンに予め組 み込まれた様々な機能を使うことで、ブロックチェーンの特 徴を活かしたアプリ開発を開発者フレンドリーに行うことが できるというコンセプトを示したブロックチェーン ● 独自トークンの発行 ● 独自トークンへのブロックチェーン内での唯一性が担保さ れた名前の付与 ● ブロックチェーンネイティブにビルトイン済のマルチシグ機 能(複数の署名が揃ったらトランザクション実行できるアカ ウント管理機能) ● バリデーターノードの分散化だけでなく、 APIノードの分散 化にもこだわりがある ● NEMの新バージョンとして後述する Symbolが新たにロー ンチされたが、NEMブロックチェーンもSymbolブロック チェーンとは別に今も動いている
- 21. Cosmos SDK製ブロックチェーン ● 独自チェーンを作るのに便利なフレームワークの提供 ● ブロックチェーン間で柔軟かつ堅牢に各種連携 (トークンの 送受信・情報のやり取り )を行えるような規格の整備 といった点に主眼を置いて、一つのブロックチェーンだけで全てを 行うにあたっての限界を、目的ごとに独自のブロックチェーンを作 成して、それら別々のブロックチェーン間が連携することで解決を 目指す枠組みがCosmos SDK 近年、ブロックチェーン間の連携が実働開始したことで、 Cosmos SDK製ブロックチェーン間のエコシステムが大きく発展を遂げてい る 技術的な違いはあるが Astar等のPolkadot系エコシステムも近い 思想が根底にあると感じる
- 22. Symbolブロックチェーン … NEMの新バージョン ● 他チェーンがスケーラビリティや拡張性等の点で、ライトニングネッ トワークやLayer2やブロックチェーン間通信等のようにブロック チェーンの外へ活路を見出していたのに比べて、 ● ブロックチェーンのLayer1それ自身の改善に(長い時間かけて)真 正面から取組した結果生まれた新しいブロックチェーン ● NEMの哲学が引き継がれつつ ○ APIノードの分散性重視、REST API, WebSocket重視 ● 以下のような機能面も拡充され ○ 多階層で柔軟なマルチシグ構成 ○ 署名が揃うのを待って複数のトランザクションが一括実行される限 定的なスマートコントラクトのような機能 ○ 複数のブロックチェーン間でのアトミックスワップをサポートするため のHashed Time Lock Contractのサポート ● スケーラビリティの点でも改善され ○ 1ブロック60秒120トランザクション -> 1ブロック30秒6000トランザク ション ● 既存のWeb開発の延長線上でブロックチェーンを容易に組み込ん で使うことができるという点で開発者フレンドリーなバランスの良い 現実的な選択肢となりうる点が大きな特徴
- 26. 4. NEM / Symbolブロックチェーン紹介
- 27. NEM / Symbol ブロックチェーン 概要 NEM (XEM) ● 旧version(2015/03～) ● 今も動いている ● トークンを簡単に発行可能 ● 名前空間(≒ドメイン名) ● メッセージ ● マルチシグ ● 全世界分散公開REST API Symbol (XYM) ● 新version(2021/03～) ● 旧バージョンのNEMから自 由度やスケーラビリティが改 善され、トランザクションの種 類も多様化し、より柔軟な表 現力を持つ Old New Live Live
- 29. 全世界に分散化されたAPIノードを開発者が自由に使える ● 用語 ○ バリデーターノード… インセンティブ求め新ブロックを作っていく ■ 一般的にブロックチェーンネットワーク外からのアクセスは厳しく遮断して安定稼働を重視 ○ APIノード … アプリからブロックチェーンの情報を参照したりトランザクションを送信したり ■ 一般的に各アプリ開発者毎に個別の APIノードを用意し自アプリ外からのアクセスは遮断して稼働 NEM / Symbolでは... 以下の特徴があり少し事情が違う点が個性的 ● (ブロックチェーンを使ったアプリ開発に必要な)APIノードが重視された設計 ● 公開運用前提で設計・テストされたバリデーター兼APIノード ● 全世界に分散して公開されたAPIノードを開発者がそのまま自由に使用可能
- 32. スマートコントラクト無しにブロックチェーンを活用可能 スマコン関連アプリ開発の場合 1. スマートコントラクトの実装・テスト 2. スマートコントラクトのテストネットへのデプロ イ 3. テストネットのスマートコントラクトを呼び出す フロントエンドの実装・テスト 4. (主にスマートコントラクトの )セキュリティ監査 5. (主にスマートコントラクトの )監査での指摘点 を修正 6. メインネットへのスマートコントラクトデプロイ ・フロントエンドのデプロイ NEM / Symbolの場合 1. テストネットへトランザクションを送る部分は フロントエンドの実装と同じ技術ベースで可 能なため同時並行で実装・テストを行うこと になるのが自然 2. メインネットでのアプリをローンチ スマートコントラクト関連の工程と、その工程の難し さやセキュリティを担保するための監査等の工程 を省いた開発が可能というメリットがある
- 34. NEM / SymbolにおけるDApps開発 通常のアプリ開発の延 長線上で (スマートコントラクト開 発なしに) ブロックチェーン自体に 元々組み込まれた様々 なトランザクションを実 行することで 自由度はある程度制約 されるが様々な挙動を 柔軟に表現可能 アプリその1 アプリその2 ブロックチェーン ● 状態 ● 様々な トランザクショ ン チェーンの状 態を参照 トランザクション を実行 アプリ開発 デプロイ 独自言語を用 いた スマート コントラクト開 発 やらなくてOK→
- 35. いわゆるワイブロについて個人的に思うこと よく「Why blockchain ?」という問いかけがある ブロックチェーンの技術的特性が、対象としている課題解決にマッチしているか？ビジネ ス上の要件を満たすことができるか？という意味でのこの問いかけは大事だと思うが、 多くの場合、ブロックチェーンを用いることによる開発の大変さ等を警戒してこの問いか けをしていることが多いのではとも思う。しかし、この点の大変さは、Symbolブロック チェーンのような技術的選択肢の場合、ほとんどないといっても過言ではないのではな いか... と最近感じるようになった。 ブロックチェーンの「透明性」「過去データを書き換えられない」という証明能力の強さが 上手くはまる案件においては、むしろ逆に「Why not blockchain?」という問いかけを発し ても良いのではないか...
- 36. Tx.1 モザイク(≒トークン)発行 NEM / Symbolではトークンのことをモザイクと呼ぶ (モザイクアートみたいなものをイメージしているのかな？という所感 ) 特徴的な機能 ● コントラクト無しにパラメーター指定してトランザクション送信することでトークン 発行可能 ● 徴収(Levy) … ロイヤリティや税金自動徴収的なイメージ ● 期限 … NEM: 1年固定、Symbol: 1日～10年 or 無期限と選択可能 ● 転送可否(Transferable) … 転送不可だとSBTのような構想に応用可能 ● 取消可否(Revokable)≒没収可否 … 中央集権的管理を可能にもできる
- 37. Tx.2 転送トランザクション シンプルな、トークンやメッセージの送信 特徴的な機能 ● メッセージ無し ● 平文メッセージ付き ○ ブロックチェーンに情報を刻むシンプルな方法 ● 暗号化メッセージ付き ○ 以下いずれかで復号可能な暗号化メッセージをブロックチェーンに刻むことができる ■ 送信者: 送信者の秘密鍵 + 受信者の公開鍵の組合せで復号可能 ■ 受信者: 受信者の秘密鍵 + 送信者の公開鍵の組合せで復号可能
- 38. Tx.3 マルチシグ 複数の署名が揃って初めてトランザクションが実行されるアカウントをマルチシグア カウントと呼ぶ マルチシグアカウントの作成、連署者の追加、連署者の削除等が可能 マルチシグアカウントからのトランザクション送信は後述するアグリゲートトランザク ションを利用する ● 単階層(2階層のみの)マルチシグ化 ● マルチレベル(3階層まで)のマルチシグ化 ● 連署者の追加、削除等に必要な署名数を柔軟に設定可能 〇〇社マルチシグ単階層 N**** 社長 N**** 部長 N**** 社員 N**** 社長 N**** 部長 N**** 社員 N**** 社員 N**** △△部マルチシグ N**** 多階層マルチシグ N****
- 39. Tx.4 (ルート)ネームスペース、サブネームスペース ブロックチェーン内唯一の名前をレンタルできる仕組(≒ドメイン名) 特徴 ● ネームスペースレンタル期間 ○ NEM: 1年固定、Symbol: 30日～365日で設定可能 ○ ジェネシスブロックで作成されたネームスペースのみ例外的に永遠に有効 ■ 例. symbol、symbol.xym 等 ● ルートネームスペース … 例. foo ● サブネームスペース … 例. foo.bar , foo.bar.buz ○ NEMではモザイク発行時にサブネームスペースを一緒にレンタルする必要があった ○ Symbolでは、ルートネームスペース、サブネームスペースともに、モザイクだけでな くアドレスにも紐づけることができる ■ エイリアスリンクトランザクション
- 40. Tx.5 メタデータ ブロックチェーン上にkey: valueのペアのデータを署名者の情報をセットにし て残すことができる機能、valueは署名者によって更新可能 ● {署名者公開鍵、key、value}の3情報がセットとなる ● モザイク、ネームスペース、アカウントにメタデータを紐づけることがで きる ネームスペースとの比較 ● 同一keyでも署名者が異なれば存在可能なデータとなること ● keyに対してvalueを持てること ● ネームスペースと異なりレンタル手数料不要 転送トランザクションのメッセージとの比較 ● トランザクションを検索しなくてもメタデータを直接参照できる
- 41. Tx.6 アカウント制限 アカウントに対して以下のような設定が可能 ● 特定のモザイク(トークン)の受け取りを自動的に拒否 ● 特定のアドレスからのみトランザクションを受信できるように設定したり ● それらの制限を削除して元に戻す設定をしたり 目的 ● スパム防止 ● ノイズとなり得るデータトランザクションがそのアカウントに届かないよう にしてそのアカウントが関連するトランザクションのデータをクエリする ロジックをシンプルにする等
- 42. Tx.7 モザイク(≒トークン)制限 1. モザイクの発行時にrestrictable(制限可能)フラグを設定して 2. モザイクを送信可能なkey: valueの条件をモザイクに設定し、 3. モザイクを受取・送信可能にしたいアカウントに2の設定を追加するトラ ンザクションを送信することで、 4. 特定のアカウントのみがそのモザイクを送受信可能な状態に制限でき る 目的 1. 特定の条件を満たしたユーザーしか対象のトークンを送受信できない ようコントロールすることができる
- 43. Tx.8 アグリゲートコンプリートトランザクション 上限100個の子トランザクションを一括実行できるトランザクション (トランザクション送信時 に必要な全ての署名が揃っている場合 ) ユースケースイメージ ● 給付金支給 ○ 1トランザクション1人ずつ転送トランザクションを送信するのではなく、 1トランザクション100人分ず つ送信することで手数料や通信時間を削減可能 ● NFT発行して配布 … 例えば以下のようなトランザクションを一括で実行 ○ ネームスペース取得 … memorial-nft ○ サブネームスペース取得 … memorial-nft.seq1 ○ メタデータ作成 … {発行者公開鍵, name, Memorial NFT} ○ メタデータ作成 … {発行者公開鍵, symbol, MNFT} ○ メタデータ作成 … {発行者公開鍵, metadatauri, https://example.com/api/test.json} ○ メタデータ作成 … {発行者公開鍵, imageuri, https://example.com/images/test.png} ○ モザイク発行 … 供給量1 ○ モザイクにサブネームスペースを紐づけ ○ モザイクにメタデータを紐づけ x 4 ○ 配布先に転送トランザクションでモザイクを送信
- 44. Tx.9 アグリゲートボンデッドトランザクション 上限100個の子トランザクションを一括実行できるトランザクションだが、トランザクション送 信時に全ての署名が揃っておらず、他のアカウントによる連署が必要な場合に使うトランザ クション ● 署名が全て揃っていなくともトランザクションをネットワークにアナウンス可能 ● ただしスパム防止のためトランザクションアナウンス前に対象のアグリゲートボンデッ ドトランザクションのハッシュを指定して 10XYMを担保としてネットワークにロックして ハッシュロックトランザクションを送信し、 ● それが承認されたらアグリゲートボンデッドトランザクションを送信するという手順を踏 む必要がある ● 全ての署名が揃ったらネットワークに担保としてロックしていた 10XYMが自動的に返 却されるとともにトランザクションが自動的に実行される ● 期限内に署名が揃わなかったらネットワークに担保としてロックした 10XYMは没収さ れる
- 45. Tx.9 アグリゲートボンデッドトランザクションのユースケース ● Symbolブロックチェーン上での2者間でのトラストレスなトークンの交換 ○ AさんからBさんに10symbol.xym送信する ○ BさんからAさんに10cms.xym送信する ● マルチシグアカウントからのトランザクション送信 ○ マルチシグアカウントA からのトランザクション送信の場合、連署アカウント aがアグリゲートボンデッドトランザ クションとしてマルチシグアカウント Aからのトランザクションを送信し、それに対して連署アカウント b, cが連署 することでマルチシグアカウントからのトランザクションが実行される ■ 連署アカウント a ■ 連署アカウント b ■ 連署アカウント c ● 手数料の肩代わり ○ お客さんCさんが店主Sさんにトランザクションを送信したい状況だが Cさんは手数料として必要な基軸トークン を持っていない ■ 店主Sさんがアグリゲートボンデッドトランザクションで Cさん→Sさんのトランザクションをアナウンスし、 お客さんCさんはそれに連署することで(連署には手数料発生しないので )Cさんは手数料として必要な トークンなしにトランザクションを送信できる
- 46. Tx.10 HTLC(ハッシュタイムロックコントラクト) Symbolブロックチェーンでは HTLC相当の機能を担うシークレットロックトランザクションとシーク レットプルーフトランザクションの 2種類のトランザクションが用意されている シークレットロックトランザクション ● 秘密の値を知っている人だけが ● そのトランザクションを実際に実行できるよう ● 秘密の値のハッシュを含めた形で ● トランザクションをアナウンス 正しいシークレットを含むシークレットプルーフトランザクションが実行されたらトランザクションが 実行される 期限までに正しいシークレットでシークレットプルーフトランザクションが実行されなかった場合、 そのトランザクションは無かったことになる ユースケース ● 異なるブロックチェーン間でのアトミックスワップ
- 48. ブロックチェーンの透明性・耐改竄性・堅牢性を活かす ● 例 ○ 公的情報の管理 ■ 公文書管理 ■ 戸籍情報管理 ■ 各種インフラ情報管理 ■ 各種契約情報管理 ■ 年金記録 ■ 保険記録 ■ 納税記録 今、不正防止や、改竄防止や、 データ喪失防止といった取組を人 が頑張ってやっているようなと ころを、ブロックチェーンに刻んで、後はブ ロックチェーン自体を維持するという形にする ことで、頑張らなくても重要な記 録を未来に残せるようにする 取組での活用が進むと良いな... と個人的 には思っています
- 49. ブロックチェーン活用における課題は何か ● 法規制関連の問題 ● ユーザーにとってのUI/UXの課題がほとんど ● 特にアカウント管理のハードルが高い ○ ニーモニックフレーズの管理 ○ 秘密鍵の管理 ○ 絶対に無くしてはならないが、絶対に第三者に公開してもならないという難しさ ● ソーシャルリカバリー可能なUI/UXに優れたマルチシグによる煩雑 なアカウント管理を意識せずに使える仕組みが必要