Even though a validator can check all steps in the DKG, the DKG is a subjective outcome, anyway. Because 2/3 can manipulate however they want, full nodes don't need to check the correctness of the DKG; they can just trust the DKG is valid.
The complicated part is not Ferveo related, but it's a question about how much work nodes need to do to be in sync with the network.
DKG is expensive computation
In src
dkg
Params
tau: Session identifier
security_threshold: Match Tendermint 2/3 threshold
State machine
Mirror what the state is on the blockchain
Everyone should have the same state
Since Tendermint has its own state machine, it's not clear if there's anything else to keep in mind
msg
For testing purposes
Serialization and message signing
Not what we'll use (presumably)
It's better to sign transactions inside Tendermint
There are some messages that happen outside of the ledger?
For the DKG, not everything has to be conceptually on the ledger but it's simpler if it is, i.e. if every node has access to the same data
It'd be nice if all data generated by the DKG can be deleted, as it is useless (even for the verifier)
Distinguish between gossip message vs message in the ledger
pvdkg
Handles single session
The structure PubliclyVerifiableDKG will handle all the context for handling DKG messages
impl PubliclyVerifiableDKG For constructing a new context it is required
Identity (ed_key)
It is important to know which messages came from me
Maybe the API would have to account for
Possibility: we remove the signing process outside the Ferveo mode
params
Everyone needs to agree on how many shares
pvss_params
TODO: Could be generated internally and remove it from the API
share
Only 2/3 highest weight validators call the share function
This is on the boundary of Tendermint and Ferveo
It's a proactive message, not in response to a previous message
It's is a validator responsibility to create such message
There is a liveness question about how to do this
It'd be easy to sort all validators by weight and call share
This is not good enough: Not all validators are live
There must be a timeout
If times out, additional validators should be involved
Is there a cost of involving more than 2/3 validators from start?
Performance
This is the operation that generates the most data
If we want to allow everyone to share, we create 50% more data. It's overhead
Imposing a computing cost to verify
Conclusion: Everyone should call share!?
(Couldn't follow the reasoning)
aggregate
Once 2/3 threshold is reached, one of the validators need to call the aggregation function
It is not cheap, but not horribly expensive
It checks all messages and construct an aggregated shared message
The awkward bit is that the internal sharing messages don't get checked by anyone, they only get check when someone runs aggregate.
Once a block is finalized (reaches the 2/3 threshold)
find_by_key
Not an external (API) function
anounce
When validator announces they take part in the DKG
DKG should not have announce, it should be derived from Tendermint
Only use, getting the session key
Annoying because it required liveness on the part of the validator to post the session key. If not, there is no actual way to communicate the secret key shares to that validator. This is an awkward stage in the protocol.
We could have a weak liveness when someone has posted a previous session key
They can announce a refresh/update their session key, but it's optional
Then we don't have the risk of falling offline
Open questions:
What the important API calls should look like coming from ABCI++?
Part (I): Make sense of the code
dkgmsgpvdkgPubliclyVerifiableDKGwill handle all the context for handling DKG messagesimpl PubliclyVerifiableDKGFor constructing a new context it is requireded_key)paramspvss_paramssharesharefunctionshareshare!?aggregateaggregate.find_by_keyanounceOpen questions: