イーサリアムは、初期コイン提供（ICO）プラットフォームとして非常に人気があります。 ただし、ERC20トークンだけでなく使用されます。 ルーレット、宝くじ、カードゲーム-これらはすべて、イーサリアムブロックチェーンに実装できます。 他の実装と同様に、イーサリアムブロックチェーンは偽物ではなく、分散型で透過的です。 Ethereumでは、チューリング完全なプログラムを実行できます。プログラムは通常、プログラミング言語Solidityで作成されています。 プラットフォームの創設者によると、これはシステムを「グローバルなスーパーコンピューター」に変えます。 これらの特性は、ユーザーの信頼が特に重要なギャンブルアプリケーションで役立ちます。



イーサリアムブロックチェーンは決定論的であるため、ギャンブルアプリケーションの不可欠な部分である疑似乱数ジェネレーター（PRNG）を作成する際に特定の困難が生じます。 SolidityでのPRNGの安全性を評価し、脆弱性とPRNGの将来の状態を予測する機能につながる特徴的な設計エラーを強調するために、スマートコントラクトを調査することにしました。



私たちの研究はいくつかの段階で実施されました。

1. 3649スマートコントラクトに関する情報は、etherscan.ioおよびGitHubで収集されています。
2. 契約は無料のElasticsearch検索エンジンにインポートされました。
3. 機能的な検索とフィルタリングにKibana Webインターフェースを使用すると、PRNGの72のユニークな実装が見つかりました。
4. 手動評価の後、43のスマートコントラクトが脆弱であると認識されました。

脆弱なアプリケーション

分析により、脆弱なPRNGの4つのカテゴリが特定されました。

• エントロピーのソースとしてブロック変数を使用するPRNG。
• 以前のブロックのハッシュに基づくPRNG。
• 疑わしい秘密のシードと組み合わせた前のブロックのハッシュに基づくPRNG。
• トランザクションアヘッドの脆弱性（フロントランニング）に対して脆弱なPRNG。

各カテゴリの脆弱なコードの例を見てみましょう。

可変グループを使用したPRNG

エントロピーのソースと間違われるいくつかのブロック変数は次のとおりです。

• block.coinbase
  
  
  
  現在のブロックを見つけた鉱夫の住所。
• block.difficulty
  
  
  
  現在のブロックをマイニングするときの複雑さの相対的な指標。
• block.gaslimit
  
  
  
  ブロック内のトランザクションの最大ガス消費量。
• block.number
  
  
  
  現在のブロックの高さ。
• block.timestamp
  
  
  
  ブロックが見つかったときのタイムスタンプ。

まず第一に、鉱夫はブロックのすべての変数を操作できるため、この理由だけではエントロピーのソースとして使用できません。 さらに重要なことは、ブロック変数がブロック内で明らかに同じであることです。 したがって、攻撃者の契約が内部メッセージを通じて被害者の契約を参照している場合、両方の契約で同じPRNが同じ結果を生成します。



例1（ 0x80ddae5251047d6ceb29765f38fed1c0013004b7 ）：

 // Won if block number is even // (note: this is a terrible source of randomness, please don't use this with real money) bool won = (block.number % 2) == 0;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例2（ 0xa11e4ed59dc94e69612f3111942626ed513cb172 ）：

 // Compute some *almost random* value for selecting winner from current transaction. var random = uint(sha3(block.timestamp)) % 2;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例3（ 0xcC88937F325d1C6B97da0AFDbb4cA542EFA70870 ）：

 address seed1 = contestants[uint(block.coinbase) % totalTickets].addr; address seed2 = contestants[uint(msg.sender) % totalTickets].addr; uint seed3 = block.difficulty; bytes32 randHash = keccak256(seed1, seed2, seed3); uint winningNumber = uint(randHash) % totalTickets; address winningAddress = contestants[winningNumber].addr;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブロックハッシュのPRNG

Ethereumチェーンの各ブロックには検証ハッシュがあります。 Ethereum Virtual Machine（EVM）では、 block.blockhash()



関数を使用してこれらのハッシュを取得できます。 この関数は、ブロック番号を示す数値引数を受け取ります。 この調査の過程で、 block.blockhash()



関数の実行結果は、 block.blockhash()



実装でしばしば誤って使用されることがblock.blockhash()



。



このような脆弱なPRNGには、主に3つの種類があります。

• block.blockhash(block.number)
  
  
  
  、現在のブロックのハッシュ。
• block.blockhash(block.number - 1)
  
  
  
  、最後のブロックのハッシュ。
• block.blockhash()
  
  
  
  、現在のブロックから少なくとも256ブロック離れたブロックのハッシュ。

これらの各ケースを見てみましょう。



block.blockhash（block.number）



状態変数block.number



使用すると、現在のブロックの高さを知ることができます。 マイナーが契約コードを実行するトランザクションを選択すると、このトランザクションを含む将来のブロックのblock.number



変数がわかっているため、契約は確実にその値を取得できます。 ただし、EVMでのトランザクションの時点では、作成中のブロックのハッシュは明らかな理由でまだわかっておらず、EVMは常にゼロを返します。



一部のコントラクトは、式block.blockhash(block.number)



誤って解釈します。 これらのコントラクトでは、現在のブロックのハッシュは実行時に既知であると見なされ、エントロピーのソースとして使用されます。



例1（ 0xa65d59708838581520511d98fb8b5d1f76a96cad ）：

 function deal(address player, uint8 cardNumber) internal returns (uint8) { uint b = block.number; uint timestamp = block.timestamp; return uint8(uint256(keccak256(block.blockhash(b), player, cardNumber, timestamp)) % 52); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例2（ https://github.com/axiomzen/eth-random/issues/3 ）：

 function random(uint64 upper) public returns (uint64 randomNumber) { _seed = uint64(sha3(sha3(block.blockhash(block.number), _seed), now)); return _seed % upper; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

block.blockhash（block.number-1）



一部のコントラクトは、ブロックハッシュに基づいて異なるバージョンのPRNGを使用します。現在のブロックではなく、現在のブロックのハッシュが取得されます。 言うまでもなく、このアプローチも受け入れられません。攻撃者は同じPRSPコードでエクスプロイトコントラクトを作成し、内部メッセージを介してターゲットコントラクトを呼び出すことができます。 両方の契約に同じ「ランダムな」番号が付けられます。



例1（ 0xF767fCA8e65d03fE16D4e38810feller376c3372A8 ）：

 //Generate random number between 0 & max uint256 constant private FACTOR = 1157920892373161954235709850086879078532699846656405640394575840079131296399; function rand(uint max) constant private returns (uint256 result){ uint256 factor = FACTOR * 100 / max; uint256 lastBlockNumber = block.number - 1; uint256 hashVal = uint256(block.blockhash(lastBlockNumber)); return uint256((uint256(hashVal) / factor)) % max; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

未来のブロックのハッシュ



より良いアイデアは、将来のブロックのハッシュを使用することです。 このシナリオは次のように実装できます。

• プレーヤーは賭けをし、オフィスblock.number
  
  
  
  取引のblock.number
  
  
  
  保存します。
• 契約を再度呼び出すとき、プレーヤーは局に勝った番号を発表するように頼みます。
• オフィスは、ストアから保存されたblock.number
  
  
  
  を取得し、そのハッシュを受信します。このハッシュは、擬似乱数の生成に使用されます。

このアプローチは、1つの重要な要件が満たされている場合にのみ機能します。 Solidityのドキュメントは、EVMが保存できるブロックのハッシュの制限について警告しています：

スケーラビリティ上の理由により、ハッシュはすべてのブロックで利用できるわけではありません。 最後の256ブロックのみのハッシュにアクセスでき、他のすべての値はゼロになります。

したがって、ハッシュチェック付きの2番目の呼び出しが256ブロック以内に到着しなかった場合、事前に擬似乱数を予測できます。ハッシュはゼロになります。



この脆弱性を悪用する最も有名なケースは、SmartBillions宝くじのハッキングです。 契約はblock.number



の年齢をチェックしませんblock.number



。そのため、予測可能な当選番号を明らかにする前に、256 block.number



を待つ未知のプレーヤーに400 ETHが行きました。



シークレットハッシュブロックハッシュ



エントロピーを高めるために、一部の契約では追加のシードを使用しますが、これはシークレットと見なされます。 1つの例はSlotthereum宝くじです。 関連するコードは次のとおりです。

 bytes32 _a = block.blockhash(block.number - pointer); for (uint i = 31; i >= 1; i--) { if ((uint8(_a[i]) >= 48) && (uint8(_a[i]) <= 57)) { return uint8(_a[i]) - 48; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポインター変数は秘密であると宣言されています。つまり、他のコントラクトはアクセスできません。 各ゲームの後、この変数には1から9までの勝利番号が割り当てられ、ブロックハッシュを受信するときにblock.number



をオフセットするために使用されます。



本質的に透明なブロックチェーンは、秘密をクリアテキストで保存するために使用しないでください。 シークレット変数は他のコントラクトから保護されていますが、コントラクトストアのコンテンツをチェーンから取得できます。 たとえば、人気のあるweb3 Ethereumクライアントには、特定のインデックスでストレージレコードを取得できるweb3.eth.getStorageAt()



というAPIメソッドがあります。



この事実を考えると、秘密の変数の値をコントラクトストアから抽出し、エクスプロイトコードの引数として使用するのは簡単な作業になります。

 function attack(address a, uint8 n) payable { Slotthereum target = Slotthereum(a); pointer = n; uint8 win = getNumber(getBlockHash(pointer)); target.placeBet.value(msg.value)(win, win); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

トランザクションアドバンス

最大の報酬を得るために、鉱夫はトランザクションを選択して、各トランザクションに費やされる総ガス（燃料）に基づいて新しいブロックを作成します。 ブロック内のトランザクションの順序は、ガスの価格によって決まります。 最大ガス価格の取引が最初に実行されます。 そのため、ガスの価格を変更することにより、現在のブロックの他のすべてのトランザクションよりも早く目的のトランザクションを完了することができます。 これは、セキュリティの問題になる可能性があります。通常、コントラクトの実行がブロック内のポジションに依存する場合、フロントランニングと呼ばれます。



次の例を考えてみましょう。 宝くじは、外部オラクルを使用して擬似乱数を取得します。これは、現在のラウンドで賭けをしたプレーヤーの中から勝者を選択するために使用されます。 これらの番号はクリアテキストで送信されます。 攻撃者は保留中のトランザクションのプールを観察でき、Oracleからの番号を待機しています。 オラクルからのトランザクションがトランザクションプールに表示されるとすぐに、攻撃者はより高いガス価格で入札します。 攻撃者のトランザクションは現在のラウンドで最後に来ましたが、ガス価格が最も高いため、実際にはオラクルトランザクションよりも早く実行され、プレイヤーに勝利をもたらします。 このタスクは、 ハッカーコンテストZeroNights ICOの参加者によって実行されました。



トランザクションが発生しやすい契約のもう1つの例は、 Last is me！というゲームです。 プレイヤーがチケットを購入するたびに、彼は最後の場所を取り、タイマーはカウントダウンを開始します。 特定のブロック数のチケットを誰も購入しない場合、最後の「場所を取っている」プレイヤーがジャックポットを獲得します。 ラウンドが完了に近づくと、攻撃者は他の参加者のトランザクションプールを観察し、ジャックポットを割り当てて、より高いガス価格を設定できます。

より安全なPRNG

Ethereumブロックチェーンでより安全なPRNGを実装するには、いくつかのアプローチがあります。

• 外部オラクル
• 記号
• コミット開示スキーム

外部の神託：Oraclize

Oraclizeは、ブロックチェーンと外部環境（インターネット）の間のブリッジを確立する分散アプリケーション用のサービスです。 Oraclizeを使用する場合、スマートコントラクトは為替レート、天気予報、株価情報などのデータをWeb上のAPIからリクエストできます。 最もよく知られている使用例の1つは、PRNGとして機能するOraclizeの機能です。 作業中に分析された契約の中には、Oraclizeを使用して、URLコネクタを介してrandom.orgから乱数を取得するものがありました。 この図を図に示します。 1。





図 1.ワークフローの整理



このアプローチの主な欠点は集中化です。 Oraclizeデーモンが結果に干渉しないと信じられますか？ random.orgとこのサービスの基礎となるインフラストラクチャ全体を信頼できますか？ OraclizeはTLSNotary監査サービスを介して結果をチェックしますが、ブロックチェーンの外部でのみ使用できます。宝くじの場合は、勝者の発表後にのみ使用できます。 チェーン内で検証可能な元帳証拠を使用して、「ランダム」データのソースとしてOraclizeを使用することをお勧めします。

外部オラクル：BTCRelay

BTCRelayは、EthereumとBitcoinブロックのチェーン間のブリッジです。 BTCRelayを使用する場合、イーサリアムブロックチェーンのスマートコントラクトは、将来のビットコインブロックのハッシュを要求し、エントロピーのソースとして使用できます。 PRTCとしてBTCRelayを使用するプロジェクトの1つは、 Ethereum Lotteryです。



BTCRelayメソッドは、マイナーを刺激する問題から保護されていません。 ここでの障壁はイーサリアムブロックの場合よりも高いですが、ビットコインの価格が高いためです。 したがって、このアプローチは、鉱夫による詐欺の可能性を低減しますが、排除しません。

記号

Signidiceは、暗号署名に基づくアルゴリズムです。 プレーヤーとオフィスの2つのパーティが関与するスマートコントラクトでPRNGとして使用できます。 アルゴリズムは次のように機能します。

• プレーヤーは賭けをし、スマートコントラクトを呼び出します。
• オフィスは賭けを見て、秘密鍵で署名し、署名をスマートコントラクトに送信します。
• スマートコントラクトは、既知の公開キーを使用して署名を検証します。
• 次に、この署名を使用して乱数を生成します。

Ethereumには、チェーン内のECDSA署名を検証するためのecrecover()



関数があります。 ただし、オフィスは入力パラメーター（特にkパラメーター）を操作できるため、結果の署名に影響を与えるため、SignidiceではECDSAを使用できません。 Alexey Pertsev はそのような詐欺のデモを示しました。



幸いなことに、ハードフォークMetropolisのリリースにより、 モジュラーべき乗演算子が登場しました。 これにより、RSA署名の検証が可能になります。 ECDSAとは異なり、入力パラメーターを操作して適切な署名を見つけることはできません。

コミット開示スキーム

名前が示すように、コミット-公開スキームは2つのステップで構成されます。

• 当事者が暗号で保護されたシークレットをスマートコントラクトに送信するコミット段階。
• 開示フェーズでは、当事者がクリアテキストでシードを宣言すると、スマートコントラクトはそれらが正しいことを確認し、乱数の生成に使用されます。

適切に実装されたコミット開示スキームは、片側に依存すべきではありません。 プレイヤーは所有者によって提出された元の開始番号を知らず、彼らのチャンスは同じですが、所有者はプレイヤーである可能性があるため、プレイヤーは彼を信頼できません。



コミット開示スキームは、 Randaoサービスにより適切に実装されています。 PRNGは、いくつかの関係者からシード番号のハッシュを収集し、それぞれが参加に対して報酬を受け取ります。 他の人の開始番号を誰も知らないため、結果は完全にランダムです。 ただし、少なくとも1つのパーティが最初の番号の報告を拒否した場合、サービスは失敗します。



コミット開示スキームは、将来のブロックのハッシュを使用して組み合わせることができます。 この場合、エントロピーの3つのソースが関係します。

• sha3所有者（seed1）
• sha3プレーヤー（seed2）
• 未来のブロックのハッシュ

次に、乱数が次のように生成されます： sha3(seed1, seed2, blockhash)



。 したがって、「コミット開示」スキームは、マイナーを刺激する問題を解決します。マイナーはブロックハッシュに影響を与える可能性がありますが、所有者とプレイヤーの初期番号はわかりません。 また、所有者を刺激する問題も解決します。所有者は自分の初期番号のみを知っていますが、プレーヤーの初期番号と将来のブロックのハッシュを知りません。 また、このようなスキームは、所有者とマイナーとして同時に行動する場合に適しています。ブロックハッシュを決定し、所有者の初期番号は知っていますが、プレーヤーの初期番号はわかりません。

おわりに

EthereumブロックチェーンでのPRNGの安全な実装は未解決のタスクのままです。 私たちの調査が示したように、既製のソリューションが不足しているため、開発者はPRNGの独自の実装を実装する傾向があります。 しかし、ブロックチェーンにはエントロピーの原因がほとんどないため、間違いを犯しやすいです。 PRNGを開発するとき、開発者は各側の動機を理解していることを確認してから、適切なアプローチを選択する必要があります。