Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Blockchain関連 調べたことまとめ

Blockchain関連 調べたことまとめ

ブロックチェーンの基礎・ユースケースから、web3 に重要な要素であるイーサリアムの技術スタックまで 幅広く、自身で調べてまとめたスライドです。

Katsuya Omura

December 02, 2023
Tweet

Other Decks in Technology

Transcript

  1. Blockchain 関連
    調べたことまとめ
    ブロックチェーン基礎〜イーサリアム / Web3まで

    View full-size slide

  2. ⽬次
    • ブロックチェーンの基礎
    • ブロックチェーンの利点・種類・合意形成アルゴリズム
    • ブロックチェーンのユースケース
    • ブロックチェーンのデータ構造(イーサリアムのワールドステート関連)
    • DApps(分散アプリ)の基礎
    • DApps 全体イメージ(Web 2.0 アプリとの関係)
    • スマートコントラクトの実装(Remix / Hardhat)
    • スマートコントラクトの操作(Web3.js / Ethers.js)
    • NFT の基礎
    • NFTの概要(規格 / アーキテクチャ)
    • デモアプリのアーキテクチャ設計
    • Angular 概要(コンポーネントの基本構成)
    • ブロックチェーンのセキュリティ
    • 安全性はどのように確保されているのか
    2

    View full-size slide

  3. ブロックチェーンの基礎
    3

    View full-size slide

  4. 新規ビジネス
    ブロックチェーンの特性
    システム的な⾯
    Why ブロックチェーン?
    4
    スマートコントラクト
    契約処理の⾃動化によるコスト削減
    ⼿作業を排除しデータの信憑性を確保
    改ざん耐性
    ブロックチェーンの仕組みによる特性
    で、データの「正しさ」を証明
    耐障害性の⾼さによる信頼性の向上
    トレーサビリティ
    (追跡可能性)
    監査で求められるデータとして提供
    透明性の⾼いデータを関係者で共有
    トークンエコノミー
    (新しい経済圏)
    分散型システム
    中央管理者不要による運⽤コスト削減
    複数関係者でエコシステムを構築
    トークン化でデジタルデータに価値を
    法定通貨を超え世界中で利⽤可能
    web3 への対応
    ⾃律分散型に適したアーキテクチャ
    NFT / DAO / メタバースの実⾏基盤
    データベースではなく、ブロックチェーンにする意義とは

    View full-size slide

  5. ブロックチェーンの種類
    パブリック型 プライベート(パーミッションド:許可型)
    管理形態 管理者が存在しない・⾃由参加 管理者が存在する・許可制
    不特定多数が
    ⾃由に参加可能
    許可された⼈
    のみ参加可能
    合意形成
    アルゴリズム

    PoW(Proof of Work)、PoS(Proof of Stake)等 BFT(Byzantine Fault Tolerance)等
    ビットコイン、イーサリアム等
    Hyperledger Fabric、
    Quorum、Corda等

    View full-size slide

  6. ブロックチェーンの合意形成アルゴリズム
    PoW(Proof of Work) BFT(Byzantine Fault Tolerance)
    仕組み
    • 最初にブロックを⽣成する計算を完成させた⼈に報酬
    (処理速度が遅く、消費電⼒が⼤きい)
    • 多数決による合意形成(過半数ノードの承認でブロック作成)
    耐障害性
    拡張例 PoS (Proof of Stake):コイン保有量により作成権を得る⽅式
    PoA(Proof of Authority):事前承認により作成権を得る⽅式
    PBFT、IBFT
    トランザクション
    ナンス
    前ブロックのハッシュ
    ハッシュ値計算
    トランザクション
    ナンス
    前ブロックのハッシュ
    ⼀番⼩さいハッシュ値になる
    ナンスを計算(=マイニング)
    • リーダーが転送したトランザクションをメンバーで検証・承認
    ノード故障や不正ノードがあっても問題なく合意形成を⾏う
    • マイニング作業は存在しない(⾼速な処理が可能)
    • ノードの障害は考慮不要
    • 「善良なノード」が多いことを前提にした改ざん耐性
    (改ざんしたブロックの計算速度が間に合わない)
    • ノード故障を何台まで許容するか考慮が必要(1/3 まで等)
    • リーダーによるファイナリティを得られることでの改ざん耐性
    リーダー
    メンバー 1
    メンバー 2
    メンバー 3
    準備 検証 実⾏
    コミット
    改ざんの有無をチェック

    View full-size slide

  7. ブロックチェーンの
    ユースケース
    7

    View full-size slide

  8. 8
    ブロックチェーンのビジネスモデルパターン
    l ブロックチェーン上のデータに価
    値をつけ、ユーザー間でトークン
    による売買を⾏う(NFT など)
    • マーケット
    l ブロックチェーン上に情報を記録
    し、必要に応じて取得できる
    l トレーサビリティ、改ざん不可
    l ⾮中央集権化により管理者不在でも
    信頼性を担保
    l スマートコントラクトによる⾃動化
    • 共有・可視化
    • トラストレス
    × ×

    View full-size slide

  9. ブロックチェーン
    9
    ユースケース①:契約
    業種 ⾦融・不動産
    パターン トラストレス
    売却者 購⼊者 仲介者
    • ⼿数料や契約に関する書類作業コストが掛か
    らない
    • ⼿数料や契約に関する書類作業コストが掛か
    らない
    • 低コストな管理
    • 詐欺などの防⽌
    不動産
    購⼊者
    ⾦融商品
    送⾦
    登記情報
    l ⾦融商品、不動産などの⼤量の
    ペーパーワークをブロック
    チェーンで簡略化
    l スマートコントラクトにより、
    仲介なしで安全に⾃動契約
    売却者
    権利移動
    同期 同期
    取引情報

    View full-size slide

  10. ブロックチェーン
    10
    ユースケース②:サプライチェーン
    業種 製造・流通
    パターン 共有・可視化
    消費者 販売店 製造業者
    • 製造〜⼿元に届くまでが可視化され、安全性
    を確認できる
    • サプライチェーンに関わる業者の偽装を防御 • 共有データベースによるコスト削減
    材料
    消費者
    製造 流通 販売
    購⼊
    l 商品が製造され、消費者の⼿元に
    届くまでのサプライチェーンを
    可視化
    l 各事業者が個別に保持していた
    データベースをブロックチェーン
    化することで統合管理が可能に
    材料ID 加⼯情報 流通情報 販売情報
    必要な情報に
    アクセス可能

    View full-size slide

  11. 11
    ユースケース③:証書発⾏
    業種 ⽂教(⼤学)
    パターン 共有・可視化
    ⼤学 学⽣/卒業⽣ 企業(採⽤担当)
    • 学位情報の安全な保管
    • 証書発⾏の作業コスト削減
    • いつでも証書発⾏できる利便性 • 信頼できる提供元からの証書⼊⼿
    企業
    情報開⽰リクエスト
    学⽣/卒業⽣
    アクセス許可
    ブロックチェーン
    学⽣/卒業⽣
    学位情報 学位情報
    l 卒業証書をデジタル化して
    ブロックチェーンに保管
    l 企業の採⽤担当や卒業⽣が
    必要なタイミングで信頼の
    おける証書を⼊⼿可能
    ⼤学 ⼤学
    いつでも
    ⼊⼿

    View full-size slide

  12. ブロックチェーン(プラットフォーム)
    12
    ユースケース④:マーケット(NFT)
    業種 コマーシャル
    パターン マーケット
    企業(マーケット運営) クリエーター ユーザー
    • ⾃社のコンテンツを流通、利⽤料の収益
    • 次世代クリエーターの発掘
    • 作成したコンテンツを販売でき、⼆次流通
    (中古)でも報酬を受けとれる
    • 唯⼀性のあるコンテンツを購⼊し、ユーザー
    間での交換も可能
    企業
    ユーザー B
    クリエイター
    コンテンツ
    l アート、⾳楽、ゲーム内アイテム
    などのコンテンツをトークンとし
    てプラットフォームに登録
    l ユーザー間でコンテンツを売買し
    たり、次世代クリエーターの発掘
    を⾏う
    コンテンツ
    ユーザー A
    購⼊(⼆次流通)
    購⼊(⼀次流通)
    販売 販売
    報酬

    View full-size slide

  13. 13
    ユースケース⑤:環境価値取引(電⼒)
    業種 エネルギー
    パターン マーケット
    電⼒会社 プロシューマー ⼀般家庭
    • 仲介者不在によるコスト削減 • 余剰電⼒の売却利益 • 電気料⾦の低コスト化
    ⼀般家庭
    電⼒取引
    l ⼀般家庭の太陽光発電などの再⽣
    エネルギーをトークン化
    l P2Pの電⼒取引(マイクログリッ
    ド)を分散台帳で実現
    購⼊
    電⼒販売
    電⼒会社
    ブロックチェーン
    ⼀般家庭
    報酬
    個⼈間の電⼒供給(マイクログリッド)
    プロシューマー
    (⼀般家庭)
    電⼒取引
    余剰電⼒

    View full-size slide

  14. 14
    ユースケース⑥:環境価値取引(カーボン)
    業種 エネルギー
    パターン マーケット
    企業(環境価値創出) 個⼈(環境価値創出) 企業(購⼊者)
    • カーボンクレジット売却による利益
    • 電⼒市場への参⼊
    • カーボンクレジット売却による利益 • SDGs貢献によるイメージ向上
    カーボン
    クレジット
    l 脱炭素化の要求に対応する
    カーボンクジレット(CO2排出量
    の削減による環境価値)の取引
    l IoTの活⽤により、モニタリング
    を効率化
    l スマートコントラクトによる
    ⾃動取引(⼿続きの簡略化)
    購⼊
    CO2削減量
    企業
    環境データ
    ブロックチェーン
    ⼀般家庭
    カーボン
    クレジット
    CO2削減量
    IoT
    (モニタリング)
    環境価値取引市場
    企業
    需要者と創出者による資⾦循環

    View full-size slide

  15. 15
    ユースケース⑦:IoT × ブロックチェーン
    業種 コマーシャル
    パターン 共有・可視化
    IoT デバイス エッジコンピューティング ユーザー/AI プラットフォーム
    • 収集したデータを分散型で安全に保管
    • データ共有してオープンに活⽤
    • 加⼯したデータを分散型で安全に保管
    • データ共有してオープンに活⽤
    • 信頼性が担保されたデータを利活⽤
    • 複雑なデータ管理が不要
    センサー
    データ
    l IoTで収集したデータをブロック
    チェーンに保管することで改ざん
    されていないことを証明
    l 分散型で共有することで、透明性
    のあるデータ活⽤が可能
    l IoTデバイスを連携させて即時決
    済するマイクロペイメントの実現
    データ
    利⽤
    ユーザー
    ブロックチェーン
    センサー
    データ
    IoTデバイス
    データ
    分析
    AI プラットフォーム
    センサー
    データ
    加⼯
    データ
    エッジコンピューティング
    データ収集

    View full-size slide

  16. 16
    ユースケース⑧:AI × ブロックチェーン
    業種 コマーシャル
    パターン 共有・可視化
    AI プラットフォーム ユーザー ロボット等(AI 実装対象)
    • AIが⽣成したデータをブロックチェーンに保
    管することで改ざんを防⽌
    • 信頼性が担保されたデータを利活⽤ • 実⾏履歴を保管することで監査性を向上
    学習
    データ
    l AIが⽣成したデータの信頼性をブ
    ロックチェーンで担保
    l 異なるAI モデル間のデータ共有
    を安全に実施
    データ
    活⽤
    ユーザー
    ブロックチェーン
    学習
    データ
    AI実装
    AI プラットフォーム ロボット等
    実⾏履歴 実⾏履歴

    View full-size slide

  17. 17
    ユースケース:ポイントプログラム
    企業(ポイント管理) 企業(ポイント提携先) ユーザー
    • ポイントの⼀元管理が可能
    • 分散処理による性能が安定したポイント処理
    • 台帳を共有することで、他システム・他社を
    またいだ共通ポイント基盤を構築可能
    • ポイント使い分けが不要に
    • ポイントを安全に管理(不正操作防⽌)
    企業 提携先
    ポイント
    ⼝座
    l ポイント管理システムをブロック
    チェーンに構築(スマートコント
    ラクトでポイント⾃動付与)
    l ユーザーが⾃由に参照・交換可能
    l 提携先とのポイント交換が容易に
    ポイント
    ⼝座
    ユーザー
    ポイント
    参照・利⽤
    ポイント付与 ポイント付与
    ポイント交換
    ポイント
    獲得
    ブロックチェーン
    業種 コマーシャル
    パターン マーケット

    View full-size slide

  18. web3
    ブロックチェーンと web3 の関係
    DAO
    スマートコントラクト
    デジタル通貨 NFT
    DeFi
    メタバース
    NFT
    マーケット
    意思決定
    流通
    企業
    ユーザー
    クリエイター
    企業
    イーサリアム (プラットフォーム)
    ブロックチェーン技術

    View full-size slide

  19. イーサリアムの
    データ構造について
    19

    View full-size slide

  20. イーサリアム全体のアーキテクチャ
    • 以下の Qiita 記事も参照ください
    https://qiita.com/katsuyaom86/items/4b1aa63224a69753392a
    20

    View full-size slide

  21. イーサリアムのデータ構造
    イーサリアムのデータ構造には「マークルパトリシアツリー」が使われている
    マークルツリーとは?
    • データを要約した結果を格納するツリー構造のこと
    • 2つのデータのハッシュ値をひとつにまとめる
    • 1つ値が変わると全体に影響(改ざん検知が容易)
    パトリシアツリーとは?
    • マークルツリーの探索を容易にする仕組み
    • 簡単に⾔うと…⼀つの⽂字ではなく⽂字列をラベル
    として付与する(共通の⽂字がある場合に⾼速)
    マークルルート
    データA データB データA データB
    Aのハッシュ Bのハッシュ Cのハッシュ Dのハッシュ
    ABのハッシュ CDのハッシュ
    要約
    要約
    パトリシアツリー
    だと…
    d o g
    c
    c a t
    p
    do g
    c
    ca t
    p
    21

    View full-size slide

  22. ブロックチェーンのデータ構造
    ブロック
    https://www.etarou.work/posts/4979138
    ワールドステート
    トランザクションのリスト
    トランザクション
    トランザクション
    ブロックのヘッダー
    前のブロックのハッシュ
    ステートの要約(Hash)
    l ブロックにはトランザクションとヘッダー
    が含まれる
    l ヘッダーには前のブロックのハッシュが
    ありチェーンをつないでいる
    l ワールドステートの要約が「マークルパト
    リシアツリー」で格納されている
    l ワールドステートに全アカウントの状態が
    格納されている
    l 各アカウントがもつデータの要約が「マー
    クルパトリシアツリー」で格納されている
    ブロック + 1
    トランザクションのリスト
    トランザクション
    トランザクション
    ブロックのヘッダー
    前のブロックのハッシュ
    ステートの要約(Hash)
    アカウントのステート
    ストレージの要約(Hash)
    ワールドステート
    アカウントのステート
    ストレージの要約(Hash)
    22

    View full-size slide

  23. ブロックのデータ構造:ステートの要約
    ブロック
    トランザクションのリスト
    トランザクション
    トランザクション
    ブロックのヘッダー
    stateRoot transactionsRoot receiptsRoot
    ワールドステートの要約 トランザクションの要約 レシート(結果)の要約
    ブロックのヘッダーにある3つの要約
    23

    View full-size slide

  24. ブロックのデータ構造:ストレージの要約
    ワールドステート
    コントラクトアカウント
    アドレス ステート
    ナンス
    バランス(残⾼)
    storageRoot
    コードHash
    アカウント
    ステート
    stateRoot
    配列
    アカウントに保存されるデータの要約
    Key (Address) Value (Balance)
    0x00000000... 0
    0x121200000.... 100
    0x242400000... 500
    0x36360000... 2000
    Key-Value 形式のストア
    24

    View full-size slide

  25. リレーショナル DB と Key-Value ストアの違い
    リレーショナルDB Key-Value ストア
    https://atmarkit.itmedia.co.jp/ait/articles/0907/02/news101.html
    • テーブル(表)形式でデータを保存
    • 複雑な条件検索や集計処理が得意
    • 負荷分散やスケールアウトが苦⼿(難しい)
    • キーと値の組み合わせでデータを保存(分散配置)
    • シンプルな問い合わせが可能で、スケーラビリティ
    が⾼いためブロックチェーンで⼀般的に使われる
    key value
    key value
    key value
    key value
    key value
    key value
    key value
    key value
    25

    View full-size slide

  26. l マークルパトリシアツリー には 4 種類のノードが存在する
    l NULLノード(初期状態)
    l ブランチノード(枝分かれ)
    l リーフノード(ツリーの末端。value値を持つ)
    l エクテンションノード(⼦ノードへのポインタを持つ)
    コードの実⾏:Key-Value Store への操作
    コントラクトアカウント
    アドレス ステート
    ナンス
    バランス(残⾼)
    storageRoot
    コードHash
    EVMコード
    トランザクション
    Message Call
    コードの実⾏
    データを変更
    データを読取
    (補⾜)実際には...
    26

    View full-size slide

  27. Solidity で実際の動きを確認する
    Solidity 公式のサンプルコード:https://solidity-by-example.org/app/merkle-tree/
    マークルツリーの leaf(葉) から
    計算した root のハッシュ値が
    正しいか検証するサンプルコード
    ※ちなみに、単純なトランザクションの取得だけであれば、
    web3.js ライブラリを使って簡単に実⾏できる
    実⾏例:
    web3.eth.getTransaction(ʻトランザクションハッシュ')27

    View full-size slide

  28. オラクル問題
    • オラクル問題:
    • リアル世界のデータをブロックチェーンに変換するポイントでの信頼性担保をどうするか
    • 解決⼿段:「Chainlink」など
    • オンチェーンとオフチェーンという2つの異なる環境の橋渡しする
    • レピュテーションコントラクトによって、正しい情報を提供したオラクルノードの評価スコアを
    上げる仕組み(報酬としてLINKトークンを付与)
    28

    View full-size slide

  29. DApps (分散アプリ)の
    全体イメージ
    Web 2.0 アプリとの違い
    29

    View full-size slide

  30. Web 3.0
    Web 2.0
    Web 2.0 アプリと Web 3.0 アプリの違い
    フロントエンド
    ( HTML / JavaScript )
    ʻ
    バックエンド
    (実⾏環境)
    イーサリアム
    クライアント
    (Provider)
    https://medium.com/the-graph-protocol-japan/web-3-0アプリケーションのアーキテクチャ-e796d73e24bd/
    DB
    Web 2.0
    Web 2.0
    Web 3.0
    フロントエンド
    ( HTML / JavaScript )
    ブロックチェーンネットワーク
    スマートコントラクト
    ブロック
    30
    ʻ

    View full-size slide

  31. Web 3.0
    Web 2.0
    Web 3.0 : DApps(分散アプリ) の全体イメージ
    フロントエンド
    (HTML / JavaScript)
    ユーザー
    ウォレット
    MetaMask など
    React / Angular / Vue など
    バックエンド
    (実⾏環境)
    Node.js など
    ブロックチェーンネットワーク
    アプリ利⽤
    スマートコントラクト
    連携(Web3Provider)
    スマートコントラクト操作
    Web3.js / Ethers.js
    https://medium.com/the-graph-protocol-japan/web-3-0アプリケーションのアーキテクチャ-e796d73e24bd/
    アカウント管理
    RPC接続
    ※DApps における
    バックエンド側に相当 Solidity など
    31
    ʻ

    View full-size slide

  32. 開発環境
    スマートコントラクトが実装されるまでの流れ
    開発フレームワーク
    Remix / HardHat / Truffle
    スマートコントラクト
    (Solidity⾔語で作成)
    ローカルPC
    ソースコードのコンパイル
    l SolidityファイルをEthereum Virtual Machine(EVM)バ
    イトコードに変換
    l スマートコントラクトを実⾏可能なバイナリにする
    コンパイル デプロイ 接続
    32

    View full-size slide

  33. 開発環境 ブロックチェーンネットワーク
    スマートコントラクトが実装されるまでの流れ
    開発フレームワーク
    Remix / HardHat / Truffle
    スマートコントラクト
    (Solidity⾔語で作成)
    コントラクトの新しいアドレスが作成される
    内部状態を保持するストレージ部分、
    実⾏コード(EVMコード)を持つ
    ワールドステート
    コントラクトアカウント
    EVMコード
    アドレス ステート
    ローカルPC
    スマートコントラクトのデプロイ
    l コンパイルしたバイトコード
    をEVM に移⾏
    l ネットワークにコントラクト
    をデプロイ
    コンパイル デプロイ 接続
    33

    View full-size slide

  34. ブロックチェーンネットワーク
    スマートコントラクトが実装されるまでの流れ
    ワールドステート
    コントラクトアカウント
    EVMコード
    アドレス ステート
    Web3 クライアントからの接続
    l Web3.js やEthers.js などの
    イーサリアムクライアント
    ライブラリを使⽤
    l スマートコントラクトに接続
    し、各種コントラクト関数を
    呼び出す
    イーサリアムクライアント
    スマートコントラクト操作
    Web3.js / Ethers.js
    コンパイル デプロイ 接続
    34

    View full-size slide

  35. EVM(Ethereum Virtual Machine )とは
    • EVMはスマートコントラクトのランタイム環境
    • EVMコードはEVMで実⾏される
    • ⼀時的なメモリで動作(トランザクション中のみ持続)
    • イーサリアムノード上にEVMが実装されている
    35

    View full-size slide

  36. スマートコントラクトの
    実装
    Remix
    36

    View full-size slide

  37. Remix を使ったスマートコントラクトの実装
    コントラクトの作成とコンパイル
    l Solidity ファイル(.sol)を作成
    l メッセージ格納⽤の関数を記載
    l Remix でコンパイル実⾏
    MetaMask
    ウォレット
    Remix
    IDE(開発環境)
    スマートコントラクト
    (Solidity⾔語で作成)
    BCネットワーク
    RPC
    URL
    pragma solidity >=0.7.0 <0.8.0;
    contract Message {
    string message;
    function store(string memory msg_in) public {
    message = msg_in;
    }
    function retrieve() public view returns (string memory){
    return message;
    }
    }
    37

    View full-size slide

  38. Remix を使ったスマートコントラクトの実装
    コントラクトのデプロイ
    l Remix でデプロイ実⾏
    l Injected Web3を指定することで、MetaMask経由で
    ネットワークに接続が可能
    MetaMask
    ウォレット
    Remix
    IDE(開発環境)
    スマートコントラクト
    (Solidity⾔語で作成)
    BCネットワーク
    RPC
    URL
    const hre = require("hardhat");
    async function main() {
    const Greeter = await hre.ethers.getContractFactory("Greeter");
    const greeter = await Greeter.deploy();
    await greeter.deployed();
    console.log("Greeter deployed to:", greeter.address);
    }
    ※HardHat の場合は、deploy.js に以下の様な記述が必要
    38

    View full-size slide

  39. AWS
    Remix + Metamask のスマートコントラクト実装イメージ
    ネットワーク接続
    ローカルPC
    ブラウザ
    (Chrome)
    拡張機能
    MetaMask
    ウォレット
    連携
    (Injected Web3)
    ウォレットを経由してネットワーク
    上にコントラクトをデプロイ可能
    ブラウザ接続
    Remixでコントラクトを
    コンパイル、デプロイ
    Remix
    IDE(開発環境)
    スマートコントラクト
    (Solidity⾔語で作成)
    BC
    ネットワーク
    RPC
    URL
    39

    View full-size slide

  40. スマートコントラクトの
    実装
    Hardhat
    40

    View full-size slide

  41. Hardhat を使ったスマートコントラクトの実装
    l パッケージマネージャー(npm / yarn) を
    インストール
    l Hardhat のプロジェクトを作成
    (TypeScript のテンプレートが作成される)
    l 付属のブロックチェーンノードをローカルで
    実⾏することも可能
    l フロントエンドを起動
    (Provider で設定した Metamask と接続)
    hardhat
    ├─README.md
    ├─ contracts
    │ └─ Greeter.sol
    ├─ hardhat.config.js
    ├─ package.json
    ├─ scripts
    │ └─ deploy.js
    └─ test
    │ └─ indext.ts
    └─ tsconfig.json
    ※サンプルプロジェクトのディレクトリ構成
    コントラクト本体(Solidity)
    Hardhat 設定ファイル
    (デプロイ先のネットワークを指定)
    デプロイ⽤のスクリプト
    (hardhat.config.js で設定した
    ネットワークを指定して実⾏する)
    パッケージ全体の設定ファイル
    (起動時オプションの指定)
    TypeScript 設定ファイル
    (コンパイルオプションなど)
    https://zenn.dev/ktechb/articles/66a80c3640a3e3
    41

    View full-size slide

  42. 開発環境
    Hardhat のスマートコントラクト実装イメージ
    MetaMask
    ローカルPC
    ブラウザ
    (Chrome)
    拡張機能
    ウォレット
    Hardhat
    IDE(開発環境)
    スマートコントラクト
    (Solidity⾔語で作成)
    ネットワーク接続
    Hardhat
    ローカル
    ネットワーク
    パッケージマネージャ(nvm / yarn)
    Ubuntu OS
    フロントエンド
    (React App)
    実⾏環境(Node.js)
    local
    host
    ʻ
    ノード作成
    RPC
    URL
    ライブラリ(ethers.js)が拡張
    機能を読み取ってMetaMask
    経由でコントラクトと通信
    コントラクト
    操作アプリ
    コントラクト
    デプロイ
    連携
    (Web3Provider)
    Webアプリ利⽤
    https://zenn.dev/linnefromice/articles/create-simple-dapps-with-hardhat-and-react-ts
    42

    View full-size slide

  43. スマートコントラクトの
    操作
    43

    View full-size slide

  44. コントラクトを操作するインターフェイス(Webアプリ)の作成
    l フロントエンド(HTML)にイーサリアムクライアント
    ライブラリ(Web3.js / Ethers.js)を読み込む
    l ブロックチェーンノードと通信をするための
    Provider オブジェクトを作成
    l スマートコントラクトにアクセスするためには以下が必要
    l コントラクトアドレス:
    (ブロックチェーンにデプロイされたアドレス)
    l ABI(Application Binary Interface):
    コントラクトの取り扱い説明書
    (コントラクトに渡す型やパラメータの定義)
    イーサリアムクライアント
    Web3.js / Ethers.js
    フロントエンド
    HTML / JavaScript
    BCネットワーク
    スマートコントラクト
    ・コントラクトアドレス
    ・ABI
    ライブラリ利⽤
    Provider
    44

    View full-size slide

  45. 補⾜)ABI(Application Binary Interface)について
    l スマートコントラクトをコンパイルしたときに⾃動⽣成
    l JSON ファイル形式で保存される
    l Remix:コンパイル後の画⾯でコピー可能
    l Hardhat:artifacts/ディレクトリ配下に保存
    > myContract.abi
    [{
    constant: false,
    inputs: [{...}],
    name: "set",
    outputs: [],
    payable: false,
    stateMutability: "nonpayable",
    type: "function"
    }, {
    constant: true,
    inputs: [],
    name: "get",
    outputs: [{...}],
    payable: false,
    stateMutability: "view",
    type: "function"
    }]
    ※ABI のサンプル
    // ABIの指定
    import artifact from "./abi/Greeter.json";
    // コントラクトアドレスの指定
    const contractAddress = "0x5F..."
    // Provider の作成
    const provider = new ethers.providers.JsonRpcProvider();
    // Contract への接続
    const contract = new ethers.Contract(contractAddress, artifact.abi, provider);
    45

    View full-size slide

  46. 補⾜)Ethers.js で使えるAPI
    ウォレット
    MetaMask など
    ブロックチェーンネットワーク
    スマートコントラクト
    連携(Web3Provider)
    スマートコントラクト操作
    Web3.js / Ethers.js
    RPC接続
    Solidity など
    https://zenn.dev/nft/books/410be300912936/viewer/00c605
    デプロイされたコントラクトを
    操作する
    (関数呼び出し、データ取得)
    ethers.contract
    ブロックチェーンネットワークへの接続を確⽴
    この Provider を介してクエリ発⾏を⾏う
    ethers.provider
    ethers.utils
    データのフォーマットやユーザ⼊⼒を処理するための
    ユーティリティ関数
    ethers.provider.getBalance()
    :残⾼取得
    ethers.provider.getBlockNumber()
    :ブロック番号取得
    ethers.utils.getContractAddress()
    :スマートコントラクトのアドレスを取得
    ethers.utils.formatEther()
    :ETHの値を⼈間が理解できる10 進数に変換
    46

    View full-size slide

  47. DApps 技術構成のまとめ
    • Web2.0(従来のWebアプリ)部分の実装が⼤部分を占める
    47
    Web アプリ
    開発⾔語 TypeScript
    フレームワーク React、Angular
    バックエンド Node.js
    Web2-Web3 Bridge Ethers.js / Web3.js
    https://zenn.dev/nft/articles/dapps-technical-structure
    スマートコントラクト
    開発⾔語 Solidity
    フレームワーク Hardhat / Remix / Truffle
    DApps 開発ライブラリ OpenZeppelin
    RPC URL ノード(VMBCなど)
    Ethers.js
    コンパクトでパフォーマンスが⾼い
    最近⼈気が⾼まっており現在の主流
    テストケースが豊富に⽤意されている
    Web3.js
    イーサリアム財団のプロジェクトであり、歴史が⻑い
    GitHubのメンテナーも多い
    ブロックチェーン上のデータを
    操作するためのライブラリ

    View full-size slide

  48. NFT の概要
    基本的な仕組みと規格
    48

    View full-size slide

  49. • NFT はインデックス、メタデータ、実際のデジタル
    データの3階層のデータ構造になっている
    • インデックス:NFTの固有の識別⼦
    • メタデータ:NFTに関する情報を記述(JSON形式)
    NFT の概要
    NFT とは
    • Non-Fungible Token(⾮代替性トークン)は、
    デジタルデータに唯⼀性と所有権を付与する技術
    • ブロックチェーン技術を⽤いて発⾏され、取引履歴
    や権利関係が改ざん不可能に記録される
    • デジタル資産に新たな付加価値を与えられるため、
    様々なコンテンツでのNFT 化が注⽬されている
    NFT のデータ構造
    FT
    (代替できる)
    NFT
    (代替できない)
    ×
    インデックス
    トークン ID
    トークン URI
    所有者 アドレス
    メタデータ
    NFT の名前
    NFT の説明
    コンテンツの URL
    オンチェーン オフチェーン(IPFSなどのストレージ)
    49

    View full-size slide

  50. NFT の規格
    • 代表的な 2 つの規格
    ERC-721
    • Ethereum上で⾮代替性トークン(NFT)を発⾏するための標準規格
    • NFTは、⼀意で代替不可能なデジタルアイテム(画像、動画、⾳声など)のこと
    • ひとつひとつのトークンに「トークンID」を割り振ることで、トークン同⼠を区別
    • NFTのタイプ情報や名前、画像のURLなどのメタデータをNFTに付与する
    ERC-1155
    • Ethereum上で代替性トークン(仮想通貨)と⾮代替性トークン(NFT)を
    同時に発⾏するための標準規格
    • ⼀つのスマートコントラクト内に複数種類のトークンを定義することができ、
    ⼀度の取引処理で複数個・複数種類のトークンを送信することが可能
    • ゲームアイテムやコレクションカードなどを効率的に管理するために使われる
    +
    50

    View full-size slide

  51. 51
    NFT のユースケースの変化
    コレクション
    コミュニティ
    メンバーシップ
    アート
    ランダム⽣成の希少性
    の⾼い絵柄を集める
    ゲーム
    装備や⼟地を購⼊してキャ
    ラクターをアップデート
    会員証
    所有者のみの特典や
    優先購⼊権の付与
    チケット
    購⼊者向けに特別な体験
    転売対策の強化
    地域創⽣
    デジタル住⺠票、地域の
    特⾊PRによる活性化
    メタバース
    デジタル空間のアイテム
    をリアル世界に転換

    View full-size slide

  52. NFT の規格
    • ERC-721 と ERC-1155 の違い
    項⽬ ERC-721 ERC-1155
    トークンID ⼀つのコントラクトに対して⼀意に割り当て
    ⼀つのコントラクトに対して複数のトークンIDを
    持つことができる
    トークン数 ⼀つのトークンIDに対して⼀つのトークンのみ存在
    ⼀つのトークンIDに対して複数のトークンを
    発⾏することができる
    転送⽅法 ⼀度に⼀つのトークンしか転送できない
    複数の異なるトークンIDと数量をまとめて転送する
    ことができる
    ガスコスト 転送ごとに⾼いガスコストがかかる
    複数のトークンをまとめて転送することで
    ガスコストを削減できる
    • 「個別性」や「希少性」が⾼い NFTにしたい → ERC-721
    • 「多様性」や「効率性」が求められる NFT → ERC-1155
    52

    View full-size slide

  53. NFT(ERC-721) の全体アーキテクチャ
    Owner
    デジタル
    コンテンツ
    ⽣成
    NFT プラットフォーム
    作成 登録
    デジタル
    コンテンツ
    User
    外部アカウント連携
    NFT
    ブロックチェーン
    ERC-721 スマートコントラクト
    転送
    購⼊
    (権利移転)
    NFT
    Token ID
    Token URI
    Owner Address
    NFTのデータ構造
    https://tech.nri-net.com/entry/how_nft_work
    MetaMask
    ウォレット
    MetaMask
    ウォレット
    File URL
    IPFS or ファイルサーバ
    ブロックチェーンで
    NFT の所有権を管理
    (転送されたら
    Owner Addressを
    書き換える)
    53

    View full-size slide

  54. OpenZeppelin とは
    l ERC-20 / ERC-721 のスマートコントラクトを実装する
    ためのライブラリ
    l コミュニティでテスト・メンテナンスされており、セ
    キュアにメソッドを扱える
    l 公式の Contract Wizard(右図)で
    各トークンで使いたい機能セットの
    サンプルコードを⾃動⽣成できる
    https://www.openzeppelin.com/contracts
    54

    View full-size slide

  55. OpenZeppelin Wizard で NFT コントラクトをデプロイ
    https://xtech.nikkei.com/atcl/nxt/column/18/00160/011700338/
    Mint (NFT 発⾏)を許可する
    Mint の度に ID を1ずつ上げる
    トークン URI (画像の場所)
    を指定する
    発⾏された NFT を列挙する
    作成したコードを Remix で
    開いてデプロイする
    デプロイ後のコントラクトで
    送付先アドレスとURI を指定して Mint
    55

    View full-size slide

  56. デモアプリの
    アーキテクチャ検討
    サンプルアプリからのカスタマイズ⽅法
    56

    View full-size slide

  57. デモアプリのアーキテクチャ設計の進め⽅
    Step 2 Step 3
    Step 1
    • サンプルアプリを触ってみる
    • 簡易的な変更(⾒た⽬の変更)を
    試してみる
    • Angular ハンズオン
    (クラウドIDEでHello World)
    • NFT 化する既存業務をフロー化
    • 登場⼈物の洗い出し
    • Input / Output の洗い出し
    • NFT アプリのモック(イメージ図)
    を作成
    • Step 2 を踏まえて NFT アプリを
    カスタマイズ
    • モックから1画⾯ずつ作成
    • Angular アプリ構成の理解
    • サンプルアプリカスタマイズ
    (軽微なビジュアル変更)
    • 業務フロー図(既存)
    • UI モック(Miro?)
    • 業務フロー図(NFT アプリ版)
    • サンプルアプリカスタマイズ
    (Step 2 反映)
    サンプルアプリに慣れる 既存フローの整理&モック作成 NFT アプリ向けに洗練
    57

    View full-size slide

  58. デモアプリのアーキテクチャ設計
    Step 1
    • サンプルアプリを触ってみる
    • 簡易的な変更(⾒た⽬の変更)を
    試してみる
    • Angular ハンズオン
    (クラウド IDE で Hello World)
    • Angular アプリ構成の理解
    • サンプルアプリカスタマイズ
    (軽微なビジュアル変更)
    サンプルアプリに慣れる
    サンプルアプリ(NFT Platform)の実⾏環境の⽤意
    Angular のファイル構成を理解する
    ・別途 Tech セッションでインストール⽅法を説明
    ・⼀通りの画⾯を触り、UI 変更イメージを膨らませる
    サンプルアプリ⾒た⽬カスタマイズ
    ・基本的なファイル構成と変更対象の
    ファイルがどれかを確認
    ・公式チュートリアルを試す
    ・どこがどう連動するか触ってみる
    ・ラベルの張り替えだけ試してみる
    アウトプットイメージ
    58

    View full-size slide

  59. デモアプリのアーキテクチャ設計
    Step 2
    • NFT 化する既存業務をフロー化
    • 登場⼈物の洗い出し
    • Input / Output の洗い出し
    • NFT アプリのモック(イメージ図)
    を作成
    • 業務フロー図(既存)
    • UI モック(Miro?)
    既存フローの整理&モック作成
    アウトプットイメージ
    業務フロー図
    ・誰が何をするをストーリーで洗い出す
    ・インプット、アウトプットの関係性を
    ポインティングする
    UI モック
    ・フローが変わらず使えるのであれば、
    使いやすさにフォーカス
    ・カラーチャート、コーポレートカラー
    を揃えれば完成度⾼く⾒える
    59

    View full-size slide

  60. デモアプリのアーキテクチャ設計
    Step 3
    • Step 2 を踏まえて NFT アプリを
    カスタマイズ
    • モックから1画⾯ずつ作成
    • 業務フロー図(NFT アプリ版)
    • サンプルアプリカスタマイズ
    (Step 2 反映)
    NFT アプリ向けに洗練
    アウトプットイメージ
    業務フロー図(NFT版)
    ・NFT のライフサイクルを意識する
    ・必要ないもの、⾜りないものを選別して洗練させていく
    NFT issue
    NFT
    transport
    NFT
    redeem
    Data
    Integration
    UI
    Transaction of customer use-case / Tasks
    Org..
    Digital
    arts
    ERP
    Approv
    al
    Business Process/Operation
    60

    View full-size slide

  61. Angular 概要
    基本的なアプリ構成
    61

    View full-size slide

  62. Angular とは
    l JavaScript 系フレームワーク
    (ReactやVueと並ぶ)
    l 基本構成はモジュール型
    (コンポーネント等をまとめた機能セット)
    l コンポーネントでビュー (画⾯表⽰) を作成
    l アプリを起動するブートストラップは
    ルートモジュール(AppModule)と呼ぶ
    project / src
    ├─ app
    │ └─ app.component.ts
    │ └─ app.component.html
    │ └─ app.component.css
    │ └─ app.module.ts
    ├─ assets/
    ├─ environments/
    ├─ index.html
    ├─ main.ts
    └─ styles.sass
    project
    ├─ src/
    ├─ angular.json
    ├─ package.json
    ├─ node_modules
    └─ tsconfig.json
    Angular 設定ファイル
    (ビルドやデプロイの設定)
    HTMLテンプレート、セレクター、
    CSS スタイルを指定した
    Typescript クラスを定義する
    パッケージ全体の設定ファイル
    (起動時オプションの指定)
    TypeScript 設定ファイル
    (コンパイルオプションなど)
    画像や動画など起動時に
    読み込まれるリソース
    グローバルな設定ファイル
    複数環境向けの設定を格納
    ルートモジュール
    (コンポーネントをまとめて記載)
    62

    View full-size slide

  63. Angular アプリの基本構成
    index.html
    l index.html がトップページとして
    読み込まれる
    l app-root タグから
    app.component.ts が読み込まれる




    Artemis








    ルートコンポーネント
    app.component.ts で定義された
    タグとリンクする
    63

    View full-size slide

  64. Angular アプリの基本構成
    main.ts
    l Angular のスタートアップ
    l impot ⽂でモジュールをインポート
    (標準のモジュールを指定)
    l AppModule でメインのモジュール
    (app.module.ts)を読み込む
    import { enableProdMode } from '@angular/core';
    import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
    import { AppModule } from './app/app.module';
    import { environment } from './environments/environment';
    if (environment.production) {
    enableProdMode();
    }
    platformBrowserDynamic().bootstrapModule(AppModule)
    .catch(err => console.error(err));
    アプリの本体となるモジュール
    後述の app.module.ts で定義されている
    Angular の起動コマンド
    (前述のAppModuleを指定して実⾏)
    64

    View full-size slide

  65. Angular アプリの基本構成
    app.module.ts
    l impot ⽂でモジュールをインポート
    (標準のモジュール、読み込みたいコン
    ポーネントを指定)
    l @NgModule で使⽤するコンポーネント
    (AppComponentなど)を指定してモ
    ジュールを定義
    l クラスを宣⾔して外部参照可能に
    import { BrowserModule } from '@angular/platform-browser';
    import { NgModule } from '@angular/core';
    import { AppComponent } from './app.component';
    @NgModule({
    declarations: [
    AppComponent
    ],
    imports: [
    BrowserModule
    ],
    providers: [],
    bootstrap: [AppComponent]
    })
    export class AppModule { }
    最初に起動するコンポーネントを指定
    クラスとして定義することで外部から
    使⽤可能に(main.tsで読み込み)
    ルートコンポーネント
    実体は app.component.ts
    65

    View full-size slide

  66. Angular アプリの基本構成
    app.component.*
    l app.component.html
    l コンポーネントのテンプレート
    l app.component.css
    l コンポーネントのデザイン
    l app.component.ts
    l コンポーネントのロジック
    l @Component でコンポーネントを定
    義してクラス化
    Welcome to {{title}}!
    {{ }}で囲った⽂は app.component.ts
    で定義されたプロパティとリンクする
    app.component.html
    @Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.scss']
    })
    app.component.ts
    外部参照する際のタグ
    index.html で読み込まれる
    export class AppComponent { title = 'app'; }
    AppComponent の実体
    アプリ実装はここに書いてクラス化
    66

    View full-size slide

  67. Angular アプリの基本構成
    app.component.ts
    app.component.html
    app.component.css
    AppComponent
    index.html

    main.ts
    bootstrapModule
    app.module.ts
    AppModule
    その他コンポーネント
    (html, css, tsのセット)
    https://qiita.com/ksh-fthr/items/d040cf8b2d15bd7e507d#srcappappmodulets
    コンポーネント本体
    モジュール本体
    HTML 起動
    Angular 起動
    コンポーネント定義
    アプリの実体
    (主に実装を気にするところ)
    67

    View full-size slide

  68. Angular ハンズオン
    l 公式:https://angular.jp/start
    l モジュール、コンポーネント等の関連性が
    ⼀通り理解できるガイド
    1. ガイドに従って商品やボタンを追加してみる
    2. スタイルを変更してみる(style.css)
    • TOPページのデザインを変更(例)
    68

    View full-size slide

  69. ブロックチェーンの
    安全性について
    なぜ安全といえるのか?
    69

    View full-size slide

  70. ブロックチェーンの安全性:3つの柱
    Consensus
    (合意形成)
    Cryptography
    (暗号化)
    Immutability
    (変更不可)
    3つの仕組みで安全性を成⽴させている
    70

    View full-size slide

  71. ブロックチェーンの安全性:3つの柱
    Consensus
    (合意形成)
    Cryptography
    (暗号化)
    Immutability
    (変更不可)
    • ノードの障害や不正な操作があっても正しく処理する仕組み
    • PoW / PoS(パブリック)、BFT(プライベート)の違いは
    あるが同じ⽬的を達成する
    • 公開鍵暗号⽅式(ECDSA)による強固な暗号化
    • ウォレット=秘密鍵、アドレス=公開鍵からハッシュ⽣成
    • 送信者のトランザクションを秘密鍵でデジタル署名
    • ブロックには前のブロックのハッシュが含まれるため
    追加されたブロックは以後変更ができない
    • SHA-256ハッシュ関数により⼀⽅向の値(復元できない)
    パブリック・プライベートを問わず、ブロックチェーンの特性から安全性が得られる
    71

    View full-size slide

  72. ブロックチェーンのセキュリティ脅威マップ
    ブロックチェーンプラットフォーム
    台帳 ノード コンセンサス
    エコシステム
    ハード
    ウォレット
    スマートコントラクト
    コード
    EVM
    取引所
    開発
    プラットフォーム
    ストレージ
    ユーザ / DApps
    プライベート
    ウォレット
    Web /
    エンドポイント
    分散型⾦融
    サプライ
    チェーン
    NFT
    マーケット
    デジタル証書
    マルウェア
    秘密鍵の漏洩
    フィッシング
    DoS 攻撃
    コンセンサス集中
    攻撃
    ビサンチン不正
    ノード
    ⼆重⽀払い攻撃
    リエントランシー
    攻撃
    フロント
    ランニング攻撃
    DoS 攻撃
    プライバシー侵害
    プラットフォームで
    対処すべき脅威
    72

    View full-size slide

  73. ブロックチェーンの攻撃例
    プライベートブロックチェーンの場合
    51% 攻撃 シビル 攻撃 ダブルスペンディング 攻撃
    • ネットワーク全体のマシンパワーの
    総量の過半数を⼿に⼊れることで
    乗っ取り(別の枝分かれしたチェー
    ン作成)を⾏う
    • 不正に複数IDを作成し、あたかも
    多くのユーザがいるように⾒せかけ
    てネットワークに影響を与える
    • 同時に 2 つトランザクションを送信
    し、取引を無効化する
    • ファイナリティが必要だが、PoWは
    承認の待ち時間が課題に
    • ネットワーク参加者⾃体が許可制なため、過半数の悪意あるノードが現実的に存在しない
    (閉じられたネットワーク内で⼀部のノードに合意形成の権限を与えるなど)
    • コンセンサスアルゴリズム(BFT)の信頼性と、確実なファイナリティの機能が必要
    正しいチェーン
    不正チェーン
    73

    View full-size slide

  74. BFT( Byzantine Fault Tolerance ) の安全性
    ファイナリティ(取引の完了判断)
    ノードの最⼤ 1/3 がクラッシュもしくは悪意ある第三者
    に乗っ取られた場合でも機能性が維持されることを保証
    合意形成アルゴリズム
    Replica
    Replica
    Replica Replica
    Blockchain Network
    n = 3f + 1
    レプリカノードの
    必要台数
    許容可能な
    ノードの障害台数
    1台が故障しても残りの3台で
    合意形成が取れる(多数決ができる)
    リーダーノードによってブロックが⽣成されるため、
    ブロックチェーンが分岐することはない
    74

    View full-size slide