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

Loading player…

EthCC 2: Alex Beregszaszi

Ethereum ParisWed, Oct 9, 2019, 12:00 AM

EthCC 2 EthCC, the Ethereum Community Conference is created by the community, for the community. It brings together great minds and forethinkers, and allows the community to grow. Follow us : @AssethFR https://ethcc.io

Transcript

hello okay it works so I kinda actually planned for initial ten minutes then the agenda was really confusing so I thought it's 15 minutes extended it and turned out it's actually 10 minutes so I need to skip a couple of things but I hope it's gonna be interesting still so my name is Alex and I'm the team leader he was Amanda co-leader of solidity and this talk gonna be a couple of like insider info from last year and this year from the team itself I think this is the slide which can be tweeted is like the most interesting one so like last year 2018 was a really busy year we grown the team to nine before that four years it's been only like a two two and a half percent team but we're a nine percent team now so we can achieve a lot of lot more things than we killed before in 2018 we have made eight releases that's a lot of releases I'm not sure how frequently you guys update but I think people don't really appreciate all these changes so frequently you should consider using them more frequently as well like one really big thing with it is finally releasing that rating release it took us one and a half years the zero-five-zero if you're really excited about it in the first six months but after like a year and it's still not being released devil super annoying so we finally got that behind us we released it and the last key point there is in 2018 there were only four bucks found another question is does that mean that people are better at finding bugs or are we better at writing bugs but I leave the answer to you guys to decide I don't know to answer to that some tiny notes zero five zero depends on a couple of things like truffle and Zeppelin those are releases you need to use to get zero-five-zero features and on regarding the for bugs two out of the four bugs were fixed in the very last 0 for release and there's still a couple of big projects who pinned their contracts to 0 for 24 that's like a really bad idea because it has two bugs you shouldn't do that and I'm not sure why people really still want to stick with 0 4 0 guess it's not maintained anymore there won't be a 0 for release you have to move to 0-5 it's way better ok we do have some takeaways based on like 2018 the ecosystem is super complex so I'm gonna have like a graph to explain that ok like these are four components we have the compiler versions on the left on the right I wrote truffle but it's really frameworks different frameworks on the on the bottom right it's Zeppelin but it's totally Zeppelin it's different libraries and then of course your contract so the contract depends on a compiler version depends on a library version depends on a framework version the library depends on a framework the framework depends on a compiler version the library also depends on a compiler version all of this is hard-coded and we also depend on them so the reason we depend on them is we take big projects and be used and during CI we use them during testing so every single change with you goes through a couple of different big projects and you know it's an easy way to catch issues if you make any mistakes and it also gives us a way to to see how big of a scope how big of a change it will be to make like a breaking change at a compiler you know how many libraries how many the contracts it's gonna break so it's quite complex and we need coordination between all these projects to get like especially breaking changes out but for any other change you know something people need to update and it's binned so it's a lot of coordination between all these teams at the same time we as a solidly team we want really rapid changes we don't want like this slow cycle of a year and a half to make a breaking change this ecosystem is still early we need to iterate much faster at least that's how we look at it at celerity and the only way to achieve that with all these issues with this big ecosystem is by engaging more people and by that I not only mean like library there's framework tabs I mean you guys Deb developers and everybody else there's no need to write code for the compiler what we need is you guys engaging with us and telling us what you like what you dislike what would you change yeah stuff like that so we just need you guys okay so that was like last year and we have some crazy goals for this year we want to make like one release a month maybe even more but at least one really is a month and we want to make at least two breaking releases this year so this is like quite a big change from the previous two years and the way our religious work now is ahead we just decide the dates for the next two releases and we don't move those dates if we don't manage to implement every item on the wish list for those we just keep a couple but we just stick to the dates so it's a frequent like no one really scheduled for you to pick it up so like these are a lot of releases and you may ask what the hell you guys want to put into those releases I don't really see any changes I don't know what should be changed well we do have a lot of plans to to change stuff so here's like a couple of things there we would like to change I'm not sure if you guys you know you'll but a simple explanation is today the compiler goes directly from solid it is source filled TVM bytecode and we are trying to change that into a two-step process first we translate slowly the source code into this intermediate version let me translate the TVM and by splitting the this entire pipeline into two we can ensure that the two parts are better than a single one we had before we can also apply optimizations into those two parts separately and today we only have one opportunity to do optimizations the other big part which is kind of Comet connected to this as the a bi encoder so quick explanation on that is the way to interact with contracts you need to encode your input data and the output data in a specific way and that is called a bi specification contract a bi specification and a bi encoder is the piece of software which generates this decoder and encoder in the contracts still today we use one which was written quite a while ago it's quite complex within c++ and we have rewritten it in use it's of course way better but it's not enabled yet it's enabled through an experimental program so people can use it but the afraid to use it because it's experimental so we really once you enable it and get rid of the old one I like some check marks there it's like a very random scale 5 check marks mean it's done so we like it for check marks for those things and the optimizer the two check marks doesn't mean that it's bad it just means we can still improve it we can add a lot of more things to make it better the second half of the the roadmap items maybe I won't go into too much detail now because of time but on the top the Yule stuff is really just the lower half and this is like an order of importance and you know what we can achieve during the year so maybe the second half of the year you can have the other part we can have solidity to Yule and I maybe even you'll - he wasn't and couple more things some check mark stir okay the big news you guys seen it yesterday we made a release it was just on the timeline we just scheduled it and here are a couple of interesting things we have changed in it so this ABI stuff it's pretty complete it works there's only like one change left we want to make but this one is like really good at this point the part you're going to notice when you start using 0 5 0 5 5 all these version numbers so the part you're going to notice is that we change the default version the default target avian version from Byzantium to Constantinople slash Petersburg so now if you just use a compiler as it is it's going to generate code for Constantinople you can choose it on another chain but the compiler has a setting to change that traful exposes that setting remix doesn't so if you look for it in remix you won't find it yet and by enabling constantinople we can make use of a couple of changes in constantinople and that means we can have a lot of gas savings so like one interesting thing here you may know that constantinople has been by shifting which is like a miracle on its own why the heli wasn't included the first place in the yeah but it's now there and we have this piece in the compiler called a constant optimizer and what a constant optimizer is doing it translates big literals big numbers into an expression and this is controlled by by the runs parameter and the optimizer runs parameter is super confusing it doesn't mean that how many runs they come up tomorrow you're gonna take it has nothing to do with that the optimizer always takes as many runs as it wants as it seems it's feasible you cannot control that what the parameter actually means we plan to rename it we plan to rename it to executions per deployment so it basically just the expectation how many times this code going to be executed on the chain so if the number is low that means you gonna just deploy it once and you won't rly execute it too frequently so the compiler will try to optimize this for deployment cost that it should be a low deployment cost but the execution cost might be higher because you don't really run the frequently now if you said the number high you expect that it will be executed a lot of times so you may be happy to pay a lot more gas to deploy it but you want to save gas on execution time and this code it practically breaks up numbers into an expression of a shift and an addition but before Constantinople there was no shift so it was an extra nunciature and multiplication really expensive but with Constantinople we can make that cheap so if you guys go for which yeah if you guys go for like a less frequently executed contract and use a new compiler to you to compile it it's gonna be very poor than before and that's like in order of like 10 to 25% savings the last point there is the OSS fuzz anybody knows anything about fuzzing so fuzzing is a say a security / testing technique where you feed random information into the compiler and you try to break the compiler so that's the goal but you can do this like in a really dumb manner you can just feed random stuff into it and you may wait forever to get a crash or a problem so fast thing usually is a bit more advanced and it's for example takes a corpus of source files a set of source files and has algorithms to transform those and and it has a much better likelihood that this transformation going to result in a source file which is accepted by the compiler and maybe even break the compiler so as as fuzz is a carry on time okay so what's this fuzz is a project by Google it's for open source projects they can submit the codebase and Google gonna gonna run fuzzing for them 24/7 in the past two years the security team at the EF has run fuzzing from time to time um but it's you know it was like a home run solution OSS fuzz is way better a lot of big companies but a big projects use it if you have like three different cases of solidity being used in OSS files we just first the actual compiler with solid source code but we also face it with dual source code and it has found in the last like month and a half it has found like 25 issues but none of these are like big issues in terms of generating invalid code it's more like issues at compilation time you get like a wrong error or you know it's the wrong message or it crashes or whatever so it's it's nothing serious but it still improves the compiler a lot so that's like what we did in this year so far and this is what next hopefully the next release is actually breaking breeze I don't even know what's the date set but we do have the date set and these are the big changes in it so like the big one is this API stuff it's gonna be on by default the other one is inheritance during inheritance today you can just override functions nobody complains it's terrible you don't know what the hell is going on so that's going to be changed there going to be a requirement for a keyword to enforce that you can override something so there's a keyword on the parent and there's a keyboard on the on the child contract and a child contract you have to say I'm overwriting this in the parent you're saying I let you to overwrite this in any other case there gonna be an error and today you can just do whatever you want so that's gonna change the the last point is somewhat related to this because that's four variables so today you can just override variables and the semantics is not fully clear what happens in that case so that that they're also going to be be cleared up and the abstract keyword for contracts so like today a contract if it's missing functions it's an abstract contract so what it means is it won't produce your bytecode but a compiler doesn't tell you this you just have to figure it out yourself so that's gonna be changed I can be keyword if you said that keyword the contract gonna be abstract if you don't say the keyword and try to compile it it's an error because it's not a complete contract and that's like that link for the project board where we plan all these issues you can have a look at it you can comment on those issues you can propose new ones you can also join our calls and I really invite all of you to do that said that was really just update ahead I'm not sure if you have like time for a lot one of two questions if you guys have but I would be happy to answer any questions oh cool thank you guys [Applause]

Automatic transcript — names and jargon may be misspelled.