►
From YouTube: Being a Responsible Multisig Signer (Verify, Don't Trust!) by Santiago Palladino | 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/being-a-responsible-multisig-signer-verify-dont-trust/
So you have been trusted with safeguarding a project along with other members of your community, congratulations! But, alas, the first transaction from a developer on the team comes in. How do you proceed? Can you blindly trust the developer? Should you? It's tempting to just see what other multisig members do and roll along, right?
In this talk we'll go over what you can do to verify what a transaction will actually do, and what tools you have at your disposal for this. No coding required!
Speaker(s): Santiago Palladino
Track: Security
Keywords: multisig,verification
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
Welcome
everyone.
Thank
you
very
much
for
coming
today,
we'll
be
talking
about
how
to
be
a
responsible,
signer,
we'll
be
focusing
on
multi-six,
basically,
because
we
only
have
seven
minutes,
but
this
applies
to
pretty
much
any
proposal-based
governance
system
so
picture
the
situation
that
you
have
a
set
of
smart
contracts
set
of
assets
that
you
want
to
control
you
manage
them
via
VIA
multi-sig.
You
are
one
of
the
signers
of
the
multi-sig
and
you
are
presented
by
this.
What
happens
99
of
the
time
is
that
no
one
is
going
to
review
this.
A
They
are
going
to
blindly
sign
it,
go
ahead
and
pretty
much
defeat.
The
purpose
of
the
multi-seal,
like
you,
only
have
the
multisig
becomes
basically
one
out
of
an
wallet
where
just
a
proposer
gets
whatever
they
want
approved.
The
scope
for
today
is
go
through
a
series
of
tools
or
techniques
that
we
can
do
to
actually
verify
understand
what
we're
signing
right
click.
A
You
understand
what
you're
saying
when,
whenever
you
sign
something
in
real
life,
you
should
do
two
when
dealing
with
with
matching
internet
money,
and
the
important
thing
is
that
the
tools
should
be
understandable
for
non-technical
people
right
now,
multi-seek,
it's
very
often
that
you
have
the
CEO
CEO.
You
have
contributors
to
a
project
that
are
not
not
necessarily
technical,
so
we
want
to
make
sure
that
they
are
able
to
review
and
understand
what
they're
assigning
so
we'll
Begin
by
understanding
the
transaction
understanding.
A
What's
in
a
proposal,
and
for
that
we'll
go
to
First
there,
it
is
so
we'll
start
by
going
on.
Okay,
what's
actually
in
a
regular
ethereum
transaction
right,
so
we
have
a
recipient.
We
have
something
that
we
call
usually
contract,
that
contract
will
do
stuff
will
most
likely
go
into
other
contracts.
We
have
a
piece
of
data
where
we
say
hey.
A
We
want
you
to
execute
this
this
and
that,
in
this
case,
for
instance,
a
swap,
and
we
may
have
a
valued
basically
something
that
we
send
to
it,
and
the
proposal
in
multisig
is
no
different.
It's
basically,
we
are
asking
our
multi-seat
contract
to
be
calling
to
be
calling
another
contract
with
some
information
and
optionally
with
some
money,
so
they
catch.
A
The
first
thing
that
we
can
do
is
this
is
actually
a
screenshot
from
the
nosy
safe
here
is
understand
what
what
it's
doing
I'm
like
parsing
that
and
we
can
see
how
much
money
sent
we
can
see
which
contact
we're
interacting
with
and
we
can
see
which
function
is
being
called
now.
The
function
may
give
us
more
or
less
information
right
and
the
first
thing
that
we
can
do
with
this.
It's
pretty
obvious
like
go
to
the
documentation.
A
Every
serious
project
has
a
documentation
attached
to
it
and
will
tell
us
what
the
function
will
do
that
way.
We
can
actually
see
that
that
swap
exactly
for
tokens,
what
it's
going
to
do.
What
each
argument
to
it
is
representing
actually
understand
what
we're
approving,
but
you
guys
are
not
here
so
that
they
tell
you
to
read
the
freaking
manual,
so
we'll
look
into
some
more
interesting
stuff.
A
Something
something
very
very
powerful
we
can
do
is
simulate
the
transaction,
so
we
can
use
different
tools,
tenderly,
open
sampling,
Defender
block
native,
though,
for
now
it's
a
API
only
to
simulate
what
would
happen
if
a
transaction
were
executed
now
granted.
That
will
not
be
the
same
as
when
the
transaction
gets
actually
executed,
for
instance
in
swap,
you
may
get
more
or
less
tokens
back
later,
depending
on
price
fluctuations,
but
it
gives
you
a
pretty
good
idea
right
and
the
idea
is
that
a
simulation
will
give
you
different
information
right.
A
It
will
tell
you
which
contracts
were
involved,
State
changes
or
events.
So
in
terms
of
contracts,
at
the
very
least
you
can
see
where,
as
we're
saying
couple
minutes
ago,
one
contract
can
call
another
and
another
and
basically
have
different
different
effects
on
the
chain
and
so
by
spotting.
If
there
is
any
contract
that
shouldn't
be
there,
that's
the
first
sign
of
alarm
when
we're
signing
something,
for
instance
here
in
the
case
of
a
swap,
we
see
that
a
unitary
pool
is
involved,
a
router,
the
tokens
that
we're
exchanging
things
that
make
sense.
A
If
we
are
feeling
a
bit
more
adventurous,
we
can
also
look
into
State
changes.
We
can
see
okay,
how
each
of
these
contracts
involved
changed.
Probably
there
is
a
thing
to
go
through
our
balances
right
like
if
you're,
if
you
are
doing
a
swap,
we
would
expect
that
the
balances
of
one
token
would
go
up.
Another
one
would
go
down
and
again
we
can
see
if
there
are
any
funky
things
there
usually
State.
A
However,
it's
difficult
to
parse
or
to
understand
so
the
main
thing
that
we
want
to
look
to
look
at
our
events,
so
any
reasonably
designed
contract
will
emit
an
event
whenever
something
interesting
something
important
happens.
So
there
are
a
bunch
of
events
that
should
immediately
catch
our
attention
when
we're
reviewing
a
transaction,
namely
a
transfer
moving
assets
from
one
place
to
another,
an
approval
which
is
giving
right
to
someone
else
to
manage
our
assets.
A
Anything
related
to
role,
management,
to
ownership
and
to
upgrades
and
events
will
have
some
extra
information
that
we
can
look
into
to
get
better
sense
of.
What's
Happening
now
speaking
of
upgrades,
this
pretty
much
deserves
a
whole
chapter
of
Their
Own.
An
upgrade
transaction
usually
looks
more
or
less
like
this,
like
calling
the
contracts
and
telling
it
hey.
Can
you
please
upgrade
to
this
new
address
and
the
only
information
we
have
is
literally
an
address
and
okay,
let's
simulate.
Now
we
have
something
new
on
our
toolbox.
A
We
can
see
what
what
it's
like
sure
the
simulation
will
tell
us.
Yeah
yeah
the
implementation
is
moving
to
this
new
address
and
that's
all
the
information
we
have
now.
That's
that's
a
problem
right
like
what
what
information
does
an
address?
Carry
for
sure
the
address
should
have
a
verified
source
code
Associated
to
it
whether
it's
an
ether
can
sourcify
the
price
that
the
source
code
is
a
bit
long
right.
This
is
an
actual
contract
from
from
the
graph
that
URL
wrote,
you're
you're
over
here,
and
it's
like
thousands
of
lines
of
code
spread.
A
Actually
there
you
are
spread
across
16
different
files
like
no
signer,
is
going
to
review
this.
What
a
signer
can
review
and
can
understand
is
this:
it's
a
report
that
they
get
from
an
auditor
from
a
set
of
developers
from
someone
that
say
Hey.
You
know
we
have
reviewed
the
code
at
this
version.
It
looks
good
to
me
and
they
can
trust
that
they
can.
They
rely
on
that
and
that's
what
they
should
be
using
for
making
a
decision
whether
they
want
to
upgrade
to
another
version
of
or
not.
A
But
the
problem
that
we
have
here
is
Bridging
the
Gap
between
that
identifier,
that
version
of
The
Source
call
and
what
gets
deployed
at
an
address
right.
So
we
know
that
there
are
a
couple
of
steps
involved.
We
have
the
source
code
that
gets
compiled
into
into
a
binary
artifact
and
that
in
turn
gets
deployed
to
a
particular
to
a
particular
address.
So
what
we
want
to
do
is
make
this
process
transparent.
A
Granted.
We
could
ask
reviewers
to
write
them
to
run
a
script
like
this
and
try
to
replicate
the
compilation
on
the
deployment,
but
we're
trying
to
give
the
tools
to
reviewers
that
are
not
technical
to
be
able
to
do
this,
and
let's
tell
the
truth,
like
even
developers
are
not
going
to
do
this,
and
there
is
a
solution
here
like
it
has
been
in
traditional
web
development.
For
years,
it's
making
deployments
public
reviewable
of
auditable
traceable
like
just
to
a
deployment
to
NCI
on
some
on
any
word,
that's
public
that
anyone
can
go.
A
There
can
see
hey
this
version
of
The
Source
Code
has
triggered
this
build.
That
was
deployed
at
this
address,
make
it
transparent
and
easy
to
understand
and
to
read
and
embed
that
information
in
The
Proposal,
that's
being
that's
being
sent
to
signers,
so
they
they
can
understand
that
they
can
bridge
that
Gap
from
source
code
to
an
address
with
the
code
that
they
are
approving
an
upgrade
to.
A
So
all
in
all.
What
I'm
pushing
for
is
to
make
sure
that
multi-6
are
actually
multi,
that
we
make
use
of
all
the
people
that
are
appointing
assigners,
because
they
should
have
the
tools
to
be
to
be
able
to
understand
and
Dot
security
to
the
process
by
reviewing
everything
that's
happening
instead
of
blindly
signing,
and
if
this
is
not
possibly
a
reviewer.
Remember
the
burden
is
on
the
proposal.
The
Proposal
of
something
needs
to
give.