Remove "ethereum" references from API output

[NoahMaizels]

Task

Currently, the API still returns references to Ethereum, which continue to cause confusion for new users. For example:

curl -s localhost:1633/addresses | jq

{
  "overlay": "46275b02b644a81c8776e2459531be2b2f34a94d47947feb03bc1e209678176c",
  "underlay": [
    "/ip4/127.0.0.1/tcp/7072/p2p/16Uiu2HAmTbaZndBa43PdBHEekjQQEdHqcyPgPc3oQwLoB2hRf1jq",
    "/ip4/192.168.0.10/tcp/7072/p2p/16Uiu2HAmTbaZndBa43PdBHEekjQQEdHqcyPgPc3oQwLoB2hRf1jq",
    "/ip6/::1/tcp/7072/p2p/16Uiu2HAmTbaZndBa43PdBHEekjQQEdHqcyPgPc3oQwLoB2hRf1jq"
  ],
  "ethereum": "0x0b546f2817d0d889bd70e244c1227f331f2edf74",
  "public_key": "03660e8dbcf3fda791e8e2e50bce658a96d766e68eb6caa00ce2bb87c1937f02a5"
}

While it is true of course that the Gnosis Chain address format is the same as the Ethereum address format, these remaining references continue to cause confusion for new users, who may think they should be supplying an Ethereum RPC endpoint rather than a Gnosis Chain endpoint due to output like this.

I think there are a few alternatives to this. One is simply to use address (which is actually how it is already done in the swarm.key file), but this can be an issue since there are multiple types of addresses (overlay, underlay, etc.,), so it may also lead to confusion. Another is to use a key name like chain_address, which clearly indicates it is a blockchain address without specifying which chain, and finally there is the option of gnosis_chain_address. Personally I prefer the chain agnostic chain_address, especially considering the upcoming work being done on multi-chain support.

Acceptance criterea

Once all references to ethereum have been removed from the API output and replaced with alternative keynames (my preference being chain_address.

[gacevicljubisa]

All of these chains are Ethereum-based, so the reference is technically accurate. Changing it could break backward compatibility, requiring users to update their code. Additionally, the API can be clarified in the documentation.

If we decide to change, we could add the new field (chain_address) and keep the old one for compatibility, eventually deprecating it in the future.

Let me know your thoughts! @NoahMaizels @istae

[NoahMaizels]

All of these chains are Ethereum-based, so the reference is technically accurate. Changing it could break backward compatibility, requiring users to update their code. Additionally, the API can be clarified in the documentation.

If we decide to change, we could add the new field (chain_address) and keep the old one for compatibility, eventually deprecating it in the future.

Let me know your thoughts!

I do understand that the reference is technically correct, and I especially think it's fine to keep internally in the code base, but I'm not sure whether it is a good idea to refer to the addresses as ethereum addresses in output from the API which node operators / developers will be exposed to.

As for clarifying it in the documentation, I have attempted to do that, but since we can't assume the doc users will just read through the docs in order, and because the output from this endpoint is used on multiple different pages, it seems a bit of a waste need to add an extra explanation every time this reference comes up

I'm not sure what the standard approach is to this when it comes to EVM chains / Ethereum forks, but even if there is some convention to always refer to "ethereum" to refer to addresses in the API output, I still think it would be better to have a generic 'chain_address` field.

And yes like you mentioned there is the issue of backward compatibility and breaking things, but I think if we do like you said (add the new field, keep the old one functioning but officially deprecated for a while before removal), then I don't see it causing any big issues.

Anyway ultimately it is not a big critical issue, but it's a minor annoyance and I have seen it sometimes causing confusion for newcomers over the time I've been at Swarm.