Case study
Hyperledger Besu
A tiny malformed Ethereum transaction was making Besu respond with a server error. I traced it through the Java code, fixed the validation, and added tests for eight different bad inputs.
By Mishal ShanavasUpdated

- What was going on
- Besu is a Java Ethereum client. One odd input—an RLP payload containing no transaction bytes—was slipping through as if the server had broken, even though the client had simply sent bad data.
- What I did
- I followed the 0x80 payload down to TransactionDecoder, added the missing validation, and wrote parameterized tests for eight malformed inputs. The tests also make sure none of them ever reach the transaction pool.
- How it turned out
- The maintainers merged the fix after all 36 checks passed. It also cleared the RPC compatibility tests and went out in Besu 26.7.1. Tiny input, surprisingly long journey.
Technical details
- Traced an empty RLP transaction payload through the JSON-RPC and transaction-decoding path.
- Changed malformed client input from an internal server error to the correct Invalid params response.
- Added parameterized regression coverage for eight invalid payload shapes and verified the transaction pool stays untouched.
JavaEthereumJSON-RPCRLPJUnit