Summary 09/07/21

[Acentelles]

• Part (I): Make sense of the code

  • What's the role of full nodes vs validators?
    • 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++?
  • Fears:
    • Compute load, latency, performance, etc.
      • It will drive iterations of the DKG