TRANSACTION FLOW, SPLIT AND MERGE STATE IN R3 CORDA
The R3 corda ledger is a directed acyclic graph of state sequences that evolves over time
Transactions can contain state of many types and they are atomic, i.e. all state changes occur or nothing occurs
Transaction can split and merge state representing fungible assets
The Corda does not have an inherent cryptocurrency but you can model cash or bonds or other financial instruments as states.
The cash itself can be modeled as a state and it can map from letting us say one cash state to another cash state.
So cash can go from cash 0 to cash 1 in exchange for letting us say a bond which goes from 1 bond to bond 2.
So these are captured. so this is a very similar UTXO example. You have split 10 USD into 8 USD in 2 USD and you are going to consume those in one or more transactions and this 20 USD can be pointing to a previous transaction altogether.
So this is similar to a split and merges representing fungible assets very simple to how bitcoin is a fungible asset.
TRANSACTION CONTRACT EXECUTION
1. Alice calculates value STATE, using flow or off –chain potentially proprietary) logic and submits transactions.
2 contract verifies whether state change satisfies all conditions and attaches Alice’s signature
3. Corda separate’s logic to create transaction proposal (done using flows or off network) from logic to verify, done by contracts on the network
4. Contract verifies whether state change satisfies all conditions and attach BOB’S signature
Let us just work through an example of our transaction and contract execution will work.
So let us say this is a transaction between two parties Alice and Bob, Alice first executes the transaction it calculates the state value.
It calculates state 2 using a flow. So is going to execute this logic and it is going to submit a transaction.
So that is the first step. So the second step once the contract gets this transaction from Alice it is going to first verify whether this is a valid transaction and the state change you will check whether all conditions or preconditions for this transaction are satisfied and these and these preconditions are may specified.
There is a contract and there is each step of the contract there are preconditions and the precondition will specify who needs to sign what other information needs to be valid maybe it refers to an oracle, an external piece of information.
All of that is validated and only if all the preconditions are met will the contract execution be valid.
So that now includes Alice’s signature and that signature is verified. So that is the contract part.
The third thing is that Bob might receive this as a peer to peer message. So it receives this message from Alice and then it will check again.
Then execute other validation logic to see whether bob is ok with signing this transaction and this logic can be some external information.
So bob can use information private to just bob itself and determine whether it wants to sign this and let us say it agrees to sign it then bob will also sign this thing and the contract can verify that all the conditions are met and this is actually a valid transaction.
Now once this fully goes through then the transaction is recorded by both Alice and bob that now this is found out.
TRANSACTION PROPOSAL AND FINALITY
Uncommitted transactions are proposals to update the ledger which have not yet been signed by all required peers.
To commit a transaction it must be signed by all required peers. Alice proposes a transaction which is signed by her peer node
Bob signs the transaction next. The transaction is then sent to the notary service.
If all of the required signatures are gathered, the transaction has achieved validity consensus and (together with uniqueness consensus) and becomes committed.
In the notion of finality first, there are proposals that are made. So there is a current state and the desired state.
So Alice creates these desired states and submits them to the contracts but to commit the transaction it must be signed by all the peers.
So Alice proposes and it is signed by her peer not. So there is the signature of Alice that is added to this desired state and then it is sent to bob and then bob can figure out whether they want to bob also sign it and them adds bobs signature.and then finally once the contract verification validation passes it is also determined that this is unique this is the input states are not consumed in other concurrent transaction once it is determined to be unique that is through we will talk about how that uniqueness is achieved uniqueness consensus and then that is recorded as final.
So that is once it is recorded and these states are marked historic is when transaction finality is reached. So we still need to see what validation there is happening.
TRANSACTION PROPOSAL AND FINALITY
Digital signatures enforces output state immutability. Signature is created against a hash of the txn. immutability
The ledger evolves over time by applying transactions, which update the ledger by marking zero or more existing ledger states as historic (the input) and producing zero or more new ledger states (the output). Transactions represent a single link in the state sequences.
Transactions references previous transactions by hash, building up an immutable chain-like structure
Unlike fabric, there’s no chain-of-block of transactions and a world state. State sequences lead to an immutable DAG, shared between parties on a need-to-know basis. The current state is all the unspent output.
The digital signatures are the ones that are giving you immutability and authenticity.
In fact, Alice was the one that signed it. No one has modified it since the time Alice signed it.
So when an auditor comes and looks at this they know exactly what happened they know that none of these could have been altered because if they were altered the signatures would not match.
So through those digital signatures, you can get the mutability and authenticity.
But state information is only available with Alice and bob; it is not available universally with other nodes, that is the no blockchain aspect.
So the state sequence leads to almost like a dag. Each node is going to maintain this dag of state sequence each state could be referring to the past state and it is really DAG.
TRANSACTION ATTACHMENT IN R3 CORDA
•Attachments are arbitrary data in the form of ZIP/JAR files identified by a hash.
•Attachments are intended for data on the ledger that multiple peers may reuse over time.
•A transaction can reference one or more attachments (files not included in the transaction itself).
•Transaction may contain references to contact code or data files such as passport.
Reference to contract code in the attachment restricts which contract can be applied to verify the transaction.
Attachments are added by tx creators and referenced by their hash.
data files can be accessed by the contract code. Code can check for authenticity of data by looking at signature
Attachment (documents) are first-class citizens in corda’s design. Not hard to do with fabric, but corda makes the development experience simpler by providing APIs to easily manage attachments.
In Corda one of the key designs, principles are the notion of attachment, so I mentioned having a contract code associated with a legal agreement or legal proof.
So they can be provided as an attachment to a transaction.
So if you look at a particular transaction, it not only specifies input states or output states, it can optionally provide a set of attachments.
So it can refer back to the attachment, refer back to the contract code, it can refer back to external documents, maybe this might be physical documents or scanned documents for instance.
All of these can be added as attachments to support a transaction.
these attachments can be added as attachments to support a transaction.
So, these attachments can be arbitrary data in the form of zip or jar files identified by a hash.
And the jar files are typically for contract code reference itself and attachment is intended for data on the ledger that multiple peers may be used over time.
So this is supporting documentation in some sense. A transaction can reference one or more attachments and it may contain references to data files also.
So, for instance, it can refer to an identity document it can refer to a bill of lading
Which is a trade document for reference if you are doing tried finance for instance and attachment are of first-class citizens for a Corda?
In any other blockchain platform Hyperledger fabric an Ethereum you can, of course, store attachment but it doesn’t come as a first-class citizen, as part of your transaction structure itself and that I believe has value.
It does make things a little easier for an application developer especially in I think financial services where typically there are financial documents that need to be attached with a particular transaction.
R3 CORDA TRANSACTION FLOW
•In R3 corda, peers communicate point-to-point.
•Transactions specify a list of message recipients that are required to sign and verify the transaction.
•The flow framework is designed to orchestrate this multistep coordination and verification of transaction messages.
•Thus to commit a transaction, there’s a back-and –forth communication flow between peers.
Transaction flows are the ones that are going to validate the sequence of steps that are needed to make a transaction legitimate and be committed on the ledger of different peers that are different transacting.
so let us say we have an example where we have Alice, Bob, and charlie in a network and there are a 1 notary and 1 oracle.
This notary thinks of it as a service so it can actually be multiple nodes there but logically it is a single entity.
So as I mentioned Corda all communication is a point to point and the transaction will along with the contract logic itself.
The transaction specifies a list of message recipients that are required to sign and verify the transaction.
So the flow framework is then designed to arrange. First Alice needs to sign then Bob needs to sign and then it can be finalized.
And the logic that Alice and Bob used to sign this transaction can also be part of the flow or it can also be external information.
First, let us say Alice creates a transaction proposal to sign it.
So it is going to take some input then transform it into some output, input and output can be null as well or one of them can be null for instance and this transaction state along with the attachment is signed by Alice.
Alice has a proposal for a transaction. Alice then sends this proposal using a point to point message to bob.
Bob on receiving this proposal can inspect it and can use any logic of their choice. This is off-contract logic this is not the contract logic itself.
But it can look at the contract executions to see if the state derived by Alice is correct and it can also use external information.
to see whether Alice is making if this is a payment for instance whether Alice is making a payment in time for instance.
It can use all sorts of logic that is private to just bob and use that information to determine whether it wants to sign it or not.
Once it agrees with this proposal from Alice, bob attaches its signature also and sends it back to Alice.
So now both have this transaction that is signed by both parties and let us say that was all that was needed for this transaction to complete.
This transaction could potentially be sent to a notary and the notary can attest to the fact that there is no double spend.
that happens for instance in the network it provides certain functionality so the notaries can also be part of the flow itself and that is also part of the flow itself and that is also captured before transaction finality is reached.
R3 Corda provides a library of flows for common use cases such as:
•Atomic asset swaps
•Broadcasting data to multiple peers
•Agreeing multilateral deals
We start with Alice creating a flow, starting a flow it creates a proposal, it creates a transaction it signs the transaction sends it to bob and that is where bobs flow begins so at this point Alice flow is suspended it is checkpointed and Alice is going to wait.
Even if Alice goes down and comes back up at a later point. Its flow can resume.
Bob once at receiving the transaction it is again going to inspect and verify if it signs the transaction and then now it has a signature from both Alice bob. So now it can commit that transaction and you can also send that transaction.
The signed transaction by both parties sends it back to Alice. Alice again inspects and commits. So that is the full flow.
So if you look at the bob flow. This what bob date, Alice in-between waited for bobs signature and then it also committed so at this end of this both nodes of committed.
In case Alice did not receive this message it can time out and it can ask Bob whether did you agree to it or not, it can always fetch that back from bob.
And because all of these are recorded immediately. Once both of them commit no one can go back on that transaction because the same of these flows can be complicated it can involve multiple parties, here it is just a two-party flow.
These flows can involve multiple parties and multiple signatures. Corda provides a library of flows for common use cases such as:-
- Atomic asset swaps
- Broadcasting data to multiple peers
- Sending cash
- Agreeing multilateral deal
So for some of these common flows that are seen in financial use cases, Corda provides of these flows.
So these flows together with the contract logic itself comprise the whole transaction lifecycle and how a transaction from proposals to commit how they have.
Peer reach consensus in two ways
|VALIDITY CONSENSUS||UNIQUENESS CONSENSUS|
|•check that the transaction (and all dependencies) is signed by all required peers.•Check that the transaction satisfies the constraints defined by the contract.||•check that the transaction output is unique in the network, i,.e. there’s no double-spend attempt|
Problem: since there’s no global broadcast and transaction are P2P, what happens if an asset issued by party A to party B is transferred to party c a month later? Party c can’t see the provenance of the asset.
We have only talked about the transaction execution. We need to talk about how consensus is reached between peers, at least peers who are transacting with each other.
So, Corda distinguishes two notions of consensus.
One of them is validity consensus which is to say that this transaction is actually meeting all criteria, it is that all the dependencies are met, all the required parties have signed.
That makes the transaction valid and all the constraints are satisfied so that is the validity consensus.
The uniqueness consensus is to check whether the state. I mentioned the UTXO state information.
It checks whether the UTXO has not been spent. So the transaction output is unique.
So no one is trying to double spend on this network so that is a uniqueness consensus.
the validity is separated away from uniqueness. We will see how both of these are achieved.
Now one of the problems that you could see is since there is no global broadcast, and transactions all peer to peer.
Now what is the problems that can happen is if an asset is issued by one party and it is transferred to another party B and then to C for C to verify a let us say a month later, they will have to go through the provenance of the entire asset to see if all the transaction has in some ways that are similar to how are a financial transaction and other transaction also happen in the real world.
For instance, let us say you are buying a new piece of land. Before you buy the land you will probably get the services of a lawyer or you will probably do it yourself.
You will verify whether this piece of land this legal document has changed hands in a legitimate manner maybe you will look at a 100-year history, it might have changed hands may be dozens of times. You will go through all the history of the transaction.
That whole provenance is not recorded in the blockchain, it will be great if it is but what Corda is providing is that provenance is recorded on a blockchain but you will still have the overhead of having to go through and verify every one of those transactions. Because all that is new to you are a new buyer for this piece of land.
Before you buy it you will have to verify all of those previous transactions on exchanges, make sure they are legitimate before you can accept it so that an overhead Corda will incur all right especially assets that are changing hands.
Validating transaction histories
|Shared state between charlie(central bank) and danCharlie issues an asset to dan||Shared state betweenDane and aliceDane transfers asset to alice inExchange for cash|
Let us say there is a central bank that issues a particular asset to DAN. so this is a bond that is issued. So Charlie is the central bank here.
So it is signed by charlie and once dan accepts it, Dan also signs it with Dans with his signature.
So that is a transaction that is recorded on the blockchain. Now let us say Dan shared that same asset with Alice.
So, the reference to the previous bond is made and a new state is created. So each of these is not the same state that is modified; it is actually a new state that is created that is how it is or remains unspent.
So this is how the unspent transaction is because of a spent state. Now this transaction is signed by both Dan and Alice
Validating transaction histories
|Shared state between charlie(central bank) and danCharlie issues an asset to dan||Shared state betweenDane and aliceDane transfers asset to alice inExchange for cash||Shared state between alice and bob. alice transfer asset to bob in exchange for cash|
When a peer is presented with a transaction containing input state references, the
Prior transaction which created the reference output state needs to be verified
This recursive process is called walking the chain.
And now let us say Alice shares this with bob.
Now Bob needs to verify the whole chain, the fact that charlie issued to dan, then issue to Alice.
All that has to be verified by bob. This is actually a legitimate piece of state that has come from the central bank and has gone through a certain set of legitimate transactions.
So I can believe this so then I will be willing to purchase that bond so then the final transaction is also signed by Alice and bob.
Now, whenever a peer is presented with the transaction.
Containing input references that it has not seen before then it needs to fetch all of this and verify this so this is called walking the chain.
NOTARIES –UNIQUENESS CONSENSUS
•Transaction finality is reached when the specified notary service signs the tx
– Notary service is designated at the time a state is an issue and remains fixed for the life- the cycle of the state.
•In simple terms , the notary service maintains a map of transaction IDs used as input.
•if the notary service has not seen the input reference before, the input reference is added to the map, transaction is signed and is considered final
-This ensures the output is a unique successor of the input and thus a double- spend did not occur.
•A special type of notary, called the verifying notary, will require the transaction and the entire dependency chain of histories for greater assurance.
•Many notaries can exist in a network (privacy, load balancing and low latency)
•Single machine or cluster(RAFT or BFT consensus if notary instance is run by multiple
EXAMPLE FLOW INVOLVING NOTARY
• There’s no global broadcast in R3 corda(unlike Fabric or Ethereum).
•Peers need to recursively retrieve the entire dependency graph of historic transactions from other peers to fully validate transactions.
– Handled automatically by the flow framework
– Neighboring peer usually has all history
– Only required in cases where transactions are not confined to a set of participants (e.g. generic assets such as cash that are transferable, whereas a fixed trilateral agreement is OK).
•Can lead to a long sequence of transactions being moved from peer to peer.
•Privacy concern as data can leak from issuing parties to parties further down the chain that need provenance.
•Problem only with transferable assets.
•Using a merkle tree to hide transaction histories.
•Signing key randomization to anonymize peers
•Intel SGX to verify transactions on the remote peer without transferring history
NOTARIES AND TRANSACTION TIME-WINDOW
•If a transaction includes a time-window, it can only be committed during that window.
-the notary is the timestamping authority, and refuses to sign transactions outside of that window.
-time-windows can have a start and end time, or be open at either end.
•The purpose of a time window is to communicate a transaction’s position in a time-line to contract code for the enforcement of contractual logic.
-Eg redemption of bond or late payment of debt.
•Time windows may be used for other purposes, such as regulatory reporting.
•Oracle allow the validity of transactions, as determined by a contract, to be conditioned based on an off-ledger fact (e.g. price)
-An oracle provides a digitally signed data structure that
assets an off-ledger fact.
•The oracle is a source which is accepted by multiple parties as authoritative, binding
and definitive for a range of facts (or calculations).
-The oracle can source data externally.
-Alternatively, the oracle can calculate results based on on-ledger states or attachments.
•Oracles are available during the proposal and verification of a transaction.
•Oracles are implemented in a transaction using either commands or attachments.
– the oracle becomes a required signer of the
Oracles are first-class citizens in corda . Developer support makes it easy to write code that sources off-ledger facts from oracles.
Vault: stores output states relevant to a particular node
Transaction storage: key value store for attachments, transactions, and serialized state machines (SSM)
Flow State Machine Manager: manages operation of flow state machines
Identity/Key Management: manages various supported identities and generated keys used to sign transactions
Scheduler: schedules operations for future points in time
Network Map: searchable phone book of nodes on network
Notary: obtains authorized signatures
Messaging: interface with other nodes for
Oracles are first-class citizens in Corda . Developer support makes it easy to write code that source off-ledger facts from oracles.
READ MORE ARTICLE: R3 CORDA
follow us on facebook