Expand the design space and enhance developer experience
Overview:
Data on blockchains is public which limits the use-cases centred around privacy. Think of a simple voting where you don’t want to reveal your vote or a game where you want to hide your cards.
This RFP is targeted at one of the solutions that adds confidentiality to blockchains i.e. fully-homomorphic encryption. The motivation comes from recent advancements in fully homomorphic EVM(aka fhEVM) design space. For a deeper dive, please refer fhEVM by Zama.
This RFP aims to bring in proposals for a native FHE inside the cartesi machine that developers could leverage to build their own application logic. Linux runtime provided by the Cartesi machine gives a flexible environment to test traditional FHE schemes not limited to Solidity.
We’re looking for ways to leverage FHE to open up use-cases around private token transactions, DIDs, confidential voting, hiding sensitive game moves or assets, PRNGs and other similar ideas.
Solution Criteria:
We encourage teams applying for this RFP to submit:
Solutions that are viable and optimised for the Cartesi machine.
Solutions that explore pseudo randomness generating functions.
Solutions that focus on easy to install packages and smooth integration for developers.
Solutions that support widely used languages in the ecosystem.
Solutions that dive into the nature of data flow in rollups and any possibilities of data leakage.
Can you expand a bit on the demand you see for this feature? I think an important part of evaluating RFPs is not just assessing whether the proposal is technically sound or useful in general terms, but also considering whether it’s the right time for it. Is this addressing an immediate need within the ecosystem, or are we aiming to anticipate a future demand?
I’m sharing this same feedback on other proposals as well, as I think these questions are key to making well-informed decisions. Thanks for your input!
Generally, I think running any of these novel cryptographic primitives (FHE, MPC, ZKP, etc.) within the Cartesi stack would be very cool for the confidentiality it gives to dapps.
However, I have concerns that running FHE or any other of these novel cryptographic primitives inside the Cartesi Machine may be too heavy. We should be careful, since FHE is known to be very computation-intensive even when running on bare metal, sometimes even infeasible for complex applications. I wouldn’t be surprised if FHE was too slow to run inside the Cartesi Machine, although I am completely ignoring what fhEVM does to make it happen on Ethereum (which is way slower than the Cartesi Machine). I think these novel cryptographic primitives should usually be run outside the Cartesi Machine due to their computational demands. Maybe in the future, we could have bare-metal accelerators for some common computation-intensive tasks that dapps may want (matrix multiplication, FHE, ZK, hashing), but we don’t have them yet.
So I would like more elaboration on the computational demands of this RFC, where the heavy computations are run, and how much it demands from the Cartesi Machine, so I can better understand how this is technically feasible.
Through our research over the least few months, it seems ZAMA has been working on releasing a coprocessor of their own. Though this seems to be focused specifically on making on-chain transaction details in block explorers on EVM chains encrypted to certain parties and less-so focused on encrypting off-chain data that exists “on chain” as an example.
Some of our efforts have been focused on either utilizing Python packages like pySEAL or Zama’s own “Concrete” to achieve this with financial data, as an initial use-case and we’re confident in the feasibility. This also opens the possibility of AI models continuously trained and fine-tuned on verified and encrypted data to be a possibility as an extension. Exciting stuff.
Allow me to take this one! The major motivation behind the RFP is to stay competitive in recent programmable cryptography(ZK, MPC, FHE etc) developments and at the same time open up new use-cases in the Cartesi ecosystem. Every project in this field is trying to address the same demand from the community - private yet auditable computations. It’s hard to evaluate an immediate need for this but generally, it’s great for experimenting with cartesi as co-processor, as leading projects fh-evm and fhenix are moving in that direction. In my humble opinion, we quickly run out of use-cases when thinking about something like a co-processor, diving into FHE could be one of the catalyst.
FHE is a vast field with only a couple of projects actively researching in blockchain and FHE intersection. I believe we should take a small step - if not a huge effort right now - to prove Cartesi Machine as a de-facto runtime for all your blockchain dApps.
From a tech pov, the current schemes like Zama do not run end-to-end FHE on all the computations and data on EVM rather they provide devs with FHE-supported opcodes and variables making EVM smart contracts a mix of public and private computing. For curiosity another project - fhenix, an optimistic rollup - is a wrapper around Zama’s tfhe-rs FHE libraries.
Great to see other comments. This is quite a broad RFP, any concrete step in this direction would be interesting to watch.
Hey Pedro! Just to clarify, this RFP is of a “Broadly-Scoped” type, hence the deliverables were intentionally left open-ended to encourage exploration.
That said, we’re looking for a working solution that aligns well with the Cartesi stack. For instance, a simple yet popular use-case is a Voting dApp where the only confidential variable is the user’s vote. Here, FHE would be leveraged to encrypt and conceal individual votes, while the final tally remains publicly accessible and transparent. This approach keeps FHE computation minimal, focusing solely on safeguarding voter privacy.