hello I'm Danny Ryan I work with the
etherion foundation on the research team
work on research specifications
education communication etc a lot of
coordination these days I'm here to talk
to you about aetherium and open source
and getting involved maybe deeper with
the community if you feel any way like I
do at the end of Def Con you're super
inspired your super enriched and excited
about the future that aetherium holds
and you know sometimes we need some help
to figure out how to channel that that
energy so before I talk about that this
is a blank slide because I'm going to
talk about me I don't need to put bullet
points about myself I just want to kind
of ground this and in a little bit of
personal story I've been a firm believer
in open source for many years believer
in the sense that this is open source is
going to drive the future that I want to
be a part of the future in which we
control our destinies the future in
which we can enable ourselves to live
live in the reality that we seek but and
this is this is something that I'm
somewhat ashamed of and and at the same
time proud of at this time before the
beginning of 2017 made pretty much zero
contribution to open source although
I've held these firm beliefs for a long
time I just I never found my avenue and
I never felt the drive to finally make
that poor request and and really get
involved with a project and I'm ashamed
because I knew that it's something that
I should have been a part of but I'm
proud of it and I'm not proud of it
necessarily for myself I'm proud of it
for the community at this point year and
a half two years later I'm working on
incredibly awesome work I'm working on
like high value deep infrastructure for
this community
and and it's not because of anything I
did its up that I stepped up and try to
do it it's more about the ecosystem it
says how one how early the ecosystem is
and how there is so much to do but also
about the project maintainer z' and the
people in this community and how open
they are to really anyone knocking on
the door and saying let me help and so I
just wanted to ground you in that and
that there is so much opportunity to get
involved and getting involved is a good
thing in terms of for yourself getting
involved in this community is enriching
and helping you get to where you're
going so back to the talk not about me
by the end of Def Con you should have
this feeling of that I do at least
aetherium is the future or at least the
future that I want to live in and the
future that I want to be a part of in
the future that I want to build and but
at the end of the end of Def Con you may
be asking so when when are we going to
get to this future and how are we gonna
get there and maybe most importantly you
might be asking what what can I do the
answer is simple contribute to open
source and this is an interesting
concept in the etherium community
because and in the etherium stack
because most of what you're going to be
doing even if it isn't building core
infrastructure and building public
resources is open source you're building
like open source contracts open sourced
apps that people can interact with and
know the bounds and rules in which the
games they play but I mean when I say
contribute to open source
I mean contributing to public goods
contributing to things that don't just
help you and your end user thing that
you're building but contributing to
things that build out the core
infrastructure and enable not just you
to succeed but enable the entire
community to succeed before we dig
deeper into that I just want to talk
about this ecosystem is created by a
number of diverse teams diverse projects
of all shapes sizes colors it's
and before you begin to get involved
with any any project I want you to think
about etiquette before you show up on
somebody's doorstep to begin contribute
contributing take a look at their
repository take a look at how they how
they do things how do they communicate
how are they structuring issues how are
they
formatting pull requests what what sort
of syntax and structure do they
generally write code you want if you
want to come in and make changes and
make a positive impact on an existing
project take the time to make somebody's
job easier and better than making it
harder and takes a little bit of
etiquette and just a little bit of
thought and a little it goes goes a long
way so I want to give you kind of the
lay of the land with the etherium
ecosystem and maybe some good ways to
get involved with the the various layers
and one way to think about it is maybe
an onion in the center we have research
and specifications and clients and web 3
and and it's it is like that but it's
also kind of like this it's a little
messy sometimes it's hard to see the
where the where the lines are drawn
people work on different portions of the
stack and it's one big delicious mess
and I hope to help parse it apart a
little bit and give you some avenues to
get involved so the innermost layer I
would call research and specifications
so this is kind of from an outsider's
perspective sometimes it's the most
opaque it's the most kind of thing that
maybe you wouldn't you wouldn't figure
out how to most easily get involved and
easily contribute and I'd say it's true
that it seems that way but you can
actually really make an impact in this
layer and get more involved with this
layer without too too much work
like with papers read drafts when you're
reading the drafts be an active reader
fix typos find bugs like often there's
like weird references that are just
incorrect a great way to enhance your
understanding and also enhance the
contribution of the community is
create figures enhanced figures and for
all of these super super important
create translations like most of us in
this conference or English speakers but
if we want a theorem to make the impact
that we want on the world then we need
to get this broader than just the
english-speaking community saying with
specifications a similar path III search
check it out follow it follow it read it
follow it contribute when you can all
this kind of stuff you can iterate you
read more you learn more and as you as
you get deeper in you can contribute
more and more blog posts similarly read
them but write them as you were
beginning to take on new concepts
sometimes the stuffs pretty dense and as
you understand it and as you be create
the analogies and frameworks that help
you understand it if if those weren't
out there get them out there and again
create those translations the really the
core here is you need to read you need
to read and then read some more and read
some more and then it begins to make a
little bit more sense another way to get
involved with research and
specifications and this is kind of my
main avenue that got me more and more
involved in the community is create
proof of concepts often researchers post
these radical new cool ideas that have
really solid mathematical and algorithm
foundations but often the community
doesn't really know if and when things
are ready and a great way to vet it is
to create proof of concepts and that
helps you understand it helps the
researchers get a better handle on their
ideas you can iron out bugs and
specifications and honestly if you knock
on some researchers door and say hey
look what I built or hey do you think it
makes sense if we do proof of concept or
hey I see you have a proof of concept
can I make a graphic interface like
they're gonna be so receptive to you
helping out like this is super super
easy
nup not easy it's not the right word a
great Avenue to get more and more
involved the next layer out is probably
the clients which are the
implementations of the protocol they
translate the protocol specifications
into a reality the cool part about this
that there's so full-stack these are
pieces of machinery that touch
everything databases networking
algorithms ui/ux
you name it it's got it and so because
of that there's very likely if you have
any programming experience at all
there's very likely a component of this
stack that you're somewhat familiar with
and so that's a great way there's a
great avenues there and like they come
in all shapes and sizes diversity is a
win there's clients old and new there's
a ton of them and because of that often
one will fit into your realm of maybe
language expertise and so a common path
would be pick go find find a repository
for a client that you're interested in
working on find issues that are relevant
to your domain if you're coming from a
web application stack and you've been
working in databases optimizations maybe
opening up one of these clients and
finding some of the database issues will
give you an avenue to begin to
contribute and from there you can branch
out you can start taking on issues that
are a little bit more outside of that
domain and then Buzz five before you
know it you're a client of this is
actually how you do it go in and start
contributing like there's nothing the
difference between you and a client
developer is that a client developers
doing it the next layer from there we'll
call the web three this is how
developers interact with the core
protocol how developers interact with
the client implementations this really
is the first step that defines our
developer experience and defines the
ease with which people can begin to
interact with this platform and if we
take the time to build clean and
beautiful api's in this layer we're
going to enrich and enable our community
similar to the clients they're written
in all sorts of different languages we
need more this is really if you are
familiar with language X and there is no
web 3 library and language X
that's a great opportunity to get
involved and vegan contribute because
these serve is really the main
onboarding points for entire communities
of developers and for the existing stuff
what you can do you can as you're using
this stuff like it will become clear oh
there's a bug oh there's a missing
feature file bug reports fix them fix
the bugs build out features if you go
look I'm sure web 3 dot whatever has
tons of issues about potential features
that they want to build they're swamped
if there are features in that feature
set that you can help enable and
contribute go and build them increase
testing optimize I don't know I write
optimize these usually don't need to be
optimized too much the next layer out
from there I would probably say is the
developer tooling so all of the things
that help make development more
efficient safe and fun for developers
this in the past year is definitely
growing but if you've begun to develop
on etherium you know that there's so
much to do we could use more
domain-specific libraries that build on
top of web 3 maybe some gaming libraries
maybe some gam all sorts of stuff
debuggers I think we're in great need of
debuggers of those both of our
contracting languages and also debuggers
of the EVM and clients themselves IDs
testing framework there's so much to do
in this layer and if you begin to
develop in the application layer it's
going to become immediately obvious the
big thing this is kind of the path as an
application developer notice the pain
points don't just complain about it
don't just say to your buddy like oh
this sucks man like notice them take
note of them and fix them like if there
is something missing from the developer
experience create it enable it give it
to the community share it with the world
and beyond there are tons of layers and
layers become a little bit more blurry
and they begin to interact with the user
layer but testing layer 2 infrastructure
layer 2 frameworks
take notes on public calls there are
things that you can do even if you're
not a developer to help enable this
community from that open source ethos
local meetups political advocacy testing
documentation testing documentation if I
didn't mention it before testing and
documentation are seriously lacking in
this ecosystem and it is a great way to
begin to contribute to begin to meet the
developer community and to begin to get
involved to make a make an impact man
I'm just blowing through this so this is
the empty slide next phase of this talk
is I have some concrete calls to action
for three different groups the project
maintainer x' we can all do better we
can all enable our contributors more we
can all take that extra time to enable
people to come in and contribute and by
doing that we can go from that guy being
alone to this you know bunch with
shovels building the whole thing lead by
example make even if it's even if it's
silly stuff that like your buddy is
someone you work really close with is
going to be reviewing and you have a
common workflow like lead by example
make well specified issues have
well-structured pull requests do have
somebody do code review on your stuff
this next point good first issue I think
is one of its so incredibly obvious and
so incredibly simple but it enables it
is like the best I cannot say it enough
it is the best route you can give to
people to begin to dip their toes into
your project and to build up from there
and become serious contributors and
don't just tag things with good first
issue
make it even if it's simple you you hold
the project in your head do a brain dump
make it as easy as possible for a
developer to come in say you can you
could probably do it in 30 minutes or an
hour like clean up the whole issue or
instead you can take five minutes and
say you should probably check out this
file maybe you should check out this
function this should probably be tested
in a similar manner is this like I
cannot iterate enough if you want to
enable people in your ecosystem give
them a clear path in another thing that
we all need to work on is documentation
if you're don't just yes you can write
more documentation but maybe you should
be writing more code make it clear in
issues in some forum that where the
documentation is lacking and and allow
people as an avenue to come in and
contribute and enrich it so project
maintainer y'all are badass like
absolutely badass we can't do this
without you
but take like help other people help you
individual developers you need to
contribute you need to contribute you
need to contribute for many reasons one
yes you need to do it because if you
don't do it nobody's going to do it and
this ecosystem needs to be built by
somebody but I'll flip it a little bit
this can actually be a pretty selfish
action in our ecosystem I firmly believe
that the best way that you can further
your career in the etherium ecosystem is
to contribute to public infrastructure
and public resources from there like
that is how you make a name for yourself
that's how you begin to work with the
people that are building serious stuff
if you don't get the reference Google
Steve Ballmer developers okay my last
call to action organizations
at least 20% of your developers time
should be spent on building public
infrastructure and public resources and
I know a lot of you are doing this but I
think this should be a bare minimum
industry standard for the etherium
ecosystem and I I ask you developers put
the pressure on the people running the
organization's make this our hiring
requirement asked are we going to be
doing 20% time are we going to be
focusing on building out the core
infrastructure and again this is similar
to the selfishness that a developer can
have in building out open-source to
build out their network and build out
their their career similarly this is how
as an organization you make a name for
yourself and how as an organization you
enrich your company and you bring on
better developers etc etc if you are in
an organization today and you're not
building public resources and public
good put a pressure put pressure on your
on your managers on your project
managers CEOs whatever whatever you need
to be contributing you need to build
this stuff because it's not going to
build itself that's all I got today I
kind of flew through it I'm very eager
to take questions if you have any
questions for me
[Applause]
what was that yeah if you want to ask me
about if serenity that's fine too I
actually if it's okay I would like 70
okay yeah
so basically Canyon give me like more
details how will actually a registration
of validating service work and how we
can actually protect against stealing of
private keys of validator and protect
our deposits sure there are multiple
avenues so I think the first component
is how do you register you register with
a public key but importantly you
register withdrawal address that is
distinct from your signing key this
means that even if somebody over took
and controlled your public key the worst
they're gonna be able to do is either
log you out or have you sign some slash
herbal offense fortunately because we're
using variable slashing we're the amount
you're slash is proportional to the
faults that could have been made in the
network so as more people are creating
slash munitions in a given stretch of
time the amount with which your slash is
gross so if you're a relatively small
validator and this happens to you you're
likely you're going to be ejected you're
gonna lose some amount of capital and
your funds are gonna be locked for four
months those are kind of the the main
things other things that we're looking
for looking into in terms of protection
is just enabling the core networking
protocol to be generic enough such that
we can better obfuscate who the
validators are this is gonna happen more
in the the user about like who's
building the user validation software
but at least designing the protocol in a
clean way such that you have the option
ality to obfuscate who you are and try
to protect yourself on the that where
someone can slash my deposit right what
was that if someone can steal my private
key it can do something and slash my
deposit right it's like worst case
scenario yes but what I'm saying is if
you're if you having your private key
stolen is not highly correlated with a
bunch of other people having their
private key stole and then the amount
with which your slash is gonna be
minimal
which is a big argument for having
diverse client setups okay hi and this
is a contra contribution question from a
perspective of a project we've got about
ten people knowing on like developer
evangelism what where's a good place to
start whether that's documentation
versus creating more first issues and
then second what are like the
operational processes to help ensure
that this isn't just like a quarter
focus and that drops so the question is
twofold it's how we can what are the
best avenues as an organization to
beacon where would you start as a ten
person um start well two things one
start with you're gonna hit in the
developer experience and etherium it's
gonna become abundantly obvious what
needs like what is missing there's gonna
be something in your workflow where
you're gonna be reinventing the wheel if
you reinvent the wheel or if you start
creating internal tooling for some part
of the developer experience tak
open-source that give it to the
community and that's that's definitely a
great way for an organization to begin
contributing and if you have the
in terms of the individual developers
these guys these people are often just
super fascinated by the technology so
give them a little bit of free rein if
they want to begin working on clients
like give them time to work on the
clients if they want to begin working on
a debugger give them the time to work on
a debugger this is a contribution
question what is the role of a product
manager in open source communities
interesting I meant to mention kind of
who I model when I work on open source
projects and I manage and maintain open
source projects I try to emulate Piper
as much as possible Piper is this
incredible force that has these
beautifully maintained repos with
excellent standards kind of all around
and he's taught me a lot and taught
pretty much anyone that works on his
stack a ton so step one go look at
Piper's projects step two the the
project manager on an open source
project is often simultaneously the
developer and the best thing they can do
is really like create a strong ethos of
standards around what they're doing
project management project management
management is a tough one because it's
often kind of emergent and it's often
something that in open source
repositories we have some difficulties
with so I would say if there's a if your
company is working on some sort of open
repo and want to add in some version of
project management to it it's there's
probably opportunity there just to
follow on what about product management
that's always a big question sometimes
we put the cart before the horse in this
ecosystem and we just start building
things engaging with the users and if
for a lot of the stuff we're talking
about engaging with the developers is
really the best that you can do in
seeking explicit feedback about what
you're building rather than just
assuming hi you think it makes sense to
catalyze open-source with the bounty
challenge yeah that's like that I I'm a
huge fan of get coin I think that
they're making a really really great
impact kind of coupling these bounty
programs with they've they've received a
number of grants to kind of dig into
certain components of the stack this is
kind of like good first issue in that
you really you really have to enable the
bounty hunters you really have to like
take the time to spec it out to be clear
about the problem that's being solved
and what results you expect otherwise
your results will seriously seriously
vary and so if you do begin to use some
sort of bounty program be very know that
you need to be very proactive you don't
need to manage these people you need to
be very clear about what your standards
are and what you're actually expecting
from the issues
cool thank you very much
contributor open source
[Applause]
you