Codify the decision that validators will download all block data

[evan-forbes]

On various chats and synchronous calls, it was decided that validators will not perform data availability sampling, and will instead download all of the block data. I couldn't find this decision written down formally anywhere and figured that here is the place to do it.

While I couldn't find any, we might also need to change portions of the spec that rely on the assumption that validators will not be downloading all of the block data.

[liamsi]

Here is an non-exhaustive list:

• [ ] DAHeader is included in proposal: if validators don't do DAS this is not a strict requirement anymore! Only if the spec wants to very vaguely and very implicitly make assumptions around block propagation during consensus, which indeed is an implementation detail. If we want to keep the DAHeader in the Proposal, we should clarify here why DAHeader is included in the first place (previously for sampling, now for ??). Also if proposal include the DAHeader why don't Votes also include it? John: files celestiaorg/celestia-core#866 to track this since it's orthogonal
• [x] validator node types was updated in celestiaorg/celestia-specs#177

It think that is it.

[adlerjohn]

Relevant: https://github.com/celestiaorg/lazyledger-core/issues/423

[Wondertan]

@adlerjohn, @liamsi, can you pls reiterate here why it is not possible/secure for validators to DASing only, without downloading the whole block. The reason didn't fix in my mind and also this would be useful for anyone external reading the issue.

[liamsi]

also this would be useful for anyone external reading the issue.

Good point. Most of the discussions around that were in chats between John, Mustafa and me and in calls.

can you pls reiterate here why it is not possible/secure for validators to DASing only, without downloading the whole block.

It's not that this would be insecure or even impossible. In fact, @musalbas original paper assumes DAS "validators" (quotes bc/ the paper is actually consensus agnostic and it could also be miners etc).

The reasons to not do this are:

• main motivation for DAS validators: low resourced (bandwidth/storage) validators; an unreasonable / unrealistic assumption in PoS
• it (unnecessarily) overcomplicates the implementation as this effectively changes how tendermint works (to some extent)

[adlerjohn]

It has to do with accountability. If validators do DAS, they can end up voting on a block that's unavailable (if they're the first to do DAS), or worse, invalid. In such a case, only the proposer is accountable, as the validators had no way of knowing prior to voting that the block was invalid. So the cost of getting a Commit for an invalid block (and thus fooling potentially millions of light clients that expect instant finality from a Commit) is maybe a few thousand dollars if the proposer is the 100th by voting power.

[musalbas]

Actually, the real reason is because validators doing DAS would have to wait for fraud proofs. Block interval times would therefore have to at minimum be the conservative maximum network delay to generate and receive a fraud proof.

[Wondertan]

So there is a chance in the future, maybe post main net, that we will return to this, right?

[adlerjohn]

Maybe, but I would say not until after our first major post-launch hard fork.