status-im
/
nimbus-eth2
mirror of https://github.com/status-im/nimbus-eth2.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
nimbus-eth2/tests/test_sync_committee_pool.nim

370 lines
12 KiB
Nim
Raw Permalink Normal View History

segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
# beacon_chain
# Copyright (c) 2021-2023 Status Research & Development GmbH
# Licensed and distributed under either of
# * MIT license (license terms in the root directory or at https://opensource.org/licenses/MIT).
# * Apache v2 license (license terms in the root directory or at https://www.apache.org/licenses/LICENSE-2.0).
# at your option. This file may not be copied, modified, or distributed except according to those terms.
update 29 Altair spec ref URLs to beta.3 (#2839)
2021-08-31 12:16:27 +00:00
{.used.}
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
import
unittest2,
import cleanup (#2997) * import cleanup ...and remove some unused types * add random imports * more imports
2021-10-19 14:09:26 +00:00
../beacon_chain/spec/[beaconstate, helpers, signatures],
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
../beacon_chain/consensus_object_pools/sync_committee_msg_pool,
import cleanup (#2997) * import cleanup ...and remove some unused types * add random imports * more imports
2021-10-19 14:09:26 +00:00
./testblockutil
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
enable `styleCheck:usages` (#3573) Some upstream repos still need fixes, but this gets us close enough that style hints can be enabled by default. In general, "canonical" spellings are preferred even if they violate nep-1 - this applies in particular to spec-related stuff like `genesis_validators_root` which appears throughout the codebase.
2022-04-08 16:22:49 +00:00
func aggregate(sigs: openArray[CookedSig]): CookedSig =
rename no{R=>r}eturn, no{I=>i}init, short{l=>L}og, E{T=>t}h2Node, Beacon{c=>C}hainDB (#3403)
2022-02-16 22:24:44 +00:00
var agg {.noinit.}: AggregateSignature
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
agg.init sigs[0]
for i in 1 ..< sigs.len:
agg.aggregate sigs[i]
agg.finish
suite "Sync committee pool":
setup:
reduce `nim-eth` dependencies just for RNG (#5099) We have several modules that import `nim-eth` for the sole purpose of its `keys.newRng` function. This function is meanwhile a simple wrapper around `nim-bearssl`'s `HmacDrbgContext.new()`, so the import doesn't really serve a use anymore. Replace `keys.newRng` with the direct call to reduce `nim-eth` imports.
2023-06-19 22:43:50 +00:00
let
rng = HmacDrbgContext.new()
cfg = block:
var res = defaultRuntimeConfig
res.ALTAIR_FORK_EPOCH = 0.Epoch
res.BELLATRIX_FORK_EPOCH = 20.Epoch
res
var pool = SyncCommitteeMsgPool.init(rng, cfg)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
test "An empty pool is safe to use":
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
let headBid =
BlockId(slot: Slot(1), root: eth2digest(@[1.byte, 2, 3]))
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
var outContribution: SyncCommitteeContribution
let success = pool.produceContribution(
Slot(1),
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
headBid,
clean up sync subcommittee handling * `SyncCommitteeIndex` -> `SyncSubcommitteeIndex` * `syncCommitteePeriod` -> `sync_committee_period` (spec spelling) * tighten period comparisons * fix assert when validating committee message with non-altair state in REST api
2021-10-20 16:32:46 +00:00
SyncSubcommitteeIndex(0),
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
outContribution)
check(success == false)
use correct slot when producing sync aggregate around forks (#5089) `produceSyncAggregate` is called in new slot when block is produced, while the other functions in `sync_committee_msg_pool` are called in previous slot. So, need to subtract 1 slot when producing sync aggregate to accept the signatures using the old digest during fork transition.
2023-06-16 21:30:36 +00:00
let aggregate = pool.produceSyncAggregate(headBid, headBid.slot + 1)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
check:
aggregate.sync_committee_bits.isZeros
aggregate.sync_committee_signature == ValidatorSig.infinity
test "An empty pool is safe to prune":
pool.pruneData(Slot(0))
test "An empty pool is safe to prune 2":
pool.pruneData(Slot(10000))
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
test "Missed slots across sync committee period boundary":
let
genesis_validators_root = eth2digest(@[5.byte, 6, 7])
privkey1 = MockPrivKeys[1.ValidatorIndex]
privkey2 = MockPrivKeys[2.ValidatorIndex]
nextPeriod = cfg.BELLATRIX_FORK_EPOCH.sync_committee_period + 1
bid1 = BlockId(
slot: Slot(nextPeriod.start_slot - 2), # Committee based on `slot + 1`
root: eth2digest(@[1.byte]))
sig1 = get_sync_committee_message_signature(
bellatrixFork(cfg), genesis_validators_root,
bid1.slot, bid1.root, privkey1)
sig2 = get_sync_committee_message_signature(
bellatrixFork(cfg), genesis_validators_root,
bid1.slot + 1, bid1.root, privkey2)
pool.addSyncCommitteeMessage(
bid1.slot, bid1, 1, sig1, SyncSubcommitteeIndex(0), @[1'u64])
pool.addSyncCommitteeMessage(
# Same participant index in next period represents different validator
bid1.slot + 1, bid1, 2, sig2, SyncSubcommitteeIndex(0), @[1'u64])
var contribution: SyncCommitteeContribution
let success = pool.produceContribution(
bid1.slot + 1, bid1, SyncSubcommitteeIndex(0), contribution)
check:
success
contribution.slot == bid1.slot + 1
contribution.beacon_block_root == bid1.root
contribution.subcommittee_index == SyncSubcommitteeIndex(0).uint64
contribution.aggregation_bits.countOnes == 1
contribution.aggregation_bits[1] == true
contribution.signature == sig2.toValidatorSig
test "Missed slots across fork transition":
let
genesis_validators_root = eth2digest(@[5.byte, 6, 7])
privkey1 = MockPrivKeys[1.ValidatorIndex]
privkey2 = MockPrivKeys[1.ValidatorIndex]
bid1 = BlockId(
slot: Slot(cfg.BELLATRIX_FORK_EPOCH.start_slot - 1),
root: eth2digest(@[1.byte]))
sig1 = get_sync_committee_message_signature(
altairFork(cfg), genesis_validators_root,
bid1.slot, bid1.root, privkey1)
sig2 = get_sync_committee_message_signature(
bellatrixFork(cfg), genesis_validators_root,
bid1.slot + 1, bid1.root, privkey2)
pool.addSyncCommitteeMessage(
bid1.slot, bid1, 1, sig1, SyncSubcommitteeIndex(0), @[1'u64])
pool.addSyncCommitteeMessage(
bid1.slot + 1, bid1, 2, sig2, SyncSubcommitteeIndex(0), @[2'u64])
var contribution: SyncCommitteeContribution
let success = pool.produceContribution(
bid1.slot + 1, bid1, SyncSubcommitteeIndex(0), contribution)
check:
success
contribution.slot == bid1.slot + 1
contribution.beacon_block_root == bid1.root
contribution.subcommittee_index == SyncSubcommitteeIndex(0).uint64
contribution.aggregation_bits.countOnes == 1
contribution.aggregation_bits[2] == true
contribution.signature == sig2.toValidatorSig
test "isSeen":
let
fork = altairFork(cfg)
genesis_validators_root = eth2digest(@[5.byte, 6, 7])
privkey1 = MockPrivKeys[1.ValidatorIndex]
bid1 = BlockId(slot: Slot(100), root: eth2digest(@[1.byte]))
bid2 = BlockId(slot: Slot(101), root: eth2digest(@[1.byte, 2]))
sig1 = get_sync_committee_message_signature(
fork, genesis_validators_root, bid2.slot, bid1.root, privkey1)
sig2 = get_sync_committee_message_signature(
fork, genesis_validators_root, bid2.slot, bid2.root, privkey1)
msg1 = SyncCommitteeMessage(
slot: bid2.slot,
beacon_block_root: bid1.root,
validator_index: 1,
signature: sig1.toValidatorSig)
msg2 = SyncCommitteeMessage(
slot: bid2.slot,
beacon_block_root: bid2.root,
validator_index: 1,
signature: sig2.toValidatorSig)
check:
not pool.isSeen(msg1, SyncSubcommitteeIndex(0), bid2)
not pool.isSeen(msg2, SyncSubcommitteeIndex(0), bid2)
pool.addSyncCommitteeMessage(
bid2.slot, bid1, 1, sig1, SyncSubcommitteeIndex(0), @[1'u64])
check:
pool.isSeen(msg1, SyncSubcommitteeIndex(0), bid2)
not pool.isSeen(msg2, SyncSubcommitteeIndex(0), bid2)
pool.addSyncCommitteeMessage(
bid2.slot, bid2, 1, sig1, SyncSubcommitteeIndex(0), @[1'u64])
check:
pool.isSeen(msg1, SyncSubcommitteeIndex(0), bid2)
pool.isSeen(msg2, SyncSubcommitteeIndex(0), bid2)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
test "Aggregating votes":
let
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
fork = altairFork(cfg)
enable `styleCheck:usages` (#3573) Some upstream repos still need fixes, but this gets us close enough that style hints can be enabled by default. In general, "canonical" spellings are preferred even if they violate nep-1 - this applies in particular to spec-related stuff like `genesis_validators_root` which appears throughout the codebase.
2022-04-08 16:22:49 +00:00
genesis_validators_root = eth2digest(@[5.byte, 6, 7])
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
remove privkey from mock withdrawal credentials (#2936) In tests, the private key was put into the validator deposit's withdraw credentials so that it can be recovered later. This leads to problems when creating the validators through other means that do not put the key there. In general, mock private keys only depend on the validator index, though, and because it is clear what the index of a validator is, it is not actually needed to put the key into the credentials.
2021-10-01 11:35:16 +00:00
privkey1 = MockPrivKeys[1.ValidatorIndex]
privkey2 = MockPrivKeys[2.ValidatorIndex]
privkey3 = MockPrivKeys[3.ValidatorIndex]
privkey4 = MockPrivKeys[4.ValidatorIndex]
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
bid1 = BlockId(slot: Slot(100), root: eth2digest(@[1.byte]))
bid2 = BlockId(slot: Slot(101), root: eth2digest(@[1.byte, 2]))
bid3 = BlockId(slot: Slot(101), root: eth2digest(@[1.byte, 2, 3]))
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
clean up sync subcommittee handling * `SyncCommitteeIndex` -> `SyncSubcommitteeIndex` * `syncCommitteePeriod` -> `sync_committee_period` (spec spelling) * tighten period comparisons * fix assert when validating committee message with non-altair state in REST api
2021-10-20 16:32:46 +00:00
subcommittee1 = SyncSubcommitteeIndex(0)
subcommittee2 = SyncSubcommitteeIndex(1)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
batch-verify sync messages for a small perf boost (#3151) * batch-verify sync messages for a small perf boost Generally reuses the same structure as attestation and aggregate verification * normalize `signatures` and `signature_batch` to use the same pattern of verification * normalize parameter names, order etc for signature stuff in general * avoid calling `blsSign` directly - instead, go through `signatures` consistently
2021-12-09 12:56:54 +00:00
sig1 = get_sync_committee_message_signature(
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
fork, genesis_validators_root, bid1.slot, bid1.root, privkey1)
batch-verify sync messages for a small perf boost (#3151) * batch-verify sync messages for a small perf boost Generally reuses the same structure as attestation and aggregate verification * normalize `signatures` and `signature_batch` to use the same pattern of verification * normalize parameter names, order etc for signature stuff in general * avoid calling `blsSign` directly - instead, go through `signatures` consistently
2021-12-09 12:56:54 +00:00
sig2 = get_sync_committee_message_signature(
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
fork, genesis_validators_root, bid2.slot, bid2.root, privkey1)
batch-verify sync messages for a small perf boost (#3151) * batch-verify sync messages for a small perf boost Generally reuses the same structure as attestation and aggregate verification * normalize `signatures` and `signature_batch` to use the same pattern of verification * normalize parameter names, order etc for signature stuff in general * avoid calling `blsSign` directly - instead, go through `signatures` consistently
2021-12-09 12:56:54 +00:00
sig3 = get_sync_committee_message_signature(
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
fork, genesis_validators_root, bid3.slot, bid3.root, privkey1)
batch-verify sync messages for a small perf boost (#3151) * batch-verify sync messages for a small perf boost Generally reuses the same structure as attestation and aggregate verification * normalize `signatures` and `signature_batch` to use the same pattern of verification * normalize parameter names, order etc for signature stuff in general * avoid calling `blsSign` directly - instead, go through `signatures` consistently
2021-12-09 12:56:54 +00:00
sig4 = get_sync_committee_message_signature(
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
fork, genesis_validators_root, bid3.slot, bid2.root, privkey1)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
# Inserting sync committee messages
#
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
pool.addSyncCommitteeMessage(
bid1.slot, bid1, 1, sig1, subcommittee1, @[1'u64])
pool.addSyncCommitteeMessage(
bid1.slot, bid1, 2, sig2, subcommittee1, @[10'u64])
pool.addSyncCommitteeMessage(
bid2.slot, bid1, 3, sig3, subcommittee2, @[7'u64])
pool.addSyncCommitteeMessage(
bid2.slot, bid2, 4, sig4, subcommittee2, @[3'u64])
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
Bugfix: Avoid the aggregation of duplicate signatures when creating sync committee contributions
2021-11-04 18:22:24 +00:00
# Insert a duplicate message (this should be handled gracefully)
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
pool.addSyncCommitteeMessage(
bid1.slot, bid1, 1, sig1, subcommittee1, @[1'u64])
Bugfix: Avoid the aggregation of duplicate signatures when creating sync committee contributions
2021-11-04 18:22:24 +00:00
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
# Producing contributions
#
block:
# Checking a committee where there was no activity:
var outContribution: SyncCommitteeContribution
let success = pool.produceContribution(
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
bid2.slot,
bid2,
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
subcommittee1,
outContribution)
check:
not success
block:
# Checking a committee where 2 signatures should have been aggregated:
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
var outContribution: SignedContributionAndProof
template contribution: untyped = outContribution.message.contribution
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
let success = pool.produceContribution(
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
bid1.slot,
bid1,
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
subcommittee1,
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
contribution)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
let sig = aggregate [sig1, sig2]
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
check:
success
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
contribution.slot == bid1.slot
contribution.beacon_block_root == bid1.root
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
contribution.subcommittee_index == subcommittee1.uint64
contribution.aggregation_bits.countOnes == 2
contribution.aggregation_bits[1] == true
contribution.aggregation_bits[8] == false
contribution.aggregation_bits[10] == true
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
contribution.signature == sig.toValidatorSig
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
Implement a missing ingnore rule for sync committee contributions (#3941)
2022-08-09 09:52:11 +00:00
check:
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
not pool.covers(contribution, bid1)
drop subset sync contributions in gossip (#4490) * correctly report ignored contributions in metrics * avoid counting subset contributions in vmon (bring in line with attestation aggregates) * avoid signature checks for subset attestations A being a non-strict subset is a sufficient condition to ignore.
2023-01-12 14:08:08 +00:00
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
pool.addContribution(outContribution, bid1, sig)
drop subset sync contributions in gossip (#4490) * correctly report ignored contributions in metrics * avoid counting subset contributions in vmon (bring in line with attestation aggregates) * avoid signature checks for subset attestations A being a non-strict subset is a sufficient condition to ignore.
2023-01-12 14:08:08 +00:00
check:
Implement a missing ingnore rule for sync committee contributions (#3941)
2022-08-09 09:52:11 +00:00
pool.isSeen(outContribution.message)
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
pool.covers(contribution, bid1)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
block:
# Checking a committee with a signle participant:
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
var outContribution: SignedContributionAndProof
template contribution: untyped = outContribution.message.contribution
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
let success = pool.produceContribution(
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
bid1.slot,
bid1,
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
subcommittee2,
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
contribution)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
check:
success
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
contribution.slot == bid1.slot
contribution.beacon_block_root == bid1.root
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
contribution.subcommittee_index == subcommittee2.uint64
contribution.aggregation_bits.countOnes == 1
contribution.aggregation_bits[7] == true
contribution.signature == sig3.toValidatorSig
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
Implement a missing ingnore rule for sync committee contributions (#3941)
2022-08-09 09:52:11 +00:00
check:
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
not pool.covers(contribution, bid1)
pool.addContribution(outContribution, bid1, sig3)
drop subset sync contributions in gossip (#4490) * correctly report ignored contributions in metrics * avoid counting subset contributions in vmon (bring in line with attestation aggregates) * avoid signature checks for subset attestations A being a non-strict subset is a sufficient condition to ignore.
2023-01-12 14:08:08 +00:00
check:
Implement a missing ingnore rule for sync committee contributions (#3941)
2022-08-09 09:52:11 +00:00
pool.isSeen(outContribution.message)
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
pool.covers(contribution, bid1)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
block:
# Checking another committee with a signle participant
# voting for a different block:
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
var outContribution: SignedContributionAndProof
template contribution: untyped = outContribution.message.contribution
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
let success = pool.produceContribution(
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
bid2.slot,
bid2,
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
subcommittee2,
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
contribution)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
check:
success
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
contribution.slot == bid2.slot
contribution.beacon_block_root == bid2.root
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
contribution.subcommittee_index == subcommittee2.uint64
contribution.aggregation_bits.countOnes == 1
contribution.aggregation_bits[3] == true
contribution.signature == sig4.toValidatorSig
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
Implement a missing ingnore rule for sync committee contributions (#3941)
2022-08-09 09:52:11 +00:00
check:
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
not pool.covers(contribution, bid2)
pool.addContribution(outContribution, bid2, sig4)
drop subset sync contributions in gossip (#4490) * correctly report ignored contributions in metrics * avoid counting subset contributions in vmon (bring in line with attestation aggregates) * avoid signature checks for subset attestations A being a non-strict subset is a sufficient condition to ignore.
2023-01-12 14:08:08 +00:00
check:
Implement a missing ingnore rule for sync committee contributions (#3941)
2022-08-09 09:52:11 +00:00
pool.isSeen(outContribution.message)
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
pool.covers(contribution, bid2)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
block:
# Checking a block root nobody voted for
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
var outContribution: SignedContributionAndProof
template contribution: untyped = outContribution.message.contribution
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
let success = pool.produceContribution(
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
bid3.slot,
bid3,
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
subcommittee2,
Better REST/RPC error messages (#3046) * Better REST/RPC error messages * homogenise block logging (root first) * homegenise message verification pipeline (verify in `gossip_verification`, act in `eth2_processor`) * use `subcommitteeIdx` consistently * log each sent contribution * fix block_sim * fix block topic * don't recalc root on gossip block validation * move position loop into sync pool
2021-11-05 15:39:47 +00:00
contribution)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
check:
not success
# Obtaining a SyncAggregate
#
block:
# Checking for a block that got no votes
use correct slot when producing sync aggregate around forks (#5089) `produceSyncAggregate` is called in new slot when block is produced, while the other functions in `sync_committee_msg_pool` are called in previous slot. So, need to subtract 1 slot when producing sync aggregate to accept the signatures using the old digest during fork transition.
2023-06-16 21:30:36 +00:00
let aggregate = pool.produceSyncAggregate(bid3, bid3.slot + 1)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
check:
aggregate.sync_committee_bits.isZeros
aggregate.sync_committee_signature == ValidatorSig.infinity
block:
# Checking for a block that got votes from 1 committee
use correct slot when producing sync aggregate around forks (#5089) `produceSyncAggregate` is called in new slot when block is produced, while the other functions in `sync_committee_msg_pool` are called in previous slot. So, need to subtract 1 slot when producing sync aggregate to accept the signatures using the old digest during fork transition.
2023-06-16 21:30:36 +00:00
let aggregate = pool.produceSyncAggregate(bid2, bid2.slot + 1)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
check:
aggregate.sync_committee_bits.countOnes == 1
aggregate.sync_committee_signature == sig4.toValidatorSig
block:
# Checking for a block that got votes from 2 committees
use correct slot when producing sync aggregate around forks (#5089) `produceSyncAggregate` is called in new slot when block is produced, while the other functions in `sync_committee_msg_pool` are called in previous slot. So, need to subtract 1 slot when producing sync aggregate to accept the signatures using the old digest during fork transition.
2023-06-16 21:30:36 +00:00
let aggregate = pool.produceSyncAggregate(bid1, bid1.slot + 1)
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
let sig = aggregate [sig1, sig2, sig3]
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
check:
aggregate.sync_committee_bits.countOnes == 3
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
aggregate.sync_committee_signature == sig.toValidatorSig
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
# Pruning the data
#
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
pool.pruneData(Slot(200), force = true)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
block:
# After pruning, all votes are gone
var outContribution: SyncCommitteeContribution
let success = pool.produceContribution(
segregate sync committee messages by period / fork (#4953) `SyncCommitteeMsgPool` grouped messages by their `beacon_block_root`. This is problematic around sync committee period boundaries and forks. Around sync committee period boundaries, members from both the current and next sync committee may sign the same `beacon_block_root`; mixing the signatures from both committees together is a mistake. Likewise, around fork transitions, the `signing_root` changes, so those messages also need to be segregated.
2023-05-17 04:55:55 +00:00
bid1.slot,
bid1,
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
subcommittee1,
outContribution)
check:
not success
use correct slot when producing sync aggregate around forks (#5089) `produceSyncAggregate` is called in new slot when block is produced, while the other functions in `sync_committee_msg_pool` are called in previous slot. So, need to subtract 1 slot when producing sync aggregate to accept the signatures using the old digest during fork transition.
2023-06-16 21:30:36 +00:00
let aggregate = pool.produceSyncAggregate(bid2, bid2.slot + 1)
Restore the sync committee pool pruning and add tests
2021-08-30 01:00:37 +00:00
check:
aggregate.sync_committee_bits.isZeros
aggregate.sync_committee_signature == ValidatorSig.infinity