ブロックチェーンR&D企業における SREの実態 / SRE Kaigi 2025

ブロックチェーンR&D企業における SREの実態⽔落啓太 SRE Kaigi 2025

Copyright © 2025 Datachain, Inc. All Rights Reserved. ⾃⼰紹介 •
⽔落啓太 (みずおちけいた) • キャリア ◦ 2017-2022 プラットフォームSRE/CRE@ヤフー (現LINEヤフー) 株式会社 ◦ 2022-2023 ブロックチェーンエンジニア@N.Avenue株式会社 ◦ 2023-現在ブロックチェーンSRE@株式会社Datachain • 興味 ◦ SRE / システム運⽤ ◦ ブロックチェーン 2

Copyright © 2025 Datachain, Inc. All Rights Reserved. 本セッションのゴール 3
• ブロックチェーンR&DビジネスにおけるSRE実装事例を知る ◦ 何をやっているのか？ ◦ 何が⾯⽩いのか？

Copyright © 2025 Datachain, Inc. All Rights Reserved. アジェンダ 4
• Datachain紹介 • ブロックチェーンとは • クロスチェーンとは • クロスチェーンブリッジTOKI • SREのミッション • SREの取り組み

Datachain紹介 5

Copyright © 2025 Datachain, Inc. All Rights Reserved. Datachain紹介 6
• 2018年創業 • ブロックチェーン技術による⾦融課題解決 • R&Dを基礎としたトークン移転‧送⾦基盤を開発‧提供 • 2024より事業拡⼤に伴い採⽤強化中

Copyright © 2025 Datachain, Inc. All Rights Reserved. Datachain紹介 7
• チーム • ビジネス • エンジニア ◦ R&D ◦ Webフロントエンド ◦ Webバックエンド ◦ アプリケーションコントラクト ◦ SRE

ブロックチェーンとは 8

Copyright © 2025 Datachain, Inc. All Rights Reserved. ブロックチェーンとは •
分散台帳技術の⼀種 • 分散データベースの⼀種ともいえる 9

Ethereumを例にブロックチェーンの特徴を説明 • Ethereum ◦ 最も使われているブロックチェーンのひとつ ◦ Datachainに⼊社した⼈は最初に覚える (?) 10

3つの特徴 ◦ トランザクション (取引) データを分散的に記録 ◦ 改ざん耐性 ◦ スマートコントラクト 11

特徴1: トランザクション (取引) データを分散的に記録 ◦ ユーザーはトランザクション (取引) をブロックチェーンノードに提出する 12 Ethereum Node Transaction from: 0x123 to: 0x456 value: 10

特徴1: トランザクション (取引) データを分散的に記録 ◦ 提出されるトランザクションはユーザーの秘密鍵により電⼦署名される ▪ → トランザクションは「誰」が発⾏したものなのか明確に識別される 13 Ethereum Node Transaction from: 0x123 to: 0x456 value: 10 signature: xxxx Sign

特徴1: トランザクション (取引) データを分散的に記録 ◦ 提出されたトランザクションはP2Pネットワークを通して各ノードに保存 (プール) される 14 Node Ethereum Network Node Node Node Node Node Transaction Transaction Transaction Transaction Transaction Transaction

トランザクションはブロックと呼ばれる単位で記録される ◦ ブロックを作成するノード (プロポーザー) が選択される ◦ 対象ノードは、トランザクションプールからトランザクションを集めてブロックを作成する 15 Ethereum Node (Proposer) Ethereum Network Block Transaction Transaction Transaction Transaction

特徴2: 改ざん耐性 ◦ 作成されたブロックは、別ノードに伝搬され検証される ◦ 検証内容: トランザクションの内容‧署名、ブロックの連続性 etc 16 Proposer Node Ethereum Network Block : Transaction Node Node Node Block Block Block ✔ ✔ ✔

改ざん耐性 ◦ ⽭盾のあるトランザクションを含むなど異常ブロックは、ネットワークに受け⼊れられない (捨てられる) 17 17 Proposer Node Ethereum Network Block : Transaction Node Node Node Block Block Block

特徴3: スマートコントラクト ◦ ブロックチェーン上にデプロイ‧実⾏されるアプリケーション ▪ ロジック (バイトコード) ▪ データ ◦ デプロイされたスマートコントラクトは固有アドレス (ID) を持ち、アドレス経由で外部から実⾏できる ◦ ⾃⾝の保有するデータ変更‧他アドレスへの送⾦‧他アドレスにデプロイされたスマートコントラクトロジックの実⾏が可能 ◦ Ethereumでは、Solidityと呼ばれる専⽤⾔語で記述される ▪ 他チェーンではRustが⽤いられることも⼀般的 18

特徴3: スマートコントラクト ◦ コンパイルして得られたバイトコードをトランザクションに載せて送信してデプロイ 19 Ethereum Node Ethereum Network counter.sol Transaction from: 0x123 input: <byte code> int counter; function increment(int diff) { … Compile

特徴3: スマートコントラクト ◦ コンパイルして得られたバイトコードをトランザクションに載せて送信してデプロイ 20 Ethereum Node Ethereum Network counter.sol Transaction from: 0x123 input: <byte code> int counter; function increment(int diff) { … Compile Contract Address: 0x456 int counter = 0; function increment(int diff); Deployed!

特徴3: スマートコントラクト ◦ 実⾏時: デプロイアドレス‧実⾏する関数セレクタ‧引数を含むトランザクションを提出 ◦ ブロックチェーンネットワーク上 (各ノード上) で実⾏される 21 Ethereum Node Ethereum Network Transaction from: 0x123 to: 0x456 input: <ABI callseq> Contract Address: 0x456 int x = 0; function increment(int diff); Decoded Input: increment(10);

特徴3: スマートコントラクト ◦ 実⾏時: デプロイアドレス‧実⾏する関数セレクタ‧引数を含むトランザクションを提出 ◦ ブロックチェーンネットワーク上 (各ノード上) で実⾏される 22 Ethereum Node Ethereum Network Transaction from: 0x123 to: 0x456 input: <ABI callseq> Contract Address: 0x456 int x = 0; function increment(int diff); Decoded Input: increment(10); Executed! Contract Address: 0x456 int x = 10; function increment(int diff);

Copyright © 2025 Datachain, Inc. All Rights Reserved. ブロックチェーンとは 23
• スマートコントラクトで表現できるロジックの例 ◦ ⼿数料 ▪ 取引⼿数料を5%引いて、送⾦先とは別アカウントに送⾦する ◦ ⾦融資産 ▪ ステーブルコイン: 1ドルの価値をスマートコントラクト上に表現 ◦ 認可処理 ▪ 指定されたロールを持つユーザーのみ送⾦可能とする • スマートコントラクト処理系は⼀般にチューリング完全であり、広範な処理を実装可能 ◦ 後述のクロスチェーン処理にも応⽤される

• アプリケーションプラットフォームとしてのブロックチェーン ◦ アプリケーションロジックを実装したスマートコントラクトデプロイ ◦ スマートコントラクトをバックエンドとした、Web‧スマートフォンアプリケーション ▪ dApps (Decentralized Application)

• ブロックチェーン3つの特徴をEthereumを例に説明 ◦ トランザクション (取引) データを分散的に記録 ▪ トランザクションがブロック単位で各ノードに記録される ◦ 改ざん耐性 ▪ 分散されたノードにより検証される ◦ スマートコントラクト ▪ ブロックチェーン上 (オンチェーン) にデプロイ‧実⾏されるアプリケーション

クロスチェーンとは 26

Copyright © 2025 Datachain, Inc. All Rights Reserved. クロスチェーンとは •
トランザクションの対象とできるのは通常、同⼀チェーンのみ • Aチェーン上に資産を保有していたとしても、Bチェーン上で利⽤できない • AチェーンとBチェーンをまたぐ取引をプログラムできず、各チェーンのエコシステムがサイロ化する • インターオペラビリティ (相互運⽤性) がない、という 27 A Chain Network B Chain Network

クロスチェーン ◦ 異なるブロックチェーン間でのデータのやり取り • クロスチェーンの実現⽅法 ◦ いくつかの⽅式‧規格があるが、弊社が採⽤‧貢献しているIBCを紹介 28

IBC (Inter-Blockchain Communication Protocol) ◦ ブロックチェーン間でのメッセージングを可能とするためのプロトコル ▪ Exactly Onceなメッセージングが可能 ◦ ⼤まかに、RelayerおよびLightClientと呼ばれる仕組みからなる 29

Relayer • 2つのブロックチェーンをリレーするコンポーネント • ⽚側チェーンにて、発⽣したトランザクションを反対側チェーンに伝える 30 Src Chain Network Dst Chain Network Relayer Transaction Packet Packet Transaction Packet

Light Client • 送信元チェーンの状態を検証する ◦ 送信元チェーンでのパケットの存在性を検証 ◦ Relayerは、パケット本体と共にプルーフ (存在証明) を取得‧転送する ◦ 送信先チェーン上で受信したパケットをプルーフにより検証する ▪ verifyMembership と呼ばれる • ブロックチェーン上 (On Chain) に実装される ◦ Ethereumの場合はスマートコントラクトとしてデプロイされている 31

Copyright © 2025 Datachain, Inc. All Rights Reserved. クロスチェーンとは 32
• Light Client 32 A Chain Network B Chain Network Relayer Transaction Packet Packet

• Light Client 33 A Chain Network B Chain Network Relayer Transaction Packet Packet LightClient Proof Proof Packet Proof Verify

Light Client • Relayer: Oﬀ Chain (Untrusted領域) で動作 • LightClient: On Chain (Trusted領域) で動作 • トラストレス性の維持: Relayerへの信頼が不要 (Untrust) ◦ パケット送受信の偽り、パケット内容の改ざんが不可能 ▪ Relayer 運⽤者さえ偽り‧改ざんできない ◦ ブロックチェーンの良さが、クロスチェーンでも維持される 34

• Light Client 35 A Chain Network B Chain Network Relayer Transaction Packet Packet LightClient Proof Proof Packet Proof Verify

• Light Client 36 A Chain Network B Chain Network Relayer Transaction Packet Packet LightClient Proof Proof Packet Proof Verify Off Chain: Untrusted Area On Chain: Trusted Area

Light Client • 検証しないとどうなるか？ ◦ チェーン間でデータ不整合が発⽣する ◦ 送信側でパケットを送っていないにも関わらず、受信側でパケットを受け取ったことになる ◦ 不正送⾦などが可能に 37

Datachain はクロスチェーン分野を中⼼にR&Dしている 38

Datachainのクロスチェーンプロダクト • YUI Relayer ◦ 拡張モジュールにより任意のブロックチェーンを接続できるRelayer • YUI IBC Solidity ◦ EVM (Ethereum Virtual Machine) 系チェーン上にIBCエンドポイントを作るライブラリ • LCP (Light Client Proxy) ◦ LightClient/verify処理にかかるガスコスト (ネットワーク使⽤料) を最⼩化 39

クロスチェーンブリッジTOKI 40

Copyright © 2025 Datachain, Inc. All Rights Reserved. クロスチェーンブリッジTOKI •
異種チェーン間でトークン交換できるサービス • クロスチェーン技術 YUI/LCP をコア技術としている • https://toki.ﬁnance/ 41

Datachain SREの責務 44

Copyright © 2025 Datachain, Inc. All Rights Reserved. Datachain SREの責務
• クロスチェーンブリッジTOKIのインフラ構築‧運⽤最適化 • クロスチェーンミドルウェア YUI Relayer/LCP の安定化‧運⽤機能改善の推進 45

• クロスチェーンブリッジTOKIインフラ • 主に3層のワークロードで構成される ◦ Webアプリケーション (Frontend + Backend) ◦ ブロックチェーンノード ◦ クロスチェーンミドルウェア (YUI Relayer + LCP) • これらをAzure + AKS (Azure Kubernetes Service) を中⼼に構築‧運⽤ 46

47

Datachain SREの取り組み 48

Datachain SREの取り組み 1. ブロックチェーンノード運⽤最適化 49

Copyright © 2025 Datachain, Inc. All Rights Reserved. SREの取り組み 1.
ブロックチェーンノード運⽤最適化 • ブロックチェーンノード ◦ ブロックチェーンへの書き込み (トランザクション発⾏) ◦ ブロックチェーン上データの読み込み • 何らかのブロックチェーンノードに接続する必要性 50

ブロックチェーンノード運⽤最適化 • ブロックチェーンノード運⽤の⾟さ (Ethereumの場合) ◦ readのスループットが悪い ▪ 数⼗ req/s ◦ 消費ディスクが莫⼤ ▪ 2TB~ ▪ 安易にスケーリングできない ◦ 定期的なハードフォーク (プロトコルアップグレード) 対応 ▪ サボるとネットワークに追従できなくなり停⽌ or 無意味な挙動になる ◦ ブロック同期が遅延しやすい ▪ 同期遅延 = 最新データの read および write が実質できなくなる 51

ブロックチェーンノード運⽤最適化 • Blockchain Node as a Service (NaaS) ◦ ブロックチェーンノードのマネージドサービス ◦ 前述のペインポイントをおおよそ解決する ◦ 使えるなら使うべきサービス 52

ブロックチェーンノード運⽤最適化 • 適材適所で使い分ける ◦ アプリケーション向け ▪ Blockchain Node as a Service ◦ クロスチェーン処理向け ▪ ⾃社運⽤ 53

ブロックチェーンノード運⽤最適化 • マネージドノードにはない、⾃社ノード運⽤のメリット ◦ 透明性の⾼さ ▪ ブロックチェーンノードのログ‧メトリクス etcを読める ▪ ソースコードを確認でき、障害の原因を完全把握できる ◦ 最適なブロックチェーンノード実装を選べる ▪ Prysm (Go) ▪ Lighthouse (Rust) ▪ Lodestar (TypeScript) • ライトクライアント検証のためのAPIを唯⼀実装している ◦ 最適な起動パラメータを選択できる ▪ クロスチェーン処理に必要⼗分な起動パラメータを指定できる 54

ブロックチェーンノード運⽤最適化 • アプリケーション視点 ◦ ⾼スループットの read ◦ 安定性 (UI表⽰に関わる) ◦ 特殊なAPIは要らない • クロスチェーン処理視点 ◦ 障害時の追跡性 ◦ 最新 or マイナーAPIが必要 ◦ 多少のダウンタイムOK ▪ ⾮同期処理のため 55 Blockchain Node as a Service ⾃社運⽤

Datachain SREの取り組み 2. クロスチェーンミドルウェアのオブザーバビリティ向上 56

クロスチェーンミドルウェアのオブザーバビリティ向上 • クロスチェーンミドルウェアYUI Relayer, LCP ◦ できたての技術 ▪ 2024年よりユーザー環境で稼働開始 • オブザーバビリティをはじめとした運⽤最適化が求められるフェーズ • YUI Relayer/LCP は他社でも運⽤されることを想定している ◦ 他社にとっても運⽤しやすいことが重要 57

クロスチェーンミドルウェアのオブザーバビリティ向上 • ログ‧メトリクス‧トレーシングそれぞれにて改善‧機能強化を推進 58

クロスチェーンミドルウェアのオブザーバビリティ向上 • ログの課題: ブロックチェーンノードからのエラーが不明 59

クロスチェーンミドルウェアのオブザーバビリティ向上 • ログの課題: ブロックチェーンノードからのエラーが不明 60 Relayer Src Chain Node Dst Chain Node failed to execute a transaction

クロスチェーンミドルウェアのオブザーバビリティ向上 • なぜエラーメッセージがなかったのか？ ◦ transactionReceipt (レシート) ▪ 専⽤のRPCコールにより得られるトランザクション実⾏結果データ ▪ エラーメッセージは含まれない → 普通に実装すると、Transaction失敗時のエラーメッセージを得られない 61

クロスチェーンミドルウェアのオブザーバビリティ向上 62

クロスチェーンミドルウェアのオブザーバビリティ向上 • debug_traceTransaction ◦ トランザクション実⾏時情報を得るためのRPC ◦ debug_traceTransactionをを利⽤してSREが直接ノードに問い合わせる必要があった 63

クロスチェーンミドルウェアのオブザーバビリティ向上 • Relayer ⾃⾝に debug_traceTransaction を実⾏させる • エラーメッセージをログとして直接確認できるように 64 Relayer Src Chain Node Dst Chain Node reason: ConsensusState not found

クロスチェーンミドルウェアのオブザーバビリティ向上 • メトリクス ◦ 定量情報による可視化‧監視に⽋かせないもの ◦ 未実装だったため、設計‧実装を進めた 65

クロスチェーンミドルウェアのオブザーバビリティ向上 • クロスチェーンミドルウェアにおいての主な監視観点 ◦ パケット転送のレイテンシ/スループット ◦ ブロックチェーンノードとの同期レイテンシ • ミドルウェア⾃⾝のメトリクスおよび、外形監視コンポーネントを設計開発 66

クロスチェーンミドルウェアのオブザーバビリティ向上 • Relayer (内部) 主要メトリクス ◦ backlog_packets ▪ Relayerが認識している送信すべきパケット数 ▪ 本数値増⼤の場合パケットを滞留させている ◦ processed_block ▪ Relayerが認識している最新ブロック番号 ▪ 本数値が定速で増加しない場合、ブロックチェーンノードとの同期がとれていない 67

クロスチェーンミドルウェアのオブザーバビリティ向上 • Relayer (内部) メトリクス監視の課題 ◦ Relayerが停⽌した場合に、メトリクスが⽋損する ◦ Relayerの主機能の不具合につられて、メトリクスが信⽤できなくなる ▪ Counter/Gauge が正確に更新されない ◦ やはり、外形監視も必要となった 68

クロスチェーンミドルウェアのオブザーバビリティ向上 • Relayer 主要外形監視メトリクス ◦ ibc_sequence_send ▪ 送信側IBCパケット番号 ◦ ibc_sequence_recv ▪ 受信側IBCパケット番号 • IBC Metricsという監視コンポーネントを開発 69

クロスチェーンミドルウェアのオブザーバビリティ向上 70 Relayer Internal Src Node Internal Dst Node NaaS Src Node NaaS Dst Node Src Chain NW Dst Chain NW sequence_send: 100 sequence_recv: 99

クロスチェーンミドルウェアのオブザーバビリティ向上 71 Relayer Internal Src Node Internal Dst Node NaaS Src Node NaaS Dst Node Src Chain NW Dst Chain NW sequence_send: 100 sequence_recv: 99

クロスチェーンミドルウェアのオブザーバビリティ向上 72 Relayer Internal Src Node Internal Dst Node NaaS Src Node NaaS Dst Node Src Chain NW Dst Chain NW sequence_send: 100 sequence_recv: 99 IBC Metrics OTelCol

クロスチェーンミドルウェアのオブザーバビリティ向上 73

クロスチェーンミドルウェアのオブザーバビリティ向上 • メトリクス導⼊の結果 ◦ レイテンシ‧スループット計測が⽤意となり、SLIとして計測可能になった ◦ SLOアラートとして最重要の監視項⽬のひとつに ◦ ブロックチェーンプロトコル/ノードの性質から、必ず起きるレイテンシ発⽣を発⾒ ▪ 現在のSLOとしては問題がないなど、定量的な運⽤議論がしやすくなった 74

クロスチェーンミドルウェアのオブザーバビリティ向上 • トレーシング ◦ 要件定義‧設計まで完了し、開発に着⼿したところ ◦ クロスチェーン処理では、多数のモジュール/プロセスが連携して動作することから、調査の難しさ‧属⼈性が課題になっている ▪ トレーシング導⼊による軽減を期待 75

Datachain SREの取り組み 3. 安全な秘密鍵運⽤ 76

安全な秘密鍵運⽤ • ブロックチェーンシステム運⽤において絶対に起きてはいけないこと ◦ 秘密鍵の漏洩‧悪⽤ → ユーザーおよび会社の資産が奪取される → 管理者専⽤スマートコントラクトロジックが実⾏される 77

安全な秘密鍵運⽤ • ブロックチェーンを操作する、ワークロード‧運⽤者 (SRE) はブロックチェーン上にアカウントを持っている ◦ アカウント毎に資⾦および権限を持つ • アカウント利⽤には対応する秘密鍵が必要 ◦ 復習: トランザクション提出には秘密鍵による署名が必要 78

Copyright © 2025 Datachain, Inc. All Rights Reserved. • ブロックチェーンの仕組みとしてはこれで動く
• セキュリティの観点からは⼤変危険 • SREはじめ⼀部の⼈は鍵を⾒られる ◦ 漏洩のリスク ◦ 内部不正のリスク ▪ 運⽤するアカウントによっては、エンジニアの年収を軽く超える額を容易に抜き取れる ▪ 犯⼈の追跡も難しい • オンチェーンでは追跡が可能だが、秘密鍵に対応するアカウントでしか識別されない ◦ 誰が秘密鍵を使ったのかは分からない 80 SREの取り組み 3. 安全な秘密鍵運⽤

安全な秘密鍵運⽤ • 秘密鍵を保護するアプローチ ◦ 秘密鍵を誰を取り出せなくするアプローチ ▪ HSM (Hardware Security Module) / リモート署名 ◦ 秘密鍵をどこにも作成しないアプローチ ▪ MPC (Multi Party Computation) ウォレット 81

安全な秘密鍵運⽤ • HSM / リモート署名の導⼊ ◦ HSM (Hardware Security Module) ▪ 鍵の⽣成および署名を実施するハードウェア ▪ ⽣成も署名もハードウェア内で⾏い、秘密鍵がHSM外に出てくることがない • 秘密鍵の作成者さえ秘密鍵を⼀切⾒られない 82

安全な秘密鍵運⽤ • HSM / リモート署名の導⼊ ◦ リモート署名 ▪ データへの署名を、署名者⾃⾝と異なるサーバー/プロセスで実施する ▪ HSM においては、HSMに署名を移譲する 83 Relayer HSM Ethereum Node Transaction Hash Signature

安全な秘密鍵運⽤ • HSM / リモート署名の導⼊ ◦ リモート署名 ▪ データへの署名を、署名者⾃⾝と異なるサーバー/プロセスで実施する ▪ HSM においては、HSMに署名を移譲する 84 Relayer HSM Ethereum Node Transaction Signature

安全な秘密鍵運⽤ • MPCウォレットの導⼊ ◦ MPC: Multi Party Computation (複数参加者による計算) ◦ 秘密鍵を分割して、複数主体で⽣成‧管理することで、安全性を⾼める仕組み ◦ 分割された秘密鍵単体では、完全な署名をつくることができない 85

安全な秘密鍵運⽤ • MPCウォレットの導⼊ ◦ Co-Signer ▪ 分割された鍵を持ち、部分署名を⽣成する ◦ Aggregator ▪ 部分署名を集め、完全な署名を⽣成する 86

安全な秘密鍵運⽤ 87 SRE Co-Signer Transaction Aggregator Partial Signature Partial Signature

安全な秘密鍵運⽤ 88 SRE Co-Signer Transaction Aggregator Partial Signature Partial Signature Full Signature

安全な秘密鍵運⽤ 89 SRE Co-Signer Transaction Aggregator Full Signature

安全な秘密鍵運⽤ • MPCウォレットの導⼊ ◦ MPC Walletにはワークフローエンジンが搭載されている ◦ Co-Signerの挙動は、トランザクション内容よりCo-Signさせるかどうかを事前に決められる ▪ ポリシーを事前定義しておく ▪ e.g. ⾦額が⼤きい場合は、セキュリティ担当者の承認を得られないとCo-Signしない ◦ SREは部分的な鍵による部分署名しかできない ▪ ポリシーにしたがったトランザクションしか提出できない 90

まとめ 91

Copyright © 2025 Datachain, Inc. All Rights Reserved. まとめ •
ゴール: ブロックチェーンR&DビジネスにおけるSRE実装事例を知る • ブロックチェーン/クロスチェーンとは？ • Datachain SREの責務 ◦ クロスチェーンブリッジTOKIのインフラ構築‧運⽤最適化 ◦ クロスチェーンミドルウェア YUI Relayer/LCPの安定化‧運⽤機能改善の推進 • Datachain SREの取り組み ◦ ブロックチェーンノード運⽤最適化 ▪ NaaS (Blockchain Node as a Service) vs. ⾃社運⽤ ◦ クロスチェーンミドルウェアのオブザーバビリティ向上 ▪ エラーログ明⽰化 / 内部‧外部メトリクス / トレーシング ◦ HSM / MPC Walletによる安全な鍵運⽤ ▪ HSMリモート署名 / MPCウォレット 92

EOP 93 ※本資料に記載されている会社名、商品名、サービス名およびロゴは、各社の商標⼜は登録商標です

ブロックチェーンR&D企業における SREの実態 / SRE Kaigi 2025

ブロックチェーンR&D企業における SREの実態 / SRE Kaigi 2025

More Decks by Datachain

Other Decks in Technology

Featured

Transcript