Hello to the community!
Today I’m writing to talk about the past, present, and future of Secret Network – and to share some plans that to this point have never been shared.
The Secret ecosystem has always been proud of our ability to iterate fast and be at the forefront of pragmatic privacy-preserving technologies that can be deployed in production. Seven years ago, we were the first team to even talk about privacy for Web3 when I published my original whitepapers (including “Decentralizing Privacy,” now with over 2,000 citations and the currently most-cited paper about privacy on the blockchain). Over two years ago, Secret became the first privacy-preserving smart contracts L1, which is still the case today.
But as Secret Network grows, along with Web3 itself, the time has come to think bigger about our privacy vision and how to ensure that we are always at the forefront of both research and development. We never want to be stuck in a local maxima; rather, we want to always be the market leader in Web3 privacy solutions that are active in production. We always want to push our solutions to be more secure, more performant, faster, and lower cost – especially as adoption rises.
We refer to all development to this point as “Secret 1.0”: a live Layer 1 blockchain and a relatively mature ecosystem of privacy-preserving applications in production. Today we’ll talk about “Secret 2.0”: where new research and development is taking the ecosystem next.
A full release of the collective Secret 2.0 vision would require an in-depth whitepaper featuring everything from technical minutiae to economics. Today is not that release. In this post, I would like to share a couple of critical pieces of the roadmap for raising Secret’s privacy solutions to yet another level:
- Bringing forth a companion network – a threshold fully homomorphic encryption (FHE) Layer-1 that alongside enclaves provides the best-in-class privacy solution
- Hardening SGX (and other supported enclaves) using both cryptographic techniques and practical engineering techniques
With these improvements, the future of Secret looks more like a bright constellation of interconnected privacy solutions rather than a single star. Let’s take a look at both of the above strategic paths and how they will help define Secret as the privacy hub for all of Web3!
At the close of this post, we will also include a call to action for researchers, developers, and partners interested in contributing to Secret 2.0. If you are an independent researcher, developer, or team that is interested in joining this effort, please reach out to SCRT Labs using email: [email protected]
Want to learn more about where Secret already is today? Dive in here.
Threshold Fully Homomorphic Encryption for Secret Contracts
We have always stated that the mission of Secret is to bring the most pragmatic and practical privacy solutions into production systems. Privacy is too important to only discuss in an academic setting – it is needed by users today. However, we keep a very close eye on all new academic advancements to understand when and how new solutions could be deployed in production for the benefit of developers and users. Security is an ever-evolving space!
We’ve commented in the past that secure enclaves were (and really, still are) the only technology currently ready for use in a generalizable smart contract network. Enclaves provide faster performance for lower cost over more use cases. This is why we focused on their use in Secret 1.0.
However, we’ve always considered how combining multiple technologies could lead to better production-ready solutions. Thanks to recent advancements, we are now exploring fully homomorphic encryption (FHE) as a serious option for strengthening Secret as a privacy hub.
A new FHE-based companion network (name to be revealed) is planned to look and feel very much like Secret, and we’re currently working on an interesting way to interconnect the two in a cross-beneficial manner. But for the purpose of this blog post, I’d like to focus on the technical design of such a chain and how it can provide the most secure solution for solving the privacy problem.
The network will leverage Fully Homomorphic Encryption for privacy, which is a scheme that allows you to compute over encrypted data. Essentially, it maintains the invariant of:
FHE schemes have improved performance by leaps and bounds in recent years, and the trend seems to be continuing. Via the use of GPUs, FPGAs, and eventually ASICs, we can expect a 1,000-10,000x increase in the next few years. The advancements are promising and there’s now good reason to believe FHE can become scalable enough in a fairly short term.
But there’s one problem. FHE itself can only work with a single key, so how do we deal with a multi-user environment as is the case in blockchains? We need to essentially use a multi-party-computation (MPC) variant of FHE called Threshold FHE. As the name suggests, Threshold FHE allows each server to run any computation over the encrypted data, but in order to decrypt the output, a certain threshold of nodes must work together to decrypt.
So how does this fit into our companion network? Essentially, with a proper Threshold FHE scheme, we can have the validators share the encryption secret key among themselves. This can be fairly easily achieved with a simple DKG protocol that is highly efficient. Using mobile proactive secret sharing, we can essentially move shares from validators that leave to those that join. The ‘proactive’ part would ensure that any attacker can’t slowly corrupt validators over time, as it requires the validators to refresh their shares of the key every certain amount of blocks.
With this setup, sending a smart contract transaction to the network is fairly trivial:
- The user sends a transaction calling a function in a specific contract, while encrypting all of her data using the public key of the shared network key.
- All validators run consensus as usual, while computing over the encrypted data. This is basically similar to how Secret works today, except the computation is done directly on the encrypted data without decrypting it in an enclave.
- Using this scheme we can achieve input, state, and output privacy just like in Secret today. (For output privacy, all validators should run a key-switch protocol which does a threshold proxy re-encryption to switch the output to be decryptable with a key that is only known by the user.)
One important note to mention is that each validator will get a share of the decryption key according to their stake. It would require 67% of the staking power to decrypt the network. This figure is in line with the number of votes to approve a block, so it makes sense.
One problem with this design is that validators can collude, and collusion is trivial and undetectable (write a few lines of code that allow validators to exchange the secret key shares off-chain). For this reason, we believe that for this work we will need to combine these cryptographic techniques with SGX or a similar TEE (ideally multiple TEEs using multiple architectures). By doing so, we increase the barrier to attack – you now need to get all validators to collude, which becomes extremely unlikely when TEEs are used.
However, it’s also important to note that running FHE inside an enclave is probably a bad idea. As mentioned, scaling FHE will itself rely on the support of GPUs, FPGAs, or ASICs, which is not compatible today with enclaves. Luckily, it should be easy to see that we only ever really need the threshold decryption key in case of a key switch or a threshold decryption. The entire actual encrypted computation can occur outside of the enclave, which would greatly help with performance. Also, limiting the enclaves themselves to focus on storing a key-share and running a specific key switch / threshold decryption protocol means that it would be much easier to protect that enclave from any potential attacks.
Hardening SGX and Other Enclaves
Introducing cryptographic solutions like FHE into our privacy constellation will significantly improve Secret’s offering to developers and users alike. However, there is much more we can do in the meantime to harden our existing network – as well as improve its future flexibility. Most of these ideas also look into combining more advanced cryptography together with SGX, in a way that leverages the benefits of secure enclaves but does not rely solely on them.
Thresholdizing the master key
I very recently wrote a forum post that described how we can retrofit a recent paper by Momeni et al., which leverages Identity-Based-Encryption (IBE) with secret sharing to distribute Secret’s master key, which is the main source of entropy used to generate encryption keys for users’ transactions, state encryptions, on-chain randomness, etc.
The idea proposed essentially splits the current master key, which is present in every enclave (and therefore breaking a single enclave would be sufficient to decrypt all data), into shares of the key, such that one would require the shares from 67% of the validators to actually be able to learn the key. Since all these shares also live in enclaves, the same argument from the Threshold FHE chain above stand: needing to break the enclaves of the majority of the network is likely impractical in any situation.
The secret-shared master key will then be used to generate a derived key for every block. The interesting part is that users can a priori and independently generate the corresponding public key for every block, thus keeping the client-side encryption of transactions non-interactive as is the case today. Furthermore, all validators can generate their derived share of the secret key independently as well, and for each block attach that as part of the consensus mechanism. This means that enclaves learn a specific block’s key just in time to run the computations, but they never learn the master key!
We can use the same mobile proactive-secret sharing technique from the FHE chain to make sure the master key shares are periodically refreshed and moved from old validators to new ones, to improve both security and availability.
Forward Secrecy?
The scheme above essentially uses homomorphic encryption and Multi-party Computation (MPC) to prevent a potential leak of the master key even in an SGX catastrophe. Similarly, it better protects against collusion, which all MPC techniques are vulnerable to by keeping all their key-shares in their enclave.
This is great, but there’s still one big challenge to address. Validators learn a block’s key once every block. If an adversary sits on a compromised enclave, they can slowly collect keys and decrypt blocks. This is still limited in scope if you assume there’s a limited time window between being able to compromise an enclave and fixing it. Over the years, as enclaves become more and more battle-tested these should become rare and unlikely, but they are still a form of attack. Perhaps more concerning, a new validator who’s just starting out and wishes to process all historical states can instantly take a compromised enclave and learn all history.
This concern needs to be addressed with some form of forward secrecy for privacy-preserving blockchains and is likely relevant to whether you’re using enclaves of pure cryptographic solutions that need to store keys in the network. Forward secrecy essentially means that any specific key that leaks should not reveal more than a little bit of information (e.g., a single transaction or a block worth of data). This is to some extent achieved by my proposal above, but there should also be a mechanism that limits one’s ability to retrieve all keys in one go.
This is currently an open research topic that we are looking into and are inviting other researchers to collaborate with us on! It potentially has a lot of other implications as well.
Two-party Computations
Secret 1.0 has a very interesting and peculiar property – it can store and operate on private data while, like any blockchain, ensure that it’s always executing the contract code properly. Additionally, like any other blockchain, it’s always online.
This presents a really interesting type of application, in particular for extremely sensitive data like wallet and cryptographic keys, passwords, and seeds, where we may not want to fully trust SGX alone – but in a similar vein, the users themselves would not want to trust themselves to properly manage those keys.
The most interesting and useful current use case we see for this is that of unstoppable threshold wallets, but this should only serve as an example. These wallets essentially split the wallet key between a user and Secret – each gets one share. On Secret, a user can define an access policy, such that if their key is ever compromised, the chain would notice a suspicious behavior (e.g., someone trying to drain their wallet) and would block it. On the other hand, it’s fairly reasonable to assume that no attacker will be able to compromise both the share stored on the network and the user’s share of the wallet, especially if we continue to use techniques like proactive secret sharing which refresh the shares every so often.
To enable this technique, we’d need to add support and build several building blocks into Secret, such as additively homomorphic encryption and threshold-signing protocols. We will need to retrofit them to work without being compiled into WASM for performance/gas-cost issues (similar to what Ethereum did in the past with the on-chain verification of certain zero-knowledge proofs). One such pilot is currently planned with a design partner.
This should illustrate a much greater class of two-party computations, where a user’s sensitive material is split between the user itself and Secret.
Now What?
Here I will restate what has always been part of our mission as Secret Network: bringing pragmatic privacy solutions to market so that they can be used in production by millions of global users.
The Secret ecosystem – from its core developers to its validators to its dApps to its passionate users – has proven that we will do anything it takes to ensure our vision of a more secure Web3 future becomes reality. That has meant building and using applications that are at the bleeding edge of our industry for the past years. Now we are asking you to join us as we strengthen our network from its first iteration to its next more powerful form: a constellation of interconnected privacy solutions that makes the collective foundation ever stronger and positions Secret as the Web3 privacy hub.
There are many other topics we could have touched on in this post, including vertical scaling via rollups, horizontal scaling via IBC, and much more. This is just a first look at Secret 2.0, which will be a highly complex endeavor that is inclusive of substantial community effort.
Today we have dozens of live private-by-default dApps leveraging Secret Network; in a few years, we aim to have thousands. Today we have 250,000 accounts on Secret; we aim to add many millions more. By combining these technical improvements with an aggressive approach to developer and user growth, we can ensure every Web3 user has access to strong privacy solutions.
A more decentralized internet requires privacy to be truly empowering. By a similar token, privacy solutions will require decentralization to be sustainable. Secret Network is where decentralization and privacy intersect – providing the right foundation for users now and in the future.
Get in Touch
Much of what is proposed above is already an active area of research and development, but we are constantly looking for the very best partners as we continue to pursue this goal of global adoption. If you are an independent researcher, developer, or team that is interested in joining this effort or in a joint venture, please reach out to SCRT Labs using email: [email protected]
scrtlabs_admin
Secret Network also has grants and other resources available for developers who want to contribute to our privacy mission. If you’re interested in building your own Secret Apps, check out our developer resources and learn how you can get funding to support your projects!
If you’re anyone passionate about ensuring Web3 users has the data privacy protections they need and deserve, become a Secret Agent! It is our mission to make sure the decentralized web we’re building is one that truly empowers – and one that is accessible to all. From awareness and education to international growth and university relations, there are many ways to help transform Secret into the Web3 privacy hub and ensure the global availability of privacy technologies.
Check out the Secret Agents program and join one of the best and most committed communities in the entire blockchain space!
Onwards and upwards!
