Fully Homomorphic Encryption (FHE) enables computation on encrypted data without decryption, allowing smart contracts to process confidential information while maintaining public auditability of contract logic and transaction metadata. The fhEVM implementation combines FHE with Secure Multi-Party Computation (MPC) for key management and Zero-Knowledge Proofs for input validation, creating a privacy-preserving EVM that supports applications like blind auctions, private voting, and confidential token transfers while preserving the transparency benefits of public blockchains.
Fully Homomorphic Encryption for Smart Contract Privacy | Zama fhEVM | ETHDam 2024
Added:[Music] okay up next we have Torah talking about uh zama's uh FH evm uh I'm looking forward to this one we've been chatting about this like for quite a bit over the last couple of days thank you for the introduction so yeah I'm to fixon um I'm going to be talking about uh Sam FH evm basically how to get privacy on top of of an evm on a blockchain so just a little information first about like what s is s is a cryptography company uh we provide open source homomorphic encryption solution for both Ai and blockchains those are the main two use cases Although our core is uh fully homomorphic encryption for those of you who don't know fully homomorphic encryption basically um enables you to compute on encrypted data blindly so you can encrypt some data x uh send it to a send it to a server who can then evaluate any function on the encrypted data and return the output to you which you can then later uh decrypt so if it's only you doing this it doesn't make much sense unless uh you're considering a case like um Outsource computation but fortunately uh fully homomorphic encryption allows composability so this means I can encrypt some data you can encrypt some data and so on and we can compute collaboratively any any uh touring function any touring complete function on this encrypted data uh which can then be decrypted to the relevant parties um later on uh has been an elusive uh an elusive primitive for many many years uh cryptographers saw it as the Holy Grail of cryptography and thought that it would basically be impossible uh and then in 2019 Craig Gentry came up uh with a very brilliant paper that showed well you can actually do this it's very very slow but it is possible um since then there's been a lot of research from the cryptographic community and this primitive and how to optimize it and make it work faster and get more practical which is also what we're seeing today and you know there's a mass acceleration still we're still in the early days of of FH so we expect it to get much much faster within too long especially once uh specific custom hardware and things like this ends up being uh being made for for FH so I mean this is a conference about uh privacy and there's been a lot of talk about different Primitives uh so just want to highlight the difference between like the main three Primitives uh for for encryption we see here in the blockchain setting we have a FHA for the homomorphic encryption zero knowledge and secure multiparty computation NPC like all of these primitive offers privacy in some form or another uh so they have all that in common but the specific characteristics of each of these is still um still different for example the only one that offers decentralization in the sense that um that keys and data is not stored on a single entity is MPC the only ones affording composability is FH and NPC zero knowledge only makes sense if you're one person with a with a secret input you can't really compose things um finally in relation to interaction uh only and zal knowledge allows evaluation non interactively whereas requires rounds of communication between each party for every multiplication uh every for the multiplicative depth of the circuit you're Computing so all of these have some advantages and disadvantages and uh they complement each other very well and as I will explain in a few slides we actually use all of these three Primitives in U in our solution uh first I want to give a little outline of uh what exactly we are we have here at s and uh what's proba now so basically we start with the the lowest layer the hardware layer like uh we have bunch of different solutions working on top of CPU gpus uh hopefully in the future um um hopefully in the future custom Hardware uh can can also be can also be applied um on top of this we have our core Library which is tfhs uh which is an open source uh Library you can go download it on on GitHub it's stable and usable which allows valuation of homomorphic operations on encrypted data it's uh very user friendly I'll show you a little snippet of quote later on uh in order to use this in a sensible way we have a compiler called concrete which compiles python code down to the circuits that needs to be fully homomorphically evaluated so this allows you to basically write standard python code with a special uh with an imported Library uh that um that basically gives you encrypted variables on top of this we have concrete ml uh which is our machine learning library that works on top of of concrete and TF RS the reason we have a specific library for this is there's a bunch of mathematical tricks you can do in FHA to allow like say sigmoid functions other kind of machine learning based uh based functions quite efficiently this can then be used for applications such as credit scoring for detection you know so on uh then what I'm talking about today is the FH evm which is fully homomorphic evaluation of the smart contracts um which then gives a rise to confidential blockchain that can give you like secret token swaps blind auctions and so on of course you can also build stuff directly on top of concrete uh and TFS uh to allow data collaboration biometric validation private s intersection um and and other cryptographic Primitives that require FH um okay so in the blockchain setting we basically know uh blockchains are public by Design it's it's a ledger a pend a pend only Ledger where you you put data that you know will always sta that would be validated so you have a transcript of everything that has been going on and this is great for a lot of different applications where this is what you want uh but for other applications it's not uh the most ideal setting and even some applications where you kind of want this it also leads to some uh to some problems uh for example in the currency setting it can lead to theft because everyone will know which addresses have a lot of money which addresses sent to this address and where they send out money to uh it can lead to surveillance uh since everything is public analysis of transaction patterns can be analyzed by uh private companies or governments uh for whatever reason uh they they want to do it since all the metadata and amounts and so on is is there and finally it can also lead to minor extractable value since the validators know the transactions before they actually carry them out and can lead to front running attacks so by um by adding encrypted variables with our fhvm we allow smart contract to be evaluated um using homomorphic encryption and thus securely so this allows into an encryption of transactions and State uh composability between uh between different smart contracts and different uh different clients um while we build this on top of the existing evm you uh with with solidity so it means it doesn't break any existing uh existing state or daps something you can add on top um so this basically means that the values you compute on remain secret but the contracts and the trans who transacts what when and to whom is still is still public so you get like kind of uh The Best of Both Worlds in that users can still audit the contract they know when the data will be used they know how they will it will be used people can still audit the the blockchain uh to some extent but you still get the privacy of having the actual variables um hidden and this can for example be used for for for Access Control and different kinds of uh of composability some specific use cases for this is uh is tokenization of private tokens uh blind auctions uh with bits where the bits are are hidden voting where the votes are hidden and you only get the result it has applications to a decentralized identifier since now you can have identifier validation on the blockchain without uh revealing your actual variables only whether or not you fulfill a certain policy that's required it allows private transfers uh it can be visible to see who is transferring to whom but not how much so you get a p so you get a privacy of of the amounts of tokens you have and who you receive from uh sorry and uh yeah how how how much you receive uh finally another use case is onchain gaming because we have this encrypted uh encrypted State we can simply have a random uh seat that no one knows that can be homomorphically evaluated in a prf which allows for cryptographic Randomness to also be used in smart contracts so there's a lot of exciting use cases you can add on on top of the evm by uh by using this so I want to give a little bit more of uh some deep details on how exactly this uh this works so as I mentioned we use like the big three privacy preserving uh cryptographic Primitives to uh to achieve this FH MPC and zero knowledge basically we consider the setting where we have the blockchain uh which is a layer one blockchain that's evm compatible although running with custom validators because they do need to run the code to evaluate the uh the the fully homomorphic circuits we have one Public public key uh which everyone will encrypt under and all the validators will will know this key uh the secret key will never exist in plain anywhere the secret key will be secret shared between uh a set of the party that that realize a key management service and this is done using uh using MPC so for for the setup phase of this when you start the blockchain first you run a key gener distribute a key generation protocol between the KMS uh KMS server such that each of them learn a share of the secret key and the public key gets posted to the blockchain so now when a user a client wants to encrypt some some data for a specific smart contract they just use the public key to encrypt it and can distribute this with the validators the validators can then carry out um operations uh in accordance with the logic of the smart contract uh to learn the encrypted output uh and at some point when they require decryption of it in accordance with the logic on the smart contract they ask the uh the threshold the threshold servers of the KMS to do a decryption of the variable it's also possible say if you're a client and you are realizing an encrypted esc20 uh contract you want to know how many tokens you have right uh let's say I have a a patreon bucket like for people to donate for my open source work if everything is encrypted I don't know how much money I have uh so uh to allow this we also offer a re-encryption uh where basically uh the the the client supplies a normal public key to be to get encrypted under and then the KMS servers will do a partial decrypt of the actual value encrypt this under the public key and send this back to the client so the client can decrypt and reconstruct the actual value so in this way we also support a private opening of uh of any uh of any variables if it's in accordance with the logic of the smart contract of course so this allows us to realize uh realize view functions so what's actually going on uh inside the FH evm uh is uh just the evm and a bunch of pre-compiled smart contracts with which calls down into some of the S libraries so the the way it it's handled is that the smart contracts work on handles of Cipher text a handle is just a hash digest of a uh of a given Cipher text uh which is then processed through a pre-compiled smart contract and can be posted to um some protected memory it can either be stored on the chain or can be stored using PFS or filecoin or an other external service what is done in this protect memory is just a map from the handles to the cipher text and an access logic where the access logic is about whether or not a given contract or user is allowed to decrypt the cipher text so once a user uh wants to add something uh post an encrypted value to the smart contract they uh they encrypt this and they construct a SE knowledge proof that they know the value that's encrypted why is this needed well because otherwise I could take any smart any uh Cipher text I see on the blockchain put into another contract and ask for that to be decrypted so we don't want that so you need to actually know to to you need to know what the input is when you add an input to the to the blockchain then this calls into a pre-compiled contract which calls down into the TFS library that validates uh that validates the cipher text and if everything is okay it gets stored in the protected memory uh on handle and a list of uh an access control list uh in the same way like decryption is handled with a call through the pre comp pre-compiled that takes uh that looks it up in the protected memory and calls to the KMS um which then does does the decryption assuming the pre-compiled validates that the calling contract is actually allowed to uh to decrypt uh when it comes to the execution of uh operations uh fully homomorphic operations it's kind of the same again the smart contract calls into the pre compile that fetches from the protected uh protected memory uses TFA GRS to actually do the computation on the the cipher text the resultant Cipher text and updated Access Control list in accordance with the logic is then uh then sted in the protected memory and a handle is returned to the underlying smart contract so that's overall high level how it uh how it works uh I have here a snippet of code just an example of how you might use this to do an encrypted ESC esc20 so we have here a uh we have here a contract which basically um in solidity that basically has an internal map of addresses to balances where the value is an encrypted unsigned 32-bit integer uh then we have two functions transfer and balance off where the transfer is uh simply taking addresses from and to and an amount it then uses um the TFA GRS to uh to check that that the amount is less than the balance of the call of the from address uh and if this check passes then it simply uh then it simply adds uh the balance the two address and subtract subtracts it from the from address that's basically it the balance off here is then allowed to basically learn the balance of U of an address using the decryption uh so that's basically it so as you can see it's it's it's quite streamlined it's pretty straightforward uh to do if you already have solidity to just add these uh to to just add these aspects of uh of encrypted variables uh for where you need it in your contracts so that's Bas more or less what I wanted to say today I wanted to also say we do have a grand and a uh Bounty program so if you're interested in playing with this every quarter we have new bounties uh which are basically challenges to use our our code or to construct uh construct something uh it could for ex um like one one was we had previously which was a very hard problem was doing a um secret uh signing like do ecdsa using fully homomorphic encryption but we have a bunch of different uh different challenges which you can uh can look up at our Bounty program um so the TFS concrete concrete ml all of these are open source already out and running and you can find the code on uh on GitHub uh uh for the whole blockchain thing we have a white paper out which uh which you can uh which you can also find on our GitHub repository and have a look at um the blockchain like the whole KMS thing is still a bit uh work in in progress we have the the we have some limited versions out already that you can play with so you can actually launch this FH evm uh using using Dogg and play around uh the last bits and pieces we are missing and which are coming during uh during this year uh is the whole full flow of setting up all the threshold uh threshold threshold notes uh running the distributed decryption and uh and key generation so that's coming um later later this year uh finally we're also hiring so if you're interested in working with us you can go have a look at uh our open open positions um and that's basically it thank [Applause] you so have any questions yeah that's what we like to see so I actually wanted to ask about the signature you said that that's already completed you have the signature over encrypted uh uh Secrets or like signature of uh data um so so we had a challenge about doing uh doing this using fully homomorphic encryption and as we kind of suspected especially if it's ecdsa it it's a funky ecdsa is a very funky signature that has very little structure and a lot of weird stuff happening so it was horribly inefficient to to to do an FHA like that that specific one um so uh we don't have that valuea in F like if you wanted to do this it does make more sense to just use NPC directly uh to do that it was more of a feasibility yeah know I was curious because it sounds like a super interesting uh option to have your you know your key encrypted somewhere and then they can manage fonts or whatever would be great like to be able to sign data sign things uh do you have any data in terms of performance um you know how much time takes to run one of these oper or like in terms of certain operations that you manage both in terms of AI or signatur Hing yeah um so FH FH is still like not super fast so it's you need to be a bit selective with where you are applying these uh these operations uh General arithmetic operations over over integers are like kind of the fastest the same with comparisons and stuff like this they're usually around uh like uh 50 to 200 milliseconds depending on the operation and like whether you know you're an 832 or 64bit uh 64-bit integer so it's around that vicinity on a uh AWS uh metal uh server um of course like a lot of things many things can be powerized if you throw more resources at it yeah um Hardware availability you mentioned Hardware uh is there like who's behind it like is Intel doing something will it be something we can expect uh to have in a CPU for example like we have TPM now um I'm not part of uh of those of that part uh that part of Summer um I I I know a business developer are talking with different companies like you know in in investigating uh the options like for now we have uh we have Hardware that is fpg fpga uh made for this um I don't expect this to be something we see in an Intel chip anytime soon I think it will be more like you know separate companies uh coming out with modules like uh you know like a GPU then you have a I wanted to say CPU but that for crypto Processing Unit but that that name is already taken right um uh but I I'm I I I I I don't know um I don't know exactly um homeomorphic Processing Unit yes yeah amazing thank you so much that's all we've got time for uh another round of applause thank you than [Music]
Up Next

Implementing FHE on Ethereum: The fhEVM Co-Processor Approach
@zama_fhe
1.6K views•2024-07-09

Torrent File Format & Bencoding: A Technical Deep Dive
@AsliEngineering
12.5K views•2022-08-08

Operational Security Essentials: A Guide for Hacktivists (OPSEC)
@hitbsecconf
157.4K views•2012-11-26

Understanding Ethereum: A Comprehensive Beginner's Overview
@99Bitcoins
3.1M views•2018-06-26
Related Study Plans & Knowledge Roadmaps
Structured learning paths in Blockchain & Crypto























![[Tutorial] Secure your dApps with Access Control List (ACL) in fhEVM](https://i.ytimg.com/vi_webp/ZJ2jLckBqB0/maxresdefault.webp)













