mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-23 09:41:07 +00:00
approval-voting improvement: include all tranche0 assignments in one certificate (#1178)
**_PR migrated from https://github.com/paritytech/polkadot/pull/6782_** This PR will upgrade the network protocol to version 3 -> VStaging which will later be renamed to V3. This version introduces a new kind of assignment certificate that will be used for tranche0 assignments. Instead of issuing/importing one tranche0 assignment per candidate, there will be just one certificate per relay chain block per validator. However, we will not be sending out the new assignment certificates, yet. So everything should work exactly as before. Once the majority of the validators have been upgraded to the new protocol version we will enable the new certificates (starting at a specific relay chain block) with a new client update. There are still a few things that need to be done: - [x] Use bitfield instead of Vec<CandidateIndex>: https://github.com/paritytech/polkadot/pull/6802 - [x] Fix existing approval-distribution and approval-voting tests - [x] Fix bitfield-distribution and statement-distribution tests - [x] Fix network bridge tests - [x] Implement todos in the code - [x] Add tests to cover new code - [x] Update metrics - [x] Remove the approval distribution aggression levels: TBD PR - [x] Parachains DB migration - [x] Test network protocol upgrade on Versi - [x] Versi Load test - [x] Add Zombienet test - [x] Documentation updates - [x] Fix for sending DistributeAssignment for each candidate claimed by a v2 assignment (warning: Importing locally an already known assignment) - [x] Fix AcceptedDuplicate - [x] Fix DB migration so that we can still keep old data. - [x] Final Versi burn in --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io> Co-authored-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
This commit is contained in:
Andrei Sandu
@@ -75,22 +75,27 @@ struct TrancheEntry {
|
||||
assignments: Vec<(ValidatorIndex, Tick)>,
|
||||
}
|
||||
|
||||
struct OurAssignment {
|
||||
cert: AssignmentCert,
|
||||
tranche: DelayTranche,
|
||||
validator_index: ValidatorIndex,
|
||||
triggered: bool,
|
||||
pub struct OurAssignment {
|
||||
/// Our assignment certificate.
|
||||
cert: AssignmentCertV2,
|
||||
/// The tranche for which the assignment refers to.
|
||||
tranche: DelayTranche,
|
||||
/// Our validator index for the session in which the candidates were included.
|
||||
validator_index: ValidatorIndex,
|
||||
/// Whether the assignment has been triggered already.
|
||||
triggered: bool,
|
||||
}
|
||||
|
||||
struct ApprovalEntry {
|
||||
tranches: Vec<TrancheEntry>, // sorted ascending by tranche number.
|
||||
backing_group: GroupIndex,
|
||||
our_assignment: Option<OurAssignment>,
|
||||
our_approval_sig: Option<ValidatorSignature>,
|
||||
assignments: Bitfield, // n_validators bits
|
||||
approved: bool,
|
||||
pub struct ApprovalEntry {
|
||||
tranches: Vec<TrancheEntry>, // sorted ascending by tranche number.
|
||||
backing_group: GroupIndex,
|
||||
our_assignment: Option<OurAssignment>,
|
||||
our_approval_sig: Option<ValidatorSignature>,
|
||||
assigned_validators: Bitfield, // `n_validators` bits.
|
||||
approved: bool,
|
||||
}
|
||||
|
||||
|
||||
struct CandidateEntry {
|
||||
candidate: CandidateReceipt,
|
||||
session: SessionIndex,
|
||||
@@ -264,19 +269,25 @@ entry. The cert itself contains information necessary to determine the candidate
|
||||
* Check the assignment cert
|
||||
* If the cert kind is `RelayVRFModulo`, then the certificate is valid as long as `sample <
|
||||
session_info.relay_vrf_samples` and the VRF is valid for the validator's key with the input
|
||||
`block_entry.relay_vrf_story ++ sample.encode()` as described with [the approvals protocol
|
||||
section](../../protocol-approval.md#assignment-criteria). We set `core_index = vrf.make_bytes().to_u32() %
|
||||
session_info.n_cores`. If the `BlockEntry` causes inclusion of a candidate at `core_index`, then this is a valid
|
||||
assignment for the candidate at `core_index` and has delay tranche 0. Otherwise, it can be ignored.
|
||||
* If the cert kind is `RelayVRFDelay`, then we check if the VRF is valid for the validator's key with the input
|
||||
`block_entry.relay_vrf_story ++ cert.core_index.encode()` as described in [the approvals protocol
|
||||
section](../../protocol-approval.md#assignment-criteria). The cert can be ignored if the block did not cause
|
||||
inclusion of a candidate on that core index. Otherwise, this is a valid assignment for the included candidate. The
|
||||
delay tranche for the assignment is determined by reducing `(vrf.make_bytes().to_u64() %
|
||||
(session_info.n_delay_tranches +
|
||||
session_info.zeroth_delay_tranche_width)).saturating_sub(session_info.zeroth_delay_tranche_width)`.
|
||||
* We also check that the core index derived by the output is covered by the `VRFProof` by means of an auxiliary
|
||||
signature.
|
||||
`block_entry.relay_vrf_story ++ sample.encode()` as described with
|
||||
[the approvals protocol section](../../protocol-approval.md#assignment-criteria). We set
|
||||
`core_index = vrf.make_bytes().to_u32() % session_info.n_cores`. If the `BlockEntry` causes
|
||||
inclusion of a candidate at `core_index`, then this is a valid assignment for the candidate
|
||||
at `core_index` and has delay tranche 0. Otherwise, it can be ignored.
|
||||
* If the cert kind is `RelayVRFModuloCompact`, then the certificate is valid as long as the VRF
|
||||
is valid for the validator's key with the input `block_entry.relay_vrf_story ++ relay_vrf_samples.encode()`
|
||||
as described with [the approvals protocol section](../../protocol-approval.md#assignment-criteria).
|
||||
We enforce that all `core_bitfield` indices are included in the set of the core indices sampled from the
|
||||
VRF Output. The assignment is considered a valid tranche0 assignment for all claimed candidates if all
|
||||
`core_bitfield` indices match the core indices where the claimed candidates were included at.
|
||||
|
||||
* If the cert kind is `RelayVRFDelay`, then we check if the VRF is valid for the validator's key with the
|
||||
input `block_entry.relay_vrf_story ++ cert.core_index.encode()` as described in [the approvals protocol
|
||||
section](../../protocol-approval.md#assignment-criteria). The cert can be ignored if the block did not
|
||||
cause inclusion of a candidate on that core index. Otherwise, this is a valid assignment for the included
|
||||
candidate. The delay tranche for the assignment is determined by reducing
|
||||
`(vrf.make_bytes().to_u64() % (session_info.n_delay_tranches + session_info.zeroth_delay_tranche_width)).saturating_sub(session_info.zeroth_delay_tranche_width)`.
|
||||
* We also check that the core index derived by the output is covered by the `VRFProof` by means of an auxiliary signature.
|
||||
* If the delay tranche is too far in the future, return `AssignmentCheckResult::TooFarInFuture`.
|
||||
* Import the assignment.
|
||||
* Load the candidate in question and access the `approval_entry` for the block hash the cert references.
|
||||
|
||||
@@ -189,9 +189,10 @@ Assignment criteria compute actual assignments using stories and the validators'
|
||||
Assignment criteria output a `Position` consisting of both a `ParaId` to be checked, as well as a precedence
|
||||
`DelayTranche` for when the assignment becomes valid.
|
||||
|
||||
Assignment criteria come in three flavors, `RelayVRFModulo`, `RelayVRFDelay` and `RelayEquivocation`. Among these, both
|
||||
`RelayVRFModulo` and `RelayVRFDelay` run a VRF whose input is the output of a `RelayVRFStory`, while `RelayEquivocation`
|
||||
runs a VRF whose input is the output of a `RelayEquivocationStory`.
|
||||
Assignment criteria come in four flavors, `RelayVRFModuloCompact`, `RelayVRFDelay`, `RelayEquivocation` and the
|
||||
deprecated `RelayVRFModulo`. Among these, `RelayVRFModulo`, `RelayVRFModuloCompact` and `RelayVRFDelay` run a
|
||||
VRF whose input is the output of a `RelayVRFStory`, while `RelayEquivocation` runs a VRF whose input is the
|
||||
output of a `RelayEquivocationStory`.
|
||||
|
||||
Among these, we have two distinct VRF output computations:
|
||||
|
||||
@@ -203,6 +204,12 @@ sampled availability core in this relay chain block. We choose three samples in
|
||||
secure and efficient by increasing this to four or five, and reducing the backing checks accordingly. All successful
|
||||
`RelayVRFModulo` samples are assigned delay tranche zero.
|
||||
|
||||
`RelayVRFModuloCompact` runs a single samples whose VRF input is the `RelayVRFStory` and the sample count. Similar
|
||||
to `RelayVRFModulo` introduces multiple core assignments for tranche zero. It computes the VRF output with
|
||||
`schnorrkel::vrf::VRFInOut::make_bytes` using the context "A&V Core v2" and samples up to 160 bytes of the output
|
||||
as an array of `u32`. Then reduces each `u32` modulo the number of availability cores, and outputs up
|
||||
to `relay_vrf_modulo_samples` availability core indices.
|
||||
|
||||
There is no sampling process for `RelayVRFDelay` and `RelayEquivocation`. We instead run them on specific candidates
|
||||
and they compute a delay from their VRF output. `RelayVRFDelay` runs for all candidates included under, aka declared
|
||||
available by, a relay chain block, and inputs the associated VRF output via `RelayVRFStory`. `RelayEquivocation` runs
|
||||
@@ -223,14 +230,14 @@ We track all validators' announced approval assignments for each candidate assoc
|
||||
tells us which validators were assigned to which candidates.
|
||||
|
||||
We permit at most one assignment per candidate per story per validator, so one validator could be assigned under both
|
||||
the `RelayVRFDelay` and `RelayEquivocation` criteria, but not under both `RelayVRFModulo` and `RelayVRFDelay` criteria,
|
||||
since those both use the same story. We permit only one approval vote per candidate per validator, which counts for any
|
||||
applicable criteria.
|
||||
the `RelayVRFDelay` and `RelayEquivocation` criteria, but not under both `RelayVRFModulo/RelayVRFModuloCompact`
|
||||
and `RelayVRFDelay` criteria, since those both use the same story. We permit only one approval vote per candidate per
|
||||
validator, which counts for any applicable criteria.
|
||||
|
||||
We announce, and start checking for, our own assignments when the delay of their tranche is reached, but only if the
|
||||
tracker says the assignee candidate requires more approval checkers. We never announce an assignment we believe
|
||||
unnecessary because early announcements gives an adversary information. All delay tranche zero assignments always get
|
||||
announced, which includes all `RelayVRFModulo` assignments.
|
||||
tracker says the assignee candidate requires more approval checkers. We never announce an assignment we believe unnecessary
|
||||
because early announcements gives an adversary information. All delay tranche zero assignments always get announced,
|
||||
which includes all `RelayVRFModulo` and `RelayVRFModuloCompact` assignments.
|
||||
|
||||
In other words, if some candidate `C` needs more approval checkers by the time we reach round `t` then any validators
|
||||
with an assignment to `C` in delay tranche `t` gossip their send assignment notice for `C`, and begin reconstruction and
|
||||
@@ -318,10 +325,10 @@ finality. We might explore limits on postponement too, but this sounds much har
|
||||
|
||||
## Parameters
|
||||
|
||||
We prefer doing approval checkers assignments under `RelayVRFModulo` as opposed to `RelayVRFDelay` because
|
||||
`RelayVRFModulo` avoids giving individual checkers too many assignments and tranche zero assignments benefit security
|
||||
the most. We suggest assigning at least 16 checkers under `RelayVRFModulo` although assignment levels have never been
|
||||
properly analyzed.
|
||||
We prefer doing approval checkers assignments under `RelayVRFModulo` or `RelayVRFModuloCompact` as opposed to
|
||||
`RelayVRFDelay` because `RelayVRFModulo` avoids giving individual checkers too many assignments and tranche zero
|
||||
assignments benefit security the most. We suggest assigning at least 16 checkers under `RelayVRFModulo` or
|
||||
`RelayVRFModuloCompact` although assignment levels have never been properly analyzed.
|
||||
|
||||
Our delay criteria `RelayVRFDelay` and `RelayEquivocation` both have two primary paramaters, expected checkers per
|
||||
tranche and the zeroth delay tranche width.
|
||||
|
||||
@@ -22,6 +22,35 @@ enum AssignmentCertKind {
|
||||
}
|
||||
}
|
||||
|
||||
enum AssignmentCertKindV2 {
|
||||
/// Multiple assignment stories based on the VRF that authorized the relay-chain block where the
|
||||
/// candidates were included.
|
||||
///
|
||||
/// The context is [`v2::RELAY_VRF_MODULO_CONTEXT`]
|
||||
RelayVRFModuloCompact {
|
||||
/// A bitfield representing the core indices claimed by this assignment.
|
||||
core_bitfield: CoreBitfield,
|
||||
},
|
||||
/// An assignment story based on the VRF that authorized the relay-chain block where the
|
||||
/// candidate was included combined with the index of a particular core.
|
||||
///
|
||||
/// The context is [`v2::RELAY_VRF_DELAY_CONTEXT`]
|
||||
RelayVRFDelay {
|
||||
/// The core index chosen in this cert.
|
||||
core_index: CoreIndex,
|
||||
},
|
||||
/// Deprectated assignment. Soon to be removed.
|
||||
///
|
||||
/// An assignment story based on the VRF that authorized the relay-chain block where the
|
||||
/// candidate was included combined with a sample number.
|
||||
///
|
||||
/// The context used to produce bytes is [`v1::RELAY_VRF_MODULO_CONTEXT`]
|
||||
RelayVRFModulo {
|
||||
/// The sample number used in this cert.
|
||||
sample: u32,
|
||||
},
|
||||
}
|
||||
|
||||
struct AssignmentCert {
|
||||
// The criterion which is claimed to be met by this cert.
|
||||
kind: AssignmentCertKind,
|
||||
|
||||
@@ -55,7 +55,7 @@ struct HostConfiguration {
|
||||
pub zeroth_delay_tranche_width: u32,
|
||||
/// The number of validators needed to approve a block.
|
||||
pub needed_approvals: u32,
|
||||
/// The number of samples to do of the RelayVRFModulo approval assignment criterion.
|
||||
/// The number of samples to use in `RelayVRFModulo` or `RelayVRFModuloCompact` approval assignment criterions.
|
||||
pub relay_vrf_modulo_samples: u32,
|
||||
/// Total number of individual messages allowed in the parachain -> relay-chain message queue.
|
||||
pub max_upward_queue_count: u32,
|
||||
|
||||
Reference in New Issue
Block a user