-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: self dos of transactions gossip #4952
Comments
Simplest solution is to just increase |
Transaction i've sent to iroha: transfer.json: {
"Transfer": {
"Asset": {
"Numeric": {
"source": "rose##ed0120CE7FA46C9DCE7EA4B125E2E36BDB63EA33073E7590AC92816AE1E861B7048B03@wonderland",
"object": "10",
"destination": "ed0120CE7FA46C9DCE7EA4B125E2E36BDB63EA33073E7590AC92816AE1E861B7048B03@wonderland"
}
}
}
} transaction.json: yes transfer.json | head -n 4096 | xargs cat | jq --slurp '.' > transaction.json cat transaction.json | /iroha --config client.toml json transaction |
I think this cannot be a drawback of the solution, even if the malicious peer is the only one who could gossip a certain transaction. It would be the same as before that a transaction might be dropped by a malicious entrypoint. I'm more concerned about if transactions are assumed to be forwarded in one shot to all of validators |
Can you clarify your concern? |
While working on #4265 i've noticed that in case of heavy transaction increasing commit time does not help.
Additionally time between leader creating the block and other nodes receiving it increased as view changes grow.
Turned out it was due to repeatedly rebroadcasted transaction gossip which overloaded communication channels between 2 peers.
This issue is similar to one discovered by @SamHSmith in #4909.
However i'm not sure that solution used in this PR would work here because sending hash of every tx with each gossip request is too much of data.
One possible solution is to only gossip transaction on it's arrival from the client.
Q: What if not delivered?
A: Than one who received it should put it in the block.
Q: What if this peer is malicious?
A: To be sure that your transaction not going to be censored you should submit it to at least f + 1 nodes.
But i going to do additional research in how to handle transaction gossip.
The text was updated successfully, but these errors were encountered: