3283 certified block upon hare termination

[jonZlotnik]

Motivation

Closes #3283

Changes

Test Plan

TODO

• [ ] Explain motivation or link existing issue(s)
• [ ] Test changes and document test plan
• [ ] Update documentation as needed

DevOps Notes

• [x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources)
• [x] This PR does not affect public APIs
• [x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.)
• [x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)

[jonZlotnik]

thanks for sharing. tho there isn't enough for me to understand what you are trying to do. Will change implementation to use the database as "blackboard" to comply with patterns seen in the rest of the codebase.

mainly i'd like to understand

• what is the criteria for a node to be eligible to certify/sign the BlockID? To be eligible, you need to be chosen by the oracle. That's it. A vrf to prove role just like every other committee in hare.
• do we expect all nodes to receive gossip of terminationSignature and therefore can generate the certificate on its own if its online?

Yes. Any online node can "generate" the certificate. It's just a collection of signatures. A full certificate should only be sent over wire if directly requested from a peer (fetcher).

• is BlockCertifyingService going to be a long-running goroutine or instantiated per layer? what is its relationship with the main hare process?

From the perspective of the exported API, it should look like it does nothing but return the gossip handler. It handles the time-based logic, and vrf-signature calls to the roracle. It's role will be clearer once I push the implementation. It's meant to be injected into short-lived/ephemeral objects of the surrounding code.

• which entities are subscribing to wait for the BlockCertificate?

So I originally thought the syncer would want to do that. But as discussed last week, the syncer and fetcher use more of a blackboard pattern with the database. So the channel getter will probably not be exported in the end and I'll only use it for deciding when to commit to database.

• if you plan to also share the terminationSignature with the peers when they ask, how?

Single terminationSignatures should only be shared through gossip. Ideally, upon request, a group of signatures (even if not enough to certify a block) should be able to be fetched from a peer. That will probably be a "next step".

• how is the certificate persisted?

Once enough signatures are collected, they're persisted in the database as discussed.

[countvonzero]

implemented. see #3199