BLOG
BLOG
We believe in AI and every day we innovate to make it better than yesterday. We believe in helping others to benefit from the wonders of AI and also in extending a hand to guide them to step their journey to adapt with future.
This blog post tells you about what Blockchain is, and a brief introduction into one of the blockchain platforms — Corda.
Few months back, one of my colleague challenged us for a LinkedIn viral question “Explain Blockchain in 10 words.” Now that i have found it , i can swiftly find my way whenever i am shot with questions like “What exactly is Blockchain? Are you working on something illegal? You guys will go to jail (Yes, One of my church goer actually said this to me , Duh!)”. So here it is:
Blockchain is a distributed and decentralized digital ledger with immutable records which is consensus driven.
Lets take an example of a record and look into the following five key words to understand about what this technology is all about,
“Joe borrowed 5000 money from Sam.”
Distributed: The record (Joe borrowed 5000 money from Sam) will be distributed to everyone in the network. Everyone who shares the network will be able to view this record.
Decentralized: The record will not be stored in a central database, it will be available to everyone within the network. No single authority controls it.
Digital ledger: The Decentralized record will act as a digital ledger shared among the participants in the network.
Immutable: The record cannot be removed/deleted from the ledger. If any manipulation is made, it will be reflected and the nodes in the network can reject the manipulated record and not store the ledger with false records.
Consensus Driven: Majority of the nodes participating in the network should agree to the validation/existence of the record. If the validation fails, then the record will not be considered valid. Different blockchain platforms uses different consensus algorithms.
Now lets see how CORDA defines itself as a blockchain platform. We cannot say Corda follows all the above key features of a blockchain and it has its own reasons. Corda was developed to perform better for its particular use cases. To give you a brief introduction,
Reach out to us today, to discuss your project
In this article, we’ll cover the following key concepts of Corda :
Corda uses a point to point messaging system compared to other Blockchain platforms which goes for global broadcasting or gossip networking for the propagation of data.
In these systems, nodes may issue transactions by broadcasting them in the overlay network. Validator nodes collect and verify transactions and periodically consolidate them into blocks, which are appended to a replicated, immutable ledger — the blockchain. However this process could suffer from high message overhead, as duplicates are introduced to the system.
Now to reduce the load, some networks spread block messages only by gossiping to a subset of neighbors. For example, Node1 and Node2 pick a peer each (say, Node3 and Node4) randomly and share the same information. The process continues in this fashion unless the information is passed on to all the connected nodes.
In Corda, there is no global broadcast or gossip network, we must specify the recipients of your messages on Corda. You can control who sees what and when they see it.
We can consider Corda has a fully connected graph. Nodes on the graph are Corda nodes with the potential to communicate with other nodes. It is not necessary that every node needs to communicate with every other node. That decision is solely given to the individual nodes.
Corda nodes discover each other via a Network Map service. You can think of the service as a phone book, which publishes a list of peer nodes, containing metadata about who they are and what services they can offer.
The “Ledger” is a subjective construct from each peer’s point of view.
In Corda, there is no single central ledger. Instead, each node maintains its own database of those facts that it is aware of. There are no peers that see everything.
From a data perspective, we can think of the Corda Ledger as a Venn diagram.
Consider a network with the nodes Alice , Blob, Carl , Ed and Demi. Each numbered circle on an intersection (see the pic below) represents a fact or data shared between two or more nodes. Now we lets consider a scenario where Alice loans Bob some money, both Alice and Bob will store an identical record of the facts about that loan. Alice only shares facts (and is therefore is only in consensus) with Bob — not Carl, Demi, or Ed. So they will be the only nodes that ever see or store this data.
The result of this design is that each peer only sees a subset of facts on the ledger, and no peer is aware of the ledger in its entirety.
Each node sees their own facts, and the facts that they share with others. Each person’s ledger has the facts(data) that relate to their own business dealings with other persons.
For example, Alice and Demi don’t share any facts, so they each see a completely different set of shared facts.
The rows that are shared between nodes (facts 1 and 7 in this example), these are called shared facts. Each set contains known facts and where the sets overlap are shared factswhich are stored on the Corda ledger.
States are immutable objects representing shared facts such as an agreement or contract at a specific point in time.
For example , the following state represents an IOU — an agreement that Alice owes Bob an amount X:
This state represents an IOU of £10 from Alice to Bob.
As states are immutable, they cannot be modified directly to reflect a change in the state of the world. Instead, the lifecycle of a shared fact over time is represented by a state sequence. When a state needs to be updated, we create by copying the old one and updating its properties as required. There is only one latest version at any point in time. Once a new state is created, the old one must be marked as historic. Historic states remain accessible and provide a useful audit trail. States are never deleted.
A sequence of states represents the life cycle of an agreement. It is created after one or more state transitions. State transitions occur in chronological order.
Specifically we can see how the shared facts between the participants Alice and Bob are evolving over time.
Each node on the network maintains a vault — a database where it tracks all the current and historic states.
The sequence head reflects the current state of the shared fact. The head is always current, while all prior states are historic.You can query the vault for all the heads of each state sequence or by type.
Corda mandates that each state must reference a contract. A contract has two items associated with it.
The legal prose states the rules governing the evolution of the state over time in a way that is compatible with traditional legal systems. We need the legal prose so that we can rely on the existing judicial system and legal framework to resolve any disputes.
Corda will use all referenced contract code to verify a (proposed) transaction. The verification function is defined in the contract code. The verification function must be a deterministic function.
So, what does it mean for a piece of code to be fully deterministic? Ultimately, it means that the code, when viewed as a function, is pure. In other words, given the same set of inputs, it will always produce the same set of outputs.
If Alice needs to transfer 100 tokens to Bob , Corda will run the referenced contract code. It will execute all of the constraints that the Cordapp developer has defined in it.
For example ,
// The lender cannot be the borrower.
tx.outputs[0].lender != tx.outputs[0].borrower
// The output state must contain an amount > 0
tx.outputs[0].amount > 0
If any of the constraints fails, it will throw an exception. If all of the constraints passes, then it will return nothing and consider the transaction which was passed in to be valid.
Get your free copy now
A transaction is a container that contains zero or more input state references and produces zero or more output states.
I know that might have went over your head. It happens. Happened with me too. However it will be clear after we discuss on different types of transactions.
There are three broad types of transactions:
Issuance creates new states on the ledger. By nature, they do not contain any input state references. They can create one or more output states. Some typical examples are agreements to deals such as a swap and cash issuance.
In the diagram above, we see one of the simplest Corda transactions: an issuance transaction. We see the creation of a new Cash state, issued by a PartyA to PartyC.
Updates are used to change state properties.
A typical example of an update transaction would be to transfer cash.
Unlike the issue transaction, we have an input in the transfer transaction, since we are trying to update the state (change owner) of an existing token on the ledger.
Updates take one or more input state references and create one or more output states.
It comprises a pair of Transaction ID and Index.
Transaction ID refers to the hash of the transaction which created the state.
Index references the position of the state in the list of outputs.
Any on-ledger state can be referenced by a (transaction ID, index) coordinate.
Let’s say we have a transaction with two state updates, State A and State B. Then, we have a subsequent transaction to update State B. In this subsequent update, State B references the State B that was produced in prior transaction.
Exits remove states from the ledger by ending the state chain. Exits take one or more input state references and create zero output states.
A typical example of an exit would be to redeem a bond once it has matured.
Now if we go back to the definition of a Transaction , it is a container that contains zero or more input state references (zero in the case of Issuance transactions )and produces zero or more output states (zero in the case of Exits transactions). Update transaction will have both the input and output states.
Now transactions need to be committedbefore they update the ledger.
To commit a transaction it must be signed by all required peers. Each required signer appends their signature to the transaction to indicate that they approve the proposal. Digital signatures are applied over the transaction hash and appended to the transaction.
If all of the required signatures are gathered, the transaction becomes committed.
Committed transactionsenforce output state immutability because they are digitally signed. Uncommitted transactions are transactions which have not yet been signed by all required peers. Uncommitted transactions are proposals to update the ledger.
