システム構築

仮想通貨EOSの専門家向けvRAMガイド

EOSブロックチェーンは、完全に分散化され主流のオーディエンスにサービスを提供するスケーラブルなアプリケーションを収容する目的で立ち上げられました。

メインネットを立ち上げてからわずか数ヶ月で、EOSはブロックチェーンの活動で競合他社を凌駕してきました。

EOSには、次のようなパラダイムシフトのdAppをサポートするための最適なプロトコルとしての地位を証明するための利害関係の証明と500ミリ秒のブロック時間が与えられています。

RAMが正しく使用されていない

その優れたパフォーマンスにもかかわらず、EOS上のネットワークリソースのコストと制限により、dApp開発者はアプリケーションの構築と拡張を制限されています。

特に、dAppのスマートコントラクトとその状態情報(各ユーザーの残高など)を永続的にRAMに保存するという要件は、dAppのスケーラビリティに対する障壁となっています。

EOSのRAMは、ライブ操作に関連するデータを格納することを役割とするランダムアクセスメモリデバイスよりもハードディスクドライブのように機能するため、誤解を招く用語です。

EOSメインネットは、最大64GBのRAMを搭載して発売され、ブロックプロデューサーは、RAMの総供給量を年間でさらに64GB増やすことに賛成しました。

ただし、現在作成中のdAppでは、ユーザープロファイル、アカウントの残高、および更新された状態情報を保存する必要があるため、RAM要件が数ギガバイトになることが多く、そのため現在のRAMモデルとの互換性がありません。

vRAMシステムの紹介

vRAMシステムは、RAM互換のEOS dAppを構築する開発者向けのエンドツーエンドの分散型代替ストレージソリューションです。

それは、潜在的に無制限の量のデータの保存と検索を手頃な価格で効率的に可能にすることを目的としています。

vRAMシステムにより、EOSのRAMを本来の目的のものにすることができます。使用中のdAppデータのみを格納するための軽量なキャッシュレイヤーで、EOSのRAMから恒久的なデータ保存機能を取り除き、使用中のデータのホワイトボードとして機能できるようにします。

vRAMは、既存のテクノロジスタックの体系的な制限により、これまで想像もできなかったさまざまなdAppに電力を供給するためにDAPPネットワークインフラストラクチャを利用した最初の製品です。

DAPPネットワークは、dApp開発者に追加のストレージ容量、安全な通信、およびその他の重要なユーティリティを提供するサービスを構築するための基盤を形成する、プロビジョニング層とDAPPサービス層で構成されています。

このDAPP基盤の上に置かれているのは、開発者が効率的なデータ検索のために最適化されたおなじみのデータ構造であるマルチインデックステーブルを扱うことを可能にするIPFSサービスレイヤとユニークなvRAMライブラリです。

プロビジョニング層

DAPPネットワークの中心には、EOS dAppを構築する開発者に重要なサービスを提供するDAPPサービスプロバイダ(DSP)があります。

DSPは、自由市場の開発者に提供するサービスパッケージを作成します。特定のサービスパッケージにアクセスするには、dAppスマートコントラクトは、DSPによって定められたサービス契約に従って、十分な量のDAPPトークンを使用する必要があります。

「dappservices」スマートコントラクトは、ステーキングメカニズム、パッケージプロビジョニング、およびクォータ管理を管理します。

各サービス要求はチェーン上で記録され、dAppスマートコントラクトに利用可能な残りのアクションの割り当てを減らします。

オフチェーンサービスの場合、DSPはプロビジョニングレイヤを使用して使用状況を報告しクォータを管理します。

DAPPサービス層

ホワイトペーパーでユーザー契約と呼ばれるdAppスマートコントラクトとのやり取りが必要なDSPサービスの場合、DAPPサービス層には、ユーザー契約がDSPから特定のサービスを要求するためのプロトコルが含まれています。

サービスリクエストは特定のパラメータを持ち、特定の結果で契約への応答をトリガできるという点で、DSPへの「関数のような」呼び出しです。

同期と非同期の2種類のサービス要求があります。

■同期要求
同期要求は、要求が契約に応答を返すまで、ユーザー契約がトランザクションを実行し、それをピアツーピアネットワークに伝播することをブロックします。

vRAMシステムでは、DSPノードがトランザクションを受信し最初にローカルで実行します。
トランザクションによって参照されるRAMテーブルで必要なデータが利用できないため、これが例外をスローします。

例外は、トランザクションの準備ができていないことをDSPに通知してサービスを要求する方法です(ローカルIPFSクラスタファイルの返却、Webオラクル要求の処理、乱数の生成など)

DSPが必要なデータをRAMにロードすると、トランザクションはブロック生成ノードに中継され得る。

ユーザがサービスを必要とするトランザクションをDSP以外のAPIノードに直接送信すると、サービス要求として例外を解析できるのは一意のDSPノードだけであるため単に失敗します。

■非同期要求
コントラクトはサービス要求を表すイベントを送出し、失敗することなくトランザクションの実行を続けます。

非同期要求がvRAMシステムのDAPPサービスレイヤで動作する方法は次のとおりです。
DSPはチェーン上のイベントのストリームを監視し、それらの要求を実行することによって契約がサービスを要求したことを検出します。トランザクション要求をスケジュールします。

非同期要求は要求応答の受信に依存しないため、それらをDSP APIノードに直接送信する必要はありません。

そうではなく、この要求は任意のEOSIOノードから送信することができ、ブロックチェーン上のイベントをリッスンしているDSPノードによって解析されます。

IPFSサービス層

ローカルIPFSクラスタは、コンテンツベースのアドレス指定を使用してファイルにアクセスする分散データストレージソリューションです。各ファイルが特定のIPアドレスを持つサーバー上に存在し、そのアドレスを要求するクライアントによって取得される従来のクライアント/サーバーモデルとは異なり、ローカルIPFSクラスターファイルは、ポインターとして機能する固有リソース識別子(URI)を与えるためにハッシュされます。

与えられたファイルに。DAPPネットワークは、分散型のピアツーピアネットワークにファイルを格納し、それらを安全かつ効率的に取得するためにローカルIPFSクラスタの機能を利用する3つの異なるサービス要求をサポートします。

IPRAMサービスレイヤでは、vRAMシステムは3種類のサービス要求を使用します。
ウォームアップ要求、クリーンアップ要求、およびコミット要求です。

■ウォームアップ要求
ユーザー契約は、そのURIを使用してローカルIPFSクラスターからファイルを取得するためのサービス要求を送信します。

サービス要求を解析して、DSPはファイルを含むペイロードをコントラクトに返します。URIはファイルのハッシュでもあるので、コントラクトはデータをハッシュし、それをその識別子と比較することによってファイルの整合性を簡単に検証できます。

ウォームアップ要求は同期的であり、応答が契約に返されるまで契約の実行をブロックします。

■クリーンアップ要求
クリーンアップ要求は、キャッシュからファイルを削除するようにDSPに要求を送信します。これは非同期要求です。

■コミット要求
コミット要求は、新しいデータをそれらのローカルIPFSクラスタノードに書き込むようにDSPに指示する。

開発者はDSPノードによってキャッチされるコミット要求をディスパッチする前にURIを返すために、最初に新しいデータをハッシュするために、スマートコントラクト内からsetData関数を利用できます。

同様に、getData関数はスマートコントラクトのデータを取得したり、データが見つからない場合にウォームアップを要求したりするために利用できます。

vRAMレイヤー

vRAMレイヤは、スマートコントラクト内から開発者に慣れ親しんだインターフェイスを提供します( マルチインデックステーブル)

vRAMを使用するとローカルのIPFSクラスタから情報を取得し、dApp開発者にとってなじみのある方法で操作することがはるかに効率的になります。

DSPは(vRAMライブラリを使用して)ユーザー契約内にのみ存在するため、DSPソフトウェアを変更することなくシステムのアップグレードや最適化を行うことができます。

vRAMはデータベース全体を表すためにMerkleツリーを使用します。

Merkleツリーの各ノードは、証明が必要な場合にのみ要求に応じて要求されるローカルIPFSクラスター上のファイルとして表されます。

特定のファイルを見つけるには、必要なデータを表すリーフノードに到達するまでツリーをたどる必要があります。データベース全体を表す現在のルートノードのみをRAMに保持する必要があります。

Merkleツリーベースの構造はvRAMレイヤーで2つの役割を果たし、データベースクエリの高速化を可能にするインデックスと、データの有効性を検証できる整合性の証明の両方として機能します。

ボンネット下のvRAM

vRAMが開発者に新世代のdAppを作成する方法を説明するために、スーパーマリオスタイルのランナーゲームを紹介します。

それをスーパーDAPPと呼びましょう。スーパーDAPPスマートコントラクトには2つのアクションがあります。

新しいゲームセッションが始まる前にプレイヤーの進捗状況と現在のスコアをロードする「ゲーム開始」と、ゲームセッションが終了するとプレイヤーのスコアを更新する「スコア変更」です。

この例の一連のトランザクションは5つのステップで行われます。

・信号
・準備し始める
・ロードとトランザクション
・修正する
・キャッシュの消去

信号

(1)ホワイトペーパーでは「ユーザー契約」と呼ばれるvRAMを使用するdAppスマートコントラクトは、DSPノードのEOSIO APIを介してクライアントからトランザクションを受け取ります。

(2)トランザクションを実行するために必要なデータはRAM上ではなくvRAM上にあるため、dAppスマートコントラクトはトランザクションを実行して例外をスローします。この失敗はDSPにサービスが必要であることをシグナリングする手段です。

(3)サービス要求を解析して、DSPは、vRAMに存在するRAMに存在しない必要なデータをすべて検出する。


クライアントのアプリケーション(eosjsインスタンス)はDSP APIノードを介してトランザクションを送信します。DSPによってローカルに実行されるとトランザクションは失敗します。この例外はサービス要求を通知する方法です。

上記のイラストでは、アリスは ‘スーパーDAPP’の新しいラウンドを始める準備ができていて、 ‘スーパーゲーム’取引をスーパーDAPP契約に送ります。

ただし、トランザクションがDSPノードによってローカルに実行されると、彼女の最後のチェックポイントと現在のスコアはRAMから失われます。

これらのデータポイントは新しいゲームセッションをロードするために必要なので、トランザクションはアサーション失敗をスローします。

トランザクションを実行したDSPはシグナルを受け取り、サービス要求を解析します。

準備し始める

(1)DSPは、dAppスマートコントラクトが、特定のサービスパッケージに対して十分な量のDAPPおよび十分な量の利用可能な割当量を有することを検証する。

(2)DSPノードは、欠けているデータポイントを表すローカルIPFSクラスタファイルを中継する。データセット全体の現在の状態を表すMerkleルートのみがRAMに永続的に存在するため、データを表すリーフノードに到達するまでデータセットを表すMerkleツリーをたどることによってデータの整合性が検証されます。

(3) dAppスマートコントラクトは、暗号証明を使用して、要求されたデータが改ざんされていないことを確認します。これで「ウォームアップ要求」フェーズは終了です。


DSPは要求されたファイルをローカルIPFSクラスタから取得し、データセットの整合性の暗号証明をEOS RAMから取得します。それは「ウォームアップ要求」として知られているものでファイルと証明をdAppスマートコントラクトに証明します。

DSPがサービス要求を解析すると、アリスのデータをローカルIPFSクラスターから取得します。
それは彼女の最後のチェックポイントと現在の得点をSuper DAPP契約に伝え、暗号の証明と一緒にして契約がデータの完全性を検証できるようにします。

ロードとトランザクション

(1) dAppスマートコントラクトは、必要なデータをRAM内の一時キャッシュテーブルにロードします。

(2)必要なデータはすべて現在RAM上にあるため、トランザクションはブロックチェーン上のブロックプロデューサーノードに伝播される前に正常に処理できるようになりました。

(3) その他の理由でトランザクションが失敗した場合は、未使用のキャッシュを消去するためにクリーンアップ処理が実行されます。


データの有効性を確認した後、DSPはそれをEOS RAMにロードし、トランザクションをブロックチェーンに送信します。必要なデータはすべてRAMに格納されているため今回は成功します。

データを検証した後、DSPはBPのP2Pエンドポイントにトランザクションを送信することによって、アリスのスコアとチェックポイントをRAM上の一時キャッシュテーブルにロードします。

必要なデータがすべてRAMに格納されたので、トランザクションをブロックプロデューサーノードに送信できます。

修正する

(1)スマートコントラクトがvRAMベースのマルチインデックステーブル内のデータを変更するたびに、変更されたデータと変更の影響を受けたmerkleツリーノードを使用してコミットイベントを送出します。データポイントとメルクルツリーノードは、ローカルIPFSクラスタファイルとして表されます。

(2)ローカルIPFSクラスタのURIとデータのハッシュは同じであるため、契約はデータが実際にDSPによってローカルIPFSクラスタにコミットされる前に予想されるURIを知っています。同じロジックで、2つの異なるDSPが同じデータを個別にキャッシュするか履歴を再生すると、同じローカルIPFSクラスタURIの下でローカルIPFSクラスタにデータが固定されます。

(3)コントラクトは、新しいデータと新しいMerkleツリーノードをRAMキャッシュテーブルに保存します。

(4)契約により、新しいMerkleルートが永久にRAMに保存されます。

(5)ブロックチェーン上の他のイベントと同様に、データを含むコミットイベントもチェーン履歴の一部になります。これにより、履歴を再生することで、どのDSPでもデータを確実に復元できます。

(6)DSPはdemuxサービスを使用してチェーンから来るイベントのストリームをリッスンすることによってイベントをキャッチします。イベントが検出されると、DSPはローカルIPFSクラスタ内のファイルをキャッシュしてインデックスを作成し、すばやく検索できるようにします。

(7) DSPが契約にコミット応答を送信します。

このプロセスの最後に、MerkleルートはEOS RAM上で修正され、新しいデータポイントはDSPの分散ファイルストレージシステムにキャッシュされます。


dAppスマートコントラクトは、インラインアクションによってEOS RAM上のデータを変更します。DSPは変更イベントをリッスンし、新しいファイルをローカルIPFSクラスタノードに書き込みます。

アリスはレベルを終えて彼女の進歩を保存します。

彼女は現在、得点とチェックポイントの進捗状況の両方の点で進歩しています。

Super DAPP契約は、EOS RAM内のデータを変更する新しいデータとともにイベントを送信します。

同時に、DSPはイベントをリッスンし、RAM上のデータに従ってアリスの最新のスコアとチェックポイントを反映するようにローカルIPFSクラスタ上のデータを変更します。

キャッシュの消去

(1)トランザクションが終了した後、DSPはクリーンアップイベントをdAppスマートコントラクトに送り、RAMからデータを削除します。

(2)DSPがdAppスマートコントラクトにクリーンアップアクションを送信し、dAppスマートコントラクトがRAMからデータを削除します。

(3) dAppのスマートコントラクトは、暗号化署名(merkle root)をRAMに残します。これは次のウォームアップリクエストの完全性を検証するために必要です。


データはEOS RAMから削除され、その操作が行われたことを示す暗号証明(Merkle root)が残ります。

ゲームが終了すると、スーパーDAPPスマートコントラクトはデータをRAMから削除し、次のウォームアップ要求の検証に必要な暗号証明を残します。

エンドツーエンドの分散ストレージ

データが変更されるたびに、RAMに格納されているデータセットのMerkleルートが更新されます。そのデータが契約内から要求されると、必要なデータとともにMerkleプルーフがDSPノードによってdAppスマートコントラクトに渡されます。

データベース全体を表す単一のMerkleルートによってdAppスマートコントラクトは、「ウォームアップ要求」として知られるプロセスにおける現在の操作に関連するデータセットの特定部分の妥当性を検証できます。

このようにして、スマートコントラクトはデータセット全体をダウンロードしたり追加の信頼要件を導入したりする必要なしに、テラバイト単位のデータで大規模データベースからの単一エントリを「ウォームアップ」できます。

さらに、スマートコントラクトがvRAMを使用してデータをコミットまたは変更するたびに、データはチェーン履歴の一部になり、予期しない状況が原因でデータが利用できなくなった場合に履歴を再生することで再作成できます。

未来へのDAPP

vRAMはDAPPネットワークの最初の実装に過ぎず、DSP、開発者、およびDAPPトークンの機能を利用してdAppのスケーラビリティを引き出すことができます。

DAPPネットワークの採用が拡大し続けているため、開発者のDAPPコミュニティは、vRAMシステムの新しいユースケースを設計することによってDAPPサービスの機能を拡張することを期待しています。

INFORMATION



おすすめ仮想通貨を購入できる取引所(人気順)

coincheck(コインチェック)
No.1 コインチェック
仮想通貨初心者に使いやすく、アプリの機能も充実の仮想通貨取引所です。

金融庁認可業者 関東財務局長 第00014号

(主な取扱通貨)
Bitcoin ビットコイン BTC Ethereum イーサリアム ETH Ripple リップル XRP BitcoinCache ビットコインキャッシュ BCH litecoin ライトコイン LTC NEM XEM ネム ゼム LISK リスク LSK
bitFlyer(ビットフライヤー)
No.2 ビットフライヤー
取扱通貨及びアプリも重質し、BitcoinFXでも有名な仮想通貨取引所です。

金融庁認可業者 関東財務局長 第00003号

(主な取扱通貨)
Bitcoin ビットコイン BTC Ethereum イーサリアム ETH BitcoinCache ビットコインキャッシュ BCH litecoin ライトコイン LTC LISK リスク LSK monacoin mona モナコイン
Zaif(ザイフ)
No.3 ザイフ
豊富な通貨に加え、板による購入方式のため最安購入可能な取引所。NEMが一番人気

金融庁認可業者 近畿財務局長 第00001号

(主な取扱通貨)
Bitcoin ビットコイン BTC Ethereum イーサリアム ETH BitcoinCache ビットコインキャッシュ BCH NEM XEM ネム ゼム monacoin mona モナコイン
bitbank(ビットバンク)
No.4 ビットバンク
板による購入方式のため最安購入可能な取引所です。リップル取引高No.1

金融庁認可業者 関東財務局長 第00004号

(主な取扱通貨)
Bitcoin ビットコイン BTC Ethereum イーサリアム ETH Ripple リップル XRP BitcoinCache ビットコインキャッシュ BCH litecoin ライトコイン LTC monacoin mona モナコイン
huobi japan(フォービジャパン)
No.5 フォビジャパン
世界2位の取引所の日本版取引所、板注文に加え、豊富な通貨数を誇る

金融庁認可業者 関東財務局長 第00007号

(主な取扱通貨)
Bitcoin ビットコイン BTC Ethereum イーサリアム ETH Ripple リップル XRP BitcoinCache ビットコインキャッシュ BCH litecoin ライトコイン LTC monacoin mona モナコイン
BINANCE(バイナンス)
No.6 バイナンス
世界1の取引高を誇る海外仮想通貨取引所。数百種類の通貨を購入できます。まさに最強です。

金融庁非認可

(主な取扱通貨)
Bitcoin ビットコイン BTC Ethereum イーサリアム ETH Ripple リップル XRP BitcoinCache ビットコインキャッシュ BCH litecoin ライトコイン LTC NEM XEM ネム ゼム LISK リスク LSKetc..
DMMビットコイン DMM BITCOIN
No.7 DMMビットコイン
レバレッジ取引(FX)を主軸においた仮想通貨取引所。FXでは10種類の仮想通貨に対応

金融庁認可業者 関東財務局長 第00010号

(主な取扱通貨)
Bitcoin ビットコイン BTC Ethereum イーサリアム ETH
No.8 GMOコイン
東証一部上場のGMOインターネットのグループ会社で、使いやすいアプリが目玉

金融庁認可業者 関東財務局長 第00006号

(主な取扱通貨)
Bitcoin ビットコイン BTC Ethereum イーサリアム ETH Ripple リップル XRP BitcoinCache ビットコインキャッシュ BCH litecoin ライトコイン LTC