Corda’s Blockchain-Inspired Design
During workshops and meetings, many solution architects have asked me to compare Corda to existing blockchain architectures (and specifically Ethereum) and describe how exactly corda is “blockchain-inspired” but not technically a blockchain. I think the naming wars of blockchain vs DLT is over and the industry is much more focused on solving business problems, but the architectural distinction and power of the Flow Framework is important to point out.
Architecture Overview

In my view, a standard blockchain architecture has 5 different layers (distinguished to make comparisons for Corda):
- Network: All blockchain nodes are connected via the gossip network and contain the same replication of data. A map of your seeds and peers are shared and propagated around the network.
- Node: All blockchain full nodes are not unique — their databases contain the same transactional (and account) data.
- Wallet: Any wallet software derived from the agreed upon private-public key generation mechanism can be used to create an “identity”. These identities are anonymous or masked by a centralized party like an exchange. Wallets are also used as software for generating transactions that interact with any node in the network.
- Application: All blockchains interact via the concept of a transaction protocol. In standard blockchains, the transactions are usually fairly simple instructions on how to update the database signed by the private key of the wallet’s private address. In Ethereum (and other dapp blockchains), the transactions can include data that publishes and calls smart contract accounts.
- Consensus: Globally, transactions are collected by mining pools and processed via the proof of work lottery mechanism for transaction ordering and block creation. All new blocks are broadcasted back to the network. This is effectively a polling mechanism based on a block time parameter shared by all parties. It is a linear single-threaded processing of transactions into blocks.

Following the same architecture layers, Corda, deployed as a permissioned network of decentralized Corda nodes, had requirements to maintain privacy. Architecturally, R3 had made the decision to combine the wallet and node concept together such that there is no global ledger, but a complex overlap of shared facts among known parties.
- Network: Permissioned network of known identities of nodes added via the Doorman service into a Network Map
- Node/Wallet: Corda nodes are unique and owned by companies (e.g. legal entity ownership). These can be either cloud-based or on-prem on any hardware that supports a JVM. Each corda node can run different corda versions that are API stable (Open Source V3.0 and above, Enterprise, etc). There is a one-to-one mapping of the corda identity to the corda node. This means most corda implementations start with the B2B corporate/wholesale focuses.
- Applications: Corda nodes can run multiple CorDapps (Corda Distributed Applications). Each CorDapp can be customizable on the API, States, Contract Code, and Flows for their use cases. Transactions for the application are customized to each use case and specifically allow for large transaction nesting (e.g. multiple Corda State transitions in one atomic transaction). Transactions are proposed by initiators running the CorDapp to other Corda nodes.
- Consensus: When a transaction is proposed, it is only sent to the parties that need to know (via point-to-point AMQP) and collects signatures for that transaction. Consensus is real-time and specifically limited to these parties and the Notary (of which the Corda State is registered to collect the final signature). The Notary Service provides the uniqueness, validation, and timestamping to prevent double spend. Note that there are no blocks and these are by default multi-threaded with a higher global network throughput. Processing is exclusive to transaction-specific parties.
Transactions & Flows

If we drill into the transaction signature collecting, it looks a lot like what happens within the wallet of Bitcoin. If we overlay this with the Flow Framework diagram, you can see that the transactions are built and signed within the wallet.

When writing this transaction in Corda, the difference is that the parties signing the transaction are known Corda nodes (Parties). Coding the flow lets you use reusable subflows and specify any error collection or triggers to other systems.
Application Deployment
The Ethereum model of publishing Dapps reuses the Ethereum account-to-account transaction for deployment. An Ethereum account can send transactions to 0x, which deploys the Smart Contracts/Dapps to all nodes in the network.
Since Corda’s privacy not only focuses on transaction/state data, but also the specific business logic installation, Corda has created the concept of a Business Network Operator (BNO). Its role is equivalent to the current software vendor with a set of SLA responsibilities for deploying and upgrading CorDapps (.jar file(s)) to the membership of the Business Network (subset of corda nodes that would like to run this CorDapp).
Standard tools for deployment of .jar files (e.g. TeamCity) can be used by the Business Network Operators for managing package dependencies, environments, and versions.
Corda and Individual Identity
Since the Corda node and wallet effectively ties the identities together, the standard Blockchain/Ethereum use cases within cryptocurrencies and in the B2C/C2C area are directly less relevant. Instead, the individual identities in the usage of Corda will likely still come from the LDAP, ActiveDirectory, PeopleSoft, or bank Internal ID integrations. This avoids a lot of the wallet KYC management conversations occurring in the public blockchain space.
While Corda does not support individual identity, R3 has completed POCs with Hyperledger Indy and Sovrin in coordination with the Evernym team. This model understands Corda may not be suited for globally replicated/shared data registries, but they’ve proven an ability to connect to them. The 2018 project between OP, Nordea, Asiakastieto Group, and Tieto in Finland shows some of the potential of linking the wallet services of Sovrin with the transport and private sharing mechanisms with Corda.
Summary
While Corda is not fit for every use case, it is seen as the “blockchain for business”. The team has made very specific architecture design choices for privacy and system integration purposes while balancing the security and performance needed within enterprise deployments.
Disclaimer: This view does not represent the view of my current or former employers.
