Workers

Corda 5 introduces a distributed architecture for the Corda runtime that is based on worker processes. There are different types of worker processors which each have their own operational responsibility and, because each worker is stateless, it is possible to scale horizontally.

Currently, Corda uses the following types of workers:

•  Crypto workers A worker that manages the cryptographic materials of the Corda cluster and virtual nodes. It connects to any Hardware Security Modules (HSM) used to hold private keys, as well as database(s) used as a software HSM to hold wrapped and encrypted private keys. — the only worker type that can load sensitive cryptographic material such as private keys.
•  Database workers A worker that connects to, manages, and operates upon the database(s) used by the Corda cluster. This includes the cluster-level database schemas needed to store configuration data for the cluster, but also the separate databases/schemas used by each virtual node. — responsible for database configuration and management.
• Persistence workers — responsible for flow and ledger persistence operations within the database sandbox.
• Uniqueness workers — provide fixed-function checking for spent input and reference states and time-window validation.
•  Flow workers A worker that runs the CorDapp application code and translates flow API calls into function requests to the relevant workers. The flow workers are designed to share work between themselves and to record checkpoints at each stage of the application's progress, so that in the event of worker failure, the operations can be retried. — execute the 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. code represented by flows Communication between participants in an application network is peer-to-peer using flows. .
•  Flow mapper workers A worker that maintains the mapping and context switching between flows and sessions. — maintain the mapping and context switching between flows and sessions.
•  Verification workers In combination with the platform ledger code, this worker ensures that the ledger operations of a flow operate atomically across peers. — verify ledger transactions within the ledger sandbox.
•  Membership workers A worker that manages the peer-to-peer routing information available to virtual nodes. The membership workers communicate periodically with the MGM to ensure they have up-to-date network information on peers. This MGM communication is secured via the Link Manager protocols. — provide all membership capabilities, such as joining an application network and discovering other members Corda identity that has been granted admission to a membership group. Synonym for a virtual node or group member. in the network.
•  Gateway workers A worker designed to communicate with external Corda clusters via HTTPS. They have restricted access only to specific topics on the Kafka bus and view only the minimum information needed for their role. — responsible for establishing TLS Transport Layer Security. A protocol that establishes an encrypted session between two computers on the Internet. connections with the gateways from other clusters and sending or receiving messages via HTTPS; this is typically internet facing.
•  P2P Link Manager workers A worker that manages the secure transmission of packets to peers. The main functional component is the Link Manager, which establishes end-to-end secure sessions for virtual nodes to communicate over. — responsible for delivering messages between two virtual nodes in a secure and reliable way.
•  REST workers A worker that exposes the intranet HTTPS REST control ports of the Corda cluster. The REST workers support all of the dynamic administration APIs of the cluster, such as APIs to configure the cluster, set up user role based permissions, or create and register virtual nodes. — expose the Corda REST API used for administration and flow execution.
• Token selection workers — selects the set of states to use as input states in a UTXO transaction.

Workers are typically referred to in the plural form because they are designed to be deployed with multiple replicas (for example, Kubernetes replica sets) to achieve high availability. Each worker instance is stateless, and work in the cluster is distributed to all available workers of a particular type. The number of replica workers needed is a function of the desired throughput and availability. Workers are made available as container images and R3 recommend deploying them to Kubernetes A powerful tool for managing containerized applications at scale, making it easier for teams to deploy and manage their applications with high reliability and efficiency. via a Helm chart.