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.