In the EVM most numbers are represented as 256 bit integers. In most programming language, the default representation of numbers is smaller than 256 bits, which means you'll either overflow if your JSON library tries to cast as integers, or lose precision if your JSON library tries to cast as floating point objects. To help ensure that JSON libraries don't handle these numbers incorrectly, they are encoded as strings in the JSON instead of numbers.
But we could still do something like:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"currentBlock": "1464618",
"highestBlock": "4235238",
"knownStates": "7246963",
"pulledStates": "7229201",
"startingBlock": "0"
}
}
So why hex instead? Here I'm speculating a bit on the design decisions, but a couple of possible reasons:
- Hex is more concise for large numbers, though the leading "0x" makes that untrue for smaller numbers.
- It discourages people from doing things like calling parseInt(data["result"]["currentBlock"]), and forces them to consider how to properly convert from hex, which will hopefully land them at a tool that will convert to numeric representations that can deal with the required number of bits.