2

Playing around with geth jsonrpc.

Sending the eth_sycing.

{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}

What is the design decision to use Hexidecimal for numbers?

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "currentBlock": "0x16592a",
        "highestBlock": "0x409fe6",
        "knownStates": "0x6e9473",
        "pulledStates": "0x6e4f11",
        "startingBlock": "0x0"
    }
}
2

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.
  • Thanks. Make sense. The decision is already made. As for now, I'll just convert value to integer string because my api is for humans. – Yada Sep 19 '17 at 17:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.