Notaries

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:

• Network Member Roles
• Notary Plugin CorDapps

Network Member Roles

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:

• Application: Members which run 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. containing a CPB 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. which provides a CorDapp Corda Distributed Application. A Java (or any JVM targeting language) application built using the Corda build toolchain and CorDapp API to solve some problem that is best solved in a decentralized manner. to run on the network. Most members fulfil this role, and would be our archetypical “Alice” or “Bob” nodes.
• Notary: Members which run a CPI containing a CPB which provide a notarization service to the network. These are effectively representatives of a notary service, similar to how notary workers represented a notary service in a Corda 4 high-availability notary setup.
• MGM: The Membership Group Manager. In the context of notary functionality, there is nothing special or different about the MGM Membership Group Manager. May also be referred to as the Network Manager. It is a virtual node and Corda identity that acts as a central registrar for group membership. . The MGM virtual node is deployed as part of your standard network setup.

Notary Plugin CorDapps

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.1, only a single notary protocol is provided, the non-validating notary protocol.

Plugin Packaging

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.

Notary CPKs

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.

Notary Server CPB

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.

Application CPB

It is not possible to provide a standard application CPB, because the contents of this depend on how you write a CorDapp. You must decide which CPKs to 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 supports.

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 must add the following to your Gradle dependency configuration, where cordaNotaryPluginsVersion is the version of Corda deployed on your cluster:

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).

CPI Creation

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