Unlocking Corda <> Ethereum Interoperability Pt 1

Corda <> Ethereum Love

I’ve been a Corda and Ethereum fanboy for a long time. As a Solutions Architect previously at R3 (2.5 years) and currently at ConsenSys (since Sept 2018), the only consistent buzzword every client and partner has requested has been “interoperability.” Every major enterprise wants to avoid silo-ed technology, obsolete stacks, vendor lock-in, and making long-lasting platform choices on any new technology immaturely. However, none of these companies want to go into analysis paralysis, so they either choose one (that they can most easily learn or have hired people who know about it) or build a POC on all of them to do an internal comparison.

It’s not surprising to find that most platform comparisons that larger companies care about tend to be less technical (except for tested performance thresholds) and lean towards adoption, community of developers, cost of specialized developers, integrations, opportunities for new partnerships, and ease of learning.

Both Corda and Ethereum have their strengths in the ecosystem, but I don’t personally consider it a war to claim territory. There will be the “ledger appropriate*” solution for every use case and ultimately the tech stack will be chosen by the same developer platform “preferences” (or fanboys) as you have with databases, OSs, frameworks, languages, etc. (*Thank you, Tim Grant, CEO of DrumG, for introducing the term to the industry!).

To take advantage of both ecosystems, I went on a short research sprint that dissects the architectures of both platforms and finds common components needed for interoperability. The three parts for this series will include:

  1. Review of Interoperability patterns and trust (this article)
  2. Breakdown of Corda and Ethereum Components to see where common shared services can be built (with focus on identity/permission/asset control)
  3. Comparison of existing identity/permission solutions with proposals of different joint efforts

Note: These diagrams and descriptions represent my personal assessment of the Corda and Ethereum platform and do not represent r3’s or ConsenSys’s view. The publishing of this article also does not represent any formal partnership between r3 or ConsenSys.

Relevant Interoperability Research

Back in 2016, Vitalik helped write an interoperability research paper for R3 that was published with the following generic patterns:

Vitalik’s Conclusion from a 2016 Interoperability Research Paper

Even from 2016, these patterns are eerily still accurate to the techniques approached by most companies today. Layer 2 solutions with relays to ERC-20 issuances and general lock/unlock mechanisms to prevent double spend across chains are very relevant to the direction of hybrid chains and blending of Intranets to Internet.

Broader Interoperability Patterns

To further extend Vitalik’s work, myself and Clark Thompson wrote some generic interoperability patterns that can be achieved between two parties (just ledgers) and three parties (2 ledgers and a trusted third party/oracle). A summary of these patterns are provided here:

High Level Interoperability Patterns Summary

These patterns, while not exclusive, tend to summarize most approaches towards synchronizing across multiple ledgers via a known trust, standard, and messaging mechanism. More details of these patterns follow:

Pledge/Redeem Pattern

Standard Pledge/Redeem transaction patterns allows for asset transfers between ledgers (traditional to blockchain-held assets). This model requires collateral to be held off-ledger and the lock-unlock mechanisms to prevent double spend on one ledger as it’s being used on another. Trust in this case is stored with the encumbrance agreement.

Feed Event Pattern

Standard 2-ledger patterns of a Feed Event model means one ledger holds a master. A request/reply pattern allows for confirmations from Ledger B to A on changes. A push or notification model can be implemented with durable message queues to guarantee transmission.

Shared Registry Pattern

Another pattern for 2-ledger interactions include a Shared Registry set of rules. Either Ledger A or B can lead the update, but both parties must confirm changes made to the shared views.

Translation Table Pattern

The last 2-ledger interaction pattern includes a Translation table agreed upon between ledgers. Here, Ledger A and B can have different mechanisms of storing the data, but the Translation Table provides clear mappings of fields and formats.

Oracle-Led Pattern

If involving a 3rd party, this trusted component (or Oracle) can provide updates pushed to both ledgers. The component can push to all ledgers in a publish/subscribe methodology as through a MQ service, or a seed ledger can use the standard mechanism of sharing updates from master to slave.

Address/ID Sharing Pattern

An oracle pattern can also have permission to update ledgers by providing the specific shared IDs. This authoritative push of data or formats are usually observed with Shared Registries for reference data.

Common Consensus Pattern

Two parties reaching consensus on a set of agreed upon actions can also be done by signing the agreed changes prior to making changes. This follows the flow framework supported by Corda where the request for change is seen as a partial Transaction that gets signed by all parties before it’s committed to each ledger.

Where’s the Trust?

Trust is particularly important with shared infrastructure components. The following table provides an overview of where trust is distributed in order to think about implications of new or shared components within an identity context.

Trust Implementation Matrix for Identity

All patterns indicated must have trust placed somewhere. Even in Bitcoin, all full nodes and users trust the software doesn’t have a glitch or a way for it to be compromised within the rules of the running network.

If the project is to create interoperability between Corda and an Ethereum client, there will fundamentally need to have some agreement on the standard and a known registry of network identities.

If the Corda Network and Ethereum Network forms a level of trust, then technically a Corda node would only need to run a CorDapp that provides an Ethereum address identity. If there’s a bridging component like a DID model for users then different groups can agree upon using the same identity service and standards.

On the last column with respect to legally bound contracts, I’d also add that a shared legal mapping may seem most feasible. There will need to be a level of cross-ledger monitoring or trust around the e-Signature identity on both ledgers, but there are benefits to defaulting to a standing legal framework.

In Part 2, we’ll breakdown Corda and Ethereum components and propose some shared common services.

Clemens Wan is a ConsenSys Global Solution Architect on the Solutions team. He specializes in blockchain enterprise deployments and corda architecture in the capital markets, trade finance, insurance, legal, and regulatory industries.

Before Consensys, Clemens spent 2.5 years at R3 as a Director leading Solutions Architecture Design completing 40+ industry designs on Corda, tech advisor for 10+ projects, and leading initiatives in smart contract development, CBDCs, platform comparisons, dev collaboration, client engagement, security, and scalable operation strategies.

Solution Architect @consensys and "guy that likes to write lists of 30"