Skip to content

For the Docs: Differences between the functions of Validators and Super Validators on the Global Synchronizer #768

Open
@canton-network-da

Description

@canton-network-da

[ This issue was auto-migrated from DA's internal repo (DACH-NY/canton-network-node#12605). Original author: @waynecollier-da ]

Goal

The content below is valuable and putting it into our docs where we can just point to it seems valuable.

I (@meiersi-da ) suggest that the implementor checks whether we should just push it into an FAQ or whether it naturally fits in the glossary and the existing sectioning.

Original content by wayne (formatting lost due to Slack slacking 👿 )

What are some differences in the roles played by Validators and Super Validators on the Global Synchronizer?

Validators talk to all the Super Validators

A Validator node talks to one Super Validator at a time, but it maintains a list of all Super Validators (unless you specifically configure it to not do this, at your own risk), and can submit messages to any of them. The Validator also reads from f + 1 Super Validators (where f is the number of faults that the BFT quorum can work around and still give valid answers), to make sure that f Super Validators are not deceiving it.

Validators are the blockchain

A Validator is simpler than a Super Validator, but the Validators are the heart of the Canton blockchain. Super Validators are also Validators, as you correctly point out. All blockchain state is stored on Validator nodes, whether those nodes are operated alone, or as part of a Super Validator.

Validators mine Canton Coin

All Canton Coin is mined by Validator nodes, whether operated as a standalone Validator, or as pat of a Super Validator.
Canton Coin wallets are apps that communicate with the network via a Validator node that hosts them. The wallet app relies on the Validator node to construct transaction inputs, submit and sign transactions, and receive transactions via the synchronizer.

Super Validators create a decentralized synchronizer (the Global Synchronizer)

The synchronizer in Canton replaces the broadcast component of other blockchains. Instead of broadcasting all messages to all nodes, Canton distributes messages only to the nodes that host the parties to that transaction. The blockchain is formed by consensus on that transaction among just the parties involved in it.

The synchronizer is just the replacement for a public broadcast mechanism. Because Canton doesn't broadcast to all nodes, or rely on a longest-chain or statistical method to make sure "enough" nodes get the message, we add additional layers of controls and validation at the broadcast layer, to make sure all of the required nodes get the message.

The synchronizer acts as a transaction processing monitor, ensuring that all the appropriate nodes receive the message, and that they all validate it. If they don't all validate it, the synchronizer rolls the transaction back: an atomic, two-phase commit.

A decentralized synchronizer adds another layer to this, by requiring a BFT threshold of synchronizer nodes to agree on everything: message order, message distribution, validation confirmations, and rollbacks if necessary. The Global Synchronizer operates with a 3f + 1 BFT quorum, which means that the integer number equal to or just above 2/3 of the nodes must agree on any action, and you can trust a read if you get the same answer from one more than the tolerated number f of faulty nodes.

This means a decentralized Canton synchronizer uses blockchain consensus to make its two-phase atomic commit especially resilient and trustworthy.

Super Validators validate all Canton Coin transactions

Super Validators don't mint Canton Coin in any special sense: they just do it as part of being Validators, like any other Validators. The special role of Super Validators with respect to Canton Coin is that they see each Canton Coin transaction, validate its inputs and outputs, and publish it for everyone to see.

Canton Coin is a public app, which is why the Super Validators see every Canton Coin transaction. But Super Validators are not party to any other transactions, unless specified by the Daml models for the apps that generate them. So non-Canton Coin transactions remain private.

Super Validators host and distribute a limited set of additional applications to facilitate use of Canton Coin and use of the Global Synchronizer

Super Validators operate a name service application (the Canton Name Service) that allows users to associate a unique readable name to their Party ID, in exchange for a fee.
Super Validators operate Canton Coin scan, which reports the details of all Canton Coin transactions to anyone with access to the network
Super Validators operate their own wallet apps, and maintain and distribute the code that Validators use to operate a wallet app.
Super Validators govern the Global Synchronizer on the Canton Network

Super Validators run an additional app on their own Validators called the SV app. This app allows them to vote to modify the characteristics of Canton Coin, and the operations of the decentralized synchronizer. The Super Validators also vote to allow new Super Validators to join, and vote to remove Super Validators whose operations are harming the decentralized synchronizer.

Super Validator nodes should never host different applications than those offered by all the other Super Validators and governed by the SV app, because the Super Validators rely on each other for data permanence and disaster recovery, and make every effort to operate via common, coordinated processes.

And one last point for clarification: the Global Synchronizer is just one synchronizer on the Canton Network; most Canton synchronizers are private and work on subnets. Validators can use any number of different synchronizers depending on their application needs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions