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.
Related
Network:
PartyA, PartyB, PartyC, Notary
Scenario:
PartyB’s node is put into draining mode.
PartyA performs a transaction where PartyB and PartyC are
participants (not signers)
Outcome:
PartyA completes the transaction, gets the notary’s signature and
saves the state in its vault.
PartyB will not be informed of transaction (expected)
PartyC will not be informed of the transaction (surprise!)
Learning:
I assume because PartyC is listed after PartyB in getParticipants() it has to wait until PartyB is back online before it will receive the transaction. This is unfortunate because PartyC gets punished because PartyB’s node is down.
Question:
Is this just a limitation of the open source version of Corda? Would Corda Enterprise behave the same way?
Thoughts:
It may be necessary to clearly inform the users of your CorDapp about this phenomenon because it creates a condition of asymmetric information that is caused by some other node on the network.
It is a limitation of Corda Open Source. The FinalityFlow of Corda Enterprise (up until 4.x) sends the transaction - after notarisation - to all the peers and resolution is performed in parallel for increased performance. In Corda Open Source it is done in sequence.
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.
I set up a network with 2 normal Node (NodeA and NodeB) and 1 Notary. If NodeA has shut down and lose apart of its database (about current states), how can We ensure that the network may run as well. And how does NodeA restore this data that loss? (Can Enterprise Corda Version help me in this case?)
When a database admin deletes your data, Corda will not be able to help you. You are responsible for your own database. You need to ensure that only authorized parties have permissions to access the database.
Let's say that PartyA now does not have latest states/ data for your custom tables. In this scenario, PartyA can request PartyB for this missing state if PartyB was also a participant to the state. It depends on PartyB whether to share this state to PartyA.
There is a built in flow to send the state from one party to other
SendStateAndRefFlow(otherSideSession: FlowSession, stateAndRefs: List<StateAndRef<*>>)
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.
We need to change our Corda Network infrastructure. Currently we are working with one network map, three notaries (RAFT) and four additional nodes.
We will replace our network map and one notary server (notaryCluster one) with new servers.
Our plan is to perform following steps:
1. Stop all Nodes
2. Change all node.conf files needed to point to new networkmap and new notary
3. Deploy Networkmap and Notary service in new servers from scratch (not reusing data from old notary and network map)
4. Start new network map, start new notary servers, and rest of nodes (not old network and notary)
Is this process correct to ensure existing transactions will remain in the systems and will be able to work with them?
Thanks!!
There are several things you need to consider
- Stop all Nodes
You need to consider any flows that are currently in-flight to perform a clean shutdown of the node.
Version 3.1 of Corda adds a "Draining mode" feature, through which:
Commands requiring to start new flows through RPC will be rejected.
Scheduled flows due will be ignored.
Initial P2P session messages will not be processed, meaning peers will not be able to initiate new flows involving the node.
- Deploy Network map and Notary service in new servers from scratch (not reusing data from old notary and network map)
You would want to keep data from the old notary, else the notary would lose track of states that have been consumed, and the network would lose the guarantee of preventing double spends