snarkOS
snarkOS copied to clipboard
AleoNet
Feat/puzzle response
Motivation
Client or Prover should only process the latest PuzzleResponse.
Sync already ensures that the client/prover will only request a PuzzleRequest with a specific set of peers if it deems them to be further on the canonical chain. Additionally, we enforce that a PuzzleResponse message is only processed from a peer if the node sent a PuzzleRequest to that peer. So we only process responses which we asked for.
In the case that the network is partitioned or forked, this proposed change introduces risk that the provers will not target the rebased ledger (i.e. the new canonical chain).
Syncalready ensures that the client/prover will only request aPuzzleRequestwith a specific set of peers if it deems them to be further on the canonical chain. Additionally, we enforce that aPuzzleResponsemessage is only processed from a peer if the node sent aPuzzleRequestto that peer. So we only process responses which we asked for.In the case that the network is partitioned or forked, this proposed change introduces risk that the provers will not target the rebased ledger (i.e. the new canonical chain).
It seems reasonable when the network is stable. However, I push the Prover current_height metrics to exporter, it seems like sometimes the current_height decline sharply。
Prover/Client will not process BlockRequest and BlockResponse now, and never update itself's canon chain, If I'm not mistaken, It only update_peer_locators in processing Ping. Please check this logic, thanks.
@howardwu
I see your point here, let me think about it. While the drop in height isn't great, it is frankly the correct behavior.
We should be optimizing for higher quality peers, as opposed to artificially preserving (stale) block locators.
All right. Not as you say "drop in height isn't great", it's even worse now, more frequent, greater height. Scoring mechanism is needed. There's no reward for Provers to broadcast proofs to theirs connected peers, but just drop the proofs is benefit.