Available network parameters

This topic lists the currently-available network parameters, in alphabetical order:

The confidentialIdentityMinimumBackupInterval network parameter is an optional parameter of type Duration. It specifies the minimum age of a generated Confidential Identity key before it can be used. This can be overridden in the node configuration or if a more recent database backup is indicated via RPC/shell.

This parameter is optional in both the network parameters and the node configuration. If no value is specified for either, then it is assumed to be zero.

For example:

confidentialIdentityMinimumBackupInterval = 5d

or

confidentialIdentityMinimumBackupInterval = 30d

The version number of the network parameters. Starting from 1, this will always increment whenever any of the parameters change.

The time after which nodes are considered to be unresponsive and removed from the network map. Nodes republish their NodeInfo on a regular interval. The network map treats that as a heartbeat from the node.

The maximum allowed size in bytes of an individual message sent over the wire.

The maximum allowed size in bytes of a transaction. This is the size of the transaction object and its attachments.

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

The time when the network parameters were last modified by the compatibility zone operator.

The list of identity and validation types (either validating or non-validating) of the notaries which are permitted in the compatibility zone.

The recoveryMaximumBackupInterval network parameter is an optional parameter of type Duration, and is used by Ledger Recovery. It specifies how far back in time the recovery process should consider. When attempting a recovery, a node will only restore to a database backup more recent than this value.

This value can be overridden by specifying an override in the flow. It can also be overridden for a particular node if the same parameter is specified in the node configuration; the node configuration takes precedence over the network configuration. An override to the flow takes priority over values in either the network configuration or node configuration.

The parameter is optional in both the network parameters and the node configuration. However, if no values are set then it needs to be specified in the flow.

For example:

recoveryMaximumBackupInterval = 5d

or

recoveryMaximumBackupInterval = 30d

The list of the network-wide Java packages that were successfully claimed by their owners. Any CorDapp JAR that offers contracts and states in any of these packages must be signed by the owner. This ensures that when a node encounters an owned contract, it can uniquely identify it and knows that all other nodes can do the same. Encountering an owned contract in a JAR that is not signed by the rightful owner is most likely a sign of malicious behavior, and should be reported. The transaction verification logic will throw an exception when this happens. Read more about package ownership in the Package namespace ownership section.

The list of whitelisted versions of contract code. For each contract class there is a list of SHA-256 hashes of the approved CorDapp JAR versions containing that contract. For more information about zone constraints, see Contract Constraints.

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.