What is NuCypher – Utility and Tokenomics

by Surly_Kiwi

Nucypher Part 1: Utilization

Nucypher is a one-of-a-kind tool that provides access to a decentralized key management system. To understand a decentralized KMS we must understand a centralized KMS. Examples of centralized key management systems include Amazon CloudHSM, Google Cloud KMS, etc. In broad terms, a KMS allows for one entity to share encrypted information with another entity. One example of KMS that we use every day in our lives is on the internet. When we enter most websites we only see [website].com however not so long ago we would see HTTPS in front of the website and it would appear as https://www./[website].com. This HTTPS protocol encrypts data through a server run by Google for example that is transferred between the website user and the website which is especially important when using login credentials. It’s also important because without data encryption your data can be used against you or sold to a third party especially if that data is valuable which it is in modern times where data is frequently sold without your knowledgeable consent. Now you may ask why is a decentralized KMS better than a centralized KMS.

1. A decentralized KMS does not rely on servers owned by an entity for example Amazon or Google it relies on a network of nodes run by a community of computers that perform KMS functions.
2. The nucypher token acts as an incentive for network providers running nodes to be paid for their correct and fast services and have their stake be slashed as a punishment if they damage the network
3. The most important case for a decentralized KMS in Nucypher’s case is proxy re-encryption [see the paragraph titled proxy re-encryption before continuing] Nucypher is the only project that is working on making PRE practical while also making it better. Some of the project’s guarantees with proxy re-encryption include minimalization, flexible classification, time dependence and independence, and abstraction.

Minimalization: a data consumer, for example, the insurance company can request only the data it needs to be re-encrypted for example subsets of your health record (blood test) and not your whole medical record (some information is more sensitive than others).

Flexible classification: would allow the subject being you to only allow access to the blood test subset of your health record rather than your whole health record when sending it to the insurance company. This can be implemented through the use of various private keys that lead to subsets of smaller data, one consumer of data ex. Insurance Company can decrypt a key named x-/health and x-/health/blood but not the other way around.

Time dependence and independence: Since the hospital encrypts the data of your blood test and sends it to you, you can send it to the insurance company on your own time. Through nucypher you can also set time limits on the Insurance Company’s to the data you send it, which in this situation may be more practical for developers working on a project.

Abstraction: data producers like a hospital and data consumers like the insurance company only serve their own purposes while you are in control of the data you want encrypted and transferred between both entities rather than the entities themselves.

Note: There are many more complex situations that can use PRE through Nucypher that allow for higher security and privacy for data encryption between two centralized entities rather than only just between decentralized entities pertaining to blockchains or dapps. The blood test example is solely a simplified example of the process pertaining to PRE.

[Nucypher has other technologies in development but this is the most important when detailing the project.]

[Proxy Re-Encryption]

To understand proxy re-encryption we have to understand public-key encryption. An easy understanding of PKE and PRE is the blood test example.

PKE: Let’s say you (subject) do a blood test at a hospital (producer), the hospital that has the blood test (data) sends it to the insurance company (consumer) as a source of data using the insurance companies public encryption key to encrypt your blood test so that the insurance company can decrypt the test using its own private key while protecting the integrity of your blood test.

Hospital ——-> Blood test (encryption using the Insurance Company’s public key) ———> Insurance Company (can use their private key to unlock data)

You (not involved with data transfer)

PRE: Proxy re-encryption on the other hand has a situation where the hospital using the PKE method encrypts your blood test using your public key. Now, instead of the encrypted blood test going directly to the insurance company it is sent through a provider, in this case, the large number of nodes (computers) on the NuCypher Network who cannot access the information they receive but instead allow you to re-encrypt your data using a derivative of your private key and the public key of the Insurance Company to then send the re-encrypted blood test to the insurance company who de-encrypts it using their own public key.

Hospital——> Blood test (encryption using your public key )——> *Nucypher Nodes (encrypt the blood test using your private key derivative and the Insurance Company’s public key) ——> Insurance Company (can use their private key to open re-encrypted blood test)

*You (create a private key derivative) ——-> Nucypher Nodes

Your private key derivative can then be used with other public keys if you wish multiple parties to receive your data, this can also be done automatically using set protocols for ease of integration.

Nucypher Part 2: Token Economics

In order to keep these encryption nodes running there must be a community incentive for people to run them. This incentive comes in the form of the Nucypher token. When people who are running nodes complete these encryption tasks they are paid with Ethereum by the people who need these tasks completed along with an inflation fee of nu tokens depending on if they own a stake of nu tokens assigned to their node. Other people can also stake their own tokens to the worker and earn an inflation fee of nucypher tokens. When these inflation tokens run out in ~5 years the staker will be compensated with service fees through Ethereum payments.

The nodes with the highest amount of Nu staked have the highest chance of receiving data that needs encryption services since there is the most trust allocated to that node by the community. If the worker of the node does something wrong such as create a faulty encryption his stake may be slashed as a punishment.

Staker: Locks Nu tokens into a contract with a set time duration which are assigned to a worker node

Worker: network node that performs encryptions on behalf of the staker

This partnership between the staker and the worker benefits both parties, if more people stake on a specific node that node will receive more work to process and thus benefit the person running the node because the node has a higher amount of trust in the network. However, this also benefits someone staking to the node because they also earn rewards for the work that the node produces.

[Nucypher and Keep Protocol]

Nucypher’s main focus is the use of proxy re-encryption for private and secure data transfers, while Keep Protocol’s main focus is their “Random Beacon” which allows for more secure and private data storing (and their creation of tBTC).

By merging both networks Nucypher would not have to compete with Keep Protocol’s tBTC which is a solution for the integration of Bitcoin on the Ethereum network. Instead, Keep Protocol would be able to use the larger amount of nodes that Nucypher has implemented. This merging of networks would allow for increased focus on converging issues and open up new opportunities for the launching of tBTC v2 on the Ethereum blockchain and beyond. Thinking ahead of tBTC v2 both projects will retain their focus on their own prospects while the intertwining of their services and networks could significantly expedite their progress.