This is Part 5 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.
‍
Privacy Layer

Beyond Interoperability, I-DELTA will provide a new security layer or toolset that will allow DLT platform to use practical zero-knowledge-proof algorithms. Using simple symmetric and asymmetric encryption to secure some data between two parties is not a good solution for DLTs. The biggest value of DLTs is trust between parties. By simply encrypting data between two parties make other parties useless for the data and creates a P2P channel. Other parties cannot understand the operations and cannot make an effective role in consensus. As a solution to this problem, cryptographic algorithms can be mixed and matched with sophisticated methods and other algorithms to create proofs that can be voted by all parties while not revealing sensitive information. This method mostly known as zero knowledge proof (ZKP). In the I-DELTA project, we are going to offer practical zero knowledge algorithms for the common problems. On top of a data layer, I-DELTA will provide a ZKP layer that can be used as an API with user-defined smart contracts. With the help of ZKP, the items mentioned below will be verified:

·     Balances of accounts without knowing their real balance

·     The validity of an amount of asset transfer

·     A field of digital identity without revealing personal information (such as verification age restriction without revealing age and other personal information)

·     In addition to demographic information, genetic data such as DNA can be used to query   similarities between people, sensitivity to a new drug, etc. without revealing any subset of DNA information. This kind of privacy-preserving personalization of the services will open a new horizon.

Pub-Sub Component

For blockchain interoperability to be viable, the proposed mechanisms must be of a decentralized and distributed nature, and furthermore, must also be able to connect multiple blockchain networks. Hence, this component’s function is to provide a distributed pub-sub mechanism across multiple blockchain solutions.

Broker

The publisher and subscriber blockchains enroll with the broker as publishers and subscribers respectively, using the connector smart contract. This has to be done only once, after which the publisher can create topics and publish messages topics based on the needs of the application. Likewise, the subscriber can then subscribe to topics and receive notifications for topics. When a message is published to a topic by the publisher, the topic manager fetches the list of subscribers from the connector and uses that list to send a notification to the connector of every subscriber network.

Since the use cases will involve enterprise blockchains that are going to be permissioned, the blockchain used by the broker will also be permissioned and compatible with privacy and governance concerns and be able to support sophisticated smart contracts.

The topic manager contract will keep track of all the topics and their related information, where each topic will have one publisher that can only update the topic, which will be the blockchain topic that has registered the topic with the broker. The connector smart contract will keep track of the connection information of all the blockchain networks.  Furthermore, support for different DLT networks will also be the primary function of the connector smart contract.

Subscriber

By definition a subscriber requires information from another blockchain to fulfil its function. In order to take part in the platform, the subscriber network must have a connector deployed on it. The connector smart contract tracks the topics the subscriber network has subscribed to stores the latest versions for other smart contracts to access. Since the primary function is receiving information, the connector smart contract has less design constraints when compared to the connector for the broker.

Publisher

The publisher blockchain is the source blockchain that provides information to the subscribers. The publisher connector will keep track of its topics and also connect to the broker to publish the topics. For the broker to interact with the publisher, the publisher must first register itself with the broker connector. Once registered, the publisher can then create new topics by specifying a topic name. Afterwards the application can update the topic as needed by through the connector, which will then publish the message to the topic on the broker
‍
This is Part 5 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.