作者：djrtwo
The Ethereum Foundation (EF) is seeking proposals for projects looking to contribute to the domain of Data Availability Sampling (DAS) with respect to its implementation in peer to peer networks. This problem domain is under-explored, and we are excited to invite additional teams and individuals to explore this with us.
In particular, the EF is requesting proposals that aim to design, refine, build, analyze, and test both theoretical and practical DAS techniques. This is a critical problem space in Ethereum p2p networking.
The EF has earmarked$1.5M in fundingfor this RFP and is looking to accept not one, but a number ofproposals. Proposals can span from formal design/analysis to more practical engineering and testing.
Problem statement
RFP Details
Bidding instructions
DAS is critical for any blockchain design that provides data availability guarantees beyond the resources of any standard node on the network -- e.g. Layer-1 comes to consensus on 1MB of data per second, but any standard node on the network only has the resources (bandwidth, storage, etc) to validate/download 50kb per second.
In a DAS model, nodes randomly sample data that has been erasure encoded to ensure data is available and (in the event of data being missing or withheld) reconstruct portions of the data.
To read more about the Data Availability problem and DAS please see these resources:
A note on data availability and erasure coding
Fraud and Data Availability Proofs
Recent Ethereum sharding design proposal
DAS Requirements and tools
DAS can be divided into a number of problems:
Disseminate small amounts of data to all nodes (samples or sets of samples) to support sampling from other nodes, in a way that supports random sampling (see 2)
Support queries for random samples in an efficient and safe way
Identify and reconstruct missing data (to then disseminate, 1 & 2)
For a deeper discussion of these requirements, please seehere.
In an exploration of one or more of these requirements, we suggest you parametrize the relevant values and analyze under various considerations (e.g.DATA_PER_BLOCK,NETWORK_NODE_COUNT, etc)
Note that designs should be analyzed/tested in both the happy case as well as under a diverse adversarial environment -- e.g. where does the design break down, under what type of adversary, what types of attacks are available, etc.; examples of typical attacks on DAS are:
Data withholding attacks (attacker overtakes/bribes the validator set to vote for an invalid block)
Temporary withholding attack (same attack but attacker later makes the data available)
Targeted eclipse attacks, where the attacker makes samples available to a subset of node, but not enough to reconstruct the data
DOS attacks, where the attacker breaks data availability sampling in such a way that all or a certain subset of samples are never retrievable Analyzing these attacks as well as coming up with new ones is part of this RFP.
As noted above, the EF is looking to accept multiple proposals pertaining to DAS networking that aim to design, refine, build, analyze, and/or test both theoretical and practical DAS techniques.
The entire process can be summarized as follows:
Request:EF releases RFP (this post)
Gather:Teams submit proposals
Deliberate:EF analyzes proposals, discusses dynamically any suggestions in structure, direction, fee schedule, and/or timeline, and comes up with a plan based on the resources and needs of the accepted proposal(s).
Propose:EF proposes a final structure of the proposal based upon deliberations/discussions.
Begin:Team accepts and work begins
TheEFproposes projects be structured either as 3, 6, or 12 month engagements with milestones/check-ins throughout (more for longer engagements).
Initial proposals will not be accepted for longer than 12 month engagements. Subsequent proposals and grants can be formulated for followup work in the event this engagement goes well and a continuation is warranted.
The team is expected to define their own deliverables as a part of scoping the project. Deliverables can include but are not limited to -- formal papers, design documents, instructional videos, survey specifications, implementations, creation or extension of library code, experimental results, and blog posts.
