How to scale a Corda Node horizontally? - corda

I would like to understand if it is possible to scale a Corda node out horizontally and how this would work.
I have read that the message broker is planned to be separated from the Corda node which I guess would allow for horizontal scaling. Would the message broker be the entity that is identified by the network map service or would each of the underlying Corda nodes still have their own separate network identity and vaults?
My question is for v1 open source, Corda enterprise or if it is planned for future releases.

We have some work in progress here related to the flows and we'll talk more about this in the very near future. But in the current open source 1.0 branch it would be a scale up model. You could scale out the Artemis MQ however. But it would be a single node for Corda at the moment.

Related

How to block flows from other nodes on Corda network?

My dev node is part of the Corda test network, and when I open the logs I see something like (node etc..sent you a flow which you don't have installed, you can kill it with kill flow). So I have 2 questions:
How do I reject these calls? I know the purpose of being part of the Corda network is to have the ability for CorDapps of different orgs to transact, and I don't want to go with the segregated network model (because it's more expensive for prod and pre-prod Corda nets).
Can a node on the network perform a DoS (Denial of Service) attack by sending me flows that I don't have installed and eventually bringing my node down?
I'm not sure if I'm right about my answer but as far as I know Corda Network is designed on a need to know basis and I know that you are aware of it and I was having the same doubt when I first started with Corda but I found out that one can simply block a node from sending you any undesired flows which could cost you unnecessary CPU runtime. The explanation to this is given in this link.
Apart from this I have gone through a Medium Post which explained about ResoponderFlow validating information passed through flows and one of the points mentioned over there was to verify the identity of the flow initiator(so as to find if we need that flow),which can't be done within a contract so it needs to be done inside a flow.
Also one can't keep flooding a node with a flow because it contains a timeout,maxRestartCount and backOffBase which really help in determining how the flow is getting propagated across the network.
I hope this helps you to construct a solution to your doubt.

How can Corda be safely forked and remain compatible?

When building on open source Corda how can I make changes to the project in way that the Corda node will continue to be interoperable with nodes built on standard open source Corda?
The concern is that by forking Corda I may inadvertently change the Corda protocol such that my node can no longer communicate with other nodes. For example: changing serialization could break the p2p messaging between nodes.
In addition: does the network the Corda node run in affect how much I can modify a forked version of Corda? For example:
What if the forked nodes are running in a private network where all nodes are under my control.
What if the forked nodes are running in the Corda Network where other nodes are using standard versions of Corda.
If you run in the Corda Network then the relevant policy is this one:
https://corda.network/policy/protocol-definition.html
Zone members agree that their nodes will understand the Corda protocol as defined by the open source reference implementation, of at least the version specified in the network parameters’ minPlatformVersion field or higher.
So you can modify your node as long as it still understands how to speak with other nodes. This is a fairly lax definition. You can change a lot without breaking that requirement. But it sounds like you already know what to watch out for - changing serialisable types, mostly. It's up to you to ensure you don't deviate from the protocol.
In your own networks you can of course do whatever you like. It's open source after all.

Clarification on corda network type of cordapp example

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.

CORDA booting in my world

Background-
I am extremely new to CORDA and Blockchain Platform. In the past few months i have had my share of experience working on a small project on Ethereum as platform. Ethereum blockchain was leveraged as ledger to mark Transaction as a proof of existence. It means for some action (success/failure) we have marked respective transaction on Blockchain. We may consider it as a proof of concept to show knowledge of interaction with nodes running on Ethereum Blockchain.
Infrastructure - Node.js web services, two ethereum (PoA) nodes
Question-
I would now like to port this running example on to CORDA blockchain. How would i achieve this with bare minimum changes. That means if i have a Corda network with two nodes running on my system and i want my web services to connect to one or both of the nodes and save the transaction (in its state). I understand that this certainly is not what CORDA might be meant for. Consider this question as my first step to interact with CORDA from Node.js web services.
Any inputs highly appreciated.
I recommend you go through the documentation first. your Tx will be a state. you need to build contracts and flows for a Tx to happen. Tx will happen using flows which will be initiated using Crash Shell or RPC Client. AFAIK, this client is in Kotlin or Java. so you'll have to create a JAVA or Kotlin application to instantiate this client. now in the Java application, you'll have to expose rest endpoints to communicate with the client which will initiate your flows. you can call these rest endpoints from your node application. All this has to be created in CodaApp. This is the bare minimum.
I just found there is a library.
look at this: https://gitlab.com/bluebank/braid
This can help you.

Is there a way to know the status of a node using the network map service?

Looking through the documentation I can't find a way to get the current status of the nodes (online/offline) using the network map service.
Is this already implemented?
I can find this information using OS tools but I would like to know if there is a Corda way for this task.
Thanks in advance.
This feature is not implemented as of Corda V3. However, you can implement this functionality yourself. For example, see the Ping Pong sample here that allows you to ping other nodes.
In the future, it is expected that the network map will regularly poll each node on the network. Nodes that did not respond for a certain period of time (as defined by the network operator) would be evicted from the network map. However, this period of time is expected to be long (e.g. a month).
Please also note that:
In Corda, communication between nodes uses message acknowledgments. If a node is offline when you send it a message, no acknowledgment will be received, and the node will store the message to disk and retry delivery later. It will continue to retry until the counterparty acknowledges receipt of the message
Corda is designed with "always-on" nodes in mind. A node being offline will generally correspond to a disaster scenario, and the situation should not be long-lasting

Resources