Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove medstate from receipts #98
Option 1: For blocks where
Option 2: For blocks where
Option 3 (update 2017.07.28: we are going with this one): For blocks where
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.
referenced this issue
Apr 26, 2016
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.