20240215_Web3エンジニア進化論

取扱注意 TechStreet(02-15-2024) WEB3エンジニア進化論 02-15-2024 Matsuda Ver1.01掲載版

Agenda 1 本⽇の発表内容 Ø WEB3に触れて1年ちょっとのエンジニアの体験談 Ø エンジニアはどういう⾯持ちで向き合えばいいのかという、WEB3の歩き⽅ 想定ペルソナ Ø Ø Ø Ø Ø 中堅エンジニア（インフラエンジニア／ソフトウェアエンジニア問わず） ご⾃⾝のキャリアにWEB3を絡めていくべきか迷っている 技術的探究⼼に溢れている WEB3に興味はあるが、なんとなく『胡散臭くね︖』と思っている WEB3に興味はないが、何かの間違いでこの場に来てしまった 本⽇のゴール Ø 果たしてWEB3はエンジニアが進むべき進化の先に位置しているのか。 その⽰唆を感じてもらいたい

⾃⼰紹介 2 松⽥ 祐征 ⽒名︓ 所属︓株式会社オプテージ 技術本部 プラットフォーム技術部 経歴︓ ・基本属性は情報通信技術者（ネットワーク＆インフラエンジニア） ü 電⼒保安通信設備の保守運⽤ ü 電⼒スマートメータシステムの開発 ü 光多重伝送装置やPON等の光ファイバ伝送装置開発 ü キャリアグレードのBGPフルルート運⽤ ü 広域L2スイッチ,MPLSルータの開発運⽤ ü IPv4アドレスの調達、⼤規模DNS運⽤ ・等を経て、現在は株式会社オプテージにて、何かの間違いで ü ソフトウェアエンジニア部隊の⻑としてマネジメント職に従事 ・並⾏して ü イーサリアム"The merge"(2022年9⽉)頃からブロックチェーンの学習を開始

株式会社オプテージ 3

Why WEB3 ?? 4 関⻄電⼒グループ中期経営計画(2021〜2025)

Table of Contents 5 1.WEB3取り組み内容 - エンジニアとして実際に”やってみた” 2.WEB3エンジニア進化論 - エンジニアはWEB3というモヤモヤしたテーマをどう捉えるべきか

1.WEB3取り組み内容 6

取り組み内容 7 Ethereumを主体にスキル習得 2022.10 社内の有志の集まりからスタート ドメイン知識の習得 P2P伝搬技術の調査 ノードオペレーション スマートコントラクト 2023.05 WEB3アプリ 社内イベントで⾃作WEB3アプリを発表 ブロックチェーン可観測性 Ethereum 報酬・罰則の仕組み 2023.08 Validatorノードを実弾(会社のお⾦)で運⽤ カストディ＆メタ・トランザクション MEV/MEV-BOOST 2024.02現在 複数のビジネスPoCに⾄る 秘密分散&秘密計算

①P2P伝搬技術の調査 ü過去の主要な研究・実⽤化技術 基礎研究 ü 隣接ノード選択 ü ノード間プロトコルの選択 ü リレーネットワークの影響測定 実⽤化/商⽤化された技術 ü ü ü ü BFRN ~Bitcoin Fast Relay Network~ FIBRE ~Fast Internet Bitcoin Relay Engine~ FALCON Bloxroute その他の学術研究 ü FastChain: Scaling blockchain system with informed neighbor selection ü Peer Selection Techniques for Enhanced Transaction Propagation in Bitcoin Peer-to-Peer Network ü 複数地域に跨るブロックチェーンネットワークにおける最適な隣接ノード選択⼿法の提案 8

①P2P伝搬技術の調査 9 TPS 単位時間あたりの取引処理数 (Transactions Per Second) >> 中央集権型 分散型(ブロックチェーン) 1700~ 24,000 ~7 320~ ~15

①P2P伝搬技術の調査 10 ブロックサイズ Max TPS ＝ ① ブロック⽣成間隔 ② ① N-1 N N+1 ② ブロックサイズ↑ ＝ 分散性の低下(中央集権化の加速) ブロック⽣成間隔↓ ＝ 分岐発⽣率の上昇(ネットワーク安定性の低下)

①P2P伝搬技術の調査 11 ü『ブロックチェーンのトリレンマ』、Layer1の性能上限やLayer2 がなぜ必要なのかを体系的に調査・理解 スケーリングソリューションの類別 技術スタック Layer 2 2nd Layer (Off-chain) Side-chain, Child-chain, Lightning Networkなど Layer 1 1st Layer (On-chain) 派⽣コイン(hard fork)、Segwit、Shardingなど Layer 0 Network Layer P2Pネットワーク効率化、伝搬速度向上など 最初に着⽬

②ノードオペレーション 12 üEthereumノードを構築し、Validatorを運⽤ üブロックチェーンの挙動を体系的に理解 はじめの⼀歩 OSS Validator OSS CLクライアント OSS ELクライアント OSS Linux ブロードバンド回線 PC ü 初めは必ず実機を使うことを推奨 - いきなりパブクラ︖ - いきなりdocker︖ - ⼿を動かして得られる経験知はエンジニアにとって貴重 ・P2Pのピアリングはどのように⾏われるのか。どのくらいで安定するのか。 ・通信量はどの程度発⽣するのか ・マシンリソースはどの程度必要なのか。AttestationやPropose時の バーストは⽣じるのか ・OSのセキュリティをどのように確保するのか。FWやアカウント管理は。 ・ブロック同期時間はどのくらい要するのか ü WEB3特有の様々な検討障壁にぶち当たることで⾃⼰ 成⻑ - 秘密鍵はどうやって⽣成するのが安全か - 安全にオフライン保管するべきものたくさん (ニーモニック、ウォレットパスワード、パスフレーズ、etc) - クライアントソフトウェア(複数あります)の組み合わせどうするか

② ノードオペレーション 13 ü 実際、触れば触るほど謎が増えていきます - Faucetって何︖テストネットトークン全然⼊⼿できないんだけど︖ - 報酬が発⽣するメカニズムや計算式が謎すぎる - 罰⾦やスラッシングの判定条件や回避⽅法はどう考えたらいいの︖ - ECDSAやBLS署名の原理が謎 - Attestationがどうやって集約されていくのか謎 - ニーモニックからどうやって鍵が⽣まれるのか謎 - Validator Keyはどこまで多重化できるか謎 - MEV︖何それ美味しいのですか︖ etc 親の顔より⾒ることになるExplorer ソースコードと睨めっこ

② ノードオペレーション 14 üとはいえ、エンジニアなら試⾏錯誤と⾃⼰研鑽は当然。皆さん常 に歩んできた道ですよね︖WEB3とて同じことです ビジネスユースに昇華するとこうなる︖ CI/CD CL CL モニタリング/監視 運⽤/保守 署名サーバ Validator EL EL kubernetes ü 可⽤性の最⼤化 - しかしValidatorの⼆重起動はNG ü Slashingリスクの低減 - マルチクライアント化により運⽤コストの上昇 ü 報酬の最⼤化 - 監視とモニタリング - MEV-BOOST Linux マルチクラウド オフライン鍵管理

15 ③WEB3アプリ開発 üweb3.js(とGPT)を活⽤して、独⾃トークンを扱うアプリ「まなび っとコイン」を⾃作 まなびっと＝”終業時間内に⾃⼰啓発して良いよ”という社内制度 まなびっと コントラクト OpenAI まなびっとガチャ (ＡＩが採点→★を獲得) Smart Contract まなびっとの思い出 (ブロックチェーンに刻印) まなびっとコイン コントラクト Smart Contract まなびっと神 ★の数に相当する「まなびっとコイン」配布 Slack まなボット まなびっと実績報告 担当者

16 ③WEB3アプリ開発 まなびっと実績を報告 担当者 まなボット コメント(⽣成AI) 講評・採点(⽣成AI) まなボット(モノシル) まなびっとコイン付与 (スマートコントラクト) この後、さらにAIと会話を続けることも可能

17 ③WEB3アプリ開発 üEvent発⾏コントラクトとERC-20トークンコントラクトで構成 GPT +プロンプトエンジニアリング 秘密鍵署名 JSON-RPC OpenAI Text Completion 刻印(Event発⾏) まなびっとコイン Owner JSON-RPC REST-API API Gateway まなびっと実績＋イーサリアムアドレスを 添えてBOTメンション まなびっとコイン (ERC-20) Contract Call Internal Call Smart Smart WEB3 Contract Contract Endpoint ロールプレイ⽤のPrompt Slack まなびっと コントラクト まなボット.py WEB3.js Lambda Lambda Secrets Manager コントラクトアドレスや 接続情報を保持 Amazon Managed Blockchain イーサリアムアドレス

2.WEB3エンジニア進化論 18

WEB3が関わる技術レイヤ 19 取り組み事例と技術レイヤの関連 WEB3アプリ アプリ ノードオペレーション サーバ P2P伝搬技術の調査 NW Ethereumを正しく理解するために必要な技術スタック・ドメイン知識（最低限） Layer ⾼ q Dapp/DeFi/DAO/⾦融⼯学/Fintech/MEV q q q q q q q q q q 低 q スマートコントラクト(solidity/web3プログラミング) World State EVM(Ethereum virtual machine) マークル・ツリー/マークル・パトリシア・ツリー Reward/Penalty/Slashingの判定・計算式 Gasper(LMD-GHOSTプロトコル/Casper-FFGプロトコル) Keccak256ハッシュ関数 ECDSA/BLS署名アルゴリズム Randaoメカニズム Execution Layer/Consensus Layer/Validator & 各クライアントソフトウェア P2Pネットワーキング(DiscV4/RLPx/DevP2P/Etherum capability protocols) 基本的に教えてくれる⼈はいない・本もない・⽇本語の情報もあっても古い(半年や1年ですぐに陳腐化)

温故知新（賢者は歴史に学ぶ） 20 ビットコイン前夜 ü ビットコイン(ブロックチェーン)の発明に⾄る遥か以前から、⾮中央集権なデジタルカレンシーを作ろう とする⼈類の営みは始まっており、実際のところTCP/IPの歴史よりも古い ü これらの試みで、今⽇のブロックチェーンの中核技術の多くは形成されてきたものの、⼆重⽀払い問 題を解決するに⾄らなかった。 1976 – Diffie-Hellman鍵共有法の研究開発 1978 – 公開鍵暗号発明 1979 – マークル・ツリー発明 1980s – TCP/IP開発 1982 – ビザンチン将軍問題の提起 1985 – 楕円曲線暗号の研究 1991 – “⽂書のタイムスタンプ改ざん防⽌”に関する研究→(ブロックチェーンに繋がる初期のアイデア) 1992 - “Pricing via processing or combatting junk mail” 発刊→(PoWに初めて⾔及) 1998 – Nick Szaboが“Bit Gold”を提唱(匿名の電⼦キャッシュシステム,PoW,ハッシュチェーンなどの要素を含む) ビットコイン原典 2002 – “Hashcash”の開発 2004 – “B-Money”の開発 ü ビットコインホワイトペーパーを書き上げ、初期コードを実装したSatoshi Nakamotoの当時の謳い 2005 – 計算パズルを使⽤したシビルアタック防⽌に関する研究 ⽂句としても、⾮中央集権かつ分散型でありながら「⼆重⽀払い問題」を解決するソリューションを 2009 – Satoshi Nakamotoが”Bitcoin: A Peer-to-Peer Electronic Cash System”をネットに投稿 始まりはTCP/IPの歴史より古い 提案するものと喧伝。これは積年の課題を解決した⼈類の⼀つの到達点(ゴール)でもあり、あるいは 全ての始まりでもある ビットコインホワイトペーパー(2008/11) Satoshiはホワイトペーパーで 何を⾔っていて、何を⾔っていないか 「これはP2Pネットワーク上で⼆重⽀払い問題を解決する ソリューションを提案するものである。」 ⼆重⽀払い問題＝『減らない財布』 ü 全てのノードが統⼀状態（単⼀状態）に収斂する ü 不正を⾏うノードを検出し排除する

【参考】１つのカテゴリ論的区分け 21 テクノロジとしての観点 ü ブロックチェーンは情報⼯学・暗号学・通信⼯学・⾦融⼯学等のテクノロジが組み合わされており、こ れらの素材をとても賢い⼈達が融合・加⼯・調理した結果の産物として創造された新たなカテゴリ ü WEB3はこれらをオーバーラップしてマスアダプションを⽬指す⼤きなモメンタムと解釈できる インターネットの 勃興 既存⾦融システ ムの拡⼤と退廃 P2P技術⾰新 暗号学の発展 ハッシュ関数 公開鍵暗号＆ 署名アルゴリズム リーマンショック Fintech ⾦融⼯学 分散型⾦融システム (コア機能としてのブロックチェーン) ブロックチェーンエコシステム 現実世界との境界 実体経済活動 WEB3(インタフェース) Geekな⼈たち マスな⼈たち 数理演算 記憶容量 計算機の進化

【参考】１つのアーキテクチャ論的区分け 22 システムアーキテクチャとしての観点 ü ブロックチェーンベースのアプリケーションは障害耐性・検閲耐性に優れており、データはユーザセントリッ クで、SPoFを排除し、設備所管の境界も曖昧（ない︖） ü 透明性重視も匿名性重視も(!?)設計思想次第 Distributed DB 外部システム Web/App server Legacy mainframe Traditionalなserver/client Web App UI De-centralized ブロックチェーンベースのスマートコントラクト Web App UI API strage RPC strage RPC B B B B B B B B strage RPC strage RPC B B B B B B B B

エンジニアはWEB3というモヤモヤしたテーマをどう捉えるべきか︖ 23 WEB3と⾔う名称がすでにミスリード Ø 『WEB3エンジニア』という⾔葉、なんだかすごく違和感感じませんか︖ Ø 『WEB3』に特別で明確な技術領域があるように思わせるが、、、 (そもそも、「WEB2エンジニア」とかって呼んでました︖) Ø 実際に触ってみた実感として、技術はいつだって既存技術からの延⻑線で成り⽴っており、境界線は ないと思う（温故知新。先駆者にリスペクト） Ø ⾔うまでもなくアプリ領域に閉じたスキルでもない 上に積み重ねるイメージではなく WEB3 アプリ サーバ NW 🤔 技術の使い⽅が変わっていってるイメージ WEB1.0 WEB2.0 アプリ WEB1.0 サーバ NW WEB2.0 😋 WEB3 スマコン,web3.js PoW,PoS,PoA P2P 適切なリスキリング フルスタックで 体系的に学ぶ

まとめ 24 üブロックチェーンは最新の暗号⼿法やアイデアが実験的に次々と 投⼊される領域でもあり、頻繁に改廃がなされる。常に最新の 情報を追いかけなければ追随できない üしかも、これらに関する、まとまったドキュメントが(ほとんど)ない 。英語圏の情報を追跡し、かつソースコードを⾃ら読み解きなが ら⾃⼰検証し、⾃⼰進化していけるエンジニアが絶対的に求め られる ü逆説的に⾔うなら、WEB3エンジニアは、それが既に⾃然と⾝ に付いている⼈財のことを指していると⾔える

【宣伝】⼤阪でもWEB3盛り上げたいですよね︕︖ 25 ü リファラル採⽤、やってますので是⾮ ü QRコード →「話を聞きに⾏きたい」をクリック →必要事項（登録1分）を⼊⼒ 英語が⾝に付く Ø 英語を公⽤語化 Ø 週⼀回の英語プレゼン練習会 (ネイティブの補佐あり) Ø ⽉⼀回の英語ライトニングトーク会 (誰でも参加可) 最新の開発環境が使える Ø 全員に最新開発端末を⽀給。 JTCにありがちなセルフ経済制裁 のような環境から脱却 Ø GitやAIも使い放題。最新の開 発スタイルでライバルに差をつけろ 充実した教育プログラム Ø アジャイル開発メソッドを導⼊ Ø 熟練エンジニアによるコーチング Ø ペアプログラミング・モブプログラミン グを通じて、初学者でも確実にス キルアップ

参考⽂献 Matering Blockchain (Fourth Edition) [Imran Bashir]@March 2023 26