Conversation
beacon-chain/p2p/pubsub_filter.go
Outdated
|
|
||
| denebForkDigest, err := forks.ForkDigestFromEpoch(params.BeaconConfig().DenebForkEpoch, s.genesisValidatorsRoot) | ||
| if err != nil { | ||
| log.WithError(err).Error("Could not determine Capella fork digest") |
There was a problem hiding this comment.
| log.WithError(err).Error("Could not determine Capella fork digest") | |
| log.WithError(err).Error("Could not determine Deneb fork digest") |
| return []*eth.SignedBlobSidecar{} | ||
| } | ||
| bs, ok := value.([]*eth.SignedBlobSidecar) | ||
| if !ok { |
There was a problem hiding this comment.
Should we log something here? Something very strange is happening if we have the wrong object in the cache.
| func (s *Service) addPendingBlobToCache(b *eth.SignedBlobSidecar) error { | ||
| blobs := s.pendingBlobsInCache(b.Message.Slot) | ||
|
|
||
| blobs = append(blobs, b) |
There was a problem hiding this comment.
Is it possible that we accidentally append a blob that has been already cached, resulting in having the same blob twice?
Looking at the way we use it, I would say yes, meaning that someone can spam the cache with one blob for an nonexistant block.
if !s.cfg.chain.HasBlock(ctx, parentRoot) {
if err := s.addPendingBlobToCache(sBlob)
beacon-chain/sync/service.go
Outdated
|
|
||
| const rangeLimit = 1024 | ||
| const seenBlockSize = 1000 | ||
| const seenBlobSize = 4000 // Each block can have max 4 blobs. Worst case 164kB for cache. |
There was a problem hiding this comment.
| const seenBlobSize = 4000 // Each block can have max 4 blobs. Worst case 164kB for cache. | |
| `const seenBlobSize = seenBlockSize * 4` // Each block can have max 4 blobs. Worst case 164kB for cache. |
beacon-chain/sync/subscriber.go
Outdated
| s.validateBlob, /* validator */ | ||
| s.blobSubscriber, /* message handler */ | ||
| digest, | ||
| params.BeaconConfig().MaxBlobsPerBlock, |
There was a problem hiding this comment.
I think we should have a BlobsSubnetCount value in the network config for symmetry with AttestationSubnetCount. The two can possibly be different in the future, I guess...
beacon-chain/sync/validate_blob.go
Outdated
| return pubsub.ValidationIgnore, err | ||
| } | ||
|
|
||
| // [IGNORE] The blob's block's parent (defined by sidecar.block_parent_root) has been seen (via both gossip and non-gossip sources) |
There was a problem hiding this comment.
| // [IGNORE] The blob's block's parent (defined by sidecar.block_parent_root) has been seen (via both gossip and non-gossip sources) | |
| // [IGNORE] The sidecars's block's parent (defined by sidecar.block_parent_root) has been seen (via both gossip and non-gossip sources) |
Nitpick :)
beacon-chain/sync/validate_blob.go
Outdated
| parentRoot := bytesutil.ToBytes32(blob.BlockParentRoot) | ||
| if !s.cfg.chain.HasBlock(ctx, parentRoot) { | ||
| if err := s.addPendingBlobToCache(sBlob); err != nil { | ||
| log.WithError(err).WithFields(blobFields(blob)).Error("Failed to add blob to queue") |
There was a problem hiding this comment.
| log.WithError(err).WithFields(blobFields(blob)).Error("Failed to add blob to queue") | |
| log.WithError(err).WithFields(blobFields(blob)).Error("Failed to add blob to cache") |
beacon-chain/sync/validate_blob.go
Outdated
| } | ||
|
|
||
| // [REJECT] The sidecar's block's parent (defined by sidecar.block_parent_root) passes validation. | ||
| blk, err := s.cfg.chain.GetBlock(ctx, parentRoot) |
There was a problem hiding this comment.
Is this enough for "passes validation"?
There was a problem hiding this comment.
It's enough. We only put validated object in the DB or initial sync cache
| // is valid with respect to the sidecar.proposer_index pubkey. | ||
| parentState, err := s.cfg.stateGen.StateByRoot(ctx, parentRoot) | ||
| if err != nil { | ||
| return pubsub.ValidationIgnore, err |
There was a problem hiding this comment.
Shouldn't we reject here? After all we are unable to verify the signature.
There was a problem hiding this comment.
We are not able to get the parent state, which does not mean we cannot verify the signature. In this case, we probably shouldn't penalize the peer, but we do drop the object
| "github.com/sirupsen/logrus" | ||
| ) | ||
|
|
||
| func (s *Service) validateBlob(ctx context.Context, pid peer.ID, msg *pubsub.Message) (pubsub.ValidationResult, error) { |
There was a problem hiding this comment.
I see a little inconsistency in this function with regards to logging. We usually log before returning on ignore/reject, but not always.
There was a problem hiding this comment.
Good point. I'm only putting them in the relevant parts. I just fixed it and only use debug
5421f7b to
62c6fc4
Compare
| ReceiveBlock(ctx context.Context, block interfaces.ReadOnlySignedBeaconBlock, blockRoot [32]byte) error | ||
| ReceiveBlockBatch(ctx context.Context, blocks []interfaces.ReadOnlySignedBeaconBlock, blkRoots [][32]byte) error | ||
| HasBlock(ctx context.Context, root [32]byte) bool | ||
| GetResentBlockSlot(root [32]byte) (primitives.Slot, error) |
There was a problem hiding this comment.
What's the purpose of using the word Resent here? Was it supposed to be Recent?
There was a problem hiding this comment.
Renamed it to ResentBlockSlot :)
Co-authored-by: Sammy Rosso <15244892+saolyn@users.noreply.github.com>
Co-authored-by: Sammy Rosso <15244892+saolyn@users.noreply.github.com>
Co-authored-by: Sammy Rosso <15244892+saolyn@users.noreply.github.com>
This PR
validate_blobs.go