ethers v6

[Music] [Applause] [Music] so next up we have rick moo and rick's going to be talking about ethers v6 so without further ado i'd like to welcome yes we can excellent excellent um so just jump in then yes sir excellent so um let me figure out how to go back to sharing screen so as some full disclosure i kind of got confused as to what talk i was giving today and so i prepared the wrong one so i spent the last hour throwing this together so there might be typos and such um can you see this yep excellent excellent we'll do it live with the bill o'reilly round yes exactly so um this has not been fully thought through or but here's my best um thing so i think probably a lot of people are familiar with ethers um so i just want to give a quick overview what the v6 is going to be about um right now v6 only lives on my desktop as a local repository but i'm hoping within the next two weeks to get a public beta out so people can start using it um i'm also hoping there's lots of questions that people have because i don't think this is going to take up the full half hour but we will see i'm also awesome talk uh austin it was uh it felt like uh like the movies were like the counter is counting down and you're trying to get this this contract deployed in the last like you know it's coming down five four three two and then you're done you saved it you got just in the the neck of time so anyways back to ether's v6 um so one of the big things with ether's v6 is it's esm first so there's no longer going to be any es3 support so if you're running node 8 or no 10 um or you're using an ie era browser things probably will not work out well with with v6 i plan to keep v5 running for a little bit for people who who really need kind of those old old platform supports um but there's also some things i'm changing in v v6 that'll make it easier to maybe like use babel to get those es3 like things working um so also because everything is esm the build process is far more simple for those that aren't familiar the build process for for v5 because it builds es3 and it builds um es esm modules the and also because typescript does not support multiple targets in that way during the build process for comp for composite packages during the build process it has to rewrite all the ts config files everywhere all over disk and then recompile it um this just leads to a really complicated build process so this makes things much easier also esm has much better tool support like i said between babel and all the different bundlers things just work also all the dependencies are esm which really helps the bundlers because the bundlers usually choke the second they hit elliptic or they hit bnjs or js these like traditional javascript libraries so basically not in a nutshell esm first is like a key part of of v6 and part of that is because now we can use modern es features for example we can use map or weak map or any of those really or especially proxies those really cool features that javascript has introduced in the last five or six years just because v5 tried to stay compatible with a very large audience so proxies are very cool for those unfamiliar with proxies they're basically a javascript object they can trap when you're trying to do stuff with them i've got a better slide next that kind of demonstrates that private members a lot of the things in v5 they were private just by virtue that they had an underscore in front of them the problem with this is people kind of tinker with and and and break things they don't even realize they're breaking by interacting with these private members especially other frameworks i've definitely seen frameworks who are tinkering with private members and then i get an issue because ethers isn't working for them but it's because it's been broken somewhere else along the way again much better bundler support this is an important thing i think for most people at the end of the day everyone wants to make a react native app which needs bundling or as awesome was just showing with scaffolding you want this one thing all bundled up into one little concise package that can sit out on the web and be served from some cdn and your app should just work bigint 20 es 2020 big int is kind of like um it's a it's a weird point for me because on the one side it's really recent es 2020 if you have a browser that's that's made in september 29th or even if you have a react native app that was made in september 29th of 2020 it's going to fail the work with this version of of the library so for es2020 bigints there's also an additional dist file which has a which is um got the big int stuff swapped out for the traditional big number libraries so internally it'll be a bit slower but it'll still work on older platforms um backwards compatibility for those who don't know me is very important i maintain a lot of really old projects and it sucks when there's literally no path forward to keep them alive because i can't update this version of that thing without breaking this and vice versa um so next slide contract proxies so this is really where the proxies are going to shine um so right now if you use um ethers for contract if you've got a function called foo if you've got multiple multiple functions called foo or in this case adder it's hard for for the uh the system to know which one you mean if you have one that takes in an adder and a uh 256 and when it takes in an adder and a unit 128 there's literally no way that it can tell which one you actually intended um which is why you then have to specify the actual signature which gets complicated this might be too much detail for some people i'm not sure but those who've who suffered this they are very vocal about suffering this and so um they'll be the ones who appreciate this the most and i'm hoping people going forward will appreciate this without realizing that they're appreciating it but basically you can force a type so in this case we see that you've got to typed until six you're casting this so if there is for example if there was a function called adder that took in an address and a uni-256 and an adder in a un128 this is now not ambiguous the system now knows exactly which one you meant because that chain id has been forced into unto 256. the other big advantage of the proxies though is if you see the next three examples they're all they're all referring to the exact same method this this address that takes an address and you you do you into 256 um well it will normalize them before you even get to the point so the proxy actually gets the string and gets a chance to normalize it into a string to do a do a lookup in its own lookup table so it doesn't matter how you specify this method it'll be able to find the one you want whether you have extra things in there like the names or not the names whether it's a view public all those extra stuff it just throws it away so that's the biggest advantage of of having a proxies is at run time i can decide what you probably meant now ethers will still never guess if it's if it's at all ambiguous then you're going to get an error you have to but you yeah the problem with ev5 though is you start getting all these warnings in the console logs just by loading this um this abi this at runtime can tell you you know you're wrong you know go to go to jail do not pass go that sort of thing um so typescript when i wrote v5 it was very much based on v4 and i had never used typescript before and so as a result there was a lot of decisions that were made that were i mean at the time typescript was still very young but there was a lot of decisions i made based on javascript developers javascript is still very important the nice thing is modern typescript takes into account a lot of things for javascript developers that it did not back then so it's been redesigned a lot with typescript as a first class citizen so typescript is like a fundamental part of of the library now not just kind of useful for for people who um who use typescript so all dependencies are fully type typescript there's no more weird little libraries lying around that uh have types that were made by hand and therefore maybe not quite right it also again goes back to the bundler thing because all the dependencies are typescript and all the bundle all the dependencies are ecmascript they kind of cohesively work together better without weird foibles there's also a lot more templating in v6 and i'll give some examples of that next but even with the templating i don't think there's many places where you have to explicitly specify the templating it will fall back onto meaningful defaults for you strict error checking is in now which is something i know a lot of people wanted um in v5 anything that returns something can always return something or null and this means that you miss out on a lot of type checking because you if you're not doing null checks then you might get a null object back and you won't get any compile time error for that and there's better separation between concrete classes and abstract interfaces there's moving around more on that in a few slides i think again the slide deck is really new in my head so oh those came first excellent so concrete classes so i've moved some interfaces to concrete classes so interfaces are kind of good for things that you want the flexibility of just what they should look like whereas classes are nice because you can actually do things to them so one of the big changes is networks networks are now an actual class there's actually another slide even later later on about networks so i'll go more into it then um but it means that they can do [Music] much more things at run time based on the parameters you gave them the other big one is transactions transactions for serializing and parsing they've always been a hassle because people do weird things people specify a v as well as an y parameter or they specify a vs as well as an s like there's all these things that i had to check and make sure they all worked together so now that transactions um are a proper object it's much easier to set all the things on it especially these days um with eip 2930 eip2718 eip 1559 we have all these weird things that go with with transactions so this just helps bring them all together and much easier to to either parse or serialize or pass them around a transaction object is now a valid object for example to pass into a signer if you wanted to send it and transaction responses for example inherit from transaction so it's just like all those all those that's actually a slide i should have made um i'll make a mental note of that so basically the inheritance model makes more sense because you've got transaction requests transaction responses transaction objects parse transactions all these different types of things now that there's a proper hierarchy to how they all interact with each other you can pass one thing in from one thing into another thing that should accept that thing in v5 right now it does a lot of checking to make sure you're not shooting yourself in the foot but sometimes that shooting yourself in the foot is almost desired um so this makes sure that when you shoot yourself in the foot you're shooting yourself in the foot safely if that makes sense also there's a much more flexible web api it provides pre-flight checks and advanced retry logic this is useful aws has added a lot of functionality for blockchain type things but the way they interact with with authenticated requests means that there's a lot of things that are very hard to do right now so the new web api i'm looking forward to sharing um i use it actually in other non-ethereum ethers based projects so that's a bit on concrete classes so abstract interfaces i also moved the other direction some things that used to be classes are now interfaces um so the signer and the provider used to be classes that you had to inherit which meant if you want to do really custom things you sometimes couldn't because you had to inherit from provider you had to hear from signer and now you're stuck because you might want to subclass something else that's more interesting or you might not want to implement a thing that's in those abstract classes but that it needed that you don't want uh yeah another big thing a lot of people asked for so i'm just blowing through these i'm hoping for questions to clarify anything people so please write down questions and bug kartik for things that come up um i think he'll pass those along to me um so addressable this is something that i know people really are frustrated with there's weird errors because right now if there's a function call for a contract or there's a method on a provider that takes in a address it accepts addresses and accepts e s names a lot of people have bugs where they pass in a signer instead and a signer is 100 reconcilable as an address it's just v5 doesn't do that so in v6 you can pass in signers or accounts or anything that's meaningfully an address into something that expects an address and so there's this whole address type that things can implement to ensure that the system knows that they're an addressable and that they'll just work the new feasible api so this is another thing that ethers has always done and it's been a huge point of annoyance for a lot of people everything in ethers is immutable this is really important for an asynchronous environment because you don't want to pass something into the provider have it preparing to do something with it and then you and another part of code start mutating that object and now maybe the provider receives half of the mutated states and half the mutated states so everything in ethers has historically been immutable so with the new feasible api you can pass in a mutable or immutable object the first thing it's going to do is create an immutable copy of it internal to the provider so you can go off and now do weird things to the thing you have and be assured it's not affecting anything else there's also a lot of places in ethers where it passes you an immutable copy for example a transaction you might get for example you might hit a provider ask for a transaction um want to change some things on that transaction and then send that transaction maybe just update the nonce or something well you can't do that as it stands right now because those things are all coming back as immutable so with this you would get back an immutable copy but there's always on the cli on the freezable api you can do.clone get immutable copy which allows you to modify the things you want to pass so it kind of like helps keep things safe by the things that need to be immutable or should be immutable are still but when you need a mutable copy for doing something useful you can the air interface i'll actually go into more as well in another slide but it provides a type safety for the property access because ethers provides a very complex complex right word a very useful but not not the the way that most people are used to handling with errors and yeah i'll get to that in a second anyways oh actually i'll get two next currently um so errors so here's a great example so right if you have a modern typescript thing errors come back as unknown you don't know what the air is so this actually uses um a conditional type in typescript so it knows that the transaction replaced is an enum and so once you're inside this is air i don't know if you see my cursor i'm wiggling over top of the air dot replacement once you've once you're inside this block for is error it the typing system is now fully aware that the air object is of type which is an interface is the interface of a transaction replaced error sorry i'm talking fast from okay so yes once you're inside this block it knows that's the type so it knows what properties exist it also knows what types of properties are and so it also means that anywhere in the code that throws a transaction replaced error it must provide all the properties associated with that so it kind of helps on the coding side to make sure i'm not missing a property that you really want to exist and to make sure that when you want to use a property um that you can have the type checking in place to verify as the property is the right thing um i don't know how much more i think i'm almost done but so the network network so this was talking about before one of the biggest issues ethers has right now is not just the issues but requests i have from ethers is people start having these weird chains they've chains that no one's ever heard of or they're chains that i've never heard of at the very least because i don't really follow a lot of these um like fringe or even some of the common ones um uh chains so the network now bundles a lot more stuff into it but as a result the network is often enough to [Music] to specify a chain that's weird in a strange way if it has a different address format if it hashes things differently if it needs to talk to l ones to do something the network object the network object is now more more cohesive more more flexible you know a lot of those things so for example right now for bsc and for polygon and for um arbitrarum i don't want to pronounce that one but for those types of chains they actually sometimes require a whole different package which provides a new json rpc provider and therefore a new static json rpc provider and a new ether scan provider all these extra things just because they changed something that's kind of fundamental to ethereum but for their chains it made sense so with the network object being pulled out it means that you can now have just a a bsc based network and things will just work the the world's a happy place um all that extra work that needs to be done is done inside the network object instead of inside the provider um on that note the plugins the plugins uh are kind of part of that as well it means that a network can use a plugin to describe a more complex behavior full d of the one the biggest issues with l2's right now is that the e and s support is not obvious for how it should work e s on an l2 is somewhat complicated so with the new network object we're now able to fully support um l2s with e and s basically they need an l1 connection but all that happens internal to the network and the provider objects so you can just start using ens names on polygon for example um and also during unless you're people from durham it's an awesome way for l2s to interact with anything like basal it basically means anything can become an l2 it's really awesome if you don't know about it check it out but there's built-in support for it um one of the big advantages of using plugins is we can in a very backwards compatible way add support or remove support for things like durin so durin right now will be by default off but we'll have a plug-in that will turn it on in the future we have it by default on and have a plug-in that turns it off um yeah lots of awesome flexibility ah excellent i'm done so i guess i will open up the floor to questions if anyone has anything to i'm sorry i blew through everything really fast but i'm hoping to fill in the time with questions or the things i blew through too quickly or did not describe enough words to like um yes it's a good way we're good here um all right so a few questions few comments and a lot of a lot of amazing comments um first of all everybody's excited about typescript support so that's that's great that's not a question that's just a lot of happiness uh obvious question what is the timeline of the release um how are you thinking about that and when can people try this out so right so i'm hoping for a public beta in maybe two maybe three weeks i have a minor bump i need to get out this week um i'm hoping this will be the last minor bump of v5 um so hopefully in three weeks time and maybe even earlier i can i might not have a version up on npm but earlier i am hoping to even maybe have a github repo up so people can kind of see the differences and if they're really ambitious you know try it out from that without npm support but it'll be on npm hopefully within i'm hoping two to three weeks but you know this is ethereum so two weeks tm giveaway take a month uh this is great uh okay so another kind of question and a theme is uh talking about you you sort of touched on this but talking about um multiple networks like is is the fallback provider the best approach still or how do you think about supporting multiple networks uh more appropriately and kind of talked about some of them like optimism or arbitrary and handful of those absolutely so you should always still use the fallback provider if you have that opportunity um one of the cool things i'm doing with that is plugins so for example if you pull so there's ancillary packages so for example if you pull in the ancillary package for for polygon or for bsc one of the things it can now do is it can is that new package that you have that somebody else can even maintain not richard someone else can maintain that package it can actually call into the default provider and register itself as a plugin so in the future so basically you would you would include ethers then you would include the bsc package but then when you do ethers.defaultproviderbsc it's actually going to be the bsc package that's responding to that and populating the object as you as you need um and so it will all so that for example will automatically handle um deciding how to connect to l1 so that you get uh ens support it'll figure out whether the network supports eip1559 or all those extra little things it needs to do so weird networks can do the weird things they need and i don't use weird as a negative connotation i use weird as in different like it's behaving not as ethereum does specifically but it's ethereum enough to to work yes cool um another kind of question which is that we can kind of go as deep as you'd like here what are some kind of extensions that you personally wish existed that still don't um and sort of like how does the v6 architecture sort of help enable some of those things from your own personal wish list so so i'm in terms of extensions um i'm not quite sure what that means i'm going to guess maybe like ancillary packages um that's one of the things i'm focusing on in v5 a lot is making more instillery packages and i'm trying to move a lot of things so there's actually a lot of packages in v6 that will not exist at existing v5 i'm merging some packages but for example hardware wallets has been moved out into its own um ancillary package so the advantage of this is it makes the turnaround time faster because i don't want people mucking around with the core the core is still something i want to make sure is like secure and concise and adheres to all the things i want to adhere to but the ancillary packages are a little bit more more open-ended and so for example what i'm hoping to at some point is to just give ledger um the ability to have contributor rates to the insurer package for hardware waltz so that when they make an update they can go in and make that change it'd be nice if trezor can also go in and make the changes as well there's still going to be a gatekeeping thing i still control publishing things to mpm but i can at least let other people manage that sort of thing and so it's exact so it's the same thing as well for other extensions for maybe like diamonds maybe somebody wants a diamond api i don't necessarily need that built right into ethers but if there's an insular package for diamonds um the the author of that eip i could even give uh him or her i'm not sure um permission to to modify or update that as as necessary um so that's kind of like that's part of v5 ish but with v6 i'm making a much stronger push towards moving more things out of the core and into ancillary packages awesome um another question is around um how do you think ethers will evolve to support more cutting-edge stuff like building or testing or interacting with zero knowledge applications or just circuits do you kind of see that that's ether's js's role or what should somebody think about in this case it would depend a lot um actually i've not thought of it before but i think it would make sense so for example there should be probably some sort of zk you can imagine zk sync could have like a zk sync provider um and again this would be a an ancillary package anything that they need kind of bundled inside i would totally be willing to add to to ethers but a lot of that stuff can just be added kind of like as a as an extension library if you don't need zk snarks inside ethers i'd rather not have it directly in ethers but if there starts becoming a thing where all networks start using zk rollups for this specific thing then it totally makes sense to put in there and possibly even wrap into a plug-in for networks um and oh that's another thing i forgot to mention as well uh a big chunk of the redesigning for v6 is breaking things into a ridiculous number of files so in v5 everything was one file inside each package the problem is like bundlers and specifically tree shaking fail tragically when you have one file it has it has to be so it has to be so pessimistic as to what is going to be possibly called that it includes stuff that is remotely completely completely impossible to be involved so the nice thing is most tree shaking systems they understand file boundaries so if something requires me from their file it's completely out of scope of what's going to be necessary and so it drops it so um right going back to what we were talking about a second ago it's actually possible because of this this explanation of files to include zk snark stuff in ethers and because it'd be in its own file separate from everything else if you're not including something that includes something that includes something that includes this it'll automatically get like ripped out by most bundlers exactly and i think in that world like even if something is part of the core ethers library and not being used you can still kind of make the argument that z case could be actually part of the core and that's exactly and then as i said that's one more quick point as well is the size of this library much smaller i'm using noble's secp 256 and a different big number library and because of es 2020 ins it's gonna chop like a ridiculous amount like i feel like between 10 and 20 of the size is gonna get knocked off by this one library change amazing um two more questions before we uh before we close off today um how can people kind of contribute to the project do you need any help with certain things what's kind of the process or things that you prioritize right so this is one of the biggest reasons why i want to move to instiller packages because everyone wants to help i love the idea of people helping but i reviewing code is hard the and the other thing is any code like people want little features added and once you add a feature you may you may spend three days making the feature but now i'm supporting it for life um so i'm looking forward to more insider packages so that i can actually just kind of give some of the ownership up if you really want this feature then you can add it and so it's kind of hard right now for me to kind of like give pieces off to people to work on uh documentation is always appreciated i love it when people contribute the documentation um i love tutorials and once and once instagram packages are more of a thing i'm looking forward to having more people be able to like just take that and run with it um so that will be coming soon again tm and final question which has been asked a couple of times um can you share the slides with our audience so if you can just send that link to me and i'll be able to send it to everybody in the chat so whenever that is ready absolutely yeah i'll send those out perfect thank you so much rick awesome thank you for v6 take care all right with that we are ready for our next talks [Music] [Applause] [Music] you