Remove medstate from receipts

[vbuterin]

Parameters

• METROPOLIS_FORK_BLKNUM: TBA

Specification

Option 1: For blocks where block.number >= METROPOLIS_FORK_BLKNUM, the receipt should remove the intermediate state root parameter.

Option 2: For blocks where block.number >= METROPOLIS_FORK_BLKNUM, the intermediate state root parameter in the receipt should be set to zero instead of the actual state root.

Option 3 (update 2017.07.28: we are going with this one): For blocks where block.number >= METROPOLIS_FORK_BLKNUM, the intermediate state root parameter in the receipt should be set to a \x01 byte if the outermost code execution succeeded, or a zero byte if the outermost code execution failed.

Rationale

Not calculating the state root after each transaction allows for the process of computing the state root to be parallelized, and for fewer merkle tree branches to be calculated because repeated updates can be hashed. Additionally, it sets the stage for future scalability upgrades where transaction processing itself is done in parallel.

This change DOES mean that if a miner creates a block where one state transition is processed incorrectly, then it is impossible to make a fraud proof specific to that transaction; instead, the fraud proof must consist of the entire block. However, (1) block times are low and we expect block times to reduce in the future with Casper, and (2) we have already accepted the principle that light clients must be capable of downloading entire blocks if need be, because of how verifying bloom filter entries works.

[kumavis]

(2) we have already accepted the principle that light clients must be capable of downloading entire blocks if need be, because of how verifying bloom filter entries works.

We would also need to load state touched by all txs in the block up to the tx you want to replay. Since we don't know what it will touch ahead of time it, it is a serial process frequently blocked by getting state from the network. Just want to make sure we are properly enumerating the impacts on the light client strategy.

[gumb0]

Other Metropolis EIPs are specified for block.number >= METROPOLIS_FORK_BLKNUM, so start with fork block.

[Souptacular]

@vbuterin does this EIP have an associated PR?

[Souptacular]

EIP #98 corresponds to #658. We will call PR #658 EIP #98 and incorporate EIP #98 changes into PR #658.

[Souptacular]

Closing issue. Please direct discussion of EIP 98 to pull request 658 per this comment.

[Arachnid]

This EIP is referenced by #658, which has already been merged. As such, it needs to either be finalised and merged, or the dependency in the existing EIP needs to be removed.