Does Corda node send messages to only the participant nodes or to all nodes of the network/zone?
Transactions are shared only between participants (and external observers who are added to the transaction on purpose). From the Corda whitepaper (downloadable from here):
A transaction between a group of parties is visible only to them, and
to those whose own view of the ledger in the future may depend on verifying
the validity of this transaction. [...] The foundational object in our concept is a state object, which is a digital document which records the existence, content and current state of an agreement between two or more parties. It is intended to be shared only with those who have a legitimate reason to see it.
And from Corda training doc:
According to R3, "On the grounds of confidentiality, we reject the notion that data should be broadcast to all participants or cumbersome pre-defined groups." Corda communications are peer-to-peer on a "need-to-know" basis without broadcast. Need-to-know is quite different from Ethereum's public broadcast, Quorum's private transactions or Hyperledger Fabric's network "channels" approach. In a Corda network, if Alice transacts with Bob, then only Alice and Bob need to know about it, and possibly a regulator.
Related
Corda non-validating notary doesn't have any information about transaction signatures. Then, when some party in network made denial-of-state attack, how the network find who made that transaction ?
About denial-of-state attack
https://www.ingwb.com/media/3024436/solutions-for-the-corda-security-and-privacy-trade-off_-whitepaper.pdf
I don't know what a denial of state attack means in the blockchain context and I'm not able to find anything on it online.
Assuming that means some kind of malicious transaction, remember that generally on a corda network you'll know who's running which nodes (or at least have their keys) so if someone were to submit bad (or malicious) transactions presumably they'd fail verification on the other nodes that would be affected.
You can find out more info on notaries from the docs page here: https://docs.corda.net/docs/corda-os/4.6/key-concepts-notaries.html
In our Corda network we work with Accounts. We have a network with well-defined nodes.
To show the problem, imagine 3 nodes, PartyA, PartyB and Notary.
We created the accounts (AccountA for example) on PartyA. We have flows that can be executed at PartyB that has AccountA as a participant in the transaction.
Now imagine that PartyA is down for any reason, or communication between nodes is not available.
When I request a new AccountA key for PartyA, the flow gets stuck trying to communicate and does not return any exception. This happens in any situation that tries to communicate with another node, when running a CollectSignaturesFlow or ShareStateAndSyncAccounts to share account states for example.
The question is, is there any configuration or mechanism to return an exception in those cases where it is unable to communicate with another node?
Timeouts can be handled differently depending on where you need to manage it.
There is the flowTimeout:
When a flow implementing the TimedFlow interface and setting the
isTimeoutEnabled flag does not complete within a defined elapsed time,
it is restarted from the initial checkpoint.
Currently only used for notarisation requests with clustered notaries
Or otherwise it can be done programmatically in your flow. I suggest you to take a look to this part of the Corda documentation (Concurrency, Locking and Waiting) where there are many suggestions that you could try to implement.
In Corda, while every state can have a different notary, all of the states consumed by a particular transaction must be assigned to the same one.
What's the impact of this newly-appointed notary to the original ones in terms of double-spending check? e.g.: cash state is handled by notary A. But due to a DvP transaction involving cash (notary A) and other asset (notary B) in its input states, let's say that we appoint notary B. How can notary B knows which cash states have been consumed, knowing the fact that notary A is the one currently owning the list of consumed cash states?
The same question as 1), but the impact in terms of visibility of tx dependency chain. Following the above example, assuming that both notaries are validating, must notary B request notary A to give him the tx dependency chain of cash states?
Many thanks for clarification.
Best,
Afrisal
1) There will be no double spend, as you mentioned all of the states consumed by a particular transaction must be assigned to the same Notary. So before making any Tx that has different notaries, you'll make sure their notaries are the same. you'll do so by calling NotaryChangeFlow all the information about the consuming states will be transferred to the new notary.
2) you'll simply make a call likesubFlow(NotaryChangeFlow(stateRefOfYourState, newNotary)). This assembles the transaction for notary replacement and sends out change proposals to all participants of that state. If participants agree to the proposed change, they each sign the transaction and the notary gets changed.
Does the Corda Enterprise have an Information Broadcast solution?
If it does not currently exist, will it be possible in the future?
The quick answer is, of course you can perform "information broadcast" and it can do so in exactly the same way that other DLT platforms do. In fact, it makes no sense that you can't broadcast with Corda!
This question comes up a lot, probably because there is some marketing material which says that Corda messaging happens on a peer to peer basis and that "there is no broadcast". What this actually means is that there is no gossiping of transactions with Corda. This is a good thing because it means peers have fine-grained control over which other peers can see their transactions.
To send a message to a peer on a network, you must know where the recipient can be reached. As such DLT/blockchain platforms maintain a list of peers. Platforms like Bitcoin, have a list of peers bundled with the software to bootstrap the network. This list can grow as more peers are discovered. With Corda, this is currently done through the network map service. Corda nodes can query their local cache of the network map to get a list of peers on the network.
If you want to broadcast a message to all peers on the network or a sub-set of peers on the network then it follows that you can iterate through the set of peers that you which to send a message to and send them the message. Easy. Note there is no gossiping here. It's simply just a bunch of unicast messages. You can do this asynchronously, as well.
It is also possible to facilitate gossiping of messages with Corda. In section 12 of the technical white paper, there is a concept mentioned called data distribution groups or clubs. You can think of a club as a directed minimum spanning tree of nodes on a network, which might look something like this:
As such, a node can start a club, then invite others to it, and so on. Members of the club can send a message to the club and it will be forwarded on to all the others. Referring to the image above, if node one publishes a message to the club, then all the other nodes will receive it.
I've implemented a prototype of this here. It's a feature that we plan to roll out in the near future.
Probably worth noting that most networks don't default to broadcasting or multicasting because it makes them a lot slower (if you look into the original history of the Internet, for example, you'll see that multicast didn't exist).
Broadcast platforms have a lot of problems in that senders typically don't know if the recipients have received those messages or not, so it's not at all unusual to find that when some systems talk about "broadcasting" they actually do multiple unicasts instead.
The Corda approach means that there's guaranteed delivery of the messages sent to all the relevant parties. As a point of comparison, even though Wi-Fi networks support multicast messages at L2, most access points will prefer to convert L3 (IP level) multicasts into a series of point-to-point L2 messages as these will be delivered reliably (the receiver ACKs the messages).
It's not that hard to build a gossipy sort of design on top of Corda's messaging. We did this for project Ubin phase 2a in 2017.
Within one business network (Business Network A), a notary provides validation and signing off on the transaction proposed by N number of participants.
In the situation where this asset needs to be transferred from one business network (Business Network A) to another (Business Network B), how will the provenance work already completed on the Business Network A be maintained, handled while working in Business Network B?
when there is a transfer of assets from one network to another.
i.e. Morgtage Home Loan Cordapp ---> needs asset transferred to Legal Lending Cordapp
it's not completely clear how the notaries will be setup, and the level of privacy and/or data isolation that will be able to be maintained between notaries on different collaborative Business networks.
Please explain.
One requirement for a compatibility zone is that all the nodes in the compatibility zone are able to transact for any purpose at any time using any application using any vault data. Among other things, this implies that:
The notaries in the compatibility zone are not associated with any individual business network(s). Each notary is a notary for the entire compatibility zone
All nodes in the compatibility zone are required to trust all the notaries in the compatibility zone
When you want to move a state to a new notary, you use the built-in NotaryChangeFlow to repoint the state to the new notary:
val newStateAndRef = subFlow(NotaryChangeFlow(originalState, newNotary))
If the new notary is validating, it will request the entire transaction chain from the caller of NotaryChangeFlow.