PeterYaoNYU
commented
1 week ago I was thinking that maybe we can have a util that handles all the verification stuff on behalf of the replica. Does that sound good?
Open dqian3 opened 2 weeks ago
PeterYaoNYU
commented
1 week ago I was thinking that maybe we can have a util that handles all the verification stuff on behalf of the replica. Does that sound good?
Currently, our protocol skips a number of verification steps. These are important to have for a complete version of our protocol, both because they are essential to showing our implementation is not trivially unsafe, but also because the work of verification in our protocol could have a significant impact on performance. Following are a list of items that need to be done, in approximate order of complexity:
[x] Certs: This is actually mostly done. However, the client and replicas have completely separate but mostly similar implementations (in
cert_collector.ccandreplica.cc) that could be refactored out into a separate utils file. This should take in parameters such asfand the signature provider. It would be good to also add tests that, for example edits the content of a request to see if it fails. Finally, the implementation isn't quite complete, and needs to factor in cases such as a malformed certificate with multiple replies from the same replica, or non matching replies[x] Checkpoint: Currently, our checkpoint protocol passes around certs in commit messages that are not verified. We would need to verify each one of these (or perhaps we only need to verify a single one and use that). There may be other stuff that I am overlooking here though.
[x] Fallback Trigger Proof: In the case of severe inconsistency, the client is able to start the fallback process by providing a proof showing that the normal path and fast path are not possible (i.e. a set of requests, such that the replicas that haven't responded would not be able to create a set of 2f + 1 consistent replies). Right now, the replicas don't do any verification on this, and enter directly into fallback.
[ ] Fallback Proposal: The "history" consisting of the logs of each replica needs to be verified before applying the fallback result, to prevent a leader from causing the slow path to be incorrect. This would consist of verifying each message from the 2f + 1 replicas, as well as the provided checkpoint. Note the underlying fallback protocol would take care of consistency. Ideally, we could have this be done in the middle of fallback as well.