Corda Framework Overview + Examples
Last updated:- Objects
- States
- Transactions
- Contracts
- Commands
- Vaults
- Consensus
- Notary services
- Using external data via Oracles
- Differences w.r.t. other DLT technologies
Corda is a framework for writing distributed applications inspired by distribute ledger technology (DLT), leveraging characteristics such as immutability, privacy and per-to-peer communication, aimed mostly at large financial institutions.
These applications (called Cordapps) are distributed applications that run on Corda nodes, each one running the JVM-based Corda stack.
Objects
Objects are the entities in your ledger. Examples include accounts, financial instruments, etc.
States
A state is a snapshot of an object at a given point in time. States may be valid or marked as historical (i.e. not the current depiction of the object they reference).
Transactions
Transactions are proposals for changing the state of the ledger. Transactions define input states (these will get marked as historical upon completion) and output states (these will be the new current representation of an object).
The validity criteria for a transaction is defined by a contract.
Contracts
Contracts define input and output conditions that transactions must fulfill in order to be considered valid. Only valid transactions are commited to the ledger.
A contract must have no side-effects (i.e. it can only use and act on information on the ledger).
In terms of actual code, contracts are functions that throw an Exception if some condition is not met. They can be just assert* statements over the state of the ledger before and after a transaction has occurred.
Contract code may include constraints on the transaction (i.e. verify that a Command is present), states (i.e. verify that state properties match given criteria) and signers.
Commands
Commands are definitions of intent in contract code. They allow us to infer what the multiple assertions in a contract are meant to achieve.
Commands are also where one defines the peers that will take part in the transaction (i.e. who must sign the transaction before it's considered valid).
Vaults
Differently from other systems such as Bitcoin and Ethereum, Corda nodes only view a fraction of the total state of the ledger.
Each node has a vault where it keeps states that have been shared with it.
In other words, a node's vault is its subjective view of the whole network state.
Consensus
A transaction is commited to the ledger if:
Its input and output states don't violate contract code;
All peers (nodes) involved in the transaction have signed the transaction;
It's been verified as unique by a notary service.
Notary services
Notary services are special nodes used to prevent douple-spend attacks.
When a state is created on the ledger, it's assigned a notary node, which must be consulted whenever this state is used as input to a transaction.
It can also be used to verify that a given transaction happens within a given time window.
Using external data via Oracles
Off-ledger data (e.g. foreign exchange rates, a snapshot of asset prices for a given day) can be used in transaction if it's validated or provided by an oracle.
An oracle can be added as a peer in an transaction and then it must sign it as though it were a regular node.
Differences w.r.t. other DLT technologies
Difference 1) The full ledger state is not known to all peers in the network
Data is only sent on a need to know basis between peers;
Each node must ask for data they don't own so as to be able to verify transactions;
This is different from Bitcoin or Ethereum where all data is available to all nodes in the network.
Difference 2) Corda networks are permissioned
Only parties duly registered with the network may take part in transactions.
This restricts participation (as compared to permissionless networks like Bitcoin and Ethereum) but caters to the needs real-world financial institutions such as accountability, KYC, regulations, etc.