Optimizing Commit-and-Reveal for Smart Contracts - Julie Bettens

Transcript

all right thank you so I am J bans I am a blockchain security engineer at chain security and as a result of that I am contractually obligated to tell you a story so uh that happens at the other eth which is over there in my back and a long time ago some guy said to another guy the chain is not going to secure itself and the other guy said we need to do something about it and then one thing led to other and now chain security is here now having said that I will take you to the other other eth which is in loan with this uh campus and what happens is I did my

master thesis at apfl loan called optimizing commit and review for smart contracts and that's the project I'm going to talk about so what is yeah unfortunately yeah I went to the first slide unfortunately technical issues so I exit this one but yeah yeah I'm sorry don't have two presentations okay sorry about that okay so EPF laan I did my master thesis titled optimizing commit and R for smart contracts and to explain that I like to start with the

title what do we mean by commit and reveal a commit and reveal protocol is a cryptographic protocol that looks a lot like a voting envelope like these ones why do we use BL voting envelope and why what do we get out of them we get two things because I will vote and I don't want other people to see inside the envelope because it's a secret ballot vote but they also need to be able to take and move around a representation of my vote so we use these moting envelopes and if we think of a cryptographic scheme we would have two operations commit which is when you make a commitment to an arbitrary message like your vote and put it in an envelope and reveal which is when you open the

envelope and you give cryptographic proof that the message inside was the one you originally put in we want two security properties out of this the hiding property which is the fact that the envelope does not leak the information inside it's opaque and The Binding property which is that you cannot change your mind about your vote in the middle of things now now how do smart contracts use commit and reveal today I will give you two examples relatively quickly the first one is ens if you've seen the screen what you do is you do a first transaction which has a commitment inside and then you wait a little bit and then you give a transactions which opens the commitment to show the name that you wanted to reserve and this is to protect you

against front running on ens the other example is again ens the ens auction when in 2017 I I think all the names went up they had a sealed bid auction to price the names and attribute the names and again they used commit and reveal a first phase where people could commit to their bid on chain and then a second phase where people could reveal their bits and it's again using the same two properties to make it work in a fair and efficient way now there are limitations if you study these protocols to doing it in smart contracts the first one is that it requires two transactions always and a waiting period in between and it increases code complexity because you

have to keep track of everything in a custom way and you need to find a way to handle unrevealed inputs this particular problem doesn't have really a good solution because if someone doesn't open their envelope and they the only one who can open it you maybe you ignore them but that that changes the result but if you wait for them you get theil of service one thing that people do is they require people to put up collateral to ensure good behavior but that's not Capital efficient and there's also a timing game in that the last person to open their commitment can has the most information to decide if they want to withhold their commitment or not this is an inevitable issue that you have with this types of protocol so at the D lafl

people said you know there must be a better way that's the motivation for the optimizing commit and reveal project now to talk to you a little bit about the design I will show you the normal way that a blockchain is usually structured you will have usually users will produce signed and CLE clear text transactions and give them to the consensus Group which is the way we abstract over either miners validators or a sequencer and then the consensus group will produce the canonical ordering of all the transactions submitted to the blockchain and then when you have the canonical ordering you can execute the all the transactions and get the state of the blockchain

the important thing is that transactions can already be simulated before the consensus group even does its work and that's where a lot of M for example comes from now in a dawn blockchain which is our proposal instead we will have users produce an encrypted representation of their transactions and give that to the consensus group and the consensus group will order that then once they've produced the canonical ordering and they can't change their mind another group called the secret management committee which is usually a threshold network will decrypt the transaction and allow everyone to execute the transactions and recover the state of the blockchain now what applications are we

helping with this we have a theoretical model for what we're looking for we're looking for applications where there is a state of the application and there's some Logic for updating the state so the logic can look at the current state and it can look at multiple people's inputs to produce the next state of the application if you want an example in the case of the auction the state would be the state of the blockchain the inputs will be all the bids and then what you do is you look who has the highest bid and you give them the object of the auction now what security properties do we need we want causality which is the property that nobody can alter the state of the application after seeing someone

else's input and that is against front Runing in particular and we have the fairness property which is that no participant can cancel or change the input to the application after seeing anyone else's input now the research goal we set out to do is to implement temporary encryption with delayed execution which is another name for our proposal on a smart contract blockchain the expected benefits of certain approach is first of all complete front training protection we also would have higher credible neutrality because the consensus group would not be able to arbitrarily make decisions based on transactions because they're encrypted and we want to show that we can Implement efficient and safe

sealed bid auctions on top of the new system now should you do this on an L1 or an L2 we are agnostic with regards to this they they can both have benefits so we also implemented three variants of the scheme I will skip the last one but I will describe threshold public key encryption which is a system where transactions are each encrypted independently and the SMC is able to decrypt any transaction individually so the SMC is expected to decrypt every finalized transaction one by one and the other mode is called threshold identity based encryption in this scheme transactions are encrypted such that they can be all decrypted if they have

the same block number and the SMC will look for a find block with the block number but it's unable to to decide individual transactions it has to reveal a decryption key for every transaction that was encrypted for that block number now talking a little bit about the implementation what we did is we took an ethereum blockchain we took go ethereum and we haded functionality for potential heart Fork that would add the new rules and the new functionality the application that we run is a B auction for uh one nft and we want to simulate at least a, biders to show that that it

scales and it's a quick option because we have to be within the execution delay that we added and we also have a smart contract implementation of commit and reveal auction to get a baseline now the interesting magic trick is that our smart contract for the seal bid auction on the dawn style blockchain looks exactly like an open bid auction because it's really the system underneath that's doing all of the heavy lifting and you have relatively simple logic at the end now some results and discussions first we ask do we did we achieve our security properties we argue that we did because the causality is respected the transactions are already

ordered when they are revealed so you can't go and alter the state and we have fairness we argue that we do because it there's no way to cancel a transaction after it has been committed and revealed so in terms of benchmarking the threshold public encryption requires 212 bytes net per transaction and the amount of computation scales linearly with the number of transactions you put in the threshold identity based encryption however can be amortized a little bit because the multiple transactions can share uh a single decryption key so you have upper bounds on the slides that

tell you how much at the maximum you can get if you have one transaction per block so to summarize this a bit in a table we see that the performance for TN is better but the nice property of tpke is that a it's the inclusion of a transactions that triggers its decryption so this is a bit safer if you have a transaction that doesn't make it into the blockchain as a result we think that tib is great for auctions because if you have a a late bid it doesn't really matter but the best use case for tpk is front running protection now from the applications perspective what's better what's worse well we've removed the capital inefficiency that we had in the ANS auction but we currently consume twice

the amount of gas compared to the commit and reveal auction and we've increased the execution latency because of the delay that's kind of an interesting point because if you look at this from a theoretical perspective if normally only transactions that are ordered by the consensus group should matter applications outside of the blockchain should not make decision based on something that is not final but in practice people will use a couple transactions especially in ethereum a couple confirmations sorry and consider that a transaction has made it if it has a certain number of confirmations so in practice this adds delays and this uh this adds delays for applications this also means that simulation in order to

decide the the gas or to decide if the transaction is going to be successful is harder because you have less information less current information and that you have to wait longer for execution receipts which affect some programs like Foundry for example the other drawbacks of the Dawn architecture is that it will require a hard Fork as we've discussed it also breaks EIP 1559 which is the B based gas the auction market for transactions reform because it needs to know how much gas was in the previous block and it's difficult to do that if you have delayed execution and breaks some other things and it also loses us a lot of the benefits of me you might

think there are benefits to me and yes that is the case because before proposers were simulating transactions and trying to extract the most amount of value using things like MEF Boost flash buts and all of that it was difficult to promptly liquidate a position on chain because you could not the the block producer could not arrange to do that it's also harder to have well arbitraged pools because the proposer is is not smart enough to do it so the prices arguably were worse and the chin had a lot of failed transactions that would just waste resources because you did not have revert prot ction with flashboards whereas since we have the me pipeline we

have some of these nice functionalities now having said that what Future Works can be done in this area of research we make a couple proposal so the first one is can we reintroduce some of the me pipeline that we lost potentially what we could do is have a Fast Lane section at the end of the block where after the encrypted transactions have been executed we can have a few m transactions to do liquidations and Arbitrage for examples then can we show the contracts and the transactions themselves their decryption key why would you do that there are two benefits first of all you could allow applications to block the fast lane let's say okay you you can't

bid from the fast lane because otherwise it's cheating and the second thing you get is you get synchronous Randomness this is a cryptographic property of the encryption schemes we use which is also used by the drun project which is that decryption keys can also function as random Vons so something it's not quite a for first I think some networks have synchronous Randomness but we can have synchronous Randomness as a bonus on top of delayed execution now can we encrypt more Fields because in the Prototype we just encrypted the destination address and the data the problem with that is you need to be able to know that there's a valid signature and that the account that sends a transaction has enough gas to pay for it but the potential solution

to that is you can use zero knowledge to prove that the transaction inside sapper text is valid without actually revealing the entirety of it so this leads to an interesting question what how does this impact sensorship resistance let's say we have these almost completely encrypted transactions and we have a centralized sequencer well what the centralized sequencer can do is it can require people to prove more things to prove that they are not on the on The Blacklist but it's interesting because anyone who transacts immediately knows what the transaction is so you can have sensored rollups but that are transparent on their censorship now whether that's desirable or not is up to the community

to decide of course and finally I would like to give some acknowledgement to some people who've been helpful in the project and quickly conclude so we have this implementation of uh delayed execution which is a realist B demonstration and we have a seal bid ocean that runs on it which is cool the we think that delay execution enables patterns that would not be practical otherwise for example the the seal bid auction the simple seal bid auctions but there are some drawbacks when it comes to implementing especially on existing Shain two things that can help us would be abundant computation so that the gas

is not that much of an issue and fast finality so that the exist ction delay can be lowered now that's it I will link to you the full report from my thesis and I am awaiting your questions brilliant presentation do we have any questions in the audience today anyone yep right over here she has a mic here you can speak into that so everyone can hear thank you of ah uh this is here well can can see me after or in the recording okay there all right great do we have any

other questions from the audience today yep right over here um maybe throw the mic ah okay for your presentation really great did you look at sh Network which does threshold commit and Reve style encrytion and how does your system differ from that yes I've talked with people from shut Network and and from nether mind the difference at least currently is that shutter network is trying to work without hard foring is trying to do something very Progressive to get to to essentially the same point whereas in the in the project we said okay we're going to need to hard for so we just uh we did something that's not uh backwards compatible at all try to

get directly to the thing but I think we will converge roughly on on the same uh the same type of design okay brilliant we have one more question over here so how big of a change is it you have to do to ethereum like this hard Fork how like is it something that's has even a chance of getting into main net or is purely research thing uh yes and no the the code is not that that complicated at the complicated thing is trying to make AUM agree to trust a threshold Network to decrypt things in time and there's a lot of this is not popular on the L1 they have uh they have a system where they want to have liveness and this is this is the big potential issue with these

types of uh of systems and uh also people who work on this on network know this so that's the L1 story [Music]