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.
Related
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.
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.
If input states are consumed in a transaction then a notary is required. As per the documentation, the same notary that signed the original unconsumed inputs should sign the transaction which will consume these states to create an output state.
If there is a pool of notaries then how to search for the original notary to sign the new transaction?
Available docs/api explain how to get a new notary which is usually getFirstNotary/getAvailableNotary.
Cheers
There are two aspects for notaries to keep in mind:
High Availability: the notary pool provides replicated instances of the notary to ensure that its notary services are consistently available.
Notary Identity: the X500 identity of the notary that is registered onto the Corda Network.
When speaking about a notary on a Corda Network we generally refer to its identity. The way in which a notary is deployed (aka the notary pool) is an implementation detail. Each notary identity that can be used on the Corda Network generally represents a different consensus protocol and/or a different business organization which operates the notary.
When you're using the notary selection API you're selecting which notary identity to use (aka consensus/organization) as opposed to any implementation detail of how the notary is deployed.
Notary selection comes from the network map and you can choose from the list of whitelisted notaries that exist on the Corda Network. Here's a primitive selection that simply gets the first notary: final Party notary = getServiceHub().getNetworkMapCache().getNotaryIdentities().get(0) You can customize this as you see fit to choose a notary on a transaction by transaction basis.
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.