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 — the only worker type that can load sensitive cryptographic material such as private keys.
• Database workers — 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 — 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 — maintain the mapping and context switching between flows and sessions.
• Verification workers — verify ledger transactions within the ledger sandbox.
• Membership workers — 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 — 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 — responsible for delivering messages between two virtual nodes in a secure and reliable way.
• REST workers — 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.