Proof generation / verification: allow cancellation
Description
Proof generation and verification should be able to be cancelled for multiple reasons:
- Publication epoch of ATXs for which a PoST proof is currently generating has ended. A late proof cannot be used anyway so generation should stop.
- Verification of proofs: incoming ATXs are processed in batches. Cancellation is needed among others to abort when shutting down a node.
Acceptance criteria
-
VerifyVRF,VerifyandProof(method of post service client in the node) can be passed a context that when cancelled aborts verification / generation of proof.- Signal to cancel is forwarded to Rust code via FFI for the verification functions
- Cancellation signal for proofing is used to communicate to the post service to stop generating a proof (likely by sending a stop command via grpc API)
-
Proof(method of post service client in the node) is passed a context with a timeout at the end of the cycle gap that is also cancelled when the node shuts down. -
VerifyandVerifyVRFis passed the "App-Context" that is canceled when the node is shut down.
Implementation hints
- For
VerifyVRFa passedcontext.Contextthat it is checked for before calling the oracle is sufficient. - For
Verifya passedcontext.Contextthat it checks before calling the underlying Rust code is sufficient as well -
Proofalready receives acontext.Contextthat only stops the node querying the proof from the post service but doesn't stop the post service from generating the proof.
Related issue in post-rs: https://github.com/spacemeshos/post-rs/issues/81
Cycle gap of PoET passed and the node hasn't finished generating a proof. A late proof cannot be used anyway so generation should stop when the window passes.
But one can still use and publish ATX so I'm not sure if that's the best idea, isn't it?
But one can still use and publish ATX so I'm not sure if that's the best idea, isn't it?
When we created this issue I was thinking of prioritizing PoET registration over ATX publication, since only one of the two can be accomplished without breaking protocol rules and being marked as malicious.
I updated the issue to instead cancel the PoST proof generation at the end of the publish epoch, since this better fits the current behavior of the node.
@fasmat The description needs to be updated as we now have the post-service