The problem Harpocrates solves

Fully Homomorphic Encryption allows you to keep your data private, which was never possible before. To be able to get analytics on your data, you would usually be required to decrypt it from you database, send it to a third party so they can crunch the numbers and get it back to you. This means that to gain insight into your own data, you have to give it all away. With FHE, you don't have to, these same insights can be gotten while never ever revealing the inputs (and even the output!).

By merging FHE and permanent decentralized storage, you get censorship resistance, always-on encryption of your data and on top of that you can run computations on it. I had to also add Zkproofs to it, to ensure that the votes are valid.

The current POC is a simple voting application, you can vote by submitting a transaction to arweave with your encrypted vote. Thanks to the properties of FHE, anyone can go and fetch all these transactions and even compute them, but won't be able to decrypt neither the input nor the output.

It's not all rosy, as I've outlined in the "Limitations" section of the readme, but this has the potential to unlock a lot of very interesting interactions (read the Future Possibilities section for some alpha!)

Challenges I ran into

FHE is still in its infancy - the research is diverse but good quality libraries are hard to come by. I had to go for a not so ideal FHE scheme (numerical BFV) which in its current state does not allow for comparisons. So one has to be clever as to how they create "contracts". As these libraries are not so mature, I had to directly fork them and change a few things for myself :P.

Also this scheme has a "noise threshold" meaning that you cannot do an infinite amount of computations. As the noise level increases, you chances of actually being able to decrypt the output lower and at one point it becomes impossible. There are some techniques (bootstrapping) that exist to go around that, but it wasn't readily available. Decisions on the specific use case for this application had to be made given the constraints.

Currently too, with this scheme it is not possible for me to create a proof that the encrypted data is a valid piece of data (as in within constraints that I set beforehand). There are some great developments towards that goal (check the readme again for more details).

This was a first "big" project in rust for me, so it was good to get the practice!

Lastly, the ZkSnark/Starks/bulletproofs ecosystem is growing immensely which is great, but I find there are no great tool as widely used as snarkjs for it, hence why I'm making syscalls to snarkjs in the rust code. You gotta adapt!