公開テスト: イーサリアム上のプライバシーとスケーラビリティのためのソリューション

ブロッカイン は、人間の生活の多くの分野を改善することを約束する革新的なテクノロジーです。 実際のプロセスと製品をデジタル空間に転送し、金融取引の速度と信頼性を確保し、コストを削減するだけでなく、分散型ネットワークでスマート コントラクトを使用して最新の DAPP アプリケーションを作成することもできます。

ブロックチェーンの多くの利点と多様な応用を考えると、この有望なテクノロジーがまだすべての業界に浸透していないことは驚くべきように思えるかもしれません。 問題は、現代の分散型ブロックチェーンにはスケーラビリティが欠けていることです。 イーサリアムは 20 秒あたり約 XNUMX トランザクションを処理しますが、これでは今日のダイナミックなビジネスのニーズを満たすには十分ではありません。 同時に、ブロックチェーン技術を利用する企業は、ハッキングやネットワーク障害に対する高度な保護機能を備えたイーサリアムを放棄することに躊躇しています。

ブロックチェーンの分散化、セキュリティ、スケーラビリティを確保し、スケーラビリティのトリレンマを解決するために、開発チームは Opporty Plasma Cash は、スマート コントラクトと Node.js に基づくプライベート ネットワークで構成される補助チェーンであり、その状態を定期的にルート チェーン (イーサリアム) に転送します。

Plasma Cash の主要なプロセス

1. ユーザーはスマート コントラクト関数「deposit」を呼び出し、プラズマ キャッシュ トークンに入金したい ETH の金額をそれに渡します。 スマート コントラクト機能はトークンを作成し、それに関するイベントを生成します。

2. スマート コントラクト イベントにサブスクライブされた Plasma Cash ノードは、デポジットの作成に関するイベントを受信し、トークンの作成に関するトランザクションをプールに追加します。

3. 特別なプラズマ キャッシュ ノードが定期的にプールからすべてのトランザクション (最大 1 万件) を取得し、それらからブロックを形成し、マークル ツリーを計算し、それに応じてハッシュを計算します。 このブロックは検証のために他のノードに送信されます。 ノードは、マークル ハッシュが有効かどうか、およびトランザクションが有効かどうか (たとえば、トークンの送信者がその所有者であるかどうか) をチェックします。 ブロックを検証した後、ノードはスマート コントラクトの「submitBlock」関数を呼び出し、ブロック番号とマークル ハッシュをエッジ チェーンに保存します。 スマート コントラクトは、ブロックの追加が成功したことを示すイベントを生成します。 トランザクションはプールから削除されます。

4. ブロック送信イベントを受信したノードは、ブロックに追加されたトランザクションの適用を開始します。

5. ある時点で、トークンの所有者 (または非所有者) がプラズマ キャッシュからトークンを引き出したいと考えます。 これを行うために、彼は「startExit」関数を呼び出し、トークンの最後の 2 つのトランザクションに関する情報を渡します。これにより、彼がトークンの所有者であることが確認されます。 スマート コントラクトは、マークル ハッシュを使用してブロック内のトランザクションの存在を確認し、引き出し用のトークンを送信します。引き出しは XNUMX 週間後に行われます。

6. トークンの出金操作に違反があった場合（出金手続きの開始後にトークンが使用されたか、出金前にトークンがすでに他人の所有物であった場合）、トークンの所有者は XNUMX 週間以内に出金に異議を唱えることができます。

プライバシーは XNUMX つの方法で実現されます

1. ルート チェーンは、子チェーン内で生成および転送されるトランザクションについては何も知りません。 誰がプラズマ キャッシュに ETH を入金および引き出したかに関する情報は公開されたままです。

2. 子チェーンでは、zk-SNARK を使用した匿名トランザクションが可能になります。

技術スタック

• NodeJS
• Redisの
• エテュリアム
• 土壌

テスト

Plasma Cash の開発中に、システムの速度をテストし、次の結果が得られました。

• 35 秒あたり最大 000 のトランザクションがプールに追加されます。
• 1 つのブロックには最大 000 のトランザクションを保存できます。

テストは次の 3 つのサーバーで実行されました。

1. Intel Core i7-6700 クアッドコア Skylake (含む) NVMe SSD – 512 GB、64 GB DDR4 RAM
3 つの検証用プラズマ キャッシュ ノードが発生しました。

2. AMD Ryzen 7 1700X オクタコア「Summit Ridge」 (Zen)、SATA SSD – 500 GB、64 GB DDR4 RAM
Ropsten テストネット ETH ノードが立ち上がりました。
3 つの検証用プラズマ キャッシュ ノードが発生しました。

3. Intel Core i9-9900K オクタコア (含む) NVMe SSD – 1 TB、64 GB DDR4 RAM
1 つのプラズマ キャッシュ提出ノードが発生しました。
3 つの検証用プラズマ キャッシュ ノードが発生しました。
Plasma Cash ネットワークにトランザクションを追加するテストが開始されました。

合計： プライベート ネットワーク内の 10 個の Plasma Cash ノード。

テスト1

ブロックあたり 1 万トランザクションの制限があります。 したがって、1 万件のトランザクションは 2 つのブロックに分類されます (システムはトランザクションの一部を取得し、送信中に送信できるため)。

初期状態: 最後のブロック #7; 1 万件のトランザクションとトークンがデータベースに保存されます。

00:00 — トランザクション生成スクリプトの開始
01:37 - 1 万件のトランザクションが作成され、ノードへの送信が開始されました
01:46 — 送信ノードはプールから 240k トランザクションを取得し、ブロック #8 を形成します。 また、320 秒以内に 10 のトランザクションがプールに追加されることもわかります。
01:58 — ブロック #8 が署名され、検証のために送信されます
02:03 — ブロック #8 が検証され、マークル ハッシュとブロック番号を使用してスマート コントラクトの `submitBlock` 関数が呼び出されます
02:10 — デモ スクリプトの動作が完了し、1 秒で 32 万件のトランザクションが送信されました。
02:33 - ノードはブロック #8 がルート チェーンに追加されたという情報を受信し始め、240k トランザクションを実行し始めました。
02:40 - 240k トランザクションがプールから削除されました。これらはすでにブロック #8 にあります
02:56 — 送信ノードは残りの 760k トランザクションをプールから取得し、マークル ハッシュと署名ブロック #9 の計算を開始しました。
03:20 - すべてのノードには 1 万 240 のトランザクションとトークンが含まれています
03:35 — ブロック #9 が署名され、検証のために他のノードに送信されます
03:41 - ネットワークエラーが発生しました
04:40 — ブロック #9 の検証の待機がタイムアウトになりました
04:54 — 送信ノードは残りの 760k トランザクションをプールから取得し、マークル ハッシュと署名ブロック #9 の計算を開始しました。
05:32 — ブロック #9 が署名され、検証のために他のノードに送信されます
05:53 — ブロック #9 が検証され、ルート チェーンに送信されます
06:17 - ノードは、ブロック #9 がルート チェーンに追加され、760k トランザクションの実行を開始したという情報を受信し始めました。
06:47 — プールはブロック #9 内のトランザクションをクリアしました
09:06 - すべてのノードには 2 万のトランザクションとトークンが含まれています

テスト2

ブロックごとに 350k の制限があります。 結果として、ブロックは 3 つになりました。

初期状態: 最後のブロック #9; 2万のトランザクションとトークンがデータベースに保存されます

00:00 — トランザクション生成スクリプトはすでに起動されています
00:44 - 1 万件のトランザクションが作成され、ノードへの送信が開始されました
00:56 — 送信ノードはプールから 320k トランザクションを取得し、ブロック #10 を形成します。 また、320 秒以内に 10 のトランザクションがプールに追加されることもわかります。
01:12 — ブロック #10 が署名され、検証のために他のノードに送信されます
01:18 — デモ スクリプトの動作が完了し、1 秒で 34 万件のトランザクションが送信されました。
01:20 — ブロック #10 が検証され、ルート チェーンに送信されます
01:51 - すべてのノードがルート チェーンからブロック #10 が追加され、320k トランザクションの適用を開始するという情報を受信しました
02:01 - ブロック #320 に追加された 10k トランザクションのプールがクリアされました
02:15 — 送信ノードはプールから 350k トランザクションを取得し、ブロック #11 を形成します
02:34 — ブロック #11 が署名され、検証のために他のノードに送信されます
02:51 — ブロック #11 が検証され、ルート チェーンに送信されます
02:55 — 最後のノードがブロック #10 からのトランザクションを完了しました
10:59 — ブロック #9 の送信によるトランザクションはルート チェーンで非常に長い時間がかかりましたが、完了し、すべてのノードがそれに関する情報を受け取り、350k トランザクションの実行を開始しました。
11:05 - ブロック #320 に追加された 11k トランザクションのプールがクリアされました
12:10 - すべてのノードには 1 万 670k のトランザクションとトークンが含まれています
12:17 — 送信ノードはプールから 330k トランザクションを取得し、ブロック #12 を形成します
12:32 — ブロック #12 が署名され、検証のために他のノードに送信されます
12:39 — ブロック #12 が検証され、ルート チェーンに送信されます
13:44 - すべてのノードがルート チェーンからブロック #12 が追加され、330k トランザクションの適用を開始するという情報を受信しました。
14:50 - すべてのノードには 2 万のトランザクションとトークンが含まれています

テスト3

XNUMX 番目と XNUMX 番目のサーバーでは、XNUMX つの検証ノードが送信ノードに置き換えられました。

初期状態: 最後のブロック #84; データベースに保存されたトランザクションとトークンは 0 件です

00:00 — それぞれ 3 万件のトランザクションを生成および送信する 1 つのスクリプトが起動されました
01:38 — 1 万トランザクションが作成され、送信ノード #3 への送信が開始されました
01:50 — 送信ノード #3 はプールから 330k トランザクションを取得し、ブロック #85 (f21) を形成します。 また、350 秒以内に 10 のトランザクションがプールに追加されることもわかります。
01:53 — 1 万トランザクションが作成され、送信ノード #1 への送信が開始されました
01:50 — 送信ノード #3 はプールから 330k トランザクションを取得し、ブロック #85 (f21) を形成します。 また、350 秒以内に 10 のトランザクションがプールに追加されることもわかります。
02:01 — 送信ノード #1 がプールから 250k トランザクションを取得し、ブロック #85 (65e) を形成しました
02:06 — ブロック #85 (f21) が署名され、検証のために他のノードに送信されます
02:08 — 3 秒間で 1 万トランザクションを送信したサーバー #30 のデモ スクリプトが動作を終了
02:14 — ブロック #85 (f21) が検証され、ルート チェーンに送信されます
02:19 — ブロック #85 (65e) が署名され、検証のために他のノードに送信されます
02:22 — 1 万トランザクションが作成され、送信ノード #2 への送信が開始されました
02:27 — ブロック #85 (65e) が検証され、ルート チェーンに送信される
02:29 — 送信ノード #2 がプールから 111855 トランザクションを取得し、ブロック #85 (256) を形成しました。
02:36 — ブロック #85 (256) が署名され、検証のために他のノードに送信されます
02:36 — 1 秒間で 1 万トランザクションを送信したサーバー #42.5 のデモ スクリプトが動作を終了
02:38 — ブロック #85 (256) が検証され、ルート チェーンに送信されます
03:08 — サーバー #2 スクリプトの動作が完了し、1 秒で 47 万件のトランザクションが送信されました
03:38 - すべてのノードがルート チェーンからブロック #85 (f21)、#86(65e)、#87(256) が追加され、330k、250k、111855 トランザクションの適用を開始したという情報を受信しました。
03:49 - ブロック #330 (f250)、#111855(85e)、#21(86) に追加された 65k、87k、256 トランザクションでプールがクリアされました
03:59 — 送信ノード #1 はプールから 888145 トランザクションを取得してブロック #88 (214) を形成し、送信ノード #2 はプールから 750k トランザクションを取得してブロック #88 (50a) を形成し、送信ノード #3 はから 670k トランザクションを取得しましたプールとフォームブロック #88 (d3b)
04:44 — ブロック #88 (d3b) が署名され、検証のために他のノードに送信されます
04:58 — ブロック #88 (214) が署名され、検証のために他のノードに送信されます
05:11 — ブロック #88 (50a) が署名され、検証のために他のノードに送信されます
05:11 — ブロック #85 (d3b) が検証され、ルート チェーンに送信されます
05:36 — ブロック #85 (214) が検証され、ルート チェーンに送信されます
05:43 - すべてのノードが、#88 (d3b)、#89(214) をブロックするルート チェーンから情報を受信し、追加され、670k、750k トランザクションの適用を開始しています
06:50 — 通信障害のため、ブロック #85 (50a) は検証されませんでした
06:55 — 送信ノード #2 がプールから 888145 トランザクションを取得し、ブロック #90 (50a) を形成しました
08:14 — ブロック #90 (50a) が署名され、検証のために他のノードに送信されます
09:04 — ブロック #90 (50a) が検証され、ルート チェーンに送信されます
11:23 - すべてのノードは、ブロック #90 (50a) が追加されたという情報をルート チェーンから受信し、888145 トランザクションの適用を開始します。 同時に、サーバー #3 はブロック #88 (d3b)、#89(214) からのトランザクションをすでに適用しています。
12:11 – すべてのプールが空になる
13:41 — サーバー #3 のすべてのノードには 3 万のトランザクションとトークンが含まれています
14:35 — サーバー #1 のすべてのノードには 3 万のトランザクションとトークンが含まれています
19:24 — サーバー #2 のすべてのノードには 3 万のトランザクションとトークンが含まれています

障害物

Plasma Cash の開発中に、次の問題が発生しましたが、徐々に解決され、解決されています。

1. さまざまなシステム機能の相互作用における競合。 たとえば、プールにトランザクションを追加する機能により、ブロックの送信と検証の作業がブロックされ、またその逆の場合も同様であり、速度の低下につながりました。

2. データ転送コストを最小限に抑えながら膨大な数のトランザクションを送信する方法はすぐにはわかりませんでした。

3. 高い結果を達成するためにデータをどこにどのように保存すればよいかは明確ではありませんでした。

4. 1 万トランザクションを含むブロックのサイズは約 100 MB を占めるため、ノード間のネットワークをどのように構成するかは明確ではありませんでした。

5. シングルスレッド モードで作業すると、長い計算 (マークル ツリーの構築やそのハッシュの計算など) が発生したときにノード間の接続が切断されます。

私たちはこれらすべてにどのように対処したのでしょうか?

Plasma Cash ノードの最初のバージョンは、トランザクションの受け入れ、ブロックの送信と検証、データにアクセスするための API の提供など、すべてを同時に実行できる一種の組み合わせでした。 NodeJS はネイティブにシングルスレッドであるため、重いマークル ツリー計算関数がトランザクション追加関数をブロックしていました。 この問題を解決するには XNUMX つのオプションがあることがわかりました。

1. それぞれが特定の機能を実行する複数の NodeJS プロセスを起動します。

2. worker_threads を使用して、コードの一部の実行をスレッドに移動します。

その結果、両方のオプションを同時に使用しました。つまり、3 つのノードを論理的に XNUMX つの部分に分割し、個別に動作できると同時に同期的に動作できるようにしました。

1. 送信ノード。プールへのトランザクションを受け入れ、ブロックを作成します。

2. ノードの有効性をチェックする検証ノード。

3. API ノード - データにアクセスするための API を提供します。

この場合、cli を使用して Unix ソケット経由で各ノードに接続できます。

マークル ツリーの計算などの重い操作を別のスレッドに移動しました。

このようにして、すべてのプラズマ キャッシュ機能を同時に、障害なく正常に動作させることができました。

システムが機能するようになったら、速度のテストを開始しましたが、残念なことに、5 秒あたり 000 トランザクション、ブロックあたり最大 50 トランザクションという満足のいく結果は得られませんでした。 何が間違って実装されたのかを把握する必要がありました。

まず、システムのピーク能力を調べるために、プラズマ キャッシュと通信するメカニズムのテストを開始しました。 Plasma Cash ノードは Unix ソケット インターフェイスを提供すると以前に書きました。 当初はテキストベースでした。 json オブジェクトは「JSON.parse()」と「JSON.stringify()」を使用して送信されました。

```json
{
  "action": "sendTransaction",
  "payload":{
    "prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
    "prevBlock": 41,
    "tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
    "newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
    "type": "pay",
    "data": "",
    "signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
  }
}
```

このようなオブジェクトの転送速度を測定したところ、毎秒約 130k であることがわかりました。 json を操作するための標準関数を置き換えようとしましたが、パフォーマンスは向上しませんでした。 V8 エンジンは、これらの操作に対して十分に最適化されている必要があります。

私たちはクラスを通じてトランザクション、トークン、ブロックを扱いました。 このようなクラスを作成すると、パフォーマンスが 2 分の XNUMX に低下しました。これは、OOP が私たちには適していないことを示しています。 すべてを純粋に関数型のアプローチに書き直す必要がありました。

データベースへの記録

当初、Redis は、キーと値のストレージ、ハッシュ テーブル、セットの操作など、私たちの要件を満たす最も生産的なソリューションの 80 つとしてデータ ストレージに選ばれました。 redis-benchmark を起動したところ、1 パイプライン モードで XNUMX 秒あたり最大 XNUMX の操作が得られました。

高いパフォーマンスを実現するために、Redis をより細かく調整しました。

• UNIX ソケット接続が確立されました。
• ディスクへの状態の保存を無効にしました (信頼性を高めるために、レプリカをセットアップして別の Redis でディスクに保存できます)。

Redis では、XNUMX つのクエリですべてのトランザクションを取得し、トランザクションを XNUMX つずつ削除できる必要があるため、プールはハッシュ テーブルです。 通常のリストを使用してみましたが、リスト全体をアンロードすると速度が遅くなります。

標準の NodeJS を使用すると、Redis ライブラリは 18 秒あたり 9 トランザクションのパフォーマンスを達成しました。 速度はXNUMX倍に落ちました。

ベンチマークによって可能性が明らかに 5 倍大きいことが示されたため、最適化を開始しました。 ライブラリを ioredis に変更したところ、25 秒あたり 32k のパフォーマンスが得られました。 hset コマンドを使用してトランザクションを XNUMX つずつ追加しました。 そのため、Redis で大量のクエリを生成していました。 トランザクションをバッチに結合し、それらを XNUMX つのコマンド `hmset` で送信するというアイデアが生まれました。 結果は毎秒 XNUMXk になります。

以下で説明するいくつかの理由により、`Buffer` を使用してデータを操作します。結局のところ、書き込む前にデータをテキスト (`buffer.toString('hex')`) に変換すると、追加のデータを取得できます。パフォーマンス。 したがって、速度は毎秒 35k に増加しました。 現時点では、さらなる最適化を中止することを決定しました。

次の理由により、バイナリ プロトコルに切り替える必要がありました。

1. システムはハッシュや署名などを計算することが多く、そのために「バッファ」内のデータが必要です。

2. サービス間で送信される場合、バイナリ データはテキストよりも軽量です。 たとえば、1 万件のトランザクションを含むブロックを送信する場合、テキスト内のデータは 300 メガバイトを超える可能性があります。

3. データを継続的に変換するとパフォーマンスに影響します。

したがって、私たちは、素晴らしい「バイナリ データ」ライブラリに基づいて開発された、データの保存と送信のための独自のバイナリ プロトコルを基礎として採用しました。

その結果、次のようなデータ構造が得られました。

-取引

  ```json
  {
    prevHash: BD.types.buffer(20),
    prevBlock: BD.types.uint24le,
    tokenId: BD.types.string(null),
    type: BD.types.uint8,
    newOwner: BD.types.buffer(20),
    dataLength: BD.types.uint24le,
    data: BD.types.buffer(({current}) => current.dataLength),
    signature: BD.types.buffer(65),
    hash: BD.types.buffer(32),
    blockNumber: BD.types.uint24le,
    timestamp: BD.types.uint48le,
  }
  ```

— トークン

  ```json
  {
    id: BD.types.string(null),
    owner: BD.types.buffer(20),
    block: BD.types.uint24le,
    amount: BD.types.string(null),
  }
  ```

-ブロック

  ```json
  {
    number: BD.types.uint24le,
    merkleRootHash: BD.types.buffer(32),
    signature: BD.types.buffer(65),
    countTx: BD.types.uint24le,
    transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
    timestamp: BD.types.uint48le,
  }
  ```

通常のコマンド `BD.encode(block, Protocol).slice();` と `BD.decode(buffer, Protocol)` を使用して、データを Redis に保存したり、別のノードに転送して取得したりするための `Buffer` に変換します。データを戻します。

サービス間でデータを転送するための 2 つのバイナリ プロトコルもあります。

— UNIX ソケット経由でプラズマ ノードと対話するためのプロトコル

  ```json
  {
    type: BD.types.uint8,
    messageId: BD.types.uint24le,
    error: BD.types.uint8,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

ここで：

• `タイプ` — 実行されるアクション。たとえば、1 — sendTransaction、2 — getTransaction。
• 「ペイロード」 — 適切な関数に渡す必要があるデータ。
• `メッセージID` — 応答を識別できるメッセージ ID。

— ノード間の対話のためのプロトコル

  ```json
  {
    code: BD.types.uint8,
    versionProtocol: BD.types.uint24le,
    seq: BD.types.uint8,
    countChunk: BD.types.uint24le,
    chunkNumber: BD.types.uint24le,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

ここで：

• 「コード」 — メッセージ コード。例: 6 — PREPARE_NEW_BLOCK、7 — BLOCK_VALID、8 — BLOCK_COMMIT。
• `バージョンプロトコル` — プロトコルのバージョン。異なるバージョンのノードがネットワーク上で起動され、異なる動作をする可能性があるため。
• `シーケンス` — メッセージ識別子。
• `カウントチャンク` и `チャンク番号` 大きなメッセージを分割するために必要です。
• 「長さ」 и 「ペイロード」 長さとデータ自体。

データを事前に入力したため、最終的なシステムはイーサリアムの「rlp」ライブラリよりもはるかに高速です。 残念ながら、将来的にはスマートコントラクトを完成させる必要があるため、まだ拒否できません。

なんとかそのスピードに到達できたら 35 000 30 秒あたりのトランザクションを最適な時間で処理する必要もあります。 おおよそのブロック形成時間は XNUMX 秒かかるため、ブロックに含める必要があります。 1 000 000 トランザクション、つまりより多くの送信を意味します 100 MB のデータ。

当初、ノード間の通信に「ethereumjs-devp2p」ライブラリを使用していましたが、それほど多くのデータを処理できませんでした。 その結果、`ws` ライブラリを使用し、WebSocket 経由でバイナリ データを送信するように設定しました。 もちろん、大きなデータ パケットを送信するときに問題も発生しましたが、パケットをチャンクに分割したことで、これらの問題はなくなりました。

マークルツリーの形成とハッシュの計算も行う 1 000 000 トランザクションには約が必要です 10 数秒間の連続計算。 この間、すべてのノードとの接続は切断されます。 この計算を別のスレッドに移動することが決定されました。

結論：

実際、私たちの発見は新しいものではありませんが、何らかの理由で多くの専門家は開発中にそれらを忘れてしまいます。

• オブジェクト指向プログラミングの代わりに関数型プログラミングを使用すると、生産性が向上します。
• モノリスは、生産的な NodeJS システムのサービス アーキテクチャよりも悪いです。
• 大量の計算に「worker_threads」を使用すると、特に I/O 操作を処理する場合のシステムの応答性が向上します。
• unix ソケットは http リクエストよりも安定しており、高速です。
• ネットワーク経由で大規模なデータを迅速に転送する必要がある場合は、WebSocket を使用してバイナリ データをチャンクに分割して送信し、到着しない場合は転送して、XNUMX つのメッセージに結合することをお勧めします。

ぜひご訪問ください GitHubの プロジェクト： https://github.com/opporty-com/Plasma-Cash/tree/new-version

この記事の共同執筆者は、 アレクサンダー・ナシバン、シニア開発者 クレバーソリューション株式会社.

出所： habr.com