Introduction
Sunscreen is an ecosystem for building privacy-preserving applications using fully homomorphic encryption (and later on zero-knowledge proofs as well).
Problem
Some cryptographers think the solution to crypto’s privacy concerns lies in zero-knowledge proofs (ZKPs), a technique that allows for a transaction to be verified on a blockchain without the underlying data being shared.
While zero-knowledge proofs could indeed improve privacy and scalability for some of the most popular blockchains, they are far from being the only cryptographic method that could accelerate progress in web3.
Existing solutions fall short in achieving this goal since they support a limited operation set, enable private computation on inputs belonging to only one user, or even ask the users themselves to coordinate and perform the computation off-chain.
Solution
To address these limitations, smartFHE was proposed. It is a framework to support private smart contracts using fully homomorphic encryption (FHE). To the best of their knowledge, smartFHE is the first to use FHE in the blockchain model; it is also the first to allow for building arbitrary smart contracts that operate on multiple users' inputs on-chain while preserving input/output privacy. smartFHE does not overload the user since miners are instead responsible for performing the private computation.
What is Fully Homomorphic Encryption (FHE) ?
Fully homomorphic encryption (FHE) is a special kind of encryption scheme that allows anyone to perform computations directly on encrypted data.
FHE is relevant to public distributed ledgers (such as blockchain) and machine learning.
From here on, it’ll get a bit technical, so bear with me.
Review of Encryption Schemes
Plaintext is data in the clear (unencrypted data) whereas ciphertext is encrypted data.
An encryption scheme includes the following 3 algorithms:
KeyGen(...security_parameters)
→keys
: The Key Generation algorithm takes some security parameter(s) as its input. It then outputs the key(s) of the scheme.Encrypt(plaintext, key, randomness)
→ciphertext
: The Encryption algorithm takes a plaintext, a key, and some randomness (encryption must be probabilitistic to be "secure") as inputs. It then outputs the corresponding ciphertext (i.e. encrypted data).Decrypt(ciphertext, key)
→plaintext
: The Decryption algorithm takes a ciphertext and a key as inputs. It outputs the corresponding plaintext.
Private Key Encryption Scheme
In this scheme, the same key
is used to both encrypt and decrypt. That means anyone who can encrypt plaintext (i.e. data in the clear) can also decrypt ciphertext (i.e. encrypted data).
Public Key Encryption Scheme
In this scheme, different keys are used to encrypt and decrypt. An individual may be able to encrypt data but have no way of decrypting the corresponding ciphertext.
Evidently, the public key encryption scheme are the most useful. So we will turn our focus to the homomorphic (public key) encryption schemes. The "homomorphic" part implies that there is a special relationship between performing computations in the plaintext space (i.e. all valid plaintexts) vs. ciphertext space (i.e. all valid ciphertexts).
How does it work?
Every time we perform a homomorphic operation, we add additional noise to the ciphertexts. At some point if the noise gets too big, you won't be able to successfully decrypt the ciphertext.
What's needed to build a fully homomorphic encryption scheme?
All FHE schemes use a specific type of post-quantum cryptography called lattice cryptography.
The good news is that FHE is resistant to attacks from a quantum computer.
The bad news is you likely have no familiarity with lattice cryptography even if you've taken an introductory cryptography course before.
Congratulations, you’ve made past the technical aspects. If you wish to geek out on more technical explanations and specific relationships the homomorphic encryption schemes hold, head over here for a more detailed summary!
Why do we care about this?
Private Transactions on a Public Ledger (e.g. blockchain). A private transaction scheme allows a user to securely send digital currency to some recipient without revealing the amount being sent to anyone (apart from the intended recipient) on a public distributed ledger. This is in contrast to cryptocurrencies like Bitcoin where transactions and balances are all public information.
This can be extended to more interesting financial applications such as auctions, voting, and derivatives.
Private Machine Learning. There has been an increased interest in the last few years around how we might be able to "learn" from data (via machine learning) while still keeping the data itself private.
FHE is one tool that can help us achieve this goal.
Why FHE has yet to have received widespread attention? What are some potential solutions to these issues?
Three pointers:
Many Different Schemes (aka everyone is speaking a different language)
Efficiency
Usability
Many Different Schemes
FHE schemes model computation in one of three ways - as boolean circuits, modular arithmetic, or floating point arithmetic.
One has multiple options for FHE schemes that fall under the same computational model, meaning a developer has to probably play around with the various schemes and implement your specific use case with both of them to determine which is best.
Different schemes tend to use different techniques to control efficiency and noise growth. Additionally, the schemes have different parameters one needs to understand in order to set them properly. The parameters affect the security of the scheme, the number of homomorphic computations allowed, and the overall performance of the scheme.
To summarize:
One does not know the tradeoffs between the different FHE schemes or how the schemes relate to one another
One has to invest a lot of energy into understanding a single scheme
One has to understand that the knowledge gained from understanding one scheme is not really transferable to learning a new scheme (under a different computational model)
Potential Solutions
Updated and improved benchmarking efforts
Better resources / guides to explain tradeoffs between schemes
Ability to move between different FHE schemes (i.e interoperability)
Efficiency
Number of Computations: Some FHE schemes allow you to perform a truly arbitrary number of computations on encrypted data. Many schemes, however, only allow for a certain number of homomorphic operations to be performed. After that point, there's no guarantee decryption will be successful. This means that the schemes that only allow for a truly arbitrary number of homomorphic computations suffer from very poor performance.
Plaintext Space: The larger the plaintext space, the slower it will be to perform operations.
Key Sizes: Some keys you'll need to access in the scheme can be 1 GB large! The performance, in terms of timings, may be decent but you're instead left with a giant key you need to store.
Large Ciphertexts: When working with FHE, ciphertext expansion can negatively affect its efficiency.
Potential Solutions
Hardware acceleration (Accelerate using GPUs)
Research breakthroughs improving FHE schemes (easier said than done)
Usability
FHE is not beginner-friendly, not user-friendly, and certainly not non-cryptographer-friendly.
There really isn't any usability for an engineer lacking a math or cryptography background.
Most FHE libraries require deep expertise of the underlying cryptographic scheme to use both correctly and efficiently.
Potential Solutions
Standardization efforts (Standards to make it clear what parameters to use, what functionalities are offered etc.)
More user-friendly libraries and examples
Potential compliers
Nevertheless, despite all these supposed “problems” with FHE, why does Sunscreen still wish to venture into this uncertain territory? Here are some recent developments of Sunscreen, and some insights from the founder, Ravital Solomon, on the goal of Sunscreen as well as plans for the future.
Recent Developments
$4.65M Seed Round
Sunscreen’s $4.65m seed round was led by Polychain Capital with participation from Northzone, Coinbase Ventures, dao5, and Naval Ravikant–following a small pre-seed of $570k.
Open Sourcing FHE Compiler
Over the past few months, Sunscreen has been working on their own FHE compiler that will be open-source. They also have a playground available that allows developers to try writing some code before installing the compiler. Check out their library here!
Sunscreen is the first to design a FHE compiler that addresses Web3 developers’ challenges and concerns. However, Sunscreen believes that this is only the first step in their journey to realize the full promise of private computation in Web3.
Sunscreen FHE Grants Program
This led to Sunscreen’s FHE Grants Program, which aims to promote further research and development into FHE. Sunscreen hopes to encourage developers to build private apps and teach others in the community how to do so as well.
Sunscreen’s goal is to make advanced privacy technology (like FHE) accessible to engineers so that they can easily build and deploy private applications. Initially, Ravital Solomon, founder of Sunscreen was a cryptographer at NuCypher researching privacy-preserving smart contracts. She believes that there’s more to Zero knowledge proofs, which have so far dominated the privacy narrative of Web3.
Future Plans
What will be next for Sunscreen? They are looking to work on the infrastructure needed to support developers in building private applications. Concretely, they will be focused on integrations with complementary zero-knowledge proof libraries as well as decentralized storage solutions.
Resources
Website - https://sunscreen.tech/
Discord - https://discord.gg/WHCs6jNNDS
Twitter - https://twitter.com/SunscreenTech
Blog - https://blog.sunscreen.tech/
Founder Intro - https://ravital.github.io/
smartFHE’s Abstract - https://eprint.iacr.org/2021/133