 How's Steph Hong going? Yeah, OK. So my name is Richard Moore. I go by Rikmoo Online. And so I write an Ethereum library called ethers.js. So what is ethers? It aims to be a complete, compact, and friendly Ethereum library that developers can use. But also, part of user friendliness is safety. Like, don't let the developer do things that, like, bites in the ass without realizing it. So one of the cool things is the default provider. I don't know where I should stand. So the default provider will haul. Basically, it lets you just connect to Ethereum. Historically, you had to either run a node, or you have to sign up for an Ethereum. You have to do something to start using Ethereum right away. So we've got a bunch of relationships with these third-party providers. And right off the bat, you can just connect to Ethereum and start doing simple things. It's heavily throttled, but you can at least do something before deciding whether you want to, like, get your own inferior ID and all that. This is all the old stuff, so I'm going to go over quickly. It's written in TypeScript now. Very few dependencies. 26,000 in growing test cases. ENS is a first-class citizen. Everything, including all dependencies, are MIT licensed. And there's extensive documentation. And in v6, the documentation is getting much better. And an important thing is to understand, like, I made ethers because it's something I needed, and it's something that I use a lot. And so I mean, it's in my best interest to keep it getting better over time, and that sort of thing. I think dogfooding is very important to keeping a library good, otherwise, you get a library. It's very good at Hello World, but very difficult at anything more complex. So getting into the new things, then v6, that's coming out. There's currently a v6 available, both on MPM and GitHub. It's still very beta, but it's there to try out. So one of the biggest features is modern ES features. Currently, v5, it targets ES3. So if you are trying to run ethers in IE3 from 2002, it'll probably still work mostly. But that's no longer a priority. And so the goal is to start adding kind of like new age JavaScript things. Heavily reduces the code size because rather than having this big class for big numbers, you can actually just use the built-in big numbers that JavaScript now provides you. So I mean, you can now use the equals, equals, equals sign, which is super exciting. If you want to use a big number, you just put an N on the end, and that tells JavaScript this number should be treated as a big literal. Don't go doing IEEE 754 truncation to it, and that sort of thing. I'm going to try to go through this faster-ish. If I'm talking fast, let me know. But basically, it'd be nice to get to the end so people who have questions can ask questions. So another really cool feature that modern JS offers is proxies. For those that don't know, proxies basically are an object. And if you call a property that doesn't exist, code gets to run first and decide whether or not it should let you think something exists and continue. So this heavily improves how the contract object works. Historically, if you had a ABI with multiple different signatures for different methods, it really required you to understand all the rules for how formatting works to normalize a signature in order to access it. So now you can do whatever you want. So basically, you can have all sorts of white space, extra little letters, and whatnot in there. And this will all figured out at runtime and map it back into that and get the right thing for you. Basically, for all those people who've ever had duplicate ABI definition errors and have filed an issue saying, how do I get rid of them? This is for you. Typed values are another cool thing. So going back to the same situation where you have two different methods, foo and foo, and they take in different things. In v5, there's no way for it to know which one if you pass into parameters. An address looks very much like a number, a 160-bit number, but it looks like a number. There's no way for ethers to actually know which one you meant to call. And so now you can do, yeah, so this would be an error. It doesn't know what this is. This looks like it could be a number. This is a perfectly valid U in 256. So now you can force it and tell it that it's a typed object of an address. And then if you do this, it'll automatically know, oh, this is the one you wanted. So again, really cool things we can do. This is sort of related to proxies, but kind of its own thing. Likewise, if you're doing programmatic things, sometimes you just have a bunch of keyworded objects. And so for example, you've got transfer from. It's got a from, a to, and a value. So this is how you would do it in v5. You can still do this in v6, this works fine, using positional parameters. For those that are used to Python, they call them positional versus keywords. But now you can also do typed.keywords and pass in a from, a to, and a value. And it knows that those things should get deconstructed into the from, to, and some value. This order doesn't matter either. If you wanted to construct this object from a bunch of other lines of code, reading stuff in, you can just build an object up and add a to if it's not null, and add a this if it's not that. And then it's off to the races. Okay, another big thing is things are now classes. Okay, I'm down to 19 minutes. So things have class, basically. Oh yeah, so I'll dive into this a bit more because I think this is a really cool feature in general of something we should be doing more in Solidity. This is kind of steering away from ether specifically into more Solidity generically. If you're using V five, a signature is literally just some dumb object. It's not a class. It's just an object with the values r, s, and v. And that's all you get. By making it a class, it can take in an anything, whether it's a like a raw signature or whether it's an r, s, and y parity, r, s, and v, r and y parity and r, r and y parity and s, whatever random combination of things you have feed it in. It'll figure it out, it'll give you back the signature you want. And then if you do something like update a value, if you said, for example, sig dot y parity equals zero, and it used to be one, it'll also change the v for you. It'll update all the y parity and s. It'll reflect all the changes so that the signature stays consistent, which means so you can get all the stuff out of it. And that sort of thing, but the cool thing I want to show off is, maybe I'll come back to this in a second. That's how things are done today. Maybe I will explain this quickly. So these other things are basically done today. So this is basically people that pass in a signature for solidity, for doing EC recover on. They pass in a bytes or they deconstruct it themselves. So that'll be the third slide for now. But they'll pass this bytes object in and then you've got this expensive, weird byte manipulation library. I mean, it's well written, it's by Open Zeppelin, I think, but you're doing a bunch of string manipulation on byte arrays to figure out where the RS and V sit. It's also a huge amount of data otherwise. And then this is what your code looks like. The cool thing with these new things are a class. You could, for example, in your code, have a signature that has an R and S and a V. And then you can just use the sig type from the struct. And this is your EC recover. So historically, you might have also seen a verify that takes in a byte32, digest a bytes32 V, bytes, sorry, bytes, you went eight V, bytes32 R, bytes32 S, and go off the races. But with this, you can kind of pack them all together. This is the same size for the ABI point of view. And then you just pass in the signature. And because it's a class, when it's starting to build out that encoded piece of information, it knows to take the R and pack it together with the S and pack it out the V in a nice compact format and then you're off to the races. So one important thing to note with this in the next slide is this line here does not change. And so you see, you're still creating a signature, you're just passing the signature in verbatim, and yeah, basically it's because the ABI is encoding it, it can look at this object and figure out, okay, I need to take the difference in this case is the R and the Y parity and S. For those that aren't familiar with EIP 2098, basically this allows you, signatures are much bigger than they need to be, so basically you're used to RS and V. That V is actually just one bit. And thanks to Homestead, every S value in Ethereum is actually always got the top bit set to zero. So we kind of just slot that in. And now your signatures are 60, 30% smaller. And yeah, again, feel free to ask questions because these are gonna be a little complicated, but you need a little bit more math to help decouple that. I'm gonna bug the Solidity guys to see if we can kind of get this built more into Solidity, so you can just pass in the signature directly. But in the meantime, this is still much simpler than the couple dozen of lines of byte manipulation libraries that's going on if you're passing the bytes. So quick comparison, so if you use the raw bytes like most people do today, it's 160 bytes, which is by itself, just for the call data, is 1,444 gas, expensive, da-da-da-da. So if you use decompose, that's 96 bytes, but if you use the compact representation, 64 bytes. Yeah, I'm not gonna go into more than that. That was just a quick thing for people who are looking at the slides afterwards. Transactions are also now an object, so if you decouple a transaction, if you just feed in a bunch of raw, like a raw transaction object or a bunch of stuff, if you start updating the stuff, it updates the other parts of it as well. Yes, basically, when you have just an object and you set some property on it, you're only updating that property. With this, when you set a property, it sets that property but also updates all the entangled properties. For example, if you set the gas price, then the serialized version of that transaction should update. And you can just set things. You can set them to anything that's valid. So in this case, I'm using a big int, but you could pass it a string, you could pass in a hex string, you pass in pretty much anything you want that makes sense for a max fee per gas, and it'll be reflected. 13 minutes bits. So this is just a little odds and ends of random things. So pausing providers. So for example, a lot of people find that people keep their customers keep their app open in a tab that they're not even looking at anymore, which means that their events are still firing, it's still hitting the infira, gobbling up all their requests. Well, because there's now these visibility APIs available in browsers, you can tell ethers, by the way, when I'm not visible anymore, pause the provider. That way, if they go to another page for a week and then they find that tab that's left around from like a week ago or a month ago or we all have really old tabs, this way, they haven't been consuming your bandwidth every time that you've been, they've been doing nothing with your site. So you can pause your provider, and then when the tab becomes visible again, you can resume, and you get the choice of whether you want to replay all the events that would have happened during the time that was paused or whether you kind of want to just drop them and keep on going. Both situations have like valid use cases, so up to your own personal use case. The cool thing with this feature is because we can now pause and unpause providers, all the underlying API and framework changes that went into making this happen, it means that if you have, for example, a WebSocket and the WebSocket disconnects, it can now reconnect and resubscribe to all your events before it starts feeding you the new events that start coming in, it can actually get the events that happened from the time it disconnected to the time that is now. And so all your events come back in order and you don't miss a beat and you don't even know that your WebSocket crashed. And odds and ends, I'll just go over these quickly. Basically networks are now a plugin, they have a plugin system. There's a lot of really strange networks out there and I always get like requests saying like, oh, my network computes hashes in this strange way or my network doesn't have an author in the block or this sort of thing or the other. So this makes it possible that ethers can stop capitulating to each of these individual things and all those oddities, which are fine. I mean, competition in the ecosystem is good, but then we can push all those differences into the network object and let it handle it. And package exports, I'm moving away from a mono repo which uses a bajillion sub-packages all by ethers because it used to be like at ethersproject slash ABI at ethersproject slash providers and that sort of thing. Package exports are awesome, they're supported by all major bundlers now and it means that there's no complicated weird process going on for ethers build. For those who've used ethers or tried modifying ethers at all, the build process is absolutely insane because I try to target, again, ES3 and React and I try to build for everything and as a result, people who are using more modern utilities like people complain about Vite a lot or if you're trying to build a bundle for Node, it just fails. So the nice thing is by using package exports, instead of all these crazy custom scripts, it just kind of works with all these tools and everyone's happier. I hope we'll see that after I launch the non-beta. There's better and fewer dependencies, I'm actually gonna grab a bit of water. So yes, there's basically, I think I'm at five dependencies-ish right now but down to four authors, which is an important thing. I feel like we've all recently been pretty worried about supply chain attacks going on from MPM installing a bajillion things and so right now, there's four well-established authors that are responsible for all the libraries, so there's me, I actually myself well-established. There's Paul Miller, who does an awesome library for hashing and for signing and Microsoft writes TSlib, it's a tiny little thing, it just helps save some space and there's a popular WebSocket library that works in Node. If you're using a browser, you don't have to use that one, so now you're down to three authors and four dependencies. And it saves me a lot of work as well because there's so many times where Elliptic has some bug in it and I'm trying to track down him to get him to update things and once that's fixed, I now update everything and put a new build out, so the fewer dependencies, the happier my life is as well. And that's all I've got. I've got nine minutes for questions, if anyone has questions, oh, and come find me afterwards, I've got these little, like, aha, I brought one up. For anyone who's curious about v6, I've actually started to write, oh, I should explain that, so yes, basically I'm trying to write a bunch of little apps right now against v6 to help test it, so this one's actually found quite a few bugs already. It's an NFT, it's got a little scratch-off hologram when you scratch it off, you can scan it and claim it and you can fold your little papercraft robot up and do this and then take pictures of him and post it into the contract and you can, I'm thinking of more of that little gnome from Amelie, you can take it around and show you that this thing's visited different places. Right now it's going to deploy to DeGorley for anyone who actually goes through the effort of submitting this. I will be migrating your tokens to Mainnet. If you wanna wait till the Mainnet version launches, the same QR codes will work on Mainnet and you can claim it there. So that's just like a little demo I'm flooring together to test and make sure v6 works and it's definitely not ready for production as it stands right now, but it's getting closer and I'll probably be doing a few more little weird projects like this just to kind of like find those little foibles and things that happened during the last two years worth of rewriting and rewriting and rewriting. So I've got seven minutes, 49 seconds left for any questions out there. I don't know where we'd be without you. Like, open source hero. Thank you. At this point in the state of Ethereum, at this point in the state of Ether's, what kind of support are you getting in terms of like audit help, especially as we see more like front end attacks and things like that right where it's like, you know, smart contract auditing is important but the interaction layer is equally as important, especially now as people are getting more clever, like, you know, not to throw shade, but you know, like when I saw string normalization for ABI calls, you know, I instantly thought like just made me like uncomfortable in my gut of like different things that could happen. So just curious like who's helping you audit, who's helping you kind of like comb through this code and go through different edge cases and things like that. Right, so basically auditing is all done by me, which is terrible right now. One of the cool things though is between, I've got like, the EF helps sponsor me. I get GitHub grants, get coin, get coin grants, a few sponsors. And so now I'm starting to develop an endowment. So I am hoping to be able to get like a proper audit at some point. There was one team at one point that was going to formally verify a bunch of things. Close to. I haven't heard from them in a while. So I don't know if that's still a thing, but I think form over, I don't, I'm on the fence with formal verification. Like it helps in some regards, but it's not a magic bullet. I think absolutely like proper auditing would work. And I'm also a big, that's why I'm a big fan of tests. I don't want issues to happen. So I feel like tests, I mean tests can only find the presence of bugs, not the absence of bugs. So I mean, it's a great question. Talk to me afterwards if you've got some ideas. I'm starting to get some money off to the side now that I can actually start throwing if you know any like auditing firms that do TypeScript. What you mean? Should definitely pay for auditing. Those people are so skilled and valuable. Oh, okay, sure. Well, I mean, you kind of are. I mean, thank you, GetCoin. GetCoin's been awesome. So. I was wondering if you are gonna add batch transactions in this version. Sorry, it's a little bit hard to hear with the echo. Are you guys know about batch JSON RPC? Batch transactions, sorry. Oh, batch transactions. What you mean by batch transactions? Like via smart contract wallets? Like by, you mean through smart contracts or? Yes. Yeah, yeah, yeah. I mean that already works. You just need the ABI for it. There's not currently in Ethereum an official like batch standard, but you can do it with smart contracts. Like smart contract wallets. Like an OSIS SAFE, for example, allows you to send mobile. Is that what you mean? Like being able to send multiple transactions at once and atomic, atomically? I have an application and I was, I want to send a batch of transactions in my node application. Not through contracts. Okay, not through contracts. So you can't currently in Ethereum in general send multiple transactions atomically or at once. You basically, if you will have a bunch of transactions you're trying to send serially, so the NONTS manager already does that. Basically it's a wrapper that goes around a signer and you can just quickly fire off transactions and it will automatically bump up the NONTS from the initial NONTS it fetched. There are some issues with that as well if you just flood the mem pool with a bunch of transactions from the same address that are all serialized. It could be seen from the network's point of view as a DOS attack and so it might drop them. So that's a feature I want to add to the NONTS manager in v6 as well is kind of the ability to rebroadcast or whenever something succeeds, kind of like have a callback that lets you know something succeeded. And so you can kind of nudge or tell it to rebroadcast the transactions that are still around. Hey Richard, I can't understate how useful what you did for the whole Theorem community. We use what you do every single day back and front and everywhere. So thanks for that. Thank you. That's it. Thank you. Thank you. Thanks. Yeah, that's all right. So yeah, more than deserved. One question about philosophy and this is going to be very specific on being that guy, but one thing that ethers has a philosophy is really the how it returns undefined and actually it doesn't return undefined for waiting for transactions. And we actually talked once in one of the PRs of TypeScript really giving the option of returning undefined when it turns action. You wait on it and it doesn't return anything, for example. And you mentioned that that's not really part of the philosophy of how you're building the types for ethers. Sorry, I missed that last part. So you mean we set a transaction and you get back null or? Well, let's say it's a hash that doesn't exist. Okay. What is the philosophy of ethers returning that? Would it be undefined? In their case, the TypeScript for that doesn't contain undefined. It always says it's- Oh, I know what you're talking about now. Okay, so that's a big thing in v6 as well. I should have probably put on the odds and ends. Okay, so- We four came for exactly that, so. Right, okay, so for a quick background, basically ethers v5 was started two years ago. I was still kind of learning TypeScript. It did not have strict null checks enabled, which basically means anything that returns anything. I'll return that anything or null. And so in v6, I've got strict null typing and strict null check type. Whatever, what the plague is, it's enabled. And so, for example, the provider's method for get transaction, the return type is null or transaction response. Whereas in v5, it was just transaction response and I just trusted people knew that it could be null, but don't worry about it. So yes, v6 has been fixed. It helps fix a lot of people's libraries as well that are dependent on it and are kind of crawling into the ethers tree to run their linking rules. So yes, that's absolutely changed. And will there be backwards compatibility between those new big int type and the old big number type? Like, will big int be big number-ish? Sorry, will what be big number-ish? Add the new big int type. Oh yes, for input types, you mean? Yeah. Yes, there's still a big number-ish type because, like so for example, the slide up there that demonstrated, I lost the clicker, the slide that shows you like the transaction dot max gas equals, so that takes in a big number-ish. So you can pass in a big int, you can pass in a string that happens to be decimal number, you can pass in a string that's a hex number that'll all be munged into a big int type, but you can still pass anything, anything that's not ambiguous, ethers will accept. It will not accept things that it can't possibly interpret, like for example non-zero x prefixed things, because if it did that, it wouldn't know whether one one was hexadecimal 17 or binary 11, and so it requires you to be completely non-ambiguous. So if you pass in a string that's one one, it's going to assume it's decimal. But yes, it's still a big number-ish. And there's functions as well for your own purposes that will convert any big number-ish into a big number, or any numeric, which is another type that it now has, into a number. Thank you, thank you. Thank you.