Unlocking Corda <> Ethereum Interoperability Pt 3
Part 1 of this series reviewed interoperability. Part 2 focused on comparing Corda and Ethereum components with a deep dive on common services. These two parts are not pre-requisites for this article.
Low Hanging Fruit — Identity & Access Control
In general, interoperability use cases cover:
- Asset Portability — From Ledger A (main) to Ledger B
- PVP/DVP Atomic TXs — Trigger Ledger A to move Assets on Ledger B and record on Ledger A
- Cross-Chain Oracles — Ledgers A & B update off of an action from a trusted source of event — Ref Data
- Asset Encumbrance — From Ledger A (locked) to Ledger B back to Ledger A (unlock)
- Asset Control — Role-based permissioning on asset usage
While all of these use cases are relevant and interesting, the core component unlocking interoperability will be common Identity and Access Control.
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.
Identity & Access Control Requirements
“DID” integration depends on the specific implementation. The following high level features would be useful for bridging multiple ledgers:
- Establish DID trust between parties
- Store shared DID between both ledgers
- Creation of well-defined roles (shared registry view)
- Assignment of roles to DID — known party granting/attesting roles as claims
- Granular dapp permissions based on role interpretation
- Privacy of smart contract assignments of role
- Hierarchy of relationships between X509 and Accounts
- Known network administrative role
- Avoid bottleneck/centralized designs
- Delegation of roles
User Stories
Standard Ethereum smart contract roles are through the address.owner or address.sender parameters (callable within the contract). For example, mortal contracts usually only allow the address.owner to perform a suicide() function. Additional checks can be made to the key-value store within the smart contract such as whitelist or possibly a creation of permissions based on amount staked within a token.
Similar to the addresses sent by accounts via transactions, we can consider other types of Roles:
- Ability to perform “X” function
- Ability to read, write, or edit
- Ability to assign specific roles to profiles across a dapp
Who Uses This?
Existing Ethereum Implementation Examples
In order to avoid reinventing the wheel, I reviewed existing ConsenSys spoke and external implementations of Identity and Access control on Ethereum. As a quick summary:
- Kaleido — Identity Service directly maps organization to membership node identifiers on an ENS-like smart contract. This provides hierarchy of organization parent entities to specific nodes owned by such entities.
- Blockapps — Blockapp’s own identity management platform with users and groups. Also flattened with permissions to provide management on the separate networks.
- uPort — Suggestions include registration of an x509 identity from Corda to a standard ERC identity contract. Also provides Verifiable credentials via uport-credentials, but these can be interpreted differently by different dapps. uPort’s lightweight identity contract is on EIP1056. Latest dev libraries and DID registry also available.
- Pantheon — V1.0 includes a lightweight whitelist permissioning from EEA spec. This is account and node whitelists with JWT authentication and authorization via JSON RPC. Future versions will include smart contract based permissioning and fine grained permissioning.
- Viant — Single XML file generates the network with predefined accounts and roles within the supply chain process flow. Roles are embedded into the supply chain contracts and bespoke to each instance.
- Meridio — Active permissions on specific asset movement depends on compliance modules. These are passed through with every transaction to ensure each asset is following the assigned modules.
- 3box — Solves for the problem of linking a single profile across multiple dapps on the same Ethereum network. Profile properties can be used like verified claims created by dapps. Information is stored on IPFS.
- Liquality — Chain abstraction layer can be leveraged for cross-account mapping. This provides cross-chain wallets and normalizes data across different chains.
- Sidetree — Specific permissions and identities are implemented specifically with IPFS for off-chain storage and encryption. The specific DID implementation will have similar interpretation analysis to Uport DID implementations.
- Polymath — Separate identity and role management created while generating the STO through different registries. Pre-determined roles like owners and investors will see a subset of data. Investors are whitelisted with these permissions.
- EOS — Full visualization of accounts and permissions structure is available. I personally like the EOS model as it’s fairly clean.
- Plasma — Implementations vary, but generally doesn’t seem to have an issue since most of the account formats are consistent across difference layers. Each application can manage their own set of registries and identities.
- Cordentity (Luxoft+Hyperledger Indy) — Indy-cordapp is a one-way integration with a sovrin network via the hyperledger indy wallet that allows for storage of DID and credentials within Corda states. In this case, sovrin acts as a trusted DID registry.
High Level Solution Proposals
Based on comparison of existing implementations, review of interoperability design patterns, and deep understanding of overlapping components, I’ve recommended a few further modules. These will require interaction and collaboration across Corda and Ethereum developers.
Corda Enterprise Interoperability Module
Design Concept:
Provide a Business Network Membership Management tool that focuses on identity and role/permission management for the business network operator. This module registers a business network membership set of x509 certificates to link multiple ledgers and private network instances. The module is effectively an embedded Ethereum wallet with trust parameters installed across known permissioned ledgers.
Features:
- Reusable Business Network Membership Service for other Ethereum ledgers
- Use of Corda Business Network as the mainnet relay for side chain Ethereum implementations
- Ability for Corda nodes to sign and send Ethereum transactions to known networks
Corda Project Maximus with Ethereum Addresses
Design Concept:
Project Maximus aims to provide a single Corda node the ability to host multiple identities. One part of this effectively creates an Hierarchical Deterministic (HD) Wallet off of a Corda node identity as a parent. The second part will require a registration of these individual identities mapped to parents in order to allow an individual to know for certain it is sending access of a Corda state specifically to an individual under a parent. Both the wallet creation and registration can be hosted on Ethereum mainnet or a trusted Ethereum network as smart contracts.
Features:
- Ethereum registry providing identities to Corda node owners
- Embedded Corda HD wallet management solving for parent-subaccount mappings
- Shared Corda/Ethereum accessible registry
- Possibility for Ethereum accounts and initiating Ethereum transactions within CorDapp flows
Corda Oracle (e.g. Stores Legal Entity Mapping) for Ethereum
Design Concept:
A trusted Business Network within a Corda network allows for a set of Corda nodes to solely manage the legal entity registry. This will be viewed by Ethereum smart contracts as an oracle service.
Features:
- Known Corda nodes act as an oracle to Ethereum smart contracts
- Lighthouse model can be used to publish changes initialized by Corda nodes
Shared Smart Contract / DID Model
Design Concept:
Similar to the Corda-Sovrin integration project with Hyperledger Indy, but instead utilize uPort or Sidetree to incorporate the DID registry and DID Document sharing. Tweaks will need to be made to create a CorDapp calling Ethereum smart contracts and creation of addresses that represent the x509 entity.
Features:
- Trusted shared registry storing DIDs and proofs
- Corda identities able to establish DID trust between other non-corda identities
- Corda identities able to issue verifiable claims across platforms
- Corda identities able to create proofs off of issued claims
- Non-Corda identities able to verify proofs issued on to Corda identities
- Abstraction of individual identity and delegations to another ledger
Shared Network Mapping Services
Design Concept:
Corda Foundation and bespoke governance enabled by permissioned Ethereum networks can create joint CDN-based network map services. Both governance entities would trust the shared service and update based on the delegated permissions for each application. This common network mapping across ledgers and networks can still be distributed and de-centrally run.
Features:
- Known governance entities support a shared network map service
- Network map service technical specifications do not need to be explicit (e.g. can be on central, distributed, or blockchain tech as long as it scales)
- Levels of mapping and privacy will provide for global services across ledger networks
- Provides a unified namespace
Shared Legal Mapping
Design Concept:
Legal smart contract negotiation, construction, deployment, and monitoring provides a full life cycle of known assets linked by e-signature rules. Utilizing the identity module within a trusted legal smart contract platform, the wallets that maintain these known delegated signatures can be linked to the shared published legal smart contract agreement. This distributed/decentralized arbitration layer can be an interoperability across different ledgers and networks if it’s explicitly written within legal parameters. The triggering of the deployment of a legal smart contract object can also link to both a Corda state’s legal prose hash or the hash of the decentralized storage solution.
Features:
- e-Signature identities linked to multiple ledgers and specific standing networks
- Proof of linked signatures to known and confirmed accounts
- Reviewable live legal smart contract referenceable by legal hash of document
- Reviewable terms of legal smart contract by both platforms
What’s Next?
While I’d love to see any of these solution proposals pursued, the blockchain ecosystem is still in the midst of platform comparison and what’s good for winning business.
Within ConsenSys, our work with identity across our Solutions implementations will take into account the relevant Corda requirements. Hopefully this will open further conversations and create proper translations and trust between ledgers.
—
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.
