Tracking subnet membership from gateway or new membership actor

[adlrocha]

Background

For many processes, like the execution of top-down cross-net messages described in https://github.com/consensus-shipyard/ipc-agent/issues/72 it is useful to keep the current view of the membership of a subnet on-chain. The truth about the list of validators of a subnet lives in the state of the subnet actor in the parent, and this is what Mir uses to trigger its reconfigurations. However, when a reconfiguration is successful, it is useful to update an on-chain data structure that persists what is the current validator set so on-chain contracts can leverage this information for their operation. We can think of this as the power table in the Filecoin mainnet.

Proposal

My proposal is to create a new validator_set data structure and a new set_membership method in the gateway actor that tracks the current membership in the subnet. set_membership receives a validator_set as an input, and updates the membership stored. set_membership can only be called by the system actor, which means that it is executed implicitly. Every time the set of validators agree on a new membership, they propose a new message from the system actor that is executed implicitly and updates the validator set in the subnet. If a malicious validator tries to forge this message, it will only execute it locally and it will lead to corrupting their state and getting out of sync of the chain.

Implementation

We could implement the on-chain logic in two ways:

• As a new method is the gateway. This is the easiest to implement and it allows us to directly access this data structure from within the gateway without the need of external calls.
• As a new membership actor. Some subnets may choose not to use this membership functionality, and not track membership for the subnet at all. To allow for a cleaner integration and avoid confusions this may be a cleaner approach.

That being said, for M1 we will target the first approach.

[adlrocha]

Implemented here: #70