When a single node in a consortium or a consortium as a whole runs the notary service, how can trust be established between the nodes in a consortium?
How can one node trust the other node to run the notary?
In the case, where the notary is a 3rd Party, how does all the nodes in the consortium come to an agreement to choose this 3rd party to run the nodes?
Thank you.
It will often be the case that there is no clear node or pool of nodes that can be absolutely trusted to run a notary pool.
In that case, the notary pools should be set up as follows:
They should run a byzantine-fault tolerant algorithm. This prevents nodes in the pool from maliciously giving bad consensus results
They should operate in non-validating mode. This prevents nodes in the pool from seeing the contents of the transactions they are deconflicting
With this set up, there is no need to trust the nodes in the notary pool.
Choosing the nodes for these pools would be a network governance matter. In all likelihood, a pool of standard technology service providers will be paid to run a BFT, non-validating pool.
Related
I am using a Fabric 2.2 network with two organizations, one endorsing peer per organization and one ordering service.
I want to scale up my network with many clients and servers in order to test the performance of the system (latency and throughput), similarly to what it is done in this paper ieeexplore.ieee.org/iel7/69/4358933/08246573.pdf in section 6.1.2
I confuse maybe the terms. I am really new to Fabric.
What is the meaning of "clients" and "servers" in the paper? Are they ca-servers and ca-clients? In this case, how to configure a network with an increasing number of Fabric clients and servers?
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
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.
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