# Missing Links in the Ethereum Stack

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2018-10-07
- Duration: 22:19
- Watch: https://streameth.org/watch/yt-VhR9OOzWGks
- YouTube: https://www.youtube.com/watch?v=VhR9OOzWGks

## Description

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/3/missing-links-in-the-ethereum-stack

Observations about what developer tools missing from the Ethereum stack, yet currently available to traditional web developers.

Speaker(s): Jack Peterson
Skill level: Intermediate
Track: Developer Infrastructure


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 3 was held in Cancún, Mexico on Nov 1 - 4, 2017
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

[Music] hello everyone my name is Jack Peterson I'm the lead developer of auger but I'm actually not really going to be talking about auger today instead I'm gonna be talking about the sort of the general state of tooling in etherium zico system and point out some things that I think could use some improvement you know auger has been in development at this point for almost three years and that that's a so long as a long development cycle it's certainly longer than any of the team who were you know came from backgrounds of web development application development scientific development expected based on their past experiences and I think one of the reasons for this is that we all came from environments where you know that had been established for a while and in an established development environment there are certain tools that you just sort of take for granted as being available whereas in a very young ecosystem like youth areum's they might not be it's over the past I don't know six months I've spent a fair amount of time talking to DAP developers on different projects about whether they you know what their thoughts are on the tooling in the ecosystem and whether or not they are ahead of schedule or behind schedule well I guess you're a lot of you are deaf developers yourselves so I don't have to tell you this but the most common answer was definitely Wow everything is taking a lot longer than we expected and I think the reason for that is basically just that there's a there's a lack of good consistent tooling in this space you know I think of tooling as being so important because it's a force multiplier right if I have an ecosystem of thousand developers and those thousand developers don't have I don't know a debugger all right and then you sit down you write one you give it to them that makes every one of them more efficient right so it has a multiplicative not an additive effect and I think that the main thing that we need in this ecosystem is just is just better tools I think it's worth taking a step back in and examining well why might there not be good tooling in this space and now part of it is just that this is a young space all right so you wouldn't expect it to have you know the maturity of desktop application development tools for example but I also think that there is sort of a structural problem in that there's currently a lack of incentives to build good tools right there's the allure of the doing the token sale right and the thing is having done a token sale after you do a token sale you are committed to delivering on a particular application right so you move at breakneck speed towards MVP for your application and I think that a lot of the best minds in this space are doing exactly that and I think that if you stop and think about how tooling does have a multiplicative effect that we are all ironically actually moving slower than if we stopped and took a deep breath and all communicated really well with each other about what tools we could share between different projects and so to try and address the issue of lack of incentives I'd like to propose sort of a call to arms if you will I think that DAP teams especially those of us that have done token sales and we have some resources and we have a dire need for better tools I think we should create bounties for the tooling that we need or we could just commission the tools but bounties and prizes are sort of more fun so I'm gonna go with that okay so I had I have had a bunch of long conversations with my smart contract with augur smart contract development team sort of what what is their wish list as far as tooling that could be improved and it's mostly not things that are well X is just completely missing from this ecosystem rather it's you know something that exists but maybe doesn't work as well as we would like it to or it just doesn't work quite as we would like it to so this is this is my wish list sort of trimmed down the suggestions that I got for my engineers and this seemed to be the consensus list and I'm gonna go through each one of these in some detail and I guess there's there's two things that I would like people to take away from this first is that if you are Andy theorem developer which I know I know many of you are then please chip in this is you know this is me saying that augur could really use your help and I guess in the spirit in the spirit of auger putting putting our money where our mouth is and if you are a you know if you're adapt development team and by which list doesn't match yours and I mean it probably doesn't right everybody's not gonna have the exact same needs then I would say you should create your own bounties or Commission your own tools and I'll tell you what if you don't if you don't want to go through the hassle of you know let people know that you're you you're doing a bounty and you want to just make it available you can put it on augers website we're gonna have all Garnett slash bounties is where it's gonna be listed you know just send me an email jacket auger dotnet and I'm happy to put up third-party bounties as well as the ones we want so now let me let me go through my particular wishlist in detail well 10 minutes Wow anyways so feedback I got from our smart contract development team as well as a number of other people in the space is that the number one thing that's really missing is a debugger like a good debugger the kinds that we knew in our past lives as other other sorts of application developers you know there's there's all kinds of well there's a roomful developers right so tell me if this if any of you have been through this sort of debugging cycle where you are trying to execute a sent transaction and it fails for what you've a bug in your code you ran out of gas whatever transaction failed but you don't actually know anything other than that your transaction failed right you can't if you have you tried to omit some logs as part of your transaction well they didn't get emitted because your transaction failed you can't just set a breakpoint in your solidity code and then drop into the environment and look at the variables because well you don't have a property bugger and so what you end up doing is you comment out chunks of code you recompile you run your test again and see if it passes you do that over and over again until you get you get a transaction not failing this makes writing contract code take forever if this is your development cycle now there's various things that we do in house to make this not literally our development cycle it's not it's not quite quite this raw but this is sort of the this is sort of the naive cycle now a lot of you're probably thinking well there is a debugger out there right remix and remix is cool but it's also it's a full browser-based IDE and it's so one it's it's awkward for large projects to use it's awkward to load lots of contracts into it get all the relative paths and stuff to resolve correctly but the big I think the bigger issue with it by far is that you can't really integrate it with other tools or at least I don't know how to do it and by smart contract dev team doesn't know how to do it for example like augur has a pretty extensive test suite as you might imagine we have including libraries and stuff we have 75 or 76 smart contracts make up augur in total and so we have a lot of tests associated with that we have unit tests written using pi theorem tester and we have integration tests which are written using well they're written in JavaScript using the eath KS library I think the author of that library is actually talking right after me and I mean what what the cycle we would really want is to be able to say set a breakpoint in solidity and then run our test suite right that that's basically what we're developing against and you know have it break and then drop us into a context where we can see what went wrong when something goes wrong and as far as I can tell there's not there's not really a way to do this with remix because it's it's it's a it's a full solution it's a standalone web application and so remix is cool but it would be so much cooler if it was a library and so this is the first bounty I want to propose what I want what I want I should say what my team wants is a portable debugger and they want this more than anything else and the the most important requirement is that it must be a library slash module so that it can be integrated with our existing tooling that means integrated with our existing IDs all right like for example if you use a vs code you want the debugger to be integrated with vs code you want it to be integrated with your existing test suite with your existing build system with your existing deploy system and this probably is obvious but the key feature is breakpoints they're one of those things that you do not realize how much you miss breakpoints until you're in a development environment where you don't have great points and so we're gonna put up details for this bounty and the others I'm proposing at augur dotnet slash bounties there's just a placeholder page there now the details will be available sometime over the next few days and so if once we have that up and you can look at proper specs for this thing if you build it you get 2,000 rep that's the first bounty this is the second point and this is that this may be a look this is a little controversial very often I find when I bring this up especially among younger developers I'm met with something less than a chorus of agreement but nevertheless I think it's an important point especially for code written in a smart contract environment which is very unforgiving and where if you you can't reasonably expect to launch with bugs and recover so I one thing I think it makes sense to do is step back and say like what other software is written in environments like this and and good examples are things that are called safety critical software right so these are things like the software that monitors nuclear reactors the software like the firmware insighting anti-lock brake controllers pacemaker firmware stuff like that the stuff that if it fails the consequences are catastrophic you know your brakes fail there's a nuclear meltdown right so no but people do write software in these environments right and in many cases they write software and it works consistently for 30 years and if you look at if you compare that to that sort of move fast and break things mentality of modern web development Mille to write stuff that's that reliable right you're gonna write something and not only is it not gonna have bugs it's gonna it's gonna work bug free for 30 years in an environment where if it fails there will be a nuclear meltdown it's a pretty reliable code and it's so I think it's really worth asking how do people actually write code for environments like that well so my co-founder Joey spent a bunch of time over the past year really searching this he looked up the standards that are used to write code in these kinds of environments and there's actually several of them misra is the one used as a C coding standard used by the automotive industry NASA and JPL Jet Propulsion Laboratory they have their their own coding standard there's another there's like a restrictive subset of the ADA language called spark that's also used in these kinds of environments and there's a lot of commonalities between these different these different safety critical coding standards one is that they always use a restricted subset of a language I mean you take some mysteries of C coding standard now sees a pretty small language to begin with it's not like well it's not like say C++ which is just all kinds of features this is a fairly small language but mr. C is actually a subset of C and it's a subset it has fewer features it's designed to be less abstract and it's designed to just be safer by sort of just being simpler and really if you could encapsulate the the goal is just catch as many bugs as you can with static analysis so bounty number two is what I'm calling super simple solidity so this is sort of like mr. Mishra for solidity and I would really like to see a basically just a pragma for a solidity and this would just be a safe simple very restricted subset of solidity so here are some examples right and this may seem absurdly restrictive depending on what kind of programming you're used to but these these restrictions are the kinds of things that you find in the mistress standard for example no inheritance no recursion no implicit types right no var no function overloading and we've got a whole I'm not gonna list them all here but we have a whole list of things that we would like to see excluded from this sort of very simple solidity subset and so if you create this pragma you get one thousand two hundred fifty rep I need to move this along cuz it looks like I'm running out of time okay so to go through the rest of this quickly the anybody ever seen this exception exception stack to deep solidity has this has a quirk where local variables and parameters they go on the stack and the stack can only be a certain depth sort of depending what's on it so we have between 8 and 16 variables something like that one kind of one one thing that's a little awkward about it is anytime you allocate a new variable in solidity it puts a very puts it on the stack but there there's an actually way to pop it off the stack at least not without was not without digging down into assembly serpent which I missed terribly sermon had both stack and memory variables and you could pop variables off the stack if you needed which seems like a pretty reasonable system to me right nothing on the stack uses the whiff keyword to put something on the stack and then when you axe it there's nothing on the stack again so body number three is a stack popper feature four solidity I so this is just a way of removing local variables from the stack without digging down into assembly doesn't act doesn't even have to work for function parameters just talking about local variables here yeah you can sort of accomplish the same thing with function calls but it would also be really nice to be able to clear off the stack the solidity devs themselves claim this christian alex so you guys in here or really anyone but it's open anyone who wants to submit a PR as long as your PRI is accepted you get a thousand wrap currently there's actually not a way to get return values if you do a send transaction to any theory of node which actually surprises a lot of people at first but if you do a send transaction you actually just get back a transaction hash you do not get back and at the actual return value and in fact that return value is not accessible anywhere at all now if your return value isn't it doesn't have any dependence on State if it's just based on the input data then you can rerun the same input data as a call and that will give you the return value okay but if you on the timestamp then there's actually no way to get it now it's computable by the caller using commands - nice library but this is somewhat heavyweight it's inconvenient I think the etherium I think it'd be really great if the etherium notes just would provide the return value and so this is the fourth and final bounty I want to propose is it's a lot of text isn't it it's just that I would like any theory imply any of the theorem playing guess parity to supply users with a return value and you can do this using really any mechanism you like there was an EIP recently that's proposed putting it in transaction receipts for various reasons that didn't go through but there's other ways of doing it that I think would work perfectly well you don't have to store anything you could just make it available via a subscription you know so when the transaction is sealed the then the theorem node uses its existing pub/sub system to send out a push notification to the client saying hey here's the return value but really can be implemented any way you want it's claimable by either the theory of no development teams over again by third party submitting a PR okay and the bounty all the bounty of utils will be posted over the next few days at augur net slash bounties [Music]