Trader-demo - database observations

(Nehal Shah) #1

I have been investigating trader-demo process using debugging and looking at database on side(buyer & seller). I have noticed following in database at the end of running runSeller demo when it finishes running TwoPartyTradeFlow. Please help understand.


  1. Why the commercial paper output of last transaction is not propagated to both databases (Seller & Buyer)? Seller only sees cash output in the vault table and Buyer sees commercial paper output and cash output unspent cash.

  2. Why seller’s CP_STATES table would not see the final output? Shouldn’t both database contain same entries?

(Clemens Wan) #2

The TwoPartyTradeFlow is used to show true DVP (Delivery Versus Payment) of an atomic transaction that exchanges the cash and ownership in one single true/false transaction. This is the potential of removing reconciliation for the synchronized databases. Since this is a true change of ownership with the UTXO model, the seller will no longer “own” their CP as the access to it has been moved to the buyer. The same becomes true of the cash as the buyer will not be able to access the cash that it has moved to the seller.

This can be confusing if you think of this from a standard blockchain perspective because they typically broadcast all transactions (and those transactions are processed by validators for ordering). These Ethereum transactions look more like function calls and executions of instructions to the Ethereum-wide database.

In Corda, I like to think of each node as its own unique view of the assets and the “position” of a bank. Each CP_State itself will have its own “chain” of transaction histories between nodes, but those states do not need to be shared with all parties.

(Nehal Shah) #3

If seller has a web app which has a dashboard and the requirement to find out which CP are ready to be redeemed and which one he has already redeemed then how could we achieve that as Seller doesn’t keep track of the stat?

(Clemens Wan) #4

You can query the historical/archived states as well, but most of the servicehub calls are for the latest states in the vault. You can also query the transactions directly and create a table of transactions (the transaction graphs are saved).

If you’d like to alter this example, you can write your own flow that does a copy of the new state with a new field for “status” and that would mean the states are not consumed, but both states are updated in a single transaction.

More broadly, any transaction can encompass multiple state transitions through the contact code commands. The TwoPartyDealFlow is executing two state changes - one updating the ownership of the CP_STATE to the buyer and another one taking the price of the CP_STATE and sending the cash from the buyer to the seller.