This is Part 4 in a series on the I-DELTA project. Read Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8.
Türkçe için buraya tıklayınız.
‍

I-DELTA will use a multi-layer solution built on top of a pub-sub message bus that will be used by different ledgers to communicate. This will be a scalable system supporting atomic swaps, event propagation etc. Further, one of its main focus will be data privacy and confidentiality. Compared to state of the art, our design rationale is having a more generic, more flexible and as seamless as possible solution for having interoperability for distributed ledgers.  The details of the innovations will be given later in this section. Below we summarize the key-points of the technological innovation of I-DELTA:

·        Until now, most of the applications run on their own distributed ledgers; a potential interoperability solution must integrate all these applications with no need to alter their design.  Even the most used chains such as Bitcoin and Ethereum have different finalities, consensus mechanisms, number of transactions supported, functionalities etc. A pairwise interoperability solution will need an individually optimized bridge/channel in between for each application pair that want to operate together. Furthermore, the bridges must be updateable in case one of the endpoint chains forks or changes in some other way.

·     On the other hand, a pub-sub-based solution with a single message bus will enable multiple applications and use-cases seamlessly communicate via different sub-channels. These channels can be public or private; hence one can control the subscription permissions for the ledgers while a channel is being established. For instance, the ledgers of all the banks can be subscribed to a channel established a for a loyalty system. Or, two ledgers being managed by two different companies can be the only subscribers.

·     As mentioned above, privacy and confidentiality will the two main pillars for I-DELTA to further increase the commercial adoption. With the proposed Privacy Layer, confidential subscriptions will be enabled, and the ledgers can seamlessly communicate in-between via confidential transactions which can also be verified thanks to ZKPs. As far as we know, there is no interoperability solution using these advanced cryptographic techniques.

·     Together with AI, distributed ledgers are considered to be the two most disruptive technologies that will be realized in the close future. Indeed, AI is not the main concern of I-DELTA and it seems to be not useful for a single chain. We are aware of blockchain-based solutions to enable AI with permissioned data/model sharing and building a financial ecosystem on top of that. However, the other utilization direction does not appear in any use-cases we are aware of. For multi-chain, interoperable distributed ledger technologies, we envision the following crucial and interesting research and development directions;

o   Using AI to optimize the interoperability performance: Machine learning and AI-based models can be used to optimize the performance of communication channels and the message bus. For instance, based on their expected message volume and other characteristics such as bytes-per-transaction, number of chains, number of active chains etc. the channels can be placed, prioritized or optimized on a different level and scale on I-DELTA. We believe this will reduce operational costs for and yield a better, faster, and more effective interoperability solution.

o   Considering I-DELTA will be a widely accepted solution and be a huge step for Web 3.0, training the model to optimize the management module (as mentioned in the previous bullet) will be a burden for the system itself; the data to be processed will be in massive scale. As stated in SotA, PoW, in its current form, is not an efficient consensus mechanism and various solutions such as Casper, Avalanche and Algorand are being investigated and developed. During I-DELTA, we will always consider the state-of-the-art mechanisms as potential enhancements. However, one possible avenue for I-DELTA consensus is PoI; it is indeed an interesting alternative since the AI-model to be trained will be built by the I-DELTA ecosystem and will be used for the I-DELTA ecosystem. That is PoI can direct all the computational cost of model building in the previous bullet to the consensus itself. This is one of the reasons of making us interested in the use of PoI in I-DELTA.

Interoperability:

Some enterprise networks such as a group of banks or a group of government institutions can build a blockchain network for themselves. These networks also build their own rules, policies and related smart contracts. However, collaboration between these networks create new use cases and become very effective. As a sample, some banks may create a payment system between each other, and a government institution wants to join the network to collect tax through the payment network. Since there are many other rules and policies cannot be applied to government tax office, it makes it harder to make the government institution be a member of the recent bank network. There comes the interoperability will be a solution for this case. Some of the use cases which are valid for both two different DLTs, can be provided using interoperability protocols. In this project, our consortium will provide a message-based interoperability platform.

As mentioned in SotA, interoperability is not a well solved issue for DLTs. Interoperability between ledgers have some technical challenges such as;

·     Smart Contracts cannot be run on different DLTs at the same time.

·     Consensus policies may be different for different DLTs

·     Actual data may be different for different DLTs

According to the challenges mentioned above, the interoperability between DLTs should be message or service based. Interledger (interledger.org) is a kind of example which is message based, and money transfer messages are routed between ledgers. In current situations, interoperability is mostly established on some specific use cases so far. In I-DELTA we will provide an interoperability layer that will follow a general approach and provide the following systems;

·     A service layer, which handles messages specific to ledgers and a reference architecture

·     A distributed message bus, which routes messages between ledgers

·     A protocol which is used for message transfers and extendible to fit use-cases

Using these systems, I-DELTA will provide a more general interoperability layer and will define the standards of interoperability of ledgers. Here are the more detailed definitions of the interoperability system parts.

Interoperability: Service Layer: Since every ledger is different and has its own platforms, smart contract languages and policies. A common interface is needed for each ledger. This service layer will provide the common interface for each ledger. It will be responsible for the following jobs;

·     Listening for new messages from other ledgers

·     Transmitting the messages to other ledgers

·     Authenticating of other ledger services or the message bus

·     Authorization of messages and message types

·     Queueing of messages between message bus and ledger order services

·     Tracking and auditing the message delivered to the ledger

·     Providing an ACK or NACK mechanism which will be a feedback to the message bus

·     Possible merge of messages that are to be sent

Since every ledger has different system parts and implementation details, this service layer will be implemented for each DLT platform. In I-DELTA we will provide at least two examples of Service Layer, one for a public and one for a private ledger. We will provide all the reference documentations and architecture for the platforms, so other platforms and partners can implement other necessary Service Layers.

There will also be a challenge for the service layer, because DLT systems are distributed, it is not easy to implement a service layer for every DLT. For permissioned ledgers, such as Hyperledger Fabric, this can be another ledger service such as the Orderer Service and it can be duplicated and supported by an AMQP (ex: Kafka) in the system to prevent Single Point of Failure situations. On the other hand, it will be much more difficult to implement a service layer for Ethereum. The service layer must be designed as a distributed system, so some of the peers in the network can make it work without a dedicated server. In I-DELTA, we will also provide a sample implementation of distributed service layer.

Interoperability: Distributed Message Bus: Since DLT systems are distributed, the interoperability layer, which will transfer the messages between those systems, should also be distributed. The Distributed Message Bus will provide the following functions;

·     A Naming and registry service for the Service Layers of DLTs

·     Authenticating of DLTs

·     Authorization of DLT messages

·     Transferring of messages between DLTs

·     Managing message bus nodes

·     Providing an ACK and NACK for Service Layers

·     Duplication of messages

·     De-duplication of messages

·     Broadcast and multicast transfer options

·     Monitoring and auditing tools

·     A Distributed File System or will use a Distributed File System (such as IPFS)

·     Rating and Charging system for the use of Message Bus

Distributed Message Bus will operate independent of any DLT. It will work as a global message bus for DLTs or it will be available to create a test network, which can be used as a message bus for private ledgers. The message bus will be the core part of Interoperability Layer. Since it is distributed, there will be many challenges that we are going to solve and some of them are;

·     Reliability KPIs for transferring messages

·     Creating and calculating the optimum redundancy of messages that will be transferred through a distributed message bus. This optimum number will be re-calculated according to the number of nodes, number of DLTs and the target throughput of the message bus. It needs to be defined with consensus and broadcasted to all nodes in the system.

·     Shrinking and scaling the message bus. Duplication of messages and de-duplication of messages according to the optimum redundancy number.

·     Managing the flow of messages that have specific activity diagrams.

·     Queueing of messages for an optimum time window. It needs to be very optimized to meet the QoS constraints.

Interoperability: Message Protocol: The message protocol defines at least the following properties; (1) Version, (2) Source DLT, (3) Target DLT, (4) Authentication Token, (5) Message Type, (6) Message Payload.

Message Protocol will be implemented by both the Message Bus and the Service Layer of a DLT. It may include other fields that will make the protocol more reliable. The protocol will define the retry and redundancy features according the statistical analysis of the initial test. These fields and activity diagrams will be available in the detailed design of the project.

Message Protocol will be the base layer for the other messages which are specific to the DLTs, so it will work as an enveloping protocol between ledgers. On the other hand, to talk about a real interoperability for a wider range of DLT platforms and technologies, some messages types need to be defined for common scenarios. Therefore, in I-DELTA we will provide message types and activity diagrams for the following scenarios; (1) Digital Identity, (2) Payment Systems, (3) Supply Chain History.

‍

This is Part 4 in a series on the I-DELTA project. Read Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8.
Türkçe için buraya tıklayınız.

‍

‍