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.
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.
According to the Corda Network documentation https://corda.network/participation/distinguishedname/
A X.500 must be unique within Corda Network. The combination of O and OU are used for the uniqueness check, and the other fields are considered as attributes of the identity.
Is this uniqueness check specific to the Corda Network or does it also apply to private Corda Networks? Within the Corda Network is it unique across all zones?
If not then what are the X500 name uniqueness checks for X500 names of:
CENM networks
Bootstrapped networks
The uniqueness check is enforced on any network, including the Corda Network (tCN) and any other private Corda Networks. And it needs to be unique across all zones.
That is, the X500 names need to be unique across zones regardless of deploying on the tCN or any private network (using CENM or bootstrapper).
The reason is that the same identity manager is used for all zones across the network and the uniqueness is checked on the identity manager level. Also, A bit future thinking on the network, clients might consider subzone merging / cross-zone interop, and etc. So this grants them the flexibility and ability to achieve that in the future.
To further address your questions: How would you enforce uniquessness checks on bootstrap network and CECM networks?
The CENM Identity Operator will have built-in checking to enforce the uniqueness check. With newtwork boostrapper, there is no uniqueness check, so use it with caution.
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.
I m referring Can corda nodes communicate when run from different networks?
I am looking at 3.3 opensource cordapp example and could see the certificates are generated automatically while deployment with devmode=true.
Can I get information - whether it is configured with network type as business network or compatibility zone ?
Can I get more information on how to configure as a business network? is there any example?
If you use deployNodes to create your nodes, you create a mini-compatibility zone of nodes running in devMode. Unlike a traditional compatibility zone, you need to use the Network Bootstrapper tool to manually add nodes to the network, rather than using the dyanmic joining process available in a compatibility zone with a central network map service.
A business network is a sub-group within a compatibility zone of nodes operating for a specific business purpose. A node can be part of multiple business networks. You can read more about business networks here: https://solutions.corda.net/business-networks/what-is-a-business-network.html.
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