[Music]
let's see hello everybody I'm Piper I've
been working on a lot of things in the
etherium ecosystem since the frontier
network launched and today today I would
like to talk to you about packaging up
smart contracts
so first let's establish what we mean
when we say package management Thank You
Wikipedia package management system is a
collection of software tools that
automates the process of installing
upgrading configuring and removing
computer programs for a computer's
operating system in a consistent manner
hopefully that's the last reading from
my slides I want to point out the part
here that says that it is a system it's
a collection of software tools so we're
not talking about one thing we're
talking about specifications and tooling
support and all of these things coming
together to allow us to package up a
smart contract system so let's take a
look at what a smart contract package
actually is so at the beginning of this
year myself and a number of other
framework developers came together and
we hashed out what is referred to as ERC
190 this is a spec for how smart
contracts can be packaged you can find
it in the AP's repo as well as in a
dedicated get github repo for this
specification so what Air c90 specifies
is a format for a JSON document it
allows for all of the rest of these
bullet points are effectively the same
thing it allows for you to create a
package that allows other people to
deterministically rebuild the assets
from that package to verify on chain
assets or assets that are included in
the package and the packages themselves
are designed to be immutable which means
once you have a reference to a package
that thing can never change out from
under you package because the packages
ERC 190 packages can include a number of
things full source code for the source
files assets that have been precompiled
ABI for contracts that are included the
addresses of actual deployed assets on
the blockchain and as well as sort of
nitty-gritty data like link references
when people are using things like
libraries from solidity so that you can
actually do verification all the way
down the chain we also covered a number
of use cases so base things like
reusable contracts you can think of like
the ERC 20 contracts that ship with the
Zeppelin OS sort of normal common
patterns like the owned pattern as well
as live contracts deployed instances
things like that we also made sure that
we covered both the theory of main net
case which is a place where we don't
want to have to trust things and we want
to be able to verify everything as well
as stuff for private chains places where
you're working in an environment where
Trust is okay where potentially the
packages that you're using are all made
by you so you are happy to just trust
embedded byte code in them rather than
verifying that that matches the source
code so let's look at some examples of
what a smart contract package actually
looks like this should be familiar to
anybody who's worked in solidity this is
a very standard pattern I'm sure that
you can find almost this exact contract
in hundreds of different code bases so
this is what I call an inheritable
contract this contract is not really
useful on its own but it is useful when
when you when you inherit from it and
make use of some of these modifiers this
is a very simple version of what this
package looks like
is a JSON document it defines a couple
of bits of metadata and it uses a
content addressable URI an IP FS URI to
reference the actual source code and
then if you pipe that lock file from the
previous version by the way IU we use
the term lock file it's roughly
interchangeable with package then this
right here is the actual IP FS URI for
that package and in theory with a
supporting development tool you can take
this and use it to install the owned
package now that's a very ugly reference
to own it's not a very nice URL way to
install things so we'll talk about that
in a little bit here so we have a source
file we have this lock file which you
can also think of as a package and then
we can reference it using its own
content addressable URI so let's look at
what dependencies look like so we can
actually extend the owned concept with
this transferable contract it depends on
the previous example and this is what
the lock file is gonna look like for
that package it references the other
lock file using the build dependency
this build dependencies key which makes
the the entire dependency tree immutable
because everything is using content
addressable your eyes we can move on to
things like ready-to-use contracts like
a ready to go
er C 20 contract that can just be used
right out of the box here's some we've
got two source files here that that are
the an abstract version of it and the
actual implementation and in this one we
actually include some information about
the contract types themselves we say
this includes the standard token
contract there's maybe some meta
information included with it like the
ABI that allows people to use this
package to interact with it
and we can also include bits of extra
information like the compiled bytecode
and the information about the compiler
that we used
to actually compile this no this is
where we get into different use cases if
this were a package I was using on the
main net then what I'm gonna do is use
this compiler information to recompile
this and verify that the included
bytecode does in fact match the compiled
output but in a trusted environment we
can actually just use the bytecode
embedded in this in this package cool so
now let's look at what it looks like if
we have a smart contract that's been
actually deployed to the blockchain so
this is a safe math library it does some
underflow and overflow protection and
this is what it looks like to package up
a smart contract that has a live
deployment so we have references to you
can see this blockchain URI up here this
is how we reference what chain this is
deployed to this is also how we support
deployments across multiple chains this
means that we aren't locked into
something like just supporting the main
net or just supporting Rob's tenoram
predefined set of them you can use this
for private blockchains for local test
chains anything like that and then
within it we actually get a reference to
you know which contract did we deploy
what address can I find it at and then
we've got some convenient stuff which
are the transaction that it was deployed
with or the block that it was deployed
on again these are things that are easy
to verify but they're convenient to
include in the actual package so with
packages we it enables a number of
things that we can actually do with
these the most obvious is just using
them in our code a tool that supports
these packages in theory you run some
installation command you can see that on
the upper left on the upper right here
this is what likely results in our file
system this should be familiar to people
who are used to node development this is
much like the node modules directory and
then from within our actual code we can
import these and use them but there's
some really cool other things that we
can do so this is the
interface from ether scan for how you
verify contracts and anybody who's ever
tried to verify a complex set of
contracts knows some of the pain points
of this you have to munch together all
of your source code into one file you've
got to pick the exact right compiler
version you've got a reference if you
want to verify multiple contracts you've
got to go through this multiple times
smart contract packages can replace that
entire thing with just a single upload
since packages include enough
information to verify everything instead
of having to manually put all of that
information in you could just upload the
lock file and either scan can
automatically verify every deployed
instance of the contract included in
that package I also think that this
would be useful in wallets this is a
pretty common interface for wallets give
me the contract address tell me what the
ABI and then I will generate an
interface and you can interact with it
this is often sufficient but it leaves a
lot of things desired because you don't
really know what you're interacting with
you don't know if it's been verified
that's sort of sort of thing if we
replace this with with a package where
you upload a package wallets can still
generate the same interface but they can
also show you a lot of extra information
such as yes this does actually verify
whenever I recompile the source code and
check it against the byte code or or
there is not enough information to
verify this or it can even just let you
browse the source code but this right
here's my favorite idea come with me on
a journey to the future where the EVM is
everywhere where there are packages for
all kinds of things and where the EVM is
really fast so I think that EVM packages
are capable of being a cross language
packaging system and what I mean by that
is that we can actually use the EVM
implementation natively in our code this
is sort of an imagined
the Python library here that makes use
of some mystical sha seven package and
rather than needing and implementation
of sha seven and python instead we use
the EVM implementation in our code and I
think that's really powerful because
that means that we can have single well
tested battle-tested implementations
that are then usable across many
different languages so let's talk about
the standard library so to talk about
the standard library I actually want to
back up and talk about packaged indexes
this is sort of the like default state
of the world right now is that packaged
indexes are centralized there's often
sort of one centralized system that
handles all of the packages for an
ecosystem we've got NPM we've got pi PI
we've got whatever else is out there but
this is what I'd like I'd like everybody
out here to have their own packaged
index and that is actually really easy
with the ethereum blockchain so with a
with a reusable implementation of a
packaged index contract a contract that
manages tracking versions and tracking
what packages are available that plus a
little bit of tooling integration
combined with ens means that we have a
very easy system for every team to set
up their own packaged index where they
are in full control of all of their
packages now how this relates to the
standard library so and and this is a
theoretical way of how you would install
this we've got the part on the Left
which is handled by the dev framework
and the part on the right which is the
namespace piece which is handled by ENS
so our ecosystem might look like this
maybe I've deployed a couple packages to
my index maybe the Maker Dow teams and
deployed a couple there maybe zeppelins
got some there and there's some overlap
right like I've got my own version of
owned up here I hope that one doesn't
overlap safe math I've got my own
version of safe math on my side
Zeppelin's got they
and the idea here is that somebody can
then come along and pick and choose out
of each of these different indexes which
ones they think need to come can come
together to form one rich reusable
standard library and well it's great
that we all get different packaged
indexes and we all have our own packaged
indexes I think that's the way the
standard library can work - it can look
a lot like Linux where there's different
flavors of the standard library where
there's different curators and different
people who've picked and choose which
packages from which place they think
make up the best standard library which
means we're not stuck with one packaged
index we're not stuck with one standard
library but we actually have a lot of
choice to pick and choose this can be
thought of sort of as the spread a bunch
of seeds and see which flowers bloom but
I think this has some is very promising
for a rich ecosystem of packages so what
do we need to make this a reality um so
right now we need more support for erc
90 and tooling populous has some basic
support in it same with truffled but in
we need more tools to support this we
need a standard implementation of a
package registry something that we can
ship around in those tools so those
tools can set them up for us and then we
need automation for setting these
registries up and that's both automation
for deploying them as well as automation
for getting the ens piece tied together
and we need a feature request into
solidity and other EVM languages to
allow us to inject pre-compiled byte
code into the compilation process and
the reason for this is that as our
package ecosystem grows we're gonna have
many different versions of solidity that
are required to recompile certain things
and in order to require compile a very
complex dependency tree that has lots of
different versions of solidity we're
gonna need to be able to compile all
those individually and then slowly
combine them together into one big
compiled asset so there's gonna be some
compiler or if it has to be done but in
general most of these pieces are at the
80% mark or more we're very close to
this and all of this is about ready to
come together thank you
[Music]