The Private Database Network
Think of Canton not as a blockchain, but as a network of private blockchains or databases that can synchronize.The Model
Key insight: Each party’s data stays in their validator. When Alice and Bob transact, only Alice and Bob’s validators participate. Charlie’s data is unaffected and Charlie doesn’t even know it happened.Why This Matters
- For queries: You can only query your own data
- For design: Think about what data goes where
- For privacy: Data stays with the parties who should have it
Contracts as Facts
Think of contracts not as code that executes, but as facts that exist.The Model
| Traditional View | Canton View |
|---|---|
| ”Contract has state X" | "Fact: Alice owns 100 tokens" |
| "Update state to Y" | "Archive old fact, create new fact" |
| "Contract at address Z" | "Fact identified by ID, may be archived” |
Example
Authorization as Structure
Think of authorization not as code you write, but as structure you declare.Traditional Authorization
Canton Authorization
Views as Windows
Think of transactions as having windows (views) that different parties look through.The Model
Imagine a transaction as a building with different windows: Each party looks through their window and sees only what they’re entitled to see. The building (transaction) is the same, but the views are different. Key insight: Privacy isn’t about hiding data—it’s about each party having their own view of shared reality.Parties as Stakeholders
Think of parties not as “accounts” but as stakeholders with specific roles.Roles
| Role | Meaning | Analogy |
|---|---|---|
| Signatory | Must authorize, always sees | Signer on a legal document |
| Observer | Can see, can’t act | CC’d on an email |
| Controller | Can execute specific action | Has the key to a specific door |
Example: Loan Agreement
The Synchronizer as a Post Office
Think of the synchronizer not as a blockchain, but as a post office.The Model
The post office:- Receives sealed letters (encrypted messages)
- Puts them in order
- Delivers them to recipients
- Never opens or reads them
Transactions as Proposals
Think of multi-party transactions as proposals that require acceptance.The Model
When Alice wants to create a contract that Bob must also sign: Key insight: Multi-party authorization requires explicit consent. You can’t force someone into a contract—they must accept.Putting It Together
When building on Canton, keep these models in mind:| Situation | Apply Model |
|---|---|
| Designing data storage | Private Database Network |
| Designing state changes | Contracts as Facts |
| Designing permissions | Authorization as Structure |
| Designing privacy | Views as Windows |
| Designing parties | Parties as Stakeholders |
| Understanding infrastructure | Synchronizer as Post Office |
| Designing workflows | Transactions as Proposals |
Common Misconceptions
| Misconception | Reality |
|---|---|
| ”Canton is just another blockchain” | It’s a fundamentally different architecture |
| ”I can query all contracts” | You can only query your party’s data |
| ”Smart contracts have addresses” | Contracts have IDs that change on archive/create |
| ”Validators see everything” | Validators see only their parties’ data |
| ”The synchronizer stores my data” | The synchronizer stores nothing |