New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Confidential EVM: Next-Generation Contracts | Harry Roberts - Oasis Protocol

Ethereum DenverWed, Oct 9, 2024, 12:00 AM

Everything on Ethereum is transparent, but does that limit what we can do with smart contracts? In this session we'll look at what is Confidential EVM and how it enables the next generation of innovative smart contracts & dApps to be built using Solidity and all your favorite tools & frameworks. APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN APPLY NOW https://ethdenver.com/apply

Transcript

generation contract thank you uh so hi hi everyone uh I'm Harry from Oasis protocol and uh we're making confidential evm so I I think first I should start with a little bit of context to uh show my perspective of how I'm thinking about this so with uh transparent evm we have a very basic function you have the transaction that comes in with a previous state and all of this is public information uh it executes the contract for example and then it uh emits the new state and the events um so I'm starting with this and then I'll get to what is confidential EVMS and how is it different and what can we do with it I think first uh I'd like to go through a little bit of the history of uh how we got up to confidential evm from transparent evm uh so yeah uh if we start with the ZK protocols on evm uh they exist because of pain points so these are like deficits in the protocol where uh you don't have enough transactions per second so you want to do more transactions or you don't have a privacy so you want to make private transactions and uh these were developed initially as uh well rollups and ZK privacy protocols that ran on transparent uh ethereum um so what we're really doing with the the ZK stuff is we're using uh the Zer knowledge protocol to uh emit information so in the example of a ZK roller this would be uh all of the signatures and the auxiliary information that uh you can be condensed down into uh the the bare minimum that you need to replicate the chain which would be like uh the account index of this was the source of the funds and the account index of the destination of the funds and how many funds were transferred uh so likewise with a ZK protocol uh the information you're hiding is uh which of the balances you're spending from uh but I think that the crucial point with uh zero knowledge in comparison to uh transparent evm is that uh you do have privacy but only if you're proving the the ZK circuit so for example with uh with rollups if you wanted to add privacy to a rollup you have to find another privacy system that could work inside the rollup because the prover of the rollup has all the information uh so if we next move on to uh ZK evm for example so uh with a centralized cheda one of the main things that it's doing is uh to put together a batch of transactions and really it's its only job is to prevent uh sort of uh read and write conflicts so you might have a bunch of different contracts that read from the same state so be that like un swap you want a price or uh some sort of defi protocol and it serializes the order of the uh application of the contract so that uh if you have two contracts that uh modify the the same Keys uh they need to have a consistent view of this so you don't get overlapping conflicts and and stuff like that so the problem though is that uh with the scheduler this this ends up being a sort of very centralized aspect to it and if you want privacy you still have to add an additional layer of privacy to hide that information from the scheduler um but with ZK evm and privacy I think this is something that's sort of underutilized at the moment so uh if you look at uh being able to provide a ZK evm proof to a ZK evm contract that as long as you don't do anything with your your contract that would cause a storage conflict forever uh then you could potentially do as much computation you want in private give that to the the zkm sequencer and then then um that would go ahead and uh schedule that with the rest of the transactions and as much as I I like zkm I don't think people are really taking full advantage of the confidentiality aspect that's possible at the moment but really I I'm trying to get at at uh like confidential evm so we have ZK it can do privacy it can do rollups we also have multi-party computation so if you want to have uh uh a third party that signs something for you or keep something secret then really there there's only sort of three different options uh either you have something that's private uh and you provide a proof that shows that you know it or you have an NPC protocol that keeps it private for you um and that that means that uh for example it would only sign a transaction if it was uh built into the protocol uh but these are they're both quite sort of technically complex so uh with both ZK and and MPC you end up with these very specific use cases where uh to do it quickly and efficiently you have to minimize the amount of functionality you have but if we look at a trusted execution so this has kind of the benefits of uh multip computation where you can have for example a contract that has secrets from everyone else and does delegated signing and you also have some of the aspects of uh of ZK snarks as well but without the proving time or without the the multi-party communication overhead uh means that it's kind of like the sweet spot is confidential trusted enclaves where you can use them as a an honest third party uh so I think there's there's like three modalities where with confidential ebm I'm really saying that this is a slightly different way of attacking problem so uh with ZK there's lots of different novel ways of solving problems that you have to sort of work around the semantics of of how that works with a transparent evm you also have the similar kind of problem where uh you you have to figure out how do I make this into a smart contract how do I make this sort of fully autonomous and interactive and I'm looking at the confidential evm as being a a new problem space where there legitimately are very different ways of thinking about this and the ramifications that has on a a defy ecosystem for example uh so yeah this is uh we do have a confidential evm in production and it's been been running for the past year or so in mainnet and uh yeah it's it's Sapphire so this is our our product uh but if I wanted to Define what confidential ebm is uh so really um it's something in the middle it's the tradeoff right so uh you don't have the the proving overhead of ZK circuits you don't have the the overhead of message multi party computation but you have you do have unobservable execution so you can have any contract that can execute in private so uh all of its state is encrypted you may have endtoend encryption between the the user DAP in the in the browser and the smart contract itself so uh unlike with uh normal evm you could have password authentication so you could put secrets into the contract um get it to operate in private against encrypted data and then that can emit public events um so this is It's a a new way of thinking about it so for example uh uh uh you could choose the different types of things that you want to be private and you want to be public and because it's all solidity and evm uh you could do this at runtime so instead of having like a preconfigured circuit that has a it's not very flexible uh you could uh load in whatever plugin you want that could uh do queries against its own confidential data and decide in private like is your authentication uh sufficient to use this contract or um maybe releasing audit information in a public event log and um really this comes down to like what what can we do with this where if most of the stuff in the real world is a mix of like public and private uh we can start thinking about how do we make uh uh what information do we really need to be public and what inform to be really really need to be private uh so for example uh if you're looking at the social graph and I know there are some messaging systems on ethereum there might be who interacts with the decks and you could say specifically I want all the information to be public but I don't want people to be able to discover my transaction history or I don't want people to discover who I'm interacting with so on a caseby Case basis you can decide uh What uh in your application do I do I want to make this uh public or private and uh an example we have here is uh like account abstraction so if you have a a confidential contract that can have its own Secrets then uh I could create a Bitcoin wallet or an ethereum wallet from the contract and ask the contract to sign for that so uh it's not just about privacy where if you have a secret that you can't let out like is uh you know you don't want to give everyone your your private key for your wallet then this is like uh uh a new piece of functionality that you have to uh avoid people from uh extracting secrets from it um so an example of the the different type of thinking you'd have is uh if you have two blockchains so if all of the blockchains that are evm compatible were also running in trusted execution then you could have uh two contracts on different chains that each trust each other's public keys and they could sign messages for each other so uh instead of having a a bridge and yet another consensus protocol to you know verify the block State on both of the chains and Shuffle the messages across uh you can get rid of that extra piece of infrastructure and just use the the users themselves to relay the messages uh because it's trustless so if you have two contracts that can encrypt data for each other and they can sign this then it's tamper proof uh it's verifiably from the the correct Source you can enforce uh things like sequence constraints and there's nothing the user can do to to modify that but you also cut out a lot of the extra infrastructure that is no longer needed uh so an example here is uh like private voting so we we made a demo uh a couple of to present a couple of days ago uh to show well how can we do something that most people seem think is pretty complex so there are a lot of different projects that are doing private voting and uh we thought we want to have someone be able to make a spicy opinion Poll for their D so anybody could come along and use like the ethereum block header storage proof uh to show that they have an account balance in a specific contract without revealing exactly which account they are only that they're a member so if you were to do this with a multi party protocol uh system or like a ZK circuit uh doing ethereum storage proofs in a ZK circuit is not trivial it takes a lot of time to prove you need to uh Implement uh like the cack function in Zer knowledge and this could take like a couple of minutes maybe two minutes to to actually create the proof to show that uh I am a Anonymous Dow member but with uh just plain solidity you just verify the storage proof so uh there's a lot of code for this and it's really straightforward to do and because it's just solidity it's uh I'd say it's like 15 times quicker than doing the equivalent with with ZK uh so you can use the the standard solidity stack I another thing is uh well you could also do something similar to ZK rollups but with uh trust execution environments so if you have a a contract that can sign things uh that means that it can verify that it gave you something before so an example I have is uh like a Bitcoin light client that's running fully in view calls so uh that means you don't have to make any storage rights at all if you have the the previous block header that was validated by the like client it can sign that and it can also sign for example that I have signed uh you know 4,000 blocks in a row without ever making any rights or storage uh updates and then I can give that latest block header to anybody and the fact that the contract has seen the previous 4,000 blocks means that I don't have to replicate that information so similar to ZK rollups we're doing computational compression with like a proof of authority but in this case the proof of authorities a like a trustless decentralized smart contract um but yeah it's not a free lunch so if you look at uh the kind of security problems we had with uh solidity and evm when people were first making contracts and there's the entire security industry in the blockchain space now to uh like you know uh re-entrancy was a problem because it was something new that we hadn't thought of but with confidential evm you also have quite a new set of considerations so uh if you have the contract that's executing in private that not even the node operator can see what's going on it does have these side channels so for example you can see how much gas it consumed or you could even though you can't see the content of the message you can see that the message the call data input is of this length or that uh the gas payer is paying for this or they're interacting with a specific contract um so yeah it's a bit uh if you look at like electronic engineering I think you have to start thinking about uh if I'm doing cryptography in constant time for uh some kind of high Assurance lowlevel implementation you do have to start thinking more in that mindset when you're developing uh confidential contracts because you have to be protecting against uh malicious users more than you would do on transparent evm for example uh so the the interesting uh point is uh with confidential evm there might be you might not need a lot of this other infrastructure so if you're trying to keep the like the user's token balances private how do you discover what kinds of tokens you have so uh with ethereum like polygon you'd go and look at one of the indexes there'd be something that monitors all the token transfers but with confidential evm you might not be able to have this indexer so how do you get this information how do you make it easy for users to use the confidential contract and a lot of this comes down to well you you have to query the contract so instead of just having a token you need a token registry so you can register the tokens that each user has um or if you want to uh iterate through uh say the last transactions or the last sort of orders you have to implement this in the the contract because only the contract can uh query its internal State and do the lookups for you and that also means that uh you also have to be sure that people aren't impersonating you so for example uh on ethereum I can simulate a transaction from anybody to any contract and I can see how that would play out uh but with confidential evm you obviously don't want someone else pretending to be you so again there's there's there's a small Cascade of supple differences when designing contracts on confidential evm that you have to think of and one of those is uh authentication you know do I have a login like I do with Gmail that I then use this token uh to look at my emails but I could also give that to other people so I could uh give somebody else a permit to view my data for a limited amount of time and uh instead of using message sender authentication they would have to use alternate schem that uh s of give you finer grain access control and uh yeah that's that's all I have to say today uh so if you have any questions uh you can come and talk to us and uh thank you very much [Applause] guys thank Harry that was great good give us a couple of minutes and we'll have the next talk ready y it's fantastic uh

Automatic transcript — names and jargon may be misspelled.