Understanding Corda Networks

A Corda network is a collection of nodes with a vetted, unique identity that share a common “root of trust” upon which all certificates and signatures are ultimately chained back to. The tooling that enables this infrastructure is provided by the Enterprise Network Manager suite of tools, specifically the Identity Manager component.

As part of their boot-strapping process nodes submit their identity (public key and x500 name) to the Identity Manager of the network they wish to join. From there a number of things happen:

• The request is recorded in the global store of identities

• A new request is created via the workflow engine of choice to facilitate the verification of the submitters legal identity. The extent to which this is conducted is left to the discretion of the operator of the network but should be consistent with their existing policies on such things.

  Alternatively, the service can be configured to automatically accept signature requests. However, this is not the recommended deployment model outside of a testing setup.

• Once accepted the requests have a certificate signed by the PKI infrastructure that governs the network.Signing is performed by a separately deployed process called “The Signing Service”. It is important to realise how this service should be deployed (for more details on this see the Signing Service documentation), in brief, it is the intention that, unlike the Identity Manager, the signer is completely isolated from external communication. It only addresses a data source it shares with the Identity Manager. This ensure no hostile entity can penetrate the system and force the signing of a certificate. See signing-service

• The signed certificates are recognised by the Identity Manager and returned to the requesting node (Nodes poll the Identity Manager periodically to see if their signature request has been fulfilled).

At the end of this process a node will have successfully registered the legal identity of the entity it is operating on behalf of with the Zone. However, that node now needs to join one of the sub zones that make up the network as a whole.

Sub Zones

Where the zone as a whole is defined by the unique set of identities, a sub zone is a sub grouping of those entities that agree to a common set of parameters that define the global consensus mechanisms for all members. This functionality is offered by one or more Network Map services.

Sub Zones are currently categorised in relation to the mechanism a zone operator has in place for the process of setting the network parameters for it.

• Public Sub Zones where the entirety of the Network Parameters are under the sole control of the Zone Operator
• Segregated Sub Zones where one or more of the Network Parameters have been delegated to the authority of some third party.

Note, in either circumstance the operation of the Network Map in question is still under the perview by the Zone Operator, with a suitable out-of-band process established with the party to communicate the deferred parameter entity.

For more information, see sub-zones

Operating a Segregated Sub Zone

From the perspective of a mature CENM deployment, operating a sub zone post ENM 0.3 is the same as operating a single network under the old paradigm where there was only the one zone.

Each Network Map that represents a segregated sub zone is configured separately from the others as a distinct entity unaware of one another

Each Network Map requires:

• A configuration file
• A starting set of network parameters
• One or more notaries for inclusion in the whitelist
• A signing service configured to sign the network map and network parameters

More in this section

• What is a compatibility zone?
  • How do I become part of a compatibility zone?
    • Bootstrapping a compatibility zone
    • Joining an existing compatibility zone
    • Setting up a dynamic compatibility zone (in detail)
      • Do you need to create your own dynamic compatibility zone?
      • Why create your own zone?
      • How to create your own compatibility zone
        • Using an existing network map implementation
        • Creating your own network map implementation
          • Writing a network map server
          • Writing a doorman server
          • Setting zone parameters
        • Selecting parameter values
• Network certificates
  • Certificate hierarchy
  • Key pair and certificate formats
  • Certificate role extension
• The network map
  • HTTP network map protocol
    • Additional endpoints from R3
  • The additional-node-infos directory
  • Network parameters
  • Network parameters update process
    • Automatic Acceptance
    • Manual Acceptance
  • Private networks
  • Cleaning the network map cache
• Cipher suites supported by Corda
  • Certificate hierarchy
  • Supported cipher suites