`debug_accountRange` returns hash as Base64

[Wollac]

System information

Geth version: Geth/v1.15.6-unstable-2645b4e0-20250305/linux-amd64/go1.24.1

Expected behaviour

The debug_accountRange RPC should return the field next as a hex-encoded string with a leading 0x. This next field is used for pagination—enabling clients to page through the complete set of accounts—so its format should be consistent with the debug_accountRange parameter and other JSON outputs where hashes are represented in hex format.
Instead of returning a Base64 encoded string, it should output for example:

"next": "0x00240fda6f0ec1a470a223356528a0180ec8f13cd8ce0fc8cb17805cd8652a02"

Steps to reproduce the behaviour

Run the following command:

curl -X POST -H "Content-Type: application/json" \
  --data '{"method":"debug_accountRange","params":["latest","",1,true,true,true],"id":1,"jsonrpc":"2.0"}' \
  http://localhost:8545

This returns output similar to:

{
  "root": "61bdd509187f77a75cb67a9489009d510fe86a920269e5ca0876eadf0713ac48",
  "accounts": {
    "0xd038A0De6Fe7EE14Ad49625ee2E858693990FE0A": {
      "balance": "0",
      "nonce": 1,
      "root": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
      "codeHash": "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
      "address": "0xd038a0de6fe7ee14ad49625ee2e858693990fe0a",
      "key": "0x0007345d5c1d5a7b1d8260de1e94cfcb6e4ae88a21bdd12f070dd35c0361cb27"
    }
  },
  "next": "ACQP2m8OwaRwoiM1ZSigGA7I8TzYzg/IyxeAXNhlKgI="
}

[jwasinger]

I looked through github history and our internal chats to see what the reason for this was. From what I could gather, it seemed like this was just down to the original author's preference. Maybe @jsvisa remembers why?

This API has been around for five years. If we break backwards compatibility now, it will break things for (potentially a lot of) downstream users. I'd opt to just leave it as it is.

[jsvisa]

Hi @jwasinger thanks for ping me, I have no clue of the original design.

[jwasinger]

The benefits of making this change don't outweigh the cost of potentially breaking tools that depend on this API. I think we will just keep the method as-is (if someone from the Geth team disagrees, please reopen this with a rationale).