Add config to protocols in admin_nodeInfo api

[anhnhgutech]

Add config to protocols in admin_nodeInfo API

Related #7536

Changes

• Add config to admin_nodeInfo RPC API

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Screenshots

[LukaszRozmej]

This won't give you same response as https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-admin#admin-nodeinfo due to how geth handles genesis differently

[anhnhgutech]

This won't give you same response as https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-admin#admin-nodeinfo due to how geth handles genesis differently

Yes, but I think there should be a configuration in the protocol; it resembles the format of Geth, right?

[LukaszRozmej]

This won't give you same response as https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-admin#admin-nodeinfo due to how geth handles genesis differently

Yes, but I think there should be a configuration in the protocol; it resembles the format of Geth, right?

Well depends, what do you mean by that. We don't have hardfork blocks by design as we allow fine grained per-EIP configuration. Feel free to check the details and tell me what you think. One could build a translation layer from our format to Geth format here.

[anhnhgutech]

This won't give you same response as https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-admin#admin-nodeinfo due to how geth handles genesis differently

Yes, but I think there should be a configuration in the protocol; it resembles the format of Geth, right?

Well depends, what do you mean by that. We don't have hardfork blocks by design as we allow fine grained per-EIP configuration. Feel free to check the details and tell me what you think. One could build a translation layer from our format to Geth format here.

Yes, I know Nethermind and Geth have different config parameters. But what I mean is adding a config option to the RPC API to match Geth’s format. I think we should add this config in the RPC API while keeping the EIP parameters in the spec configs. If a user wants to use the format same as Geth, they can add a translation layer to their project.

[LukaszRozmej]

This won't give you same response as https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-admin#admin-nodeinfo due to how geth handles genesis differently

Yes, but I think there should be a configuration in the protocol; it resembles the format of Geth, right?

Well depends, what do you mean by that. We don't have hardfork blocks by design as we allow fine grained per-EIP configuration. Feel free to check the details and tell me what you think. One could build a translation layer from our format to Geth format here.

Yes, I know Nethermind and Geth have different config parameters. But what I mean is adding a config option to the RPC API to match Geth’s format. I think we should add this config in the RPC API while keeping the EIP parameters in the spec configs. If a user wants to use the format same as Geth, they can add a translation layer to their project.

Ok, can you show example response in full (attach json)?

[anhnhgutech]

This won't give you same response as https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-admin#admin-nodeinfo due to how geth handles genesis differently

Yes, but I think there should be a configuration in the protocol; it resembles the format of Geth, right?

Well depends, what do you mean by that. We don't have hardfork blocks by design as we allow fine grained per-EIP configuration. Feel free to check the details and tell me what you think. One could build a translation layer from our format to Geth format here.

Yes, I know Nethermind and Geth have different config parameters. But what I mean is adding a config option to the RPC API to match Geth’s format. I think we should add this config in the RPC API while keeping the EIP parameters in the spec configs. If a user wants to use the format same as Geth, they can add a translation layer to their project.

Ok, can you show example response in full (attach json)?

Example

{
    "jsonrpc": "2.0",
    "result": {
        "enode": "enode://271cfbc8a970e84890a456a8c5cc22ec0d318c9e61319cccab8d49607378b24c2b33152f2ea64ea2f9e1f26ffa5bc1da3580af18ae7a8e7cbecdce9824d3bcb1@10.5.0.3:30303",
        "id": "cb97d1b14ae1d0ddf963600e68c4c2048fb9a06afabf78c438c99c3d79b8792a",
        "ip": "10.5.0.3",
        "listenAddr": "10.5.0.3:30303",
        "name": "Nethermind/v1.30.0-unstable/linux-arm64/dotnet8.0.10",
        "ports": {
            "discovery": 30303,
            "listener": 30303
        },
        "protocols": {
            "eth": {
                "difficulty": "0x1",
                "genesis": "0x5be7cb7061b2c3f25d68bc7a9b0d12c8a93b58429f240243411e8c41574be4a1",
                "head": "0x5be7cb7061b2c3f25d68bc7a9b0d12c8a93b58429f240243411e8c41574be4a1",
                "network": "0x539",
                "config": {
                    "maxCodeSize": "0x6000",
                    "maxCodeSizeTransition": "0x0",
                    "gasLimitBoundDivisor": "0x400",
                    "maximumExtraDataSize": "0xffff",
                    "minGasLimit": "0x1388",
                    "eip150Transition": "0x0",
                    "eip152Transition": "0x0",
                    "eip160Transition": "0x0",
                    "eip161abcTransition": "0x0",
                    "eip161dTransition": "0x0",
                    "eip155Transition": "0x0",
                    "eip140Transition": "0x0",
                    "eip211Transition": "0x0",
                    "eip214Transition": "0x0",
                    "eip658Transition": "0x0",
                    "eip145Transition": "0x0",
                    "eip1014Transition": "0x0",
                    "eip1052Transition": "0x0",
                    "eip1108Transition": "0x0",
                    "eip1283Transition": "0x0",
                    "eip1283DisableTransition": "0x0",
                    "eip1344Transition": "0x0",
                    "eip1884Transition": "0x0",
                    "eip2028Transition": "0x0",
                    "eip2200Transition": "0x0",
                    "eip1559Transition": "0x0",
                    "eip2565Transition": "0x0",
                    "eip2929Transition": "0x0",
                    "eip2930Transition": "0x0",
                    "eip3198Transition": "0x0",
                    "eip3529Transition": "0x0",
                    "eip3541Transition": "0x0",
                    "eip3607Transition": "0x0",
                    "eip1559BaseFeeInitialValue": "0x3b9aca00",
                    "eip1559BaseFeeMaxChangeDenominator": "0x8",
                    "eip1559ElasticityMultiplier": "0x2",
                    "eip4788ContractAddress": "0x000f3df6d732807ef1319fb7b8bb8522d0beac02",
                    "depositContractAddress": "0x00000000219ab540356cbb839cbe05303d7705fa",
                    "eip7002ContractAddress": "0x00a3ca265ebcb825b45f985a16cefb49958ce017",
                    "eip7251ContractAddress": "0x00b42dbf2194e931e80326d950320f7d9dbeac02",
                    "eip2935ContractAddress": "0x0aae40965e6800cd9b1f4b05ff21581047e3f91e"
                }
            }
        }
    },
    "id": 1
}