|
|
|---|
|
|
|
|---|
States of the system.
The committee of validators that run the protocol is dynamic: validators are bonded and unbonded via transactions; see transaction. There is a genesis committee, i.e. an initial set of validators, and then the committee may change, potentially at every block. Validators who unbond simply leave, while validators that bond after genesis need to sync with the rest of the validators, in order to have enough internal state to run the protocol.
This dynamic aspect of AleoBFT is complex. Note also that each validator has its own notion of the current committee, based on their own view of the blockchain. If the blockchains are in sufficient agreement, which is the purpose of the protocol, then there is also suitable agreement on the current committee. But, again, it should be clear that the details are delicate here.
To avoid modeling the syncing process of newly bonded validator, we make a modeling assumption that, while unrealistic if taken literally, it seems actually quite adequate as a way to model successful syncing. Our approach is to include, in the system state, all possible validators that may ever be part of any committee, including obviously the genesis committee; this may be a very large set, but that causes no issue in a formal model. All these validators keep their internal states up to date, by receiving and processing messages from other validators. But only validators in the current committee generate messages. A validator knows whether it is in the current committee or not, based on its current blockchain. A faulty validator may violate that, and attempt to author certificates without being in the committee, but those are not accepted by correct validators, if they come from validators not in the committees.
The above explanation is just a sketch, which alludes to several complexities. We will discuss how we model all of that when we define state transitions. For the time being, i.e. for the purpose of defining the possible states of the system, it suffices to say what has been said above.
At a high level, the adequacy of this modeling choice can be argued thus. If a new validator bonds and syncs, after successful syncing it will have enough state to participate in the protocol. This is somewhat equivalent to the validator having always been present, receiving and processing messages to update its internal state, instead of doing all of that (or a sufficient part of it) at syncing time.
Eventually, we will want to model syncing more explicitly. However, we believe that the current model is already a good one.
Besides the validators, we also model the state of the network that connects the validators, in terms of messages in transit, which have been sent but not received yet.
Along with a definition of the states of the system, we also introduce operations to handle system states in a slightly more abstract way: operations to retrieve validator addresses, operations to read and write validator states, and operations to read and write the network state.