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

feat: note on DA, DAS, erasure codes #135

Merged
merged 7 commits into from
Apr 8, 2024

Conversation

ultraviolet10
Copy link
Contributor

Adds compiled notes on data availability, sampling, and the concept of erasure codes.

Copy link
Contributor

@taxmeifyoucan taxmeifyoucan left a 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.
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

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).
Copy link
Contributor

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/

Copy link
Contributor Author

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!

@ultraviolet10
Copy link
Contributor Author

took your suggestion and added it in verbatim 😅 @taxmeifyoucan

Copy link
Contributor

@taxmeifyoucan taxmeifyoucan left a 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

@taxmeifyoucan taxmeifyoucan merged commit baac7dc into eth-protocol-fellows:main Apr 8, 2024
1 of 2 checks passed
@ultraviolet10
Copy link
Contributor Author

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 :)

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

Successfully merging this pull request may close these issues.

2 participants