Decentralization Manager proposal#298
Conversation
Signed-off-by: Gabi <103584312+gabitu7@users.noreply.github.com>
Signed-off-by: Gabi <103584312+gabitu7@users.noreply.github.com>
gabitu7
requested review from
hythloda,
isegall-da,
stas-sbi,
tkatrichenko and
waynecollier-da
Signed-off-by: Gabi <103584312+gabitu7@users.noreply.github.com>
Signed-off-by: Gabi <103584312+gabitu7@users.noreply.github.com>
Signed-off-by: Gabi <103584312+gabitu7@users.noreply.github.com>
|
|
||
| The Decentralization Manager implements a 1-coordinator-N-peers model for decentralized party creation. A coordinator node initiates party setup and invites peer nodes to join. The system automates an 8-step workflow: | ||
|
|
||
| 1. **WaitingForPeers** - Coordinator publishes invitation; peers accept or decline via UI |
There was a problem hiding this comment.
What long term role does Coordinator play or is this only the initiating peer in the long term quorum set?
There was a problem hiding this comment.
No special role - the coordinator is just the initiating peer. Anyone in the quorum set can be the initiator; once the party is set up, all peers operate as equals with no ongoing coordinator privileges.
|
|
||
| **Plugins** are DAML packages defining domain-specific governance actions. Each plugin registers action types with Governance Core and inherits the propose/confirm/execute workflow. The following Daml templates are in scope for this proposal as open-source reference implementations: | ||
|
|
||
| - **Token Management Daml template** - governed token issuance, minting, and burning operations, wrapping the utility and registry functions needed for third-party tokens |
There was a problem hiding this comment.
How does the differ from CIP-56 and CIP-97 standards?
There was a problem hiding this comment.
The token management plugin doesn't compete with CIP-56 - it complements it. CIP-56 standardizes the token APIs (metadata, holdings, transfers, allocations) that wallets and apps consume. The token management Daml template is a governance wrapper around the registry/utility functions (issuance, mint, burn) that any token registry needs to implement on its side. So you can use Decentralization Manager to launch a fully CIP-56-compliant token whose registry operations are governed by a decentralized party instead of a single operator.
CIP-97 isn't relevant here - it's a governance CIP about Nasdaq's Super Validator participation, not a token or registry standard unless I misunderstood your question.
There was a problem hiding this comment.
May have CIP number wrong but Token Standard V2 was the intent of the question.
There was a problem hiding this comment.
For CIP-112 (Token Standard V2), DecMan doesn't have support for it as it's not live yet but same answer as CIP-56 - no conflict. Token Standard V2 defines the token APIs; Decentralization Manager will let you (in the future) launch and govern a V2-compliant token through a decentralized party instead of a single operator. The two sit at different layers.
Signed-off-by: Gabi <103584312+gabitu7@users.noreply.github.com>
|
|
||
| The setup allows configuration of m-of-n thresholds (default: n/2), party ID prefixes, peer selection, and real-time progress monitoring. Threshold configuration is enforced at both the topology level and the governance level via `GovernanceSetThreshold` actions. | ||
|
|
||
| All off-chain coordination between coordinator and peer nodes - invitation distribution, key share exchange, and signature collection - runs over a peer-to-peer transport built on the [Noise Protocol Framework](https://noiseprotocol.org/noise.html#introduction), giving every leg of the workflow mutually-authenticated, end-to-end-encrypted channels between participating nodes. On-chain submissions (DNS and PartyToParticipant transactions) continue to flow through Canton's standard topology path; Noise is only used for the off-chain coordination that has to happen between nodes. |
There was a problem hiding this comment.
Why wouldn't you just implement the workflow you are describing above as a dApp using Daml contracts and signing topology transactions using the dApp API?
The main point of the DND bootstrapping is that you need a trusted channel between the initial owners to exchange the fingerprints of the public keys and the synchronizer id among the actors. This is literally what you get out of the box if you do this directly on ledger.
In that sense I don't know why you are proposing to use another P2P protocol for this. Sounds too complex and cumbersome without any true benefit.
There was a problem hiding this comment.
Thanks for the push - this is fair and you are right that bootstrapping maps cleanly onto existing Canton-native topology patterns, although as I understand would need to introduce extra complexity on the DAML side. Using an off-ledger channel makes this step faster and cheaper as far as I see. Also, this is how we bootstrapped CBTC, so this is the system we know and extended to this framework.
Nevertheless, this is where Phase 2 and beyond is heading: we would migrate away from any off-chain (or off-topology) orchestration for bootstrapping and node registration. Phase 1 uses our existing framework, which has been in production for quite some time, so is a tested and code-complete system.
Noise does carry some node-to-node operations that don't really need to be on-ledger (mostly for cost considerations), like DAR-distribution, liveness/heartbeat flows, etc. Arguably these could be handled through regular HTTPS/mTLS, but we find that noise is easy and well-suited for decentralized systems.
All in all, we agree and aim to phase out noise in a future release, seeing now a potential for simplifying the system. Let us know what you think.
6 participants
Development Fund Proposal Submission
Proposal file:
proposals/decentralization-manager.md
SIG: Decentralized Attestor Pools / DAO / Multisig
Champion: Gabija Tuinaite, BitSafe (@gabitu7)
Co-Champions: Tobias von Vignau (Digital Asset, @VinyoDA), Akshay Sinha (Alpend, @akshaysinha100)
Summary
This proposal seeks funding to implement, open-source and audit the Decentralization Manager - a generalized framework for creating and managing decentralized parties on the Canton Network. Today, teams that want to launch multi-party applications on Canton must hand-coordinate DNS and PartyToParticipant topology, write Daml governance contracts for threshold signing, and build proposal/confirmation UIs from scratch. The Decentralization Manager replaces all of that with automated topology orchestration, a plugin-based propose/confirm/execute governance engine with configurable m-of-n thresholds, an on-chain governance audit trail, and Token Management and Custody Daml templates that any team can extend. Once released under Apache 2.0 on the Canton Foundation GitHub, any builder - asset issuers, DeFi protocols, wallet providers, institutional custodians - can launch threshold-governed multi-party applications on Canton without reimplementing the underlying coordination, signing, or quorum-enforcement code.
Checklist
/proposals/