-
Notifications
You must be signed in to change notification settings - Fork 94
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
feat: note on DA, DAS, erasure codes #135
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution!
|
||
A core responsibility of any layer-1 blockchain is to guarantee _data availability_. | ||
|
||
Data availability refers to the availability of transactions in a block that is appended to the tip of the chain. During consensus, validators download the block to verify its availability. If the block contains any transactions that are withheld by a validator, the block is unavailable and will be rejected as invalid. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would make it clear that DA is a prerequisite to validating the chain. It's not about data being available but being able to verify them with protocol rules
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you suggest I collate the exact rules that are being verified?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to go to details. Just to point out that a node needs to verify transactions and validate blocks to be able to operate trustlessly and build the state which requires historical and latest data.
|
||
In case (1), the block is valid and the light client can accept it. In case (2), it is expected that some other node will quickly construct and relay a fraud proof. In case (3), it is also expected that some other node will quickly construct and relay a specialized kind of fraud proof that shows that the erasure code is constructed incorrectly. If a light client receives no fraud proofs for some time, it will take that as evidence that the block is in fact valid. | ||
|
||
An interesting implementation to study can be found [here](https://github.com/ethereum/research/tree/master/erasure_code/ec65536). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a section for resources. There are many great articles on DA and solutions you explained here. Ethorg does a great job on DA https://ethereum.org/en/developers/docs/data-availability/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a few interesting ones, lmk what you think!
took your suggestion and added it in verbatim 😅 @taxmeifyoucan |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ultraviolet10! One paragraph I would find missing is the changes to L2 data availability with introduction of ephemeral blobs
Got it, I'll add this in the next update. Thanks :) |
Adds compiled notes on data availability, sampling, and the concept of erasure codes.