Optimizing Commit-and-Reveal for Smart Contracts

Transcript

in 2024. If I can take my good. So I obtained my MSDFL in 2024. Then I went to work for chain security which is a smart contract audit firm and random which works on threshold cryptography. And the work I'm going to present today was my master thesis for this uh this degree. And so to jump into it, I like to use the title as a as a way to explain it. So what is commit and reveal? Commit and reveal is a cryptographic protocol that we can use to put a message in a an opaque envelope and then give the envelope and later we can take out the

same message from the envelope. Of course, there's a real life equivalent to this which is the the ballot box. So usually I bring a physical one but uh this time around there's not a votation in Switzerland. Can you believe it? But uh so you get the picture and to use this to understand what we get out of commit and reveal. We get these two properties. We can commit and we can reveal. And we want the message to be the commitment to be hiding which uh or the envelope to be a pack which means that the message is not revealed when we have the commitment. And we also want it to be binding, which is the fact that the envelope is sealed. You can't change the message and then reveal a different

message than the one you decided on when making the commitment. And the other question is commit and reveal for smart contracts. How do smart contracts use commit and reveal? Today I will show you three examples. The first one you might have seen the screen is ENS registration. When you go to register, you do two transactions. First transactions is committing to the name you want to to register and the second transaction is revealing that name and and registering it that way. And the reason you do it that way is to prevent an instance of front runninging. So fronting is the fact of uh putting a transaction in front of an existing

transaction to based on what the other transaction contains. It's a an unintuitive phenomenon that sort of breaks the causality because the cause happens before the effect in the final ordering of the chain. And in the specific case, what you could happen is you go to register Julia. Someone sees your transaction and goes to register it in front of you, then tries to say it back to you for a premium. So we don't want that. That's why ENS uses this commit and reveal scheme. Another instance of commit reveal in smart contract is also ENS which is the ENS auction that they ran in 2017 if I remember correctly. So at that point most of the names went out at once and

to attribute them they ran a second price sealed bid auction and they used commit and reveal to implement that. So you would commit to your bid everyone could commit to their bid during a certain period. they would have to put more than their bid in a smart contract to hide the exact amount. Then later people could reveal their bids and the highest bid would get the the name. Now the interesting thing with that is that you it's not very capital efficient because you have to lock your uh your money in smart contract for a while and we're going to come back to that. The third example I want to show is gathering randomness. It's a very old idea in blockchain called randow usually

and it's the idea that you have multiple parties who will contribute to the randomness. So everyone commits to a number hopefully a random number then in a second uh phase everyone can reveal that number and hopefully the resulting uh output will be random enough. Now commit and reveal schemes simple commit and reveal schemes have to have multiple limitations. They take two rounds to resolve commit and then later reveal. They have to deal with unrevealed inputs in a way or another.

If a party gives you a commitment and then decides not to give the reveal to you and they are prompt to timing games because the last person to commit or to reveal can sometimes have more information than the first ones. So you have an incentive to try to do it at the last minute to get this asymmetric information. Now how does for example the beacon chain the Ethereum beacon chain uses this rendo? They sort of solves this problem a little bit. So they use BLS signatures and VRF so they have only one round. If you don't reveal your input you have to skip your block as a validator. So you lose a bit of money and there are some timing games but

they're sort of uh mitigated. This a whole topic I'm not going to get into but it's worth mentioning that they are doing that. Now the impetus for the research project was you know there must be a better way to do this and we should uh we should study that at EPFL. So what coming to it what I did at my project is I put a system of delayed execution in the the execution layer and using this system I run simple auctions and I compared this to the baseline which is commit and reveal in contract and also the academic stuff you know prior art literature and everything like that.

So what would be the expected benefits of a system like this? Well, you would get for once fronting protection which is nice. You would also limit the ability of the block builder to front transactions and rearrange transactions because they cannot see the transactions while they are not revealed. and you hope to get capital efficient seal bid auctions because uh commit and reveal sealed bid auctions have this uh locking up a lot of capital for a while. So to formalize this a little bit, I took from the yellow paper the way that uh they describe Ethereum transactions and non Ethereum transaction is processed when you can put your

transaction in this state transition function that produces the next state of the blockchain like that. And basically the block proposer can decide what transactions it puts in which order. What we proposed is maybe we could have the same thing but with a security property which I call causality which is the idea that nobody can go and alter the preview state having seen having been revealed the transaction itself. So that's interesting. And a second property that uh we're looking into is if we try to generalize this model a bit to multiple inputs and not just one transactions, you would hope to have something like fairness, the fact that

uh people cannot cancel their input or change it after they've seen other people's input. Now I use two variants of uh cryptography in this project. One is threshold encryption. So the idea that there's a committee with maybe 10 nodes and any seven of these nodes are enough to decrypt a given message but not any six and time lock puzzles which are these computation that take a long time to perform so that you can say okay I put my message in a time lock and I know that it's going to take at least 10 minutes for anyone to hopefully decrypt.

Now to discuss the results a little bit. So I will answer these questions. Did we achieve the security properties? We argue that yes because you can read the rational. I guess I don't have much time. So how do we compare the different variants? So here's a summary for threshold decryption. In short, it makes the blockchain execute a bit more uh computation compared to the benchmarking we've done for the VDF. So 192,000 gas.

It's consistent with the EIP1 108, but it adds 200 bytes roughly a witness size. If we look at VDFS, we have the opposite. we have more data that needs to be shared but we have less execution because the verifying the verifiable delay function happens to be a bit faster in this instance. So to put this in a table here and so what does it look like from the applications perspective? Well the nice thing is we've solved the capital in efficiency for auctions. That's for sure. We know that we've decreased throughput because in any case you have more computation that needs to be done.

So naturally the throughput given the same amount of gas will come down and we've in some points of view we've increased the latency because you won't get any sort of result of the execution of your transactions until they go through the whole process. Whereas if you just include a a transparent transaction in a block, you know that's going that you already have the final results of the execution when you receive the block. And we've messed a little bit with the ability to simulate transactions offchain because your transaction will only execute after the entire queue of encryptered transactions that are still waiting have executed and you cannot simulate those by designs. So

this has the problem that it's kind of breaks the gas estimation that you have in your Ethereum client. This something uh I've noticed while exper experimenting with that but it also breaks a lot of uh MUV extractions good and bad. Now some design choices that I did in my project. So the maybe the most important one is that I started from the idea that you need a hard fork to introduce delayed encryption into an Ethereum like blockchain. So I think to fully do it you do but there are I will go back to this. There are ways to do it in a more incremental way. I put every transaction in the encrypted queue.

There's no way to like do a transaction that is faster than others. And this is good for auctions because if you don't have uh if you have a fast queue, you might be able to cancel your bid or the stuff that influences other transaction and you would not get the causality property. But for certain transactions, certain applications, this might not be good. So maybe one thing we could have is we could have a a fast transaction queue and a slow transaction queue and the fast one can be unencrypted. But there are of course implications to that as well. And we were only able to encrypt the call data. So the the message you sent to the smart contract, not the sender, for example, because you need the sender to make sure that the

sender has enough gas to pay for transactions. But maybe there are ways we can do that. Maybe we can use zk proofs to to prove that the transaction is solvent. And you also have we didn't experiment with tees but for some trust models this might be a valid application. Now there's choices in Ethereum itself that can interfere with the front protection. One is the fact that you expect to only pay the amount of gas that you used and not the amount of gas that you reserved. But that means that at some point we need to be able to execute your transactions. And uh

there's some attacks on uh encrypted me pools where you reserve the entire block but you don't actually use it and that just blocks everyone else. So this is a bit difficult to deal with. It also breaks a bit the EIP159 which is the the burn and the adaptative uh base fee but because you need a feedback loop from one block to the next to know how much gas was used and you can't have that if all the transactions are encrypted. It also interferes with EIP7702 recently, which is interesting because I used the fact that Ether cannot leave an account unless that account does a transaction to make sure that they would still have enough gas to

pay for the transaction when it goes through the queue. But with the IP772, this logic can break because you could empty an account while it has transactions already committed but not executed. And the question is also what about the reliability standards that Ethereum have? Maybe we don't want to have a threshold network that can hold or deny some service to the blockchain. So this is always a valid question to to ask. Now I will I want to highlight this document published by a bunch of people I've been able to talk to which is called the the road towards an encrypted meool on Ethereum L1 in particular they have a lot of interesting out of

protocol solutions that don't necessarily require a hard fork which is something that I was not able to experiment with because of time as well and I think I've been yeah I think there are a lot of what I presented is found in this document there's also more interesting research in that space. So just shout out to uh to Mark from mind and uh the other people and I want to also acknowledge these people who've been very helpful in my project that is professor Brian Ford at EPFL Yolan Roer from Randu and my colleague Shuan Wang. I will give you a link with the slides report the code for the project which if you want to run the

auction yourself you can. And uh I'm waiting for your questions. [Applause] No questions. This will be on the test.

Uh not yes. So not in production. It's aing prototype. There are something that that would be trivially broken if you put it in production. So that's the thing. If you want to play with the encrypted transaction, you should look into uh shutter the shutter network on nos's chin. I mean it also has some issues but uh that's because it's not uh in protocol. So I mentioned TE's. How can TE's be used in synergy with what I presented? I think T's so T's can custody a

decryption key by nature. So you could have one example is you could just have the T decrypt encrypted transactions on time. Another maybe interesting thing is you could combine threshold networks with TE's. So you have multiple TE's that have to cooperate to decrypt the the transactions. This is maybe a good idea because if you have only one TE, you can isolate it from the network and uh and lie to it about the state of the blockchain. Whereas if you have multiple TE's, it becomes harder. So it's not a TE's versus threshold network. It could be both.

Do you have any other questions? Okay, thank you very much. Yeah, thank you for your attention and uh I'll be outside if you