Unlocking Corda <> Ethereum Interoperability Pt 2
Part 1 of this series provided background on different interoperability patterns and techniques. It’s not a pre-requisite for this article.
Corda and Ethereum were designed with different use cases and requirements in mind. Having expertise on both platforms, I’ve given workshops teaching Ethereum experts Corda and vice versa. Before tackling interoperability of Corda and Ethereum, it makes sense to provide a comparison of these platform components and highlight any interoperability dependencies. After reviewing these two platforms, I’ll review the “common services” that may be explored further for connectivity.
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.
Also Note: To reduce any additional text bloat, please read the description and interop comments within the diagrams. I’ll add in text anything that might summarize the analysis or highlight differences in architecture.
Corda Component Analysis
Corda runs on a permissioned network. Each Corda network (lower case “n”) requires a Doorman (onboarding) service, Network Map (look-up) service, and Notary (Validation). There is an open Corda Network (upper case “N”) which effectively provides multiple Business Networks (e.g. software providers) these shared network services.
The onboarding process, which I’ve always like to call “KYN” (“Know Your Node”), is required to join the global open Network to obtain an agreed upon X509 certificate (node identity). Additional onboarding processes are controlled by each Business Network to join their membership (i.e. subset of Corda nodes running the same CorDapp).
With respect to interoperability on identity, the corporate-level identification will be important here. Most interoperability node solutions tackle this by creating multiple identities while onboarding, or referencing a shared identifier or shared mapping registry.
With respect to interoperability on asset encumbrance, the Notary will be important for noting any spent UTXO states updated within the Corda Network. An additional service may be required to monitor dispute resolution in the case of any double spend across platforms.
Registration into any Corda network actually starts with a Corda Node owned by the company. An unregistered Corda node can exist prior to using the doorman process. It’s the responsibility of your company’s devops team to update any configurations in the node.conf file. For example, tweaks can be made to support Disaster Recovery or High Availability when using domain names rather than static IP addresses.
Observer nodes are still Corda nodes, but may be run by a Business Network in order to keep read-only copies of states shared between participants. This is also a use case for regulators or central banks on reviewing (but not necessarily signing) all transactions between parties.
It’s also important to note that the Corda node acts like a wallet. The creation of a node does not download data from peers (there are no “full nodes”). As with Bitcoin, you only receive Bitcoin if an address sends it to you or through an issuance process with mining rewards.
The node.conf file is a good candidate for adding static information mapping to different network identities. Interoperability node offerings likely extend this configuration for any needed environment variables.
Corda nodes can install multiple jar files called CorDapps. These are usually installed by the devops team for a given Corda node. If you imagine the Corda node being a smart phone, you as a user can choose which CorDapp is installed and when to update it to the latest version. There were proposals for a “CorDapp store” CorDapp which can allow for Business Networks to push the latest version of their CorDapp to their membership nodes. It’s particularly interesting because your states can represent a chain of previously installed versions of CorDapps plus the flow framework can guarantee agreed upon updates of CorDapp versions through signatures.
Within CorDapps, the CorDapp developer writes flows and state information. States are just java objects that can only be changed with a transaction that must be validated true by all involved parties. The governance around the validation is written within the smart contract verify() logic like in Bitcoin rather than direct function calls like in Ethereum. The metadata within the state can be any complicated java object thereby allowing for a flexible set of variables and fields.
The legal hash as a pointer is also included within the state and added to the transaction. This hash can open some possibilities for legal interoperability with published contracts on multiple platforms.
Ethereum Component Analysis
Ethereum runs like a global computer. The set of validators running full nodes receive unverified transactions that propose updates to the shared decentralized ledger. The consensus mechanism within Layer 1 uses Proof of Work, but a permissioned Ethereum network can use other consensus algorithms. The P2P network file similar to the network map contains known seed peers.
Similar to DNS, there’s a smart contract service that provides mappings of Ethereum addresses to known domains for easy reference. Alterations to this concept have been used for different permissioned solutions as with Kaleido’s identity/directory service.
Corda does benefit compared to other platforms by having a single kotlin client with trusted software best practices and version releases. Ethereum, on the other hand, has multiple versions written in every language with varying levels of standards and interoperability. Compatibility with mainnet is often the test of a standard.
Another difference here with Corda is the wallet service. Separate wallet software have been written for different requirements and optimizations on account updates across Ethereum applications. These wallets in Ethereum pushes the responsibility of the KYC creation and key recovery best practices of addresses to the wallet providers or wrapper applications (e.g. exchanges).
At the moment, Corda does not support individual identities created by the node’s parent identity (although there’s a good proposal outlining the Maximus project publicly available).
Layer 2 solutions like Plasma, POA Network, or EOS were created to address scaling, privacy, and gas cost issues for high transaction updates. Like side chains, these solutions can be encumbrances for on-chain assets that effectively use mainnet as a Proof-of-Existence or Certainty-as-a-Service timestamping mechanism. There are Kaleido services in their marketplace that provides a relay or tethering service to mainnet.
Architecturally, it may be possible for either Corda or Ethereum permissioned networks to be the Layer 2 solution for each network. I personally like the use of mainnet for the existing access to liquidity, but it wouldn’t be difficult to link an ERC20 token issuance to a Corda node identity.
Another key pattern here for syncing between layers are bridging oracles. This trusted third party is not just trusted by the participants of a single network, but can also be trusted across separate networks.
Ethereum smart contracts contain a few interesting reusable patterns for creating on-chain permissioning, registries, and governance. For example, you can simplify an ERC-20 smart contract down to their set of function calls that edit the registry of address-to-amount mappings. These contracts can also exist as factory or scaffold patterns that create other smart contracts with set permissions and mappings. The smart contract ecosystem if written properly can become an open library of simple object oriented reusable functions.
As noted in the comments, there are many different ways to utilize smart contracts for representing identity across networks.
Common Services Analysis
The common services hypothesized map functional similarities across both platforms that have not been explicitly explained in the component analysis.
The base common service is network governance. All platforms creating permissioned networks will go through the same process of forming agreements and establishing founding principles. Blockchains are not magical and do not remove legal negotiation and risk reviews on joining networks or taking network responsibilities for common functions. The components listed above are just a small number of considerations when creating a separate consortium or live private network constructed of distrusting parties.
If both networks are to encumber and move assets, then a lightweight agreement will be required on a legal or technical level. For example, a land registry master database provides the trust and certainty that it will not “double book” or “double-encumber” a piece of land for multiple lines of credit. Land is normally used as collateral, and banks/insurance companies normally check these government registries to ensure multiple liens are not taken on a single piece of real estate.
The means of obtaining network governance can be done via a Legal Anchor. There could be legal smart contracts that tie proof of signed legal documents to known addresses for multiple participants to review. If this Legal Anchor were to exist across platforms then the e-Signatures must have verifiable identities linking directly to the known owners.
In the world today, we use emails and trails of proof that the email represents a digital signature of the individual. This can be filled out within profiles or stored in multiple accounts for references. In an ecosystem where one can create an unlimited number of addresses (similar to emails) it may be difficult to provide evidence of the associations to identity without a Legal Anchor.
Within the legal anchor, it will also be important to create a full lifecycle of dispute resolution. Any party that violates the activities outlined in a legal agreement should be able to file a dispute and report on the actions/activities executed by the smart legal contract.
Sitting above Network Governance would be common Network Utilities. These are direct mappings of similar functionalities across both platforms. A common Network Map namespace can be useful for mapping corporate identities or relationships between parent and subaccount mappings. A common consensus protocol can provide different levels of trust for validating transactions on either network.
Onboarding into networks also shares common manual checks. If we’re looking to avoid duplicated KYC efforts on multiple networks, it may make sense to have a shared process that creates multiple identities and stores them in a trusted and shared location.
Monitoring of network health is also commonly created across platforms. There may be some benefits in sharing messages that indicate alerts or errors if interoperability exists across networks/platforms.
The most important commonality across networks is the ID mapping component. A single user registration may be added to a broader Active Directory associated to multiple anchoring identity tenants.
Applications themselves may also have a subset of permissions granted through a paywall or other onboarding mechanism. The permissions of these users to access across networks must also be flexibly maintained.
Users also typically fall under different types based on the application or their relationship with the network. There have been interesting patterns where the known staking of tokens provides elevated membership rights. Perhaps the staking is on an Ethereum smart contract DAO while the permissioning is reflected on a CorDapp.
From a corporate identity and technical perspective, the node identity and permissioning is also a shared representation across networks. Typically corporate legal entities using LEI have parent-to-subaccount mappings recreated across multiple applications. This hierarchical agreed upon mapping can be shared across members with known entities.
In addition, nodes themselves may have special permissions or roles for different applications. The ability to identify any known set of characteristics and grant these elevated privileges will be important within Attestations. The Sovrin model uses “steward” or “anchor” nodes to represent the permissions of corporations that can maintain the network and provide write-access to known parties.
Typically, the way to add any outside source of information to a blockchain is via a trusted third party known as an Oracle. These Oracles must be deterministic and provide a certainty of data for the executed transactions. Outside data in this case can be reference data static sources already represented in centralized data sources or market data time sensitive to any smart contract’s life cycle.
Legal or code review as an Oracle service can also be an interesting concept for arbitration across networks/ledgers.
Shared data and business logic across different networks and published applications can also be very challenging. The target state might look like a curated list of standard representations with peer review from the proper auditors of known evolution. ISDA CDM, EEA technical specifications, and W3C DID specifications provides a non-platform dependent model for state evolution.
If assets are to move across platforms, we may want to do levels of formal verification to confirm the logic written for the execution on both platforms are following the same rules. This might mean that the legal documentation will include the code for both platforms.
Business Networks are a term for the software providers that are responsible for the SLAs associated with the purchase of the dapp. Corda distinguishes further to Business Network Operators (BNO), Governors (BNG), and Designers (BND), which can all be different corporations or consortia.
As with a mobile app store, the distribution mechanism and common functions are normally centralized. In a distributed system, the Business Network may need to write their own services for source control, membership, and distribution.
As with all blockchains, there must be proper versioning on upgrades across a network, node, and dapp. Networks are governed by network participation agreements and shared “initial conditions” (e.g. Genesis file). Nodes are upgraded to latest versions of clients to include additional features. Dapps can also be updated for additional on-chain features.
The deployment and upgrade path for these dapps are fairly similar. There are dependency trees for all smart contracts or published dapps. Overall, any application must be jointly reviewed by all stakeholders.
Normally there are deploy schedules within banks and fairly strict Request For Change processes associated with tickets and prod checks prior to roll out. Similarly, there will need to be an agreed upon operational checklist across institutions on core applications and platform software.
All of these common services can become shared utilities or marketplace offerings in their own right. Hopefully these are being built with multiple platforms in mind.
In Part 3, we’ll discuss the detailed requirements and some proposals for a component that can connect Corda and Ethereum networks for the Access Control use case.
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.