Hashed Block Payloads

Consensus already has a system of alternate block proposal from different block proposers, ranked randomly into “slots”, slot 0 being the highest priority block maker, slot 1 the first backup, etc.

Maybe this existing system can be leveraged to mitigate the problem you describe. For example, say only the slot 0 block maker is allowed to include blobs into its proposal, slot 1 and higher only make traditional block proposals without any blobs, where “blob” means data included by reference. And notaries ignore block proposals for which they don’t have all blobs (i.e. treat them as if the block proposal hadn’t arrived). That way the chain would continue in your scenario working with slot 1 or higher blocks until enough notaries have the blobs that appear in a slot 0 block.

In this way, our consensus proofs guarantee liveness.

It can of course happen that the chain continues with 2/3 of nodes and 1/3 never catches up but that has always been the case, blobs or not.

3 Likes