 Hello, everyone. My name is Jack Peterson. I'm the lead developer of Augur. But I'm actually not really going to be talking about Augur today. Instead, I'm going to be talking about the general state of tooling in Ethereum's ecosystem and point out some things that I think could use some improvement. Augur has been in development at this point for almost three years. And that's a long development cycle. It's certainly longer than any of the team who came from backgrounds of web development, application development, scientific development, expected based on their best experiences. And I think one of the reasons for this is that we all came from environments 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 Ethereum's, they might not be. Excuse me. It's over to the past, I don't know, six months. I've spent a fair amount of time talking to DAP developers on different projects about what their thoughts are on the tooling in the ecosystem and whether or not they are ahead of schedule or behind schedule. And well, I guess a lot of you are DAP developers 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 lack of good consistent tooling in this space. I think of tooling as being so important because it's a force multiplier. If I have an ecosystem of 1,000 developers and those 1,000 developers don't have a debugger. And then you sit down, you write one, you give it to them. That makes every one of them more efficient. So it has a multiplicative, not an additive effect. And I think that the main thing that we need in this ecosystem is just better tools. And I think it's worth taking a step back in examining why might there not be good tooling in this space? Now, part of it is just that this is a young space. So you wouldn't expect it to have the maturity of desktop application development tools, for example. But I also think that there is a structural problem in that there is currently a lack of incentives to build good tools. There's a lure of doing the token sale. And the thing is having done a token sale, after you do a token sale, you are committed to delivering on a particular application. 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 going to go with that. OK, so I have had a bunch of long conversations with my smart contract, with August smart contract development team, sort of 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 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 my wish list, sort of trimmed down the suggestions that I got from my engineers, and this seemed to be the consensus list. And I'm going to go through each one of these in some detail. And I guess there's two things that I would like people to take away from this. First is that if you are an Ethereum developer, which I know many of you are, then please chip in. This is me saying that auger could really use your help. And I guess in the spirit of auger, putting our money where our mouth is. And if you are a, if you're a dapped development team, and my wish list doesn't match yours, and I mean, it probably doesn't, right? Everybody's not going to 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 want to go through the hassle of letting people know that you're doing a bounty, and you want to just make it available, you can put it on auger's website. We're going to have auger.net slash bounties is where this is going to be listed. Just send me an email, jack at auger.net. 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 wish list in detail. Well, as much detail as 10 minutes will allow anyways. So feedback I got from our smart contract development team, as well as a number of other people in this 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 sorts of application developers. You know, there's all kinds of, well, they're just your room full 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 send transaction and it fails for where 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've tried to emit 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 proper debugger. 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 you get the 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 quite this raw, but this is sort of the naive cycle. Now, a lot of you are probably thinking, well, there is a debugger out there, right? Remix. And remix is cool. But it's also a full browser-based IDE. So one, 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 I think the bigger issue with it by far is that you can't really integrate it with other tooling. Or at least, I don't know how to do it. And my 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 PyEthereum tester. And we have integration tests, which are written using, well, they're written in JavaScript using the ETHJS library. I think the author of that library is actually talking right after me. And, I mean, what the cycle we would really want is to be able to, say, set a break point in Solidity and then run our test suite, right? 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 really a way to do this with Remix because it's a full solution, right? 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, I should say, what my team wants is a portable debugger and they want this more than anything else. And 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 IDEs, 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. This probably is obvious, but the key feature is breakpoints. 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 breakpoints. And so we're gonna put up details for this bounty and the others I'm proposing at auger.net 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 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 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 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 inside anti-lock brake controllers. Pacemaker firmware. Stuff like that. Stuff that if it fails, the consequences are catastrophic. You know, your brakes fail. There's a nuclear meltdown, right? 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 compare that to the sort of move fast and break things mentality of modern web development, it's almost unthinkable 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 work bug free for 30 years in an environment where if it fails, there will be a nuclear meltdown. That's a pretty reliable code. And 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 researching 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 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 safety critical coding standards. One is that they always use a restricted subset of a language, right? I mean, you take, so MISRA is a C coding standard. Now, C is a pretty small language to begin with. It's not like, well it's not like C++ which is just all kinds of features. So C is a fairly small language but MISRA 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 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 MISRA for solidity. And I would really like to see basically just a pragma for 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 restrictions are the kinds of things that you find in the MISRA standard. For example, no inheritance, no recursion, no implicit types, right? No var, no function overloading. Anyway, 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 1,250 rep. I need to move this along because it looks like I'm running out of time. Okay, so to go through the rest of this quickly, anybody ever seen this exception? Exception stack too deep. Solidity 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 on what's on it. So you have between eight and 16 variables, something like that. One thing that's a little awkward about it is anytime you allocate a new variable in solidity, it puts it on the stack but there's an extra way to pop it off the stack, at least not without digging down into assembly. Serpent, which I miss terribly, Serpent 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, use the with keyword to put something on the stack and then when you exit there's nothing on the stack again. So bounty number three is a stack popper feature for solidity. So this is just a way of removing local variables from the stack without digging down into assembly. 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, are you guys in here? Or really anyone, but it's open to anyone who wants to submit a PR, as long as your PR 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 Ethereum 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 the actual return value. And in fact, that return value is not accessible anywhere at all. Now, if your return value 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 it is state dependent, maybe it depends on the block number, maybe it depends on the timestamp, then there's actually no way to get it. Now, it's computable by the caller using Kumaebus' nice library, but this is somewhat heavyweight, it's inconvenient. I think the Ethereum, I think it'd be really great if the Ethereum nodes just would provide the return value. And so this is the fourth and final bounty I want to propose is, I guess that's a lot of text, isn't it? It's just that I would like any Ethereum client, any of the Ethereum client, geth, parity, you name it, 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. So when the transaction is sealed, the Ethereum node uses its existing pub subsystem 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 Ethereum node development teams or again by third party submitting a PR. Okay, and all the bounty details will be posted over the next few days at auger.net slash bounties. And that's it.