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.
notaryNodeInfoFile: File path to the notaries’ node info file.
notaryX500Name: Notaries’ X500 name.
validating: A boolean value to determine whether the notary is a validating or non-validating one.
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: Parameters update specific configuration (optional).
description: Brief description for this parameters update instance.
updateDeadline: ISO-8601 time format indicating the deadline for this update. Example value: “2017-08-31T05:10:36.297Z”
whitelistContracts: Contract whitelist specific configuration (optional).
cordappsJars: List of file paths referencing CorDapp JAR files that will be automatically scanned for contract classes to be included in the whitelist.
exclude:
List of contract class names (for example, full package names) to be excluded from the whitelist.
- contracts:
List of explicitly specified whitelisted contracts. Each element of the list has the following attributes:
className: 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: The specified epoch for the set of network parameters (optional). If set, this should be greater than the previous epoch (if one exists) and always strictly positive (> 0). If not set, 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.