Skip to content
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

Blockhash and state root changes #96

Open
vbuterin opened this Issue Apr 26, 2016 · 7 comments

Comments

Projects
None yet
6 participants
@vbuterin
Copy link
Collaborator

commented Apr 26, 2016

See #210

@zmitton

This comment has been minimized.

Copy link

commented Mar 2, 2017

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

This comment has been minimized.

Copy link

commented Mar 8, 2017

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

This comment has been minimized.

Copy link

commented Apr 6, 2017

@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

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 7, 2017

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

This comment has been minimized.

Copy link

commented Apr 8, 2017

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

@pirapira

This comment has been minimized.

Copy link
Member

commented Apr 12, 2017

(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

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2017

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

@karalabe karalabe referenced this issue Jun 29, 2017

Closed

Metropolis aggregate PR #14726

7 of 8 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.