Re: Mobile corda node

Mike Hearn

Hey Janis,


There are some people doing a project related to mobile cash with Corda – perhaps they’ll introduce themselves on the list. I think they are using the RPC client approach.


There’s an incremental path here that looks a bit like this:


  1. Sample app that shows how to authenticate to a Corda node, start flows and monitor them from an Android app, how to hook the ProgressTracker into the UI and so on. Also how to proxy the connections on the server side to the node. Docs showing how it all works. Not hard.
  2. Maybe a Bitcoin wallet style app for cash-on-ledger, of course, not really useful unless there are actual issuers but might be a fun demo. Still just an RPC client to a cloud node.
  3. Implement the human interaction design docs (see other thread with Tomas) and make an app that knows how to sign transactions with keys held in the local keystore, knows how to assist users with backing them up etc. Make phones into tx signing devices.
  4. Want to run a node on your phone? Yes, there’s a path to getting there:
    1. Add support for Android SQLite in addition to H2 as a database backend, optimise the hell out of it - node startup is way too slow for Android currently mostly because of Hibernate. Turn the node into a library (again… that’s how it started life).
    2. Allow personal identity certs. Probably a case of defining an X.500 schema for the production Corda zone that allows phone number or email address based identities, and teaching the main zone how to verify phone numbers using SMS/phone calls. Backwards compatibility needs to be considered.
    3. Improve DoS resistance. Currently Corda has non-member-on-member DoS attacks in scope but not member-on-member. There’s an implicit assumption hidden in the “run Corda on mobiles” requirement that you can scale the large numbers of consumer users sharing a zone with highly sensitive business nodes. We’d probably need to ramp up the defences before that makes sense.
    4. Attack and solve the Corda/mobile network messaging problem. See below. After these things are done, now it becomes actually feasible to run a first class Corda node on your phone. At this point we could truly say the Corda network has become a P2P network of the same level of openness and scale as email, the web, etc.


Node-to-phone messaging can be done in several ways.


The ’best’ way in the absence of carrier policies would be to exploit Corda’s tolerance to node outages. If your mobile network supports IPv6 and lets you open ports, you can simply have a background task on the phone that checks your assigned IPv6 address every so often and pushes a new entry to the network map when it changes. If your address changes as you roam, nodes elsewhere on the network will fail to connect and messages will start to buffer up on their disks, with backoff-and-retry. This is how all Corda nodes work already, it’s nothing new. If your address is stable enough and direct connectivity is possible, this is an efficient and simple way to do things. For instance if your device spends most of its time on wifi to consumer internet connections (like at home) you’re good.


But of course most networks are broken / NATd / firewalled and won’t let devices take part in p2p networks. That might change one day – with IPv6 it’s no longer a strong technical impediment but rather, ‘just’ a matter of security policies. It doesn’t really benefit any of the big players to be routing so much traffic through Google and Apple datacenters, not even Google or Apple – it’s a pure cost center for them. Direct routing when possible as an optimisation is in everyone’s interests, so it may happen eventually.


Still, today you need an alternative.


The most effective way would be to implement end to end encryption in the wire protocol, and allow identity keys to sign “proxy permissions” that grant third parties the right to announce themselves as the owners of your identity in the network map. A simple implementation would receive messages and forward them onto the Google/Apple store-and-forward networks (GCM). Nodes would open outbound connections directly. A mobile node could then generate keys, register its phone number as its identity WhatsApp style, and proceed to start receiving and sending messages. The OS wakes up the node when a message arrives on a flow and is waiting to be processed.




Join to automatically receive all group messages.