Open elderhammer opened 6 months ago
Not sure if we are able to tell which solutions are "fake" without calculating their targets. As your POC shows we can just spam solutions with random counters. Hopefully the real puzzle will be shorter per run to make this relatively a non-issue.
Not sure if we are able to tell which solutions are "fake" without calculating their targets. As your POC shows we can just spam solutions with random counters. Hopefully the real puzzle will be shorter per run to make this relatively a non-issue.
Yes, constructing puzzles is easy, but verifying them is time-consuming.
was thinking about this one and forgot to comment. So apparently this is still a concern considering all nodes will try to validate all of the incoming unconfirmed solutions and we can't really do that fast enough. We probably need some mechanisms to block peers if too many invalid solutions are seen.
This is a known issue, but thank you for flagging this again.
Our current recommendations for mitigations is for Validators to run their own "Core Clients" which acts as the filtering mechanism for valid solutions/transactions that get sent to the validator.
Validators should not be arbitrarily exposed to external clients or REST request that may be malicious; the clients should be the ones interfacing externally and becoming the line of defense for the validators. With this approach, the validators should in theory be protected from these types of attacks.
Our current recommendations for mitigations is for Validators to run their own "Core Clients" which acts as the filtering mechanism for valid solutions/transactions that get sent to the validator.
The method you mentioned can filter attacks from P2P, but it seems that it cannot filter attacks from BFT, because the validator directly requests fake solution from the malicious verifier through TransmissionRequest.
The method you mentioned can filter attacks from P2P, but it seems that it cannot filter attacks from BFT, because the validator directly requests fake solution from the malicious verifier through TransmissionRequest.
Yes that's correct. Post-launch, the community should consider requiring a small Fee for solutions, and looking into batch verification to further reduce the attack vector.
Steps to Reproduce
Use this branch to run a malicious validator: https://github.com/elderhammer/snarkOS/tree/fake_solution_transmission
Part one:
Malicious validator continuously forge and broadcast fake solutions through Worker Ping, and honest validators continuously request fake solutions and add them to worker.ready.
Part two:
All honest validators will temporarily stuck in the execution of propose_batch, making it difficult to reach consensus.
Part three:
Impact: This type of attack will lead to two results:
Your Environment
snarkOS Version: 878624d6ccab6dfeb52f69ce54ee885464cdf7d8