Notary service overview

Corda Enterprise comes with two notary types:

• Single-node: a simple notary service that persists notarisation requests in the node’s database. It is easy to configure and can be used for testing, or networks that do not have strict availability requirements.
• Highly available: a clustered notary service operated by a single party, able to tolerate crash faults.

Corda Enterprise provides two notary highly available (HA) notary implementations:

• MySQL notary (deprecated)
• JPA notary

For a list of databases supported by the MySQL and JPA notaries, please refer to the Platform support matrix.

Single-node notary

To have a regular Corda node provide a notary service you simply need to set appropriate notary configuration values as specified in the node configuration file

For clients to be able to use the notary service, its notary.serviceLegalName must be added to the network parameters. If you are using the network bootstrapper the notary service name will be added to the network parameters automatically.

Notary high-availability mode

The high availability JPA and deprecated MySQL Corda notary services are made up of two components:

• The notary workers: A set of Corda nodes configured in HA notary mode. Each node has a separate legal identity, but shares a single notary identity. These nodes are configured to work together in high-availability mode
• The notary state database: A single logical database, itself configured to be highly-available, that all the notary workers connect to

We can visualise this set-up as follows, with the regular Corda nodes in green, the Corda notary worker nodes in red, and the standard node databases and notary state database replicas in blue.

Provided there are multiple notary workers and the notary state database is configured to be highly-available, the overall notary service will be highly-available. This is because the notary service can continue processing notarisation requests even if individual database replicas and/or notary workers fail. For example, a three-node notary cluster can tolerate one crash fault.

If desired, you can choose to run each database server and its Corda notary worker on the same machine:

Notary configuration

Nodes are configured as single-node notaries or notary workers via their node.conf files. For more information, please refer to node configuration file.

Legal names and identities

All notaries and notary workers require two legal names:

• A legal name, specified in the node configuration file as myLegalName. In a notary cluster, this property is unique to each worker node.
• The notary legal name, specified in the node configuration file as notary.serviceLegalname. This is the legal name and identifier of the notary service. In a notary cluster, it is common to all workers in a given notary cluster.

Only the notary.serviceLegalName and public key are included in the network parameters.

Keys and certificates

As described above, every notary worker is configured with both its own legal name and the shared service legal name. These names correspond to identities that have their own key pair and certificate, which should be accessible by the notary worker.

Both worker identity and notary service keys and certificates are stored in the same way as for regular Corda nodes. That is, if using local key stores, the worker identity, worker node CA and notary service key pairs and certificates are stored in files within the certificates directory. If an HSM is being used to generate and store the keys then only the certificate chains will be stored in the local files. You can find out more in the permissioning document.

Expected data volume

Non-validating notaries store roughly one kilobyte per transaction.