Note on terminology: Whenever talking about a post-DAS system, I am going to use full node to refer to a node which fully validates the chain (in this respect, equivalent to today's full nodes), but which does not fully download the blob data, and instead performs some form of DAS. Also, full node will implicitly mean honest (protocol-following) full node, unless otherwise specified. Nodes which download the entire data are interchangeably called super full nodes. In a system with DAS, it is quite easy to achieve global safety, the property that at most a small minority of sampling nodes can be tricked into following an unavailable chain. Harder to achieve is individual safety, i.e., that no sampling node can be tricked except with negligible probability, as it requires the unlinkability of sampling queries. Also hard to achieve robustly is liveness. If we do not find a single DAS construction which has both great individual safety and liveness properties, we can still perhaps get the best of both worlds by using two different constructions for different purposes, so as to take advantage of their specific trade-off choices. Given a DAS solution with strong liveness and global safety properties (DAS1) and a DAS solution with strong individual safety properties (DAS2), there are at least two ways that we could employ them: Separate the DAS of validators and full nodes: validators run DAS1 as their fork-choice filter, guiding their consensus participation, while full nodes run DAS2. Separate the DAS used by fork-choice rule and confirmation rule: DAS1 is used by all full nodes as a fork-choice filter, and DAS2 is used as an additional confirmation rule criterion In the first case, a liveness failure of DAS2 does not have any impact on consensus, modulo potential network disruptions due to non-validator full nodes experience liveness issues in the fork-choice, because validators are unaffected. Even better in the second case, a liveness failure of DAS2 has no global impact at all: by being confined to the confirmation rule, it can only result in an inability to confirm new transactions, and only for full nodes. Neither the p2p network nor validators are affected. In either case, as long as DAS1 works, consensus is unaffected, and so is the ability of super full nodes to confirm transactions. This can make for a much more resilient system, and even reduce the incentive to attack DAS2 in the first place.
5/15/2025Written by Francesco, Luca and Roberto The goal of this document is to deepen our understanding of the interactions between the fork-choice and the data availability layer after introduction of data availability sampling (DAS), with the aim of mitigating potential attacks that arise. To achieve this, we first identify potential attacks under the current fork-choice specification and suggest strategies to counter them. This analysis assumes familiarity with the current fork-choice and known attacks, and with PeerDAS. Distribution phase and sampling phase Recall that in PeerDAS, each blob is individually extended horizontally, stacked vertically and subdivided in NUM_COLUMNS columns, which are used as the sampling unit. PeerDAS comprises two phases: a distribution phase and a sampling phase. In the distribution phase, columns are allocated among subsets of validators, with each subset tasked with the custody of one or more columns (CUSTODY_REQUIREMENT). Subsequently, in the sampling phase, validators request samples to verify data availability. These samples, or columns, are acquired from peers through a request/response mechanism. The distribution phase can also serve as a kind of preliminary sampling phase, enabling a validator to consider data available if all the columns it's required to custody are available, even before completing the actual sampling phase. This proves especially valuable when employing a trailing fork-choice function, a concept explaned further below. Tight fork-choice Ideally, almost all honest validators would ever only vote for blocks that are fully available, without needing to download all of the data. To achieve this, we can require a sufficiently high amount of sampling to be completed before ever voting for a block. We refer to this as the tight fork-choice. In PeerDAS, this would mean that validators are required to perform peer sampling immediately upon receiving a block, and cannot vote for it without completing it. This gives us a useful property, which we call $\delta$-safety of sampling, for some $\delta \in [0,1/2]$ dependent on the amount of sampling ($\delta \to 0$ as number of samples increases)
3/14/2025Notice: This document is a work-in-progress for researchers and implementers. Table of contents Introduction Constants Misc Withdrawal prefixes Domains
8/6/2024This post follows a previous one on the fork-choice of PeerDAS, incorporating changes stemming from the recent developments in the design of PeerDAS. Roles of peer sampling Peer sampling for full nodes: transaction confirmation The first role of peer sampling concerns full nodes, in particular the security of transaction confirmations. Still, we do not need to use peer sampling for the safe head rule, because this already relies on an honest majority assumption, which, if satisfied, would already guarantee availability. Instead, as far as transaction confirmation is concerned, we only need to use peer sampling to ensure availability of finalized checkpoints. Peer sampling for attesters: resistance to supermajority attacks As discussed in the interop update on PeerDAS, peer sampling is not necessary in order for consensus to function, as long as we have a sufficiently high custody requirement. In other words, as long as we have enough subnet sampling to ensure that at most a small percentage of the validators can ever vote for something unavailable. Still, peer sampling can play a role in improving a validator's response to supermajority attacks which invole the justification or finalization of an unavailable block. In such a situation, we would like to ensure two things:
5/24/2024