hello yeah hi everyone it's so exciting
to be talking to all of you here at Def
Con I'm especially talking after dirty
and all the incredible efforts that they
have been doing with UI hat
so yeah I'm Jorge I'm from the Argonne
team and kind of to start framing the
talk I will talk a little bit about what
with Aragon is so Aragon is basically a
decentralized organizations platform
built on a theorem we build the software
and the infrastructure so running
decentralized organizations can become a
reality and we are doing this with like
focusing on like non-technical users or
people that might not have heard about
the theorem as our users so we're very
careful that they will be able to use it
and also it's very important for us that
the system is extendable enough so it
can be used for very like large-scale
systems but also for like more tiny
things so when we talk about like
future-proof smart contracts what we
really mean it's like how can we make
sure that the contracts that we're
building today for these organizations
are going to stand the test of time and
can be used by organizations for many
years so these are kind of like three
very obvious points but the the first
one is like the damn contracts are the
best buy contracts and the what this
means is like the easiest and the clear
Edina smart contract is that better for
because everyone will know what are the
implications of every action and also it
decreases the the attack vector for for
it also something very important for us
is like to make sure that we only do in
the smart contracts the minimum amount
necessary for the system to work and
this is also because this this course
will be paid by your users and this will
be the baseline for costs for usin
Aragon and also the Third Point and the
one that I will spend more time during
the talk talking about it's like we
really feel very strongly that's my
contracts need to be upgraded and this
is kind of like a controversial point
because there
many things I could go wrong with my
contract separate ability the first
thing is like we're building this
awesome like trustless systems but if we
put one entity that can arbitrarily
change the rules of the game well
everyone is doing it we're basically
having like these trans folk on
contracts again but of course we would
see like what were two paths to
upgrading is and also there's this
interesting attack vector that could
happen in which someone could front van
like a very important transaction to a
smart contract by doing an upgrade what
this means here is like you may be doing
a transaction expecting that the system
works in one way but before the
transaction is mined and half way to is
my contract happens so this is something
to take care of
so anyway why do we need smart contract
operators
it's because like as we all know this is
an extremely young technology and there
will be probably backs that are better
solved at the contract level than at the
protocol level and also like we're very
young so there will be probably need to
upgrade our contracts for adding
features either users requests in the
future doing average right is something
that we are very passionate about at our
gun and I think these are also like very
obvious points but it's very important
that these my contact cap rates are not
controlled by just one entity and a very
important point is if they are
time-delayed people can then explore the
new contract and decide what to do with
it and also having an efficient
governance process we before doing an
upgrade this is very important so in
this road of doing like this better like
and future prismatic contrast we kind of
started early this year focusing a lot
on the solidity libraries approach the
solidity libraries are great because
they allow you to really isolate
different logic domains that your
contracting I have but something that we
found is like the problem with libraries
is that they're linked at compile time
so you cannot really operate them after
doing the after after deploying your
contract so we work with the sapling
guys on
doing this approach to operate in solid
like solidity libraries what how it
basically works is that instead of
linking to a specific version of when
library we would link it to a proxy
library that would then dispatch the
delivery call to a to T correct my
contract this was interesting because it
allowed us to change the business logic
after the contract was deployed by the
problem with it is like it didn't allow
us to modify this my contract avi1 see
what's avoid so it's not possible to add
any functions to the contract or to like
change one of the function parameters
and also the data structures that you
have are going to be fixed forever so
this is very interesting for solving
business logic PACs but it isn't as
flexible as we would like like it to be
so with this in mind we were - we went
to even simpler approach that we call
the delegate proxy but like how it
basically works it's like instead of
having your contract logic in your
contract you delegate this contract
logic to a different contract by using a
delegate call this code is specially
better with the with after device and
Jim Hartford by when the EIP 211 good
code included because right now it
allows us to by using the return data
size and return date a cop in Europe
codes we can check after doing a
delegate call or whatever call we can
see how many bytes did the underlying
call return and then return that many
data because before this you kind of had
to specify how many bytes you were
expecting from the call and for function
calls every turn dynamic data types this
wasn't really a good idea and using this
technique they're like two things that
we can do here which we call like
flavors but they're like based on the on
this same idea the first one is like
this was introduced by Vitalik and we're
ready post back in back in the summer
and it's a div of stagger D is static
forwarders so it doesn't really solve
the availability feature but the idea is
like we can deploy these very very cheap
contracts this is actually an
implementation it they are so simple
that this
plantation Western directly Navy m-code
so this allows us to really put like to
deploy clone contracts of one contract
for a very tiny amount of of gas and
this is actually the desolated
implementation done with the from the
code that that we before so these are
like very very cheap to deploy contracts
and it's like as you can see it's very
trivial deploying with this is like for
every call to these contracts we add an
overhead of gas because we need to do
this this delegate call so for example
this is not a good idea for a talking
contract that gets interacted with in
many instances the gas course is like
700 gas for every additional delegate
call that we have to pay in every in
every call but in the flipside we get
very very cheap contract deployment
costs so for example for a contract that
takes 1 million guys to deploy the
moment that we do more than 1300
contracts called duties contract it will
no longer be worth it in gas wise to do
it but for example and an example of a
contract that I think it's a perfect
example to how these can be used is with
the en STD contract that gets basically
created every time an SPD is done so
with this contract if instead of
creating a full contract with with its
code that gets stored into the
blockchain every time we created a proxy
contract like this this would have been
the biggest savings would have been very
very significant and I think this is the
perfect example for this because the
contractor gets deployed many times but
gets used individually very little times
so with this same idea we can like if
instead of these at Rice that we're
doing the call is being a constant if we
make it flexible and variable we can
actually do a great ability in this
indecent way so here is like an
implementation of how these how this
could look like as you can see this is
also like using the code that we
presented before but here instead of
doing the dakotas the same constant
address every time we're doing it to to
add an add to an address that we can
change
so basically calling
the average function here would change
the code where the where the contract is
using the problem with this is like
because we're using delegate calls which
is basically telling the contract okay
don't run my code my contract out here I
want to tell achates to tease order
address we need to make sure that this
storage like we're in the correct
version of the storage so for example in
the previous slide we see that both
contracts like inherit the same the same
storage contract that's because they
both need to know where the where the
story is and for more more complex cases
in which you introducing inheritance and
all that you need to be very careful
with how you add the the storage so this
is actually important to understand how
solid it is historian or or data so
basically the the the it's a very simple
idea it starts counting like how many
men like storage slots do you have in
your contract starting for the from the
most basic contract so it would start
like counting like this would be stored
at the at the 0th at the cereal slot
we're talking about the these contact
storage but either inherits from this
one so these would be stored at the
zeros cloud these would be stored at the
at the first slot of the of the contract
and so on and so forth but for example
in the case of an extract this would be
like as if we put this in line right
here and distract like quote-unquote in
exercise at all the case of the case of
I race is a little bit more complex for
static length arrays like this behaves
exactly the same way but for a
dynamically length array it would put
history the the array length in the
storage slug that it would be but then
these DeRay values are stored in the in
the hash of the of the pointer in the
case of mappings is actually a bit
simpler it stores the value at the hash
of the of the key and the position so
the warnings from these is if you're
like a braiding from one contract to
another it's it's better to like know
that storage in the middle because I
guess
we saw the oldest storage depends on
what the position is inside the contract
so if we add something in the middle all
the storage would be broken and the
problem with this is like this failing
will be silent so it won't like if you
don't do it like nothing will say this
is going to break your contract but
whenever you start using the contract
all the storage will be broken so an
example of an operate that that goes
wrong is this one so because of howdy
how these tracks get starting raised we
have this initial contracting which
which we are storing instead of employee
and then we create like a couple
employees here with with their salary if
after this we operate this contract to
the spiral to contract in which we had a
new a new member to distract with this
what will happen when we try to fetch
the first the second employee salary is
that it will be stored where the
employees first with the first employees
join that is so it will turn its salary
into zero and the salary will be in to
join date but if for example we use some
mapping to store this information
because mapping stones 30 values
subsequently body from value but they're
in the hash if we do this exact same
thing when after upgrading to this
second or the second contract in which
see we track the DD employee here both
salaries would be correct but both
joined edge will be 0 because we never
we never set them so with with all these
we we are using this upgradability
paradigm in our in our own contracts we
call it Aragon OS and the implementation
is actually very very simple we have
this tiny kernel contract which actually
keeps track of all what the how all the
contracts that depend on that
organization gets stored and we
basically store all the old important
business logic in an organization is
stored in in apps that are at the at the
edges of the system in this way we can
keep the kernel very very simple
so this is like kind of the lifecycle
for a repo for a new contract call that
gets done to an hour ago os contract so
we will have the the initial call here
this will go to the upgrade to an
available proxy contract but instead of
like knowing where this code is it just
has the kernel whether there has been an
upgrade and like what what is it the
code implementation for this app when it
gets it it doesn't delegate call duty to
reveal implementation of the app in this
case it would be app zero version one
after that the app if the if it's a
productive function that it's being
performed this will ask the the contract
the kernel again oh hey can this action
be perform right now so with this system
of the AC of the access control is in
the NT kernel what we can do is we can
use these complex governance mechanisms
that you could have in your in your
organization to decide whether or not an
app which should happen so we are
protecting all the average to kernel
synapse to like this so how would that
like how would an app look like it's
it's very simple by running this app on
top of the organization let's say you're
running this county rap to check how
many icos there were today so we have
these these kind of rolls inside the the
app that define what are the different
actions that can happen inside the app
and then we just protect them here with
the alt modifier what this will do is
like this will plug in to the organ the
organization ACL and basically any
governance mechanism that the
organization has can decide who can
perform these and their work condition
and by doing this we can actually up
with the very simple and add a new and a
new storage a new storage value and like
a couple new functions and this will
work and after performing the operate
everyone that's using the app will be
and this is actually how it's going to
going to look like this by making these
very very tiny app you can plug this
counter out that you can write very very
simply
and plug it into your organization and
use it with all the all the other
features that the Aragon has yeah that's
everything for us if you are curious
about this you can contact us here thank
you
[Applause]
[Music]