Private smart contracts using homomorphic encryption

Transcript

okay not so bad actually uh the others have you heard about the term at least or never okay great so this talk is not gonna be very matte heavy it's actually gonna be more conceptual but i hope that you should understand homomorphic encryption and how that works for blockchain at the end of it um at least if i can actually speak eloquently so we'll see about that we have 25 minutes my presentation is a little bit dense so i hope that we're gonna have time for questions but if there is anything i'm going to be around all day so we can always hang out and discuss more about these things all right why

uh great so my name is rand i've been a developer since i was a kid uh did a phd in machine learning 15 years ago and got into crypto in 2013 uh i then did a machine learning company that got acquired and now i'm basically working on a new startup called zama where we work on homomorphic encryption i also do quite a bit of angel investing in deep tech and crypto so my sweet spot is investing in things that most investors cannot understand um so the reason why we have a product blockchain today is that everything is public and you know you would argue but things have to be public because otherwise how can ac nodes have reached consensus on what has been done the problem with having everything public on a blockchain is that it creates a very unsafe environment

people know how rich you are so they can potentially target you you've all heard about friends you know getting mugged with a knife or whatever surveillance governments actually can trace everything you're doing despite what people think governments love blockchain because of the traceability and you know right now we have a huge mev problem where you're basically paying a hidden tax on every transaction you're making because you've got those bots basically front running what you're doing zero knowledge proofs are partially addressing those problems by enabling you to do off-chain computation so that people unchained wouldn't know what you actually do the problem is that when you have multiple users interacting well it doesn't work anymore because those users we need to somehow collaborate and if you do that off-chain you're just

displacing the privacy from an unchained privacy problem to an off-chain privacy problem and we're basically back to a normal cloud web 2 kind of privacy setup what we really want is to have full unchained privacy and the way that we can do that is using a technology called homomorphic encryption which b where basically you can do encrypted compute data computation on encrypted data so the way it works is the user has a secret key they encrypt the data with a secret key send it to the server who does the processing the server doesn't have the key to actually decrypt the data so it has no idea what it just received but it can still do processing on it produce a result which itself is encrypted send it back to the user who can now actually

decrypt it so this is really powerful because it means that you can basically offload computation to an untrusted server without having to reveal anything about the data or the result of that computation and so when you apply that to a blockchain it gives you the opportunity to actually do encrypted transactions where the content and the data included in the transaction is an encrypted uh data and not a plain text value you can have encrypted state updates we can smart contracts manipulating states which are encrypted so that nobody can actually see the unchained state and the real value of it and then finally you can also store data on chain completely encrypted and never have to worry about anybody seeing the data but you as the actual end user and so when you look at those properties it

actually solves quite a lot of problems you know there is no targeting possible you can have a wallet where nobody knows the value of the assets that you own there is no surveillance possible because you know even though people know that you've interacted with smart contract they actually don't know what you did or what you own or what you have in that smart contract and mev becomes impossible because you know if you look at the mempool you're just seeing a bunch of encrypted inputs so what are you going to front frontrun if you actually don't know what people are doing so homomorphic encryption is kind of the holy grail for unchained privacy um and it also opens up a whole bunch of new applications things like on-chain identity management things like private nft metadata that are composable or you know geolocated uh

applications where you're using some kind of very personal sensitive user data so the way homomorphic encryption works so i know that a few people here heard about it i promise this is going to be the only technical part of the talk i mean unless you want to be more technical you tell me basically but the way fhe works is that you basically have a cipher text and a ciphertext is an encryption of some data plus some random noise that you had to add to the data the reason why you need to add this random noise is because this is how you guarantee that nobody can actually guess the value of the encrypted ciphertext the problem with the noise is that when you look at the actual bits on

your computer the data is going to be on the most significant bits just the yellow stuff here and the noise is going to be on the least significant bits so you basically have your data that's in two parts on the left side you've got the data on the right side you've got random noise that's fine if all you did was decrypt you could just basically cut off the noise and then you're done but the problem is that when you're doing operations on encrypted data you're not just operating on the data itself you're implicitly operating on the noise that is in the data as well and so every time you do an operation like an addition or a multiplication the noise actually grows and eventually there is no more room for this nose to grow and it starts overflowing on the most significant bits

of data and when that happens obviously the result becomes incorrect because you're effectively randomizing bits of data instead of keeping those two things well separated and this is really the problem with homomorphic encryption is that eventually you have to stop performing computation on the data if you want the result to actually be correct so in order to avoid that kind of stuff people invented a special operation that's called bootstrapping so bootstrapping is a very expensive cryptographic operation which basically resets the noise to some kind of nominal level so you take your ciphertext you do some computation on it you see that the noise has now grown too big you stop you apply this bootstrapping operation it

puts the noise back to this original level so you can keep on going forever and by basically doing this bootstrapping operation every few operations that you're doing you basically have this infinite capability to do homomorphic computation but as i mentioned bootstrapping is an extremely slow operation most homomorphic schemes that people are used to would take about 30 seconds to actually do one single bootstrapping operation and so when people say that homomorphic encryption is slow it's not because of the arithmetics it's actually because of the need to bootstrap on a constant basis to keep this noise in check so that you get correct results so for a very long time the way people dealt with that is that they just ignored the problem and they just said

well you know what we're just not going to bootstrap we're going to use extremely big integers like you know kilobyte or megabyte integers and we're going to give enough space for the noise to grow for the whole computation and then you know we're decrypting at the end and so it doesn't matter anymore that's called level schemes you know you have the bfv bgv cks scheme which are very popular in that space the problem when you do that is that you're basically getting something extremely efficient in terms of speed but you have a limited number of computation however big and however much noise budget you're basically giving yourself in the case of a smart contract where the state on chain might be indefinitely updated so for example an erc20 smart contract

eventually you are going to run out of noise right you're not going to be able to compute forever without basically getting an incorrect value so this is the you know solidity erc20 smart contract you see this balance from where you're basically doing a subtraction in addition if this was an encrypted value you've got an encrypted balance and subtract an encrypted amount potentially eventually you're going to actually overflow the data and the result of the transfer will be incorrect so there is no actual way to guarantee that you will have an exact result unless you actually come resort to bootstrapping the second problem is that with level schemes you can only do additions and multiplications and what that means is that if you want to compute some

nonlinear function uh like i don't know exponential function or whatever or if you want to do a homomorphic comparison you will not be able to do it unless you approximate it with a polynomial approximation so polynomial's approximations are very difficult to design well so you know you would need to hand craft an approximation for every function and plus there will still be approximations so if you take again the example of the rc20 smart contract if you look at a require here which checks that a user has enough tokens to actually transfer which i think is kind of like you know the base security if this is an approximate check and sometimes probabilistically it can fail it means that sometimes you will actually pass this require even though

the user doesn't have enough balance so unless you can do an exact comparison it's impossible to guarantee that the requires in your smart contracts will actually do what they're supposed to do which is to safeguard the logic of your smart contract so it's kind of game over for homomorphic encryption at that point you're like okay so basically the choice is something extremely slow and inefficient or some random error in my smart contract which quite frankly like is not something that anybody wants so fortunately there is another scheme that's called tfhe which is one of the newer schemes which actually enables you to do exact computation an infinite number of time because it has something called very fast bootstrapping so tfh instead of basically doing you

know a limited number of additions and multiplication and approximating everything gives you this ability to do very fast bootstrapping a few milliseconds instead of tens of seconds so you can do it all the time and it gives you the ability to basically do arbitrary functions exactly as you would in plain text if it was not encrypted so you can do homomorphic comparison you can do homomorphic you know lambda functions homomorphic whatever you want the result that you will get with tfhe is exactly the result you would have gotten if there was no encryption at all so this is an extremely powerful technique which is actually very nice for smart contracts because you can basically keep on going forever without any error and you can do those requires exactly

so if you compare kind of like the approaches you've got you know kind of the older older schemes you know the leveled ones you've got a limited number of operation versus unlimited for tfhe you've got slow bootstrapping 30 seconds versus 10 milliseconds for tfhe both of them can do exact arithmetics additions multiplication but only tfhe can do exact nonlinear functions and comparisons and you can also do boolean circuits as well as integer circuits with tfh so the reason why you probably haven't heard of tfhe is because it was invented by a woman during her phd that wasn't a famous academic and so for a very long time you know big famous academics basically discredited this woman's work saying it cannot be better than 20 years of work that we all have done at mit and other

you know places uh so my co-founder in my company by the way is one of the inventor of homomorphic encryption pascal payet and he was one of the first people to recognize the power of this technology and that's the reason why we started this company so tfh if you want is the underdog that people kind of discredited but it actually is becoming the dominant paradigm in homomorphic encryption um so what we did in our company is that we made that super easy for people to do because unless you're a cryptographer homomorphic encryption is not exactly very user friendly so we created this framework called concrete which is a framework that offers very high level apis where you don't have to know cryptography to start using those things it enables hardware acceleration uh so gpu cpus fpga and eventually asics and

it's all written in rust so you don't have to worry about you know c c plus plus or that kind of stuff anymore the last thing that we need before homomorphic encryption can become practical is performance right now homomorphic encryption is still i would say a thousand x slower than what we would need in order for things to be cost efficient but fortunately the speed of homomorphic encryption is increasing by a factor of 10 every couple of years or so mostly thanks to better crypto and hardware acceleration so we're now at its inflection point where by 2025 we're expecting homomorphic encryption to become so cheap and so fast that you can use it in anything in the cloud or on blockchain without having to worry

about latency cost or any kind of other thing so homomorphic encryption today if you want is kind of where zero knowledge proofs were three four years ago when people kind of cracked the mat and the framework started to appear but it was still too slow to actually be universally applicable this is where we are with fhe and we're bridging that gap in the next couple of years so watch out for that because i think that this is going to be a pretty major topic in cryptography in the coming years and it's really just on the verge of becoming practical um so how does that relate to private smart contracts well homomorphic encryption is great but if you want to use it for private smart contracts you have to do a little bit more cryptographic gymnastics to actually

make it work out of the box so let's take an example of an encrypted erc20 what's not your c20 an encrypted token contract so this is written in rust it's a very simple contract when you read it i mean there is really no cryptography in it right you basically have a balance which is just a map between an address and a value but the value this time is not a plaintext value it's an encryption of the value so you're mapping from an address to an encrypted integer and then you've got a transfer function which takes an address from an address two and then an amount which itself is encrypted so here you know this token would give you the ability to have unchained encrypted balances as well as uh encrypted uh transfers

you've got this require function which basically does a homomorphic check that you've got enough money to make the transfer then you've got a homomorphic addition and subtraction so all of this is basically pretty much as you would have in your traditional smart contract but just replacing the integers by encrypted integers the biggest difference is to view your balance on an existing blockchain where everything is public you can just read the blockchain and then see the balance of every user but if we're talking about private smart contracts we obviously don't want people to be able to see the balance of arbitrary users we should restrict what people can see to what they're allowed to see by the contract's logic and so to do that there is this extra operation which we need to introduce

which is called key switching key switching is a way where you can homomorphically convert a cipher text that's under a key into a cipher text under another key so in this case here because all the users are collaborating you need all of them to share a key so the network has to have a key that everybody is basically doing the computation under but you want the user to be able to uniquely decrypt his own state so what you would do is you would basically kind of do a re-encryption where you would convert from the network key into the user key but all of that is done homomorphically so there is no decryption in the process you're basically just swapping the keys around um so this basically gives you the ability to have a private token where you can do everything encrypted

unchained without any kind of off-chain computation uh with full privacy so the high-level protocol is very simple there is a user the user encrypts their inputs sends it to the network the validators on the network will execute the homomorphic computation and then basically key switch for the user to see the balance and then the user can get the result and decrypt it simple well unfortunately it's not that simple because as i mentioned you need to have a shared key for the users to be able to do computation together because if everybody has a different key well you're basically not able to combine those values on chain so the network has to have a public key that everybody's using to submit their encrypted transaction inputs

and so that creates a whole bunch of problems the first one is if there is a network key well who holds the key right i mean if you have if you need a trusted third party to hold the key you're kind of defeating the whole purpose of having a blockchain in the first place the second problem is if you can actually do requires to make sure the transaction is valid you're implicitly saying that the validators can decrypt the value of the required statements so that they can decide whether they should put this transaction into the block or basically revert it but if the miners can the validators can actually do that how do you prevent them from arbitrary doing that for any value instead of what they're really supposed to do and

finally if users can actually key switch and see their own balances what prevents them from creating a fake smart contract where they would take another user's encrypted balance pretend it's their own by making a transaction and then decrypting that so there is a lot of problem because basically what you end up with is a protocol where everybody's trying to cheat and there is someone in the middle which is supposed to do a decryption so it's kind of like literally the worst possible scenario for security so there is something really cool that you probably heard about in other settings which is called threshold encryption so you can actually do threshold homomorphic encryption where you would basically have a bunch of validators sharing the secret key so you take your secret key you split it into 10 20 100

pieces you give those pieces to each of the validators so none of them has the full key to be able to decrypt the data they only have a piece of the key the second thing that they do is then they do what's called a partial decryption so each validator will then take their own piece of private key and basically decrypt the ciphertext with that piece of the private key so what they would end up with is a partial decryption but they're still they're still learning nothing about the actual value and then eventually once all the validators did that you can do the aggregation and what you end up with is a full decryption even though none of them had the full secret key and you can design this threshold protocol such that it's resistant for at least two-thirds

of the validators which means that in order to cheat you will need to control at least two-thirds of the validators which are engaged in this threshold protocol so i think you know two-thirds is quite good security i think if you've got a pretty well decentralized set of validators the only drawback of using threshold fhe is that you need to have a fairly fixed and not huge amount of validators like you cannot have like 100 000 validators and you cannot have people just going in and out every second from the network there needs to be some kind of like maybe a hundred uh validator sets uh for a period of time that you can rely on for this threshold protocol which quite frankly is pretty much what people are doing we need a delegated

proof of stake nominated proof of stake and all of those you know delegation flavor of pos basically um so now that you can do this threshold protocol you basically no longer have to worry about the secret key being compromised nobody actually has a secret key is basically a shared decentralized protocol you still have to deal with those encrypted requires so a validator who's performing a require has to know whether this recoil has passed or not in order to validate or invalidate the transaction so what prevents a validator from injecting some arbitrary value in this require doing this threshold protocol for decryption and basically getting something they're not supposed to so how

do you prevent validators from cheating so the way you do that is that you basically make sure that all the validators did the exact same homomorphic computation before you basically do the threshold protocol so you take a validator the validator picks the number of transactions executes them and proposes a block sends it to the other validators the other validators will re-execute the same computation and if all the validators agree on the result of the homomorphic computation so they don't agree on the value they agree on the cipher text itself you know like i've produced some gibberish and your gibberish is the same gibberish as mine so therefore we have consensus on gibberish that's good then they go on and do the threshold protocol because

now you can basically be assured that nobody has injected fake material into the smart contract that people did what they're supposed to do and then once you've done that you can finalize the blocks and basically append it to the blockchain the problem when you're doing that is that you're basically optimistically executing the transactions which means that if a transaction fails you have to fail all of the transactions after that and you wouldn't know that until you basically pretty much finalize the computation so this is something that we're trying to figure out how to make more efficient but to start with you know we're going to assume that people are not going to ddos this thing by doing a whole bunch of fake transactions because it might be very expensive for them to do that but if you've got ideas i'm happy to

actually take those ideas the last thing that we have to deal with are users able to do arbitrary transactions that include inputs which might be other users encrypted states because on a blockchain everything is public even though it's encrypted you could still actually go and get someone else's encrypted balance and basically do put that as an input your transaction to the decryption and know the value and this of course would break the entire thing and so you cannot do that so to solve that you have to basically use zero knowledge proofs and you have to do specifically what's called a zero knowledge proof of input awareness and so what that means is that when a user makes a transaction that includes encrypted inputs they need to provide

with the transaction a proof that they knew the plaintext value of this encrypted input so basically the user has to prove that he's the one who encrypted the value and not some other person that he just stole the ciphertext from so this is virtually something that's not too complicated to do but you know you can see how this actually starts piling up and adding more and more complexity so homomorphic encryption is difficult in itself but if you want to do it in the case of a smart contract protocol you can see that you now have to mix fhe with threshold cryptography you know with consensus engineering with zero knowledge proofs it's actually a fairly complicated protocol but the important thing is it actually kind of works in terms of security right so we

can actually build it i'm sure it's not going to be the most efficient way but we can actually build it and as far as i can tell you know this is the first time that you could actually think about having a protocol for an unchained privacy so the full protocol looks like the user encrypts inputs produces proof that he knows the inputs that he is providing the network gets those inputs and the proofs the validator check the proofs execute fhe transactions reach consensus on it do the threshold decryption check the requires invalidate the things do the key switching and then after that the user can retrieve their state and decrypt it so it's still fairly simple-ish but you now have all those extra cryptography step

so where we're going next there are ways to improve that which we don't know how to do yet uh and if you're interested in that space again happy to talk about it one of them is to do provable correctness for homomorphic encryption so right now we rely on consensus to make sure that validators executed things correctly so every validator has to redo the homomorphic computation but this computation is very expensive to perform in the first place so if we could somehow avoid redoing 10 or 100 times the same expensive computation and instead just have one validator do the computation produce a proof and other people just verify that proof that would massively speed up the performance of the network and decrease the cost of

computation for the validators dramatically the problem is that well homomorphic encryption are humongous computations and so right now it doesn't fit in any zero knowledge framework uh the amount of computation you have to do just it just doesn't fit basically just doesn't fit so we have to find ways to either make it fit or to find other stark snarks plonks or whatever flavor of zk stuff that actually could work with homomorphic encryption and the second thing we'd like to do is fhe rollups because you know if you can actually do provable correctness of homomorphic computation then you can actually combine zk rollups with a homomorphic computation and you can do those

homomorphic computation off chain in your basically uh zika transactions so you would have privacy on the layer 2 solution and then basically have you know the scalability of the zk roll up i personally think that this would be absolutely awesome and much more useful i think than launching like yet another protocol or a side chain uh for homomorphic encryption but you know that's predicated on being able to do provable fhe which is an open problem and then finally of course you know we want to improve performance so performance is the main bottleneck now for adoption homomorphic encryption which we are solving but it's still something we'd like to improve uh so as i said you know there is a couple more

years of work before people can start doing that um so i hope you guys enjoyed that i know it was a lot in a very short amount of time uh but if you have any questions let me know and you know i'm easy to find online uh at ren hindi on twitter randa zama.ai if you wanna chat directly uh if you're interested in homomorphic encryption we also have a very active community called fhe.org where we have monthly meetups about homomorphic encryption as well as discord server where people talk about homomorphic encryption and it's a cryptography centric discord now so it's not a token discord or anything like that so it's actual people talking about cryptography thank you

[Applause] any any questions do we have five minutes or not yeah yeah okay go ahead hi thank you this is very interesting but i only have one um questions about it uh we are protecting by this morphic cryptography by protecting the wallets amounts yeah we we can't protect uh from other eyes the interaction i mean example i'm everybody will say we will be able to see that i have interacted let's say for example with avegochi but i won't never

see how much i earn and how much i spent is that so we can protect them they wouldn't be able to see the data but they would still see the metadata they would know that you just called this smart contract or you just interacted with this address so if you wanted to hide that you could technically do it with fhe by basically using encrypted addresses and doing you know encrypted signature verifications that kind of stuff it would add so much complexity that i don't think is actually worth it because when you think about it anonymity and privacy are two different things right hiding who you are is different from hiding what you did and hiding what you own right and when you look at the privacy models that we have for example in messaging apps messaging apps you know the telecom operator still

knows that you and i are sending each other a message they don't know the content of the message and this is kind of what we're saying here is a privacy model for private smart contracts the network knows that you interacted with a smart contract but nobody knows the content of that interaction and the value of it okay yeah just yet again even if with a higher level of complexity still the outcomes of kind of detection need to be known in advance it's something that needs to be deterministic it has to be deterministic yes that's really important because if you want to verify that computation was done correctly you need the computation to be deterministic yes i mean as far as i know for now and

again you know this is such a new topic i think you know what i say is the case today maybe in a few years uh we're gonna have other solutions we'll see thanks very nice though very interesting uh i have a question regarding the privacy for the issue of knowledge proofs that you use yeah so if i understood correctly like if you don't use the zero knowledge proofs it would be possible to copy this data and later uh decrypt it yeah and if you use your knowledge proof basically anyone that knows the amount can decrypt the data and i was thinking like in some specific scenarios for example if i know that you get salary from your company yeah i know

already of their range but i know they i don't know the exact amount so could i copy this yeah basically data and then brutally that's a good question so this is exactly the reason why we put noise in homo in ciphertext is to prevent this kind of guess that people could do so yes you know you could technically guess that the data so the yellow squares here is 125 but you wouldn't be able to guess the noise that was added to the data and the zero knowledge proof is not made on the data alone it's made on the data with the noise added so you would actually need to know the noise that was generated in order to actually be able to guess the cipher text and and forge it basically and if you can do that to basically breaking latis cryptography

which means you're breaking post-quantum cryptography so you know if you did i think we have much bigger problem than privacy on blockchains with the future of security right yeah we're done okay thank you very much [Applause] you