Blockhash and state root changes

[vbuterin]

See #210

[zmitton]

Is there a technical limitation on WRAPAROUND being 65536? It's a welcome improvement over the current limit of 256, but I'm asking because I've come across many examples where it would be useful to have access to any historical blockhash.

[zmitton]

To elaborate, I would like to offer a few use-cases:
The first I have run into, pertains to using the hash as a source of randomness. I'm fully aware it's not the best source of randomness, but it's useful for fun games involving "random generation" of assets. A particular asset may become mintable only in the off-chance that a blockhash is divisible by a certain number or when its hash with a particular user's address, is divisible by a certain number. Then the user gains the right to mint into their own wallet. This would require the user to make a Tx of course, and currently they have a time limit on when to do this. Perhaps this use-case would become less viable after PoS is implemented.

Secondly, and much more importantly, is in the application of verifiable off-chain computation networks such as true-bit. The on-chain verification process would in many cases rely on a specific "snapshot of state". It would not be possible to verify against a moving target. I would imagine the registration of a job in true-bit might require a specific block number, or the ability to lock in a block number once certain conditions are met. That block number would include a state-root to provide merkle proofs against during the interactive verification process.

[zmitton]

@vbuterin another use case is for logs. I have considered cases where logs are nearly sufficient over expensive storage. However maybe the log needs to be read in very rare cases(1 out of every million for instance). If block headers are available, it would be possible to "escalate" a log into something that can be read by a contract by presenting a merkle proof verification of its existence.

[vbuterin]

Is there a technical limitation on WRAPAROUND being 65536?

The rationale is that if you allow each block to access literally any previous block, then storage blows up too much. That said, there is a compromise where you can access the last 256 blocks, then every 256th block up to the last 65536th block, then every 65536th block up to the last 16777216th block, and you may as well stop there. This let you access any previous block in 3 hops, and only takes up a maximum of 768 storage slots in the state.

[zmitton]

Thanks, glad to hear this! Sounds like these features will be possible by providing a few separate merkle-proofs

[pirapira]

(3) has n - WRAPAROUND <= p (which allows equality) while the getter specification blknum > block.number - WRAPAROUND does not allow equality. I find this a bit inconsistent.

[chfast]

Can we keep the addresses of precompiled contracts continuous? What's the point of jumping to 0x10 and 0x20?