EthCC 2: Guillaume Balle

hello yeah perfect okay so thanks for coming back yeah so as most people in a room know but not necessarily people on the life there was a fire alarm so I'm going to have to shorten the presentation to try to to stick to schedule so what I want to do is a quick update I mean it was supposed to be longer but yeah a quick update about a theorem one point X so very short summary a theorem one point X is the effort that is trying to to keep a theorem one alive until Easter 2.0 comes like yeah it gets delivered and we focus on the it was um the it was some aspect of it and the scope is fairly easy fairly simple we just need to support what some pre compiles so pre compiles are constructs that are not written in in like the eevn bytecode there they're supposed to be called very often and these are repetitive contracts sorry contracts that get called over and over again so they're usually written in in regular in regular like the language that your client is is is made of Israel is using why why do we want to do it wasn't pretty compiles well it all comes with the fact like a theorem one point X the focuses on reducing just the size of the state so if you need a new primitive you want to be able to you you want to be able to not duplicate it you want to be able to create this contract and make sure that everybody called the same contract instead instead of duplicated the code for a new curve over and over again and so what some is pretty interesting for that because you have a lot of languages available it's fairly deterministic so it's a good starting point and and yet you can just add features and if you you know like you have you have interpreters available so you can add the interpreter to your client and if you have a new new a new contract that you want to declare as a precompile you just distribute it to every client every client uses their their their VM and they can it can be supported pretty pretty quickly so the current state is that all existing pre compiles like those who are currently existing have it wasn't version there's a version of gas running wasn't precompiled it's using wagon and it passes the test suit test suite and there's a full rinkeby sink and there's a main that sink it unfortunately goes until block mm sorry 2 million after that the Machine I ran the test on ran out of memory so I could not I could not get like for the full data in time for this presentation but the problem was my machine and not and not pre-compile themselves so I don't have much time so I'm going to skim over this but basically the information you need to get is that the purple here is the wasone the the yellow is the the original like the comparison this is a ring QB sink and you can't see that but the scale is logarithmic and so that means like it's actually much much faster or much slower you can see the this is the ratio like the the time it's the average time it took to execute it wasn't contract versus the average time it took to execute the native version and there's some actually interesting facts for example the this is the identity contract so it's just data copy and it's actually quite surprisingly like there's quite to slow down so that's that that's the good news that means like at least you understand that copying data is actually something that takes time and and so as a result that that gives way to interesting that gives us an interesting series of least for optimization the other good news is that those two contracts are actually not used that much so that's an interesting case as well and that kind of brings like fodder for the point I was going to make further down this presentation the other thing is this one it's the modular exponentiation I've roped it in in a hurry so it's actually not optimized at all so I also have a good good like good hope to optimize it in the future shortly actually if you compare rinkeby and like the rinkeby test and and the main that test you can see this is one so it's actually pretty similar I mean there's a big variance but I expect the times to be to be roughly the same right so just skimming over but basically the idea is that obviously we're not going to replace the existing pre compiles based on those numbers what we want to do instead is just use wisdom to introduce new pre compiles like a new features you can just have it ready all you need is to have wisdom interpreter you put your contract like you distribute your contract every client can immediately enjoy like using your benefit from using contract and then over time if your contract gets really used often this is when it will start getting optimized translated into your native language but it's really meant to to make adoption of new pre-compiled faster and like the next step at least the one I'm taking is is to think about like to study ahead of time compilation and ahead of time compilation you just have your wasn't binary you turn it into something that is that your machine understands so most likely I've wrote x86 it's most likely AMD 64 but I just wanted to write that here because wisdom is 32-bit and so is x86 but so the ideas you got your binary you compile it into a native code and then you load it so you this is this represents you process addressing space you've got gas at the top very integrated very self-reliant you got the Lipsy at the end and you just load your x86 binary as if it was a library and then what happens is that you just cross your finger your fingers you jump and you regret it immediately but the information is like the information most of the information is not really useful because what really happened is that once again get is very very self-centered so you don't get much information from the from this from this stack trace however the interesting information is right here you can see the the program counter is 0 and so that means something wrong happen and then you investigate so the reason why I'm sharing all this information is for people who would be interested in in doing the same kind of work for their own clients yeah I'm just sharing some some experience so what you do is you can see the translation the software that translated the wisdom into into x86 or AMD 64 binary uses this kind of weird return trick it takes RCX the content of our CX which is a register puts it on the stack and our 6 was 0 so what turns out on the top of the stack is 0 so when you return you just return into invalid memory and the real value that was supposed to to to be in that register with this this is part of the the Reds what's called the trampoline so it's you know there's a lot of confusion that's what I wanted to say unfortunately I don't really have time to to detail that because of the alarms so if you're interested in the details please come talk to me so these shoes like more like yep high-level issues that I ran into its memory allocation memory that doesn't really work well with the the library that I used the software that I use it's called wag it's fairly it's fairly new so it's perfectly understandable the problem is also with the go runtime because once again death is very very integrated so they used like a stack pointer everything is in this area and then when you jump you basically play with the devil like do good thing about Go is that you it gives you a binary that relies on very few external libraries like just the leap see normally and you can just distribute it over all over the place here you just break this contract so you you have to deal with the consequences so you can't really before calling like when you call this phone a compiled contract you will have to you will have to if you want to call back into the go runtime you have to make sure that you translate between the two worlds and then yes all the EEI and how to simply terminate the contract that hasn't been thought through yet in in the compiler because most compiler at least the one I use it's just meant to compile it once and for all and then at the end of the program it just exits which is not what we want to do when we write contract we want to be able to reuse the code over and over again so yeah these are the two things that need to need some attention the way I got my my information I'm really going to skim over that but it's basically to use gdb to patch the to patch the the stack and everything as it goes so I just fixed the the stack pointer I say okay you're you're off by this much and I just switch to see to be able to to like modify the content of the RCX register and then I go back and I continue so it's it's a lot of breakpoints and scripts to to fix that to be able to to basically analyze analyze the the contract and then of course at the end you need to sanitize everything and make sure you you go back to to go so the next step in for one point next there's a lot of work happening with the benchmarks hopefully there's going to be some some info about this tomorrow the big question is metering how do you want to do the metering that's actually a fairly important question the pre compiles they just have a formula they just take the input data as yeah as a base they calculate how much gas is going to be and this is where it's a yeah this is how you sta you calculate your count for the gas whereas regular contracts you call use gas as at some at some specific points and and that's not something you you really want to do so the method or the exact methodology is still being discussed but like I would say the most likely is that we're we're going to do that on a kiss by kiss like yeah kiss by kiss this is at least my opinion some other team members might might disagree yeah and then we need to select a series of pre-compile that will make it to the to the release so I think we've got one 40k snarks but if you if you want another pre-compiled come talk to us and then there's the deployment proper and yeah so I went a bit fast because once again we need to catch up on the time I guess I don't know yeah if you want to maybe I can take one or two questions why in the benchmarks why was the webassembly so much slower than the native right so there's many many reasons for that first the interpreter that I picked was like the slow West I have ever seen it's yeah it's something that is kind of experimental there's there's also the like data copy a lot of data copy that's that's inefficient there's let me think of the top of my head there's well there's the fact that I mean it's it's interpreted so it's going to be slower anyway and what else could i yeah I think that these are the main factors that I foresee thank you for the presentation and a question is about 1x and 2.0 how the last implementations for these two projects will work together is it exactly the same teams working on it or we have separate approaches there might be some discrepancies just some help for the future right so there's indeed like this does it was supposed to be part of my introduction but unfortunately was rushed so thanks for asking that yeah the role of 1x is indeed like 2 to keep 1.0 alive but it's also kind of prepare the ground for for what comes next and wisdom is the prime candidate for being the execution engine for for 2.0 so that's a nice way like the pre compiles it's a nice contained way to experiment with that in preparation for 2.

0 so do we work together yes absolutely are we the same people some people do 2.0 work I mean I'm more focused on the 1.0 work myself a member of the guest team but yeah I mean we talk we talk it's definitely going to we collaborate where we're having calls to to make sure we're line all right well thank you for your time and yeah sorry there was a bit rushed but are we are we back on on schedule [Applause]