<DRAFT> CIP-XXXX: Building a Name Resolution Service for Permissioned Blockchain Infrastructure - A Hybrid Tiered Approach by zhihezhang2 · Pull Request #230 · canton-foundation/cips

zhihezhang2 · 2026-06-11T05:17:33Z

Draft CIP on thoughts on building a hybrid and tiered name resolution service

Draft CIP on thoughts on building a hybrid and tiered name resolution service Signed-off-by: Zhi Zhang <zzhml2000@hotmail.com>

meiersi-da

Thanks for the input. Here are my comments from a first review.

meiersi-da · 2026-06-11T11:30:50Z

+
+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. 


May be answered later: why does it have to be super validators that serve this information?

I'd have expected an institutions own address book to have the highest trust level.

Yes. I don't want the CIP to read as mandating super validators.
The essential requirement for "Tier 1" is a highly trusted, highly available, accountable operator that prevents conflicts at registration, not super validators specifically.

Off the top of my head, here's some examples -

Bank/institution name --> settlement address.
If "J.P. Morgan" resolves to the wrong Party, a payment goes to an impostor.
There must be exactly one agreed answer before funds move.

Stablecoin / asset name --> issuer Party.
"USDC" must point to the real issuer.
A fake answer lets someone pass off counterfeit assets as genuine.

The canonical .canton namespace root.
Whoever controls "who owns acme.canton" controls a network-wide single source of truth. That registration authority itself must be maximally trusted.

Super-validator / core operator identities themselves.
The list of "which Party is actually an SV / Global Synchronizer operator". Spoofing this undermines trust in the network's own infrastructure.

I think of these types of mapping to be "axiom" of Canton ecosystem.
But conversely - whether if these need to be hosted by SV is truely debatable.
The amount mapping under this category is tiny.

meiersi-da · 2026-06-11T11:31:40Z

+
+# 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.


the label does not have to be meaningful

it's just an arbitrary label

meiersi-da · 2026-06-11T11:34:21Z

+
+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.


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.

meiersi-da · 2026-06-11T11:42:34Z

+
+### 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.


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.

Agreed. If we assume some mappings must be maintained by a highly trusted entity, SVs are not necessarily the only ones capable of it.

We could potentially see a world where some "highly trusted and neutral" name resolvers step in to fill that role instead. The intent is to specify the trust requirement, not to mandate SVs specifically.

That said, in today's world SVs are probably the closest thing we have to "highly trusted and neutral", which are already vetted, accountable, and as available as the global synchronizers themselves.

@zhihezhang2 I think it might make sense for the SVs to approve name registrars, and determine which name spaces those name registrars can use.

approve name registrars, and determine which name spaces those name registrars can use

I'd put this in the governance bucket (as opposed to operating the name service data or mappings themselves).

SVs don't need to manage the mapping data or run the resolvers, these can be delegated.
What belongs with SVs is the governance and a small set of key metadata of the name service: accrediting registrars, delegating which namespaces each may use, and holding the namespace root.

^ I'll get this updated and reflected in the proposal.

zhihezhang2 · 2026-06-11T11:49:18Z

+
+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.


Note - CNS needs to design for name resolution service to be also permissioned. Some translation may prefer not to be directly publicly revealed.

zhihezhang2 · 2026-06-11T11:52:37Z

+
+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


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.

zhihezhang2 · 2026-06-11T12:02:28Z

+
+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. 


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

Create cip-XXXX.md

992d8fc

Draft CIP on thoughts on building a hybrid and tiered name resolution service Signed-off-by: Zhi Zhang <zzhml2000@hotmail.com>

zhihezhang2 requested a review from a team as a code owner June 11, 2026 05:17

zhihezhang2 requested review from hythloda, isegall-da, stas-sbi, tkatrichenko and waynecollier-da June 11, 2026 05:17

zhihezhang2 changed the title ~~Create cip-XXXX.md~~ CIP-XXXX: Building a Name Resolution Service for Permissioned Blockchain Infrastructure - A Hybrid Tiered Approach Jun 11, 2026

zhihezhang2 changed the title ~~CIP-XXXX: Building a Name Resolution Service for Permissioned Blockchain Infrastructure - A Hybrid Tiered Approach~~ <DRAFT> CIP-XXXX: Building a Name Resolution Service for Permissioned Blockchain Infrastructure - A Hybrid Tiered Approach Jun 11, 2026

meiersi-da reviewed Jun 11, 2026

View reviewed changes

zhihezhang2 commented Jun 11, 2026

View reviewed changes


		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.


		# 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.


		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.


		### 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.


		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


		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.

Conversation

zhihezhang2 commented Jun 11, 2026

Uh oh!

meiersi-da left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zhihezhang2 Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zhihezhang2 Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

zhihezhang2 Jun 16, 2026 •

edited

Loading

zhihezhang2 Jun 11, 2026 •

edited

Loading