-
-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve AggregateAndProof gossip validation #2329
Improve AggregateAndProof gossip validation #2329
Conversation
Code Climate has analyzed commit f45ffee and detected 1 issue on this pull request. Here's the issue category breakdown:
View more on Code Climate. |
d65e58f
to
bdb80e5
Compare
some statistic (found cached AggregateAndProof / total)
|
based on prater block explorer, I think there are at most 64 attestation data based on 64 different committee index of the same slot. There are ~600 different AggregateAndProof messages of the same slot because each aggregator see different
what do you think @dapplion ? |
@wemeetagain Can confirm but we should take any aggregate that includes new bits so the fork choice is aware of as many attestations as possible |
in that case we should cache AttestationData root + XOR of (
|
0426a73
to
6ca8401
Compare
with the cache by AttestationData root hex + XOR (aggregationBits) we have (found seen gossip AggregationAndProof/total):
so we don't have to validate every SignedAggregateAndProof like before, just around 30% of that |
|
||
/** | ||
* USed to verify gossip attestation. When there are multiple | ||
* attestation from same validator | ||
*/ | ||
export class SeenAttestationCache { | ||
private cache: Map<string, boolean>; | ||
|
||
// key as AttestationDelta root hex, value as aggregationBits |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// key as AttestationDelta root hex, value as aggregationBits | |
// key as AttestationData root hex, value as aggregationBits |
* We're only interested in the AttestationData + aggregationBits inside AggregateAndProof. | ||
*/ | ||
private aggregateAndProofKey(value: phase0.AggregateAndProof): string { | ||
return toHexString(this.config.types.phase0.AttestationData.hashTreeRoot(value.aggregate.data)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return toHexString(this.config.types.phase0.AttestationData.hashTreeRoot(value.aggregate.data)); | |
return toHexString(this.config.getTypes(value.aggregate.slot).AttestationData.hashTreeRoot(value.aggregate.data)); |
this.attDataCache.set( | ||
key, | ||
aggBit.map((_, i) => aggBit[i] || cachedAggBit[i]) | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might consider something like:
for (const [i, bit] of aggBit.entries()) {
if (bit) {
cachedAggBit[i] = true;
}
}
tbh i'm not sure which is better.
@@ -48,7 +48,7 @@ export class BeaconDb extends DatabaseService implements IBeaconDb { | |||
this.badBlock = new BadBlockRepository(this.config, this.db); | |||
this.block = new BlockRepository(this.config, this.db); | |||
this.pendingBlock = new PendingBlockRepository(this.config, this.db); | |||
this.seenAttestationCache = new SeenAttestationCache(5000); | |||
this.seenAttestationCache = new SeenAttestationCache(this.config, 2048); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious why this is decreased?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
currently it's used for 2 caches: (committee) Attestation and AttestationAndProof but this PR changes to cache them separately so mathematically it should be 5000 / 2 = 2500
, but I changed it to 2048
…x root and aggregationBits
6ca8401
to
995860f
Compare
995860f
to
f45ffee
Compare
@@ -20,7 +20,8 @@ import { | |||
// Numbers from https://github.com/sigp/lighthouse/blob/b34a79dc0b02e04441ba01fd0f304d1e203d877d/beacon_node/network/src/beacon_processor/mod.rs#L69 | |||
const gossipQueueOpts: {[K in GossipType]: {maxLength: number; type: QueueType}} = { | |||
[GossipType.beacon_block]: {maxLength: 1024, type: QueueType.FIFO}, | |||
[GossipType.beacon_aggregate_and_proof]: {maxLength: 1024, type: QueueType.LIFO}, | |||
// this is different from lighthouse's, there are more gossip aggregate_and_proof than gossip block | |||
[GossipType.beacon_aggregate_and_proof]: {maxLength: 4096, type: QueueType.LIFO}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the rationale for changing maxLength
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the issue itself is the queue length is not enough to handle SignedAggregateAndProof gossip topic, it's ~600 gossip messages per slot
Motivation
struct_hashTreeRoot
Description
part of #2306