Shortcuts to Better Dapp Development | Nenad Vitorovic, Tenderly | ETHTaipei 2023

[Applause] foreign I hope the mic works and I hope I maneuver it properly and today I will talk about shortcuts to better dab development but it's not top 5 GPT prompts that you can use to speed it up it'll be less Corner cutting and we'll go into a discussion even about where do we see the problems that make dab development slow and hard and how can we speed it up in other words where do we actually need innovation in in this space so let's start with the with I think this is an obvious thing web Redevelopment is hard so raise of hands how many of us agrees Davis card I think like 60 at least raise their hands thank you so much uh on the other hand weather development is fun razor hands well pretty much similar number come on it's fun and let's let's dig in uh to how can we build shortcuts that enable us to actually have more of the fun part and less of the hard part uh before I start talking about this I'll just uh ask you to think about what it may what is it that makes web Redevelopment a hard thing because I would like to get your input during the the presentation so let's make this a little more Interactive when it comes to building shortcuts to better dab development we can either we can approach it from from two angles the first one is to build tools and make the development such that interoper operability and integration is becomes easier on every level and another thing is better development workflow with more cohesiveness and less friction along the way so these are the two angles that I'm going to address now through various various examples but before we do that let me just tell you a little bit about tenderly so tenderly is the company I'm coming from and we're building tools infrastructure and services that help web3 developers move faster develop in a more sustainable way and yeah just keep your peace of mind so when we talk about the tools for the five years that we've been in the web 3 uh Arena we built a visual debugger which gives you a call by call way to go through your transactions and figure out why they failed a gas profiler that allows you to see how much gas your contracts use so you can optimize them and the third thing is the simulation UI that allows that gives you like an IDE like experience when debugging your contracts when optimizing gas when figuring out how can you do better transactions the next thing that we are focusing on is infrastructure and in that Arena we've developed two technologies called devnets and forks which are pretty much managed Forks of 30-ish networks that we're supporting in tenderly so that means that you don't have to spin up a fork on your local machine you can spin it up on our infrastructure and it's available through through the cloud to yourself and your team and the last bit of infrastructure is the web 3 Gateway which is node as a service that comes along and fills makes this picture complete now when it comes to Services okay we have our tooling we have our infrastructure but there are other things that we also need to do and that's on the for the beginning an API that allows you to simulate transactions from your uh daps from your uh uis but also from your backends the second thing is alerting so you need to be very much aware what's happening to your contracts as they're live and used on the network for example something big and important is going on good or bad and you want to know about it as soon as it's happening and the third bit is where three actions and you can think of what reactions as alerts that do something that react when something happens on chain and this is just a quick rundown of all of the things that that were built and the cool thing is that all of this is available on uh 30-ish networks that that we support and we keep integrating but let's get back to the topic from talking to various teams in the space who are using our technology we well understood the same thing we agreed on that web3 is difficult and the first thing is it's got a very steep learning curve and the second reason why it's difficult it's got a even an even steeper patience curve that means there's a high sense of urgency that we need different tools and better tools but there's so much going on that it's simply very hard to get there so let's back let's unpack what difficult is and one definition could be it's a presence of obstacles that need to be surmounted or puzzles that we need to resolve and obstacles come in very various levels and shapes and sizes and for example team collaboration is not something that's super easy when you're doing web3 CI is sort of not that common and not that easy and not that resolved in this space there's the spur set of tools that you have to use there's very um Troublesome support for for reusing the stuff you're building so these are just some some things that we spotted talking to to different teams and now I would like to ask you to come back to the question what makes wet 3 difficult for you so think about it in terms of just three or four keywords uh why is web3 difficult or hard for you right and now you can see this little QR code and I hope you can see it properly and I would like you to scan it it'll open up a website where you can enter those three keywords let's see what are the feelings what are the things that make web3 development hard and let's take 30 seconds for everybody to wrap their hands heads around the question times [Music] we die [Music] okay so I think the audience has given you you can keep on adding to this and I'll share I'll share this on on Twitter after the presentation is over but we can see that the biggest topics that arise are security testing debugging tooling interoperability gas optimization debug that kind of things and of course there there are other topics that we need to address as a space as well but these are sort of the most prominent ones coming from from this crowd and one thing that I would like to talk to you about first is actually about this word over here interoperability and to get interoperability we need integration so to make things integrate more easily so let me get back to to the PowerPoint okay thank you for participation we'll we'll do another one soon so let's talk about Innovation and integration so we have different protocols we have different projects and usually those projects and protocols want to integrate with each other and the way to to do that well we need to have easier interoperability now to get to interoperability well we need easier Integrations we need components that can be composed in an easier way so the the entire composability of blockchain doesn't remain as hard as it is and to get there we need higher abstractions so we need to take and we need to take simpler operations the lower Primitives and pack them into something that's high on a higher level of abstraction so we can combine them together and one take that we had to this topic is something that we call node extensions so yeah here's the the sense of urgency to get there and uh what we built is node extensions so we've taken the node and this is the symbol for tender list Gateway which is a node as a service thing and the idea was okay how can we make protocols and projects integrate more easily well one sensical place to do that is actually to extend the Json RPC interface it's very simple it's open to extension so why wouldn't we move all the complexity and all the abstraction behind the Json RPC interface now to do that we need to take the node and extend it with some functionality so node extensions and it works in the following ways so on this side we have our ethereum Network EVN compatible network and in front of it talking to a reading from it and writing to it is then release web3 Gateway and it of course offers the regular operations you would see in a Json RPC interface but what we did is that we're allowing you to actually build your own custom Json rpcs that can do things that can move data we can consider that a simple operation and you can bundle it into one higher level uh Json RPC method so you can imagine a UI Builder just using this one Json RPC giving inputs to it and getting results back or you can imagine your back end doing that in a similar way and what this does you don't put the burden of I have to integrate yet another API to your uh the app UI Builder or to somebody working on backend it's simply using the node and it can simply just call this method and get the response back so we're sort of putting extra functionality on the Node instead of having tens of tens of different services that you have to integrate with and now let's see just a little demo so before before I this is a video and I'm gonna play it one cool thing about this is that besides allowing you to create your own node extensions we also have a library and what this means you can take your node extension packet and put it onto a GitHub repo and it becomes available for other projects so this opens the door for other projects to integrate with your system and I guess it's pretty easy to see that yeah there's an activate and deactivate button and we'll just see how it how it how you would create a node extension from scratch oops so I didn't expect this to happen [Music] so the first thing we can notice is that there's a prefix extension so that means it's a custom Json RPC endpoint you're just adding now and we're gonna give it a name and now now what happens is that we need a place to add some code to the extension so by choosing this action drop down you get a little space where you can actually input some JavaScript code and from this we can see that okay there's an event coming into the node extension and there's something that's doing the processing so from the looks of it this node extension is like uh The Bash Echo command it it gets an argument it just spits it out so whatever gets in it goes out and let me play the rest of the video I'm not going to stop it so this created and activated the test extension and you can try it out or you can just call it through the Json RPC interface and this is an example so uh we're typing in uh one two three four five and when we send requests because this is an echo you get the the arguments back so you can imagine doing more complex thing with things within the node extension itself we just built an echo node extension all right so that's one thing but let's come back to the topic of what are the other reasons web3 development is hard well we have to iterate because we can't nail things on the first go we're bug driven we're we're error driven when it comes to development and um there we also need to move fast which is something that doesn't just come out of the box and when we iterate we can think of or we can think of it as we iterate on a daily level so developing contracts developing UI stuff like that but also on a higher level when we're adding different layers to the product adding different facets to the product so when it comes to daily iterations some of the the issues that were present in the word cloud well it's bugs it's gas usage and a difficulty is I I had to choose this one building a UI and building it in a nice way nice to the person building the UI so thinking about the team a little bit and let's go over a bit of these tools so when it comes to debugging and optimizing gas one approach we have is well of course the tenderly debugger it's a visual debugger that's available in the cloud guest profiler and simulation UI and we'll do a very very quick demo of this and what it offers but before that I would just like to reflect on how we approached building this thing way back so before we were able to get the transaction information from the evm the tenderly team actually took a different approach we put a lot of probes into the EDM so when you run a transaction whether it succeeds or fails you get a whole lot of data that you can show to the to a developer so they can understand how the transaction executed where it failed the why it failed and so on the guest profiler simply gives you the exact gas usage thanks to those probes and the simulation UI gives you a chance to verify your bug fixes by not sending a simulation to the network but running it in a virtual environment in a simulated environment and that's why it's so fast and that's why it helps people move move faster so now this is going to be tricky to do a demo like this all right so I'm in the simulator now and here you can see that we can actually adjust all the input parameters which are readable in a pretty humanly readable form but also what we can do is when we're debugging and we've found an issue with the code we can simply go edit source code and wait a bit for the source to load and you can actually modify any piece of this source which I'm not going to do now because this is not a position to do it so when you apply your bug fix you can simply go and simulate the transaction so what it does it replace the entire transaction with adjusted input parameters or with adjusted source code so I'll hit simulate and then this is the time it takes okay so it's not as fast as I hoped it to be this is the time it took it to simulate the whole thing to display the entire call Trace which can be pretty lengthy and this one actually succeeded so that's cool but what else what you also get here is decoded events so you can understand what was emitted the state changes and also the gas profiler which gives you a very in-depth overview of how much gas your transaction used as it executed and you can even pinpoint a suspicious method and jump back into debugger and try to understand how you can optimize this further so this is how how the simulator can give you a chance to fix bugs but another cool thing is when you're preparing a transaction you want to send to a network you can prepare it in the simulator so you can play around with the input parameters and and stuff like that so when it's actually ready you can use this raw input and just send this as a transaction to to the actual Network so you can play around in the simulator as much as you want and when you feel it's ready you can go out and actually send the real thing to the network so that was the hardest demo I ever did because of this this screen and let me get back into the slides so this is one sort of shortcut that you can take to make you move move faster and the second thing that I want to talk about is UI building and you can imagine somebody building a UI and they want to change the UR really rapidly because the the Frameworks we use for the uis allow you to do that but the network is low or they have they struggle setting everything up so the devnets or Forks are here as an as a logical shortcut and what you would do is you would Fork a networking tenderly so that's a network of simulated transactions and just give it to Json RPC to to this person over there so they can make changes really fast they can see transaction outcomes really fast and they don't have to set up anything on their local machine bonus points because whatever they do if a transaction fails they can easily share transactions with the team so you can understand why your smart contracts behave in in an inappropriate way and this is a little demo again a little video of creating a devnet so you would go there create a template from a network and just name that devnet save it and this is your blueprint for all the future instances of the network so you can have this as a starting point and whenever you spawn a network you get a new Json RPC link so you can always come back to the same place in a Network's history and for example add it to your hard head project um so when you uh when you deploy contracts or you interact with them using the hardcore script it all actually happens on the devnet so here we're deploying and interacting a couple of contracts and you can see that these transactions have but instantly and what's the best part is this is visible to your entire team and you can easily jump into debugging and have that collaboration Channel more clear and and more fluent of course you get a like a very private transaction Explorer this is visible to you only with all these beautiful things that that we saw before and you can also see the overview of all the Json RPC calls that were made uh with with this script so that's that's about the devnets now on a wider scale where do we iterate well there's the security aspect and this is a pain point for for many of us there's Automation and there's QA testing so let's talk about security and one we have to approach this problem through different different angles one angle is to do audits lots of them of course but again when your contracts are live you probably want to see when the invariance of the contracts are broken or if somebody is calling some methods that seem fishy and for that purpose you can use alerts to set up a security harness around your smart contracts so you can get notifications as soon as something fishy is going on now for automations the wet reactions are there what reactions listen to whatever's happening to your contracts and they execute a little piece of JavaScript in response to those events so you can pull in some data from the network bundle it together aggregate it make it humanly readable and send that information to somebody in to your community even okay and QA seems pretty pretty uh logical so you would deploy your dab on a fork or on a devnet and people who want to try out your your dab or do some sort of quality testing or security testing well they can go about it and they can drill the app for as long they want and it's fast because there's no network latency when using devnets and we have 10 minutes left in these 10 minutes we would like to invite you to another question let me just hop in here okay so I'd like to invite you what are your best practices problems and solutions so the problems you stumbled upon and the approaches to it whether you actually manage to solve it fully or actually just attempted solving it so let's take a minute or two you can you can keep adding these as we go on but we could also start a live q a so if you have any questions raise your hand a mic will be at your site yeah we have a question [Applause] so I think like one one big practice that a lot of uh contracts don't do is uh after it's deployed the alerting and monitoring uh you know monitoring key uh states of the of the contract and also kind of alerting the developer if you know certain even just basic things like exceptions or you know certain things happen or certain things exceed certain threshold then the developers can catch the issue before the user before it's wide scale and users actually notice it um you know allow users noticing it so like in web 2 they're like services that do that you know that even hook up with uh you know on-call Engineers you know when there are alerts that happen I don't know if it's covering one of your services alerting and monitoring of of uh smart contracts yeah that that that's a great point so um if if I understood correctly you're saying that uh we should actually when we deploy the contracts monitor for everything good and bad that's going on with them yes like like uh metrics about you know like you know if it's people if anything to do with money for example you know like if someone keeps withdrawing you know like you know a certain threshold maybe it's not even even an issue but it's like you know how like Banks if you withdraw too much maybe they they think it's suspicious you know just like alerts that uh the team can then possibly act on yeah definitely I mean in in my view that's responsibility of the development team to figure out what are the suspicious patterns that we should be aware of right right in real time in real time so setting up alerts around those suspicious patterns for example this view function changed value for 15 from the last time or yeah this amount of withdrawal happened uh in the previous window of time or something like that right so setting up alerts around those is possible with tenderly and forwarding them to pagerduty or send yes yeah yeah so there's a way to connect those tools we're familiar with pager Duty and sentry with the world of blockchain if you set up alerts that simply give signals to those tools so your team is very very much aware when something does your uh does your tool I think you have the page on the services do they send to Sentry like does your tool integrate with those those tools yeah so so our alerts can integrate with well I didn't explain this but alerts can send messages to Discord slag blah blah blah and also to Sentry and page of Duty so this can this can create the full sort of experience of monitoring there okay and then you can also uh pass data like those key metrics uh so that I forgot the the you know popular tool for that the name of that but you can have a dashboard of yeah yeah the key metrics there so so I think that at this stage it's just giving signals this happened this happened this happened this happened so the metrics and making sense out of that that's something that's still on the side of the development team but this is a very good example of where we can uh innovate and where we can create more more tools for this is a use case for that I believe thank you for the question cool out of questions yeah um is there a difference between the devnet and uh fall I didn't quite catch the difference sorry the difference between a devnet and a fork is there a difference all right so there is a difference devnet Forks are actually very very simple chains of simulated transactions so an entire simulator Network Fork those are forks and devnets take it a level up so you can think of a devnet as a Docker container as a Docker file for Forks so you can practically set up your CI with the configuration of a devnet and each time you have a build it spins up a new devnet with a fresh new simulated Network that you can use so we made that part easier with that thanks for the question all right can we share the reason yeah let's let's see the results study hard Albert handsome boy devops integrate Foundry testing coverage reports better get Branch design that makes sure we move fast but got enough preview from Security Experts before merging into other works work streams so this is a very much the the development process plus the