I am relatively new to Corda and stumbled upon a question that I am not able to find a clear answer to.
In my understanding a CorDapp is the entirety of Contract,State and Flows regarding a specific Use-Case.
Would it be possible to have different CorDapps running on different nodes?
For example in a network with 3 participants A,B and C where A&B need to interact with eachother and B&C need to interact with eachother with a different Use-Case. Can A&B have the CorDapp for their Use-Case running without C having it installed on their ledger?
Basically the question is, if all nodes on the network have to share all CorDapps no matter if they interact with eachother or not.
Thanks in advance
Florian
Yes, it is definitly possible and one of the main advantages, from my perspective, of a Corda. In Corda, nodes only need to have the CorDapps relevant to the them. In your example, A and B would only need to have the CorDapp for payables product, as an example, and C would only have receivables product.
In addition, there is also a possibility for all CorDapps to be installed on a single node, but access to them can be managed on the Client Service application (e.g. Spring Service that communicates with Corda Node)
Related
Generally, we do not have peers concepts in Corda. We always call them as nodes. How to create multiple peers (nodes) for single organization (Party) in Corda?
Technically, you can register as many peers (nodes) for the same organization. As long as, you let your counterparties know that those X509 names belong to your organization.
But, keep in mind that your peers cannot share from the database level, meaning that if peerA received some info from an external party and stored at its vault, PeerB cannot just go into peerA's vault and use it for its transactions.
That is, PeerA and PeerB are entirely different parties on the Corda level. If you want to share some information, you need to do a Flow. This is to protecting provenance and immutability of the ledger.
Looking into the future, our dev team is implementing a new accounts feature. It will be released with Corda Enterprise 5. This feature allows having multiple accounts under the same node. If you would like more information join the slack channel and ping me #http://slack.corda.net
I need to develop an enterprise grade permissioned based blockchain application using Hyperledger fabric. To start with, I would like to understand how I should determine number of nodes required. Basically every organization will have one peer node that will process all the transactions. Apart from this reason, do we need nodes for anything else and how many of them? From architecture perspective, what aspects I need to consider?
Each node can have some of this functions (router is a must):
router
full blockchain
wallet
miner
Since you're speaking about "one node per organization", you probably mean one "full" node per organization, meaning each organization will have a miner node, containing full blockchain locally.
The problem here is this: how can you guarantee each organization in your architecture will have the same mining power?..
If I develop an online application using Blockchain and I have three parties(or peers) required to reach consensus then Do I need a node for each of the three participants or the one node is enough. what I am not able to understand is how I will maintain a node or nodes.
I will be maintaining the database at one location?
First understand that blockchain architecture is not as normal client-server architecture.
In normal client-server architecture, client can change entries that are stored on a centralized server. By changing master copy, whenever a user accesses a database, they will get the updated version.
This is not at all the same as with blockchain technology.
A blockchain is a mesh network of computers linked not to a central server but rather to each other. Computers in this network define and agree upon a shared state of data and adhere to certain constraints imposed upon this data. For a blockchain database, each participant maintains, calculates and updates new entries into the database. All nodes work together to ensure they are all coming to the same conclusions, providing in-built security for the network. Database are distributed across the participant nodes and transactions are immutable.
How the blockchain will maintain different nodes?
Through the use of a peer-to-peer network and a distributed timestamping server, a blockchain database is managed autonomously.
For a production network of three parties (in Hyperledger Fabric we use the term 'organizations') you would likely want to have a network of multiple (2 or more) peer nodes per organization for crash tolerance and increased resilience. You would also likely want to run these peer nodes on different host nodes in different data centers or cloud availability zones.
What happens in Hyperledger Fabric on a private channel block-chain consisting of only two peers if one of the peers is faulty and manipulates it's private block chain?
So the two copies of the block chain will diverge and finally it will be impossible for a consensus algorithm to tell which one is correct.
Is this a valid problem? If so, how would this be mitigated? Would it help to add additional peers to the channel (e.g. placed at a regulator's data center) which are not in control of the two peers mentioned above? Or is there a better solution to tackle this problem?
Adding additional peers to each organization would defend against any single node becoming compromised. Adding additional nodes to the channel(s) at an independent 3rd party (auditor, regulator, or other trusted provider) would be another valid strategy to defend against a counter-party with malicious intent.
The consensus is achieved in the Ordering Service, the Peers are independent from it. I think that they are two different things:
The Peers don't manipulate the Blockchain. They could send incorrect or invalid transactions. The result of the execution of those transactions depends on the Smart Contrac that you have on the Peers, and the Endorsement Policy that you have defined. Then, each Peer sends the validated transactions to the Ordering Service.
The Blocks are created by the Ordering Service, so the blocks will be equal to both peers.
The solution to that issue would be to create an Ordering Service where the orderers are located in additional and independent 3rd party.
Nowadys, the Ordering Services gives you the chance to choose among different Services: two different are developed, a third one will be ready soon. More info about it, here.
I've got an akka application that I will be deploying on many machines. I want each of these applications to communicate with each others by using the distributed publish/subscribe event bus features.
However, if I set the system up for clustering, then I am worried that actors for one application may be created on a different node to the one they started on.
It's really important that an actor is only created on the machine that the application it belongs to was started on.
Basically, I don't want the elasticity or the clustering of actors, I just want the distributed pub/sub. I can see options like singleton or roles, mentioned here http://letitcrash.com/tagged/spotlight22, but I wondered what the recommended way to do this is.
There is currently no feature in Akka which would move your actors around: either you programmatically deploy to a specific machine or you put the deployment into the configuration file. Otherwise it will be created locally as you want.
(Akka may one day get automatic actor tree partitioning, but that is not even specified yet.)
I think this is not the best way to use elastic clustering. But we also consider on the same issue, and found that it could to be usefull to spread actors over the nodes by hash of entity id (like database shards). For example, on each node we create one NodeRouterActor that proxies messages to multiple WorkerActors. When we send message to NodeRouterActor it selects the end point node by lookuping it in hash-table by key id % nodeCount then the end point NodeRouterActor proxies message to specific WorkerActor which controlls the entity.