Skip to content

Conversation

mask-pp
Copy link
Contributor

@mask-pp mask-pp commented Sep 2, 2025

This PR aims to avoid being attached by illegal blob txs.

@lightclient
Copy link
Member

I think this also isn't that great because it causes us to validate the transaction twice. Once here, then again during add(..).

@mask-pp
Copy link
Contributor Author

mask-pp commented Sep 3, 2025

This also isn't that great because it causes us to validate the transaction twice. Once here, then again during add(..).

Yeah, It's that. If there is no check, the API can be easily attacked by sending illegal blob transactions.

@lightclient
Copy link
Member

@rjl493456442 how important do you think it is to convert sidecars in this codepath? It feels almost like it is better to not allow v0 sidecars after the fork. We can convert blobs that are sent to us via RPC and blobs already in our txpool, but maybe we just don't allow v0 to be propagated after the fork?

If it is important, we should probably merge this or something like it.

@lightclient lightclient self-assigned this Sep 4, 2025
@rjl493456442
Copy link
Member

@lightclient I agree, we should prevent the blob txs with legacy sidecar been included after the Osaka.

I think both you and @mask-pp are correct. The sidecar conversion is extremely expensive and can take several seconds for a single transaction. This opens an attack vector, allowing an attacker to easily drain a machine's resources by sending specially crafted blob transactions to the victim node.

@cskiraly
Copy link
Contributor

cskiraly commented Sep 8, 2025

If we do upgrade on RPC and in the txpool, that should be enough, I think. I don't see the case where we need v0 to still circulate in the network after the fork.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants