|
|
|---|
|
|
|
|---|
States of the system.
The committee of validators that run the protocol is dynamic: validators are bonded and unbonded via transactions; see transactions. There is a genesis committees, 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.
To avoid modeling the syncing process of newly bonded validators, we make a modeling assumption that, while unrealistic if taken literally, it seems actually quite adequate as a way to model successful syncing, at least at an abstract level. Our approach is to include, in the system state, all possible validators that may ever be part of any 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 discuss how we model all of that in the definition of state transitions.
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, at least as a first cut at handling dynamic committees.
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.