New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove medstate from receipts #98

Closed
vbuterin opened this Issue Apr 26, 2016 · 6 comments

Comments

Projects
None yet
5 participants
@vbuterin
Collaborator

vbuterin commented Apr 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kumavis

kumavis Jan 25, 2017

Member

(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.

Member

kumavis commented Jan 25, 2017

(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

This comment has been minimized.

Show comment
Hide comment
@gumb0

gumb0 Apr 6, 2017

Member

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

Member

gumb0 commented Apr 6, 2017

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

@Souptacular

This comment has been minimized.

Show comment
Hide comment
@Souptacular

Souptacular Jun 14, 2017

Member

@vbuterin does this EIP have an associated PR?

Member

Souptacular commented Jun 14, 2017

@vbuterin does this EIP have an associated PR?

@Souptacular

This comment has been minimized.

Show comment
Hide comment
@Souptacular

Souptacular Jul 28, 2017

Member

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

Member

Souptacular commented Jul 28, 2017

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

@Souptacular

This comment has been minimized.

Show comment
Hide comment
@Souptacular

Souptacular Sep 1, 2017

Member

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

Member

Souptacular commented Sep 1, 2017

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

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Mar 22, 2018

Collaborator

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.

Collaborator

Arachnid commented Mar 22, 2018

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.

@Arachnid Arachnid removed the needs-merge label Mar 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment