[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]