Notaries heading-link-icon

This section outlines how to configure a notary for a Corda application network The set of all possible entities onboarded according to the rules of the network. Application networks enable people and businesses to interact with each other on Corda. . It contains the following:

With the introduction of the UTXO Unspent Transaction Output. The unspent output of a cryptocurrency transaction, representing the amount of digital currency that has not been spent and is available for use in future transactions. ledger and notaries, Network Operators must be aware of the different roles that exist on a network. Network participants can take one of three roles:

Notary functionality is provided in the form of plugin CorDapps. In theory, anyone can write a new notary protocol by implementing their own CorDapps. However, initially, it is expected to only have protocols provided by R3. For a given notary protocol, two CPBs Corda Package Bundle. A signed ZIP/JAR collection of CPKs that forms a complete application suite and contains all the code that a virtual node must operate, minus the specific network details. are expected to be required:

  • A client, or application CPB, which is used to generate a CPI Corda Package Installer. A signed ZIP/JAR combination of a CPB and a Group Policy File that defines not only the application code that a virtual node will run, but also the details of the MGM with which to register, and the details of network PKI requirements. associated with application virtual nodes. At a minimum, this contains a CPK Corda Package. A signed ZIP/JAR library of Java code packaged to be portable with all of its dependencies and version information contained within it. that has an initiating flow Communication between participants in an application network is peer-to-peer using flows. that is automatically invoked by the Corda 5 flow framework to initiate a notarization request.
  • A notary server CPB (Corda Package Bundle), which is used to generate a CPI associated with notary virtual nodes. At a minimum, this contains a CPK that has a responder flow to what is packaged in the client CPB.

For Corda 5.0, only a single notary protocol is provided, the non-validating notary protocol.

The following sections describe the details of the architecture shown in the diagram below and the steps you need to take to successfully build your CorDapp. For information on how to deploy a functioning network, see the Onboarding Notaries section.

Corda 5 non-validating notary
The CPKs, CPBs, and CPIs involved in getting a functioning network that can run a notary (and by extension, UTXO ledger functionality)

There are four modules/CPKs of relevance to the non-validating notary protocol, which are then packaged into two different CPBs. These are:

  • notary-common — contains useful library functionality that is not specific to a particular notary protocol. For example, it defines the structure of an error that may be returned by a notary protocol. This is an example of something that must be standard cross-protocol, because the UTXO ledger depends on this format to perform processing, and the ledger has no visibility of the specific notary protocol that performs notarisation.
  • non-validating-notary-api — contains the payload definition that is used to communicate between the non-validating notary client and server CPKs. Extreme caution must be taken when making changes to this module, as backwards compatibility concerns must be taken into account.
  • non-validating-notary-client — intended to run on application virtual nodes, and provides a sub-flow that initiates a notarization request to a notary virtual node The combination of the context of a user and the ephemeral compute instances created to progress a transaction on that identity's behalf. when requested by the ledger finality flow.
  • non-validating-notary-server — provides a responder flow to the corresponding initiator flow in the client package, and will perform notarization processing.

The source code for all of these modules can be found under the notary-plugins area of corda-runtime-os.

R3 produces a standard non-validating notary server CPB. This only contains CPKs that are produced by R3 and therefore does not require you to build your own CPB using a mixture of R3 and third-party CPKs.

It is not possible to provide a standard application CPB, because the contents of this depend on the how you write a CorDapp. You must decide which CPKs you will bundle together to provide your application CPB. This is comprised of one or more CPKs which provide the application functionality. However, you must also bundle the appropriate CPKs for the notary protocols your CorDapp will support.

The decision on which protocols to support is trivial at present, given there is only a single notary protocol to choose; the decision is purely based on whether the CorDapp is using the UTXO ledger model or not. If it is, then you must bundle the notary-common, non-validating-notary-api and non-validating-notary-client CPKs when creating your CPB. Otherwise, there is no requirement to bundle any additional CPKs (as the notary is not involved in flow only or consensual ledger based CorDapps).

The easiest way to ensure your CorDapp includes the necessary CPKs is to use the CorDapp dependency functionality of the CPK Gradle plugin. You need to add the following to your Gradle dependency configuration, where cordaNotaryPluginsVersion is an appropriate version of corda-runtime-os, as the notary plugin currently lives as part of this repository.

cordapp "com.r3.corda.notary.plugin.nonvalidating:notary-plugin-non-validating-client:$cordaNotaryPluginsVersion"

Alternatively, you can form your application CPB using the Corda CLI. However, if you choose to use this, you need to explicitly specify all three of the required CPKs (notary-common, non-validating-notary-api and non-validating-notary-client).

Having two CPBs for the application and notary virtual node roles on the network also extends to needing two different CPIs. This process is unchanged, but ensure the following:

  • the notary server CPB signing key is used to create the CPI and then imported to Corda
  • the same group policy A JSON file containing network information that is bundled with a CPB to create a CPI. file is used when creating both the application and notary CPIs, for more information see the Onboarding Notaries section

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.