Corda — open source blockchain for business

Corda is a distributed ledger for storing, managing, and synchronizing financial obligations among various financial organizations.

Corda has quite good documentation with video lectures available here. I will briefly describe how Corda is structured internally.

Let's consider the main features of Corda and its uniqueness among other blockchains:

• Corda does not have its own cryptocurrency.
• Corda does not use the concept of mining and the Proof-of-Work system.
• Data transfer occurs only between participants of the transaction/contract. There is no global broadcasting to all network nodes.
• There is no central controller managing all transactions.
• Corda supports various consensus mechanisms.
• Consensus is achieved among participants at the level of individual agreements/contracts, not at the level of the entire system.
• A transaction is confirmed only by the participants relevant to it.
• Corda offers a direct connection between formal human legal language and smart contract code.

The ledger

The concept of a ledger in Corda is subjective. There is no single central data repository. Instead, each node maintains its own database of known facts.

For example, imagine a network of 5 nodes where the circle represents a fact known to the node.

As we can see, Ed, Carl, and Demi know about fact 3, whereas Alice and Bob are not even aware of it. Corda guarantees that common facts are preserved in the database of each node, ensuring that the data is identical.

States

A state is an immutable object representing a fact known to one or several nodes of the network at a specific moment in time.

States can store arbitrary data, such as stocks, bonds, loans, and identification information.

For example, the following state represents an IOU — an agreement that Alice owes Bob an amount X:

The lifecycle of a fact over time is represented by a sequence of states. When it is necessary to update the current state, we create a new one and mark the current one as historic.

Transactions

Transactions are proposals to update the ledger. They are not broadcasted to all ledger participants and are available only to those network participants who have a legitimate right to view and manage them.

A transaction will be added to the ledger if it:

• contractually valid
• signed by all necessary participants
• does not contain double spends

Corda uses the UTXO (unspent transaction output) model, in which each state of the ledger is immutable.

When creating a transaction, the output state of the previous transaction is passed in by hash and index.

Transaction lifecycle:

• Creation (At this point, the transaction is merely a proposal to update the ledger)
• Collecting signatures (Required participants of the transaction approve the update proposal by adding their signatures to the transaction)
• Committing the transaction to the ledger

After adding the transaction to the ledger, the input states are marked as historical and cannot be used in future transactions.

In addition to input and output states, a transaction can contain:

• Commands (transaction parameter indicating the transaction's target)
• Attachments (holiday calendar, currency converter)
• Time windows (expiry period)
• Notary (special network participants validating transactions)

Contracts

When we talk about the validity of a transaction, we refer not only to the presence of necessary signatures but also to the validity in relation to the contract. Each transaction is associated with a contract that accepts it and validates the input and output states. A transaction is considered valid only if all its states are valid.

Contracts in Corda are written in any JVM language (e.g., Java, Kotlin).

class CommercialPaper : Contract {
    override fun verify(tx: LedgerTransaction) {
        TODO()
    }
}

Must inherit from the class Contract and override the method verify. In case of an invalid transaction, an exception is thrown.

Transaction validation must be deterministic, i.e., a contract must either always accept or reject a transaction. Consequently, the validity of a transaction cannot depend on time, random numbers, node files, etc.

In Corda, contracts execute in a so-called sandbox—a slightly modified JVM that guarantees deterministic execution of contracts.

Threads

To automate communication between network nodes, flows have been added.

A flow is a sequence of steps that instructs a node on how to perform a specific ledger update, when to sign, and validate the transaction.

Sometimes it takes hours or days for a transaction to be signed by all parties and enter the ledger. What happens if a node involved in the transaction goes offline? Flows have checkpoints where the flow state is recorded in the node’s database. When the node is restored online, it continues from where it left off.

Consensus

To enter the ledger, a transaction must achieve two types of consensus: on validity and on uniqueness.

The decision on the validity of a transaction is made only by the parties directly involved in it.

Notary nodes check the transaction for uniqueness, preventing double spending.

Let’s imagine that Bob has $100, and he wants to send $80 to Charlie and $70 to Dan, using the same input state.

Such a trick will not work in Corda. Although the transaction will pass the validity check, the uniqueness check will fail.

Conclusion

Corda, developed by the R3 blockchain consortium, is not a pure example of blockchain technology. Corda is a sufficiently specialized tool for financial organizations.

Source: habr.com