Add blob sidecar inclusion proof

[dapplion]

To alleviate the concerns around blob equivocations, @fradamt suggested the idea to attach the block header and an inclusion proof on each blob sidecar.

• BlobSidecars now inherit slashing guarantees of block equivocations without adding new slashing conditions.
• Validators do not need to sign additional messages
• p2p validator is cheaper since 1 single signature has to be validated for each block + blobs set

@potuz mentioned that @dankrad may had some concerns with this approach in the past.

TODO:

• update tests
• is gindex notation fine?

---

Merkle proof test vectors:

• 1bac25a
  • Test format
  • mainnet_merkle_proof.tar.gz
  • minimal_merkle_proof.tar.gz

[arnetheduck]

To alleviate the concerns around blob equivocations

Do we have it written down what these concerns are, concretely?

[arnetheduck]

BlobSidecars now inherit slashing guarantees of block equivocations without adding new slashing conditions.

not too sure about this one - how would we slash someone that provided a rejected / ignored blob for an otherwise accepted block?

[potuz]

not too sure about this one - how would we slash someone that provided a rejected / ignored blob for an otherwise accepted block?

If someone equivocates the blob by sending different headers we can prepare a proposer slashing with these conflicting headers

[arnetheduck]

If someone equivocates the blob by sending different headers we can prepare a proposer slashing with these conflicting headers

well, but this is not really different from today - ie you can always withhold blobs from everyone except the next producer if you're privately connected to them - if you're not privately connected / colluding and instead use gossip to send both block and blob, you cannot stop the correct blob from propagating (assuming correctly implemented caches that are cleared when a blob is found to be invalid).

ergo, the only way to get slashed both today and after this change is to send two different proposals.

[djrtwo]

This seems like a much more correct way to do this -- leverage the existing proposer signature (simplify signing) and relate the payload to the proposer's actual crypto-economic commitment (the header/block)

[djrtwo]

@arnetheduck The point is that with this -- you cannot propagate two conflicting sets of blobs on the p2p network for a slot-N with out creating an equivocating proposal (thus the slashing).

[g11tech]

i also agree that this is the better/preferred way to link the blobs with the block

[realbigsean]

This seems like the way to go.

• we had a matching problem, a "valid" blob according to gossip could lie about which block it belongs to. but this becomes impossibe (sweet). This is what caused us caching issues.
• we had a problem where exploiting the existing "first seen" gossip caching mechanic had no penalty, this adds a penalty
  • problems relating to this still exist though, maybe we should still consider: Allow slashable messages to propagate via gossip until slashing #3257
• getting rid of blob signing seems like a substantial plus

[terencechain]

problems relating to this still exist though

there are other patches to alleviate these problems. I've opened the following to see if they can help:

• Check blob sidecar commitment at gossip if possible #3532
• Specify blobs by root condition if there's equivocating blobs #3530

[djrtwo]

I'm going to merge this and then handle the byRoot and byRange condition tightening in another PR

[etan-status]

This doesn't work if there is a reorg and the same proposer gets lucky and is selected at the same slot on both branches of the reorg.

[etan-status]

It's actually even worse, because the blobs from the wrong branch may end up being assumed to be valid on the other branch. As the cache is populated after validation, and validation is not re-done on each reorg.

[potuz]

No proposer should propose blocks on both sides of the reorg, and no two blocks on different sides of the reorg can have the same root so what will happen is that validators will take one side of the equivocation in this case, which is what we do with all equivocations.

[etan-status]

Yes, it is slashable, but if we accept blobs on one branch, and then reorg to the other branch, we may still end up with that situation where we have the incorrect blobs matched with a block.

[potuz]

You can't cause the blockroot is different, they can't be matched

[etan-status]

The block root is no longer checked, since beta 4. the check is now based on (Slot, ProposerIndex).

+- [IGNORE] The sidecar is the first sidecar for the tuple (block_header.slot, block_header.proposer_index, blob_sidecar.index) with valid header signature, sidecar inclusion proof, and kzg proof.

[potuz]

The inclusion proof is against the block root

[etan-status]

only body_root not block root, but the problem is still the same: At the time when we receive the BlobSidecar, we are on the old branch, so the checks all pass, and we cache it for tuple (block_header.slot, block_header.proposer_index, blob_sidecar.index). Then, there is a reorg and we switch to a new branch, with an equivocating block. For that one, we now reject any valid blobs because we already have (block_header.slot, block_header.proposer_index, blob_sidecar.index) cached, and we assume that the ones that we originally cached are actually valid for the new branch as well.

[kasey]

This gossip validation rule doesn't apply to RPC. If nodes are able to retrieve the missing sidecars for the new branch via BlobSidecarsByRoot, they would be able to verify DA and move forward.

[ppopth]

we assume that the ones that we originally cached are actually valid for the new branch as well.

I think this is not true. As @potuz said, the block root will be different and the inclusion proof will not be valid anymore because the block root in the new branch is different from the one in the old branch.

[yawayl]

l thank you pure did one's. am I getting close friends.