この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本記事に re:Invent 2019 で開催されたチョークトーク「DAT313: How Lambda256 developed a major blockchain platform with AWS databases」のレポートです。
スピーカー
- MinJung Jung
- Account Manager, Amazon Web Services
- Kwunho Jeong
- Chief Strategy Officer, Lambda256
セッション概要
Lambda256 は、AWS 上に構築されたサービスプラットフォームとしてのアジア最大のブロックチェーンの1つであり、Ethereum、Hyperledger、Luniverse mainnet、およびその他の主要なプロトコルをプロビジョニングします。このセッションでは、Lambda256 が仮想通貨取引所のプラットフォームで多数の顧客をサポートする方法を学び、Lambda256 がプラットフォームを構築するために AWS データベースを選択した理由の根拠を聞きます。
レポート
(まずは AWS の MinJung Jung さん)
アジェンダ
- 韓国におけるブロックチェーンマーケット
- Lambda256 とは？
- Luniverse Blockchain Service の紹介
- Amazon DynamoDB を使用して自社 SaaS を構築した方法
- Amazon QLDB の使い方
韓国におけるブロックチェーンマーケット
- まずは韓国の背景を少しお伝えしたい
- 国土は世界で 107 番目と小さく、人口は 28 番目
- 世界経済としては 10 番目
- インターネット普及率は 90% 以上で、どこでも超高速なインターネット速度に驚く
- BTS, PUBG, キム・ヨナ, 柳賢振 … そしてブロックチェーンが有名
- 多くの実験を行い、早期にブロックチェーンを採用したことでも知られる国
- ブロックチェーンについて話すとき、ビットコインまたは仮想通貨について考えるでしょうか
- ビットコインはブロックチェーンの最も古い実装
- Lambda256 の親会社は UPbit と呼ばれる仮想通貨を運営
- かつては世界最大の仮想通貨取引所だった
- 現在では幅広いユースケースを使用して、仮想通貨からブロックチェーンへパライダイムシフトしている
- Lambda256 は韓国市場の発展に重要な役割を果たしている
- ブロックチェーンを使用したサプライチェーン管理の興味深いユースケース
- 4つの利害関係者
- 冷蔵庫にスマートデバイスがある
- ビールの在庫が少なくなると冷蔵庫は検出して自動的に追加注文する
- 注文を受け取ったメーカーは運送会社を通じてビールを出荷する
- ビールが冷蔵庫にストックされ、注文番号と一致する場合、課税される
- このサプライチェーンプロセス全体がブロックチェーンに基づいて構築されている
- 従来、企業間の IT システム統合は困難だった
- すべての出荷プロセスを通じて、即時のコミュニケーションも困難だったが、いまではブロックチェーンで連携している
- ブロックチェーンはサプライチェーンの追跡に役立ち、必要に応じて問題のある商品の記録を作成するのにも役立つ
(紹介されていたデモがコチラのレポートのようですね)
- ブロックチェーンの採用を成功させるには、適切なデータベースソリューションを選択する必要がある
- 単一のデータベースソリューションですべてのニーズを満たすことは困難だし、得策ではない
- 適切なジョブに適切なデータベースを選択する必要がある
- Lambda256 では 3 つのデータベースサービスを使用している
- Amazon RDS
- Amazon DynamoDB
- Amazon QLDB
- まず LevelDB について知る必要がある
- ビットコイン、Hyperledger などのブロックチェーンで広く利用されている Key-Value データベース
- しかし LevelDB の使用には一定の制限がある
- 1 つ目は、LevelDB はキーによって保存およびソートされているため、ブロックを探索するのが難しい
- 2 つ目は、ローカルディスクのためスケールが難しい
- 3 つ目は、ローカルディスクの I/O が高い
- そのため、異なるデータベースを使用することが重要
- Amazon RDS は、AWS キーの管理とアクセス制御
- Amazon DynamoDB は、高いスケーラ日rティとスループットでブロック探索に役立つ
- Amazon QLDB は台帳データベース。完全に集中化され不変
Lambda256 とは？
(ここから Lambda256 の方。本来登壇する方はサンフランシスコで立ち往生しているとか。。なので精一杯開発者のフリをする、との前置きからはじまりましたｗ)
- 2012 年にカカオストックと呼ばれる従来の証券取引所プラットフォームからはじめた
- 韓国では 2 番目の証券取引所プラットフォーム
- FinTech 企業としてスタート
- 2018 年に仮想通貨取引所プラットフォームを開始
- ブロックチェーンエコシステムをサポートする
- ブロックチェーンサービスプラットフォームとして Luniverse を開始
- B2B および B2C
- B2C では分散アプリケーションにフォーカスしている
- B2B では非暗号化ブロックチェーンプロジェクトにフォーカスしている
- 韓国の自動車サプライヤーとたくさんの検証プロジェクトを行っている
Luniverse Blockchain Service の紹介
- Luniverse を思いついた背景
- 暗号化キーは非常にユーザーフレンドリーではない
- エンドユーザはすべてのキーを記憶しなければならない
- Ethereum や Hyperledger のメンテナンスをしなければならない
- エンジニアは不足しており、雇用コストは非常に高価
- 4 つの領域と、現在のブロックチェーン市場の 10 の課題を定義した
- 非常にパフォーマンスの高いサービス
- トークンサービス、DApp サービス、Solidity IDE などの開発ツール
- ユーザー管理
- セキュリティ評価
- ある調査によればスマートコントラクトの 95% に脆弱性がある
- これはエンジニアが不足しているため、多くのエンジニアが一般的な機能のコードをコピー＆ペーストを行っている。そのため機能に脆弱性があると実際に伝播する
- ブロックチェーンではロールバックにはハードフォークを伴い非常にコストがかかるし難しいため、デプロイ前にスマートコントラクトを確認する
- アーキテクチャ概要
- コンセンサスアルゴリズムは PoA
- Lunivers チェーン上に PoA ベースの Ethereum フォークがある
- レイヤー2のサイドチェーン
- トークンチェーンの安全な評価操作や、ユーティリティサービスなど多くのサービスに接続
- RESTful API を介してエンドポイント通信
- ブロックチェーンのコア開発者を雇う必要はない。ブロックチェーンの概念を理解しているウェブ開発者なら誰でも、実際に API を取得し、ブロックチェーン技術をレガシーに取り入れることがでる。それがコンセプト
Amazon DynamoDB を使用して自社 SaaS を構築した方法
- DynamoDB を使用して Luniverse を構築した方法
- これが Luniverse の初期バージョンであり、Amazon RDS で使用を開始した
- ブロックチェーンはサイドチェーンです。各顧客には異なるサイドチェーンがある。そのため Lambda256 の顧客の数が増えると、チェーンの数も増る。
- 問題は、トランザクションの受信を毎回確認する必要があるということ。そのためノードにトランザクションを送信している。
- ノードはブロックを作成し、それらのブロックを他のノードにブロードキャストして伝播する
- システムがトランザクションが成功したか失敗したかをチェックする場合、トランザクションハッシュをチェックする必要があり、以前はポーリング手法を使用していた
- RDS ですべてのトランザクションの受信を確認したが、ノードとパフォーマンスに影響を与えた
Q. 「Proof-of-Work や Proof-of-Time を使っていますか？」
A. 「Proof-of-Authority だけです。権限とそれを行う参加者だけです。なぜなら、私たちはトランザクションのレイヤー2に多くのサイドチェーンを持っているからです。トランザクション検証プロセスの数を膨大になり、RDS では出来なかったで。そこで、DynamoDB を使用して問題を処理しようとします。」
- これは Luniverse のレベル2アーキテクチャ
- チェーンクローラを作成したので、引き出す方法は必要ない
- 受信したすべてのトランザクションハッシュを要求するのではなく、グループを作成している
- そのため、実際にはロールとセカンダリデータを DynamoDB に保存して使用している
- また、非常に古い履歴データにも AuroraDB を使用している
- これは DynamoDB を使用した Luniverse の次のバージョンの概念
- どのように問題を解決したか
- パフォーマンスとスケーラビリティ
- 実際には2つのテーブルを非常に基本的なテーブルにした
- パーティションキーのみを使用している。パーティションに基づいたプレフィックスを見つける
- DynamoDB に保存するときに、データが保存されるノードを定義する基本テーブルを設定する。ただし、キーの種類としてパーティションキーの組み合わせであるセカンダリテーブルも使用する - 各ノードの下にあるブロックのデータの年表が必要 - 異なるノードとブロックのリストを作成するため、保存および照会の2つの異なるメトリックがある。
- これは基本的なテーブル
- たとえばトランザクションの recipt を知りたい場合は、トランザクションのキャッシュを知る必要がある
- まず、トランザクション ID は、ポジション ID から取得でき、チェーン ID に移行でき、さらにトランザクションハッシュを取得できる
- 実際にプラットフォームでお客様のトークンを処理している
- そのため、アドレスから行われるトランザクションとアドレスから行われる転送、トークンから行われるトランザクション、およびトークンから行われる転送とその間の通信を処理する必要がある
- そのため、セカンダリテーブルを作成している
- アドレスごとに予測リストを取得するのはとても奇妙
- これは、トランザクションを保存してデータを転送するために使用しているルールであり、アドレスのバランスも同様
- これがプラットフォームを強化するために DynamoDB を使用する方法
- 私たちはまだ開発中
- S3, Kinesis, Elasticsearch、および DynamoDB の使用を検討している
- これは Luniverse の現在のアーキテクチャ。ほぼ完成した設計です
- Amazon kinesis を使用してトランザクションパイプラインを作成。
- raw データは S3 に送られワークリストにある非常に古い履歴データを Amazon Athena で検索
- ブロックトランザクションとメインネットトランザクションのリアルタイムに近い状態にしたい多くのサービスがある
- ほぼリアルタイムのサービスにするために Amazon Elastic Search を使用
- DynamoDB をますます最新のデータにシフト
Q. 「ここでの主な目標は何ですか?」
A. 「セカンダリテーブルから Elasticsearch へのトランザクション受信データを解析しようとしています。だから、あなたの質問に対する答えは、Elasticsearch にそのデータを使用しているセカンダリテーブルのトランザクション受信に焦点を当てているということです。」
Q. 「これに対して gas の課金モデルはどのように機能しますか？」
A. 「エンドユーザーですよね？ gas 支払いの委任契約を結んでいます。だから、私たちが持っています。トークンを交換するのは危険ではありません、つまりコインです。私たちが隣人だということはリストにありません。実際にエンドユーザーの gas を支払うことができます。委任契約ですが、それは私たちによって非常に管理されているため、取引をブロックしているものが本当に高いというわけではありません。」
Q. 「どれだけの費用がかかりますか？」
A. 「月あたり $2,000ド ル以上だと思う、それは十分すぎる。ええ、実際はとても安いです」
Amazon QLDB を使うときの考慮
- 2018年まではフォーチュンアセスメントプロバイダーの規制がありました
- VASPs(仮想通貨サービスプロバイダ)のような仮想通貨ウォレットは、銀行が行った KYC と AML の面倒を見る必要がある
- これは G20 の金融行動タスクフォースとして今年発表された
- VASPs に対する直接的な規制です。したがって、サービスプロバイダーが顧客デューディリジェンス(以下、CDD)の注意を払わなければならないのは不審な取引レポートも同様
- 当社の親会社は仮想通貨取引を行っているため、これを処理する必要があった
- CDD は現在の金融サービスソリューションプロバイダーの疑わしいトランザクションレポートでも実行可能
- 匿名のウォレットアドレスと受信者のアドレスをどのようにして知ることができるか
- 送信者の CDD と CDD が受信した CDD を知る必要があるが、それは本当に難しい
- ここで準備しているのは LUniverse VASPs ホワイトリスト同盟と呼ばれるもの
- 異なる VASPs からのすべての KYC 結果データを保存し、それらを QLDB に分類
-
分散化という概念は、実際には費用がかかる
- ホワイトリストの非常に単純な API 呼び出しのために24時間、AWS QLDB からのソリューションがある
- それらには不変性と非常に高いスケーラビリティがある
- コンセプトは非常にシンプル。すべての KYC 結果データを QLDB に保存し、参加者は API 呼び出しをプラグインする
- 実際に暗号化を送信する前に、顧客が適切な KYC レベルを持っているかを確認
- QLDB を選択した理由
- 異なるノードを使用せずに移動できるように見えたため
- 非常に集中化されていますが、すべての履歴データを追跡できる
- SQL と同じような使いやすさ、非常に使いやすく、費用対効果も非常に高い
- 私たちの機能に少なくとも全体として KYC データベースが含まれる
- 任意のウォレット、たとえばメタマスクまたは分散ウォレットサービスを行っている
- それらは KYC でなければならないため、任意のウォレットに対して正規化と監査を行っている - トランザクションが適切な KYC レベルで行われたことを後で監査する
- ユーザーシナリオはこのようなものです
- KYC アドレス認証が要求されるため、ウォレットアドレスがあります
- リストされた 100 BTC を私に送る必要がある人がいます
- その送信者は私の CDD モバイルデバイスを知る必要があります
- しかし、私は KYC を持っていないため、暗号センターにリクエストする
- 受信者のアドレスがホワイトリストにない場合、料金は受信者に送られ、受信者は通知をリクエストする
- そして KYC が Luniverse から KYC レベルの KYC 作成される
- ダイジェストを作成し QLDB に追加
- KYC の結果とダイジェスト値は QLDB に保存
- KYC の検証が正しければ実際のインデックスが作成
- ダイジェストのインデックスを使用してすべてのクエリに検索され、タイムスタンプと KYC 正規化データで検索する
- ウォレットテーブル
- ユーザー ID に 暗号 BTC アドレスが含まれるアドレスに変更
- KYC レベル3
- ウォレットデータにドキュメント ID を設定
- データスキーム: 公証ダイジェスト
- ダイジェストを作成、QLDB をソートする
- アドレスが公証された場合、ウォレットのドキュメント ID とタイムスタンプが含まれる
- またダイジェストでインデックスが作成できる
- 次の計画
- 今月中にケースのオープンをアナウンスする
- KYC notarization API を発表
- VASP アライアンスパートナーシップ
さいごに
AWS におけるブロックチェーンサービスは Managed Blockchain や QLDB ですが、その他の AWS データベースサービスなどを組み合わせ、ブロックチェーンのプラットフォームが作られていることがよくわかる事例でした。
韓国はブロックチェーンに関する特許取得も進んでいるブロックチェーン大国になりつつありますので、まだまだ多くのブロックチェーン事例がありそうなのでウォッチしていきたいと思います。
以上！大阪オフィスの丸毛（@marumo1981）でした！
3
