Header trusted validators should be taken from trusted header's next validators

[ancazamfir]

Crate

relayer

Summary of Bug

see
informalsystems/tendermint-rs#831 (comment)

Version

Steps to Reproduce

This was seen sporadically on akashnet-2 when trying to update clients.

Fix

@@ -1128,7 +1127,7 @@ impl Chain for CosmosSdkChain {
             trusted_height,
             signed_header: target_light_block.signed_header.clone(),
             validator_set: target_light_block.validators,
-            trusted_validator_set: trusted_light_block.validators,
+            trusted_validator_set: trusted_light_block.next_validators,
         })
     }
 }

This is because the consensus state created on-chain stores the next_validator hash:

	consensusState := &ConsensusState{
		Timestamp:          header.GetTime(),
		Root:               commitmenttypes.NewMerkleRoot(header.Header.GetAppHash()),
		NextValidatorsHash: header.Header.NextValidatorsHash,
	}

When this is later used as trusted consensus state agains a new Header the following is checked:

	tmTrustedValidators, err := tmtypes.ValidatorSetFromProto(header.TrustedValidators)
	if err != nil {
		return sdkerrors.Wrap(err, "trusted validator set in not tendermint validator set type")
	}

	// assert that trustedVals is NextValidators of last trusted header
	// to do this, we check that trustedVals.Hash() == consState.NextValidatorsHash
	tvalHash := tmTrustedValidators.Hash()
	if !bytes.Equal(consState.NextValidatorsHash, tvalHash) {
		return sdkerrors.Wrapf(
			ErrInvalidValidatorSet,
			"trusted validators %s, does not hash to latest trusted validators. Expected: %X, got: %X",
			header.TrustedValidators, consState.NextValidatorsHash, tvalHash,
		)
	}

So header.trusted_validator_set must come from the trusted_header.next_validators

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned