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

Loading player…

Towards Eth2 Developer Tooling by Gregory Markou (Devcon5)

DevconFri, Oct 9, 2020, 12:00 AM

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/5/towards-eth2-developer-tooling Gregory Markou gives his talk on Eth2 Developer Tooling. Speaker(s): Gregory Markou Skill level: Advanced Track: Consensus layer Keywords: eth2, developers, technical Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019. Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

Transcript

my name is Greg might know me online is Greg the Greek today I'm gonna be talking about towards e2 developer tooling basically you know how are you gonna go from you 22 and is it gonna work and what are we gonna do about it so why not get a preview here okay so quickly who's changed who is changed safe I changed we're a Rd protocol shop of Toronto about 26 people mainly in Toronto and a little bit distributed and we're working on an e2 client called lodestar and who I am I'm one of the cofounders of VP engineering you can find me Greg the Greek just about on everything and yeah so what is lodestar so lodestar is a type script an assembly script basically eath to ecosystem we're building just about everything that we can in there rationale you know a lot of when it comes to interacting with blockchains 90% of time you're using javascript so we actually we're gonna need the support there and basically some of our focuses are on like clients the beacon our main focuses are on a beacon chain of a foundation like client implementation which came and had a really good talk on yesterday and how they advise checking out the videos and slides and as well as developer tooling because naturally you know as i said we're gonna have to interact somehow and web sites mainly do it do javascript so my agenda is really simple today we're gonna look at like where we are now and then how we're gonna try and you know do a migration some sort of a migration path that makes sense so that you know everybody working really hard unlike their tool sets don't have to rewrite everything cuz ode suck and a lot of waste of time so basically like where are we are now that this slide was so hard to make by the way like there's way too many like teams out there and if I didn't add your stuff I'm sorry this is just like what I typically interact with but I mean we have a lot of a whole vast type of tooling that exists right now a lot of it we have providers like what 3GS ethers j/s development related stuff like truffle ganache soul CJ s you know wallets that do a lot of like the hard work for everybody and they don't really realize what they're doing in behind such as like well connect meta mask frame so many more really helpful debugging tools like EVM lab and some of you might not know what it is but it's like helps you really like dive deep and is seeing what's going on like within the EVM while you're running executing your smart contracts and now I see there we got like really great websites that like help you build some our contracts like play and remix that are integral and one thing to note with like just about all these things I've listed here I'm pretty sure they all use JavaScript right now and it's like very deeply nested in them for how they make their connections and actually interact with the theorem so moving forward you know with theorem 2.0 there's one big thing that we have to note and it's that you know our api's are not at all equivalent like zero like the compatibility is like next to nothing which means that everything we've just listed here would not work right out of the gate it actually takes quite a lot of an overhaul borderline to rewrite if we didn't do something to help better support a transition period so that's what I've been focusing on personally so I've been spending a lot of time personally on you know how can we make this smoother transition for teams who are building quality tools that are used every day I mean like I think ethers alone does like 13,000 thousand downloads on the little used packages on like the github downloads thing which is like that's a lot of people like depending on you know one small piece of software within the larger context of the ecosystem so just like to highlight the example you know we have a block in you know eath lon and we don't really have a one-to-one equivalent because we have two types of blocks and eath too so that's a problem we also have shards shards don't exist so your eighth one I don't know what you would what you do there you know like you what would a Thursday when you say get block where do you go you know there's two blocks and there's also many shards so and then we have execution environments I don't even want to touch that and I won't be touching today is like that's something else but to highlight my point is like there's so many discrepancies that the api's will never line up and they won't but there's some things we can do and there's some clever things we can do so something I've been thinking about as an interim solution and obviously this is not great you know the more I've been talking a lot of teams especially truffle has been like no they want like they're happy to do like a like a proper baked in solution but something interim that we could do you know you know with ether is what we typically do is you pass in you know the test net or the network you want to use and what we can actually do is we can create about a like an adapter sort of like that sits right on in the outside and wraps all the requests and basically the idea behind did that slide getting to know and basically the idea behind that is something that we did a chain safe with something called ether meant from the cosmos ecosystem where we made the EVM work on top at Endermen but naturally they again it's kind of a similar situation they don't line up but we had to make sure that all the developer tooling like worked right out of the gate so that you could it was like playing in a theorem cuz you know otherwise why would you use it so what we did was we basically added this layer in front that every time an API request came into the EVM or in this case it would be like when it hits the beacon chain or AOL whatever's there we're basically looking at it and then translating to whatever we think makes the most sense from that side so we can do that with the beacon chain right and with this so chances are you have a contract you're saying hey I want to look up this contract you're probably you have to get routed to a shard because that's where your contracts and be living and you're gonna have to you do it that way so we can just take like a generic request from you know the standard eath one API and like rewrap it and pop it back out that works it's not great you know we that mean every client team would have to go and adopt this like a interface sitting in front of their current whatever we end up making these two API whether it's Jason or you know whatever it does the job it's not great you know we could also integrate into the provider so you know we could actually put it into ethers again not the optimal solution this is something we're thinking about ideally we're gonna have to do some sort of a ground-up rewrite on our providers and if we can do it from the providers perspective then we actually save ourselves as long as the providers maintain the same API format and then we're just doing a lot of magic and behind we actually won't have to rewrite a lot of our dev tooling and like dev teams can continue to operate as they did before naturally it'd be nice to get some like native you know if two tooling but to help ease the transition over this is one it's something along this line will probably have to be the best best case we can do otherwise we just won't have anything ready by the time youth two launches and there's no point in spending resources doing twice so that's my little provider show and I'm happy to talk about this a lot more after something else that's kind of interesting and this is funny you know it's like hey maybe we can solve it after 30 years but we won't is the intersection of like like clients and developer tooling and how we can actually potentially make smarter developers and by this I mean like more on the front end the D app side because right now you know we spend a lot of time a lot of our the ways we do things we do a lot polling for instance a lot of developers like go and pull the chain like a million times over and a million times over and then like you know if they're hitting in fear of getting like you're bombarding in fear with like thousands of requests it's not a great solution but moving forward because you know like clients are becoming our first class citizens in 8th - which means we actually can use this as like a powerful tool to help us you know not exhaust resources and actually utilize only what we need to you know serve our DAPs or serve whatever the application is moving forward so I've naively put you know we're still working on this and it's kind of like I want to try it we're trying to think of a new way to like reshape the way we interact with the chain I don't want to go too deep on my clients but like it so basically the idea is you subscribe to a shard that you want or a subset of shards that you want and you only get the relevant data that you need very lightly put and something that we can do here is the current and flow in eath one is that you know the website to connect to the provider that provider then hits a full node has to the full node asset like basically index the whole thing to find what exact information you need and then returns it very slow very cumbersome with like clients we can use we actually couldn't put the burden back on the website or the client or the browser itself and this is kind of interesting because what we can do is we can do one of two things we can say when you go into a website we can look for now I know a lot of people are gonna be like you shouldn't be injecting like web 3 into the browser but we're not gonna talk about there right now let's just make a naive assumption so is there like an e 2 object in the browser if there is we can assume that there's some sort of a provider already existing and there's like potentially a plug-in like meta mask in that case we can't meta mask in this instance would be hosting a like client actually within the plugin this allows then the web site to go and say hey I need you to subscribe to this chart for me and then start persisting and maintaining the data while that and then you know once the day is requested the website use it as it's going while that's happening we can actually cache you know that shard data I know a cookie local storage or even if it's a plugin the plugins state and alternatively if we make our provider smart we can then actually have the website itself if the user doesn't have a plug-in we have the website itself actually spin up a light client and this is because we're gonna we will be able to do this simply because we've got languages you know compiling to wasum but also load stars like whole goal is to have a light client that runs in the browser that's native to the browser and works so with that we can actually kind of like exploit the browser to its fullest capabilities so that the burden doesn't go on like a centralized service like in fear and don't get me wrong I configured as is amazing you know that we have two lot to thank for them but let's try and take the burden away from them if we can and a scheme something like this would definitely help solve a lot of those issues and could potentially change the way we develop and serve data yeah that that's then I under my talk I let's chat afterwards if you are tooling team because like there's a lot to kind of discuss here it's still pretty early but there's things that we need to start talking about now I know there's a lot of pain points and current api and the current way eath one works in regrets like the json-rpc api and we have an opportunity to kind of learn from our mistakes reshape it from the beginning and just saw and basically you know make it as optimal as we can right out of the gate so thank you and you can contact me here [Applause] you

Automatic transcript — names and jargon may be misspelled.