►
From YouTube: Thinking Like an Auditor to Develop Safer Smart Contracts by Dominic Bruetsch | Devcon Bogotá
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 Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/thinking-like-an-auditor-to-develop-safer-smart-contracts/
Since 2017, ChainSecurity has audited countless smart contracts. Based on this experience, our experts will present a methodology for secure smart contract development.
During the workshop, we will coach attendees to think about their project like an auditor would, to help them develop safer smart contracts using foundry and forked mainnet tests.
Speaker(s): Dominic Bruetsch
Track: Security
Keywords: security,solidity,defi
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 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
A
Here,
the
first
step
of
security
starts
because
what
you
should
actually
be
doing
is
you
should
develop
a
threat
model
listing
risk
possible,
attack,
vectors
and
possible
mitigation
of
different,
so
how
different
actors,
May
trade,
your
system
and
already
at
this
stage,
think
about
what
can
go
wrong
or
How?
Could
an
attacker
attack
your
project?
A
A
Implementing
and
documenting
what
you're
implementing
should
go
hand
in
hand.
Ideally,
you
start
documenting
what
your
system
does,
what
your
function
do
early
and
when
you're
writing
code
when
you're
writing
a
function
you're
at
a
very
low
level,
very
deep
and
very
concentrated
on
this
very
function,
making
it
efficient,
making
it
nice
making
it
safe,
but
you
risk
losing
the
whole
picture.
A
Writing
documentation,
helps
you
to
place
this
function
in
the
big
picture
and
gives
you
another
angle
to
look
at
your
project
and
how
this
function
interacts
with
multiple
parts
of
your
system
and
where
project
should
arise.
So
writing
code
and
documentation
should
go
hand
in
hand.
Unfortunately,
we
see
it
often
with
our
clients
that
they
write
documentation
as
one
of
the
last
steps
and
sometimes
then
the
documentation
simply
describes
what
they
see.
The
code
is
doing
right
and
then
it's
not
really
helpful
for
us
as
auditor,
because
reading
the
code,
we
can
do
this
ourselves.
A
So
I
understand
writing.
Documentation
is
really
boring
and
stuff.
We
won't
cover
this
in
the
workshop
today.
If
you
want
to
see
a
perfect
example
on
how
good
specification
and
documentation
is
done,
I
point
you
to
UNI,
swap
they
have
a
very
nice
white
paper
which
contains
the
specification
what
the
system
does
and
in
addition
to
that
they
have
very
nice
documentation
on
what
the
implementation
of
the
smart
contract
does.
What
the
individual
function
expect
is
input
what
they
do
and
what
they
have
as
output.
A
So
I
recommend
checking
out
this
for
your
project.
What
we're
going
to
focus
on
in
the
workshop
today
is
testing
your
project.
Unfortunately,
that's
auditory
seen
it
often
that
projects
are
not
really
tested
and
testing
covers
lots
of
things.
So
sometimes
we
need
to
guide
our
clients
and
point
them
to
links
on
how
they
can
efficiently
and
meaningfully
test
the
project.
A
So
we
want
to
give
you
some
pointers
and
some
initial
training,
so
you
can
get
it
started
with
your
own
project.
This
will
include
unit
tests,
property-based
testing,
forked
mainnet
test.
At
the
very
end,
we'll
talk
about
further
things.
You
should
consider
to
get
your
code
in
an
auditory
State
and
even
after
the
audit
is
completed
once
you
deploy
your
code
to
mainnet,
there
are
further
steps
you
should
take
to
ensure
the
continuing
security
of
your
smart
contracts.
A
Yeah,
that's
the
only
slide
covering
specification
and
documentation.
As
I
said,
you
should
tackle
this
early
on
I
put
from
the
threat
model.
We
discussed,
you
should
think
about
invariant
things
that
should
always
hold
things
that
should
always
hold
when
the
system
is
in
this
state
and
new
invariants.
When
the
system
changes
into
another
state,
this
can
help
you
find
bugs
early
and
the
last
point.
This
is
not
only
to
have
nice
documentation
for
the
auditor
or
for
you
during
your
development
process.
A
No,
the
documentation
is
also
critical
for
the
users
of
your
project,
so
they
know
what
they
interact
with
for
other
D5
protocols
that
interact
with
your
protocol.
They
need
to
rely
on
your
documentation
that
it's
extensive
and
accurate
when
they
integrate
with
your
functions.
They
mostly
refer
to
your
documentation,
and
this
is
also
reason
why
you
should
have
good
documentation
to
avoid
problems
when
third
parties
integrate
with
your
system.
A
The
example
is
a
simple
fund:
it's
a
smart
contract
that
holds
funds
in
the
form
of
erc20
tokens.
Users
can
buy
into
the
fund
by
depositing
the
underlying
token
of
this
fund
and
they
get
pool,
share
tokens
back
and
there's
a
fund
administrator
who
can
use
these
funds
for
trading
with
uni
swap
are
very
compound.
The
goal
is,
of
course,
that
he
increases
the
value
of
the
fund
at
a
later
point.
The
users
of
the
funds,
the
holes
of
the
pool
share,
can
withdraw
their
shares
and
hopefully
made
a
profit.
Of
course.
A
So
in
our
smart
contract
we
will
have
the
users
the
fund
owner
as
the
two
parties.
Interacting
with
that,
let
me
switch
to
the
code
as
it's
important
to
get
a
good
understanding
of
the
code
before
we
think
about
the
properties
and
write
the
test
to
avoid
confusion.
Yeah
this
code
is
all
in
the
GitHub
repo
I
shared
earlier
with
you
interested
to
follow
along.
A
So
here
I
opened
our
code.
Sorry,
that's
already
the
test,
that's
the
fund,
so
it
has
a
lot
of
code
to
get
it
going.
Right
is
our
fund
we
inherit
from
sc20,
so
we
have
our
pool
shares
right
built
in
we
have
some
admin
staff
or
stuff
to
attract
the
tokens.
I
will
find
supports,
we'll
take
a
fee,
it's
three
percent.
So
as
we
it's
when
we
deploy
the
fund,
we
deploy
an
underlying
asset.
This
is
what
we
will
use
for
the
fund's
value
calculation
and
we'll
add
the
token
as
supported
asset.
A
The
owner
can
add
further
tokens.
The
order
owner
can
remove
tokens.
Both
functions
are
not
really
relevant
for
our
test
cases.
Each
token
needs
a
price
feed
so
that
its
value
can
be
evaluated
here
we
have
deposit
and
we
draw.
These
are
the
two
user-facing
functions,
and
these
are
also
the
two
functions
our
tests
gonna
cover.
So
let
us
quickly
go
through
them,
so
we
have
a
good
understanding.
A
We
deposit
an
amount
it
gets
transferred
from
the
user.
We
estimate
the
total
value
of
the
user.
We
need
to
handle
the
special
case
for
the
first
depositor
separately.
As
the
funds
doesn't
hold
any
value
back
then,
and
we
would
have
zero
value,
so
the
standard
case
after
the
fund
is
live
and
holds
fund
is
the
else
Branch.
We
calculate
the
total
Supply
calculate
how
many
pool
shares
to
mean
for
the
user
and
how
many
pushes
to
mean
for
the
admin
fee
will
go
in
more
details
here
shortly
with
the
test.
A
Withdrawing
Pusha
is
basically
the
opposite.
You
give
up
shares
you
hold
and
you
get
a
proportional
amount
of
tokens
transferred
to
you.
Obviously,
your
pushers
are
burned,
then
there's
a
manage
function
which
the
admin
can
use
to
trade
with
the
funds
tokens,
but
it's
not
going
to
be
used
in
this
Workshop
down.
Here
we
have
a
functions
to
estimate
the
value
of
the
fund,
yeah
lots
of
information,
a
quick
time
frame
and
I
hope.
You
have
the
code
in
front
of
you
and
should
any
questions
arise
during
the
tests?
A
A
A
Implementing
a
smart
contract,
it
should
adhere
to
some
specification
right.
In
our
example.
The
fund
should
have
a
fee
of
three
percent,
and
this
fee
should
be
taken
when
the
user
deposits
money
and
gets
his
pool
shares
at
this
time.
Three
percent
of
the
value
should
go
to
the
owner
and
the
owner.
Another
property
is
the
owner
should
always
get
this
fees.
When
a
user
deposits,
no
user
should
be
able
to
deposit
without
paying
fees
to
the
admin.
A
Let's
first
start
with
testing
and
there
are
different
kinds
of
tests
in
your
smart
contract.
You
have
small
internal
helper
function,
which
may
also
be
public
like
our
estimate
function,
which
estimates
the
value
of
the
fund.
You
have
the
buy
shares
functions.
The
deposit
functions,
which
is
a
bit,
takes
more
steps
right
and
ideally
you
have
tests
on
every
level
you
test.
Do
you
need
tests
for
each
function?
You
do
integration
tests
for
processes
that
include
multiple
steps,
but
in
the
end
you
should
also
like
test.
A
Your
system
like
it
is
in
production
and
with
smart
contract.
The
production
environment
is
the
blockchain
right,
you
deploy
it
into
the
blockchain
and
there
it
interacts
with
other
existing
smart
contracts.
So
you
should
properly
test
it
integrating
with
the
smartcock
tracks
on
chain,
so
you
don't
get
any
negative
surprises
or
any
incompatibilities
or
anything.
A
B
A
We
should
want
to
write
a
test
case
which
are
certain
that
the
user's
pays
three
percent
fee
to
the
owner
and
if
the
user
redraws
daily
gets
97
of
the
value.
So
if
the
user
deposits
and
withdrawals
immediately,
he
should
get
97
of
the
value
back,
because
the
other
three
percent
is
the
fee
for
the
owner
yeah.
So,
let's
jump
into
the
code,
we
are
back
into
the
code
editor
and
we
move
from
The
Source
directory
into
the
test
directory.
A
So
if
you
want
to
follow
along,
you
can
open
the
integration
test
file
how
Foundry
works.
You
write
your
test
files
in
the
test,
sub
folder
and
you
call
them
integration.t.sol
and
it's
basically
solidity.
So
as
you
can,
or
as
a
developer
you're
familiar
with
solidity,
no
need
to
learn
another
language
or
anything
else.
You
can
just
use
what
you're
used
to
solidity
and
continue.
A
You
inherit
from
test-
and
you
have
all
this
fancy
stuff
available
which
allows
you
to
impersonate
another
account
distribute
E4
to
another
account
move
in
time
or
whatever
you
need
in
your
tests
and
with
your
test.
You
cannot
simply
test
your
function,
as
is
right.
It's
a
like
a
blockchain.
You
first
need
to
set
up
the
state,
meaning
in
our
case
we
first
need
to
deploy
our
font,
but
deploying
the
fund
alone
is
insufficient.
A
So
we
can
easily
use
them
for
testing
and
writing
a
test
is
really
simple
and
remember
what
we
wanted
to
write
a
test
for.
We
wanted
to
see
if
the
code
of
the
fund
we
implemented
adheres
to
our
requirement
that
when
depositing
three
percent
of
the
fees
go
to
the
admin
and
that
the
user
can
withdraw
at
all
time,
so
of
course,
this
is
like
the
high
level
statement.
A
A
No
sorry
we
get
Alice's
balance
of
rep
div,
but
we
know
that
from
the
setup
that
it's
a
unit,
so
we
deposit
everything
and
adjusted
everyone
know
Unis
stands
for
1
to
the
power
of
18,
so
one
if
and
which
has
18
decimals
as
well.
Right
now
that
you
get
confused
here,
so
we
have
Alice
balance
up
here,
we
deposit
it.
A
A
A
A
So
what
I'm,
basically
doing
here
with
match
I
just
take,
which
test
case
to
run
it
runs
the
test,
but
it
unfortunately
doesn't
pass
reason
the
assertion
failed.
Now
we
can
tell
Foundry
to
give
us
more
variables,
output
to
figure
out
what
went
wrong
and
minus
V.
You
can
go
up
to
five.
It
defines
the
level
of
verbosity
the
output
should
have
so
now
we
see.
A
A
A
A
Tokens
which
it
transferred
to
the
fund
shouldn't
be
taken
into
account
into
so
if
we
transfer
the
tokens
from
Alice
first
to
the
fund,
the
value
of
the
fund
already
increased,
but
we
haven't
issued
shares
for
this
increase
yet
right.
So
the
shares
the
existing
Shares
are
overvalued
and
Alice
gets
less
shares
and
then
can
only
redeem
less
and
doesn't
get
enough.
A
A
A
A
When
you
know
the
code
you
interact
with
so
Foundry
allows
us
to
test
a
function,
call
with
a
random
value
and
see
if
our
assert
condition
hold
for
all
these
random
values.
We
check,
we
still
have
no
guarantee
that
it
works
in
any
case,
but
of
at
least
we
have
a
way
better
feeling
that
it
works
with
big
numbers
which
may
have
triggered
an
overflow
somewhere.
It
works
with
small
numbers
where
maybe
rounding
issues
lead
to
failure.
A
Yeah,
this
is
basically
what
describes
the
difference
up.
We
have
the
unit
test
case
where
we
just
test
one
fixed
value.
The
example
we
just
did
below.
We
have
the
property-based
testing,
where
we
write
the
set
of
action
depending
on
a
random
value
where
we
assert
something-
and
we
just
tell
our
tool
to
test
it
with
many
value
and
see
if
it
can
break
the
condition.
A
Still
in
integration,
and
we
want
to
test
that
the
owner
gets
a
non-zero
fee.
So
the
rough
idea
behind
our
test
case
is
we
safe
store
the
owner's
share
balance
we
let
the
user
deposit.
We
query
the
owner's
share
balance
again
and
it
should
have
increased
right
after
a
after
a
user
deposited,
because
disassigned
fees
to
the
but
I
just
saw
that
I've
already
implemented.
It
forgot
to
delete
it
so
yeah
codewise,
we
query
Alice's
balance.
Sorry
now
let
me
delete
it
and
let's.
A
Not
worth
it
okay
Okay,
so
let's
consider
this
part.
First,
we
created
that's
the
code
for
storing
the
fund
owners
balance
before
then
we
impersonate
Alice
Alice
deposits.
We
create
a
fundamentals:
parents
afterwards,
we
checked
that
the
difference
is
bigger
than
zero.
Of
course,
this
is
a
simple
demo
test
case.
A
A
A
B
A
A
A
A
A
A
A
Admittedly,
writing
good
tests
takes
time
right.
You
need
to
design
them
properly,
you
need
to
implement
them
properly,
and
you
also
need
to
see
check
that
your
tests
are
back.
Free,
I,
remember
a
story
once
we
audited
the
system.
After
two
weeks
of
audit,
we
found
a
broken
functionality
while
manually
reviewing
the
code,
but
we're
really
puzzled.
Why
is
this
code
broken
because
they
have
a
test
case
and
it
seems
to
work
only
later.
We
realized
that
the
test
case
was
broken
and
the
small
contract
was
actually
wrong.
A
A
Reading
on
how
the
special
behavior
tokens
might
have,
you
should
still
test
as
like
in
production
as
close
to
the
production
as
possible,
and
lots
of
tools
out
there
now
enable
testing
against
Forks
of
the
mainnet.
What
this,
basically,
is?
You
run
tests
against
the
local
copy
of
the
real
ethereum
Network,
so
you
integrate
with
the
real
Ave
with
the
real
uni,
swap
you
use
the
real
usdt
code,
and
this
helps
you
detect
more
Corner
cases
and
other
unexpected
one
big
Advantage.
A
A
A
We
want
to
test
that
withdrawing
always
works
and
we
know
from
the
okay
in
the
integration
test.
We
had
the
setup
function
right.
We
deployed
our
own
grabbed.
If
token
we
deployed
our
own
fund
and
everything
we
deployed
our
own,
because
we
had
to
build
the
whole
environment
ourselves
and
if
you
note
the
Zapped
up
function
here
is
different.
We
don't
deploy
our
own
tokens.
Instead,
we
interact
with
the
real
wrapped
e
for
token
on
chain
and
the
real
usdt
token
on
chain
and
the
real
chain
link
price
feeds.
A
A
A
A
A
A
A
A
Yeah:
okay,
if
it
doesn't
work,
I'm
gonna
have
to
explain
you
yeah,
fortunately
no
chance.
So
actually
the
surprise
is,
as
we're
now
running,
our
code
against
live
on
chain
code
and
we're
integrating
with
wrapped
if
and
usdt,
and
the
rep
transfer
will
work
as
expected.
However,
usdt
doesn't
really
adhere
to
the
esc20
standard
in
the
sense
that
their
transfer
from
function
doesn't
have
any
return
value,
and
our
code
of
the
fund
actually
depends
expect
the
return
value
here
on
esc20
dot
transfer
the
interface
specification
of
esc20
expects
a
return
value.
So
it's
solidity.
A
So
if
that
we
don't
get
a
return
value
back
and
our
transaction
will
revert-
and
this
is
a
well-known
strange
Behavior
case
of
the
usdt
token,
which
have
led
to
problems
in
real
life
and
every
developer.
Integrating
with
this
token
should
be
aware
of-
and
this
should
also
serve
as
an
example.
Even
if
you
have
expectations
that
you
interact
with
legit
esc20
tokens,
there
can
always
be
weird
Corner
cases
or
weird
unexpected
behavior,
and
that's
the
beauty
of
forked
mainnet
test
and
that's
why
Fork
maintenance
tests
are
absolutely
essential
to
have
with
your
project
yeah.
A
A
A
A
A
A
A
Cool
that
was
the
interactive
part.
Of
course,
this
only
covered
multiple
tests
in
case
there's
way
more,
you
can
do
and
what
we
didn't
talk
about.
You
should
have
proper
development
process
right.
This
includes
code
reviews.
You
do
merge,
requests
another
one,
member
of
your
team
reviews.
It
gives
you
feedback,
you
discuss.
You
have
proper
coding,
standards
and
guidelines.
You
adhere
to
and
important
to
note,
not
all
bugs
can
be
uncovered
by
tests.
If
your
tests
pass,
it's
never
proof
of
correctness.
A
There
can
still
be
bugs,
because
you
didn't
think
about
test
case
that
would
have
triggered
the
bug
and
formal
verification
of
the
code
can
bring
you
to
the
next
level,
but
again
doing
formal
verification.
You
need
to
come
out
with
properties
and
specification.
If
you
don't
write
the
pro
pro
specific
specs
you
may
miss
out
on
other
bugs
and
what's
absolutely
necessary,
is
to
have
a
external
to
have
an
audit
of
the
code,
both
internal
and
external,
ideally
to
get
the
code
into
an
audit
Readiness
state
after
you've
done
all
of
this.
A
After
you're
done
with
your
project,
it
shouldn't
be
shouldn't,
go
directly
to
the
auditor.
Instead,
the
internal
team
should
take
a
step
back
and
audit
the
project
themselves,
and
this
already
helps
to
uncover
a
lot
of
bugs
and
then
in
the
next
step,
give
your
code
to
an
audit
company
which
is
going
to
do
a
total
review.
A
But
this
is
very
Project
Specific,
but
you
should
look
out
for
and
a
bug.
Bounty
is
a
very
valuable
addition
for
your
project.
So
if
there
is
a
bug
that
has
been
missed,
it
gives
incentive
to
the
writer
to
actually
report
it
to
you,
so
they
can
fix
it
in
time
and
approach
that
we
didn't
talk
about
here,
you
could,
what
we've
seen
from
clients
is.
A
You
could
also
implement
it
as
testy
driven
development,
so
you
don't
start
with
the
code,
but
you
write
the
tests
and
then
you
write
code
which
make
these
tests
pass
and
you
approach
it
from
this
way.
We've
also
seen
this,
but
very
rarely,
and
then
this
yeah
stateful
testing
there's
way
more.
You
can
do
here
you,
but
then
I
need
to
refer
you
to
the
internet
or
invariant
based
programming.