Historical Reference
A connector-less approach to the non-fungible asset interoperability problem in permissioned distributed ledgers
Federation for Interop provides for data transfer across different permissioned distributed ledgers without connectors or middleman. Federation for Interop aims to be as plugable as possible to existing distributed ledger infrastructure and networks. The implementation and design of the project enables interoperability by extending pre-existing roles and services within the existing consensus mechanism and governance roles to limit the creation of new entities dedicated to interoperability.
Federation for Interop does not describe a standard for interoperability but rather implement an architecture of roles, services and mechanisms that serves this purpose. Rather than relying on strict protocols, Federation for Interop specifies minimum requirements to ensure the cross-distributed ledger data transfer where participants can define rules and protocols on the data they are sharing on a case-to-case basis.
This document will provide a quick overview of:
- Transfer validator role
- Export & Import mechanism
- Simple asset transfer example
- Blockchain plugins
- Future work
If you prefer to get started right away: simple asset transfer setup
Federation for Interop introduces the ‘transfer validator’ role. A transfer validator is a distributed ledger participant who may take specific actions in the transfer mechanisms and provide certain services to the other participants of the distributed ledger. The identity of the transfer validators plays an important role in the cohesion of the broader ecosystem -Multiple distributed ledgers willing to interact with each other, since they represent their local distributed ledger from an external point of view.
Validators are participants chosen by the local distributed ledger governance system, their number will vary from one distributed ledger to the other based on needs. Potential transfer validators are easy to identify in private and/or permissioned ledgers: they will match existing identifiable participants in the distributed network such as participants taking part in the consensus mechanism or in the governance. Any well-known participant, within and outside the local distributed ledger, is a good potential candidate.
Typically, there is a substantial number of transfer validators within each distributed ledger. The ideal setup is to have enough transfer validators to avoid intentional, arbitrary or induced denial of service. Depending on the ecosystem, this number may vary from a few nodes to the entire network.
Each transfer validator exposes one or multiple public keys that are attached to its identity in the distributed ledger, as well as a service of certification. Any participant of the network, validators included can ask a validator to certify a piece of information coming from the local distributed ledger according to specific known lower-level protocol. On a case-to-case basis, validator will ever grant the certification in the form of digital signature or reject the request. The reason for rejection from a validator can be multiple and internal to this validator alone (e.g. a specific piece of information should not be disclosed outside of the distributed ledger for confidentiality reasons).
The transfer validators are, so to speak, the representatives of the distributed ledger in the broader ecosystem and should make sure that only proper information is certified to be exported to foreign entities or distributed ledgers. While adding a new role and services to the existing distributed ledger network, the idea is to stay as close as possible to the existing trust model of each distributed ledger ecosystem. Each of the components of the transfer validator is plugeable to already running networks and should not disrupt the inner working of distributed ledgers.
Each transfer validator exposes one or more public key to be identifiable in its local network and beyond. The core functionality of the transfer validators is to provide a certification service to all other participants of the local network. The transfer validator may certify that a piece of information exists in the local distributed ledger at a certain point in time. The certificate consists, at minima, of the piece of information to certify as stored in the distributed ledger as well as a digital signature of this piece of information matching one of the transfer validator’s public keys. A participant may collect as many certifications as needed for a specific piece of information. A minimal quorum of certifications is typically defined by the local ledger to distinguish valid proofs from invalid one. The number of certification needed for a certain proof can differ depending on the proof type.
The export mechanism relies mainly on the ability of the validator to certify information. The data structure and protocol used to verify the state of the local ledger can be implemented based on the local rules of the ledger. For example, proving that a certain asset is 'owned' by a specific Blockchain participant may be implemented differently depending on the technology and existing custom logic on the ledger.
We plan to implement high-level data protocol to cover the main interoperability use cases (proof of ownership, asset transfer...). See the future work section for more information.
Messages certified by a distributed ledger’s transfer validators can be delivered to one or multiple recipients by any secure off-chain communication system. For instance, a certified message could be sent by email to a foreign distributed ledger’s participant.
Entities receiving messages coming from a foreign distributed ledger of the broader ecosystem can gather and record the transfer validator’s public key of the emitting distributed ledger. The identity management problem is not yet covered by the solution, see the future work section for more information. At this point, we assume that transfer validator’s public keys are known and accessible in the broader ecosystem.
A proof coming from a foreign distributed ledger can be verified against the public keys the transfer validators of that foreign distributed ledger. The number of certification needed to consider the proof as valid within the local ledger can be defined locally or more broadly and can depend on the type of proof, the provenance of the proof or the requestor. Typically these elements will be decided by the governance system of the receiving ledger.
The verification can be made by any entity that knows the identities of the certificating validators. If the receiving entity is a distributed ledger, the requestor may want to trigger action on the ledger based on the verification of a valid foreign proof. To impact the state of the local ledger and verify the proof in a distributed manner, a separate on-chain logic on the receiving distributed ledger can enable the sharing and distributed verifications of any certified messages coming from registered foreign distributed ledgers. See the JPM Quorum plugin and Hyperledger Fabric plugin for more information.
See simple asset transfer setup for more information.
The Fabric plugin is two-fold and includes both logic to connect to the Blockchain and smart contract extensions.
Plugin contains two on-chain logic pieces to enable imports in distributed ledgers:
- Foreign Validator identity and public key management
- Foreign proof verification against stored identities
See Fabric on-chain documentation and Quorum on-chain documentation for more information. Note: contracts are located under the example folder for now.
The connector class is an helper component defining how to communicate with the local Blockchain. The connectors point to two different part of the on-chain logic:
- Import logic: foreign validator identity and proof verification (see above)
- Base logic: custom logic of the local ledger (see the example). Plugin connectors are using the provided Fabric SDK and a custom Quorum API, they can be modified and extended to perfectly fit the use case and integration layers of the local ledger to extend connectors
As it stands we can prove that something happened on a foreign distributed ledger. For more complex interoperability use cases (e.g. asset transfer, atomic swap, asset synchronization, …), we want data protocols defining the steps and verifications needed from the validators.
Validator identity verification is at the backbone of the solution. We want ecosystems to be able to discover foreign validators and store their identity in a reliable way. Potential lead: Distributed ledger for identity (Indy, Sovrin, …)
Communication between validators is based on broadcasting. We want the validator network to understand and match the confidentiality setup of the local ledger.
We want to implement plugins and on-chain logic for more platforms (e.g. Digital Asset, Corda …).