Ability to incrementally build a block

What is wrong?

This PR added optimizations to the process of importing blocks https://github.com/ethereum/py-evm/pull/565

The underlying changes to apply_transaction are causing problems in eth-tester. Now, there is no way to leave the chain in a half state with some transactions applied to the HEAD block. This removes the ability to incrementally apply transactions to a block without digging into internals.

How can it be fixed

Not sure but:

• Need a way for import_block to delay building the transaction trie until the end of the block.
• Need a way to do what the previous apply_transaction functionality did, executing the transaction and fully updating the pending block with the latest state.

[gsalgado]

When doing a full block import we need to re-execute the block and verify that the final resulting block is identical to the input block. Optimization here includes skipping rebuilding the receipt and transaction tries.

I don’t think this is an optimization, really, but maybe my understanding is not correct. More below…

I’m not familiar with eth-tester APIs but if we keep the current block’s transactions/receipts in memory, we should only need to generate the tx/receipt tries when finalizing the block, no? I mean, if the transaction_root and receipt_root are only needed to lookup the transactions/receipts from the DB, we shouldn’t need to generate them if the txs/receipts are available from somewhere else, but even if there’s a need for transaction_root and receipt_root to be exposed before a block is finalized, we could still calculate them on the fly when needed.

[pipermerriam]

I think you’re probably right. I think what we’re really talking about here is shuffling around what state we store, where we store it, and what parts of the architecture are responsible for what