Validity Consensus in r3 corda
Validity Consensus is a recursive process and it could be time-consuming.
That could act as a negative for Corda because of the fact that they do not have a global blockchain people are not validating transactions continuously but only a need to know basis when they are accessing that asset.
So that is an inherent trade-off that probably is Corda. That is why they have designed it this way.
But one thing with the Corda is that walking the chain and verifying these past transactions is done automatically by the flow framework.
So the flow framework can fetch all of these transactions and verify it and that is all automated for you but it still incurs a computation over here.
So in the only case where so this I think this negative that I am talking about here at least by the way treated as own perspective here.
This is only needed for assets that are being transferred.
For assets that are not transferred across users let us say there are just two parties that are trending these assets so then there is no verification that is needed there is no walking the chain that is needed.
So it is only when parties are seeing assets that they did not see before will this additional validation verification. And walking the chain will be needed.
Now there is also a privacy concern as data can be leaked from the issue parties to parties.
Further down the change chain.
But a Corda is working through multiple alternatives to address that privacy issue. So they are looking at signing at key randomization and anonymizing peers.
So that the peer’s identity is not revealed.
They are also looking to use a trusted platform such as intel SGX to verify transactions on the remote peer without transferring history.
So many alternatives are being considered. So the other alternative also states re-issuance.
there could be a say maybe a central authority that comes back and says yes this is a valid state. I will issue a new state for you. So all that is possible.
That was the validity consensus and how peers validate whether all the history of transactions is valid.
Now uniqueness consensus is provided by a special entity called notaries.
In some sense, notaries are similar to fabric, but I will highlight the similar to order service in fabric but I will highlight the difference as we talk through.
So once let us say the bob and Alice both sign this transaction they can send it to a notary and say hey notary tell us whether this transaction is unspent.
So the notary service is designated at a time, the state is issued.so then for each state at the time of the issuance of the state you can specify a notary service that will determine the uniqueness of the state.
Let us say it is a bond, a state representing bonds, so whenever that bond is created that state you also specify this node is going to be the notary for this bond and that notary will take care of ensuring uniqueness.
So what the notary will do this fairly simple if it receives the transaction and it has inputs that have not seen before then it will be added and it will be the notary will sign it and say yes this transaction can be admitted because I have not seen the inputs of this transaction form this is still is unspent and the notary will sign it and send it back to the Alice and bob.
A special type of notary called a verifying notary will require the entire dependency chain of histories for greater assurance.
So this is a verifying notary will not only do uniqueness consensus but will also do a validation consensus that we talked about.
It will validate the entire history of the transaction and on top of that will also ensure that this transaction input has been unspent. Sp of course the notary will only permit one if there are conflicting transactions that are trying to use the same input state the notary is going to be the tiebreak so it is going to say ok.
This transaction will go through first the second transaction will be invalidated. Note that many notaries can exist in a network.
The notaries are created at the level of state so based on the states different notaries can be present in the network for different states. This can be provided not only privacy but it also provides load balancing and ensures lower latency.
If everyone all the state information maintained in the network went to just one node, of course, that node is going to become a bottleneck. It is also a privacy concern.
So it is possible to separate notaries for different states. Now I mentioned ordering service in fabric.
Similar to that the ordering service in the fabric also provides some notion of uniqueness but not so.
The ordering service in fabric just orders transactions. It does not do anything else, it doesn’t determine whether two transactions are conflicting with each other or whether they are unique.
It does not look at that, it simply looks at the transaction almost as a black box and says ok here are 100 transactions.
I am going to order them 1 to 100, that is all the ordering service in fabric does. However, the notary in Corda needs to look into the input states and output states of the transaction itself.
So it has to be the transaction details and only then can it verify whether this transaction is unique.
So in addition to just ordering and avoiding duplication, avoiding double-spend notaries also look at the data to be able to say that double-spend has not happened.
I mentioned notaries again is a logical concept. It can be a single node it can be a cluster it can implement any arbitrary logic within itself within that service to determine this uniqueness it can be raft based consensus it can be byzantine fault tolerance consensus so all that is possible within a notary service.
So again these kinds of consensus algorithms are similar to the ordering service.
Ordering service in fabric uses it for ordering; it does a little more in actually determining whether double-spent has happened or not.
SO here is an example transaction flow involving a notary.
So let us say there is an Alice broker known for Alice(node a) that is going to create a transaction it is going to verify this transaction is well-formed it is going to sign it.
Then sends it to another node so this could be reinsurer so this would be bob.
The bob then verifies this transaction bob also sign it sends it back to Alice now both parties have signed this transaction Alice can then send this to the notary.
The notary will then determine whether this is indeed unspent. Once it determines that it is unspent it might be receiving many such transactions for multiple parties
This the notary will then order all of them through either a single machine is ordering then either or multiple nodes are employing consensus to order them.
It will then detect whether there are duplicates and only if it is not double spent if it is a unique transaction output.
That I will sign that transaction so the notary adds its signature and sends its back.
Now, this is the point where the notary sign is when the transaction is considered final.
And then Alice and Bob and commit those transactions into their respective ledgers.
Likewise, Alice and Charlie are if a different node might have their flow working on a different state but they can employ the same notary service for the same what we serve to order.
So then the notary you service will check whether Alice is trying to send the same state to both bab and charlie and it will prevent others from double-spending.
Alice can then leverage the notary service to prove to Bob and Charlie that it has not double-spent this transaction.
So that is why the notaries are specified at the level of the state. That way this notary can verify that this state is unspent and different states can employ different notary services because there is no double-spending problem across them.
NOTARIES AND TRANSACTION TIME-WINDOW
Notaries can also be a time-stamping authority and transactions can include a time window to be committed.
So if the transaction comes to the notary too late the notary can refuse to sign it saying it is outside the time window and does not meet the criteria mentioned in the transaction time window can have a start and end time and or it can also be open-ended so the purpose of the time window is to communicate a transaction position in the timeline, corresponding to contract code.
So like I mentioned previously this is almost the dag of states maintained by each node but if you want to put a time stamp on it then the notary service is the one that is going to put a time stamp on it.
And if you do want to have a time stamped ordering across different states that represent in the network again the notary service can help with that. again the notary service is also helpful in regulatory reporting to say that I perform this transaction on this data again that sort of reporting needed for compliance can also be provided by the notary service.
Oracle is a first-class principle in Corda.
It serves as an authority to binding and definitive authority on facts that are external to the network.
For instance, if a smart contract depends on the share price of a particular share.
So then there could be an oracle responsible for providing the share price and all the peers trust the oracle to provide the same price information to all of them regardless of who is requesting the price oracle provide them the same price value.
So that will ensure determinism of the contract and the contract itself can be access-controlled to be within that time window.
Like I mentioned you can specify that the contract has to be executed in this time window.
and the oracle can also be configured to provide the same share price to all peers within that time window.
So that way contract execution can be deterministic and the contract can also leverage facts from the outside world.
so the oracle is of course trusted entities the peers are agreeing to trust the oracle for this service.
In financial service again the need for oracles, so it could be needed for oracles is seen a lot and I guess that is why Corda has incorporated oracle has the first-class principle.
Some oracles have been created for instance as a separate entity, not really part of the platform itself.
But here in Corda oracle are first-class citizens and oracle can be included in the flow.
For instance, in the flow itself, Alice can contract the oracle get some information do some validation check and check whether it wants to sign this transaction oracle are implemented in a transaction using either commands or attachment so, it can be an attachment to a transaction and that can be validation checks on that and in this case when an oracle is a present signature from the oracle is needed as part of the transaction proposal.
So this is the overall reference architecture of Corda. It includes all the components of Corda.
We talked about how the vault stores, the state information that is each peer is aware of the storage itself, the transaction flows management, identity management, key management, the network map that tells you which peers are running on which IP address how do I send message to a particular bank, for instance, how should I address them if they can refer to notaries it can be part of a messaging it will have a messaging service that connects to other nodes and of course all the communication with the Corda node happens through an RPC client,
So I hope that you have got a good overview of the Corda architecture. We have
Looking at a bunch of these platforms, now I hope you are appreciative of the fact that there is a lot of innovation going on in different platforms.
There are different design principles they are all starting with a different construct they are creating to address the enterprise requirements of many of these blockchain applications.
So some of these networks utilizing these platforms are just starting to come into production and it is a very exciting time for enterprise blockchain applications to make a big impact in all of our lives.
So with that thanks a lot it was great having you with us in this course and I hope you enjoyed it as well talk to you again soon.
And can also have a web server along with it.
This user-defined Corda application includes all of this includes the services includes the contract the state information the transaction flows, referring to these state all of that is captured as part of the Corda application and the Corda application can also refer to existing flows refer and utilize existing flow that is already defined as libraries by Corda.
So that is roughly the high-level old view architecture of Corda.
READ MORE ARTICLE: R3 CORDA
follow us on facebook