feat(daser): do not sample before trusted init height

[walldiss]

Current Behavior

Light nodes currently sample headers from the last 30 days, regardless of their initialization method. This applies even when nodes are subjectively initialized from a trusted peer.

Problem

When a light node is subjectively initialized from a trusted peer, sampling historical headers before the trusted height provides no additional security benefits. This unnecessary sampling consumes extra storage and bandwidth.

Proposed Solution

Modify the sampling window calculation to consider the trusted height when a node is subjectively initialized:

samplingWindow = min(trustedHeight, last30Days)

Benefit

Should save 8-10GB bandwidth for new nodes.

[nashqueue]

It should cut the initial bandwidth of new light nodes by 8-10 GB, so definitely worth it.

It does provide additional security benefits if you somehow trust the hash to be part of the chain but don't want to check the data availability yourself which probably is never the case.

[Wondertan]

To certain extend, this relates to header pruning. Currently we download the whole chain of headers past the subjectively initialized one, when in theory we don't need to do that.

[musalbas]

This is only secure if the trusted peer returns the latest height that it knows is 100% available (i.e. it's a full storage node) - not just if returns the latest known height, or if the trusted peer is a light node (as DA is probabilistic for light nodes and relies on honest minority of light nodes).

[Wondertan]

By default trust peers are bootstrappers which are full archival nodes. If node operator decides to change his trusted peer to a LN instead of a FN, that's something we can't control or prevent.

[walldiss]

This is only secure if the trusted peer returns the latest height that it knows is 100% available (i.e. it's a full storage node) - not just if returns the latest known height, or if the trusted peer is a light node (as DA is probabilistic for light nodes and relies on honest minority of light nodes).

Minor addition is that not only if trusted node is light node , but also full node. Bridge node implicitly follow this rule

[musalbas]

I'm saying that the trusted peer can't be a light node, because they don't 100% know the data is available, due the honest minority of light node assumption, which newly joining nodes will help with.

[adlerjohn]

or if the trusted peer is a light node (as DA is probabilistic for light nodes and relies on honest minority of light nodes)

Hmmm. I disagree that the trusted peer can't be a LN. The honest minority assumption should already be satisfied before the new node tries to join. And while DA is probabilistic, for the agreement property to hold the probabilities should be high enough that it doesn't matter that it's not deterministic, including when new nodes join.

The LN must just have done sampling of the height before being able to return it as a trusted hash.

[Wondertan]

I agree that they LNs ideally shouldn't be trusted peers for additional assumptions it introduces, but I want to point that this is something we can't enforce in protocol, so therefore LN can be a trusted peer

[nashqueue]

Can we not assume that after a light node sampled it already follows the agreement property therefore it can give a trusted hash ? Basically agreeing with what John said above.

[musalbas]

Hmmm. I disagree that the trusted peer can't be a LN. The honest minority assumption should already be satisfied before the new node tries to join. And while DA is probabilistic, for the agreement property to hold the probabilities should be high enough that it doesn't matter that it's not deterministic, including when new nodes join.

The other problem is the selective disclosure attack, where a validator might only release enough samples to selectively trick trusted peers, so we definitely can't even consider that until level 5 DASing anyway.

I agree that they LNs ideally shouldn't be trusted peers for additional assumptions it introduces, but I want to point that this is something we can't enforce in protocol, so therefore LN can be a trusted peer

It's called a trusted peer for a reason - if the trusted peer is violating the trust by not running the right type of node then it's violating that trust.

[adlerjohn]

so we definitely can't even consider that until level 5 DASing anyway

Agree that below level 5 things get messy. There isn't really any bottleneck in practice to only supporting full nodes or bridge nodes being able to sent out trusted hashes, so this is more of a theoretical discussion anyways.