Prysm: provide a RPC endpoint to identify a beacon node client uniquely

[tzapu]

maybe the public key, or peer id?

[mcdee]

Related to this, we should tidy up the node RPCs. There are lots of single-use calls that could be amalgamated in to a single NodeInfo() call. The 0.11 release would be a good time for such a tidy up.

[prestonvanloon]

Adding this to the testnet restart milestone for consideration.

[mcdee]

Taken a look through the current information provided, I suggest we go for two RPC calls NodeInfo and ChainInfo. Their contents would be:

• ChainInfo
  
  
  
  • genesis time
  
  
  • seconds per slot
  
  
  • slots per epoch
  
  
  • genesis fork version
  
  
  • genesis validators root
  
  
  • fork version schedule
  
  
  • minimum deposit amount
  
  
  • maximum effective balance
  
  
  • effective balance increment
  
  
  • ejection balance
  
  
  • BLS withdrawal prefix byte
  
  
  • current fork version
  
  
  • next fork version
  
  
  • next fork epoch
  
  
  • chain's current epoch
  
  
• NodeInfo
  
  
  
  • prysm software version
  
  
  • sync status
  
  
  • network addresses
  
  
  • peers
  
  
  • node current epoch
  
  
  • current justified epoch
  
  
  • last justified epoch
  
  
  • current finalized epoch
  
  

The difference between ChainInfo and NodeInfo is that ChainInfo is independent of the sync state of the node, whereas NodeInfo changes depending on the node's operation.

This would allow us to simplify the current API a fair bit, and give us somewhere to put additional information about node or chain as we users request it.

[tzapu]

sounds good to me but i can t figure which of those fields would allow you to id the node

[mcdee]

Sorry yeah that's currently wrapped up in the version field; I'll break it out as a separate item in the NodeInfo call.

[mcdee]

After working through some use cases and a test implementation, ChainInfo has expanded a bit. Sample (dummy) output is now:

Genesis time: 2020-04-01T16:05:42Z
Deposit contract address: 6d22ba5f4ef18c119f7b09192453f417b4a33b0e
Seconds per slot: 12
Slots per epoch: 32
Max seed lookahead: 4
Min validator withdrawability delay: 256
Persistent committee period: 2048
Min epochs to inactivity penalty: 4
ETH1 follow distance: 1024
Far future epoch: 18446744073709551615
Genesis fork version: 00000000
Genesis validators root: 83431ec7fcf92cfc44947fc0418e831c25e1d0806590231c439830db7ad54fda
Minimum deposit amount: 1000000000
Maximum effective balance: 32000000000
Effective balance increment: 1000000000
Ejection balance: 16000000000
BLS withdrawal prefix: 00
Previous fork version: 00000000
Current fork version: 00000000
Current fork epoch: 0
Next fork version: 00000000
Next fork epoch: 18446744073709551615
Current epoch: 0

These should cover the common cases where information needs to be obtained from the chain, or calculated from chain information; the full configuration can still be fetched with GetConfig for the more esoteric cases.

[terencechain]

For my curiosity, why would users need Far future epoch?

[mcdee]

Far future epoch shows up in various places in both this and other APIs (for example, next fork epoch if there is no next fork planned) so useful to have as a marker for comparison.

[mcdee]

Sample chain info:

Node ID: 16Uiu2HAmQodJ2Kxgx6Jun7Pg5dkeYTkeBMgzaibcrAa1NmfJXbyL
Version: Prysm/Git commit: c55c9640683c8897ddd329715a8596e2a8e8bb28. Built at: 2020-04-02T09:30:56+01:00
Sync state: Active
Addresses:
    /ip4/10.0.0.189/tcp/14002/p2p/16Uiu2HAmQodJ2Kxgx6Jun7Pg5dkeYTkeBMgzaibcrAa1NmfJXbyL
Peers:
    /ip4/172.31.44.179/tcp/13000/p2p/16Uiu2HAmBwcGqxnj1q4uZJ6eLy5pHjKMAH37uU4rtsQk2VBqaMsQ,/ip4/47.90.59.177/tcp/13000/p2p/16Uiu2HAmBwcGqxnj1q4uZJ6eLy5pHjKMAH37uU4rtsQk2VBqaMsQ
    /ip4/3.234.170.62/tcp/30000/p2p/QmfAgkmjiZNZhr2wFN9TwaRgHouMTBT6HELyzE5A3BT2wK/p2p-circuit/ip4/10.0.4.28/tcp/5000
    /ip4/172.33.0.2/tcp/13000/p2p/16Uiu2HAm9JpgzsGJKPEfytXUpQ7Vq6niRSEb8txM45TBMuL5BqZL,/ip4/212.254.248.158/tcp/13000/p2p/16Uiu2HAm9JpgzsGJKPEfytXUpQ7Vq6niRSEb8txM45TBMuL5BqZL
    /ip4/222.67.173.35/tcp/13000/p2p/16Uiu2HAmQ3LH8vquPjiWm2qSKX96oj1geNKZ65WnFTyukpFDhKGU,/ip4/192.168.31.44/tcp/13000/p2p/16Uiu2HAmQ3LH8vquPjiWm2qSKX96oj1geNKZ65WnFTyukpFDhKGU
    /ip4/172.31.44.177/tcp/13000/p2p/16Uiu2HAm25NXF6BrgJyQjKeknPxpzZoDnMb7paTnqMFADoKHZ9Bj,/ip4/47.56.184.255/tcp/13000/p2p/16Uiu2HAm25NXF6BrgJyQjKeknPxpzZoDnMb7paTnqMFADoKHZ9Bj
Current epoch: 13
Current slot: 416
Current block root: d41fac3620caa403b713b5cedc9bcd22bc01e10ca71487d385bdb2420199a095
Finalized epoch: 11
Finalized slot: 352
Finalized block root: 4663fd5e6647f3a8338750bf316aba1a2ee08a6b3734ced52e12310ec306122b
Justified epoch: 12
Justified slot: 384
Justified block root: 301cb1ec0a4795f6f362cff3a53d1f876da80558f0ff1f45c6d3f3059b5bf0f9
Previous justified epoch: 352
Previous justified slot: 352
Previous justified block root: 4663fd5e6647f3a8338750bf316aba1a2ee08a6b3734ced52e12310ec306122b

[rauljordan]

Closing as an API working group is now in progress. Once the API is accepted or deemed good enough, we can reopen this issue or create a new one with the proposed schema for this feature.