ブロックチェーンの技術概要とSymbolブロックチェーンの技術的特徴の紹介(2023/09/09 オープンセミナー2023@香川)

Transcript

1. ブロックチェーンの技術概要と Symbolブロックチェーンの技術 的特徴の紹介 2023/09/09(土) 13:55～14:30 オープンソース2023@香川 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. Symbolブロックチェーンの機能紹介 d. 直近のコミュニティの取組 e. 今後の取組 2. 活用事例について … 後藤から説明(別スライド)
5. 1. ブロックチェーンの基礎
6. 少しかみ砕いて言い換えると ... ブロックチェーンとは “ブロックチェーン技術とは情報通信ネットワーク上にある端末同士を直接接続して、取引記録を暗号技術 を用いて分散的に処理・記録するデータベースの一種であり、「ビットコイン」等の仮想通貨に用いられている 基盤技術である”(引用元: 総務省平成30年版情報白書) ネットワークを通じて分散した多数のコンピューター同士が、 定められた報酬を得るモチベーションから生み出される競争を通して、 定められたルール通りにデータを正しく処理しているかを相互に検証(≒監視)しあう ことで、 管理主体となる特定の組織や個人に依存することなく、 ネットワーク全体で同一性を保ったデータを記録・維持する基盤技術
7. 管理主体となる個人・組織へ依存しないP2Pネットワーク • クライアント/サーバー ◦ サーバーが中央集権的にクライアント にサービスを提供 • P2P(Peer to Peer) ◦ コンピューター同士が対等に通信を行うこ とでサービスが成立 サーバー クライアント Peer(≒ノード) もしサーバーがダウンしたら ... × サービスは利用不能に ... そうならないよう管理する責務がサー ビス提供者に発生=管理主体となる個 人・組織が必要 × ノードが1台ダウンしても... それ以外のノードでサービス が成立する 管理主体となる個人・組織へ の依存なしに堅牢な仕組みを 実現可能 全体としては冗 長性が高い分 非効率だが各 ノードの負荷は 低め 全体としては効 率的だがサー バー周りの負荷 は高い 絶対的ではない トレードオフ
8. ブロックチェーンに送信 されるデータ一式 何をもってブロックチェーンは取引を受け入れる？ 秘密鍵 公開鍵 取引内容 from Aさん to Bさん 39XYM送信 電子署名 ブロックチェーン上で取引を実行したい人 (Aさん) ブロックチェーン 公開鍵 電子署名 取引内容 整合性OK 公開鍵 電子署名 取引内容 整合性NG シードフレーズ or ニー モニックフレーズ 1. like 2. just 3. love 4. know 5. never 6. … 階層: m/44’/1’/0’/0/0 取引内容に対して適切な公開鍵と正 しい電子署名がセットになっているも ののみ受け入れられる 秘密鍵がすべて！ 絶対に公開してはなら ない！
9. ブロックチェーンのデータ構造の概要と名前の由来 • ブロック 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 … … ブロック間でハッシュを連鎖的に連ねた データ構造→ブロックチェーン ネットワーク参加者 全員で競争的にこ の値を見つける 競争の勝者が報酬 をもらえる
10. PoW: ブロックチェーンを維持するインセンティブを生み出す競争原理 PoW (Proof of Work) … 参考記事 • 暗号パズルの早押しクイズの勝者が 報酬を得る(とともに次のブロックをブロックチェーンに刻む権利を 獲得する) • 暗号パズルを総当たり的に解くため のコンピューティングリソースが豊富 な参加者が有利 • パズルの難しさが自動的に調整され ブロック生成間隔が一定に保たれる • 正解を探すのは大変だが答えが正 解かはすぐわかる→適当に間違った 答えを送っても意味がない × × × 〇 ↑ 嘘 × × × × 検証 ↓ 不正！ ↓ 却下！ 検証 ↓ 不正！ ↓ 却下！ 検証 ↓ 正解 検証 ↓ 正解 〇 × ×
11. PoS: ブロックチェーンを維持するインセンティブを生み出す競争原理 PoS (Proof of Stake) • 暗号パズルの仕組みがPoWと違う ◦ 暗号パズルの答えは各ブロック毎にランダムに 決まっている (1) ◦ それに対し各参加者毎に回答可能な答えもラン ダムに決まっている (2) ◦ (1)の答えに対し、各参加者の回答 (2)が正解か どうかを判定する当たり判定の緩さが時間とと もに緩くなっていき (3)、一番最初に当たり判定 を得た参加者が報酬を得る ◦ (3)のスピードがステーキング額が大きい参加者 程早く、当たり判定をもらいやすく有利 ◦ 参加者全体のステーキング総量に応じて (3)の スピードが調整されブロック生成間隔が一定に 保たれるような仕組みになっている (1) (1) (2) (2) Hit! Stake≒残高 大きいと有利 Stake≒残高 小さいと不利 Stake 大 Stake 小
12. 異なるチェーンが同時に存在した場合どれに統一する？ チェーンA チェーンB チェーンB チェーンA 複数の異なるチェーンがネットワークに同時に存在する場合 A / Bどちら？ 取り決めとしてチェーンが 長い方を正として扱 う チェーンAの方が長いのでチェーンAを 正として扱う Aが長いので Aを正と判断 長い 短い
13. 一般的なコンセンサスアルゴリズムまとめ 1. 誰が次のブロックのデータをブロックチェーンに追加できるか a. PoW: 暗号パズルの総当たり計算の勝者がパズルの答えの証明を提示して その権利＆報酬を獲得 b. PoS: 時間とともにStake(≒保有残高)の大きなユーザーほど有利となる抽選 ゲームの勝者が結果の証明を提示してその権利＆報酬を獲得 2. ネットワーク内で異なるチェーンが存在した場合にどのチェーンを正 とするか a. 最長のチェーンを正とする※ ※ネットワーク内でどのチェーンを正とするかの決め方は他にもある 以下のようなルール (≒仕様)で非中央集権的な参加者同士で (、一時的にはネットワーク内で異なるデータが併 存する状況は許容しつつ、最終的には )同一のデータへ収束し、それを維持していくことができる
14. 確率的ファイナリティについて • 最長チェーンを正とする場合、短かったチェーンは無かったこと になり、短かったチェーンに含まれていたトランザクションが無 かったことになる • ではブロックに含まれたトランザクションが確定したとどうやって 判断すればいいか？ • 確率的にそのブロックが覆らないであろうと十分判断できるだけ 待って確定したものと見なす 考え方=確率的ファイナリティ あるブロック(1)が生成され、その後、数ブロック新たにブロックが生成された後で、ブロック (1)のブ ロック高さのブロックが別のものに変わったチェーンが最長となる確率は、一定以上のブロック数 が生成された後には確率的に極めて低くなる ただしブロックが 覆らない可能性 を厳密にゼロに はできないことに 注意が必要 可能性低い⇒
15. 即時確定的ファイナリティ • 確率的ファイナリティの弱さ ◦ 取引を即座に確定と見なせないのは不便 • 事前投票的なプロセスでブロック生成前に次のブロックをネット ワーク内で合意形成して決めておく方法 ◦ ブロックを各ノードが新たに生成する前に ◦ ノード間で投票のようなプロセスを行い、 ◦ 次のブロックを事前にネットワーク内で合意形成してから ◦ 各ノードが同じブロックを刻む ◦ 刻まれたブロックは覆らず、 ◦ ブロックに組み込まれると同時に即時にファイナリティを獲得 • ただしこの方法には弱点も ◦ ノード間で合意を取るプロセスで ◦ 参加者数=ノード数が増えると ◦ ノード間の通信量が爆発的に増加するため、 ◦ ノード数を無制限に増やすことは難しい ×←こういう別 のブロックが 作られないよ うに 事前に ネット ワーク間 で合意 形成して おき→
16. チェックポイントによる確定的ファイナリティ(≠即時) • 毎ブロック毎の即時ファイナリティの弱点 ◦ 参加者が増えると合意形成に必要な通信量が激増 ◦ 結果として毎ブロック毎の合意形成が難しい • 毎ブロック毎でなければいけるのでは？ ◦ 一定ブロック毎にチェックポイントを設け合意形成を行い ◦ 合意形成取れたブロックは覆らない運用で実現 合意 形成 ↓ 確定 毎回合意形成はし んどい... 即時のファイナリ ティは得られず待 ち時間は必要 合意 形成 ↓ 確定 合意 形成 ↓ 確定 合意 形成 ↓ 確定 合意 形成 ↓ 確定 合意 形成 ↓ 確定 定められたブロック数や時間だけ間隔をあけてネットワーク間での合意形 成を行ってそこまでのブロックを確定させるのを繰り返す 確定 確定 確定 確定
17. ビットコイン 確率的ファイナリティ 代表例 NEM/Symbol はこれ ブロック生成 確率的 ファイナリティ Cosmos SDK製 独自ブロックチェーン等 NEM/Symbol チェックポイント 確定的ファイナリティ コンセンサスアルゴリズムとファイナリティのまとめ • 確率的なファイナリティ ◦ PoW+最長チェーン選択でのブロック生成 ▪ ビットコイン • トランザクションがブロックに組 み込まれていくつか追加ブロッ ク承認をまって決済確定と見な す場合が多い • 確率的なもの • 100%ではない(とはいえ無視 できるほど十分小さい) ◦ PoS+最長チェーン選択でのブロック生成 ▪ NEM / Symbolでは新規ブロック生成 はPoS的なメカニズム ▪ PoS的なブロック生成メカニズムでも、 ビットコインと同様に確率的なファイナ リティしか得られない • 確定的なファイナリティ ◦ ある種の投票によって実現される • 即時かつ確定的ファイナリティ ◦ 概要 ▪ 毎ブロック毎に投票 ▪ 分散されたネットワーク間で ▪ 有効な投票を集めて合意形成する ◦ 合意形成できなかったら ▪ 即座にチェーン止まる ◦ 参加者が増えると... ▪ 合意に必要なリソースが大きくなりすぎる ▪ ので参加者数の上限を制限する場合が多い • 即時ではなくかつチェックポイントを設けることで実 現した確定的ファイナリティ ◦ チェックポイント経過時に確定的な投票が行われて合 意形成する ▪ 見える範囲のネットワーク全体 • NEM ▪ ネットワーク全体 • Symbol
18. 2. ブロックチェーンの代表例
19. BTC Bitcoin ビットコイン … ブロックチェーン元祖 • ナカモトコンセンサス … 確率的ファイナリティ ◦ Sybilアタック耐性としてのPoW ◦ 最長チェーン選択によりネットワーク内のデータの一貫性を 保つ • トークン残高等は、未使用のトランザクション出力 =UTXO(Unspent Transaction Output)をツリー上に束 ねた構造として扱われる • ブロック生成間隔10分 • 機能少なくシンプル • 近年はライトニングネットワークを通じた待ち時間不要な 仕組みを利用したマイクロペイメントのユースケースが 広がりを見せている
20. ビットコイン 確率的ファイナリティ 代表例 コンセンサスアルゴリズムとファイナリティのまとめ • 確率的なファイナリティ ◦ PoW+最長チェーン選択でのブロック生成 ▪ ビットコイン • トランザクションがブロックに組 み込まれていくつか追加ブロッ ク承認をまって決済確定と見な す場合が多い • 確率的なもの • 100%ではない(とはいえ無視 できるほど十分小さい) ◦ PoS+最長チェーン選択でのブロック生成 ▪ NEM / Symbolでは新規ブロック生成 はPoS的なメカニズム ▪ PoS的なブロック生成メカニズムでも、 ビットコインと同様に確率的なファイナ リティしか得られない • 確定的なファイナリティ ◦ ある種の投票によって実現される • 即時かつ確定的ファイナリティ ◦ 概要 ▪ 毎ブロック毎に投票 ▪ 分散されたネットワーク間で ▪ 有効な投票を集めて合意形成する ◦ 合意形成できなかったら ▪ 即座にチェーン止まる ◦ 参加者が増えると... ▪ 合意に必要なリソースが大きくなりすぎる ▪ ので参加者数の上限を制限する場合が多い • 即時ではなくかつチェックポイントを設けることで実 現した確定的ファイナリティ ◦ チェックポイント経過時に確定的な投票が行われて合 意形成する ▪ 見える範囲のネットワーク全体 • NEM ▪ ネットワーク全体 • Symbol
21. ETH Ethereum イーサリアム … スマートコントラクト • 以前PoWだったが昨年にPoSへの移行を完了 • ビットコインのUTXOと異なりデータ構造はさらに柔軟な状態を表現で きるものとなっている • ブロック生成間隔15秒 • 圧倒的な自由度 ◦ 開発者自身でスマートコントラクトを実装してブロックチェーンに デプロイすることで、ユーザーからのコントラクト呼び出しによっ て、ブロックチェーンのノード上で自動的に処理が実行されそ の結果をブロックチェーンの状態として保持しておくようなこと が可能 • デプロイ済のコントラクトを変更するのは原理的に困難 / 新たな独自 実装をセキュリティ的に問題なく実装する難しさも • 非中央集権的な領域ではDeFiのエコシステムが発展 • それ以外の領域でもNFTの認知が高まり多くのNFT関連サービスが 生まれた • 近年は更なる拡張性を求めLayer2, ZKP関連の取組がさかんに見え る
22. イーサリアム 最初はPoW (確率的ファイナリティ ) だった 確定的ファイナリティ はなかった イーサリアム ブロック生成 PoS(確率的ファイナリティ ) へ移行済 イーサリアム 確定的ファイナリティ Gasperと呼ばれるアルゴリズム コンセンサスアルゴリズムとファイナリティのまとめ • 確率的なファイナリティ ◦ PoW+最長チェーン選択でのブロック生成 ▪ ビットコイン • トランザクションがブロックに組 み込まれていくつか追加ブロッ ク承認をまって決済確定と見な す場合が多い • 確率的なもの • 100%ではない(とはいえ無視 できるほど十分小さい) ◦ PoS+最長チェーン選択でのブロック生成 ▪ NEM / Symbolでは新規ブロック生成 はPoS的なメカニズム ▪ PoS的なブロック生成メカニズムでも、 ビットコインと同様に確率的なファイナ リティしか得られない • 確定的なファイナリティ ◦ ある種の投票によって実現される • 即時かつ確定的ファイナリティ ◦ 概要 ▪ 毎ブロック毎に投票 ▪ 分散されたネットワーク間で ▪ 有効な投票を集めて合意形成する ◦ 合意形成できなかったら ▪ 即座にチェーン止まる ◦ 参加者が増えると... ▪ 合意に必要なリソースが大きくなりすぎる ▪ ので参加者数の上限を制限する場合が多い • 即時ではなくかつチェックポイントを設けることで実 現した確定的ファイナリティ ◦ チェックポイント経過時に確定的な投票が行われて合 意形成する ▪ 見える範囲のネットワーク全体 • NEM ▪ ネットワーク全体 • Symbol
23. NEM(New Economy Movement) ネム … スマートコントラクト無しの世界 • REST APIやWebSocket等の既存のWeb開発の延長線上 で、スマートコントラクト無しでもブロックチェーンに予め組 み込まれた様々な機能を使うことで、ブロックチェーンの特 徴を活かしたアプリ開発を開発者フレンドリーに行うことが できるというコンセプトを示したブロックチェーン • 独自トークンの発行 • 独自トークンへのブロックチェーン内での唯一性が担保さ れた名前の付与 • ブロックチェーンネイティブにビルトイン済のマルチシグ機 能(複数の署名が揃ったらトランザクション実行できるアカ ウント管理機能) • バリデーターノードの分散化だけでなく、 APIノードの分散 化にもこだわりがある • NEMの新バージョンとして後述する Symbolが新たにロー ンチされたが、NEMブロックチェーンもSymbolブロック チェーンとは別に今も動いている
24. NEM/Symbol はこれ ブロック生成 確率的 ファイナリティ NEM/Symbol チェックポイント 確定的ファイナリティ コンセンサスアルゴリズムとファイナリティのまとめ • 確率的なファイナリティ ◦ PoW+最長チェーン選択でのブロック生成 ▪ ビットコイン • トランザクションがブロックに組 み込まれていくつか追加ブロッ ク承認をまって決済確定と見な す場合が多い • 確率的なもの • 100%ではない(とはいえ無視 できるほど十分小さい) ◦ PoS+最長チェーン選択でのブロック生成 ▪ NEM / Symbolでは新規ブロック生成 はPoS的なメカニズム ▪ PoS的なブロック生成メカニズムでも、 ビットコインと同様に確率的なファイナ リティしか得られない • 確定的なファイナリティ ◦ ある種の投票によって実現される • 即時かつ確定的ファイナリティ ◦ 概要 ▪ 毎ブロック毎に投票 ▪ 分散されたネットワーク間で ▪ 有効な投票を集めて合意形成する ◦ 合意形成できなかったら ▪ 即座にチェーン止まる ◦ 参加者が増えると... ▪ 合意に必要なリソースが大きくなりすぎる ▪ ので参加者数の上限を制限する場合が多い • 即時ではなくかつチェックポイントを設けることで実 現した確定的ファイナリティ ◦ チェックポイント経過時に確定的な投票が行われて合 意形成する ▪ 見える範囲のネットワーク全体 • NEM ▪ ネットワーク全体 • Symbol
25. Cosmos SDK製ブロックチェーン … IBC • 独自チェーンを作るのに便利なフレームワークの提供 • ブロックチェーン間で柔軟かつ堅牢に各種連携 (トークンの 送受信・情報のやり取り )を行えるような規格の整備 といった点に主眼を置いて、一つのブロックチェーンだけで全てを 行うにあたっての限界を、目的ごとに独自のブロックチェーンを作 成して、それら別々のブロックチェーン間が連携することで解決を 目指す枠組みがCosmos SDK 近年、ブロックチェーン間の連携が実働開始したことで、 Cosmos SDK製ブロックチェーン間のエコシステムが大きく発展を遂げてい る 技術的な違いはあるが Astar等のPolkadot系エコシステムも近い 思想が根底にあると感じる
26. Cosmos SDK製 独自ブロックチェーン等 コンセンサスアルゴリズムとファイナリティのまとめ • 確率的なファイナリティ ◦ PoW+最長チェーン選択でのブロック生成 ▪ ビットコイン • トランザクションがブロックに組 み込まれていくつか追加ブロッ ク承認をまって決済確定と見な す場合が多い • 確率的なもの • 100%ではない(とはいえ無視 できるほど十分小さい) ◦ PoS+最長チェーン選択でのブロック生成 ▪ NEM / Symbolでは新規ブロック生成 はPoS的なメカニズム ▪ PoS的なブロック生成メカニズムでも、 ビットコインと同様に確率的なファイナ リティしか得られない • 確定的なファイナリティ ◦ ある種の投票によって実現される • 即時かつ確定的ファイナリティ ◦ 概要 ▪ 毎ブロック毎に投票 ▪ 分散されたネットワーク間で ▪ 有効な投票を集めて合意形成する ◦ 合意形成できなかったら ▪ 即座にチェーン止まる ◦ 参加者が増えると... ▪ 合意に必要なリソースが大きくなりすぎる ▪ ので参加者数の上限を制限する場合が多い • 即時ではなくかつチェックポイントを設けることで実 現した確定的ファイナリティ ◦ チェックポイント経過時に確定的な投票が行われて合 意形成する ▪ 見える範囲のネットワーク全体 • NEM ▪ ネットワーク全体 • Symbol
27. Symbolブロックチェーン … NEMの新バージョン • 他チェーンがスケーラビリティや拡張性等の点で、ライトニングネッ トワークやLayer2やブロックチェーン間通信等のようにブロック チェーンの外へ活路を見出していたのに比べて、 • ブロックチェーンのLayer1それ自身の改善に(長い時間かけて)真 正面から取組した結果生まれた新しいブロックチェーン • NEMの哲学が引き継がれつつ ◦ APIノードの分散性重視、REST API, WebSocket重視 • 以下のような機能面も拡充され ◦ 多階層で柔軟なマルチシグ構成 ◦ 署名が揃うのを待って複数のトランザクションが一括実行される限 定的なスマートコントラクトのような機能 ◦ 複数のブロックチェーン間でのアトミックスワップをサポートするため のHashed Time Lock Contractのサポート • スケーラビリティの点でも改善され ◦ 1ブロック60秒120トランザクション -> 1ブロック30秒6000トランザク ション • 既存のWeb開発の延長線上でブロックチェーンを容易に組み込ん で使うことができるという点で開発者フレンドリーなバランスの良い 現実的な選択肢となりうる点が大きな特徴
28. NEM/Symbol はこれ ブロック生成 確率的 ファイナリティ NEM/Symbol チェックポイント 確定的ファイナリティ コンセンサスアルゴリズムとファイナリティのまとめ • 確率的なファイナリティ ◦ PoW+最長チェーン選択でのブロック生成 ▪ ビットコイン • トランザクションがブロックに組 み込まれていくつか追加ブロッ ク承認をまって決済確定と見な す場合が多い • 確率的なもの • 100%ではない(とはいえ無視 できるほど十分小さい) ◦ PoS+最長チェーン選択でのブロック生成 ▪ NEM / Symbolでは新規ブロック生成 はPoS的なメカニズム ▪ PoS的なブロック生成メカニズムでも、 ビットコインと同様に確率的なファイナ リティしか得られない • 確定的なファイナリティ ◦ ある種の投票によって実現される • 即時かつ確定的ファイナリティ ◦ 概要 ▪ 毎ブロック毎に投票 ▪ 分散されたネットワーク間で ▪ 有効な投票を集めて合意形成する ◦ 合意形成できなかったら ▪ 即座にチェーン止まる ◦ 参加者が増えると... ▪ 合意に必要なリソースが大きくなりすぎる ▪ ので参加者数の上限を制限する場合が多い • 即時ではなくかつチェックポイントを設けることで実 現した確定的ファイナリティ ◦ チェックポイント経過時に確定的な投票が行われて合 意形成する ▪ 見える範囲のネットワーク全体 • NEM ▪ ネットワーク全体 • Symbol
29. 3. Symbolブロックチェーンの機能紹介
30. NEM / Symbolの特徴 スマートコントラクト(開発・実装)無しに Dapps開発が可能
31. 一般的なDApps開発 通常のアプリ開発に 加えて スマートコントラクト の開発・デプロイ・デ バッグ・テストが必要 高い自由度を実現可 能だが難しさも アプリその1 アプリその2 独自言語を用 いた スマート コントラクト開 発 コントラクト • 状態 • 関数 デプロイ コントラクトの 状態を参照 コントラクトの関 数を呼ぶ アプリ開発 デプロイ
32. NEM / SymbolにおけるDApps開発 通常のアプリ開発の延 長線上で (スマートコントラクト開 発なしに) ブロックチェーン自体に 元々組み込まれた様々 なトランザクションを実 行することで 自由度はある程度制約 されるが様々な挙動を 柔軟に表現可能 アプリその1 アプリその2 ブロックチェーン • 状態 • 様々な トランザクショ ン チェーンの状 態を参照 トランザクション を実行 アプリ開発 デプロイ 独自言語を用 いた スマート コントラクト開 発 やらなくてOK→
33. Symbolブロックチェーンの技術的特徴 1. フルノードの維持にインセンティブ a. 全世界に力強く分散して多数存在するAPI ノード群を開発者が自由に使用可能 2. トークン a. 転送可否設定 b. トークン送受信可能なアカウントを制御可能な 設定 c. 管理者による回収可能な設定 d. 柔軟な有効期限管理 3. ネームスペース a. 柔軟な有効期限 4. メタデータ a. key: valueデータをアドレス、トークン、ネーム スペースに紐づけ可能 5. マルチシグ a. 複数階層のマルチシグもサポート 6. アグリゲートトランザクション a. アグリゲートコンプリートトランザクション i. 取引当事者の署名及び連署を全てそ ろえてブロックチェーンにトランザクショ ンをアナウンスし、複数の取引を一括 実行する仕組み b. アグリゲートボンデッドトランザクション i. 連署が全てそろっていない状態でブ ロックチェーンにトランザクションをアナ ウンスし、取引関係者の全ての連署 (≒Walletを通じた合意意思表明)がそ ろったら一連の処理がまとめて実行さ れる仕組み 7. シークレットロックトランザクション a. 異なるブロックチェーン間でのトークン交換等 での応用が可能
34. Symbolの技術的特徴 その1 APIノードの維持に(実質的に)インセンティブが ある ↓ APIノードが全世界に分散して多数公開 ↓ 開発者が自由に公開済APIノードで開発可能 ↓ より低コスト＆簡単に
35. APIノード群 インセンティブ無し ブロックチェーン ネットワーク バリデーター ノード群: インセンティブ 有り 一般的なブロックチェーンとアプリの関係 〇 アプリその1 アプリその2 〇 × ×
36. バリデーター&API ノード群 … 誰もが自由 に使えるAPIノードが増 えるインセンティブがあ る！ ≒ブロックチェーンネット ワークそのもの Symbolのブロックチェーンとアプリの関係 〇 アプリその1 アプリその2 〇
37. Symbolの技術的特徴 その2 必要十分な機能が組み込まれた共通実装の トークンを活用可能 • 転送可否設定 … 転送不可にしてSBT(=SoulBound Token) • 回収可能可否設定 … 回収可能に設定すると、あえて、中央 集権的なサービスにおけるトークン活用も容易に可能となる • トークン送受信可能アカウントの制御 … 認可ア カウントのみトークン送受信可能にコントロール可能に設定でき、KYC, ス パム防止等に活用可能 🪙
38. Symbolの技術的特徴 その3 ネームスペース(をアドレスやトークンに紐づけ可能 ) アドレス N***A 組織名 npo.nemtus 対象組織の アドレスであ ることを明示 できる ↓ ブロック チェーン上 で重複しな い唯一の名 前を紐づけ ↓ 公式なもの であることの 証明 アドレス N***B 職位名 npo.nemtus.chairman 対象組織の 対象職位の アドレスであ ることを明示 できる トークン t***a トークン t***b 通貨名 cbdc.japan.jpy トークンの種類 を明示できる ↓ ブロックチェーン 上で重複しない 唯一の名前なの で、設定をコ ピーした偽物の トークンと明示 的に区別できる 通貨名 cbdc.usa.usd
39. Symbolの技術的特徴 その4 メタデータ(をアドレス,トークン,ネームスペースに紐づけ可能 ) ネームスペース ecobit アドレス N***B (関係者)属性情報 type=harvester name=ecob sex=male birthDate=2017/07/28 farm=ecobit トークン t***a (収穫物・商品)属性情報 type=vegitable name=tomato farm=ecobit lotId=a0b1c2d3e4f5 harvester=ecob harvestedDate=2023/07/28 (ブランド)属性情報 type=farm name=ecobit latitude=100.5017 longitude=13.7563 ブロックチェーン上に 属性 = 属性値 by 登録者 的なデータをアドレスやトー クンやネームスペースに持 たせることができる ↓ アドレス、トークン、ネームス ペースの属性情報の明示に 便利 更新可能
40. Symbolの技術的特徴 その5 マルチシグ 〇〇社マルチシグ N**** 社長 N**** 部長 N**** 社員 N**** 必要な署名がそろった場 合のみ、処理が実行可能 なマルチシグアカウント △△コンソーシアム N**** 〇〇社マルチシグ N**** 社長 N**** 部長 N**** 社員 N**** △△社マルチシグ N**** 社長 N**** 部長 N**** 社員 N**** NEM マルチシグ Symbol マルチレベル マルチシグ より柔軟で実用的なワー クフローをブロックチェー ンで実現できるように！
41. 最大100個の複数の取引を、取引当事者の署名 や連署がそろったら、まとめて実行できる機能 ブロックチェーンにアナウンス時点で全ての署名＆ 連署がそろっている「アグリゲートコンプリートトラ ンザクション」と足りない連署をブロックチェーン ネットワークを通じて集める「アグリゲートボンデッ ドトランザクション」の 2種類がある アグリゲートコンプリートトランザクションのユース ケース • トークンの一括送信事例 ◦ トークンを新たに定義して作成 ◦ トークンの属性値をメタデータで設定 ◦ トークンを複数の相手に一括送信 Symbolの技術的特徴 その6 アグリゲートトランザクション (収穫物)属性情報 type=vegitable name=tomato farm=ecobit lotId=a0b1c2d3e4f5 harvester=ecob harvestedDate=2023/07/28
42. 最大100個の複数の取引を、取引当事者の署名 や連署がそろったら、まとめて実行できる機能 足りない連署をブロックチェーンネットワークを通じ て集める「アグリゲートボンデッドトランザクション」 アグリゲートボンデッドトランザクションのユース ケース • トラストレスなトークン交換 ◦ トークンを交換する2者同士の取引をアグリ ゲートボンデッドトランザクションとしてネット ワークにアナウンスし、 ◦ もう一方の取引者が連署することでトークンの 交換取引が完了する Symbolの技術的特徴 その6 アグリゲートトランザクション
43. ハッシュタイムロックコントラクト (HTLC)等と呼ばれることもある仕組 みで異なるブロックチェーン間でのトラストレスなトークン交換に応用 可能 前提知識 • 秘密の値 -> ハッシュ値 は計算できるが • 秘密の値 <- ハッシュ値 は原理的に計算できない 取引の流れ 1. 取引開始する人は秘密の値は手元にキープして相手に伏せ た状態で、ハッシュ値をセットにして公開し、 HTLCの枠組み でトークンを送る 2. 取引相手は、1が正常に送信されていることが確認できたら 1 と同じハッシュで、シークレットロックトランザクションでトーク ンを送る 3. ハッシュ値に対応する秘密の値を、相手が送ってくれたブ ロックチェーン側で公開することでシークレットロックトランザ クションでロック状態だったトークン送信が解除され目的の トークンを受け取れる 4. 3の取引を見ると秘密の値がわかるので、相手が送ってくれ たブロックチェーン上で同じ値を公開することで、 HTLCの ロックが解除されトークンを受け取れる Symbolの技術的特徴 その7 シークレットロックトランザクション 1. EVM系ブロックチェーン ERC20　　　　ハッシュ値 Mosaic　　　同ハッシュ値 2. Symbolブロックチェーン 秘密の値 ↓ハッシュ化 ハッシュ値 3. Symbolブロックチェーンで秘密の 値を公開(してMosaicを取得) 4. EVM系ブロックチェーンで秘密の値 を公開(してERC20を取得)
44. 4. 具体的なサービスを想定してブロックチェーン を活用して実現する設計パターンを紹介
45. 戸籍管理システムを想定したブロックチェーンの活用アイディ ア紹介 -> DID マルチシグアカウント メタデータ name=暗号太郎 sex=男 birth=2009年1月3日 father=NA…Q mother=NB…Y … 成人に伴い 自己管理へ マルチシグ 構成変更 メタデータ name=暗号太郎 sex=男 birth=2009年1月3日 father=NA…Q mother=NB…Y … spouse=NC…Z marriedAt=2039年1月3日 メタデータ name=暗号太郎 sex=男 birth=2009年1月3日 father=NA…Q mother=NB…Y … spouse=NC…Z marriedAt=2039年1月3日 … death=2089年1月3日
46. 公文書管理システムを想定したブロックチェーンの活用アイ ディア紹介 -> 永続的ストレージ 細かい データに 分割 0123456789abcdef…f 0123456789abcdef…f 0123456789abcdef…f 0123456789abcdef…f … message=0123456789abcdef…f message=0123456789abcdef…f message=0123456789abcdef…f message=0123456789abcdef…f … アグリゲートトランザクション 一括書き込み (メッセージ、メタデータ いずれでも実現可能 ) 公文書ファイル
47. 登記管理システム＆証券管理システムを想定したブロック チェーンの活用アイディア紹介 -> 永続的DB＆ユーザー同士 の直接取引による効率化 マルチシグアカウント アカウントメタ データ name=ブロックチェーン株 式会社 type=株式会社 created=2029年1月3日 founder=NA…Q … 株式発行 (モザイクメタ データ) company=NB…Y type=未上場株式 (モザイク制限) 特定アカウントのみ送受 信可能 創業者 (初期)投資家 上場 株式属性変更 (モザイクメタ データ) company=NB…Y type=未上場株式 (モザイク制限) 特定アカウントのみ送受 信可能->証券会社から上 場株式の取引許可を得た 投資家に送受信が解放 (一般)投資家 取引許可 アグリゲートボンデッドトランザクション で直接取引
48. 5. ブロックチェーンの学習方法 その1. ブロックチェーンに触れてみる NFA, DYOR
49. まずはユーザーと して触ってみる 1. Wallet a. 最初はテストネットで色々試そう i. faucet(=蛇口)からテスト用トークンを取得し て試そう b. シードフレーズの確実なバックアップ！ c. シードフレーズや秘密鍵は可能な限り安全に保管し 他者に絶対に教えない！ 2. Portfolio管理ツール a. 税務関連サポートツールを使ってメインネットで使用 したアカウントの記録を残しておこう 3. X to Earn, Blockchain Game a. 無理なく楽しみながら触れてみよう 4. 取引所 a. 色々なブロックチェーンのトークンを取得してみよう 5. NFTマーケットプレイス a. 色々なNFTに触れてみよう 6. DeFiプラットフォーム a. 非中央集権的な金融プラットフォームにも触れてみよ う 百聞は一見に如かず！ ご安全に！！
50. 各種イベントに足 を運んでみる 1. セミナー講演や出展を見に行く a. オープンソースカンファレンス等 2. Community Meetup a. ゆるやかな集まりでコミュニティの方々 同士の交流を楽しむ b. NEMTUS Community Meetup 3. 勉強会・ハンズオンのように手を動 かすもの a. オープンディベロッパーカンファレンス等 b. NEMTUS主催の各種勉強会イベント 4. ハッカソン a. 腕試し！参加者の方々とのより深い交 流！新しい何かが生まれるかも？ オフの場のイベント参加に抵抗な ければぜひ！ ご安全に！！
51. 5. ブロックチェーン学習方法 その2. 本格的な学習に進むには？ NFA, DYOR
52. 手を動かしながら 開発について学ん でみる ブロックチェーン学習 その2 1. 全ブロックチェーン共通 a. HD Walletの規格等のアカウント i. Seed Phrase + Derived Path -> 子アカウントの導出方法 b. Web開発、アプリ開発等の一般的な 知識・手法 ↓共通の知識・手法ベースが固まった ら次にブロックチェーン毎の内容へ 2. ブロックチェーン毎 a. Bitcoin b. Ethereum c. Cosmos SDK d. NEM/Symbol 百聞は一見に如かず！実際 に手を動かしてまずは触って みよう！
53. Bitcoin 1. UTXO (=Unsupent TX(=Transaction) Output)への理解 2. フルノードまたはAPIの準備 3. トランザクションの種類の理解 4. トランザクションの送信 a. トランザクションへの署名 b. ネットワークへのアナウンス c. トランザクションの状態監視
54. Ethereum 1. UTXO型とは異なるステートマシンとしてのブロックチェーンの概念の理解 2. スマートコントラクトの概念の理解 3. フルノードまたはAPIの準備 … サードパーティーのノードホスティングサービスを使 うのが現実的 4. シンプルなスマートコントラクトのテストネットへのデプロイと、デプロイされたコント ラクトの呼び出しを実際に試してみて開発の流れを把握 5. スマートコントラクト開発におけるセキュリティでのはまりどころを具体的な攻撃事例 を通して学ぶ
55. Cosmos SDK製独自ブロックチェーン 1. ブロックチェーン間連携がプロトコルベースで考慮されたIBCの概念の理解 2. フレームワークが提供するCLIツールを使って開発のスタート地点となる独自ブロッ クチェーンを手元で作っては壊しながら色々試してみる a. 標準モジュールとしてフレームワークに組み込み済のモジュール群への理解を深める b. 他プロジェクトで使用されている他プロジェクトの独自モジュールの活用等も 3. 独自ブロックチェーンのノードを動かすためのインフラの構築 4. 独自ブロックチェーンのAPIを動かす 5. 独自の拡張モジュールの開発・デバッグ 6. Wasmベースのスマートコントラクト
56. NEM/Symbol 1. ブロックチェーン自身にビルトインで実装済の機能の把握・理解 a. モザイク(≒独自トークン)、ネームスペース、メタデータ b. アグリゲートトランザクション、マルチレベルマルチシグ、シークレットロックトランザクション (≒HTLC) 2. 全世界に分散して存在する公開されたREST APIでブロックチェーンとのやり取りを 行う方法を把握・理解 a. ブロックチェーンから各種情報を検索・取得 3. トランザクションの送信 a. 署名 -> ネットワークへのアナウンス -> 状態監視 b. 場合によっては連署
57. NEM/Symbolコミュニティメンバーによって制作 された速習Symbolというブロックチェーン学習用 コンテンツの紹介
58. 速習Symbol • オリジナル ◦ https://github.com/xembook/quick_learning _symbol • 作者 ◦ Twitter ▪ https://twitter.com/xembook ◦ GitHub ▪ https://github.com/xembook • 対象言語 ◦ JavaScript版 • 特徴 ◦ 特別な環境構築なしに誰もがブラウザの開発 者用コンソールで即座に試せる手軽さで、ブ ロックチェーンの基礎的な知識～実践的な開 発内容までバランスよく網羅された内容を一 通り体験できる
59. 6. 直近のコミュニティの取組の紹介 NEMTUS Community Meetup
60. 今日から現場で使 える速習Symbolブ ロックチェーン JavaScript版 技術書典14 NEMTUSにて制作し た新刊1冊目の紹介 • 特別な環境構築なしにWebブラウザの コンソールでお手軽実行可能な内容 • 金融だけでなく多くのビジネスや分化 の「現場」で活躍する人にも
61. 今日から現場で使 える速習Symbolブ ロックチェーンC# 版 技術書典14 NEMTUSにて制作し た新刊2冊目の紹介 • オリジナルのJavaScript版と同じ内 容をC#版にしたもの • ゲーム開発、PC向けアプリ開発、 各種業務用アプリ開発向け
62. Symbol 解体新書 技術書典14 NEMTUSにて制作し た新刊3冊目の紹介 • Symbolブロックチェーンの Technical Reference+解説 • 難解になりがちな内容がわかりやすくかみ砕 いて説明されている • 正確さとわかりやすさのバランス良い形でブ ロックチェーンの概論を把握できる
63. 月刊NEMTUS LT資料集vol.1 技術書典14 NEMTUSにて制作し た新刊4冊目の紹介 • コミュニティメンバーが集まって毎月最 終土曜日に開催しているオンラインLT 会「月刊NEMTUS」での、各登壇者の LT資料集 第1弾
64. 月刊NEMTUS LT資料集vol.2 技術書典14 NEMTUSにて制作し た新刊5冊目の紹介 • コミュニティメンバーが集まって毎月最 終土曜日に開催しているオンラインLT 会「月刊NEMTUS」での、各登壇者の LT資料集 第2弾
65. Symbolコミュニティ メンバーが1日店 長を！ ブロックチェーンについて語り合え る銀座のバーにて 実際にブロックチェーンを使う(≒Symbol決 済を試してみる)ことができたり、1日店長が 開発した新作ブロックチェーンゲームに触れ たりできるとても楽しいイベントでした！
66. 8/19(土) 19:00-21:00 新宿 Crypto Lounge GOX にて開催 NEMTUS Community Meetup オープンソースカンファレンス他、 NEMTUS としてリアル出展させて頂くイベントと同タイ ミング・場所で開催 過去の開催地域 • 札幌 • 京都 • 東京(新宿)
67. トマティーナ&ポテティーナ(毎年8月最終水曜日開催: 2023/08/30 水) ブロックチェーン上でトマトを模したトー クンをコミュニティメンバー同士が投げ 合って楽しむ年に1回のお祭りイベント https://symbol-community.com/ja/events/tomatina https://symbol-community.com/ja/events/potatina 今年はSymbolブロックチェーンコミュニティ以外からも Very Long Animalsコミュニティも参戦して トマトとポテトを投げ合う新しいお祭りイベントに！
68. 7. 今後の取組
69. 日本全国様々な箇所での技術イベントに参加していきたい • ブロックチェーンに興味を持っている方々とつながりたい • ブロックチェーンについて正しい知識を伝えていきたい • 堅牢で透明性の高いデータ基盤の実現に悩んでいたり、苦労され ている方々とつながりたい • ビジネスにおいて何かを「証明する」という部分に大きなリソースや ペインが発生している方々の助けになりたい
70. 技術書典オンラインマーケットで継続的に販売中！(速習 Symbol JS版/C#版, Symbol解体新書, コミュニティイベントLT 資料集vol.1/2) & 技術書典15申込中！ 新刊5冊いずれもNEM / Symbolコミュニティのブロッ クチェーンの知見と NEMTUSとコミュニティのこ れまでの歩みが感じられる 書籍だと思います！ 技術書典14は終了しました がオンラインマーケットでは 継続販売中なのでぜひご覧 になって頂けると嬉しいで す！ 技術書典15も申し込み中！ 新刊！？
71. 来年度もハッカソン開催を予定 • 毎年12月末頃～3月頃にかけて開催予定 ◦ 興味ある方はぜひ参加者としてご参加ください ◦ コミュニティ投票だけの参加も大歓迎なのでぜひNEMTUSを ウォッチしてくださると嬉しいです • これまでのハッカソンはNPO法人NEMTUS自身がテーマ設定 ◦ しかし来年度は当事者の方々とともに社会課題の解決を目指 すような取組にもチャレンジしてみたい(=現時点ではジャストア イディア＆全ては未定) ▪ (例1) 地方創生 ▪ (例2) SDGs • ぜひNEMTUSへお気軽にお声かけくださいますと幸いです
72. ありがとうございました この機会にぜひNEMTUS(ねむたす)をフォローください！ 次はビジネスでの活用事例を中心にNEMTUS代表の後藤から説明します。