Summary of Blockchain Projects for Privacy Protection

Posted 2021-04-29 码农学习区块链

As we all know, scalability and privacy are two major challenges that public Blockchains have to face nowadays. Projects such as Keep, Mainframe and Nucypher emphasize that they can solve the privacy protection issues for Blockchain. And the areas that each project focuses on are different. Let's take a closer look at them one by one.

Btw, all of them will show up in the in Bay Area on May 6th, if you have interersts in participating the Event, please ping me or leave me a message. I do have limited amounts of tickets I'd like to give away for free to the community. This article is written in English to help promote the visibility of this Event, and I also made a few improvements since I wrote the previous in Chinese.

Cool, time to move forward. First, let's talk about Keep.

Keep I have analyzed Keep in details in this and another  . Keep mainly provides a third-party off-chain data container and service to allows users (especially smart contracts) to securely store the private data. Also, the users can give permission to the data container to publish the computation results over the stored private data to the public blockchain.

Besides, sMPC (Secure Multi-Party Computation) is heavily used in Keep to split the storage of the private data and computations among multiple nodes, and it plays an important role to remove dependency on the trustworthiness of each participant node, and even if some nodes behave maliciously, the impact won't be critical. Since we have discussed Keep extensively in previous posts, this time we won't spend too much time on it.

Mainframe

Mainframe focuses on Communication layer protocol and aims to proivde a decentralized and anti-censorship data routing network (overlay on top of physical network) by improving P2P protocol. The general idea is quite similar to Orchid Protocol and (The New Kind of Network). Actually Mainframe is more like Orchid Protocol because the core of the former is to realize a P2P routing network based on 'Kademlia' algorithm into which we will have a deep dive soon, and the latter uses extended 'Chord' to build its own P2P 'market'.

NKN is a little bit different as it has nothing to do with any existing HDT-based (Distributed Hash Table) routing algorithm but relies on CA (Cellular Automata) to generate a dynamic virtual overlay so that the security and reliablity of data transmission can be guaranteed, while Mainframe chooses to introduce the customized protocol layers including Kademlia P2P network into Application layer to achieve the same.

The bottom of the Mainframe customized protocols is the most critical P2P layer, which is analog to the P2P layer empowered by NKN's CA. Here, what Mainframe wants to build is the implementations of Kademlia protocol algorithm. Kademlia (or Kad in short) is based on DHT and comes with its proprietary node ID naming mechasim and XOR-based distance computations. These sepcial and excellent innovations also help Kad greatly increase the efficiency of routing compared to other similar algorithm, as only O(log(n)) queries are needed in a network with n nodes for each routing.

Comparing to the 'Chord' which Orchid protocol uses (it uses consistency hashing, that's why you see a 'ring' to refer to the Orchid market in its whitepaper), Kad is relatively simple and performant. Some real problems that arise in all DHTs are more easily handled by Kademlia than by others. Therefore, although Chord-style routing techiniques are more popular in the academical researches, Kademlia always comes out on top for the actual projects' implementations.

More tech details on Kad: the namespace of the node ID in the Kad network has 160 bits. All nodes are treated as the leaves of a binary tree, and the location of each node is determined by the value (prefix) of its ID. Every node (i.e. node A) is guaranteed to know at least one other node that belongs to each sub-trees that are divived by node A itself. In this way, each node can recursively search for any other nodes by gradually approaching the target based on node ID and finally converge to the target. Of course, the computation of the distance between nodes (namely node IDs) is essential here. It uses XOR operation, and the difference on more significant bit will lead to greater distance betwee two nodes. Kad also use its own k-bucket to build the routing table.

It does require some decent amount of knowledge on data structures of Computer Science to thoroughly understand Kad. I am going no futher on the techical details here, and as normal reader you don't need to dive into the details too much, but only to remember that the network based on Kad is highly efficient and DDOS-proof. Actually quite a few well-known P2P applications have already adopted and used Kad such as eMule and Bittorrent. The only missing part is that the whitepaper of Mainframe does not specify clearly whether it's going to just follow Kad and implemente it without any changes, or it may customize or improve it.

Mainframe also provides a number of other useful higher-level protocols on top of its Kad P2P network, such as encryption, dark routing, and incentivization:

Encryption: It supports secure one-to-one or one-to-many data transmission by allowing Asymmetric encryption between Mainframe nodes. The system will provide a yellow-page-like service for nodes to publish their public key. If some node need to send data to the specific target node, the sender node can simply go check the public service and retrieve the public key owned by the recipient node, then encyrpt the data packet using such public key so that only the recipient can decrypt them correctly and get to know the content. Speaking of one-to-many data transmission, Mainframe also supports multi-cast, where each recipient node will receive the same large package containing all the data packets, instead of getting the one only for the specific recipient itself. Under such situation, Mainframe will provide a specific protocol for shared key negotiation, then sender just need to encrypt the large pacakge once.

Dark routing: Dark routing refers to that when only part of the information of the receiving node's address is revealed, the data packet can still be sent to the recipient. The solution that Mainframe has for achieving Dark routing is mainly based on the Ethereum Whisper Wire Protocol (a P2P information protocol that combines the aforementioned DHT and packet transmission system (such as UDP). WWP will be integrated into the Ethereum browser) and the improved version of the protocol PSS (Postal Service over Swarm).

Incentivization: It's quite natural and inevitable to get involved with token economy and incentives in the blockchain projects. As network platform, Mainframe provides interfaces and SDKs for the convenient development of multiple applications such as blockchain transactions, data services, file storage, and packet routing. In addition, the incentive system for each node in these scenarios has also been proposed.

In general, in the field of building a decentralized and privacy-protected network communication layer, Mainframe can be quite a competitor to NKN and Orchid. All of them introduce existing technologies and best practices from different perspectives into the Blockchain world.

Nucypher

The most highlighted service provided by Nucypher is Proxy Re-Encryption. Proxy re-encryption is not new concept, it is a key conversion mechanism (asymmetric encryption) between ciphertexts. Consider the following scenario: Alice encrypts the protected file (aka plain text) with her own private key. Encrypted content (aka cyphertext) is uploaded to the public network (AWS S3, Droxbox, etc) and what can she do when the plain text needs to be shared with Bob? Basically there are 3 ways:

The first way is that: Alice can decrypt the encrypted content A retreived from the Internet through her own private key. Then use Bob's public key to encrypt the plain text to generate the encrypted content B and store it back to the Internet. Then Bob can download it and use his private key to see the plain text. 

Another way is called 'Re-encryption'. Alice calculates a Re-encryption key by combining the information of her own private key and Bob's public key. The Re-encryption key can be used to convert the encrypted content A directly to encrypted content B, which Bob can decrypt it with his own private key. The entire process does not require Alice to decrypt the ciphertext back to the plain text as in the first way. 

Then here comes the third way, Proxy Re-encryption. Such Re-encryption key mentioned in the above section is good enough (thanks to Mathematics and Cryptography) and allows us to complete the Re-encryption task without exposing any plain text content. Therefore the conversion step can be handed to a semi-trusted agent and gets stored there. Agent has no way to touch the plain text throughout the process of Re-cncryption, thereby reducing the risk of data leak. Also, users like Alice will be mostly free from the repeated back and forth process with the help of the proxy/agent, as she could delegate the heavy lift to proxy for the cyphertext conversion and she will just need to calculates the Re-cncryption key for the party she want to share the secret with only once. The nice thing here is to split the trust needed for access management and decryption process.

Let me briefly introduce the hybrid encryption method (symmetric encryption + asymmetric encryption), which Nucypher typically adopts. It uses a specific password p to symmetrically encrypt the plain text (symmetric encryption), and then the private key is used to encrypt the password p rather than plain text (asymmetric encryption). As for decryption, the public key is used to decrypt the password p (asymmetric), and then the password p is used to decrypt the cyphertext to get the original plain text (symmetric). The benefits of blending these two encryption methods is to make up the shortcomings of either one: there is limitation on the length of the plain text for asymmetric encryption such as RSA, and symmetric encryption such as DES can be easily cracked.

In summary, Nucypher is just a service upon Ethereum and aims at a relatively narrow and easy-to-understand application scenario. The nodes used by Nucypher are responsible for storing Alice's computed Re-encryption key (selecting one or more nodes randomly among all active nodes via POS), and performing the actual re-encryption calculation when Bob requests it. And similar to the use of sMPC in Keep, Nucypher also supports splitting the Re-encryption key into multiple shares for different nodes to store and use, the pieces resulting from Re-encryption can be merged on the client side finally, which ultimately prevents a bad node from being out of control such as converting the ciphertext at the node's will. In addition, each node also needs to deposit Nucypher tokens to be able to serve user traffic. If the data processing is found to be incorrect after being challenged by the user, revenue of the bad node will be forfeited to the challenger and other nodes.

More detailed reviews on Nucypher could also be found via .

Feel free to connect with me if you have questions or feedbacks. Thank you for your time!