CIP-0155? | SRV Registry #1033
CIP-0155? | SRV Registry #1033
Conversation
There was a problem hiding this comment.
I like the idea and Hydra could support this. I think it's most useful to open protocols though where we would want to enumerate all registered services using such certificates (info on how to register and query that registry through the ledger would be interesting). Currently, Hydra is using statically configured topologies only and if I understand this mechanism correctly this does not make much of a difference when sharing connection info (sharing a domain name vs. sharing a hostname/ip). Definitely useful for full on overlay networks where we also want to register services for longer (mithril?)
rphair
added
the
Category: Network
There was a problem hiding this comment.
@coot I've titled this PR as a CIP because everything about it is following the CIP form... but if the Draft period suggests it is really a CPS then please feel free to change it.
In any case after you take it out of Draft mode we'll tag it Triage after a format double-check (there are currently some things missing) which will set it up for public discussion at the next CIP meeting.
|
It is a CIP, and I just wanted to gather initial feedback first - hence a draft. |
|
OK, a good way to get diverse feedback is to bring it up @ the CIP meeting (next one in 90 minutes) so I've marked it as |
rphair
added
the
State: Triage
There was a problem hiding this comment.
@coot from our reading at the meeting under the clock: aside from @Ryun1's format suggestions above which are universal for CIPs, we had to use our imagination to determine what this CIP was about... including the connection with SRV records that a few of us know from DNS experience in a different context.
So although you might have been hoping for technical feedback about the principle itself, the main feedback was that more background could be given about the terms used, and who would be using these methods, and for what.
- For instance: some SPOs who've used SRV records to configure their stake pool relays might look over this CIP without knowing whether it's applicable to them unless something is put in the Abstract to define the target audience and/or applications of the idea.
- If that's clear when this comes out of
Draftmode then it would help us tag other potential reviewers for more detailed technical feedback.
I'll take the Triage label off now & we'll reapply it as soon as out of draft & ready for review in your opinion. Personally I'd like to have a better technical understanding of your proposal but would prefer to try again when there's some more background info here.
rphair
removed
the
State: Triage
|
@coot I believe that we should make a clear distinction between the DMQ node and Mithril nodes:
It may be necessary to define multiple entries per service in the SRV Prefix Registry:
Additionally, regarding DMQ: would this imply that the DMQ node also needs access to the ledger state (which is not currently planned)? |
|
@rphair, thanks for your feedback. I'll update the CIP and clarify the target audience and how it can be useful for SPOs. |
|
@jpraynaud As I understood This registry is only helpful for DAPs that want to utilise the ledger peers. |
|
@jpraynaud what about:
|
|
@ch1bo, @rphair, @rphair, @jpraynaud I addressed your comments. @rphair I might need a bit more guidance what should be made clearer. It's hard for me to know what is unclear without more insight. Anyway, I added a few sentences on how the SRV Record Registry will be needed by SPOs and DAPP developers. |
rphair
added
the
State: Triage
There was a problem hiding this comment.
@coot as both an editor and an SPO I think what you have added in this push clarifies the purpose & process of the CIP well enough.
I've marked it Triage to put it on the agenda for the next meeting (https://hackmd.io/@cip-editors/112) which you would be welcome to attend if it suits you.
I think this is a sound document & proposal so plan to suggest at the meeting that it be given a candidate CIP number.
CIP-xxxx/README.md
Outdated
|
|
||
| This CIP defines the procedure for assigning Service Record (SRV) prefixes for Cardano applications (like `cardano-node`, `mithril`, etc.). | ||
|
|
||
| This CIP constructs means of sharing authoritative information between SPOs who deploy services and DAP developers who write them. |
There was a problem hiding this comment.
| This CIP constructs means of sharing authoritative information between SPOs who deploy services and DAP developers who write them. | |
| This means of sharing authoritative information between SPOs who deploy services and DAP developers who write them. |
this sentence is broken, what you want to say?
There was a problem hiding this comment.
SPOs need to know how to deploy, DAP devs decide how this needs to be done - the CIP adding entries to the SRV registry allows one group to agree & communicate with the other.
|
Thank you @rphair; I won't be able to attend it today, but I can join next week. |
CIP-xxxx/README.md
Outdated
|
|
||
| When a **cardano** node implementation reads an SRV record from a ledger, it must add the _cardano_ prefix from the table above before making a DNS lookup, e.g. it should do a DNS query for `_cardano._tcp.<srv-record-from-ledger>`. | ||
|
|
||
| This design allows DAPs to use SRV records registered in the ledger for different purposes, e.g. a **mithril** node can use them to learn about end-points of its network. |
There was a problem hiding this comment.
Does this mean that someone could use a stake pool registration certificate to ONLY register a mithril node? and not a Cardano node
There was a problem hiding this comment.
Yes, and also the other way around. One needs to do a query to know if the service is configured or not. I'd consider this an advantage, as it provides flexibility for both the SPO and the ecosystem. If each decentralised protocol needed its own field in the certificate, we'd need to change the ledger (hard fork) each time a new one is deployed, which seems an unnecessary complexity.
There was a problem hiding this comment.
@coot as expected this was welcomed as a CIP candidate at today's CIP meeting. Please update the CIP number in the text and rename the containing directory from CIP-xxxx to CIP-0155 🎉
We also are interested to see if the assignment of a CIP number can lead to involvement from the Hydra and SPO populations: somehow referring them here to give more feedback about how it would/will work in their respective operations.
Also we would like to please work with you more conventionally on this branch — rather than getting a "force push" every time you make changes — so that commits can be associated with ongoing review as we go forward. This is the approach that works best for collaborative editing & a universal recommendation for PRs in this repo. 🙏
rphair
added
State: Confirmed
|
@coot it seems like this proposal is progressing favourably in parallel, so please post here after the proposal text has stabilised enough to commit to the repository as |
|
|
||
| #### SRV Registry Rules | ||
|
|
||
| * Each DP can have at most one entry in the registry. |
There was a problem hiding this comment.
This this still relevant? In the example above, Mithril has two entries. Perhaps a bit of detail on what the definitions / intended use of service vs scope are would be helpful.
There was a problem hiding this comment.
Right, I'd be keen to remove scope, mithril just has two discoverable services. @jpraynaud are you fine with it?
There was a problem hiding this comment.
@coot, I guess that @Quantumplation asked for descriptions of the fields service and scope more than removing them.
However, we could remove the scope and create multiple services for Mithril that would lead to the same DNS entries if this makes more sense:
| service | SRV prefix | Status |
|---|---|---|
| cardano | _cardano._tcp |
Active |
| mithril.dmq | _.dmq._mithril._cardano._tcp |
Active |
| mithril.aggregator | _aggregator._mithril._cardano._tcp |
Active |
There was a problem hiding this comment.
I'd keep it simple and not introduce notions which we're not certain will be helpful in the future. Once a need arises, we'll find an appropriate solution.
|
|
||
| This design allows DPs to use SRV records registered in the ledger for different purposes, e.g. a **mithril** node can use them to learn about end-points of its network. | ||
|
|
||
| Each prefix SHOULD start with `_cardano._tcp` or `_cardano._udp`, to avoid clashes with services not related to `Cardano`. |
There was a problem hiding this comment.
I get the semantics of "start with" from context, but it's a bit unintuitive, as _cardano._tcp comes at the end. Would this be well understood well by someone more familiar with DNS than I am?
What should services that plan to be multi-chain use as a prefix? for example, if a decentralized bridge or multi-chain layer zero type protocol with Cardano support; Should they have their own prefix, and avoid this CIP process? or should they have different prefixes for different chains? etc.
There was a problem hiding this comment.
DNS entries are structured from the most particular to the most general, so mithril.cardano.tcp makes sense and we could imagine an entry for mithril.ergo.tcp for example.
There was a problem hiding this comment.
@Quantumplation for multi-chain services this process is focused only on cardano side of things, the other side ought to be managed by the other block-chain (unless it's also covered by the CIP process).
| ``` | ||
| (see [register-stake-pool]); and configure SRV record at `_cardano._tcp.example.com` to point to **Cardano** relays, `_mithril._tcp.example.com` to point to **Mithril** relays (see [srv], currently under development). | ||
|
|
||
| A **Cardano** node implementation when retrieving information from a registration certificate from the ledger will receive `example.com` and it must prepend the `_cardano._tcp` prefix to make an SRV query. |
There was a problem hiding this comment.
can you elaborate a bit this example, to show what the SRV query might return, and what the node might then do with it?
That's a little bit outside of scope for this CIP, as it's just repeating what DNS would do, but I think it would be helpful (and inspirational) to see the example carried through to its conclusion.
There was a problem hiding this comment.
There are good resources for that, e.g. https://www.cloudflare.com/en-gb/learning/dns/dns-records/dns-srv-record. I'll add a link.
|
|
||
| A **Cardano** node implementation when retrieving information from a registration certificate from the ledger will receive `example.com` and it must prepend the `_cardano._tcp` prefix to make an SRV query. | ||
|
|
||
| It may as well append `.` to indicate it is a top-level query, resulting in querying the `_cardano._tcp.example.com.` domain. |
There was a problem hiding this comment.
Can you elaborate on why someone "may as well" do this?
There was a problem hiding this comment.
We got this advice from @njd42, if I recall correctly, it will speed up a DNS query.
|
|
||
| ### Implementation Plan | ||
|
|
||
| Each **Cardano** node implementation or other tools which rely on SRV records stored in the ledger should comply with this proposal. |
There was a problem hiding this comment.
A little more detail here on "comply" would be helpful. What does it mean for Amaru, for example, to "comply" with this proposal?
There was a problem hiding this comment.
It means to interpret the entries stored in the ledger according to this CIP, e.g. one needs to pretend _cardano._tcp to multi host pool relay information stored in the ledger (how srv's were called by ledger, don't ask me why the name is so complex).
|
|
||
| In this CIP, we propose prefixes for both **Cardano** and **Mithril**; in the future, other services can be registered through a CIP process, thus starting a registry of prefixes used by the **Cardano** ecosystem. | ||
|
|
||
| SPOs who deploy services need to configure their system according to the registry, e.g. SPO's cardano relays node MUST be available at `_cardano._tcp.<SPO_DOMAIN_NAME>`, as other nodes on the system will be looking at this address. |
There was a problem hiding this comment.
It sounds like this sentence is describing the current state, correct? i.e. already the SRV records used by SPOs are expected to / required to begin with _cardano._tcp; and this proposal just changes that from a singular value to a "pre"fix, so it can be extended for other services?
Or is this intended to be a breaking change, where there was no enforcement on the SRV record format so far, and this invalidates those, requiring them to be more consistent?
There was a problem hiding this comment.
I understand this is the desired state. While it's possible today to register a stake pool with a SRV record, there's no particular requirement on the content of this record.
There was a problem hiding this comment.
If so, and there's not already a standard / requirement of using the _cardano._tcp prefix, then this represents a much more disruptive change for SPOs, and should be addressed in the implementation plan.
There was a problem hiding this comment.
It sounds like this sentence is describing the current state, correct? i
If one has an SRV record that uses a different semantics than what this CIP proposes, it will be broken. However, this doesn't affect cardano-node, as it's not being used. So from the cardano-node perspective: what used to be broken remains broken 😁.
|
|
||
| Thus they can be instrumental in `Cardano`, since relays are registered on the blockchain through the registration certificate. | ||
|
|
||
| By using SRV records in the registration certificate (which is supported by the `cardano-ledger`, but not by `cardano-node`), we wish to solve this problem not just for `Cardano` node implementation, but also for any DP that requires constructing its own network. |
There was a problem hiding this comment.
What does it mean that this is supported by the cardano-ledger but not the cardano-node? As in, there's a field in the SPO registration certificate for it, but the node doesn't actually use that to make SRV requests for peer discovery?
There was a problem hiding this comment.
As in, there's a field in the SPO registration certificate for it, but the node doesn't actually use that to make SRV requests for peer discovery?
Yes, you got it right :).
There was a problem hiding this comment.
Left some comments, mostly adding my 2 cts on top of @Quantumplation's very thorough review.
One suggestion I would do is to give some consideration to the question of DNS spoofing and more generally security concerns. This article exposes some of the threats DNS and SRV entries are subject to and their consequences.
To address this concern, we could add an optional requirement to provide a TXT record containing a signature of the (hash of the) SRV entry using the SPO's cold key. This way, a user could verify entries easily using the public key provided on-chain.
|
|
||
| Having access to the ledger (either directly or through tools like `cardano-cli`) will allow decentralised protocols developers to construct networks based on registered relays. | ||
|
|
||
| All involved parties (SPOs, DP developers, etc) need to agree on SRV prefixes used by various DPs and thus a public registry governed by a public CIP process is required to foster DPs that co-exist with the **Cardano** network, like **Mithril** (see [CIP#137]). |
There was a problem hiding this comment.
| All involved parties (SPOs, DP developers, etc) need to agree on SRV prefixes used by various DPs and thus a public registry governed by a public CIP process is required to foster DPs that co-exist with the **Cardano** network, like **Mithril** (see [CIP#137]). | |
| All involved parties (SPOs, protocol developers, etc) need to agree on SRV prefixes used by various protocols and thus a public registry governed by a public CIP process is required to foster protocols that co-exist with the **Cardano** network, like **Mithril** (see [CIP#137]). |
Also, why not use the blockchain itself to store that information?
There was a problem hiding this comment.
This gives greater flexibility to the SPOs and developers.
|
|
||
| In this CIP, we propose prefixes for both **Cardano** and **Mithril**; in the future, other services can be registered through a CIP process, thus starting a registry of prefixes used by the **Cardano** ecosystem. | ||
|
|
||
| SPOs who deploy services need to configure their system according to the registry, e.g. SPO's cardano relays node MUST be available at `_cardano._tcp.<SPO_DOMAIN_NAME>`, as other nodes on the system will be looking at this address. |
There was a problem hiding this comment.
I understand this is the desired state. While it's possible today to register a stake pool with a SRV record, there's no particular requirement on the content of this record.
|
|
||
| SPOs who deploy services need to configure their system according to the registry, e.g. SPO's cardano relays node MUST be available at `_cardano._tcp.<SPO_DOMAIN_NAME>`, as other nodes on the system will be looking at this address. | ||
|
|
||
| DP developers SHOULD submit proposals to the SRV Prefix Registry, so SPOs, who deploy them, can have an authoritative information how to do it. |
There was a problem hiding this comment.
| DP developers SHOULD submit proposals to the SRV Prefix Registry, so SPOs, who deploy them, can have an authoritative information how to do it. | |
| Protocol developers SHOULD submit proposals to the SRV Prefix Registry, so SPOs, who deploy them, can have an authoritative information how to do it. |
That's where having the "prefix registry" on-chain would be quite helpful. For example, one could imagine a modification to the registry to be a governance action subject to SPOs voting because that's their remit.
There was a problem hiding this comment.
Making such a link would be a mistake. Consider a syncing node: depending on the era it would see invalid SRV records depending at which stage of syncing it is. There is a fundamental difference between the stability of deployment configuration and the elasticity of blockchain-stored information.
There was a problem hiding this comment.
I don't understand your argument: No matter what, if a node is syncing then the information about its peers it can get from the ledger is not current, possibly outdated, etc, so it cannot be used anyhow even in its current form without SRV records.
The information about the (valid) prefixes to use is orthogonal to this problem.
There was a problem hiding this comment.
You're right that reconfiguration of relays does occur, but we don't see stake shifting much, which is even more important for a syncing node due to security reasons.
Note that once committed to a value, changing it would be impossible to do safely, as it would require reconfiguring DNS entries by all SPOs simultaneously.
There was a problem hiding this comment.
I still don't understand how this invalidates my proposal, sorry. It's about storing and retrieving some information for the chain which is assumed to be safe. The DNS will need to be verified anyway hence my other proposal to sign those entries.
There was a problem hiding this comment.
It will matter for nodes that are syncing recent history (which is the most common scenario for syncing). The value cannot change on-chain, as using a published genesis snapshot will result in invalid domains if SPO switches to the new value in the meantime, and Daedalus nodes won't be able to sync. If they cannot change on-chain, why add the complexity of storing it there in the first place?
|
|
||
| This design allows DPs to use SRV records registered in the ledger for different purposes, e.g. a **mithril** node can use them to learn about end-points of its network. | ||
|
|
||
| Each prefix SHOULD start with `_cardano._tcp` or `_cardano._udp`, to avoid clashes with services not related to `Cardano`. |
There was a problem hiding this comment.
DNS entries are structured from the most particular to the most general, so mithril.cardano.tcp makes sense and we could imagine an entry for mithril.ergo.tcp for example.
Summary
This CIP proposes SRV prefix registry to foster discoverability of DAPs which
have their own decentralised network running along-side cardano block-chain.
Link to rendered proposal