STATE AND VAULTS IN R3 CORDA
state and Vaults in the R3 Corda storage aspect, each node in the network maintains a vault and it is really a database that tracks all the data that node is privative, so it has all the current and historic states for that node and different nodes can actually have different views of state information.
So there could be data that is shared between three parties only those three will hold it there could be other data that is held by just two of them only those two hold it the third party does not hold it.
So these vaults are currently based on H2 embedded sequel engines and they are also planning to support JDBC have not looked recently whether they have actually added that but I believe they can support any relational database.
The current state of the ledger comprises all the unconsumed transactions. So it is very similar to UTXO. so you can have a sequence of these transactions the rest of it is historic state Corda allows for fine-grained access control on the state sequence.
So I can say who gets access to which state information I can do that in a fine-grained manner.
fabrics in contrast allow this data partitioning through the notion of channels and collections in Corda just the way the message passing works and how the transactions are shared.
Gives you a very strong notion of privacy only the participants of the transaction will ever see the transaction and the data within it.
states and vaults in r3 corda
In the r3 Corda, ledger let us say Alice is one node and bob is another node. in this case 1 and 7 are shared facts between Alice and bob. both of them will store theirs.
store them on their respective ledgers. So Alice stores 7. So the value of them is there.
Apart from this Alice might have some state that is known to bob and it will store it on it is ledger likewise bob has some state that is not known to Alice. So that in 5 and 6 that is all that store in bob ledger but not on Alice.
the vault for each peer is distinct from the other peer and it has only the data that is private to that node or that node or that node is aware of and again there is no global broadcast.
no node will know the universal or the full superset of all of this information. You want to look at it as the global state of the network itself you can think of it as the global state of the network or all the facts known by the network is really the union of all the facts known by each entity, so if you put that altogether there will be the global knowledge but no one entity maintains that. So all facts are split on and shared only by the parties private to that fact or that transaction.
So, has no notion of accounts it is only facts and information that stored amongst parties transaction ordering is enforced by hash functions. Based on previous states so in some sense this is a total ordering there this is only a partial ordering between transactions.
So you know that one transaction consumed information from a previous transaction so, there is a link between those two so there are dependency and order but there are could be a transaction where there is no ordering or at least at the level of a single peer they might be parallel transaction consensus allows you identify essentially the double-spending problem and determines whether a transaction is valid or not.
So we will discuss consensus and it all because of the fact that we have a full sequence of the provenance.
Of everything where has happened auditability it also achieved. You can get a full history of all activity that is recorded on each peer.
So this is again a fundamental difference fabric, ethereum one of those things they all are based on fabric, and all other permission networks are based on a broadcast architecture.
When I say ethereum I mean the permissions to assume ethereum. Corda takes a very drastically different view. It is only needed to know only pointed communication; there is no global blockchain at all.
CONTRACT IN R3 CORDA
The contract can be written in any JVM language.
There are many other and it is executed in the sandbox which is a modified version of the JAVA virtual machine and I mentioned before there is a contract code and associated with that contract code you can also associate a legal agreement with it and the contract code is going to refer to some state information and some participles so each state the state think of it is as a record that is going to be paired with a contract.
So a state cannot be manipulated by multiple contracts. Contract code has to be deterministic that is needed for any kind of a distributed ledger but it can reference external information through oracles.
The sandbox because it is a restricted environment guarantees determinism. So that is a modified version of JVM.
so it does not permit any non-determinism or randomness to get in. The determinism also ensures that the contract code determines the same result across all the peers so each contract is going to be a transaction that is going to be executed independently by multiple peers, but determinism is ensured because the code will always return the same result.
So the contract is only deployed on the peers that are party to an agreement. So the other peers will not even know the existence of this contract. The transaction can have multiple states.
I mentioned the code refers to multiple states. So it can have multiple states that refer to multiple contracts.
one transaction can actually operate on multiple contracts and each contract can have multiple states, for instance, you could like here is an example you can have a transaction for swap for swapping a bond for cash you are selling a bond you are getting cash in return so these could be different states that are manipulated by the transaction so I mentioned about this code is not law.
READ MORE ARTICLE: R3 CORDA
follow us on facebook