Handle the combination of DKG removals with re-attempts

With a DKG removal comes a reduction in the amount of participants which was
ignored by re-attempts.

Now, we determine n/i based on the parties removed, and deterministically
obtain the context of who was removd.
This commit is contained in:
Luke Parker
2023-12-13 14:03:07 -05:00
parent 884b6a6fec
commit 77edd00725
15 changed files with 410 additions and 132 deletions

View File

@@ -249,8 +249,6 @@ impl<T: TransactionTrait> Block<T> {
}
last_tx_order = current_tx_order;
// TODO: should we modify the verify_transaction to take `Transaction<T>` or
// use this pattern of verifying tendermint Txs and app txs differently?
match tx {
Transaction::Tendermint(tx) => {
match verify_tendermint_tx::<N>(tx, schema.clone(), &commit) {

View File

@@ -272,6 +272,7 @@ impl<D: Db, T: TransactionTrait> Blockchain<D, T> {
provided_in_chain,
allow_non_local_provided,
);
// Drop this TXN's changes as we're solely verifying the block
drop(txn);
res
}

View File

@@ -179,7 +179,6 @@ pub trait Transaction: 'static + Send + Sync + Clone + Eq + Debug + ReadWrite {
pub trait GAIN: FnMut(&<Ristretto as Ciphersuite>::G, &[u8]) -> Option<u32> {}
impl<F: FnMut(&<Ristretto as Ciphersuite>::G, &[u8]) -> Option<u32>> GAIN for F {}
// This will only cause mutations when the transaction is valid
pub(crate) fn verify_transaction<F: GAIN, T: Transaction>(
tx: &T,
genesis: [u8; 32],
@@ -204,7 +203,7 @@ pub(crate) fn verify_transaction<F: GAIN, T: Transaction>(
Err(TransactionError::InvalidSigner)?;
}
// TODO: Use Schnorr half-aggregation and a batch verification here
// TODO: Use a batch verification here
if !signature.verify(*signer, tx.sig_hash(genesis)) {
Err(TransactionError::InvalidSignature)?;
}