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.
Related
I am trying to understand the applicability of pluggable consensus in corda.
For example, the consensus service from hedera hashgraph can be plugged into corda,technically. But I am not clear why it is needed?
Can anyone help me in understanding with an appropriate business use case?
Corda is an incredibly powerful toolkit for building business networks in a distributed manner. One assumption of Corda today is that it depends on either a centralized notary, or the need to configure a network of notaries, in order to provide uniqueness consensus of the Corda transactions.
The Hedera Consensus Service addresses this dependency. Rather than building a cluster of notaries, or trusting a single notary, transaction hashes can be sent to the Hedera Consensus Service which provides a consensus timestamp of the message by the globally distributed Hedera Mainnet. Any notary or member of the Corda network can independently verify the timestamp. This can provide a more decentralized and resilient infrastructure, as well as reduce the operating burden and cost of configuring the Corda network.
More information can be found on the corda notary here: https://github.com/hashgraph/hedera-hcs-corda-demo
Corda doc says
"Admission to the network
Unlike traditional blockchain, Corda networks are semi-private. To join a network, a node must obtain a certificate from the network operator. This certificate maps a well-known node identity to:"
I have a few questions about how corda netowrk is desined.
How network is partitioned.
Can all corda instance form one network? Or, are there several networks that can be connected?
Who is network operator?
Is it one party? Can that operator dominate network arbitrary?
Is Notary included in network?
Is Notary a component of network, or can notary notrize several corda netowrks?
Does network operator authorize notary, or trust notary?
A Corda network is a set of well identified legal entities. When you want to join a network you sign a legal document (participation terms of use) and then you submit something called Certificate Signing Request; once it's approved your node automatically downloads the required certificates that identify it on that network and allows it to become discoverable by other nodes so it can interact with them.
Corda network is an example, and I recommend that you go through their website: https://corda.network
In the case of Corda network, the operator is a consortium; not one organization.
That link I shared, will answer all of your questions:
Participation: https://corda.network/participation/index
Governance: https://corda.network/governance/index
Types of networks in Corda network: https://corda.network/participation/network-choice
Notary: https://corda.network/participation/notary-considerations
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.
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.
I have set up Akka.net actors running inside an ASP.net application to handle some asynchronous & lightweight procedures. I'm wondering how Akka scales when I scale out the website on Azure. Let's say that in code I have a single actor to process messages of type FooBar. When I have two instances of the website, is there still a single actor or are there now two actors?
By default, whenever you'll call ActorOf method, you'll order creation of a new actor instance. If you'll call that in two actor systems, you'll end up with two separate actors, having the same relative paths inside their systems, but different global addresses.
There are several ways to share an information about actors between actor systems:
When using Akka.Remote you can call actors living on another actor system given their addresses or IActorRefs. Requirements:
You must know the path to a given actor.
You must know the actual address (URL or IP) of an actor system, on which that actor lives.
Both actor systems must be able to communicate via TCP between actor system (i.e. open ports on firewall).
When using Akka.Cluster actor systems (also known as nodes) can form a cluster. They will exchange information about their localization in the network, track incoming nodes and eventually detect a dead or unreachable ones. On top of it, you can use higher level components i.e. cluster routers. Requirements:
Every node must be able to open TCP channel to every other (so again, firewalls etc.)
A new incoming node must know at least one node that is already part of the cluster. This is easily achievable as part of the pattern known as lighthouse or via plugins and 3rd party services like consul.
All nodes must have the same name.
Finally, when using cluster configuration you can make use of Akka.Cluster.Sharding - it's essentially a higher level abstraction over actor's location inside the cluster. When using it, you don't need to explicitly tell, where to find or when to create an actor. Instead, all you need is a unique actor identifier. When sending a message to such actor, it will be created ad-hoc somewhere in the cluster if it didn't exist before, and rebalanced to equally spread the workload in cluster. This plugin also handles all logic associated with routing the message to that actor.