この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。AWS事業本部の木村です。
今回は 2023 年 4 月 20 - 21 日にわたって開催された AWS Summit Tokyo 2023 のセッションレポートです。
セッション概要
Web3 には特有の課題がいくつか存在します。鍵管理、Wallet、マルチチェーンの扱い、スケーリング、ガスレストランザクション、オフチェーンとの使い分け、ブロックチェーンの分析、etc.. よくある課題をどのように解決するかについてお話します。
スピーカー
アマゾン ウェブ サービス ジャパン合同会社
技術統括本部
Blockchainプロトタイプエンジニア
深津 颯騎氏
セッション視聴
5/22からAWS Summit Tokyoの登録を行うことでオンデマンドで視聴が可能になりました！（現地参加された方は改めての登録は不要です。）
https://aws.amazon.com/jp/summits/tokyo/
登録済みの場合、以下から直接遷移できます。
https://jpsummit.awsevents.com/public/session/view/564
レポート
アジェンダ
1.Web2とWeb3のシステム構成の違いと諸課題に関して
2.オンチェーンとオフチェーンの使い分け
3.スケーラビリティ
4.マルチチェーン展開
5.ウォレットと秘密鍵管理
6.データ分析
7.まとめ
Web2とWeb3のシステム構成の違いと諸課題に関して
- Web2とWeb3のシステム構成の違い
- Web2とWeb3に関してはほとんど同じである
- Web2からWeb3に追加されているもの
- ブロックチェーン
- ウォレット
- ブロックチェーンとウォレットの２つが追加されただけであるが、とても複雑になった
- Web3サービス検討時の諸課題
- オンチェーンとオフチェーンの使い分けがわからない
- アプリケーションをスケールさせていきたい
- 複数のチェーンでサービスを展開させていきたい
- 秘密鍵を誰がどのように管理していけばよいか
- データ分析のためのデータ収集をどのようにすればよいか
オンチェーンとオフチェーンの使い分け
- なぜオンチェーンとオフチェーンを使い分ける必要があるのか
- ブロックチェーンには以下のような苦手分野がある
- 大量のWrite作業
- 高速な参照
- 大容量データの保存
- データ分析
- 複雑な処理
- このギャップを埋めるために
- ブロックチェーンが得意なところはブロックチェーンを利用する
- 他者と共有する必要のあるデータ
- 公開情報にしたいデータ
- 耐改竄性が求められるデータ
- ブロックチェーンが苦手なところはブロックチェーン以外（オフチェーン）を利用する必要がある
- 画像、動画、3Dモデルなどの大容量データ
- 他者と共有しないデータ
- 分析、探索
- イベントドリブンな他システム連携
- 複雑なロジック
- ブロックチェーンが得意なところはブロックチェーンを利用する
- ブロックチェーンには以下のような苦手分野がある
- ブロックチェーンの管理について
- ブロックチェーンのノード管理が大変である点
- OSやミドルウェアのメンテナンス
- 頻繁に行われるブロックチェーンノードのバージョンアップ
- 月4回程度実施が必要、2日間隔で対応が必要なこともある
- 増え続けるストレージ
- 運用ノウハウを持つエンジニアが少ない
- トラブルは一期一会
- Amazon Managed Blockchainについて
- Amazon Managed Blockchainを利用すると解決できること
- ノードの管理が不要になる
- ストレージの自動拡張
- 複雑なセットアップが不要
- Amazon Managed Blockchainの対応しているプラットフォーム
- Ethereum
- Hyperledger Fabric
- Amazon Managed Blockchainを利用すると解決できること
- ブロックチェーンのノード管理が大変である点
- オフチェーンで利用できるAWSサービスの一例
- Amazon CloudFront
- Amazon S3
- Amazon API Gateway
- AWS Lambda
- Amazon DynamoDB
- Amazon Aurora
- Amazon ECS
- Amazon Redshift
- Amazon Athena
スケーラビリティ
- 参照のスケーラビリティ
- アクセスパターンによって参照先を変更する必要がある
- ブロックチェーンへの参照はなるべく減らしたい
- DBにキャッシュさせるなどが有効
- アクセスパターンによって参照先を変更する必要がある
- 更新のスケーラビリティ
- 高速で多くのトランザクションを扱えるパブリックブロックチェーンを採用する
- パブリックチェーンとプライベートチェーンのハイブリット構成を採用する
- こちらのパターンが近年増えてきている
- 他のワークロードの過負荷の影響を軽減することができる
- 優先度の高い処理が割り込んでくることによって遅延が起こることがある
- ハイブリッド構成にすることでパブリックチェーンの影響を軽減できる
マルチチェーン展開
- マルチチェーンが必要な理由
- チェーンごとに経済圏を形成しているため
- Bridgeは可能だが簡単ではない
- Bridgeでトークンを持ち込むことができても、元々のサービスで使えない
- 複数のチェーンでサービスを展開することで、幅広いユーザーにアプローチができるようになる
- マルチチェーン展開を行う際の課題
- スマートコントラクト以外にも複製が必要
- スマートコントラクトを他のチェーンにデプロイして完了というわけではない
- バックエンドやテスト環境を構築する必要がある
- 一つのシステムにつき環境分（本番。ステージング、開発など）の構築が必要でとても負荷が高い
- 解決策
- AWSで環境を構築するのであればAWS CDKやAWS Cloud Formationで環境構築の自動化ができる
ウォレットと秘密鍵管理
- よく聞かれるテーマである
- 管理方法は主に３種類
- ユーザー自身で管理
- 第三者による管理
- サービス提供者による管理
- ウォレット用の秘密鍵管理で求められる要件
- 様々な形式を取り扱えること
- 秘密鍵
- HD Wallet
- mnemonic
- 暗号化できること
- アクセスコントロールができること
- 様々な形式を取り扱えること
- どこで管理するのがよいか
- 秘密鍵の役割から理解されていない方が結構大勢いる
- この場合は第三者もしくはサービス提供者に管理してもらった方が良いパターンが多い
- 秘密鍵の役割から理解されていない方が結構大勢いる
- サービス提供者による管理
- サービス提供者側になって考えてみる
- ユーザーから預かった秘密鍵だけでなく提供者側の秘密鍵の守り方も考えていく必要がある
- AWSでの秘密鍵の管理に利用できるアーキテクチャの一例
- Amazon Cognito
- Amazon API Gateway
- AWS Lambda
- AWS Secrets Manager
- AWS KMS
- サービス提供者側になって考えてみる
- 以下のような厳密なコントロールを求める場合
- 電子署名の実行条件にルールを設けたい
- ルール変更は承認を必要とさせたい
- 分離されたセキュアな環境で秘密鍵を扱いたい
- AWS Nitro Enclavesを利用することで要件を実現できる
-
AWS Nitro Enclavesについて
- 高度な機密情報の保護や安全措置を向上する、分離されたコンピューティング環境
- どのようなことが実現できるか
- デバックコンソールから機密データアクセスや復号を防ぐ
- コンテナへの接続を制御できる
- 実行コードの改変に承認が必要になるように設定できる、承認手続きの正しさも保証できる
- スマートコントラクトに悪意のある書き換えができないように制御できる
- AWS KMSへのアクセスをAWS Nitro Enclavesからのみにするように制限を行うことができる
データ分析
- オンチェーンのデータ分析
- 具体例
- ゲーム内のトークンが流通している様子を可視化したい
- 諸湯圏移転の履歴を追跡したい
- 過去の売買の記録を参照したい
- あるウォレットの活動をトラッキングしたい
- これらの実現には以下の考慮が必要
- 分析に必要なデータの数
- ブロックチェーンの参照回数
- 参照にかかる時間
- 具体例
- Web3用のデータ分析基盤の課題
- データを集める
- ブロックチェーンの過去データが変わる可能性がゼロではない
- ブロックの巻き戻り
- reorg
- 複数の情報源からデータの収集を行う必要がある
- ブロックチェーンの過去データが変わる可能性がゼロではない
- データを保存する
- ストレージが増加し続ける
- データフォーマットが定まっていない
- データを分析する
- 分析対象のデータ容量が大きい
- 複数の情報を横断して分析したい
- データを集める
- 提供しているソリューション
- データを集める
- AWS Public Blockchain Dataを利用する
- データを保存する
- Glueを活用する
- S3にデータを保管する
- データを分析する
- RedShiftを活用する
- SageMakerを活用する
- データを集める
まとめ
- オンチェーンとオフチェーンの使い分け
- 適材適所で使い分けよう
- ブロックチェーンが苦手な箇所は積極的に他のサービスを利用する
- 適材適所で使い分けよう
- スケーラビリティ
- キャッシュを利用できるものは積極的に利用し、ブロックチェーンへの参照を減らしていく
- 負荷分散が必要な時はハイブリッド構成を選択肢に入れること
- マルチチェーン
- スマートコントラクト実行エンジンが同じであれば、移植は容易
- ブロックチェーン以外の部分も環境ごとに構築が必要になるのでCDKやCloudFormationで自動化する
- ウォレットと鍵管理
- Secret ManagerとKMSを活用する
- 厳密な管理が必要な場合はNitro Enclavesのような分離されたセキュアな環境を活用する
- データ分析
- Public Blockchain Dataを利用する
- RedShiftやSageMakerを活用して分析を行う
感想
Web3をAWSで構築していくにあたり、どのようなサービスを利用していけば良いのかの説明がわかりやすかったです。
以前に検証でAmazon Managed Blockchainを構築した経験があるのですが、機能について理解できておらずノード管理の大変なところをこんなにカバーしてくれていたことを知らずに利用しておりサービスについて理解少ないまま検証していたなあと今更ながらに反省していました。ブロックチェーン部分の管理だけでなく、環境構築に関してもAWSで環境作成するのが、負荷が大幅に軽減できるというのということを学ぶことができました。ブロックチェーンを使って何かをするというのはノウハウが少なくいまだにハードルが高そうですが機会があればまたチャレンジしてみたいと思いました。
この記事がどなたかの参考になれば幸いです。
以上、AWS事業本部の木村でした。