feat(api/clients/v2): relay registry caller #1175
Conversation
|
Do we need a standalone client to do this? We probably shouldn't have a standalone client for every contract call. |
| type RelayRegistryCaller interface { | ||
| // Reads the current sockets or key->url mapping | ||
| // from the on-chain registry | ||
| GetSockets() (map[corev2.RelayKey]string, error) |
There was a problem hiding this comment.
I don't think this should be called "GetSockets". I know that's the terminology used in the relay_client, but these are URLs, not sockets. Possible I'm wrong, but I've never heard a URL be called a "socket"
There was a problem hiding this comment.
They use Socket to mean URL:port combination. Not sure whether relays register a full socket address or just a URL where default 443 port or something is used though.
There was a problem hiding this comment.
I would call that an "endpoint". Socket really just seems like the wrong term
There was a problem hiding this comment.
There was a problem hiding this comment.
Socket != SocketAddress. Maybe you could argue this map contains socket addresses, but certainly not sockets
SocketAddress does indeed contain an address and a port, but it seems to me like the term is used internally on a machine, to reference the literal sockets that have been created locally.
There was a problem hiding this comment.
socket generally has a technical meaning in networking, and an IP_ADDRESS:PORT string isn't a socket (although it does tell you how to open a socket). I think we should be careful about how we use the term socket.
There was a problem hiding this comment.
I also didn't like the term originally, and did a bunch of googling lol. Seems like its an accepted term? https://en.wikipedia.org/wiki/Network_socket#Socket_addresses
I personally find endpoint to not be precise enough, but agree that socket by itself is super confusing and nor is it anymore precise.
There was a problem hiding this comment.
It's an accepted term, but I don't think in this context. From the linked article:
This combination is often known as a socket address. It is the network-facing access handle to the network socket.
It's used in a context specifically related to interactions with network sockets.
|
|
||
| func (rrc *relayRegistryCaller) GetSockets() (map[corev2.RelayKey]string, error) { | ||
| // read the # of relays by processing next key position | ||
| key, err := rrc.caller.NextRelayKey(nil) |
There was a problem hiding this comment.
nit: consider renaming key to keyCount, to make it more clear what it is
|
@ian-shim wasn't aware of this chain reader type. Would prefer to use that instead since it provides read interaction with other core contracts as well and builds a dependency mapping just from the |
Why are these changes needed?
Relay information must be ingested via EigenDA proxy. Either the user can provide this manually or just have the proxy query the on-chain
EigenDARelayRegistryduring initialization to bootstraprelayClientconfig state. Added aRelayRegistryCallertype which does the contract queries for constructing the registry state mapping.Checks