bug: self dos of transactions gossip #4952
Assignees
Labels
Bug
Something isn't working
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.jsoncat 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 |
This was referenced Aug 23, 2024
Can you clarify your concern? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: