ミリオン質問

おそらくあなたの多くは疑問に思っているでしょう：スマートコントラクトのデータの重量が数百メガバイトで、数十万または数百万のレコードを保存している場合、スマートコントラクトの動作はどのように変化しますか？ トランザクションは増えますか？ これはネットワーク全体にどのような影響を与えますか？ 堅実性のある種の変数は他の変数よりも良い仕事をしますか これらの質問に対する回答を個人的に見つけ、プライベートEthereumネットワークで実験を行い、説明されている状況をシミュレートすることにしました。 このことについては、記事を読んでください。

テストの説明

100万のトランザクションと大量のデータの1つのスマートコントラクトでの読み込みがどのように影響するかを調べたかったのです。



以下のパラメーターが測定されました。

• kgasでの1つのトランザクションのコスト。
• 1つのブロックの作成期間。
• 1ブロックのサイズ。

ブロックチェーンパラメーター



2つの許可された書き込みノードと1つの「パッシブ」からなるプライベートPoAブロックチェーンがあり、そこからトランザクションが送信されました。



3つのノードはすべて同一のサーバーで実行されていました。

• プロセッサー：2 Intel Xeon E5-2670 2.60 GHz。
• RAM：8 GB。
• OS：Windows Server 2012 R2 Datacenter（64ビット）。

スマートコントラクトの説明



2つのスマートコントラクトが作成されました。 1つはフィールドとしてbytes32 => bytes32をマッピングし、もう1つは1次元のbytes32配列をマッピングしました。 各コントラクトには、パラメーターとしてbytes32を受け取り、対応するマッピングまたは配列の要素としてこの値を格納する関数が含まれていました（実際、値はブロックチェーンストレージに格納されていました）。



マッピングを使用した契約の簡単な説明

contract TesterMapping { mapping (bytes32 => bytes32) StoragedData; function Storing(bytes32 data) { if(StoragedData[data]!= "Y") StoragedData[data] = "Y"; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

配列コントラクトの簡単な説明

 Con tract TesterArray { bytes32[] StoragedArray; function Storing(bytes32 data) { for(uint256 i = 0; i < StoragedArray.length; i++) { if(StoragedArray[i] == data) return; } StoragedArray.push(data); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

進捗とテスト結果

最初に、フィールドマッピングを使用したスマートコントラクトがテストされました。 1秒に1回、ランダムな32バイト値でトランザクションが送信されました。 技術的な問題のため、テストは計画よりも少し長くかかり、最初のトランザクションが送信されてから3週間後に100万番目のトランザクションが送信されました。 次に、アレイとのスマートコントラクトがテストされました。



マッピング-契約



実験を通して、トランザクションコストもブロックサイズも有意な値によって変動しませんでした。 各トランザクションは、最初と100万番目の両方で、ほぼ瞬時に処理されました。 ブロックの作成期間は定期的に1秒から9秒に変更されましたが、常に5秒がジェネシスブロックで対称的に設定されました（ブロックnとn + 1の作成の間に1秒が経過すると、9秒後にブロックn + 2が表示されました）平均ブロック作成時間は5秒でした。 ただし、これらの変動の発生に規則性は認められませんでした。おそらく、これは、ネットワークまたはサーバーの補助ソフトウェア（アンチウイルスなど）の動作によるものです。



配列コントラクト



このオプションでは、（一致する値を検索するための）配列検索サイクルが存在するため、1つのトランザクションのコストは、最初の2000トランザクションで40千KGasから200万KGasに増加しました。 同時に、最初の数百のトランザクションの1つのトランザクションの処理時間は、1つのブロックを作成する期間より長くなりました。 このため、1つのトランザクションがせいぜい1つのトランザクションを考慮し始めたため、約500のトランザクションで1つのブロックのサイズが最小に減少し、それ以上は増加しませんでした。 処理時間が非常に速くなり、3,000件のトランザクションを送信した後、結果のキューを「レイキング」すると約4時間かかりましたが、ネットワークは麻痺します（もちろん、「戦闘」ネットワークの送信者がそのような金額高価なトランザクション）。

結論

• マッピングのサイズは、マッピングの処理速度やトランザクションコスト（少なくとも100万要素まで）には影響しません。
• Solidity仮想マシンは、反復ループを使用する場合、非常に非効率的です。
• 多数のレコードを処理するには、マッピングを使用することをお勧めします。

残念ながら、マッピング配列を使用するときに、ストレージ内のデータが特定のスマートコントラクトのデータで占有されている量を判断する方法が見つかりませんでした。 おそらく読者の一人が自分のバージョンを提案できるでしょう。