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

Question on note about data availability #11

Open
JustinDrake opened this issue Aug 13, 2017 · 2 comments
Open

Question on note about data availability #11

JustinDrake opened this issue Aug 13, 2017 · 2 comments

Comments

@JustinDrake
Copy link
Contributor

I am reading the note on data availability, which states:

Even if succinct zero knowledge proofs can be used to verify correctness, an attacker getting away with publishing invalid blocks

If a SNARK/STARK can verify correctness of a block, how can an attacker get away with publishing an invalid block? What is the difference between correctness and validity? The two parts of the sentence above seem contradictory.

@vbuterin
Copy link
Contributor

Sorry! That's my fault. Should be publishing an unavailable block. Fixed now.

@JustinDrake
Copy link
Contributor Author

JustinDrake commented Aug 24, 2017

Thanks for the clarification. A followup remark on

an attacker getting away with publishing unavailable blocks and getting them included in the chain is still very bad, as such a thing happening denies all other validators the ability to fully calculate the state, or to make blocks that interact with the portion of the state that is no longer accessible.

I don't think unavailable blocks in the chain are very bad. I think they can be good:

  1. The fact that they "deny all other validators the ability to fully calculate the state" elegantly allows for contracts with private state. It's not a problem so long as block availability is not required for individual contracts to move state forward. Imagine a mixer where 100 people can each privately withdraw their mixed balance using a STARK. Ordering of blocks is irrelevant, so players can act independently and block unavailability is not a problem, only validity.
  2. "to make blocks that interact with the portion of the state that is no longer accessible" => This is just a design problem where the writable state needs to be segregated to a well-defined "safe" subset (like the storage of a single address) where the intent is to preserve privacy and/or do clever scalability optimisations.

I'm interested in playing with the idea of abstracting away code and storage in Ethereum. See section 3 here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants