オフチェーンデータによるブロックチェーンのスケーリング

プラトン再発行

フォロワー： 0

ハッシュがXNUMX万語に相当する場合

今では、多くのブロックチェーンのユースケースが金融取引とは関係がないことは明らかです。代わりに、チェーンの目的は、分散型の集約、順序付け、タイムスタンプ、およびアーカイブを可能にすることです どれか 構造化データ、通信、文書などの情報の種類。ブロックチェーンのコアバリューは、信頼できる仲介者に依存することなく、参加者が、いつ誰がどのデータを入力したかについて、証明可能かつ永続的に合意できることです。たとえば、SAPが最近発表したブロックチェーンプラットフォームは、MultiChainおよびHyperledger Fabricをサポートしており、幅広いサプライチェーンやその他の非金融アプリケーションを対象としています。

データの記録にブロックチェーンを使用する最も簡単な方法は、各データをトランザクション内に直接埋め込むことです。すべてのブロックチェーントランザクションは、XNUMX人以上の当事者によってデジタル署名され、すべてのノードに複製され、チェーンのコンセンサスアルゴリズムによって順序付けおよびタイムスタンプが付けられ、改ざん防止の方法で永続的に保存されます。したがって、トランザクション内のすべてのデータは、誰がいつ書き込んだかを示す証拠とともに、すべてのノードによってまったく同じに独立して保存されます。チェーンのユーザーは、いつでもこの情報を取得できます。

たとえば、MultiChain 1.0では、2.0つ以上の名前付き「ストリーム」をブロックチェーン上に作成し、生データの保存と取得に使用できました。各ストリームには独自の書き込み権限のセットがあり、各ノードはサブスクライブするストリームを自由に選択できます。ノードがストリームにサブスクライブされている場合、そのストリームのコンテンツにリアルタイムでインデックスを作成し、順序、タイムスタンプ、ブロック番号、または発行者のアドレスに基づいて、および「キー」（またはラベル）を介してアイテムをすばやく取得できますタグ付けできるアイテム。 MultiChain 1（alpha XNUMX以降）の拡張ストリーム。UnicodeテキストまたはJSONデータ、およびアイテムごとの複数のキーとトランザクションごとの複数のアイテムをサポートします。また、アイテムを同じキーまたはパブリッシャーと便利な方法で組み合わせる「JSONマージ」などの要約機能も追加しました。

機密性とスケーラビリティ

データをブロックチェーンに直接保存することは効果的ですが、機密性とスケーラビリティというXNUMXつの主要な欠点があります。機密性を確保するために、すべてのストリームアイテムのコンテンツはチェーン上のすべてのノードに表示されますが、これは必ずしも望ましい結果ではありません。多くの場合、データの順序付け、タイムスタンプ、および公証を支援するために他のノードが必要な場合でも、データの一部はノードの特定のサブセットにのみ表示されます。

機密性は、トランザクションに埋め込まれる前に情報を暗号化することにより、比較的簡単に解決できる問題です。各データの復号化キーは、それを表示することを意図した参加者とのみ共有されます。鍵の配信は、非対称暗号を使用してチェーン上で実行できます（ここに記載）または、優先されるように、いくつかのオフチェーンメカニズムを介して。アイテムを復号化するためのキーがないノードには、バイナリの意味不明なものしか表示されません。

一方、スケーラビリティはより重要な課題です。適切なブロックチェーンプラットフォームは、500秒あたり100トランザクションのネットワークスループットをサポートするとします。チェーンの目的が情報の格納である場合、各トランザクションのサイズは、主にトランザクションに含まれるデータの量に依存します。各トランザクションには、送信者のアドレス、デジタル署名、およびその他のいくつかのビットとピースを格納するために、少なくともXNUMXバイトのオーバーヘッドも必要です。

各項目が100バイトの小さなJSON構造である簡単なケースを考えると、全体的なデータスループットは、100×（500 + 100）から計算して、毎秒100キロバイトになります。これは、1メガビット/秒未満の帯域幅に変換されます。これは、現代のインターネット接続の容量の範囲内で快適です。データは年間約3テラバイトの割合で蓄積されますが、これは少なからずです。しかし、現在12テラバイトのハードドライブ広く利用可能な, RAID 複数の物理ドライブを単一の論理ドライブに結合するコントローラーでは、手間や費用をかけずに、すべてのノードに10〜20年のデータを簡単に格納できます。

ただし、スキャンしたドキュメントなど、より大きな情報を保存している場合は、状況が大きく異なります。 A4用紙の妥当な品質のJPEGスキャンのサイズは500キロバイトです。これに毎秒500トランザクションを掛けて、250のスループットを調べます。 メガバイト 毎秒。これは、2ギガビット/秒の帯域幅に変換されます。これは、インターネットへの接続はもちろん、ほとんどのローカルネットワークよりも高速です。アマゾンウェブサービスで最も安い公表価格ギガバイトあたり$ 0.05の場合、ノードあたりの年間帯域幅の請求額は$ 400,000になります。そして、各ノードは毎年生成される8000テラバイトの新しいデータをどこに保存しますか？

多くの大きなデータを格納するブロックチェーンアプリケーションでは、単純なオンチェーンストレージは現実的な選択ではないことは明らかです。傷害に侮辱を加えるために、機密性の問題を解決するためにデータが暗号化されている場合、ノードは読み取ることさえできない大量の情報を保存するよう求められています。これは、ネットワークの参加者にとって魅力的な提案ではありません。

ハッシングソリューション

では、どうすればデータのスケーラビリティの問題を解決できるでしょうか。チェーン上のすべてのノードにデータを複製せずに、データのブロックチェーンの分散公証をどのように利用できますか？

答えは、「ハッシュ」と呼ばれる巧妙な技術です。ハッシュとは、データの一部を一意に識別する長い数値（256ビット、つまり80進数で約XNUMX桁）です。ハッシュは、データを使用して計算されます一方向関数これには重要な暗号特性があります。データの一部が与えられると、そのハッシュを計算するのは簡単かつ高速です。しかし、特定のハッシュが与えられた場合、そのハッシュを生成するデータの一部を見つけることは計算上実行不可能です。また、「計算的に実行不可能」とは、既知の宇宙に存在する原子よりも多くの計算を意味します。

ハッシュは、トランザクションとブロックを一意に識別することにより、すべてのブロックチェーンで重要な役割を果たします。また、ビットコインなどの作業証明システムにおける計算の課題も根底にあります。多くの異なるハッシュ関数が開発され、BLAKE2、MD5、RIPEMD160などのgobbledygook名が付けられています。しかし、ハッシュ関数が信頼されるためには、広範な学術的レビューとテストに耐えなければなりません。これらのテストは、「プリイメージ」（特定のハッシュで入力を見つける）、「XNUMX番目のプリイメージ」（特定の入力と同じハッシュでXNUMX番目の入力を見つける）、「衝突」（任意の同じハッシュを持つXNUMXつの異なる入力）。壊れたハッシュ関数の長く悲劇的な歴史が有名な格言「自分の暗号を転がしてはいけない」を証明しているため、このガントレットを生き残るのは簡単ではありません。

元の問題に戻るには、データ自体ではなく、トランザクション内に大きなデータのハッシュを埋め込むことにより、ブロックチェーンのデータスケーラビリティを解決できます。各ハッシュは入力データへの「コミットメント」として機能し、データ自体はブロックチェーンまたは「オフチェーン」の外部に格納されます。たとえば、一般的なSHA256ハッシュ関数を使用すると、500キロバイトのJPEG画像を32バイトの数値で表すことができ、15,000倍以上の削減になります。 500秒あたりXNUMX画像の速度でも、これにより、チェーン自体に格納されているデータに関して、実現可能な帯域幅とストレージ要件の領域に快適に戻ることができます。

もちろん、オフチェーンイメージを必要とするブロックチェーン参加者は、ハッシュからイメージを複製できません。しかし、画像が他の方法で取得できる場合、チェーン上のハッシュは誰がいつ作成したかを確認するのに役立ちます。通常のチェーン上のデータと同様に、ハッシュはデジタル署名されたトランザクション内に埋め込まれ、合意によってチェーンに含まれていました。画像ファイルが空から落ちて、その画像のハッシュがブロックチェーンのハッシュと一致する場合、その画像の起源とタイムスタンプが確認されます。したがって、ブロックチェーンは、画像がチェーンに直接埋め込まれている場合と同じように、公証の点でまったく同じ値を提供します。

配達の質問

ここまでは順調ですね。元のデータではなくブロックチェーンにハッシュを埋め込むことで、スケーラビリティの問題を簡単に解決できます。それにもかかわらず、XNUMXつの重要な質問が残っています。

チェーン自体ではなくても、必要なノードに元のオフチェーンコンテンツをどのように配信しますか？

この質問にはいくつかの考えられる答えがあり、MultiChainユーザーがそれらすべてを適用していることはわかっています。基本的なアプローチのXNUMXつは、信頼できる関係者に集中リポジトリを設定することです。このリポジトリでは、すべてのオフチェーンデータがアップロードされ、その後取得されます。このシステムでは、当然、「コンテンツのアドレス指定」を使用できます。つまり、各データのハッシュは、検索の識別子として直接機能します。ただし、この設定は概念実証には機能する可能性がありますが、ブロックチェーンの目的は信頼できる仲介者を削除することであるため、本番には意味がありません。チェーン上のハッシュが仲介者によるデータの改ざんを防止する場合でも、技術的な障害または不正な従業員の行動が原因で、データを削除したり、一部の参加者への配信に失敗したりする可能性があります。

より有望な可能性は、ポイントツーポイント通信です。この場合、いくつかのオフチェーンデータを必要とするノードが、それを公開したノードから直接要求します。これにより、信頼できる仲介者に依存することは避けられますが、次のXNUMXつの代替の欠点があります。

一部のデータのコンシューマーがパブリッシャーと直接通信できるようにするには、ブロックチェーンアドレスとIPアドレスのマップが必要です。ブロックチェーンは通常、このタイプの静的ネットワーク構成を回避できます。これは、フェイルオーバーとプライバシーの点で問題になる可能性があります。
元のパブリッシャーノードがネットワークを離れた場合、または一時的にサービスが停止している場合は、他のユーザーはデータを取得できません。
多数のノードが一部のデータに関心がある場合、パブリッシャーは要求に圧倒されます。これにより、深刻なネットワークの輻輳が発生し、パブリッシャーのシステムの速度が低下し、そのデータを取得しようとするユーザーに長い遅延が発生する可能性があります。

これらの問題を回避するために、ある種の分散型配信メカニズムを使用するのが理想的です。ノードは、中央リポジトリでもデータの元のパブリッシャーでも、個々のシステムに依存することなく、必要なデータを取得できる必要があります。複数の当事者がデータの一部を持っている場合、それらはそれを望む他の誰にでもそれを配信する負担を分担するべきです。チェーンハッシュはデータが改ざんされていないことを証明できるため、個々のデータソースを信頼する必要はありません。悪意のあるノードがハッシュに対して間違ったデータを配信した場合、そのデータを破棄して、他の人に尋ねることができます。

経験のある方ピアツーピアファイル共有 Napster、Gnutella、BitTorrentなどのプロトコルでは、これはすべて非常に使い慣れたサウンドになります。実際、基本的な原則の多くは同じですが、XNUMXつの重要な違いがあります。まず、企業のコンテキストでブロックチェーンを使用している場合、システムはインターネット全体ではなく、閉じた参加者グループ内で実行されます。第XNUMXに、ブロックチェーンは分散型の順序付け、タイムスタンプ、公証バックボーンを追加し、すべてのユーザーが何がいつ、誰によって何が起こったのかについて、証明可能な一貫性のある改ざん防止ビューを維持できるようにします。

ブロックチェーンアプリケーション開発者は、どのようにしてこのオフチェーンコンテンツの分散型配信を実現できますか？一般的な選択肢のXNUMXつは、既存のピアツーピアファイル共有プラットフォームを使用することです。 InterPlanetaryファイルシステム（IPFS）、それをブロックチェーンと一緒に使用します。各参加者は、ブロックチェーンノードとIPFSノードの両方を実行し、XNUMXつのノード間で調整するミドルウェアがあります。チェーン外のデータを公開する場合、このミドルウェアは元のデータをIPFSに格納し、そのデータのハッシュを含むブロックチェーントランザクションを作成します。チェーン外のデータを取得するために、ミドルウェアはブロックチェーンからハッシュを抽出し、このハッシュを使用してIPFSからコンテンツをフェッチします。ローカルIPFSノードは、取得されたコンテンツをハッシュに対して自動的に検証して、変更されていないことを確認します。

この解決策は可能ですが、すべてが不格好で不便です。まず、すべての参加者がXNUMXつの個別のソフトウェア（ブロックチェーンノード、IPFSノード、ミドルウェア）をインストール、保守、更新する必要があり、それぞれが個別の場所にデータを保存します。次に、XNUMXつの個別のピアツーピアネットワークがあり、それぞれ独自の構成、ネットワークポート、IDシステム、およびアクセス許可があります（ただし、IPFSはまだ閉じたネットワークをサポートしていないことに注意してください）。最後に、IPFSとブロックチェーンを密接に結合すると、ミドルウェアはますます複雑になります。たとえば、一部のブロックチェーントランザクションによって参照されるオフチェーンデータを即座に（自動再試行で）取得したい場合、ミドルウェアを常に稼働させ、独自の複雑な状態を維持する必要があります。ブロックチェーンノードがこれをすべてやってくれたらいいのではないでしょうか？

MultiChain 2.0のオフチェーンデータ

今日私達は解放することを嬉しく思います XNUMX番目のプレビューバージョンマルチチェーン3（アルファ2.0）、オフチェーンデータ用の完全に統合されたシームレスなソリューション。ストリームに公開されたすべての情報は、必要に応じてオンチェーンまたはオフチェーンにすることができ、MultiChainはその他すべてを処理します。

いや、本当は すべてのもの。マルチチェーンを利用する開発者は、ハッシュ、ローカルストレージ、コンテンツの検出、分散型配信、データ検証について心配する必要はありません。ここでは、舞台裏で何が起こるかです：

パブリッシングマルチチェーンノードは、新しいデータをローカルストレージに書き込み、大きなアイテムをチャンクにスライスして、簡単に消化および配信できるようにします。
オフチェーンストリームアイテムを公開するためのトランザクションが自動的に構築され、チャンクハッシュとサイズ（バイト）が含まれます。
このトランザクションは署名され、ネットワークにブロードキャストされ、ノード間で伝播し、通常の方法でブロックチェーンに入ります。
ストリームにサブスクライブしているノードがいくつかのオフチェーンデータへの参照を確認すると、そのデータのチャンクハッシュを検索キューに追加します。（古いストリームをサブスクライブする場合、ノードは以前に発行されたオフチェーンアイテムも取得のためにキューに入れます。）
バックグラウンドプロセスとして、ノードの取得キューにチャンクがある場合、ハッシュによって識別されるように、それらのチャンクを見つけるためにクエリがネットワークに送信されます。
これらのチャンククエリは、ピアツーピア方式でネットワーク内の他のノードに伝達されます（現時点ではXNUMXホップに制限されています。以下の技術的な詳細を参照してください）。
チャンクのデータを持つすべてのノードが応答でき、この応答はクエリと同じパスに沿ってサブスクライバーに中継されます。
ノードがチャンククエリに応答しない場合、チャンクは後で再試行するためにキューに戻されます。
それ以外の場合、サブスクライバーは、（ホップと応答時間に基づいて）チャンクの最も有望なソースを選択し、そのチャンクのデータに対する要求を、前の応答と同じピアツーピアパスに沿って送信します。
ソースノードは、同じパスを再び使用して、要求されたデータを配信します。
サブスクライバーは、元の要求に対してデータのサイズとハッシュを検証します。
すべてがチェックアウトされると、サブスクライバーはデータをローカルストレージに書き込み、ストリームAPIを介してすぐに取得できるようにします。
要求されたコンテンツが到着しなかった場合、または目的のハッシュまたはサイズと一致しなかった場合、チャンクは別のソースからの将来の取得のためにキューに戻されます。

最も重要なのは、これらすべてが非常に迅速に発生することです。低レイテンシのネットワークでは、オフチェーンデータの小さな断片が、それらを参照するトランザクションの2.0秒以内にサブスクライバーに到着します。そして、高負荷アプリケーションの場合、テストにより、MultiChain 3 alpha 1000は、ミッドレンジサーバー（Core i25）でまともな7を超えるオフチェーンアイテムまたは1 MBのオフチェーンデータを毎秒取得する速度を維持できることがわかりました。インターネット接続。チェーン上のデータの64 MBの制限をはるかに超えて、サイズが最大2.0 GBのチェーン外のアイテムですべて正常に動作します。もちろん、ベータ段階でMultiChain XNUMXの最適化に時間を費やしているため、これらの数値をさらに改善したいと考えています。

ストリームでオンチェーンデータではなくオフチェーンデータを使用する場合、マルチチェーンアプリケーション開発者は次のXNUMXつのことを行う必要があります。

データを公開するときは、適切なAPIに「オフチェーン」フラグを渡します。
ストリームクエリAPIを使用するときは、「available」フラグで報告されるように、一部のオフチェーンデータがまだ使用できない可能性を考慮してください。この状況は通常の状況ではまれですが、アプリケーション開発者が適切に処理することが重要です。

もちろん、すべてのノードがすべてのオフチェーンアイテムを取得しないようにするには、アイテムを適切な方法でストリームにグループ化し、各ノードが対象のストリームをサブスクライブするようにします。

チェーン上のアイテムとチェーン外のアイテムを同じストリーム内で使用でき、さまざまなストリームのクエリ機能と要約機能が両方のタイプのデータに同じように関連しています。これにより、パブリッシャーは、アプリケーションの他の部分に影響を与えることなく、ストリーム内のすべてのアイテムに適切な選択を行うことができます。たとえば、人々の活動に関するJSONアイテムのストリームは、個人を特定する情報にはオフチェーンデータを使用し、その他の情報にはオンチェーンデータを使用する場合があります。サブスクライバーは、MultiChainのJSONマージを使用して、両方のタイプの情報をXNUMXつのJSONに結合して読み取ることができます。

オフチェーンストリームアイテムを試してみたい場合は、MultiChainの通常の方法に従ってくださいスタートガイドチュートリアル、セクション5をスキップしないようにしてください。

それでは、次は何ですか？

オフチェーンデータのシームレスなサポートにより、MultiChain 2.0は、大規模データのタイムスタンプと公証に焦点を当てたブロックチェーンアプリケーションに大きな前進をもたらします。長期的には、MultiChainのコミュニティエディションやエンタープライズエディションで、この機能を将来的に強化できる可能性について、すでに考えています。

ストリームの実装 read チェーン外のアイテム、ソルトハッシュ、署名されたチャンククエリ、および暗号化された配信の組み合わせを使用したアクセス許可。
オフチェーンデータが明示的に「忘れられる」ことを許可します。両方とも、自発的に個々のノードによって、またはオンチェーンメッセージに応答してすべてのノードによって自発的に行われます。
選択的ストリームサブスクリプション。ノードは、特定のパブリッシャーまたはキーを持つオフチェーンアイテムのデータのみを取得します。
使い方メルクルの木単一のオンチェーンハッシュが無制限のオフチェーンアイテムを表すことを可能にし、スケーラビリティの点でさらに大きな飛躍をもたらします。
プラグイン可能なストレージエンジン。オフチェーンデータをローカルディスクではなくデータベースまたは外部ファイルシステムに保持できます。
各タイプのオフチェーンデータが通常ネットワークで利用可能であるノードは、時間の経過とともに学習し、チャンククエリを適切に絞り込みます。

私たちはしたいですフィードバックを聞く上記のリストに加えて、一般的にチェーン外のアイテム。 MultiChain 2.0はまだ正式にアルファ版であるため、最終リリース前にこの機能を強化する時間は十分にあります。

その間、MultiChain 2.0コミュニティで計画されている最後の主要機能である「スマートフィルタ」の作業はすでに開始しています。スマートフィルターは、ブロックチェーンに埋め込まれたコードであり、データまたはトランザクションを検証するためのカスタムルールを実装します。スマートフィルターは、「スマートコントラクト」といくつかの類似点があり、同じことの多くを実行できますが、安全性とパフォーマンスの点で重要な違いがあります。今後、さらにお伝えできることを楽しみにしております。

コメントを投稿してください LinkedInの上に.

技術的な詳細

MultiChain 2.0のオフチェーンストリームアイテムは簡単に使用できますが、デザインに関する多くの決定事項や、関心のある追加機能が含まれています。以下のリストは主にブロックチェーンアプリケーションを構築する開発者に関連するものであり、あまり技術的でないタイプではスキップできます。

ストリームごとのポリシー。 マルチチェーンストリームが作成されると、オプションで、チェーン内またはチェーン外のデータのみを許可するように制限できます。これを行う理由はいくつかありますが、各パブリッシャーが自分で決めるのではありません。たとえば、チェーン上のアイテムは確実な可用性保証を提供しますが、古いチェーン外のアイテムは、パブリッシャーや他のサブスクライバーがネットワークから外れると回復できなくなる可能性があります。反対に、チェーン上のアイテムはブロックチェーンを変更せずに「忘れる」ことはできませんが、チェーン外のアイテムはより柔軟です。これは、ヨーロッパの新しいGDPR規制などのデータプライバシー規則の観点から重要になる可能性があります。
チェーンのメタデータ。 オフチェーンアイテムの場合、オンチェーントランザクションには、アイテムの発行元、キー、形式（JSON、テキストまたはバイナリ）、および合計サイズが含まれています。これらはすべて、スペースをほとんどとらないため、アプリケーション開発者が、特定のストリームクエリでオフチェーンアイテムを使用できないことが問題であるかどうかを判断するのに役立ちます。
XNUMXホップ制限。 ピアツーピアネットワーク全体でチャンククエリをリレーする場合、到達可能性とパフォーマンスの間にはトレードオフがあります。すべてのクエリがすべてのパスに沿って伝播されるのは良いことですが、これはネットワークを不要な「チャター」で詰まらせる可能性があります。したがって、現在のところ、チャンククエリは1000ホップに制限されています。つまり、ノードはピアの任意のピアからオフチェーンデータを取得できます。エンタープライズブロックチェーンを特徴付ける傾向があるXNUMXノード未満の小規模なネットワークでは、これはうまく機能すると信じていますが、間違っていることが判明した場合は、この制約を調整（またはパラメーターとして提供）するのは簡単です。
ローカルストレージ。 各MultiChainノードは、効率的なバイナリ形式とLevelDBインデックスを使用して、通常のブロックチェーンディレクトリの「チャンク」ディレクトリ内にオフチェーンデータを格納します。サブスクライブされた各ストリームのアイテムと、ノード自体によって公開されたアイテムには、個別のサブディレクトリが使用されます。これらの各サブディレクトリ内では、重複するチャンク（同じハッシュを持つ）は一度だけ格納されます。ノードがストリームからサブスクライブするとき、そのストリームに対して取得されたオフチェーンデータをパージするかどうかを選択できます。
バイナリキャッシュ。 チェーン上のものであれ、チェーン外のものであれ、大きなバイナリデータを公開する場合、アプリケーション開発者がそのデータを単一のJSON-RPCリクエストでMultiChainのAPIに送信するのは現実的ではありません。そのため、MultiChain 2.0はバイナリキャッシュを実装しています。これにより、大量のデータを複数のAPI呼び出しで構築し、簡単な最終ステップで公開することができます。バイナリキャッシュの各アイテムは、ブロックチェーンディレクトリの「キャッシュ」サブディレクトリに単純なファイルとして保存され、ギガバイトのデータもファイルシステムを介して直接プッシュできます。
モニタリングAPI。 MultiChain 2.0 alpha 3は、オフチェーンデータの非同期取得を監視するためのXNUMXつの新しいAPIを追加します。最初のAPIは、キューの現在の状態を記述し、待機または照会または取得されているチャンクの数（およびデータの量）を示します。 XNUMX番目のAPIは、ノードの起動以降に送信されたすべてのチャンククエリとリクエストの集計統計情報を提供します。
公開時にフラッシュします。 オフチェーンアイテムを発行する場合、MultiChainは、そのデータを参照するトランザクションがネットワークにブロードキャストされる前に、データのローカルコピーが物理ディスクドライブに完全に書き込まれる（またはフラッシュされる）ことを保証します。それ以外の場合、トランザクションをブロードキャストした直後にノードが電力を失うほど運が悪かった場合、オフチェーンデータは永久に失われる可能性があります。チャンクの取得試行間の遅延は時間の経過とともに自動的に増大するため、これはマルチチェーン自体の問題ではありません。しかし、それはアプリケーションレベルで問題を引き起こす可能性があり、誰もがデータの存在を知っていますが、誰もそれを見つけることができません。
パブリッシングのパフォーマンス。 この方法でオフチェーンデータをディスクにフラッシュすると、物理ディスクの速度が遅いため、MultiChainはパフォーマンスを低下させる可能性があります。たとえば、ミッドレンジの7200 rpmのハードドライブは、100秒あたり約10,000回のランダムデータ書き込みしか実行できず、個々のノードがオフチェーンアイテムを公開できる速度が制限されます。この問題には、XNUMXつの回避策があります。まず、最も簡単に言えば、ノードは通常のハードドライブの代わりにソリッドステートデバイス（SSD）ドライブを使用できます。これは、毎秒XNUMXのランダムな書き込み操作をサポートします。次に、「createrawsendfrom」APIを使用して、XNUMXつのトランザクションで複数のオフチェーンアイテムを公開できます。この場合、MultiChainは、トランザクションによって参照されるすべてのオフチェーンデータを単一のディスク操作で書き込みます。最後に、マルチチェーンは、それを参照するトランザクションをブロードキャストする前に、オフチェーンデータをディスクにフラッシュしないように構成できます。このオプションは注意して使用してください。
ネイティブ通貨の統合。 MultiChainは、それを必要とする使用例に対して、トランザクションスパムを防止したり、ブロックバリデーター（「マイナー」）を奨励したりするために、ブロックチェーンでネイティブ通貨を使用するオプションを常に提供しています。これらの場合、トランザクションは、チェーンで中継および確認されるために、バイトのサイズに比例する最小料金をマイナーに提供する必要があります。このメカニズムは拡張され、トランザクションで参照されるオフチェーンデータのキロバイトあたりの最低追加料金を要求することにより、オフチェーンスパムを防止できるようになりました。
ノードをアーカイブします。 ノードがすべてのストリームをサブスクライブして、発行されたすべてのオフチェーンアイテムを取得して保存する場合は、「autosubscribe」ランタイムパラメータを使用してそのように構成できます。このようなノードはネットワーク全体のバックアップとして機能し、他のどのノードが消えても、チェーン外のアイテムが失われたり利用できなくなったりしないことを保証します。これを商用サービスとして提供しているサードパーティ企業を想像できます。