Using Party object constructed manually from extern keys

(Philip) #1


Still toying with the framework, so I apologize if this has been answered already. Can Party object be constructed manually, or does it have to be from one of the running nodes?

I have a Party object created from external key pair and passed into IssueCash command. It is throwing Don’t know about party ABC when the flow is triggered. if I switch to a Party object created using name of a running node, then everything is fine.

Please advise, thanks!


(Roger Willis) #2

Hi Philip,

How come you are using an externally created key pair? The party object is a name CompositeKey (pubkey) tuple. Does the name correspond to a node which is registered with the network map service?

The idea is that you grab the Party object from the a NodeIdentity which is stored in the NetworkMapCache (which is a snapshot of the NetworkMapService).


(Philip) #3

Thanks Roger.

I suppose this is what I have in mind: I would like to run a node BANK and to issue some cash assets on that node. However, I do not want BANK to be the owner of these cash assets. Rather, these cash assets should be owned by users from an external system and represented by external key pairs. The node BANK can be the issuer in this case, and it would “create" cash to other users who are not running as nodes.



(Roger Willis) #4

Ah I See. Remember that when using Corda on a production network all nodes are required to register with a gateway and obtain a certificate. No certificate ==no transacting with other nodes, so do bear this in mind. Those keys which you are sending the cash to should be attributable to a Corda node which can transaction on the network.

Also bear in mind that you probably want the owner to be notified that they have some cash in their vault. Therefore, would be useful for the node owning those keys to be online. Perhaps your customers could use a proxy node?

(Philip) #5

Thanks Roger.

Could you please elaborate on the idea of using a proxy node? Can a node hosts multiple key pairs and register them with the identity service?

(Roger Willis) #6

Sure, at present nodes can only generate one key pair. However in the future they will be able to generate multiple key pairs in a hierarchal fashion on a per transaction basis. It follows that nodes can support multiple users / departments in this way.

Currently, there is a 1-to-1 relationship between nodes and identities, though I’m aware this will likely change in the near future as Corda draws closer to V1, therefore nodes will effectively be able to support multiple user accounts. Of course, these users will have to trust the “proxy” node. This is perhaps similar to hosted Bitcoin wallets or running a “Thin” client and relying on “Full nodes” for tx verification.

(Mike Hearn) #7

Identity and key management is one of the least fleshed out parts of Corda so far. We will be doing a lot of work on it this year.

A higher level description of your goals would be very useful for us. Is the intention that assets will be legally and technically owned by a customer who does not want to/cannot/will not use Corda directly? If so, how do you plan on the signing process working?

(Philip) #8

Hi Mike,

Here is my situation.

Let’s say I have a platform that trades financial assets and registered users can wire in money from their bank accounts. Without introducing breaking changes to the existing system, I would like to run a Corda network in parallel and swap in the ledger functionality piece by piece.

I want to record the fact that user A has transferred in $500, and I imagine I should do this with Cash().issue command. This is where the question with owner key pair comes up. Preferrably, I would like to sign this issuance with user’s own key pair.

This is just one of the many things I would like to try out with Corda. For now, I created a pseudo Cash contract that encapsulates user’s info (i.e user id, username), and issue that asset instead. Not sure if this is the right approach, and feel free to point it out if not.

In short, the assets should be legally owned by a user, and technically owned by the platform.



(Mike Hearn) #9

Got it, thanks.

Technical ownership depends on who has the private keys. So, you’d keep the keys.

For the case of separating issuances by origin user, there are a couple of different ways to do this:

  1. Use the reference field of the issuance to store a (possibly encrypted) join key with your own internal data. Issuances with different references are not fungible and thus you can assured that these references will survive as the states are passed around, split, merged, etc. Then when it comes time to exit the states from the ledger, you can look up the user account that is linked to those states using the reference field.
  2. Set the reference field of your issuances to zero and just track amounts yourself. Basically treat all money on the ledger as if it were one big pool and track in your private tables which accounts hold a claim on those pools. The advantage is that the states are more fungible and that you don’t have to deal with the references. Disadvantage is perhaps it complicates the accounting on your side.

At the moment the platform has limited support for helping you with the reference field. It’s an opaque binary field so you can encode whatever you like into it. A nice future feature to add would be transparent encryption/decryption of the contents. The reference field is inserted into the relationally mapped tables (e.g. for cash) so you can already use it as a join key if you make it opaque, like by just picking a large random number.

(Philip) #10

Thanks Mike. This is very useful!