Possible Application 1 to Counting SNARK: Reducing the amount of computation required by a leader as part of committee-based round-by-round consensus (as in e.g., HotStuff)
This https://arxiv.org/pdf/2302.00418.pdf was brought to my attention.
I believe that one can replace the part of the computation that a round leader needs to do regarding verifying incoming individual BLS signatures and also aggregating BLS signatures with a computation done by a third party with the output being our SNARK proof + commitment to public keys + apk +threshold. The third party would be submitting some stake on-chain and it would be slashed if it does not output on-chain a correct SNARK proof +etc; and it would be rewarded for a correct and timely proof. Of course, the message that is signed by the (honest) participants actually sign something would contain also the next validator set = next set of participants in the consensus.
Possible Application 1 to Counting SNARK: Reducing the amount of computation required by a leader as part of committee-based round-by-round consensus (as in e.g., HotStuff)
This https://arxiv.org/pdf/2302.00418.pdf was brought to my attention.
I believe that one can replace the part of the computation that a round leader needs to do regarding verifying incoming individual BLS signatures and also aggregating BLS signatures with a computation done by a third party with the output being our SNARK proof + commitment to public keys + apk +threshold. The third party would be submitting some stake on-chain and it would be slashed if it does not output on-chain a correct SNARK proof +etc; and it would be rewarded for a correct and timely proof. Of course, the message that is signed by the (honest) participants actually sign something would contain also the next validator set = next set of participants in the consensus.