EIP4844: Clarify ratelimit behavior for sidecar with zero blobs

[terencechain]

Clarify that a peer must not respond a sidecar with empty blobs (i.e, len(sidecar.blobs) == 0) under RPC end point /eth2/beacon_chain/req/blobs_sidecars_by_range/1/. This behavior has caused some confusion on devnet3, so it'd be good to clarify it in the spec. A peer may use the kzg commitment in the block body to distinguish if the slot should have a sidecar or not

After further discussions, we've agreed to favor the responding behavior and further clarify that a peer may not want to rate limit a sidecar with empty blobs

[Inphi]

To clarify what an "empty" blob sidecar is. It's a BlobSidecar that does not contain any blobs, but it may contain a non-zero beacon_block_root and beacon_block_slot per get_blobs_sidecar.

[Inphi]

thanks!

[g11tech]

Suggested change

	Clients MUST not respond with empty blobs sidecars.
	Clients MAY skip empty blobs sidecars.

[g11tech]

Suggested change

	In cases where a slot contains a `BlobSidecar` that does not contain any blobs, but contain non-zero `beacon_block_root` and `beacon_block_slot`, `blobs_sidecar` **may be** skipped.
	In cases where a slot contains a `BlobSidecar` that does not contain any blobs, but contain non-zero `beacon_block_root`, `beacon_block_slot` and a valid `kzg_aggregated_proof`, `blobs_sidecar` **may be** skipped.

[g11tech]

lgtm!

[djrtwo]

Why skip these -- the exist (and would exist at time of gossiping)? doesn't that just make cross validation/verification marginally more difficult?

Is it just to save the 100 bytes or so?

[terencechain]

Since we didn't clarify this condition explicitly, it has become the default behavior on devnet3. The saving for 100 bytes is not worth it, but neither cross-validation is more difficult than before (i.e check block body's kzg commitment first, if it's non-empty, then there must exist a sidecar). It does feel cleaner not to have empty objects over the wire since we assume most of them will be empty early on.

@Inphi I think you might have a stronger opinion on this. Anything else to add?

[djrtwo]

It does feel cleaner not to have empty objects over the wire since we assume most of them will be empty early on.

I feel a bit otherwise on the cleanliness -- explicit (send the side car no matter what) seems like less cognitive load to understand what's going on. Rather than implicit (drop the side car when no blobs in block) which requires knowing this extra rule to understand.

[Inphi]

whether we send zero blobs or not, the spec needs to be clear on the behavior.

I'm slightly for empty sidecar elision for a couple reasons;

• as @terencechain pointed out, we need to check the corresponding kzg commitment either way to determine if a blobs sidecar is expected.
• implementations that employ per-message rate limits don't have to unnecessarily trip up the limiter for "zero cost* empty blobs sidecars.
• this is kinda synonymous to the existing behavior for non-existent blocks in missed slots. It would be odd for there to be sidecars, empty or otherwise, if there are missed slots.

[djrtwo]

this is kinda synonymous to the existing behavior for non-existent blocks in missed slots. It would be odd for there to be sidecars, empty or otherwise, if there are missed slots.

Except there is a message that exists and was sent with gossip. I find assymetries between different p2p protocols on sending/not sending empty to be the sticking point form me.

1. explicit better than implicit
2. symmetry between different calls/functions/etc to aid in expectations and reasoning

implementations that employ per-message rate limits don't have to unnecessarily trip up the limiter for "zero cost* empty blobs sidecars.

I see this but think the above points in aiding spec understanding trump this especially considering that the equillibrium will be non-zero blobs for almost all blocks (1 is the minimum blob gas price so the resource will be utilized)

[Inphi]

Good points. I'm sympathetic to keeping things symmetric. Though there're a couple asymmetries in Req-Res RPC today, including behavior around missed w/ slots, we don't need to add more more to the pile.

[terencechain]

ready again @djrtwo 🙏🏼