Data sharing on Corda

(Beginner to Corda) #1

If data is not shared across all the nodes in the network, does that mean there is no common ledger on Corda? What are the implications of that?

(Clemens Wan) #2
  • Corda, as with all distributed ledger technology, is designed to bring participants to consensus on shared facts. Most distributed ledgers do this by syndicating all facts with all parties to achieve consensus. With this model, for consensus to occur, all parties must validate all facts and clearly this has the effect of “leaking” information to participants whether they require the information or not and has unfortunate scalability implications.
    • Corda operates by sending transaction data only to participants which require it. This is either because;
    • They are a party to the transaction and are required to validate the transaction to reach consensus with their counterparty, or;
    • They are party to a deal which requires access to the previous deal. Even in this case, we can rely on transaction level consensus reached by all past owners of an asset, so there is not a need to interrogate all details of prior transactions.
  • Therefore, as noted, it follows that there is no common ledger held by all. Instead participants maintain their own ledgers containing only the set of transactional data they require.

(mustafa.ozturk) #3

Hey Clemens, what if I want all participants, now and in the future to be able to see the data I’ve generated. For example, how would you build a corda application where all participants share settlement instructions. How would I do that?

(richard) #4

Hey Mustafa,

Take a look at the “data sharing groups” design in the technical whitepaper. That is our current thinking on how to provide support for broad data distribution where it’s needed without degrading to a full broadcast system. After all, if we imagine a world where a huge number of applications, products, services, users are sharing a Corda network, you might want broad distribution of settlement instructions for those who are interested in settlement scenarios but users of the network who have a completely different use-case wouldn’t care about the data and it would be unreasonable to expect them to have to receive/store/process/validate it.

The Data Sharing Groups design is intended to address that idea…

It is just a design right now - we’ve not implemented it. We’d love your feedback on whether you think it would meet your needs… there’s time to influence it.

(mustafa.ozturk) #5

I’ll take a look. Thanks!

(qingfeng) #6

Hi Clemens,

If the transaction is not revealed to all nodes, how could others achieve consensus on the state changing caused by the transaction ?
I mean other nodes may not see the UTXOs changed. Then how to prevent the double spent problem?

When I read more documents, I see that you introduce the notary concept. The notary can validate if one specific state had been consumed.
So I have another question: Who controls the notary ? A regulation institution or a multi-sig federation ?

And I read more docs again…
AFAK, the notary is a shard of global ledger, different noraries stores different states?
What will happen if an account want to change the notary of a state ?
The unspent state output should be marked as destroyed on the old notary and then be created on the new, am I right ? Then how to make the change atomic ?

(richard) #7

Every output state commits to the unique notary cluster that is authoritative for whether that output has been spent or not. You can simply ask the notary if the output is still current or attempt to use it in a transaction. If it has been spent, the notary will not sign your transaction.

The underlying architecture of Corda allow all these options. Corda is unique in that multiple notary clusters can operate on the same network. So one could imagine some notary clusters being operated by regulators, some by a federation of users, some by single trusted parties and so on.

The way you move a state from one notary to another is through a special type of transaction. The output state must be identical to the input - with only the identity of the notary changed. This transaction must be signed, like all transactions, by the notary that controls the input state. See “changing notaries” on this page:

(qingfeng) #8

Thanks for your answer !
Now I understand.

(Sumit mishra) #9

[quote=“Clemens.wan, post:2, topic:66”]
[/quote] In corda which format in communication is happened and what are the API available for corda

(PC) #10


For one of our usecase, we want to send a purchase order from one node to other node & then use the output purchase order state as input for generating an invoice from the recipient node.
So,how can we take an unconsumed state as input and update it to a consumed state?

(Rudrakshi) #11

Hi @richard. Is there a way that a node can be notified on just the occurrence of a transaction between two different parties and not actually be able to view the details of the transaction? For example, in a simple trade finance use case, is it possible for the export bank to know that a sales contract has been agreed upon between the seller and the buyer before approving the letter of credit received from the import bank? Am assuming that the export bank is not party to the sales contract transaction and hence does not need to sign it.

(richard) #12

Hi Rudrakshi - the flow framework may be useful here… it allows nodes to contact/communicate with other nodes directly. Can you ask this question on stackoverflow please? (tag it with corda). We’re moving questions like this there as the community is much bigger… and I think your question is a good one that lots of other people would like to hear the answer to.

(Rudrakshi) #13

Thanks! Posted on stackoverflow.