Privacy research development in Nano

Funded

Project Overview

Recently, I submitted a paper to IEEE DAPPS 2020 (not yet published), where I describe a possible way to implement privacy in Nano at the consensus level (http://hdl.handle.net/10400.6/7645), which I explain bellow in a simpler way. Currently my plan is to submit another paper, a continuation of the first, to Blockchain 2020 conference (http://www.blockchain-ieee.org/), whose deadline ends in 1 March 2020. The goal is to evaluate the viability of the scheme, theoretically, with a security analysis, and practically, with a reference implementation in Rust and respective performance analysis, which I already started (https://github.com/Fiono11/secret_sharing_scheme).

So far so good. The problem is: right now I don’t have a scholarship and I am using my savings to fund my Phd. Obviously, this is not sustainable and I may have to work on something else. There are two reasons I would want to avoid this: first, I love what I am doing, second it is very hard to conciliate both things (I know because I did that in my first year).

So, I thought of seeing if there is any interest in the Nano community to fund the production of this paper (I hope, after that, to already have a scholarship), i.e., two months of full time work. I am asking for 2000 Nanos to do that. There are a few reasons I think this project is good for Nano:

• Make Nano known in the academia: besides new people getting to know Nano, it can attract valuable people to our community, like researchers, teachers, etc.
• Possibility of finding a viable way to implement privacy in Nano, or, at least, exclude some ways.
• Incentive to research development outside the Nano Foundation.
• More credibility in general to Nano and the community. Bellow I describe the scheme in a simple way, you can read the article for more detail.

The scheme

In Bitcoin based cryptocurrencies, the transaction layer is separated from the consensus layer, so in order to implement privacy you only need to implement it at the transaction level, but in Nano you need to implement it both at the transaction level and consensus level (this is why it is generally considered more difficult) because Open Representative Voting (ORV) relies on knowing the total balance delegated to each Representative to function. However, one crucial detail is that it isn’t necessary to know the individual balances delegated to each Representative.

Based on this, the idea of the scheme is to use an asymmetric cryptosystem: a public key to encrypt the individual balances of the accounts on the network (and the transaction amounts) and a private key to decrypt. Since we are not interested in decrypting the individual balances, but only the total balances, we need this encryption to be additive homomorphic, which means that the sum of two encrypted values is equal to the encrypted sum of the values (E(x) + E(y) = E(x+y)).

One question that arises from here is: what guarantees that who has the private key only decrypts the total balances and not the individual balances, since they are all encrypted with the same public key?

The answer is easy: nothing. So how do we solve this problem? The obvious answer that comes to mind is that no single entity can have the private key.

Which leads us to a second question: who should have the private key of the cryptosystem and, therefore, be able to decrypt values encrypted with the public key?

For efficiency reasons, the private key can’t be shared by everyone on the network, so it is only natural that it is shared by those who already have the power of consensus on the network: the Principal Representatives.

So, we need a secret sharing scheme, where the generated secret is the private key of the cryptosystem, each party of the scheme has a secret share and a certain minimum number of shares is needed to decrypt, with the following properties:

• Weighted: Principal Representatives have different voting weights, so it makes sense that their secret shares of the scheme have the same weight.
• Threshold: not all secret shares are needed to decrypt, but only a minimum threshold (e.g.: 50%).
• Verifiable: since we can’t have a trusted dealer that distributes the secret shares, everyone that participates in the scheme is a dealer and we need a way to verify that the shares are valid, otherwise they would be useless for decrypting.
• Decrypting without reconstructing the secret: this allows the keys to be reused, otherwise the private key would be known after the first decryption.