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

Closed
vbuterin opened this issue Apr 26, 2016 · 9 comments
Closed

Blockhash and state root changes #96

vbuterin opened this issue Apr 26, 2016 · 9 comments
Labels

Comments

@vbuterin
Copy link
Contributor

vbuterin commented Apr 26, 2016

See #210

@zmitton
Copy link

zmitton 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
Copy link

zmitton 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
Copy link

zmitton 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
Copy link
Contributor Author

vbuterin 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
Copy link

zmitton commented Apr 8, 2017

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

@pirapira
Copy link
Member

(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
Copy link
Member

chfast commented Apr 13, 2017

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

@github-actions
Copy link

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

@github-actions github-actions bot added the stale label Jan 16, 2022
@github-actions
Copy link

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

bumblefudge added a commit to bumblefudge/EIPs that referenced this issue Feb 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants