<DRAFT> CIP-XXXX: Building a Name Resolution Service for Permissioned Blockchain Infrastructure - A Hybrid Tiered Approach#230
Conversation
Draft CIP on thoughts on building a hybrid and tiered name resolution service Signed-off-by: Zhi Zhang <zzhml2000@hotmail.com>
zhihezhang2
requested review from
hythloda,
isegall-da,
stas-sbi,
tkatrichenko and
waynecollier-da
zhihezhang2
changed the title
zhihezhang2
changed the title
meiersi-da
left a comment
meiersi-da
left a comment
There was a problem hiding this comment.
Thanks for the input. Here are my comments from a first review.
|
|
||
| Its central claim is that Canton should **not adopt a single resolution approach**. Instead, it should adopt a **hybrid, tiered architecture**, where metadata is classified into tiers by how mission-critical it is, and each tier is served by a resolution service whose trust level matches it. | ||
|
|
||
| Mission-critical mappings (e.g. bank name to settlement address) are served by a highly trusted Tier 1 service, likely operated by one or more well-trusted super validators. Less critical mappings are served by less trusted or individually hosted services owned by the data owners themselves. |
There was a problem hiding this comment.
May be answered later: why does it have to be super validators that serve this information?
There was a problem hiding this comment.
I'd have expected an institutions own address book to have the highest trust level.
|
|
||
| # The Problem Statement | ||
|
|
||
| Canton identifies parties by `Party` IDs, which are long and opaque strings that bind a meaningful label to a cryptographic namespace fingerprint. These identifiers are precise and secure, but not human-usable. No operations analyst will eyeball a fingerprint before authorizing a settlement, and no end user will type one into a payment screen. Every practical workflow therefore needs a layer that translates between what people recognize and what the ledger enforces. |
There was a problem hiding this comment.
the label does not have to be meaningful
There was a problem hiding this comment.
it's just an arbitrary label
|
|
||
| Most name services were designed for the open internet (DNS) or permissionless chains (ENS). Canton's environment differs in three ways that change the requirements: | ||
|
|
||
| - **It is permissioned.** Participants are onboarded, known, and accountable. A naming layer can lean on real-world legal identity and existing trust relationships rather than manufacturing trust from scratch. |
There was a problem hiding this comment.
participant nodes are not permissioned. the permissioning happens at the application level. see: https://www.canton.network/faq
Is Canton Network a public network?
Canton Network is a public network. Anyone can request a validator node (currently sponsorship is needed) and then participate in consensus related to transactions they are a party to. Anyone can take part in governance via the Foundation. Permissioning for any given application is defined on an application by application basis - as permissioned, or permissionless as the app provider wants.Similarly, the internet operates as a public network, but not all websites are open or permissionless. For example, your bank’s customer portal is part of the internet but is permissioned. In the same way, Canton enables each application to define its own level of openness and privacy. This flexibility allows applications to range from fully permissionless to entirely private, all operating on an open network that allows applications to interoperate with each other.
|
|
||
| ### Mission-Critical Resolution Comes From Highly Trusted Sources | ||
|
|
||
| For Tier 1, a wrong answer is a misdirected, possibly irreversible financial event. These mappings must come from a very trusted source: a registry operated by a **well-trusted super validator** (or a small governed set of them), reusing the accountability and availability the network has already vetted. Registration is deliberate and verified against the recognized source of truth (e.g. SWIFT directory, GLEIF); a name is registered once, and conflicts are **prevented at registration**, never reconciled later. |
There was a problem hiding this comment.
Super Validators have a well-established role on the Canton Network: operate the Global Synchronzier and Canton Coin. It's not clear why they should also take a role in operating CNS.
|
|
||
| Most name services were designed for the open internet (DNS) or permissionless chains (ENS). Canton's environment differs in three ways that change the requirements: | ||
|
|
||
| - **It is permissioned.** Participants are onboarded, known, and accountable. A naming layer can lean on real-world legal identity and existing trust relationships rather than manufacturing trust from scratch. |
There was a problem hiding this comment.
Note - CNS needs to design for name resolution service to be also permissioned. Some translation may prefer not to be directly publicly revealed.
|
|
||
| This gradient is the seed of the paper's recommendation: not one name service, but a **tiered set of them**, each matched to the criticality of the metadata it serves. | ||
|
|
||
| ### Serving Needs of Existing Institutional Users |
There was a problem hiding this comment.
Note - Include some examples in this section to elaborate real life use cases.
There are both internal facing and external facing sources. Utilimately giving instiutions the flexbility, ultimately help to reduce fraction to onboard onto Canton ecosystem.
|
|
||
| This paper recommends how a **name resolution service**, one that maps human-readable metadata to machine-readable identifiers, such as Canton `Party` IDs should be designed for a permissioned network whose primary adopters are regulated financial institutions. | ||
|
|
||
| Its central claim is that Canton should **not adopt a single resolution approach**. Instead, it should adopt a **hybrid, tiered architecture**, where metadata is classified into tiers by how mission-critical it is, and each tier is served by a resolution service whose trust level matches it. |
There was a problem hiding this comment.
Willingness of super vlidators in hosting name service need to be discussed/challenged.
There may be a very small set of data that would be hosted by super validators.
This can be solved by having more tiers of metadata defined, beyond just 2 tiers
e.g.
Tier 1 - super validators
Tier 2 - ?
Tier 3 - individual banks or self hosted name service
2 participants
Draft CIP on thoughts on building a hybrid and tiered name resolution service