Skip to content
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

Closed
Erigara opened this issue Aug 8, 2024 · 4 comments · Fixed by #5079
Closed

bug: self dos of transactions gossip #4952

Erigara opened this issue Aug 8, 2024 · 4 comments · Fixed by #5079
Assignees
Labels
Bug Something isn't working

Comments

@Erigara
Copy link
Contributor

Erigara commented Aug 8, 2024

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.

@Erigara Erigara added the Bug Something isn't working label Aug 8, 2024
@Erigara Erigara self-assigned this Aug 8, 2024
@Erigara
Copy link
Contributor Author

Erigara commented Aug 8, 2024

Simplest solution is to just increase transaction_gossip_period_ms, but it still has a problem that the same transactions are sent over and over again.

@Erigara
Copy link
Contributor Author

Erigara commented Aug 8, 2024

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

@s8sato
Copy link
Contributor

s8sato commented Aug 21, 2024

Q: What if this peer is malicious?

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

@Erigara
Copy link
Contributor Author

Erigara commented Sep 9, 2024

I'm more concerned about if transactions are assumed to be forwarded in one shot to all of validators

Can you clarify your concern?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants