Blockchain関連 調べたことまとめ

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

Transcript

1. Blockchain 関連 調べたことまとめ ブロックチェーン基礎〜イーサリアム / Web3まで
2. ⽬次 • ブロックチェーンの基礎 • ブロックチェーンの利点・種類・合意形成アルゴリズム • ブロックチェーンのユースケース • ブロックチェーンのデータ構造（イーサリアムのワールドステート関連） • DApps（分散アプリ）の基礎 • DApps 全体イメージ（Web 2.0 アプリとの関係） • スマートコントラクトの実装（Remix / Hardhat） • スマートコントラクトの操作（Web3.js / Ethers.js） • NFT の基礎 • NFTの概要（規格 / アーキテクチャ） • デモアプリのアーキテクチャ設計 • Angular 概要（コンポーネントの基本構成） • ブロックチェーンのセキュリティ • 安全性はどのように確保されているのか 2
3. ブロックチェーンの基礎 3
4. 新規ビジネス ブロックチェーンの特性 システム的な⾯ Why ブロックチェーン？ 4 スマートコントラクト 契約処理の⾃動化によるコスト削減 ⼿作業を排除しデータの信憑性を確保 改ざん耐性 ブロックチェーンの仕組みによる特性 で、データの「正しさ」を証明 耐障害性の⾼さによる信頼性の向上 トレーサビリティ （追跡可能性） 監査で求められるデータとして提供 透明性の⾼いデータを関係者で共有 トークンエコノミー （新しい経済圏） 分散型システム 中央管理者不要による運⽤コスト削減 複数関係者でエコシステムを構築 トークン化でデジタルデータに価値を 法定通貨を超え世界中で利⽤可能 web3 への対応 ⾃律分散型に適したアーキテクチャ NFT / DAO / メタバースの実⾏基盤 データベースではなく、ブロックチェーンにする意義とは
5. ブロックチェーンの種類 パブリック型 プライベート（パーミッションド：許可型） 管理形態 管理者が存在しない・⾃由参加 管理者が存在する・許可制 不特定多数が ⾃由に参加可能 許可された⼈ のみ参加可能 合意形成 アルゴリズム 例 PoW（Proof of Work）、PoS（Proof of Stake）等 BFT（Byzantine Fault Tolerance）等 ビットコイン、イーサリアム等 Hyperledger Fabric、 Quorum、Corda等
6. ブロックチェーンの合意形成アルゴリズム PoW（Proof of Work） BFT（Byzantine Fault Tolerance） 仕組み • 最初にブロックを⽣成する計算を完成させた⼈に報酬 （処理速度が遅く、消費電⼒が⼤きい） • 多数決による合意形成（過半数ノードの承認でブロック作成） 耐障害性 拡張例 PoS （Proof of Stake）：コイン保有量により作成権を得る⽅式 PoA（Proof of Authority）：事前承認により作成権を得る⽅式 PBFT、IBFT トランザクション ナンス 前ブロックのハッシュ ハッシュ値計算 トランザクション ナンス 前ブロックのハッシュ ⼀番⼩さいハッシュ値になる ナンスを計算（＝マイニング） • リーダーが転送したトランザクションをメンバーで検証・承認 ノード故障や不正ノードがあっても問題なく合意形成を⾏う • マイニング作業は存在しない（⾼速な処理が可能） • ノードの障害は考慮不要 • 「善良なノード」が多いことを前提にした改ざん耐性 （改ざんしたブロックの計算速度が間に合わない） • ノード故障を何台まで許容するか考慮が必要（1/3 まで等） • リーダーによるファイナリティを得られることでの改ざん耐性 リーダー メンバー 1 メンバー 2 メンバー 3 準備 検証 実⾏ コミット 改ざんの有無をチェック
7. ブロックチェーンの ユースケース 7
8. 8 ブロックチェーンのビジネスモデルパターン l ブロックチェーン上のデータに価 値をつけ、ユーザー間でトークン による売買を⾏う（NFT など） • マーケット l ブロックチェーン上に情報を記録 し、必要に応じて取得できる l トレーサビリティ、改ざん不可 l ⾮中央集権化により管理者不在でも 信頼性を担保 l スマートコントラクトによる⾃動化 • 共有・可視化 • トラストレス × ×
9. ブロックチェーン 9 ユースケース①：契約 業種 ⾦融・不動産 パターン トラストレス 売却者 購⼊者 仲介者 • ⼿数料や契約に関する書類作業コストが掛か らない • ⼿数料や契約に関する書類作業コストが掛か らない • 低コストな管理 • 詐欺などの防⽌ 不動産 購⼊者 ⾦融商品 送⾦ 登記情報 l ⾦融商品、不動産などの⼤量の ペーパーワークをブロック チェーンで簡略化 l スマートコントラクトにより、 仲介なしで安全に⾃動契約 売却者 権利移動 同期 同期 取引情報
10. ブロックチェーン 10 ユースケース②：サプライチェーン 業種 製造・流通 パターン 共有・可視化 消費者 販売店 製造業者 • 製造〜⼿元に届くまでが可視化され、安全性 を確認できる • サプライチェーンに関わる業者の偽装を防御 • 共有データベースによるコスト削減 材料 消費者 製造 流通 販売 購⼊ l 商品が製造され、消費者の⼿元に 届くまでのサプライチェーンを 可視化 l 各事業者が個別に保持していた データベースをブロックチェーン 化することで統合管理が可能に 材料ID 加⼯情報 流通情報 販売情報 必要な情報に アクセス可能
11. 11 ユースケース③：証書発⾏ 業種 ⽂教（⼤学） パターン 共有・可視化 ⼤学 学⽣/卒業⽣ 企業（採⽤担当） • 学位情報の安全な保管 • 証書発⾏の作業コスト削減 • いつでも証書発⾏できる利便性 • 信頼できる提供元からの証書⼊⼿ 企業 情報開⽰リクエスト 学⽣/卒業⽣ アクセス許可 ブロックチェーン 学⽣/卒業⽣ 学位情報 学位情報 l 卒業証書をデジタル化して ブロックチェーンに保管 l 企業の採⽤担当や卒業⽣が 必要なタイミングで信頼の おける証書を⼊⼿可能 ⼤学 ⼤学 いつでも ⼊⼿
12. ブロックチェーン（プラットフォーム） 12 ユースケース④：マーケット（NFT） 業種 コマーシャル パターン マーケット 企業（マーケット運営） クリエーター ユーザー • ⾃社のコンテンツを流通、利⽤料の収益 • 次世代クリエーターの発掘 • 作成したコンテンツを販売でき、⼆次流通 （中古）でも報酬を受けとれる • 唯⼀性のあるコンテンツを購⼊し、ユーザー 間での交換も可能 企業 ユーザー B クリエイター コンテンツ l アート、⾳楽、ゲーム内アイテム などのコンテンツをトークンとし てプラットフォームに登録 l ユーザー間でコンテンツを売買し たり、次世代クリエーターの発掘 を⾏う コンテンツ ユーザー A 購⼊（⼆次流通） 購⼊（⼀次流通） 販売 販売 報酬
13. 13 ユースケース⑤：環境価値取引（電⼒） 業種 エネルギー パターン マーケット 電⼒会社 プロシューマー ⼀般家庭 • 仲介者不在によるコスト削減 • 余剰電⼒の売却利益 • 電気料⾦の低コスト化 ⼀般家庭 電⼒取引 l ⼀般家庭の太陽光発電などの再⽣ エネルギーをトークン化 l P2Pの電⼒取引（マイクログリッ ド）を分散台帳で実現 購⼊ 電⼒販売 電⼒会社 ブロックチェーン ⼀般家庭 報酬 個⼈間の電⼒供給（マイクログリッド） プロシューマー （⼀般家庭） 電⼒取引 余剰電⼒
14. 14 ユースケース⑥：環境価値取引（カーボン） 業種 エネルギー パターン マーケット 企業（環境価値創出） 個⼈（環境価値創出） 企業（購⼊者） • カーボンクレジット売却による利益 • 電⼒市場への参⼊ • カーボンクレジット売却による利益 • SDGs貢献によるイメージ向上 カーボン クレジット l 脱炭素化の要求に対応する カーボンクジレット（CO2排出量 の削減による環境価値）の取引 l IoTの活⽤により、モニタリング を効率化 l スマートコントラクトによる ⾃動取引（⼿続きの簡略化） 購⼊ CO2削減量 企業 環境データ ブロックチェーン ⼀般家庭 カーボン クレジット CO2削減量 IoT （モニタリング） 環境価値取引市場 企業 需要者と創出者による資⾦循環
15. 15 ユースケース⑦：IoT × ブロックチェーン 業種 コマーシャル パターン 共有・可視化 IoT デバイス エッジコンピューティング ユーザー／AI プラットフォーム • 収集したデータを分散型で安全に保管 • データ共有してオープンに活⽤ • 加⼯したデータを分散型で安全に保管 • データ共有してオープンに活⽤ • 信頼性が担保されたデータを利活⽤ • 複雑なデータ管理が不要 センサー データ l IoTで収集したデータをブロック チェーンに保管することで改ざん されていないことを証明 l 分散型で共有することで、透明性 のあるデータ活⽤が可能 l IoTデバイスを連携させて即時決 済するマイクロペイメントの実現 データ 利⽤ ユーザー ブロックチェーン センサー データ IoTデバイス データ 分析 AI プラットフォーム センサー データ 加⼯ データ エッジコンピューティング データ収集
16. 16 ユースケース⑧：AI × ブロックチェーン 業種 コマーシャル パターン 共有・可視化 AI プラットフォーム ユーザー ロボット等（AI 実装対象） • AIが⽣成したデータをブロックチェーンに保 管することで改ざんを防⽌ • 信頼性が担保されたデータを利活⽤ • 実⾏履歴を保管することで監査性を向上 学習 データ l AIが⽣成したデータの信頼性をブ ロックチェーンで担保 l 異なるAI モデル間のデータ共有 を安全に実施 データ 活⽤ ユーザー ブロックチェーン 学習 データ AI実装 AI プラットフォーム ロボット等 実⾏履歴 実⾏履歴
17. 17 ユースケース：ポイントプログラム 企業（ポイント管理） 企業（ポイント提携先） ユーザー • ポイントの⼀元管理が可能 • 分散処理による性能が安定したポイント処理 • 台帳を共有することで、他システム・他社を またいだ共通ポイント基盤を構築可能 • ポイント使い分けが不要に • ポイントを安全に管理（不正操作防⽌） 企業 提携先 ポイント ⼝座 l ポイント管理システムをブロック チェーンに構築（スマートコント ラクトでポイント⾃動付与） l ユーザーが⾃由に参照・交換可能 l 提携先とのポイント交換が容易に ポイント ⼝座 ユーザー ポイント 参照・利⽤ ポイント付与 ポイント付与 ポイント交換 ポイント 獲得 ブロックチェーン 業種 コマーシャル パターン マーケット
18. web3 ブロックチェーンと web3 の関係 DAO スマートコントラクト デジタル通貨 NFT DeFi メタバース NFT マーケット 意思決定 流通 企業 ユーザー クリエイター 企業 イーサリアム (プラットフォーム) ブロックチェーン技術
19. イーサリアムの データ構造について 19
20. イーサリアム全体のアーキテクチャ • 以下の Qiita 記事も参照ください https://qiita.com/katsuyaom86/items/4b1aa63224a69753392a 20
21. イーサリアムのデータ構造 イーサリアムのデータ構造には「マークルパトリシアツリー」が使われている マークルツリーとは？ • データを要約した結果を格納するツリー構造のこと • ２つのデータのハッシュ値をひとつにまとめる • １つ値が変わると全体に影響（改ざん検知が容易） パトリシアツリーとは？ • マークルツリーの探索を容易にする仕組み • 簡単に⾔うと…⼀つの⽂字ではなく⽂字列をラベル として付与する（共通の⽂字がある場合に⾼速） マークルルート データ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
22. ブロックチェーンのデータ構造 ブロック https://www.etarou.work/posts/4979138 ワールドステート トランザクションのリスト トランザクション トランザクション ブロックのヘッダー 前のブロックのハッシュ ステートの要約（Hash） l ブロックにはトランザクションとヘッダー が含まれる l ヘッダーには前のブロックのハッシュが ありチェーンをつないでいる l ワールドステートの要約が「マークルパト リシアツリー」で格納されている l ワールドステートに全アカウントの状態が 格納されている l 各アカウントがもつデータの要約が「マー クルパトリシアツリー」で格納されている ブロック + 1 トランザクションのリスト トランザクション トランザクション ブロックのヘッダー 前のブロックのハッシュ ステートの要約（Hash） アカウントのステート ストレージの要約（Hash） ワールドステート アカウントのステート ストレージの要約（Hash） 22
23. ブロックのデータ構造：ステートの要約 ブロック トランザクションのリスト トランザクション トランザクション ブロックのヘッダー stateRoot transactionsRoot receiptsRoot ワールドステートの要約 トランザクションの要約 レシート（結果）の要約 ブロックのヘッダーにある３つの要約 23
24. ブロックのデータ構造：ストレージの要約 ワールドステート コントラクトアカウント アドレス ステート ナンス バランス(残⾼) storageRoot コードHash アカウント ステート stateRoot 配列 アカウントに保存されるデータの要約 Key (Address) Value (Balance) 0x00000000... 0 0x121200000.... 100 0x242400000... 500 0x36360000... 2000 Key-Value 形式のストア 24
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
26. l マークルパトリシアツリー には 4 種類のノードが存在する l NULLノード（初期状態） l ブランチノード（枝分かれ） l リーフノード（ツリーの末端。value値を持つ） l エクテンションノード（⼦ノードへのポインタを持つ） コードの実⾏：Key-Value Store への操作 コントラクトアカウント アドレス ステート ナンス バランス(残⾼) storageRoot コードHash EVMコード トランザクション Message Call コードの実⾏ データを変更 データを読取 （補⾜）実際には... 26
27. Solidity で実際の動きを確認する Solidity 公式のサンプルコード：https://solidity-by-example.org/app/merkle-tree/ マークルツリーの leaf（葉） から 計算した root のハッシュ値が 正しいか検証するサンプルコード ※ちなみに、単純なトランザクションの取得だけであれば、 web3.js ライブラリを使って簡単に実⾏できる 実⾏例： web3.eth.getTransaction(ʻトランザクションハッシュ')27
28. オラクル問題 • オラクル問題： • リアル世界のデータをブロックチェーンに変換するポイントでの信頼性担保をどうするか • 解決⼿段：「Chainlink」など • オンチェーンとオフチェーンという2つの異なる環境の橋渡しする • レピュテーションコントラクトによって、正しい情報を提供したオラクルノードの評価スコアを 上げる仕組み（報酬としてLINKトークンを付与） 28
29. DApps （分散アプリ）の 全体イメージ Web 2.0 アプリとの違い 29
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 ʻ
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 ʻ
32. 開発環境 スマートコントラクトが実装されるまでの流れ 開発フレームワーク Remix / HardHat / Truffle スマートコントラクト （Solidity⾔語で作成） ローカルPC ソースコードのコンパイル l SolidityファイルをEthereum Virtual Machine(EVM)バ イトコードに変換 l スマートコントラクトを実⾏可能なバイナリにする コンパイル デプロイ 接続 32
33. 開発環境 ブロックチェーンネットワーク スマートコントラクトが実装されるまでの流れ 開発フレームワーク Remix / HardHat / Truffle スマートコントラクト （Solidity⾔語で作成） コントラクトの新しいアドレスが作成される 内部状態を保持するストレージ部分、 実⾏コード（EVMコード）を持つ ワールドステート コントラクトアカウント EVMコード アドレス ステート ローカルPC スマートコントラクトのデプロイ l コンパイルしたバイトコード をEVM に移⾏ l ネットワークにコントラクト をデプロイ コンパイル デプロイ 接続 33
34. ブロックチェーンネットワーク スマートコントラクトが実装されるまでの流れ ワールドステート コントラクトアカウント EVMコード アドレス ステート Web3 クライアントからの接続 l Web3.js やEthers.js などの イーサリアムクライアント ライブラリを使⽤ l スマートコントラクトに接続 し、各種コントラクト関数を 呼び出す イーサリアムクライアント スマートコントラクト操作 Web3.js / Ethers.js コンパイル デプロイ 接続 34
35. EVM（Ethereum Virtual Machine ）とは • EVMはスマートコントラクトのランタイム環境 • EVMコードはEVMで実⾏される • ⼀時的なメモリで動作（トランザクション中のみ持続） • イーサリアムノード上にEVMが実装されている 35
36. スマートコントラクトの 実装 Remix 36
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
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
39. AWS Remix + Metamask のスマートコントラクト実装イメージ ネットワーク接続 ローカルPC ブラウザ （Chrome） 拡張機能 MetaMask ウォレット 連携 （Injected Web3） ウォレットを経由してネットワーク 上にコントラクトをデプロイ可能 ブラウザ接続 Remixでコントラクトを コンパイル、デプロイ Remix IDE（開発環境） スマートコントラクト （Solidity⾔語で作成） BC ネットワーク RPC URL 39
40. スマートコントラクトの 実装 Hardhat 40
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
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
43. スマートコントラクトの 操作 43
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
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
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
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のメンテナーも多い ブロックチェーン上のデータを 操作するためのライブラリ
48. NFT の概要 基本的な仕組みと規格 48
49. • NFT はインデックス、メタデータ、実際のデジタル データの３階層のデータ構造になっている • インデックス：NFTの固有の識別⼦ • メタデータ：NFTに関する情報を記述（JSON形式） NFT の概要 NFT とは • Non-Fungible Token（⾮代替性トークン）は、 デジタルデータに唯⼀性と所有権を付与する技術 • ブロックチェーン技術を⽤いて発⾏され、取引履歴 や権利関係が改ざん不可能に記録される • デジタル資産に新たな付加価値を与えられるため、 様々なコンテンツでのNFT 化が注⽬されている NFT のデータ構造 FT （代替できる） NFT （代替できない） × インデックス トークン ID トークン URI 所有者 アドレス メタデータ NFT の名前 NFT の説明 コンテンツの URL オンチェーン オフチェーン（IPFSなどのストレージ） 49
50. NFT の規格 • 代表的な 2 つの規格 ERC-721 • Ethereum上で⾮代替性トークン（NFT）を発⾏するための標準規格 • NFTは、⼀意で代替不可能なデジタルアイテム（画像、動画、⾳声など）のこと • ひとつひとつのトークンに「トークンID」を割り振ることで、トークン同⼠を区別 • NFTのタイプ情報や名前、画像のURLなどのメタデータをNFTに付与する ERC-1155 • Ethereum上で代替性トークン（仮想通貨）と⾮代替性トークン（NFT）を 同時に発⾏するための標準規格 • ⼀つのスマートコントラクト内に複数種類のトークンを定義することができ、 ⼀度の取引処理で複数個・複数種類のトークンを送信することが可能 • ゲームアイテムやコレクションカードなどを効率的に管理するために使われる + 50
51. 51 NFT のユースケースの変化 コレクション コミュニティ メンバーシップ アート ランダム⽣成の希少性 の⾼い絵柄を集める ゲーム 装備や⼟地を購⼊してキャ ラクターをアップデート 会員証 所有者のみの特典や 優先購⼊権の付与 チケット 購⼊者向けに特別な体験 転売対策の強化 地域創⽣ デジタル住⺠票、地域の 特⾊PRによる活性化 メタバース デジタル空間のアイテム をリアル世界に転換
52. NFT の規格 • ERC-721 と ERC-1155 の違い 項⽬ ERC-721 ERC-1155 トークンID ⼀つのコントラクトに対して⼀意に割り当て ⼀つのコントラクトに対して複数のトークンIDを 持つことができる トークン数 ⼀つのトークンIDに対して⼀つのトークンのみ存在 ⼀つのトークンIDに対して複数のトークンを 発⾏することができる 転送⽅法 ⼀度に⼀つのトークンしか転送できない 複数の異なるトークンIDと数量をまとめて転送する ことができる ガスコスト 転送ごとに⾼いガスコストがかかる 複数のトークンをまとめて転送することで ガスコストを削減できる • 「個別性」や「希少性」が⾼い NFTにしたい → ERC-721 • 「多様性」や「効率性」が求められる NFT → ERC-1155 52
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
54. OpenZeppelin とは l ERC-20 / ERC-721 のスマートコントラクトを実装する ためのライブラリ l コミュニティでテスト・メンテナンスされており、セ キュアにメソッドを扱える l 公式の Contract Wizard（右図）で 各トークンで使いたい機能セットの サンプルコードを⾃動⽣成できる https://www.openzeppelin.com/contracts 54
55. OpenZeppelin Wizard で NFT コントラクトをデプロイ https://xtech.nikkei.com/atcl/nxt/column/18/00160/011700338/ Mint （NFT 発⾏）を許可する Mint の度に ID を１ずつ上げる トークン URI （画像の場所） を指定する 発⾏された NFT を列挙する 作成したコードを Remix で 開いてデプロイする デプロイ後のコントラクトで 送付先アドレスとURI を指定して Mint 55
56. デモアプリの アーキテクチャ検討 サンプルアプリからのカスタマイズ⽅法 56
57. デモアプリのアーキテクチャ設計の進め⽅ Step 2 Step 3 Step 1 • サンプルアプリを触ってみる • 簡易的な変更（⾒た⽬の変更）を 試してみる • Angular ハンズオン （クラウドIDEでHello World） • NFT 化する既存業務をフロー化 • 登場⼈物の洗い出し • Input / Output の洗い出し • NFT アプリのモック（イメージ図） を作成 • Step 2 を踏まえて NFT アプリを カスタマイズ • モックから１画⾯ずつ作成 • Angular アプリ構成の理解 • サンプルアプリカスタマイズ （軽微なビジュアル変更） • 業務フロー図（既存） • UI モック（Miro？） • 業務フロー図（NFT アプリ版） • サンプルアプリカスタマイズ （Step 2 反映） サンプルアプリに慣れる 既存フローの整理＆モック作成 NFT アプリ向けに洗練 57
58. デモアプリのアーキテクチャ設計 Step 1 • サンプルアプリを触ってみる • 簡易的な変更（⾒た⽬の変更）を 試してみる • Angular ハンズオン （クラウド IDE で Hello World） • Angular アプリ構成の理解 • サンプルアプリカスタマイズ （軽微なビジュアル変更） サンプルアプリに慣れる サンプルアプリ（NFT Platform）の実⾏環境の⽤意 Angular のファイル構成を理解する ・別途 Tech セッションでインストール⽅法を説明 ・⼀通りの画⾯を触り、UI 変更イメージを膨らませる サンプルアプリ⾒た⽬カスタマイズ ・基本的なファイル構成と変更対象の ファイルがどれかを確認 ・公式チュートリアルを試す ・どこがどう連動するか触ってみる ・ラベルの張り替えだけ試してみる アウトプットイメージ 58
59. デモアプリのアーキテクチャ設計 Step 2 • NFT 化する既存業務をフロー化 • 登場⼈物の洗い出し • Input / Output の洗い出し • NFT アプリのモック（イメージ図） を作成 • 業務フロー図（既存） • UI モック（Miro？） 既存フローの整理＆モック作成 アウトプットイメージ 業務フロー図 ・誰が何をするをストーリーで洗い出す ・インプット、アウトプットの関係性を ポインティングする UI モック ・フローが変わらず使えるのであれば、 使いやすさにフォーカス ・カラーチャート、コーポレートカラー を揃えれば完成度⾼く⾒える 59
60. デモアプリのアーキテクチャ設計 Step 3 • Step 2 を踏まえて NFT アプリを カスタマイズ • モックから１画⾯ずつ作成 • 業務フロー図（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
61. Angular 概要 基本的なアプリ構成 61
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
63. Angular アプリの基本構成 index.html l index.html がトップページとして 読み込まれる l app-root タグから app.component.ts が読み込まれる <!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>Artemis</title> <base href="/"> <meta name="viewport" content="width=device-width, initial-scale=1"> <link rel="icon" type="image/x-icon" href="assets/ico/favicon.ico"> </head> <body> <app-root></app-root> </body> </html> ルートコンポーネント app.component.ts で定義された タグとリンクする 63
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
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
66. Angular アプリの基本構成 app.component.* l app.component.html l コンポーネントのテンプレート l app.component.css l コンポーネントのデザイン l app.component.ts l コンポーネントのロジック l @Component でコンポーネントを定 義してクラス化 <h1> Welcome to {{title}}! </h1> {{ }}で囲った⽂は 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
67. Angular アプリの基本構成 app.component.ts app.component.html app.component.css AppComponent index.html <app-root> main.ts bootstrapModule app.module.ts AppModule その他コンポーネント （html, css, tsのセット） https://qiita.com/ksh-fthr/items/d040cf8b2d15bd7e507d#srcappappmodulets コンポーネント本体 モジュール本体 HTML 起動 Angular 起動 コンポーネント定義 アプリの実体 （主に実装を気にするところ） 67
68. Angular ハンズオン l 公式：https://angular.jp/start l モジュール、コンポーネント等の関連性が ⼀通り理解できるガイド 1. ガイドに従って商品やボタンを追加してみる 2. スタイルを変更してみる（style.css） • TOPページのデザインを変更（例） 68
69. ブロックチェーンの 安全性について なぜ安全といえるのか？ 69
70. ブロックチェーンの安全性：３つの柱 Consensus （合意形成） Cryptography （暗号化） Immutability （変更不可） ３つの仕組みで安全性を成⽴させている 70
71. ブロックチェーンの安全性：３つの柱 Consensus （合意形成） Cryptography （暗号化） Immutability （変更不可） • ノードの障害や不正な操作があっても正しく処理する仕組み • PoW / PoS（パブリック）、BFT（プライベート）の違いは あるが同じ⽬的を達成する • 公開鍵暗号⽅式（ECDSA）による強固な暗号化 • ウォレット＝秘密鍵、アドレス＝公開鍵からハッシュ⽣成 • 送信者のトランザクションを秘密鍵でデジタル署名 • ブロックには前のブロックのハッシュが含まれるため 追加されたブロックは以後変更ができない • SHA-256ハッシュ関数により⼀⽅向の値（復元できない） パブリック・プライベートを問わず、ブロックチェーンの特性から安全性が得られる 71
72. ブロックチェーンのセキュリティ脅威マップ ブロックチェーンプラットフォーム 台帳 ノード コンセンサス エコシステム ハード ウォレット スマートコントラクト コード EVM 取引所 開発 プラットフォーム ストレージ ユーザ / DApps プライベート ウォレット Web / エンドポイント 分散型⾦融 サプライ チェーン NFT マーケット デジタル証書 マルウェア 秘密鍵の漏洩 フィッシング DoS 攻撃 コンセンサス集中 攻撃 ビサンチン不正 ノード ⼆重⽀払い攻撃 リエントランシー 攻撃 フロント ランニング攻撃 DoS 攻撃 プライバシー侵害 プラットフォームで 対処すべき脅威 72
73. ブロックチェーンの攻撃例 プライベートブロックチェーンの場合 51% 攻撃 シビル 攻撃 ダブルスペンディング 攻撃 • ネットワーク全体のマシンパワーの 総量の過半数を⼿に⼊れることで 乗っ取り（別の枝分かれしたチェー ン作成）を⾏う • 不正に複数IDを作成し、あたかも 多くのユーザがいるように⾒せかけ てネットワークに影響を与える • 同時に 2 つトランザクションを送信 し、取引を無効化する • ファイナリティが必要だが、PoWは 承認の待ち時間が課題に • ネットワーク参加者⾃体が許可制なため、過半数の悪意あるノードが現実的に存在しない （閉じられたネットワーク内で⼀部のノードに合意形成の権限を与えるなど） • コンセンサスアルゴリズム（BFT）の信頼性と、確実なファイナリティの機能が必要 正しいチェーン 不正チェーン 73
74. BFT（ Byzantine Fault Tolerance ） の安全性 ファイナリティ（取引の完了判断） ノードの最⼤ 1/3 がクラッシュもしくは悪意ある第三者 に乗っ取られた場合でも機能性が維持されることを保証 合意形成アルゴリズム Replica Replica Replica Replica Blockchain Network n = 3f + 1 レプリカノードの 必要台数 許容可能な ノードの障害台数 １台が故障しても残りの3台で 合意形成が取れる（多数決ができる） リーダーノードによってブロックが⽣成されるため、 ブロックチェーンが分岐することはない 74
75. Thank you 75