Hardhat's Present and Future

[Music] [Applause] [Music] and with that we are ready for our next talk and up next is patricio and patricia is going to be talking about hardhat's present and future super excited to see what he has to share and announce there welcome hey thanks kartik for the introduction so let me just set this up [Music] okay can you see my screen yep right okay thanks everyone to be somewhere watching at this presentation so i'm patricio co-founder and cto of nomiklavs and you probably know us from our product our development tool called hard hat in this presentation i'm gonna talk about how hardcode works internally and its future so first a quick recap of about what harcard is hakka is an ethereum development environment which is composed by two major components one is hard hat runner and the other one is hardhat network carcade runner is a task runner that lets you automate all the common tasks that you have to do while developing ethereum applications there are similar tools to hardhat runner in every development ecosystem or platform for example webpack and parcel are some of the most common ones when doing web development or gradle when doing android development and actually her hardware has been heavily inspired by this by default her hat runner comes with a set of predefined tasks that they do things like compiling your contracts testing them deploying them things like that but there's also a rich ecosystem of plugins that let you integrate other tools add features or new tasks to hardhat runner or customize the existing ones harcan network is our development ethereum network and what this means is that it simulates an ethereum network just like maine robstern or koban where it's totally local uh instead of having many nodes communicating with each other you can think of kafka network as a single node ephemeral ethereum network when you run hard hat card runner just like running your tests a new instance of hardhat network gets initialized your your smart contacts are run within hardhat network and then after your test passed or failed this instance of hardhat network gets destroyed and in this presentation we are going to focus on how hard a network works the challenges of building and maintaining it and how it's going to evolve in the future so first how does carhartt network work happen network is a node.js module that it's embedded into hardhat runner and exposes the same json rpc interface that a real ethereum network ethereum node does this means that we kind of lie to the different libraries and applications that integrate with hardhat network and pretend to be a real node but instead instead do everything locally within ocs so for example when you connect metamask or other wallet to hardhat network it doesn't need to know that it's dealing with hardhat instead it just acts as a feed where working with ethereum magnet the same happens with web3 or ethers or any other library or application this gave us the advantage of being able to integrate with everything quite easily so instead of communicating things to a network network it resolves everything locally and what this means is that if you send a transaction we don't forward it to a network of different nodes but just create a local block in our own blockchain and keep it for us we don't forward those blocks either not communicate with anyone else and to do this we use ethereum sbm which is a typescript evm implementation and it lets us execute everything locally but what made haka network different or special is not being able to simulate a network but rather that we always look or try to provide as much context and information about what's going on with your smart contracts because that's what let's uh let the sorry let developers debug and test their smart contracts and be more effective on building them and this is where automation challenges appear and the way this works is by relying on random observation and this is because in ethereum as we all know you have to pay for gas when you try to execute something and in particular the person paying for that gas is the final user so keeping the amount of gas that you pay to a minimum is super important because it makes your application more or less competitive and this leads to many things but in particular one of them is solsie association generating a minimal amount of buy code but when compiling your smart contracts instead of embedding functionality to help you debug your smart contracts for head tools do that it has to output a very minimal uh by code without any kind of random support so that the amount of gas that the final users are gonna pay when running that smart contacts is slower so things like for example generating stack phrases are not part of the program but rather left to the tooling in contrast in other in other development platforms this will be embedded within the actual binary which makes things easier because the compiler has the whole controller information to be able to do this effectively but the way we approach this is instead by as i mentioned random observation but what does that mean it means that when we execute anything within hardhat network we trace this execution and by tracing here i mean collecting information or the history of what went what went through when executing the contract at the ibm and this trace you can think of it as a sequence of ebmo codes or operations that have been run during the execution of a given smart contract and while this is very useful at that level uh it isn't very approachable because you have to be very deep into the avm to be able to understand that understand things at that level but instead what we do is take that evm and very low level representation of the execution of your contract and try to recreate more friendly information for the user for example this is how we implement console.log when we take a trace of the evm we recognize certain patterns that mean that someone tried to call to the console.log library library of function and when we do when we detect that we decode the calls arguments and bring them to the console or to the terminal of the user and this is in general the approach that you have to take if you are willing to build a advanced tooling for ethereum another thing that we do is generating stack prices and in this case it's it's similar like we take the trace anybody and trace but also fetch the compilers output that has a lot of information about your contract and combine those to recreate a call stack in solidity which means that we know when a function was called or or a return from a function was executed uh but this is not always complete or perfect because there are certain ways that a contact can fail or certain paths of execution which are not actually reflected or come from your code but rather from internal solidity functionality or auto generated code and that information is not very useful for the final user or developer and this is this is particularly true for all the versions of solidity so what we do is relying on a set of heuristics that we read through time to improve this information and give richer things to the user like how to generate their own messages when you send for example when you send a transaction to a contract and the function that we are trying to invoke doesn't exist in that contract we can detect that and clear and give a clear error message explaining what it did while depending on the version of solidity and your settings without this set the set of heuristics all you would have got is a a reward without reasonable message and this is in fact a ton of work with and has some limitations that i'm gonna explore next uh the first one is that relational heuristics is extremely fragile they are built super ad hoc for every version of solidity in fact the way that we build them is by looking at hundreds of vbn traces and and after some time you start recognizing to recognize patterns between them and then encoding those patterns within harca network so we can kind of translate our intuitive like pattern matching that we do when looking at the civilian traces and encode it as javascript code within hardhat network but the problem is that as they are super ad hoc they are flashing because whenever a new version of solidity comes out they can break because maybe solidity change something that broke our pattern it doesn't repeat anymore and the change may make sense it's not their responsibility for our heuristics to be stable through time but the problem with that is that nothing guarantees us that we will be able to fix them or that we will be able to create new ones if we need them for a particular feature and our problem with them is that they are not always accurate because these are heuristics and for the ones in the audience that don't know what that means it's you can think of them as fussy matching things in this context at least they are like pattern recognition logic but not very precise and the way the reason that they are not very precise is because they can't be too precise or we are going to have a lot of false negatives and they can't be to lose because otherwise we are going to have voice positives but we'll never be able to be 100 accurate because the compiler doesn't give us the precise information to do that another problem with this approach is that the tooling that does this is always getting more and more complex the reason for this is that solidity versions tend to stick forever within the ecosystem let's suppose that you build the contact now you probably are gonna use led084085 something along those lines and tomorrow's zero point and you finish your contact you deploy it and tomorrow 0.9 comes out and has some cool features that let us tool developers improve your development experience the chances of you rebuilding i mean porting rebuilding and redeploying your contact just to get very tooling are very low because that's gonna cost a lot of money at least for audits and also it's gonna take a huge coordination effort and the advantages for you may be huge uh it's not a it's not great for the community they won't get a lot of advantages so that's not gonna happen but even if you are building with the latest version of solidity chances are that you are interacting with a contract that was deployed using another version of solidity and you still want to understand what what and why things go wrong while you are testing your context or dividing them so that means that we still need to support every version of solidity probably forever another disadvantage is that creating these tools is very expensive and complex and this leads to two things the first one is that there are fewer tools than maybe there would be if these were cheaper and the other disadvantage is that you get very inconsistent features across the different tools for example if you want to use console.

log today there's only a few tools that support it like hard hat if you want to step the barrier there is just a few that have it that have them if you want to use a good integrated fashion system there is just a few of them and the problem with this is not that we want to have every feature that everyone has but that these are very basic features that in other development development platforms are given and they should be a given for every tool in ethereum but they are not and that's something that we we are aiming to improve instead i think tooling should be different tools should be differentiating themselves with more specific functionality instead of the basics and the way that we are planning to tackle these problems is with two new projects that for now we call slang and resnet slang is a new validity compiler that is gonna be built especially for tooling and resnet is a library that provides a development network with all this rich functionality that hard hard has so as i just mentioned refnet is going to be a library for other tools to build on top resting won't be a replacement for hardhat network within hardhat but instead it's gonna be its new core and the interface of hardcore network will still be the same it's being built as a platform as a runtime observation engine that will let khaka network be more stable faster and mature but also we let other tools get the same functionality for free it's written in rust so it can be run everywhere and distribute as a just as a normal library like a c library and also it's going to be compilable to wasm so that it can be used in a browser and things like premix or ethereum studio can get all these features for free it's gonna provide all the functionality that carter network has out of the box and instead of relying in heuristics it's gonna depend on slang's output to have an accurate understanding of solidity of what's going on everywhere so we are gonna be able to be precise on all the things that we do but we'll also be able to do more stuff because we are going to be we are going to have the information to do those things and once the the basic functionality is mature and we have the common base uh for a development network we are going to work on more advanced tools the more advanced features that kafka network doesn't provide today like a step debugger a gas profiler called coverage analysis and more slang slang is a solidity compiler as i mentioned that it's gonna be focused on developer tools this means that we won't be competing with soul c but instead we will be focusing duri on development time of your smart contacts but but but like orienting the compiler to be able to integrate with other tools and provide all the information that those needs but building a compiler is a huge challenge and we think that so c does a good job on building a compiler it's good to for running your smart contacts on mainnet and we pretend to keep using it for that so hard hat and other tools that want to use slang will build both with slang and suit c and use each of those bits for different things and the of course deploying with the soul c build slang is also going to have an integrated language server which is a service that lets text editors and ides integrate with the compiler to gather like features that advanced editors have uh to support the language for free things like shampoo definition refactors chant references things like that kind of require a compiler to be built or at least part of the compiler and we think that having them integrated within the compiler is a way to have them to build them reliably and keeping them up to date with the evolution of the language so we are also providing that out of the box it's also going to have apis for different tools to be built and built on top like exposing the parser or the type check system and those things are going to allow things like reliable fast and up-to-date linters formatters and other things and one of the key things of slang as i mentioned is that it's going to generate all the metadata that rest net requires not only to be able to avoid relying on heuristics but also to [Music] let us iterate breast net faster so if we want to do anything that is not possible with breast net we can just tweak slang a bit and generate more metadata and the the good thing here is that as we are not going to be deploying this smartcon these bytecodes generated by compiler compiling these smart contracts we can tweak what we generate so that we can enable everything we want within resnet but maybe some of you are wondering on how reliable are things gonna be if we compile with one compiler during development and with another one when deploying and that would be a great question because if we use different compilers for these themes this wouldn't be as reliable as just using cc but one of the cool things about ethereum is that it's a completely deterministic and isolated uh platform or execution environment that lets us do pretty cool things if you have two bits of the same smart contact but that were built with different compilers but both of them do did a good job like translating solidity to ibm by code this should execute and give the same results there is of course going to be small differences in gas costs and stuff like that but in general the modifications to the ethereum state should be the same i if i execute a new c20 transfer built in a smart contact build with slang or build with soil c the end result should be the same so we are going to take advantage of this and build breadth net in a way that can execute both versions of a smart contact at the same time so instead of relying just on slang during development we are going to be building with both and executing with both slang and sulci we are going to trace both of them compare the results and use slang to gather rich metadata of the execution and so c to commit the changes that that smart contact execution made to the ethereum state and in general this should work great and let us have the best of those of both world wars reliable test results because they are the results that the salty version of the contour generated and that's going to be the same ones that this contact would generate a magnet and at the same time we are also going to have as much metadata about the execution as we need and [Music] in the there's of course a chance that these results don't match and this would probably be because sandbag or immature aspect of slang but that wouldn't be terrible either because at worst what would happen is that the development experience would degrade a bit on a certain transaction or smart contract but we'll still be able to we rely on our test results so we won't be compromising on correctness or security of our smart contracts so the current status of these projects uh is different for each of them rested is already under developing it's being built from the inside out of carca network like we are going to replace one module at the time and ship them as part of haracan network probably we ship both at the same time initially and do something similar to what i already mentioned of executing two things either side and comparing results to ensure the correctness of resnet before shipping it to production and slang is not being developed yet we are building a team of compiler experts and doing some research and planning around it but both should ship within the next year and we'll be shipped initially as part of carcad and i stay mature they will be exported as libraries and independent tools for other libraries and tools to to be able to rely on them and get less functionality for free and finally our goal here for both for rent health rest net and slang is for them to become the building blocks of the dueling of ethereum like oil the major tooling and the like our objective is to form to lower the cost that i mentioned of building new tools and maintaining the existing ones so that this leads to new and more mature tools for ethereum ecosystem for the hearing ecosystem and eventually for all of its users some protocols are built on top of it and finally if anything of this looks interesting to you we are hiding both for rednet and slang also for hard hat and other projects that i didn't mention here so feel free to go to this link nomiglabs dot io slash kyrie and take a look at our shop listings there and if you have any questions you can join our discord which is in our website harcat.org and that's all awesome um patricia was a creator of you and uh i mean that's such a massive overtaking that you're gonna go into over the next few years um you talk to a lot of this is still in the works and especially for bristling um my only kind of question is how do you think about that um especially when absolutely itself is also evolving in parallel um what are some kind of things that you are thinking uh that should be kept in mind and how do you kind of match the direction and the speed of the vvm ecosystem evolving yes i think that's that's a good question especially about solidity still evolving i think that that's like a common fact for every language as that it's gonna be it's gonna evolve fast and tools are gonna struggle to keep up with it and we are always struggling to keep up with it and these projects were made massive are gonna make keeping up with it much easier for us and other tools but also as the ecosystem matures and gets bigger and has more tools and more stakeholders depending on solidity i guess the natural progression is for the evolution of the language to split apart from the evolution of the compiler and have some kind of governance over the language but that's still to be defined in the future absolutely um obviously finding this out in real time with everybody else is the challenge yeah yeah anybody to know what would uh this look like but uh this is great um i think you already talked about how people can get involved so check out heartache.org and if you're interested in being part of this future um so thanks again patricia this is great i wish you all the best i can't wait to use flying in [Music] [Applause] [Music]