[Music]
so I'm the CTO of digits global and I am
famous for basically doing the
first-ever athyrium transaction on block
number 46 147 and I'm here going to talk
about contract patterns in security so
so the key points is first solidity is
not broken okay so a lot of people there
is some plot posts in the past saying
that solidity because it is a an
imperative language that it's a poor
choice for writing contracts that has
like state transitions so i'm going to
show you guys that just with proper
tooling and architecture we can actually
write secure and easy to manage
contracts
so we're going to use i'm going to show
you guys code patterns that allow us to
minimize attack surface
and i'm going to show you guys that the
contract execution flow and figure out
how you guys can identify attack surface
in your contracts and
also i'm going to show you the the case
study of the digits core contract
architecture
right so both
right so the bold claims
quote good software design requires
basically gives us secure good security
so if you're right if you have good
architecture you'll be able to actually
create easy to secure and easy to audit
code the first point is that good
readable code and good architecture
which is what that can easily be reason
to can can be read by an external
auditor so if you send your code your
code base to a third-party auditing
company they can actually easily read
your code without having to deal with
spaghetti code right so we know that if
like this type of code well if you send
this to somebody it's going to take a
while for them to parse through this and
that makes a deters lives so much harder
and
to like good software architecture will
also allow us to actually have reusable
battle-tested code so basically we can
we can take components and build them
out individually and we can reuse those
those components for other parts of our
contracts and
since we know that these are battle
tested and the security you know that
there are the security is good
so good software architecture also
allows us to have separation concerns
which actually enables the second point
as well so if you separate your your
code logic into separate
contracts in the case of etherium then
it's easier for you to audit it and it's
also easier for you to control the
attack surface the potential attack
surfaces on your contracts
all right so I sort of
want to make the analogy of an
electronic circuit versus software so in
like an electronic hardware for example
a computer motherboard or a CPU once
that's created and fabricated it's it's
very difficult for the manufacturer to
recall those products so
basically in essence like if they're iam
contracts when you deploy them to the to
the blockchain you can ever change them
so
so in that sense like
we're expected to become electronics
engineers when you write contracts on
the cerium right
so here we have a
Commodore 64 motherboard I don't know if
maybe you guys are familiar with this
old school computer motherboard we have
the series of memory chips and the moss
sound chip the interfaces so when you
design hardware you have different
components that are known
known to work well and and and they've
been tested and you just basically put
these things together and you have you
know a device
so basically that that sort of falls
into the same concept as a software
development paradigm called design by
contract and i'm not talking about
sylheti contracts here but basically
creating your your your software based
on small components that multiple people
can work on or multiple organizations
can work on and you have basically a set
of preconditions that you can take in
and and that will you know either
produce a side effect or an output value
fairly simple right
so basically if you can make an analogy
this sort of like your sound chip or
your CPU you can put in put in it and
you have expected output from it
next one
am I supposed to point this
I think battery ednas is dead or dying
yeah guys have another controller yeah
the top button is not working
served by that technical difficulties
thank you
alright
back here alright alright so the third
point is separation of concerns you
basically separate your contracts into
small pieces that can be easily audited
and you basically can define the entry
points and exit points to your contracts
and
number four good architecture will allow
us to actually write better tools such
as static analysis tools and generators
to create basically help you create
boilerplate code to implement this
this approach
so
so what are attacked vectors right so
attack vectors are basically code paths
that allow malicious user such as a
hacker or somebody a user that sends
unintentional unintentional code tier
software that either gives them
unauthorized access and these can in
traditional software you have command
line arguments where you can pass
well you can pass like some some a
hacker can pass a
carefully crafted
carefully crafted code such as a
shellcode with with some buffer overflow
exploit and basically give them access
to that machine environment variables as
well and URL parameters which is common
in web application hacking where you can
basically have a hacker send sequel
injection commands into your application
by basically sending a quick carefully
crafted post data or URL parameter and
also data storage which falls in the
same concept as the the the previous
post of URL parameters in this case
somebody has access to the database and
your application reads some data from
that data and and it costs us your
application behave in a way that you are
not expecting to and in the case of
solidity and etherium contracts these
are function parameters third-party
contracts that can access your contracts
so let's look at the cerium transaction
flow so we know that all athyrium
transactions must happen from an
externally own account that means your
private key so in the first four
examples you have an externally own
account calling a cerium contract and
and that can go with an ATM contract
paste out to another externally own
account and the third example is an
externally own account that sends
transaction to an atrium contract and
that also calls another a theorem
contract and that is basically where you
see things such as
recursion and
reaction see problems right so and in
the the third act the fourth one is just
basically somebody sending either to
another external you own account and the
last two can't happen right because like
contracts cannot basically start their
own execution
maybe in the future
so let's look at the example erc 20
token here this is actually on the dot
bin I just cut and pasted this and this
is basically the that to the standard
token format standard token code with
the standard interface for it so here we
have the contract and then you have sent
coin function which takes some values
coin balance which shows you like the
balance of the account from from the
mapping and you have the balance off and
approve so obvious all these functions
and the arrow reside in the same
contract right so in the same it's in
the same binary that once deployed on
the blockchain it's immutable you can't
change it and it's very difficult to
have people point to a different
contract address so
what we're going to do is we're going to
break down the contracts into pieces
basically these are components that
behave in a certain way and and you can
basically describe your software just
based on these contracts so we have
interface controllers storage and the
last two are basically what glue
everything together now we have the
access control and the directory
services and resolver
right so interface contracts contracts
that be called directly by an end user
or external contracts this is the main
entry point right so basically this is
the contract that when you compile it
and you produce the jason ABI this is
the the con the ABI that you put onto
your misc wallet or you give to your
users or to other people that will be
using your contracts
so this is the main entry point so for
our design this is the only attack
surface so this simplifies a lot of the
security audits and making sure that
your code is secure yes this is the only
entry point and we can control this a
lot better than having a file that has
all the logic in one file and then this
can get overwhelming when you read it
right so if you're dealing with with
four hundred lines of code or five
hundred or a thousand it's overwhelming
to read one file and you can't really
you know it's hard to reason about like
large pieces of information so if you
break it down to smaller pieces it's a
lot easier to reason about it and figure
out what's going on
wyd again
am I just having the worst luck for this
you
rewind
right so
interface contracts talk about it
control contracts basically this is
where most of the code logic goes and
this is where you basically have
your you're the interface contracts
calls this basically and and all the
functions that are needed to be called
that basically either change storage
state the state storage or the some
calculations are all in here so most of
your lodgings gonna be here and if you
wanted to look for logic errors this is
where you would look for right
storage contracts yeah this is basically
your database right so in traditional
MVC this is your model this is where you
put all your data and you put basically
this is where all the information is
about your contract under the state of
your ear DAP
other components access control this is
actually a very important piece that
actually puts everything up basically
this is the biggest piece that
puts everything together and there's
basically set of your reusable code that
we can use to describe how a resource
can be accessed and at the jaques we
sort of identified several access
control patterns
basically these are how you describe how
a resource can be accessed by an
external an account or another contract
and
so that would be an example here is the
AC owned contract that we have and is
very straightforward there's a contract
that has an owner and if the sender of
that that transaction is the owner then
let it through and if not then you throw
an error and eat up every the gas that
they sent
right and then here we have a it's very
small the groups so basically this is
the same as the owner but you can
basically define multiple users to use
to basically say that like this this
this resource can be accessed by these
addresses and it's basically simple
mapping that says
if you're if you're in a group you're
you can access it and then there's like
some functions to add and register users
or ad groups to the system and
the directory service this is what puts
everything together it's basically a key
value store its own contract storage and
it tells the other contracts not because
now we have split the contracts into
multiple pieces then you have a
directory services tells you basically
where those contracts reside
so in our directory service is pretty
straightforward just a mapping of
some byte string and the address and we
can resolve it we can register and get
the values right and we have if you can
look at this
second function here or the first
function i guess if group NS admins it
allow you to do that call that function
and then we have a resolver client here
which is basically a this is your your
name server resolution client allows you
to figure out where the contract what
what the contract you need to call is
and if there's also a modifier check
basically to say that if if I'm being
called by this contract based on its
light address or is but it's byte string
then allow me to go and do what I want
to do right so
sorry
sorry so directory service
so here's a resolver so here's the the
meat of this this whole talk really is
the ICS pattern at dicks so here we have
the TX origin this is the entry point
this is your attack surface and this is
where you would look at where a
malicious person would would attack your
your application right so you have your
group access control and you have you
have your int injects we have like
different interfaces for different roles
on the system and the directory service
boss tells those contracts where to go
next and
you have the storage at the bottom so
the storage basically if you look at
this this design you can basically
easily change these contracts and update
them and add new functionality or fix a
bug by just actually changing the value
on the resolver so the only thing that's
really difficult to change our the the
storage contracts because that's where
all your state and previous state is on
there so if you have a token contract
and you have your ledger information on
there then that's kind of difficult to
change but there's ways and thank you I
think it kind of information for where
people can find more information so um
yeah so this is basically a call to
action for people to contribute more to
like these ideas so you can reach me at
last
that's my contact information slack
reddit Twitter take a screenshot Thank
You standing thank you very much
[Music]