Corda Blockchain: Architecture, CorDapp Development, and Node Operations

What Corda Is and Where It Fits

Corda is an open-source, permissioned distributed ledger platform built for business networks where participants have known identities and strict data privacy requirements. Unlike public blockchains that replicate all state to every node, Corda shares transaction data only with the parties involved and their notaries. This design makes it suitable for regulated financial markets, trade finance, and interbank workflows where confidentiality is a legal requirement rather than a preference.

The platform is developed by R3 and has both an open-source distribution and a commercial Corda Enterprise edition. Corda networks are typically consortium-run: a set of identified nodes, a permissioning service, and one or more notary services. If you are comparing Corda with public-chain infrastructure, the operational questions differ: you are managing membership, certificate hierarchies, and private network connectivity rather than public RPC endpoints. For public-chain workloads, see the multi-chain RPC endpoints guide.

• Permissioned membership with real-world identities and X.509 certificates
• Point-to-point transaction privacy rather than global state replication
• Notary services for uniqueness consensus and double-spend prevention
• Smart contracts (CorDapps) written in Java or Kotlin on the JVM
• Designed for regulated assets, tokenization, and interbank workflows

Assumptions and Prerequisites

This guide assumes you have a working knowledge of JVM development, basic cryptography concepts such as digital signatures and certificate chains, and familiarity with relational databases. The examples use Corda 4.x conventions, which remain the most widely deployed line for enterprise CorDapps. Corda 5 introduces a different deployment and packaging model, so verify version-specific commands against the official documentation for your target release.

You will need a JDK (17 is used in recent Corda 4.x builds), Gradle, and access to a Corda node distribution or the Corda Enterprise artifacts. For local development, the Corda samples repository provides a template CorDapp with a Gradle wrapper. No public endpoint is required; Corda nodes communicate over AMQP/TLS on ports you configure.

The Corda Mental Model: States, Flows, and Notaries

Corda models shared facts as states, which are immutable data structures representing an agreement between parties. A state typically includes the participants, the data, and a contract constraint. State transitions are proposed by flows, which are multi-step programs that coordinate signing, verification, and finality across nodes. Flows are the unit of business logic and the place where you implement the sequence of collect-signature, verify, and record steps.

Notaries provide uniqueness consensus. When a flow consumes an input state, the notary checks that the state has not already been consumed and signs the transaction. Different notary implementations offer different tradeoffs: a single-node notary is simple but a single point of failure; a validating notary sees transaction contents; a non-validating notary sees only input state references. Choosing a notary model is an architectural decision that affects privacy and availability.

Contracts are deterministic verification code attached to states. They run on every node that receives the transaction and must not depend on wall-clock time, external services, or random values. This determinism requirement is a common source of bugs when developers port logic from conventional applications.

• State: immutable shared fact with participants and contract constraint
• Flow: multi-step coordination program that proposes state transitions
• Contract: deterministic verification attached to a state
• Notary: uniqueness consensus and double-spend prevention
• Transaction: signed proposal that consumes inputs and produces outputs

Setting Up a Local Corda Development Environment

The fastest way to understand Corda is to run the sample CorDapp locally. Clone the samples repository, then use the Gradle wrapper to build and deploy nodes. The commands below assume a Unix-like shell and a JDK 17 installation. Replace paths as needed for your environment.

The deployNodes task generates node directories under build/nodes, each with its own configuration, certificates, and database. Running runnodes starts all nodes and the notary in separate terminal windows or background processes. This local network is sufficient for developing and testing flows before moving to a shared test network or production consortium.

git clone https://github.com/corda/samples-java.git
cd samples-java/Basic/flow-library
./gradlew clean deployNodes
./build/nodes/runnodes

Writing and Testing a Minimal Flow

A flow that issues a state typically follows four steps: build the transaction, sign it locally, collect signatures from counterparties, and finalize it with the notary. The example below is a simplified Kotlin flow skeleton. It is illustrative rather than a complete CorDapp; production flows need error handling, progress tracking, and explicit counterparty resolution.

Test flows with the MockNetwork or TestNetwork harnesses provided by Corda. These let you spin up in-memory nodes, run flows, and assert on recorded states without deploying a full network. For integration testing, use a local deployNodes network and drive flows through the node's RPC client.

class IssueFlow(private val state: MyState) : FlowLogic<SignedTransaction>() {
    @Suspendable
    override fun call(): SignedTransaction {
        val notary = serviceHub.networkMapCache.notaryIdentities.first()
        val tx = TransactionBuilder(notary)
            .addOutputState(state, MyContract.ID)
            .addCommand(MyContract.Commands.Issue(), ourIdentity.owningKey)
        tx.verify(serviceHub)
        val signed = serviceHub.signInitialTransaction(tx)
        val sessions = state.participants
            .filter { it != ourIdentity }
            .map { initiateFlow(it) }
        val fullySigned = subFlow(CollectSignaturesFlow(signed, sessions))
        return subFlow(FinalityFlow(fullySigned, sessions))
    }
}

Deploying a Corda Node and Connecting to a Network

A Corda node is configured through node.conf, which specifies the node's legal name, database connection, P2P port, RPC port, and compatibility zone settings. In a permissioned network, the node must obtain a certificate from the network's doorman or identity manager before it can transact. The exact onboarding procedure depends on whether you run a Corda Network-compatible zone or a private Corda Enterprise network.

For production deployments, run the node as a systemd service or container, back the node's data directory with durable storage, and use a managed database rather than the embedded H2 database. The node's RPC interface should be bound to a private network and protected with credentials; never expose it to the public internet. If you are evaluating managed infrastructure for other chains alongside Corda, the blockchain node hosting guide covers general operational patterns.

myLegalName = "O=Example Corp, L=London, C=GB"
dataSourceProperties = {
    dataSourceClassName = "org.postgresql.ds.PGSimpleDataSource"
    dataSource.url = "jdbc:postgresql://DB_HOST:5432/corda"
    dataSource.user = "DB_USER"
    dataSource.password = "DB_PASSWORD"
}
p2pAddress = "0.0.0.0:10002"
rpcSettings = {
    address = "0.0.0.0:10003"
    adminAddress = "0.0.0.0:10004"
}

Diagnostic Procedure: Verifying Node Health and Flow Execution

When a flow stalls or a transaction fails, work from the outside in: confirm the node process is running, confirm the RPC connection works, then inspect flow progress and node logs. The following procedure uses the node's RPC interface through a small client script. Replace RPC_HOST, RPC_PORT, and credentials with your node's values.

First, check that the node is reachable and that the identity is registered. Then list in-progress flows and inspect the node log for exceptions. A common failure mode is a flow waiting indefinitely on a counterparty signature because the counterparty node is offline or the flow session was not established. Another is a notary rejection due to a double-spend or an unknown input state.

import net.corda.client.rpc.CordaRPCClient
import net.corda.core.utilities.NetworkHostAndPort

fun main() {
    val client = CordaRPCClient(NetworkHostAndPort("RPC_HOST", 10003))
    client.start("RPC_USER", "RPC_PASSWORD").use { connection ->
        val proxy = connection.proxy
        println("Node identity: " + proxy.nodeInfo().legalIdentities)
        println("Registered flows: " + proxy.registeredFlows())
        println("Network size: " + proxy.networkMapSnapshot().size)
    }
}

Expected Verification Results

After a successful local deployment, runnodes should start the notary and party nodes without certificate errors, and the RPC client should print the node's legal identity and a non-empty network map. A successful flow run should produce a signed transaction visible in the node's vault and a corresponding entry in the transaction storage. If you are testing a contract, a deliberately invalid transaction should be rejected at the verification step with a contract constraint violation.

Record your own baseline measurements rather than relying on published figures. A simple results table you can fill in after running the procedure:

• | Check | Command or observation | Expected result |
• | Node process | systemctl status corda or container status | Running, no restart loop |
• | RPC connectivity | RPC client nodeInfo() call | Returns legal identities |
• | Network map | networkMapSnapshot().size | Matches expected participant count |
• | Flow completion | Vault query for issued state | State present with correct participants |
• | Contract rejection | Submit invalid transaction | Verification exception, no state recorded |

Troubleshooting Common Corda Issues

Certificate and identity errors usually mean the node's certificate does not match the network's trust root or the legal name in node.conf differs from the certificate subject. Regenerate the node's certificates through the network operator's process rather than editing them manually.

Database connection failures often stem from missing drivers, incorrect JDBC URLs, or schema migration mismatches after an upgrade. Run the node's migration tool against a backup first, and verify the database user has the required privileges.

Flow timeouts and stuck sessions indicate a counterparty is unreachable or a flow is waiting on a response that will never arrive. Check P2P connectivity between nodes, confirm both nodes are on compatible Corda versions, and inspect the flow's progress tracker output. For broader reliability patterns, see the RPC reliability and consistency guidance.

• Certificate mismatch: verify legal name and trust root
• Database errors: check driver, URL, and migration state
• Stuck flows: confirm counterparty reachability and version compatibility
• Notary rejection: inspect input state consumption history
• Contract failure: review determinism and attachment constraints

Limitations and Tradeoffs

Corda's privacy model is a strength for regulated networks but a limitation for use cases that require public verifiability or permissionless participation. Because transaction data is shared only with involved parties, an external observer cannot independently audit the full ledger without access. This is intentional, but it means Corda is not a drop-in replacement for public-chain transparency.

Operationally, Corda networks require coordination: membership onboarding, certificate rotation, notary selection, and version upgrades across participants. These are governance tasks as much as technical ones. Throughput and latency depend on notary configuration, database performance, and network topology, so benchmark your own deployment rather than assuming published figures apply.

Corda 5 represents a significant architectural shift toward a packaged, container-native deployment model. Teams planning long-lived networks should account for migration planning and version support windows in their architecture decisions.

Next Steps and Related Infrastructure

Once your CorDapp runs locally, the next steps are to join a test network, harden node configuration, and establish monitoring for flow failures and database health. For teams operating multi-chain environments alongside Corda, OnFinality provides managed RPC infrastructure for public networks; review the supported networks and RPC pricing to plan capacity. Dedicated nodes are available through the dedicated node service for workloads that need isolated resources, and the API service covers managed access patterns. For endpoint selection on public chains, consult RPC Assistant rather than assuming a single provider fits every network.