1. Topics
  2. Interoperability on Corda (exhaustive)

Interoperability on Corda (exhaustive)

Ryan Gledhill
 

I am increasingly fielding questions from clients and industry professionals about the current and future state of interoperability on Corda (RGB introduces the concept with his trademark lucidity here).

Clearly, this is a difficult and multi-tiered question to answer and I suspect the Corda community will be increasingly faced with such questions as a direct effect of the growth of the Corda ecosystem.

I'm in the process of writing a blog post to best collate information. I personally consider interoperability as one of the core tenets of Corda, and a concept which all other permissioned DLT seems to struggle with. As such we should endeavour to outline this effectively as a community to best aid clarity.

Some of the questions below are historical questions from clients and peers and I'd appreciate different viewpoints on them to ensure the post is as comprehensive as possible:

  • CorDapp Interoperability
    • Best practices, designs and architecture patterns to allow interoperability between disparate CorDapps
    • How can I be sure my tokens are natively interoperable with other tokens?
  • CorDapp data sovereignty between apps within the node.
    • How can I be sure a CorDapp's vault data isn't queried by other CorDapps installed within the node?
    • Building upon the above question, how do we prevent data leak when combining assets within a transaction? Let's say, cash for a bond - both chains of provenance are needed to verify a transaction. (Tear-offs/SGX?)
  • Corda Network and Business Networks
  • DLT & network interoperability projects


Apologise for the lack of brevity in this post, feel free to amend or add questions!
Clemens Wan
 

Hey that's me. I have also written one about Ethereum <> DAML integration that I havent published yet, but happy to share.

The 4th post of my series was planning to be Interop via legal anchor using openlaw. Here's a blogpost on openlaws finance toolbox - “Build an Open Investment Bank Using OpenLaw” by OpenLaw https://link.medium.com/J8JmqPdNVY

If you're talking permissionless Interop, it'd be important to look at the public projects like cosmos, polkadot, and clearmatics. The design patterns match what I've outlined.

On Tue, Aug 6, 2019, 7:33 AM Ryan Gledhill <ryan@...> wrote:

I am increasingly fielding questions from clients and industry professionals about the current and future state of interoperability on Corda (RGB introduces the concept with his trademark lucidity here).

Clearly, this is a difficult and multi-tiered question to answer and I suspect the Corda community will be increasingly faced with such questions as a direct effect of the growth of the Corda ecosystem.

I'm in the process of writing a blog post to best collate information. I personally consider interoperability as one of the core tenets of Corda, and a concept which all other permissioned DLT seems to struggle with. As such we should endeavour to outline this effectively as a community to best aid clarity.

Some of the questions below are historical questions from clients and peers and I'd appreciate different viewpoints on them to ensure the post is as comprehensive as possible:

  • CorDapp Interoperability
    • Best practices, designs and architecture patterns to allow interoperability between disparate CorDapps
    • How can I be sure my tokens are natively interoperable with other tokens?
  • CorDapp data sovereignty between apps within the node.
    • How can I be sure a CorDapp's vault data isn't queried by other CorDapps installed within the node?
    • Building upon the above question, how do we prevent data leak when combining assets within a transaction? Let's say, cash for a bond - both chains of provenance are needed to verify a transaction. (Tear-offs/SGX?)
  • Corda Network and Business Networks
  • DLT & network interoperability projects


Apologise for the lack of brevity in this post, feel free to amend or add questions!
Farzad
 

Ryan: Thanks for starting the thread - very much resonates with our experience and thoughts. 

Clemens: definitely would like to read your DAML article!

Seems to me that we face similar issues in the incumbent world. After all, there isn't a single representation for Fiat. There are protocol schemas, with some notions of standards but not consistently so. Converting from one to the other is the responsibility of entities that can be best described as gateways (with disparate pricing, latencies, service level agreement, atomicity issues, bespoke rollback mechanisms etc).

With regards to fully automatic interop, an abstract and declarative modelling language that encompasses all aspects of state, verification, and protocol will be the way to go in my view. Easier to compile or interpret such a language over a Turing machine, than attempt to attempt to "decompile" existing imperative contracts.

Kind regards,
Fuzz

On 6 Aug 2019, at 12:57, Clemens Wan <clemens.wan@...> wrote:

Hey that's me. I have also written one about Ethereum <> DAML integration that I havent published yet, but happy to share.

The 4th post of my series was planning to be Interop via legal anchor using openlaw. Here's a blogpost on openlaws finance toolbox - “Build an Open Investment Bank Using OpenLaw” by OpenLaw https://link.medium.com/J8JmqPdNVY

If you're talking permissionless Interop, it'd be important to look at the public projects like cosmos, polkadot, and clearmatics. The design patterns match what I've outlined.

On Tue, Aug 6, 2019, 7:33 AM Ryan Gledhill <ryan@...> wrote:

I am increasingly fielding questions from clients and industry professionals about the current and future state of interoperability on Corda (RGB introduces the concept with his trademark lucidity here).

Clearly, this is a difficult and multi-tiered question to answer and I suspect the Corda community will be increasingly faced with such questions as a direct effect of the growth of the Corda ecosystem.

I'm in the process of writing a blog post to best collate information. I personally consider interoperability as one of the core tenets of Corda, and a concept which all other permissioned DLT seems to struggle with. As such we should endeavour to outline this effectively as a community to best aid clarity.

Some of the questions below are historical questions from clients and peers and I'd appreciate different viewpoints on them to ensure the post is as comprehensive as possible:

  • CorDapp Interoperability
    • Best practices, designs and architecture patterns to allow interoperability between disparate CorDapps
    • How can I be sure my tokens are natively interoperable with other tokens?
  • CorDapp data sovereignty between apps within the node.
    • How can I be sure a CorDapp's vault data isn't queried by other CorDapps installed within the node?
    • Building upon the above question, how do we prevent data leak when combining assets within a transaction? Let's say, cash for a bond - both chains of provenance are needed to verify a transaction. (Tear-offs/SGX?)
  • Corda Network and Business Networks
  • DLT & network interoperability projects


Apologise for the lack of brevity in this post, feel free to amend or add questions!
Mike Hearn
 

No need to apologise Ryan, you're much more concise than I am!

Best practices, designs and architecture patterns to allow interoperability between disparate CorDapps
These are still coming together, I guess. Some of them are the same as any Java "interop" i.e. library / API design. The main area of focus for us at the moment is upgrading the security of dependency handling between apps because that's a subtle razor edge, but we think it can be fixed 99% transparently to developers.

We really badly need a design patterns section of the docsite. One pattern we've found useful is to split flows in two. The "inner" flow is inlined and expects an active session to be handed to it. It's designed to be incorporated into other apps. The "outer" flow is designed to be started by users via RPC or the shell, or due to invocation by another peer, and simply invokes the inner flow. That way the logic can be used inlined or at the top level.

How can I be sure my tokens are natively interoperable with other tokens?
Beyond using the tokens SDK I'm not sure we have much on this for now. Probably business issues are going to dominate the technical issues, e.g. how widely trusted is the issuer? It's the same as the notary problem - everyone has to agree that an issuer is trusted to use that token.

How can I be sure a CorDapp's vault data isn't queried by other CorDapps installed within the node?
You can't at the moment. Apps aren't sandboxed so to install it is to trust it. If you aren't sure you can trust it, read the code and compile it yourself.

It'll probably remain that way for a while, as it's a lot of work to change this and I guess there are higher priorities. If enough customers ask for app sandboxing perhaps we'll start on it but it could take a long time to deliver, and apps would need to opt in. Also consider that apps querying each others tables is a key part of how you can make interop work well!

Building upon the above question, how do we prevent data leak when combining assets within a transaction? Let's say, cash for a bond - both chains of provenance are needed to verify a transaction. (Tear-offs/SGX?)
Our party line on this is SGX, which is ticking along quite nicely. Of course it's not only for multi-app txns where this is useful.

How do we share data between CorDapps or within/across Business Networks, or ensure data standards are adhered to?
I think this is the same as the design patterns discussion. You can share data between CorDapps using standard OOP design principles. Get people together, agree some Java interfaces, and then try casting stuff to those interfaces to see if they conform to the standards.
1 - 4 of 4