Network Parameters

Allowed parameters are:

  • minimumPlatformVersion: The minimum platform version that the nodes must be running on. Any node running a platform version below this will not start.

  • notaries:

Either the ordered list of file paths to the node info files, or the X.500 names, of the notaries which are permitted in the network. Note that once a network has started, the only supported changes to notaries are to add new notaries at the end of the list.

Notaries must be added to the end, as flows often use the ordering of notaries during selection (“pick the first” approach), and therefore changing the order could cause errors elsewhere. Also note that you can provide only the file path to the node info file or the X.500 name of the notary, not both.

For guidance on using notaries in flows, see the API Flows page.

  • minimumPlatformVersion: The minimum platform version that the nodes must be running. Any node, which is below this, will not start.

  • notaries: An ordered list of file paths to the node info files, or X500 names, of the notaries, which are permitted on the network.

    • validating: A boolean value to determine whether the notary is a validating (true) or a non-validating (false) one.

    • notaryNodeInfoFile: The file path to the node.info file of the notary.

    • notaryX500Name: The X500 name of the notary, as an alternative to providing the node info. Only supported for HA notaries.

  • maxMessageSize: Maximum allowed size in bytes of an individual message sent over the wire. Note that attachments are a special case and may be fragmented for streaming transfer, however, an individual transaction or flow message may not be larger than this value.

  • maxTransactionSize: Maximum allowed size in bytes of a transaction. This is the size of the transaction object and its attachments.

  • eventHorizonDays: Number of days after which nodes will be removed from the network map if they have not been seen during this period.

  • parametersUpdate: Specific parametersUpdate configuration (optional).

    • description: A brief description of this instance of parametersUpdate.

    • updateDeadline: ISO-8601 time format indicating the deadline for this update. Example value: ā€œ2017-08-31T05:10:36.297Zā€

  • whitelistContracts: Specific configuration for contracts whitelist (optional).

    • cordappsJars: The list of file paths referencing CorDapp JAR files that will be automatically scanned for contract classes to be included in the whitelist.

    • exclude: The list of contract class names (for instance, full package names) to be excluded from the whitelist.

  • contracts: The list of explicitly specified whitelisted contracts. Each element of the list has the following attributes:

    • className: The full package class name of the contract to be whitelisted.

    • attachmentIds: List of JAR file hashes (given as strings) containing the contract class.

  • packageOwnership: List of the network-wide Java packages that have been claimed by their owners along with the owners’ public keys. Optionally, the list should consist of entries with the following parameters:

    • packageName: The full package name in string format.

    • publicKeyPath: The file path to the public key. Note that this public key needs to be in a .pem file format.

    • algorithm: The algorithm used to generate the public key (for example, RSA or EC). This parameter is optional and defaults to RSA. Note: Corda (and by association CENM) do not support DSA keys.

  • epoch: (Optional) The specified epoch for the set of network parameters. If set this should be greater than the previous epoch (if exists) and always strictly positive (> 0). If not set then the previous epoch value will be automatically incremented. This parameter is mainly used for ensuring uniqueness across multiple segregated sub-zones. If only one network map is being run then it is best practice to omit this option.

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.