Skip to main content
Canton’s network architecture is fundamentally different from Ethereum. This page compares the architectures to help you understand the implications for your applications.

​
High-Level Architecture

​
Ethereum Architecture

Key characteristics:
  • All nodes store all state
  • Any node can answer any query
  • Consensus requires all validators
  • Horizontal scaling limited

​
Canton Architecture

Key characteristics:
  • Validators store only their parties’ data
  • Synchronizer coordinates without storing
  • Consensus involves only affected parties
  • A party can be hosted on multiple validators (multihosting)

​
Canton Components

​
Validators

Validators store only their parties’ data and answer queries only for hosted parties. In consensus, they validate only transactions affecting their parties.

​
Synchronizers

Synchronizers coordinate transaction ordering without storing state. They ensure all affected parties see consistent ordering.

​
Key Differences from Traditional Blockchains

In Canton:
  • There is no global state—each party has their own view
  • State visibility is private to stakeholders
  • Only hosting validators can answer queries for their parties
  • Finality is deterministic after confirmation

​
Data Flow Comparison

​
Ethereum Transaction Flow

​
Canton Transaction Flow

​
Query Architecture

​
Ethereum: Global Queries

// Any node can answer any query
const totalSupply = await token.totalSupply();
const aliceBalance = await token.balanceOf(aliceAddress);
const bobBalance = await token.balanceOf(bobAddress);
const allTransfers = await getTransferEvents();

​
Canton: Party-Scoped Queries

// Query only your party's data via your validator
const myContracts = await ledgerApi.getActiveContracts({
  party: myParty,
  templateId: "Token"
});

// Can't query other parties' balances
// Must be added as observer to see their data
Query TypeEthereumCanton
My balanceQuery any nodeQuery my validator
Other’s balanceQuery any nodeMust be observer
Total supplyQuery any nodeOnly if designed to expose
Transaction historyQuery any nodeOnly my transactions

​
Implications for Application Design

​
Data Availability

ConsiderationEthereumCanton
Read replicasAny nodeOnly your validator
CachingCache any dataCache only entitled data
AnalyticsOn-chain data publicNeed explicit data sharing

​
User Experience

AspectEthereumCanton
Wallet connectionAny RPC endpointYour validator’s API
Balance displayQuery public stateQuery your contracts
Transaction historyPublic block explorerPersonal transaction view

​
Scaling

Canton’s architecture naturally distributes load because validators only process transactions affecting their hosted parties. Additional capacity can be achieved by distributing parties across more validators.

​
Network Topology

​
Ethereum: Flat P2P

All nodes are peers, all store the same data.

​
Canton: Hierarchical

Synchronizer coordinates, validators serve parties.

​
Trust Model Comparison

EntityEthereum TrustCanton Trust
ValidatorsSee all, validate allSee only relevant, validate relevant
Network operatorsBlock producers see everythingSynchronizer sees nothing
Your nodeYou trust your nodeYou trust your validator
Other usersCompete for block spaceIndependent transactions

​
Migration Considerations

When migrating from Ethereum to Canton:
AspectAction Required
State queriesRedesign for party-scoped queries
AnalyticsBuild explicit data sharing if needed
Node infrastructureSet up validator, not full node
User onboardingConnect users to your validator
Third-party integrationsAccess Ledger API via gRPC or JSON API

​
Next Steps

Architecture Deep Dive

Detailed Canton architecture documentation.

Start Building

Begin writing Daml smart contracts.