Emilie - Making sure EOF is done right

Transcript

[Music] [Music] yeah hello everyone it's my distin pleasure uh to today introduce Emily which is our small contribution to hopefully make uh EF uh safe so to make sure everything in e works properly so not just right before me but today already multiple times UF has been discussed so in case you just walked in because you were especially interested in Emily um I I'll give you a short recap so what is UF um so there there are some two talks listed here by by Den

Farin and also from this morning which are really good and and really summarize it well but for the purpose of this talk we're just going to say UF is a big change in evm so what is the problem with that because with as in um with any big change in evm a lot can go wrong so we have a a lot of different smart contracts right and we are using different compilers I mean there's solidity and there's Viper and they have a bunch of different versions they have different optimization features and so on so we actually have quite a few compilers that we're using and then out of that we get lots of different bite codes and these bite codes we execute on different execution clients and uh on

these execution clients these new bite codes interact with many different existing contracts so we have a horribly big search space to look for things that can go wrong right and um experience shows that things do go wrong and unfortunately things go uh don't always are detected during testing because we had uh chain splits after certain hard fors on chain so what do we think can go wrong here so first of all um there has been some discuss discussions on what compilers should support so we can we want to figure out what uh is actually supported so that users can have a seamless transition to EF in the bite codes of course we can have incorrect

compilation we have a totally new um features we might very well see incorrect compilation and in the clients we also have very new implementations it's not implausible that we see incorrect execution so all of these would be horrible they they would lead to to chain splits and then lastly we might have incorrect interaction right so you're calling an existing old contract from your new EF contract maybe that doesn't work the way you thought it would work so now how can we fix all that so that's why we're here um to to improve stuff so first of all is this news well no of course not so there is already uh a lot of testing going on

right so there's the testing team and lots of tests are being written but we think that Emily can improve the situation because we in the past have learned that what uh really helps is real contracts with real data and real interactions because that's in the end what we want to be sure that works on chain right because that's what might cause the chain split so what does Emily do so here we have an existing main transaction which um yeah you are all familiar with so now what does Emily do exactly so we take contract a and we recompile it to EF and we execute it again so now we can compare these two

executions right because now we actually have a really good idea of what correctness should look like because we have the execution above which is the current execution and we can compare all the parts so we can compare what does contract a do what does it right to storage how do all the call data and return data look how is the output how the uh is the success flxs and so on so we have a great uh corre nness reference here so Emily checks a bunch of things I mentioned some of them already so obviously Emily checks all the storage changes Emily checks which events are emitted Emily checks the call data Emily checks the return data and the execution status so um and lastly what we also found quite interesting while developing

is that we um can monitor some of the gas costs so we can see overall is UF execution on average cheaper or more expensive than the previous execution and um with that I we can then find all these things that we're really concerned about right missing compiler features incorrect compilation incorrect execution incorrect interaction so all these horrible things we want to avoid we can hopefully find before they are happening on chain so with that Emily contributes to the security of EF of course as is the usual case things are not quite as simple so a bunch of things can go wrong um I'm happy to discuss

them a little bit more during the questions but uh one of the things that can go wrong is um the as was previously discussed the Gas Co Gas out code is disappearing but currently it's still there and it's causing a bunch of uh problems as was just discussed in the previous talk but yeah we have some counter measures for that so I'm happy to discuss this in the questions and with that um I close and thank you for your [Applause] attention thank you thank you so let's start with the questions uh are there instances where one may uh one may want to rewrite their contracts for UF for

better performance or other reasons yeah um I guess we're going to see I mean the the I think the truth is that we don't know exactly what the numbers are going to be like because we haven't seen the the latest compiler versions and we haven't seen the full EF spec um but I think the that's quite possible because it's feasible that there might be um contracts which are significantly cheaper when when executed in EF yes M uh so uh is there compilation to EF done from source code where do you get the source code yeah excellent question so we uh get the source code from ether skan so uh and also other sources but yeah one of the sources Ean so obviously

we don't have source code for every contract but that's also not necessary I mean we just want to test as much as possible and it's actually good that we don't have source code for everything um because we as I said we also want to uh test this interaction with Legacy contracts so we don't want to necessarily recompile everything but yeah um we we uh recompile some and then test the interaction mhm um if Emily compiles Legacy bite code to to EF how does it cut compiler bugs from a high level language to EF Yeah so basically um we take the code and we we previously ran it with the real data right so for example uh let's consider a transfer an esc20 transfer and let's let's say the

esc20 transfer now works incorrectly when compiled with with ef now now what we would see is we would for example see a a difference in the storage and because we check how was the S changed originally and now we check how is it changed now that we ran it based on EF we can detect those kind of um correctness issues mhm uh