[Music]
hey everyone thank you so for those of
you who don't know us at sapling we
build technology and provide services to
help protect smart contract development
we're mostly well known for our security
audits but we also have some products
and we maintain the open sapling repo of
smart contracts so this talk will be
divided it first I'm going to review
last year since DEFCON 2 in terms of how
the smart contract ecosystem evolved I'm
then going to focus on some new
techniques on patterns we've seen
arising in industry that I'd like to get
more visibility to and finally I'm going
to talk about some pending challenges
it's my contract security and hint into
some possible solutions were working on
so let's start with history the dark
ages so 2016 was a pretty dark year for
smart contract security we've seen some
pretty embarrassing hacks in the space
most of you probably don't remember many
of these except for the Dow but just to
get a sense of how the industry was at
that moment I want to focus on one of
them specifically which is Rubik's II so
Rick's it was a formalization in a smart
contract of a pyramid scheme the
original name was dynamic pyramid but
apparently the developer didn't think
this was a good name for marketing
reasons so he renamed it to Rubik's II
which is much cooler but he forgot to
rename the constructor and this male
this made it turn into a public function
because that's how solidity works so
anyone could call the dynamic parents
function and become the owner that's
gaining gaining the ownership of the
contract and being able to steal the
fees from the contract so this seems
like a dumb mistake but the same feature
from solidity probably cost the party
wallet hack which happened recently and
cost like 30 million to be lost to
hackers so in in in May 2016 a picture
of SNS wrote a great
girl calling the community to gather
around a building best practices for
smart contract development and one month
later the dalek occurred the contract
held roughly 15% of all ether tokens in
existence and fifty million dollars were
lost and at that time the only solution
at the moment was to hard fork the
protocol so a theorem had to hurt fork
which in turn brought a lot of
complications and security problems so
it was not a good outcome in the end so
at that moment the the the community was
pretty aware that we need to ramp up our
security practices and three months
later on September we launched open
sapling as a community effort to gather
around
auditing contracts creating better
security practices and actually gather
some smart contracts called to share a
week later I was in Shanghai for DEFCON
2 and everyone loved the idea many
projects wanted to gather around open
sapling and help these contracts and
since then the project has been growing
quite a lot for the past three months we
had more than 8% a weekly growth which
is the hockey stick figure every Silicon
Valley entrepreneur wants but the truth
is we built something that everyone was
wanting and the industry grew a lot say
since then so it grew with the industry
apart from the community building better
tools for smart contract development in
Syria massive platform evolved a lot too
we've seen the consolidation of the
various standards like they are seat 20
proposal that turned into a IP 20 for
tokens standard also the platform fixed
some security problems like the nasty
call stack attack that was possible
before and after AI PE 150 it's no
longer possible also solidity the the
most popular smart contract language got
some cool new features in terms of
security
the payable keyword that allows to set
when a contract can or cannot receive
money require an assert that are really
useful for setting the preconditions and
postconditions
of our functions transfer which is a
safer way to send money from our
contract revert to cancel execution of
our function without wasting all the gas
Purim view which are the evolution of
the constant keyword and allowed to
specify if a contract if a function can
or cannot read or write state from the
contract we've also seen the death of
serpent as a language after a knowledge
within which in which we found eight
pretty serious vulnerabilities which led
us to find critical vulnerability in the
rep token which allowed any attacker to
freeze the contract forever and male
made them have to me migrate the rep
token to solidity the serpent language
was deprecated after this tweet from
metallic and now although all the
efforts around and an alternative
language are focused on Viper which is a
serpent successor and it's pretty cool
so you should check it out it's not
production ready yet but I hope it gets
more attention and more recently with
the Byzantine heart fork some
consequences on on security are the
region of begin sugar modular
exponentiation which allows RSA
signature verifications we'll see what
people come up to with this new tool the
asian of the static called opcode which
enables safer calls to untrusted
contracts because it makes them not able
to modify your storage and the asian of
up codes for data handling and revert
the river top code allow for much easier
and Tyler ways of implementing upgrade
ability proxies which is an ongoing
discussion topic in smart contracts
security so that's what happened and now
I want to focus on some new techniques
and patterns we've been seeing on our
audits and work with opens happening oh
can you see that ok let's say you're a
developer running solidity so you create
your own you RC twenties all come for
fun by using open selling you can do
this pretty easily with like ten lines
of code so you think you want to add
something that sort to make
talking cooler just for fine you think
you want your token to have an extra
functionality of being able to lock
funds for a certain amount of time and
you want to add a little extra gold as
possible so a way to do this is to add a
lock function a public lock function
that instantly transfer the tokens but
then stores when those tokens should be
released and then modifying the standard
transfer functions to make them honor
this new extra restriction on that so
let's see how this would look on coal we
had this I don't know if you can see
this but you had this a new log function
which basically calls the standard
transfer function and then adds in a in
an array of blocks for each address when
those funds should be released and then
what we need to add to that is
overriding the standard transfer
functions adding this extra restriction
where which via DS can transfer modifier
which checks the amount of transferable
tokens at a certain point in time and
enables or disables the transfers and
then to implement this a transferable
token amount what we do is we iterate
over the array of locks for every ad for
that address and we add up the amount of
locked tokens and we we return the total
balance - the locks oaken's so in this
way apparently we added a cool new
feature to our token and it seems great
but it actually has a big problem
did anyone can even tell me what the
problem is
good good you want a t-shirt so we have
a case of a gassy array as we like to
call it the problem with this array is
that the length of it is controlled by
anyone that can call the log function
which is in this case is public so you
need to see the length of the array as a
user input and as you know in security
you need to sanitize inputs and any
anyone can call the log function and
create lots of locks in the array of of
someone they want to mess with and the
array if in this case I tried it and if
you
like 5,000 logs to Anna to an address
the gas cost of calling a transfer for
that token is so high that it doesn't
fit in a block so the point here is I'm
sorry by adding an extra feature we
actually introduced a security
vulnerability so there's a simple fix
for this which is adding a an upper
bound to the amount of logs for every
address but I wanted to make you think
about a different approach to adding
features to a tokens which solves this
problem in particular and I think it's
better for security conceptually so the
idea is to leave the token assist don't
any extra functionality and actually
implement the the locking functionality
as an external contract so when a user
wants to lock tokens for another they
instantiate one of these new token time
lock contracts which received the
beneficiary address and the release time
and then transfers the the tokens
manually from the from the normal token
contract and now if in this case the the
previous vulnerability with legacy array
was solved but if there were one
vulnerability in this new contract only
the users using this extra feature would
be affected whereas with the previous
version any vulnerability potentially
could affect normal users that didn't
want to use the lock function so this is
one of the patterns with sin in terms of
improving security in new function
design and the point is when you're
thinking about adding new features to
your contracts really think about the
security implications not always having
more features is better because you
increase the attack surface and for
another example of how this has been
implemented in the industry at the
beginning of the year most crowd sales
were implemented as part of the token
code and now most most crowd cells are
implemented as a separate module so it
if you think about it doesn't make sense
to have all the crowd sale code in the
token forever for just two weeks or two
minutes of course he'll finally this I
want to talk about some the relation
between basic security software
engineering practices and more
under security these are very simple
stuff but they are not being applied in
in our industry and I think this is
basic stuff we should be doing
so first is clear and simple code is
always better for security while
security problems come from a difference
between the programmers intention and
what the code actually does so having
clear code makes it easier to check the
programmers intention and that the code
actually does what he wants a corollary
of this is that naming matters have seen
really really bad naming in many
contracts so please take your time and
think about naming because it helps
increase the security of your code reuse
existing audited call there's plenty of
good libraries out there you can reuse
there you can't imagine how many times
we reorder at the same re-implementation
of GRC 20 standard tokens also don't
copy paste code because if the code
you're using is updated you don't get
the updates and also don't repeat
yourself
that's also a source of bugs and finally
and most importantly write tests that's
the best way to check that your
assumptions about the code are correct
and also if you change the code after
the fact you can prevent regression
errors so as I was saying all these are
basic security
I mean software engineering practices
that every developer should be doing but
in our case our code manages real money
so we need to protect it from ninja
hackers stupid users and other
developers in our team
so I want to talk briefly about the
relation between security and trust
reduction let's say you're a freelance
solidity developer and your client
requests a cupped crowd sale so you
write this simple contract I think he
comes and say oh wait don't forget we
need to create tokens for the foundation
to when the crowd cell finishes so you
go sure boss
you have you make your crowd sale
ownable so it has an owner and a
privileged function to mint the
Foundation's tokens
once the cup is reached so
only if the cup is reached will it mint
tokens but then your client comes back
and says oh wait but make it trustless I
don't want to be the owner so you remove
the privilege function put it into the
buy tokens function so that the last
investor when the cup is reached means
the token for the foundation this is
better right it's more trustless wait
now an investor can come after a cap is
reached and with this particular call if
the message value equals to zero they
can continue calling this buy tokens
getting zero extra tokens but remaining
tokens for the foundation ruining the
crowd sale the point here is it's not
always good to leave critical when I
relate a critical functionality of your
contract in the hands of the public it's
sometimes ok exactly sometimes totally
ok to live really critical stuff from
your smart contract in the hands of an
owner especially if they if the
investors or users of the contract are
already trusting the owner in some other
way like giving the money I wanted to
say that so I want I want to end with
some open problems that we see in the
industry and some ideas were working on
to solve them I briefly touched upon
some of this but one of them is
upgradability or both in terms of how to
upgrade a smart contract once it has
been deployed to the network for like
bug fixing or adding extra features
interoperability it there is contracts
calling them each other the gas costs of
how contracts interact within each other
and code duplication in the blockchain
so we recently announced our sibling OS
project which tackles these four
problems and I'm gonna tell you how we
do that how we plan to do that
so for code duplication basically what
we're going to do is turning open
sapling the library into a non chained
library were applications kind direct
directly connect and Link contracts to
their own chain version to reduce the
the payload that needs the white code
that needs to be uploaded to contract on
chain and all the other
that are reusing open civilian standard
token implementation they can share the
same code on chain and release the gas
costs of deployment and reduce the
amount of storage needed and this kernel
will also have an upgrade ability
mechanism a via the delegate proxy
pattern so that we can do upgrades to
this kernel of really core and important
modules from the ecosystem so we find a
bug or or we need to improve some of the
code from from those core libraries we
can do so and possibly fix a production
code from some contracts and of course
this business a governance mechanism
because a nobody would use some
something that is in the hands of a few
developers which upgrades are approved
and by the way we we did this the
technical research for this we did with
the Oregon guys and they've been using
the same idea on Eragon OS so you might
want to check that out too and to two
other components of the OS are the
scheduler and the marketplace so the
scheduler solves the gas the gas problem
of smart contract interaction and it
comes from the idea that when two
contracts interact if you think about
who pays for the gas price for those
interactions for example a typical
example nowadays is a multi-state
contract controlling a crowd sale
contract some privilege function for
example finalizing the crowd sale if you
think about it the first let's say you
have three of five volt EC the first
owner proposes to make the call the
second one signs it off and when the
third one signs it off the actual
operation is executed
another gas cost of executed that is
paid by the third or the last owner of
the multi C so with the scheduler we're
building tools to enable contracts to
request a synchronous operations in the
future so a multi could gather all the
signatures and then request someone else
to do the actual execution of the
operation so with a couple who pays for
gas and who is actually approving the
calls
and this same mechanism also allows for
a synchronous programming in general not
just this this thing this thing is gas
but enables a smart contracts to to
request operations in the future and for
the marketplace we are standardizing the
way contracts interact with each other
so we think that there's a bigger
potential for smart contracts when they
start interacting more and we see an
ecosystem of contracts interacting and
we're standardizing the way a contract
can expose its services in terms of I
this contract offer this API call for a
monthly payment or a one-time fee and
you get access to everything or a per
call fee and finally part also part of
sibling OS is a set of of chain tools
which we call the smart contract SDK
which are basically CLI tools and web
applications to manage easy more easily
your contracts so you can know know more
about this it's a completely open source
project we encourage everyone to
participate in by giving ideas and cold
and we can talk about more about this
later
finally we're not yesterday we launched
solidity culturally flag contest
we're giving away 10k in prices it's a
hacking contest like there's a couple of
contracts you need to hack to advance
the next level so if you want to check
it out and it's it's fun and that is all
thank you very much
[Applause]
[Music]