alright great my name is Nikolai I'm
here representing Nexus developments
where a athyrium R&D shop and
consultancy and among other things we
publish open source software to help
other developers what I'm going to focus
on today is called dapple so it is Apple
dabble is a developer tool for people
targeting the etherium virtual machine
it's a collection of utilities that are
mostly loosely coupled but they all
center around a common data model which
is one of our major key innovations from
my point of view so I'll go through all
these real quick and then I'll go into a
little more detail the main thing is
this shared data model which we call the
DAP file and it's a basically a
descriptor for both code packages and
also deployed systems and then chain
forking creating local chain Forks and
then having modified evm behavior on
those local chain Forks these three
things together like you do some really
interesting things and in particular the
entire like development workflow of
creating contract systems that talk to
other contract systems kids really a it
helps a lot to how these features so let
me just go through you should use again
the first thing is that the key insight
that drives this first innovation is
that if theory em land is slightly
different from most of the other you
know programming language environment
worlds because in a theory i mean we
actually all share a global runtime
environment and so this blurs the line
between something that's a code package
and something that's it like an instance
or like a deployed code object so this
would be like if you hard code like a
web endpoints into your JavaScript
package or something that's considered
bad practice you want it like separately
how to depend on a configuration where
there you configure your endpoints and
then have all that logic in your code
but in a theory immunes like say the
ether token wrapper which is stateful
it's a deployed object that you interact
with but it's also not there's an
absolutely no reason to redeploy
everyone should be treating it sort of
like a library like you know you have
the math library on a theorem everyone
uses the same address or in theory we
should be doing that for the math
functions likewise we should all be
using the same
package for like the ether token wrapper
which creates it into an erc 20 token
but that hasn't address in it that's
part of the definition of that code
packages that there's an object deployed
so yeah so this is an example job file
don't worry about it too much the key
thing is this highlighted thing which is
that the the type information is very
rich it has all the metadata we need to
just fully recreate how this thing got
here so the next innovation is chained
forking you'll notice it's a user
experience very similar to get that
because they're very similar data
structures the missing part here is
merged because there's no analogue to
resolving merge conflicts automatically
when you try to replay Center
transactions and it doesn't have the
same result so that's chain forking and
finally okay this is an example of
basically you can actually fork any
public athyrium chain without their
permission basically just because of how
the data structure works but by default
we let you specify remote one and
internal just means a brand new blankie
vm on your machine and for QVC and where
it should be self-explanatory and
finally EVM extensions are when you
slightly change the behavior of the
virtual machine on your private chain
and this lets you do some really
interesting things as you'll see so now
let's go through the workflow how have
we developed apps using double first
thing find some dependencies this is
like a habit that you have in every
other language for some reason everyone
wants to start from scratch from there
creating their own contracts this is our
as a hint so we suggest that we have
like something like sort of like a
standard library which we are keen to
get formally verified and it has a lot
of stuff like Roxy actors tokens by the
way you can read the list I'm sure the
other ideas that these are like
composable building blocks each is very
simple and easy to verify and then you
actually most apps can be built out of
just a collection things like very few
like each DAP that each new system that
we make usually only has like one or two
contracts with custom logic and then it
has like five dependent contracts that
are just things we've built before so
again yeah if you're interested in
formal verification this is a this I
mean these again it's very simple
contracts but they are in production
systems right now in multiple systems
like nothing in here is something that
hasn't been
used so the next step is building and
linking which is boring but it's worth
noting that solidity has no name spaces
and this is kind of a smell that our
contract systems haven't really gotten
that complicated yet maker core for
example has four different deployed
abscess versions and being able to
reproduce and compile without having
like type name collisions requires us to
have a custom linker so we're going to
maintain that until solidity gets
namespaces so after you've written some
contracts and you've built them you
obviously want to test them and our
perspective on this is that the primary
consumer of contracts is other contracts
and so we emphasize writing your test of
solidity pretending your other contracts
in communicating with it and for this we
have a magic test contract where it has
an Associated harness that understands
how to interpret the functions defined
on it so this is our first example of a
chain for key so this this is an example
test if you use any unit testing
framework another in other languages
this should be familiar setup gets
called every time and then if you have
multiple test functions they each get
called an isolation so our first example
of a using chain forking this is a
suppose we did Apple chain new and use
and we specified the internal vm which
means like a brand-new fresh EVM then we
deploy our contract to it call setup and
then concurrently we can fork it and
then run each test independently so
that's nice but we really wanted so like
part of the value of dapple is that we
can take these dependence systems and
make a very accurate mock of them and we
preserve all the type of information you
can be very certain that the behavior
will be similar on the live chain and on
your fake local chain but you might as
well just use the real thing I mean it's
even better so in this example basically
you write a test and you assume that the
contract is running in the context of
like a chain but you can do more stuff
with it in your private context that
lets you test a few more features so to
give a concrete example of this if you
run this in the Morton context this will
work but if you run this on a private
internal
this won't work because you know unless
you burn some ether first so I should
have like written the usage behind this
but basically what happens is first you
enter the answer the Morton context and
then you do dapple test on this contract
and the result is that it works this
address zero refers to address your own
morden and so when you assert that the
burned balance is more than zero it's
true all right so testing is kind of
interesting but it gets really
interesting when we want to deploy
contracts which is one of the
applications of what we called wallet
side scripting which is another magic
EVM contract but it's harness has
hijacked that creates and call off codes
and makes instead what usually when you
have payer call it creates a message
costs like internal to one transaction
but instead what we do is actually
create a full transaction and then block
the wall outside EVM execution until it
gets confirmed you combine this with the
chain forking feature what you can do is
simulate live deployments before you
actually do them do dry runs and then
you can run consistency checks on the
results of your system like make sure
that you're up the update that you want
to do it doesn't screw anything up so
here's a real world example of like we
want we might want to do this you're on
slack and you get a message for me that
says hey please confirm proposal 66 it
is a critical bug fix it's going to swap
out some of the contracts this ones that
have don't have this book so if you're a
responsible administer of multi sig
folder of whatever system you're running
you will of course do a mock chain fork
and run this transaction a simulated
environment to make sure that it still
passes whatever consistency checks you
guys have defined in our case let me
show you the example so this is why this
this type information preserving this
type of information in the default is so
powerful is that then we can hoist it
into the wallet side scripting
environment and have the full type
system there with all the type of
immunities to make sure that this you
know what you're doing makes sense
there's actually a token defined in the
environment it's actually typed as a
token it has a confirmed puncturing blah
blah blah and so in this case what we're
doing is we're confirming it's from our
address but then we're fit
tending to set the origin to a different
address which is one of the magic
features of the script contract so that
the origin is mocked then we do a
confirmation from that origin and then
we show in this example to confirm also
does the trigger so the update runs and
then we do a consistency check and in
this example you can see our maid of
consistency check failed so you know
that this wasn't actually me this was
some hacker that is trying to run a bad
update on the system but each multi sig
member can easily independently verify
what the resulting state of actually
running those transactions are all right
and then the final step is publish your
job file yet other people to import your
code and have some code reuse because
there's so much duplication of effort
going on in the ecosystem right now is
partially because it's just so hard to
reuse other people's code so I'm going
to very quickly give very small sneak
peak about what are some other things
that are coming basically all the things
I described could be done in a GUI so
you could you know do your own the Dow
hack through a through a clicky you I if
you want to let's and then some more
things that we have in the pipeline a
better more wallets I DVM extension
features so one thing is uh having one
of the addresses be like a hard-coded
contract which is a thin client and so
this is call i call it DIY sharding
basically if you have to private chains
you can make up your own interpret and
communication scheme very easily if you
have the thin clients for the other
chain as a like EDM extension or like a
hard-coded contract likewise creating
like a mint opcode would allow you to
write your private chains consensus
mechanism in the evm and finally system
calls allow you to bridge the old world
web with the new world you know thin
proofs for everything and you can have
like a dedicated side chain that say
does SMS relay like this is the example
we have right so it does this it does
SMS n but it might inside this function
and it emits an event and this is like a
proof that this company claimed that
they sent an SMS at this time in
response to some action that use it and
so this is the general direction we're
moving towards and so that's actually
only
to talk about thank you for listening
let's go to lunch