so we are gonna give you a little bit of
an overview of what good projects do in
the space in order to plan and ensure
their success their success so let's
address the elf in the room everyone
says smart contracts are insecure there
doesn't seem to be anything changing
about it like like what can be done is
it just something we have to live with
or is it something that can be fixed so
I think it is possible the design robust
and secure software and I think that
this comic actually points it out a
little bit unintentionally so we built
we trust machines we trust airplanes
elevators all sorts of machines that are
actually run by software the safety
critical parts are run by software every
day and those those machines are
designed such that there's there's very
little things that go wrong that you
hear about I mean you might hear about
an airplane crash once a year you
imagine them out of time that airplanes
actually fly around the globe that's
pretty amazing so we have to ask
ourselves like how how do we get that
kind of security into our applications
no I just want to go down on this nope I
[Music]
have to do it manually yeah so we have
to we have to learn like more from these
industries how they make things so good
so most of what I what I'd like to talk
about is just how not to take shortcuts
how to plan ahead how to make sure that
you you have everything all your ducks
in a row so so the secret is is that the
weakest link and designing software is
actually humans it's all of you guys so
you have to figure out how to make
yourselves mitigate against any risks so
the only the best way to do that is by
having lots of layers of testing not
just single types of testing have really
good documentation so other people can
understand what you're trying to do and
get multiple people to review your code
tests and assumptions and a regular
basis not just during an audit so
testing is the only true way to actually
detect inker
behavior in software I think a good
quote is that like you know software -
test is just paperwork basically at the
end of day so multiple layers of testing
ensure that you don't have any single
one critical vulnerability that goes all
the way through and I like to illustrate
that with blocka Swiss cheese so the
bigger the box Swiss cheese you have the
less likely you have that a little
bubble ends up making its way all the
way through so if you have a big big
huge chunk of Swiss cheese you can you
can never see through it but if you have
one thin slice representing one layer of
testing or just one person writing the
thing you're very likely to have lots of
holes so documentation testing all helps
help you get through that and again
hitting on security audits a lot of
people like to say security audits with
gold standard for security and in space
and that's just plain wrong you have to
have a lot done before you get to that
point or else you're never going to be
successful that process you're gonna
have a lot of you're gonna have a lot of
outcomes from the audit you're gonna
have to do a lot to fix all the outcomes
that the auditors brought up and since
you guys are innovating in the space so
often you're going to have to redo this
audit over and over again pay a lot of
money to get that into there it's way
more cost-effective for you to build
into in this process into how you guys
approach smart contract development and
and you you make security auditing one
small part of how you ensure the overall
development process is secure so I from
aerospace we kind of had this like
ancient view of how things get done and
we used to use this be model of software
development it's like way before agile
and waterfall and all these other
buzzwords but I actually kind of like it
because it has this neat little
iterative process as you go kind of
moving forward so you end up always at a
place you want to end up but you you
always are looking back and make sure
you're solid on your foundation before
you move next to the next step so the
first part is just having a really good
design spec understanding with the
customers or or you know the business
leaders of your company or anyone who
has like the solid idea like what it is
you're actually doing
and you'll always be constantly coming
back to this and making sure that you
have very solid firm idea and grasp on
what you're actually doing if you don't
have this you end up in a position where
you're constantly iterating and you you
you sort of lose focus of actually what
you were trying to do in the first place
and if you don't have that real focus
it's really hard to make a determination
of is this decision I'm making the right
decision am I going in the right
direction so from there you sort of take
your design spec and it should be a the
design spec itself should be like human
readable something you can show somebody
else who's non-technical an agent
understand and get your project it's
kind of like a white paper almost so you
take that and the next step you go is
the architecture so that is the you know
the really solid underpinnings of your
project you start to design like what
kinds of contracts am I gonna have how
it's gonna interact with all the other
components in my application and how you
know what names I want to give
everything and and that really gives you
a solid foundation for the next step
which is designing requirements so you
can go you know ray off the deep end
with this like we did in aerospace it
took us months to actually get
requirement specs through the door or
you can just use this as a process to
say like hey what are the technical
things we need to do in each one of our
pieces to make sure they're like to the
degree we want and you can write this in
like a comet field at the top of each
smart contract however you want to keep
track of it just make it clear and make
it easy to understand like how that
links back to your idea so you have a
clear view of traceability all
throughout your application so from
there once you have your requirements
you're at the bottom of this V cycle
here you start the code do you just do
the thing you have all this solid
underpinning of understanding of what
well you're actually building behind you
and you can iterate on that as you
discover new things in code and you you
know identify things you want to change
about your design but because you have
this solid traceability down the left
side of the V you always understand like
well I just want to update this one
thing and then you can analyze the
change impact that has you could say oh
well this little piece gets changed and
I update this other piece everything's
fine
the really cool thing is that because
you've gotten requirements and
architecture down on paper you know what
you're calling everything you know what
everything's supposed to do you can do
testing in parallel you can you can get
a whole separate team on board and have
them work in parallel on you know test
different Velma processes and have them
start writing tests that link to each
requirements everything you want to do
so you can kind of save some time and
effort from that by having two teams
working in parallel instead of waiting
for the code to be done before you write
tests usually the tests come out better
when you don't have the tester the
person designing the verification going
back to the code to say like hey what
does this do it actually makes your
documentation more improved because
they're looking at that to design the
tests instead of your code and you make
sure you build it like a stronger
project out of the gate so the really
cool thing is that as you go up the V on
the right hand side this is how you know
you're getting closer and closer to done
you can actually design a schedule
around this so so once you're at that
bottom point you're doing code and
testing you sort of iterate in this very
short loop between requirements code and
testing updating anything on the
left-hand side as needed and until you
finish testing you get all greens on
your huge test suite from there you move
integration you kind of integrate with
the rest of the application whether it
be you know the front end or any sort of
Damons you guys written or networks or
you know plows for frame Ericsson and
anything you guys imagine that kind of
exists outside of the hypercritical
design you're doing with the smart
contracts and this works for anything
not even just smart contracts but
hypercritical
smart contracts are hyper critical so
that's why I point them out once you're
at that point and you may have some
iteration in this cycle tool back to
your architecture because you made some
fundamental misunderstandings of how the
tech would work you're basically done at
this point you're ready to go to demo
and test and release so you create your
demo you you probably want to show off
on a test and then start bumping it up
as you grow more and more confident
under what what you've made until you're
you know pushing on the main to main net
and starting to work with real user
fonts so
the important part you got a cert small
here you got to grow that as you grow
confidence and make sure that you're
able to cover any losses that happen so
like the recent spank chain hack I
actually like the pointed I was a really
cool thing that they didn't over exceed
their ability to pay for any any issues
that arise I don't think they planned
for it but I think now that they see
that they understand that like you know
this is all new technology bad things
gonna happen but as long as I keep that
expectation below my risk level
I'll be fine so once you get through
that and everything goes well on your
demos and everything's happy you're sort
of in this release cycle and now you let
it that sit out there in the world and
you just you know gather use your
feedback and you may be working on the
next iteration of the design but you're
also maintaining that code watching
things out there in the world and
understanding you know what you want to
do next and how you're gonna support
what you did and it's very important to
sports what you did I think in this
space there's this idea that you know
once you release about the main that
it's all mutable you can't change in any
way there's nothing I can do about it
after that point that's false there are
things you can do in order to respond to
react to events it may not be with that
smart contract itself but having an
accurate plan beforehand of what you're
going to do I following any sort of hack
like you know build a whole new token
contract and poured all the token
balances over just have a really good
plan of how you're gonna handle most
situation that you think will arise and
then you get Lambos of course so a
little bit requirements so this this was
pain for me for like five years but
there's a lot of truth in this defining
good requirements is really an art and
it helps your testers your your
implementers your coders everyone to
understand what the process is very
succinctly and very well
so there's five aspects of good
requirements they are smart quote
unquote so specific means each
requirement decides a very specific
logical functionality and it should be
unique to what is describing measurable
means that it should be quantitatively
measurable ie the you know the the token
shall be transferable only if the
balance meets or exceeds this amount
blah blah blah
they should be attainable I describe
functionality that the software can
actually implement not something like
the economics of the platform or some
sort of loose UX experience that's
desired it should be really tightly
coupled to something that's achievable
and practice relevant kind of describes
that same thing not describing
extraneous functionality is very it's
all very core to the application and
isn't kind of outside the realm of what
you can do with the software and
time-bound is last it basically
describes things that are like very
specific in time they shouldn't be like
oh well eventually it's going to do this
or you know at some time it should be
like X seconds or Y seconds or weeks or
months or whatever you should have very
tight requirements around time to make
it easier to understand so traceability
is another thing I think a lot of people
haven't had a lot of exposure to so the
idea is is if you go through this
process and yeah it's a little bit more
upfront work you can actually use some
really cool things to get a really good
picture of whether or not you're done
and that's pretty cool so if you have
the requirements you kind of link them
to these numbers I had an idea to you
know like hatch the requirement tax to
have a unique ID hash so you can tell
when things change you can do it any way
you want
you basically link your requirement to
you know a specific identifier you might
use like a like a NAT spec comment link
in your code be like hey this implements
requirement number one or something like
that and the same thing in your test
case you you know use Nats textile
comments in your test cases and then
once you have all these things in place
we can build tools that link it all
together and you can get a really full
picture of your entire application
linking all the way back to the
specification the human readable thing
that you guys all agreed on before you
started the project by using tools like
this and you can you can identify holes
in the approach you can look for places
that things weren't implemented
correctly or missing and make sure that
you guys are like truly done with your
application before you're ready for the
next step if you bring this to an
auditor your honor it would be like half
the cost no joke
when I was shopping around for audits
all the auditors were really
prai's that I was doing this in my
application okay so I'm Creole and I
will be more pragmatic part of this talk
pragmatic enough that you will feel like
a motivational speaker not some sort of
the engineer and this first thing I'm
going to talk to you about is
test-driven development because everyone
knows that you probably should be doing
the ads no one understands why like I
was like I asked and people to earn
because I need 100% coverage or
something like that
the actual answer is that your tests a
code and you need to verify that your
test code is working as you expect them
to do and you I'm not suggesting you
writing tests for your tests right so
the only way you verify that you test
check something and it's not like one
equals one in the end is that you write
tests first and they fail and then they
fail your ad code and then they pass and
that means that your tests are actually
checking the behavior which you just
implemented in your program also I
promise to be problematic no one is
going to do that all the time this is
like true of rust where engineering
no one is writing tests first so what
I'm suggesting for the existing systems
systems weren't written right now by you
and you have to write tests for it just
try to break your test by modifying your
code just introduce miles sounds small
error and make sure you test go read if
it happens yeah this test is useful this
test is testing what it's supposed to
and there is no subtool syntactic
mistakes in there another like being
more to the solidity testing i recommend
testing solidity in javascript because
then small syntactic misunderstandings
between you in solidity won't get in a
place so you basically won't repeat the
same error on your testing side of the
code oh yeah and actually the major
truth is that you are not designing just
the system which is deployed on chain or
like the web app you are deploying to
accompany it but the system includes you
and it includes the way you deliver
things and so on and this is the info
front blockchain gravy
really wonderful project which
accumulates the post-mortems of failed
and hacked blockchain related projects
and as you see how other projects
haven't been hacked through the unchain
things at all it is all poor operational
security it's either your servers hacked
or your cloud credentials hijacked or
your keys are compromised or something
at that and good operational security is
a part of a security of a system you
delivering you know this this is the
thing like you all know what needs to be
done you're just not doing that because
it requires you to change your habits to
the second factor just get a hardware
token if it is too expensive for you
just get the Kryptonite on your
smartphone it is almost as good for zero
price hardware wallets air-gapped sonic
devices yes please
please do that website based wallets bad
idea
never just if it is a production-related
key never to type it in any website this
is like instant compromise just assume
that we've seen even the best online
wallets being compromised by really
really expensive attacks you are not
protected from that just use something
else real keys to conduct damage like to
your investors or to someone mmm
use the test net all the time like your
production keys stay safe if they are
not on the screen when someone else is
looking that's the rule just you
wouldn't believe how frequently I see
compromises from these like probably
everything ends up fine and you
investors a trust for few guys but why
push your luck and just don't ever
forget that many mass uses the same key
and every network yes general hygiene
like do it like you know you not need to
use password manager you don't need to
reuse passwords still like everyone has
them let's just make push and change it
full disk encryption just is a must you
don't want to have your project
compromised just because you forgot your
laptop on the train firewalls like
everyone knows the list just figure out
the way you can incorporate those
security habits in your day-to-day life
I promise you I will be motivational
speaker yeah you know what needs to be
done I know
can do it please do it another thing sit
down with your DevOps or operations
engineers and come up with a list of
security improvements there they
probably also know what needs to be done
but they also overload it with day to
day tasks so they never improved your
security but we need know what needs to
be done so please go in and figure out
do you need passwords for SSH properly
you don't change that are you build
machines are secure are your secrets for
builds are protected and they won't leak
to any third party pull request offer to
your repository that's a surprisingly
frequent thing I see well yeah if easier
MongoDB port is closed from the external
world that's like the most frequent
source of hacks in the last year yeah
this thing problems happen you just need
to be able to recover from it and have a
back-up plan the thing is that when
hits the fan you will be under stress
and you want to be able to react in time
the smartest way so the only thing I can
recommend is come up with a recovery
plan before things happen have a really
it will be stupid it will be obvious
checklist you will feel like am I in the
five grade again I'm writing down
obvious things trust me
you will really thank you later when it
times come to unpack that checklist and
go step by step and ensure who is
responsible for what what is the effect
that the parts of your system
do you need to notify your partners what
are the channel for those notifications
and so on obvious things have it have it
ready
it will save you day yeah yes so I think
just like all in summary you guys are
all really smart people just write down
more things on paper share them with
each other
that'll make your things all the more
secure that all of these recommendations
involve writing things down
thanks to those folks we got 10 minutes
for questions
just raise your hand we got this down
hey so essentially first slide is the
return of waterfall a little bit at
least it feels like that and I get it
for airspace if you're building rockets
and planes where people can die or
people can lose all of their money for
sure you shouldn't throw on the
wall and see what sticks or what's what
gets hacked but in reality it's it's
also a little bit more nuanced right
it's not a plane or something super
agile where you can can afford to make
mistakes so I'd like to know how do you
how do you know which mindset to apply
because in that first example if the
first time users actually see this is at
the very top right of the V you
potentially have lost a lot of time
where users could have told you what's
not working that is a great point I
think like just getting more user
feedback in terms of the cycles so
that's about doing smaller demos trying
to figure out things ahead of time like
getting practical feedback about the
market right that you're intending and
operate in I think so in response to the
V thing like like nobody said you
couldn't use V and agile at waterfall
and agile together like everyone's like
oh man that's that's the thing you can't
do but like you can like I chose like
kind of a short cycle that you're you're
always constantly building towards a
goal and you know waterfall or V is is
like the long-term push like the idea
from start to finish you know we're
building protocols that like once you
build you probably won't want to spend
you know the ninety percent of the time
you spent testing and do that over again
for one small change so it like it
really pays to get things right ahead of
time so just building that into your
process I I think is really helpful and
you can still use agile for everyday you
know everyday use that that keeps people
moving in a specific direction this is
more project management stuff to make
sure that like when you're at the end of
the process you know you cross your eyes
not your T's and all the technical
things but you're you're totally right
you have to have the feature set
identified and validated by the market
you're ten
operated can also I meet a little bit
because I believe what waterfall
typically emits like they don't do that
is they never get the feedback loop on
pre-production stage of things but it
can be done and it works perfectly like
you can show like I don't know sketches
of your interface to the end users and
get feedbacks or something like that and
this is what all agile is about we find
your hypothesis earlier so if you can
incorporate those feedback loops in
whatever is large planning really
complicated process the more agile you
would yet even if it looks a little bit
like waterfall yeah we understand that
it has stages and they go one after
another when when you're at the lambo
stage that's that's the end release
that's every what everyone's been
waiting for that's when real people's
money enters the equation so you know I
will absolutely stay on the side of you
know handling my clients money and my
users money as effectively as possible
so this is the best way I know to do
that
but again absolutely you have to get
that feedback along the way or you're
building the wrong thing you're not
doing the right thing and to begin with
yes thank you for the presentation guys
we talked about TDD and testing and I
wanted to know where would you recommend
testing with JavaScript their solidity
is it more like you like like he was
saying just never use solidity tests
they're I think they're a terrible idea
you're trying to use the thing you're
using to release as you know like real
live code and developing in that same
framework which was never designed to
actually do testing there meant there is
some caveats to that sometimes there's
just something that's not possible like
a library it's really hard to test the
library without like some sort of you
know infrastructure around that but use
that and then do it in JavaScript test
where it has a more more feature full
test testing infrastructure or use
Python I hope people writing tests in
solidity where you have a team of people
working on a contract and you
right like you know people are focusing
on a function and you want to pass it so
well you can write this without that
it's okay thank you there's always
nuance yeah couple behind
I was hoping could you clarify or the
tools around traceability or their repos
that are open-source you think apples
I'm working on some particular tools I
have like a BIM plug-in that like will
help you like what I was talking about
with the hashing thing so that's really
useful once you very greed upon your
list of requirements you know they
should never change the hash should
never change and if you use that hash
and like you have a really big codebase
and you start putting like you know a
trek hash this does blah blah blah a
part of that requirement and and then
like further down the line you've sort
of forgotten everything you've ever done
behind the scenes and someone's like oh
well this requirement is wrong we
validated with the market those are bad
assumption we need to change these
features now you're like okay what do I
have to go update super easy I now go
change of the hash and see where all the
places where the old hash were in place
that now are mismatched with the new
hash pretty cool so I'm working on a
tool like that but there's no real tool
tool set in the market so if you're
interested to come talk to me hey guys
thanks I'm a bit curious you've provided
some very awesome technical points one
thing that I'm very curious about is how
do you actually develop a kind of
company culture of appreciating the
importance of these sorts of things both
from like the technical standpoint and
perhaps the non-technical people in your
team like basic thing I like to
encourage and like I see really helpful
in encouraging that is use robots as as
long as you can like no one like when
you go in into the pull request and you
said no this is just not testing this
requirement or something like that
you're not like you enforcing it by hand
and people start arguing with you but no
one will ever argue with robot because
that's sort of stupid and this is how
you basically put the baseline on any
culture of a culture of tests on the
culture of code style and so on just use
the robots to the like
maximum extent after that probably just
talking with people like explaining why
you're doing that in before will help
like they will not they will agree and
then we will feel bad if we will try to
like push you away from your various and
I think at the end of the day it's it's
either gonna come from a cultural shift
before a problem happens or after so I
think a lot of people in the space look
at the problems that happen and think
like oh those people were stupid they
didn't think ahead of time
no they just weren't aware of it they
weren't thinking along those lines and
they've bathed drastically changed how
they've approached the problem and we
should learn from them because you're
gonna repeat the same mistakes if you
don't take that seriously
you