Re: Need to know on network map

Avery Starr

Thanks Mike!


Our network is not a democratic network so we don’t have the philosophic issue of power struggle. The participants in the network are strictly managed and signed roles to play. We use both centralized application/server and Corda to take the advantage of both: the centralized application manages complicated business relationships, business processes, roles, and identity; the trading activity happen on Corda and therefore we gain the shared ledger and traceability.


Revealing IP would not be ok in our network as it is too easy to guess or to programmatically figure out the identity should there be bad actors in the network. We have banking accounts of our participants connected with the network too so we need to be very careful.


Regarding corporate firewalls, we could possibly request all nodes of the corporate participants being installed on a web server outside the firewall so we don’t have to worry about fighting with different versions of corporate firewalls. If we do that, the nodes will have to interact with each other on HTTP instead of RPC right? I recall Corda implemented HTTP too. Our current code is using RPC calls.  


So is there still anything in Corda we can leverage to implement our Private  Network Dispatcher? Or maybe we could take Corda’s Network Map and modify the code and make it fit in our scenario? If that is doable, what about future Corda upgrades? If that is not doable, how about we simply just develop a piece of software on our own that will feed each node the contact info of their counterparties on-demand? Is this approach going to break anything in Corda though so it will give us headache when Corda updates in the future?  




From: <> On Behalf Of Mike Hearn via Groups.Io
Sent: Wednesday, September 11, 2019 4:48 AM
Subject: Re: [corda-dev] Need to know on network map


If you're running your own network, you could initialise every node with a randomised Corda identity that gives away nothing about who they are, e.g. is a UUID. Then you implement your own protocol (or flow) to resolve user input to that randomised identity. The resolution must return zero results if the user input is even slightly wrong, for the reasons discussed above, so your own notion of business identity would need to be constructed with that in mind (e.g. check digits, if using numbers).

The advantage of this approach is you don't need to modify Corda. The disadvantage is nodes can see how many participants exist in the network and their IP addresses, but wouldn't know who owns them. The mere existence of an IP address in the system may still reveal too much information for you though.

The problem with wanting to be compatible with corporate firewalls whilst still hiding possible IP addresses is, as JC observes, that some companies want to whitelist IP addresses in advance. This isn't compatible with being peer to peer and also not knowing who your peers are.

Another way to do it is as above, but with the addition of a VPN. Everyone VPNs to a central point you administer and is allocated an internal IP address, so IP ownership is secret and corporate firewalls can whitelist the VPN endpoints. The network map would still reveal the number of participants in the system but nothing else. You can fill it with dummy entries if you want to hide the size of the system.

At this point though, it may not be entirely clear what balance of power you're wanting to achieve. The central party would control all user interactions, would see all business relationships and could probably change node's public keys to impersonate them without anyone noticing. Availability would be identical to a centralised system. What powers do you want users to have in your system? Perhaps there's a more direct way to achieve it.

Join to automatically receive all group messages.