You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assuming the following is true:
validating kzg commitments and inclusion proof guarantees that blobs and commitments are valid and that the commitments are part of the block.
Thus, if we always do those checks before sending the blobSidecar in the pool (BlockBlobSidecarsTrackersPoolImpl), then we can remove all the complex, two-step, checks we do on in ForkChoiceBlobSidecarsAvailabilityChecker and the only remaining logic is the Tracker signalling when the blobs are completed.
sources are:
Syncing code
RPC requests
inbound GOSSIP
local EL
If we trust local EL, and we apply the validation over all the sources, than it means this is feasable.
If we want to be paranoid, we could have a BlobSidecar to be an interface, the actual BlobSidecar will be BlobSidecarImpl and then we can have a ValidatedBlobSidecar type. The validation process will accept BlobSidecarImpl and produce ValidatedBlobSidecar. Then in the BlockBlobSidecarsTrackersPoolImpl we can only allow validated blobs to go in.
NOTE:
The availability checker has being designed when BlobSidecar wasn't having the inclusion proof. So we were forced to "postpone" the validation to the moment in which the block become available.
The text was updated successfully, but these errors were encountered:
tbenr
changed the title
Simplify blobSidecar availability check
Simplify blobSidecar availability checker
Oct 17, 2024
I agree, we are trying to avoid duplicate validations in PeerDAS too.
Syncing along with req/resp includes kzg proof and inclusion proof checks (which we miss, ouch https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md?plain=1#L343)
Instead of making ValidatedBlobsidecar, I'd add commitment/proof/blob check in createBlobSidecar, which pretty fast on verification and that's all.
Assuming the following is true:
validating
kzg commitments
andinclusion proof
guarantees that blobs and commitments are valid and that the commitments are part of the block.Thus, if we always do those checks before sending the blobSidecar in the pool (
BlockBlobSidecarsTrackersPoolImpl
), then we can remove all the complex, two-step, checks we do on inForkChoiceBlobSidecarsAvailabilityChecker
and the only remaining logic is the Tracker signalling when the blobs are completed.sources are:
If we trust local EL, and we apply the validation over all the sources, than it means this is feasable.
If we want to be paranoid, we could have a
BlobSidecar
to be aninterface
, the actualBlobSidecar
will beBlobSidecarImpl
and then we can have aValidatedBlobSidecar
type. The validation process will acceptBlobSidecarImpl
and produceValidatedBlobSidecar
. Then in theBlockBlobSidecarsTrackersPoolImpl
we can only allow validated blobs to go in.NOTE:
The availability checker has being designed when
BlobSidecar
wasn't having the inclusion proof. So we were forced to "postpone" the validation to the moment in which the block become available.The text was updated successfully, but these errors were encountered: