Streamlined DAS: Easy Decentralized Storage with Trusted P2P

Table of Contents
Understanding the dynamics between fork-choice rules and data availability layers, especially with the introduction of Data Availability Sampling (DAS), is crucial for mitigating potential attacks in blockchain systems. This article explores these interactions, identifies potential threats, and suggests strategies to counter them.

I. Overview of Streamlined DAS

Objective and Scope

This document aims to enhance our understanding of how fork-choice rules interact with the data availability layer following the introduction of Data Availability Sampling (DAS). Our goal is to identify potential attacks under the current fork-choice specifications and propose strategies to mitigate these threats. This analysis assumes a solid grasp of the current fork-choice mechanisms, known attacks, and the PeerDAS framework.

Fork-Choice Specification

Fork-choice rules are critical in determining the canonical chain within a blockchain network. These rules guide validators in selecting which chain to build upon, ensuring that all participants in the network maintain a consistent view of the blockchain. The primary objective of fork-choice rules is to enhance the security and integrity of the blockchain by making it difficult for adversaries to alter the canonical chain.
In typical blockchain systems, fork-choice rules are designed to favor the longest chain or the chain with the most accumulated proof-of-work or stake. Validators follow these rules to decide which blocks to add to the blockchain, thereby maintaining consensus. However, the effectiveness of these rules can be challenged by sophisticated attacks, particularly in systems with complex data availability requirements.

Data Availability Sampling (DAS) Overview

Data Availability Sampling (DAS) is a method designed to ensure that the data associated with blockchain transactions is readily accessible to all validators without requiring them to download the entire dataset. This approach significantly reduces the bandwidth and storage requirements for validators while still ensuring data integrity and availability.
DAS allows validators to sample random pieces of data from the blockchain. If a sufficient number of samples are available, validators can confidently assume that the entire dataset is available. This method is particularly beneficial in large-scale blockchain networks where full data downloads would be impractical.

PeerDAS Overview

PeerDAS is a specific implementation of DAS that divides the process into two main phases: the distribution phase and the sampling phase. These phases work together to ensure efficient data distribution and verification among validators, maintaining the blockchain's security and availability.

II. Data Distribution and Sampling in PeerDAS

In PeerDAS, the process of ensuring data availability is divided into two critical phases: the distribution phase and the sampling phase. Each phase plays a pivotal role in guaranteeing that data is effectively disseminated and verified among validators, thereby maintaining the overall security and integrity of the blockchain network.

Distribution Phase

The distribution phase is the initial step in PeerDAS, where data is allocated among validators in a structured manner to ensure broad availability and accessibility.
Column Allocation Among Validators
In the distribution phase, data is organized into units called blobs. Each blob is extended horizontally and stacked vertically, then subdivided into a set number of columns, referred to as NUM_COLUMNS. These columns are the fundamental units of data used for sampling and verification.
Once the data is divided into columns, these columns are allocated among subsets of validators. This allocation is governed by the concept of CUSTODY_REQUIREMENT, which specifies the number of columns each validator is responsible for. By distributing columns among multiple validators, the system ensures that no single point of failure can compromise the data's availability.
The distribution phase also serves as a preliminary sampling mechanism. Validators can verify the availability of the columns they are assigned, providing an early indication of data availability before the actual sampling phase begins. This preliminary check is particularly beneficial when using a trailing fork-choice function, as it allows validators to make informed decisions about data availability early in the process.

Sampling Phase

The sampling phase is the second critical step in PeerDAS, where validators actively verify the availability of data through a systematic request/response mechanism.
Request/Response Mechanism for Data Availability
During the sampling phase, validators request samples of data from their peers to confirm its availability. This is done using a request/response protocol, where validators send requests for specific columns to their peers and receive responses containing the requested data. This mechanism ensures that validators can independently verify the availability of data without relying solely on the initial distribution phase.
The sampling phase is crucial for maintaining the integrity of the blockchain. By actively verifying data availability, validators can ensure that the data required for validating blocks is accessible. This process helps to prevent attacks that exploit data unavailability, as validators can independently confirm that the data is present and accessible.
Preliminary Sampling in the Distribution Phase
The preliminary sampling conducted during the distribution phase provides a valuable early check on data availability. Validators can quickly determine whether the columns they are assigned are accessible, even before initiating the full sampling phase. This early verification step is especially useful in scenarios where validators need to make quick decisions about the availability of data, such as when using a trailing fork-choice function.
Peer Sampling and δ-Safety
Peer sampling is a critical aspect of the sampling phase, where validators request data samples from their peers to verify availability. This process ensures that data is distributed and accessible across the network, providing a robust mechanism for maintaining data availability.
The concept of δ-safety is integral to the sampling phase. δ-safety refers to the proportion of honest validators who can be tricked into perceiving unavailable data as available. By performing thorough peer sampling, validators can reduce δ to a minimum, ensuring that only a small fraction of validators can be misled about data availability.
The distribution and sampling phases in PeerDAS work together to ensure that data is effectively disseminated and verified among validators. The distribution phase allocates data columns among validators, providing an initial check on availability, while the sampling phase involves active verification through a request/response mechanism. By combining these two phases, PeerDAS ensures robust data availability, maintaining the integrity and security of the blockchain network.
To understand more about crypto attack methods. Recently, we have published an article relate to Web3 Security Essentials: Spotting Scams & Protecting Your Crypto

 III. Fork-Choice Strategies

Fork-choice strategies are central to maintaining the integrity and consistency of blockchain networks. In the context of PeerDAS and Data Availability Sampling (DAS), these strategies need to account for data availability while making decisions on block validation. This section explores two primary fork-choice strategies: Tight Fork-Choice and Trailing Fork-Choice, and introduces the concept of δ-safety, which is crucial for understanding the robustness of these strategies against potential attacks.

Tight Fork-Choice

The Tight Fork-Choice strategy aims to ensure that validators only vote for blocks that are fully available. This strategy requires validators to complete a significant amount of data sampling before casting their votes, thereby ensuring that they have verified the availability of the data in the proposed blocks.
δ-Safety of Sampling
In the context of Tight Fork-Choice, δ-safety is a measure of how secure the sampling process is against manipulation. Specifically, δ represents the fraction of honest validators that could be tricked into perceiving an unavailable block as available. Ideally, as the amount of sampling increases, δ approaches zero, meaning that fewer validators can be deceived.
The concept of δ-safety can be formalized as follows:
- δ-Safety of Sampling: If some data is less than half-available, at most a fraction δ of honest validators will perceive it as available. Consequently, no more than a fraction δ of honest validators would vote for an unavailable block.
To achieve Tight Fork-Choice, validators must perform peer sampling immediately upon receiving a block and cannot vote for it until the sampling is complete. This approach ensures that validators only vote for blocks with confirmed data availability, significantly reducing the risk of voting for unavailable blocks.

Trailing Fork-Choice

The Trailing Fork-Choice strategy offers a more flexible approach compared to Tight Fork-Choice. Instead of requiring validators to complete peer sampling before voting, this strategy allows validators to postpone the completion of sampling until after they have cast their votes. This approach aims to take peer sampling out of the critical path of block validation, reducing the immediate computational and bandwidth burden on validators.
δ-Safety in Trailing Period
In the Trailing Fork-Choice strategy, δ-safety during the trailing period is crucial. Here, δ-safety needs to account for the fact that validators might vote based on incomplete data availability information. This period introduces two different δ values:
- δp (Peer Sampling δ-Safety): This represents the δ-safety achieved through peer sampling. Since peer sampling is thorough, δp is expected to be very low, meaning that the likelihood of validators being misled about data availability is minimal.
- δs (Subnet Sampling δ-Safety): This represents the δ-safety achieved through subnet sampling. Subnet sampling is less thorough and more bandwidth-intensive due to the gossip amplification factor, leading to a higher δs compared to δp. This means that during the trailing period, a higher fraction of validators might be tricked into voting for unavailable blocks.
Comparison of Tight and Trailing Fork-Choice
Both Tight and Trailing Fork-Choice strategies have their advantages and drawbacks. Tight Fork-Choice offers higher security by ensuring that validators only vote for blocks with confirmed data availability. However, it imposes a higher computational and bandwidth burden on validators due to the need for immediate sampling.
Trailing Fork-Choice, on the other hand, reduces the immediate burden on validators by allowing them to complete sampling after voting. This flexibility can improve the efficiency of the validation process, but it introduces a higher risk of validators being misled about data availability during the trailing period.
Choosing between Tight and Trailing Fork-Choice depends on the specific requirements and constraints of the blockchain network. Tight Fork-Choice is suitable for environments where security is paramount, while Trailing Fork-Choice offers a more efficient approach in scenarios where validators need to balance security with computational and bandwidth resources. Understanding the trade-offs and implementing appropriate δ-safety measures is crucial for maintaining the integrity and security of the blockchain.

 IV. Potential Attacks and Analysis

Blockchain systems are constantly under threat from various forms of attacks that aim to disrupt their operations, compromise data availability, or manipulate the consensus process. In the context of PeerDAS and Data Availability Sampling (DAS), understanding these potential attacks and developing strategies to counter them is crucial for maintaining the integrity and security of the blockchain network. This section delves into several notable attack vectors and provides an in-depth analysis of each.

Ex-Ante Reorganizations

Ex-Ante Reorganizations, or ex-ante reorgs, are a type of attack where an adversary, by controlling a significant fraction of validators, can influence the blockchain’s canonical chain through strategic block withholding and timing. This attack exploits the time delay between the proposal and the finalization of blocks.
Adversary Strategy and Execution
In an ex-ante reorg attack, the adversary privately constructs blocks and orchestrates votes among its validators across multiple slots. This allows the adversary to outvote honest blocks upon their release. The adversary can either overcome the proposer boost with a well-timed release of withheld blocks and attestations or directly outvote the honest validators' votes.
For instance, consider an adversary withholding blocks B and C along with 21% of each committee’s attestations. An honest proposer extends block A with block D, but the adversary then reveals the withheld blocks and attestations before the attestation deadline. This strategic release causes the honest block D to be orphaned as the adversary’s votes outweigh the proposer boost.

Enhanced Ex-Ante Reorganizations

Enhanced ex-ante reorgs take advantage of the δ-safety concept in the context of PeerDAS, further strengthening the adversary's ability to mislead validators about data availability.
Proposer Sees Unavailable, Attesters See Available
In this enhanced attack, the adversary can trick a fraction δ of honest validators into believing that an unavailable block is available by publishing block B without fully releasing its associated data. The adversary ensures that the subnet sampling for B is successful for these validators, leading them to vote for B along with the adversary’s validators. The adversary then extends B with another fully available block C, causing these validators to vote for C as well.
This cycle continues until an honest slot proposer attempts to fork out B. The adversary then makes B fully available, nullifying the honest proposer’s attempt if the adversary’s chain has accumulated sufficient votes. This attack highlights the need for extensive sampling to keep δ low and minimize the fraction of validators that can be tricked.

Targeted Data Release Attacks

Targeted Data Release Attacks exploit the ability of the adversary to convince a specific honest proposer that an unavailable block is available, leading to a series of reorgs that orphan honest blocks.
Proposer Sees Available, Attesters See Unavailable
In this attack, the adversary targets a specific proposer by linking their validator identity to a node and ensuring control over at least one peer of that node. The adversary withholds data and responds positively only to the targeted proposer’s sampling queries, tricking the proposer into believing that an unavailable block B is available.
The sequence of events unfolds as follows:
1. The adversary publishes an unavailable block B during slot 2 and withholds further blocks in slot 3.
2. The adversary convinces the proposer for slot 4 that B is available. Consequently, the proposer does not attempt to reorg B, believing it to be available.
3. Other validators, seeing B as unavailable, continue to vote for the previous block A.
4. The proposer for slot 5 extends A with block D, effectively reorging the honest but now unavailable block C.
This attack can target multiple honest proposers in succession, causing their blocks to be orphaned and destabilizing the blockchain.

Impact of Tight and Trailing Fork-Choice on Attacks

The Tight Fork-Choice strategy can mitigate these attacks by ensuring validators only vote for blocks with confirmed data availability, significantly reducing the effectiveness of ex-ante reorgs and targeted data release attacks. However, the immediate sampling requirement imposes a higher computational and bandwidth burden on validators.
The Trailing Fork-Choice strategy, while more efficient, introduces a period where validators might vote based on incomplete data availability information. This trailing period can be exploited by adversaries to execute enhanced ex-ante reorgs and targeted data release attacks. The effectiveness of these attacks depends on the δ-safety during the trailing period, with a higher δ indicating a greater vulnerability.
Both fork-choice strategies have trade-offs in terms of security and efficiency. Tight Fork-Choice offers higher security at the cost of increased resource requirements, while Trailing Fork-Choice improves efficiency but introduces potential vulnerabilities during the trailing period. Understanding these trade-offs is crucial for developing robust strategies to counter potential attacks in PeerDAS and DAS environments.

 V. Mitigation Strategies

To safeguard the integrity and security of blockchain networks using PeerDAS and Data Availability Sampling (DAS), it is crucial to develop and implement effective mitigation strategies against the potential attacks discussed earlier. This section outlines various mitigation approaches for the enhanced ex-ante reorgs and targeted data release attacks, and concludes with a summary of findings and recommendations for further research.

Mitigations for Enhanced Ex-Ante Reorgs

Enhanced ex-ante reorgs exploit the δ-safety of sampling, allowing adversaries to trick honest validators into perceiving unavailable blocks as available. To counter this, several mitigation strategies can be employed:
Incorporating Peer Sampling in the Trailing Period
One effective mitigation approach is to incorporate peer sampling in the trailing period. Validators of slot \(n+1\) can complete peer sampling 10 seconds into slot \(n\), while proposers can continue sampling until they propose a new block. If the proposer extends a block that an attester sees as unavailable, the attester should try to sample again. This approach resembles a view-merge strategy but does not require additional messages in the proposal process.
In practical terms, this mitigation ensures that attesters of slot 4 do not see block B as available unless the proposer of block D does as well. This means:
- If the proposer sees block B as available, block D extends block C.
- If the proposer sees block B as unavailable, so do the attesters, and they vote for block D.
Although this mitigation introduces stricter timing assumptions around peer sampling and reduces the benefits of the trailing fork-choice, it effectively addresses the enhanced ex-ante reorgs by ensuring consistent data availability perceptions among validators.

Mitigations for Targeted Data Release Attacks

Targeted data release attacks rely on convincing an honest proposer that an unavailable block is available. To mitigate this, a more robust fork-choice rule can be employed:
Block-Slot Fork-Choice Function
The block-slot fork-choice function is a variation of the fork-choice rule designed to account for attestations associated with empty slots. At any given slot \(t\), this approach considers votes for a block A as votes for pairs (block, slot), rather than just votes for block A.
For example, consider a proposal B extending the head of the canonical chain A. Under the block-slot fork-choice rule, votes for A are considered as votes for the pair (A, t+1) if no new block is proposed. This concurrent consideration of both (B, t+1) and (A, t+1) effectively mitigates targeted data release attacks by ensuring that any reorganization must account for empty slots and the associated attestations.
By implementing the block-slot fork-choice function, the blockchain network can effectively counter targeted data release attacks, preventing adversaries from manipulating honest proposers into extending unavailable chains.

Summary of Findings

The analysis of potential attacks and mitigation strategies reveals several key insights:
- Enhanced Ex-Ante Reorgs: These attacks exploit δ-safety to mislead validators. Incorporating peer sampling in the trailing period can mitigate this threat by ensuring consistent data availability perceptions.
- Targeted Data Release Attacks: These attacks rely on convincing specific proposers of data availability. The block-slot fork-choice function effectively counters these attacks by considering attestations for empty slots.
Both tight and trailing fork-choice strategies have their strengths and weaknesses. Tight fork-choice provides higher security by requiring immediate sampling but imposes a higher resource burden. Trailing fork-choice improves efficiency but introduces vulnerabilities during the trailing period.

Recommendations for Further Research

To enhance the security and efficiency of blockchain networks using PeerDAS and DAS, further research is recommended in the following areas:
- Optimizing Peer Sampling Protocols: Investigate ways to improve the efficiency of peer sampling without compromising security, potentially through adaptive sampling techniques or enhanced peer discovery mechanisms.
- Refining Fork-Choice Rules: Explore variations of fork-choice rules, such as hybrid approaches that combine elements of tight and trailing strategies, to balance security and efficiency.
- Dynamic δ-Safety Adjustments: Develop mechanisms to dynamically adjust δ-safety thresholds based on network conditions, validator behavior, and attack patterns, ensuring optimal security under varying circumstances.
- Simulation and Testing: Conduct extensive simulations and real-world testing of proposed mitigation strategies to evaluate their effectiveness and identify potential areas for improvement.
The blockchain community can develop more robust and resilient systems capable of withstanding sophisticated attacks while maintaining high performance and efficiency.


Maintaining the security and integrity of blockchain networks in the face of potential attacks requires a deep understanding of the underlying mechanisms and strategic implementation of mitigation measures. This document has explored various attack vectors associated with PeerDAS and DAS, analyzed their impact, and proposed effective mitigation strategies. By incorporating these strategies and pursuing further research, the blockchain community can ensure the continued robustness and reliability of these critical systems.

About Orochi Network

Orochi Network is a cutting-edge zkOS (An operating system based on zero-knowledge proof) designed to tackle the challenges of computation limitation, data correctness, and data availability in the Web3 industry. With the well-rounded solutions for Web3 Applications, Orochi Network omits the current performance-related barriers and makes ways for more comprehensive dApps hence, becoming the backbone of Web3's infrastructure landscape.
Event Recap
Monthly Report
Verifiable Random Function
Zero-Knowledge Proofs
Top Posts
Partnership Announcement
Layer 2
Event Recap
Immutable Ledger
Verifiable Random Function
Zero-Knowledge Proofs
Multisignature Wallet

Orosign Wallet

Manage all digital assets safely and securely from your mobile devices

zkDatabaseDownload Orosign Wallet
Coming soon

zkOS for Web3

© 2021 Orochi