Consumer chain validator set

[julienrbrt]

Currently, once a chain launch with this ICS implementation, it will inherit the current validator set of the provider chain.
Given validators updates are fully discarded and provider validator change are not communicated via consensus to the consumer chains, it is possible that the consumer validator set in x/staking diverge from the actual validator set.

To solve this, we first need to decide how we want the system to behave:

1. Keeping consumer validator set in sync with provider chain

   • Possibly via a custom module like x/interchainsecurity sharing validator updates via IBC.

2. Have consumer validator set fully independent from the provider chain

   • This method could allow different kind of governance, where provider chain validators do not need to actively participate in the consumer chain governance.

[julienrbrt]

Right now a consumer chain is initialized with the genesis validator set of the provider (ref #9).
IMHO we should in the AddConsumer just let the consumer add their validator set (we need another name for that -- governors, distributors, idk) and just use that. This would simplify a lot for the PoC.

[tbruyelle]

I would like to sync the validator set but avoid IBC if possible. I wonder if it's possible for the consensus engine to pass the validator set in the context.

This is not something new, for example the x/evidence module fetches the evidence from the context:

// BeginBlocker iterates through and handles any newly discovered evidence of
// misbehavior submitted by CometBFT. Currently, only equivocation is handled.
func (k Keeper) BeginBlocker(ctx context.Context) error {
	defer telemetry.ModuleMeasureSince(types.ModuleName, telemetry.Now(), telemetry.MetricKeyBeginBlocker) //nolint:staticcheck // TODO: switch to OpenTelemetry

	bi := k.cometInfo.GetCometBlockInfo(ctx)
	if bi == nil {
		// If we don't have block info, we don't have any evidence to process.  Block info may be nil during
		// genesis calls or in tests.
		return nil
	}

	evidences := bi.GetEvidence()

Currently the BlockInfo bi has the following structure:

// BlockInfo is the information comet provides apps in ABCI
type BlockInfo interface {
	GetEvidence() EvidenceList // Evidence misbehavior of the block
	// ValidatorsHash returns the hash of the validators
	// For Comet, it is the hash of the next validator set
	GetValidatorsHash() []byte
	GetProposerAddress() []byte // ProposerAddress returns the address of the block proposer
	GetLastCommit() CommitInfo  // DecidedLastCommit returns the last commit info
}

Note that it already contains the validatorHash, maybe we could also leverage on this (simple query the valset to the provider and ensure the data are correct by checking the hashes?).

[julienrbrt]

This needs to be figured out, as after #15, because we init a validator in the Makefile (https://github.com/atomone-hub/ics-poc-1/blob/5426e22/Makefile#L54-L55) but when comet calls init chain with the provider chain validator.

We need to share that validator set with the consumer app state, other we get: genesisValidators[0] != req.Validators[0]