|
|
|---|
|
|
|
|---|
Transitions for certificate acceptance.
Here we define the system state transitions
caused by
As defined in system-states,
the network contains a set of messages,
each of which consists of a certificate and a recipient address;
these messages are added to the network via
A message may be accepted by any validator in the system, not only validators in the current committee. The rationale for this modeling approach is explained in create-next.
In order for the certificate to be accepted, all the previous certificates referenced by the certificate must be already in the DAG. This serves to preserve the backward closure of DAGs. Even though this condition may not be fulfilled at some point, it may be fulfilled in the future, after more certificates have been accepted by the validator; at that point, the certificate in question may be accepted. An AleoBFT implementation would normally actively request the missing predecessor certificates from other validators, but we keep our model simpler by not explicitly modeling that, but instead letting those certificates arrive non-deterministically, in line with our eventually reliable network model.
As also mentioned in create-endorser-possiblep,
nothing prevents a
If the certificate is accepted, and if the validator had endorsed the certificate, the author-round pair of the certificate is removed from the set of endorsed author-round pairs; see transitions-create about these pairs. This is because now the validator has the full certificate.
Certificate acceptance and certificate creation are the only events that involve the network component of the system state. All the other events involve just one validator. As explained in transitions-create, certificate creation involves multiple validators; in constract, certificate acceptance involves just one validator.