foreign
[Music]
and this talks talks about like five
smart contract pattern but that's
actually a lie the real thing I want to
discuss is what I think are it's a good
mindset when writing solidity contract
and basically the pattern I'm going to
show you are more of like examples of
what I think can be a fun development
and solidity and how I think it aligns
with the good good development practices
wait
distance okay yeah so I think one of the
two main points I want to make today is
that a lot of the ecosystems value is a
result of smart contract composability
uh that's particularly true of defy and
the first thing you should do when
writing a smart contract is make sure
that you are leveraging as much
composability as possible and trying to
make sure that your contract can
interface with all the existing tooling
that would be relevant an example is
people always ask us like hey can we
make an honorable contract payable like
someone could buy it and this makes
really no sense because there is already
a lot of tooling for buying assets and
that's the nft space in the nft space
you can just buy anything from openc or
variable or any other marketplaces and
we don't want to redeploy that for for
the NF for the ownable contracts that
that exists so the idea is that when own
ability is just like the ownership of of
a contract in order to to have access to
it to some admin functions well you
could just turn that into an erc721
and and this is how you would do it
basically you can very simply say like
hey my owner is just the owner of a
specific token on an ownership registry
and I can have a normal owner modifier
for that and when I want to transfer
ownership the only thing I will have to
do is go to this ownership registry and
try to transfer as a corresponding token
no on the ownership registry you would
have to override the either approval
order function to allow that but that's
very easy to do and so here in this
example you have a basic Factory this is
actually live on mainnet and when you
want to deploy a new vesting wallet with
a beneficiary for it well here's the
beneficiary it's just the owner of the
nft on this Factory and when I deploy a
new contractor just create a new clone I
initialize it and I mean the token and
that's the equivalent of my owner if the
contracts were ownable the difference is
here my contract show up on openc and I
can basically sell it or transfer it
very easily
uh if you want to go a bit further you
can even have like a universal address
ownership registry which I think is
pretty fun because it allows you to get
rid of the minting part uh by just
saying that hey by default all the
tokens are already minted and they are
owned by the address that corresponds to
the Token ID I mean all the token ID
that matches an address in exactly smart
form and then you can just say that hey
it's not possible to burn them you would
just send them back to the original
owner and there is this is approval
ownership that I'm doing some fancy
stuff with codes but you don't need to
care about that and and this can just be
another approach I think it's nice and
it it shows creative use of your season
21s
um and another thing we use is that
ownable obviously is something that a
lot of people are familiar with but the
granularity is really bad uh sometimes
you have different admin functions in
your contract that you want to have
different access for and access control
does that pretty well access control is
provided by open Zeppelin the thing is
that access control is maybe a bit more
difficult to work with because you
cannot transfer a world you need to
Grant it to someone else and then either
get it revoked or renounce it
and so it's very nice for some users but
at the same time own ability has some
advantages so let's just combine both
let's just make a contract that as an
owner and the owner is basically the
default adminual and then you just
cannot Grant or revoke this default
admin order because that's controlled by
the ownership part but the owner still
is the admin so it can grant any other
one and this here it's ownable but it
could be the ownable registry official
just before so you could have a contract
whereas the owner is the nft orders and
then you have all these access controls
that are managed in that way or you
could be creative and use ERC 1155s here
and so yeah that's that's just some
small ideas but it's not very complex
good I think everybody can understand
that but the point I really want to make
is that you can combine tooling together
and combine contracts to make sure that
everything is as
basically as seamless as possible the
second thing I want to to present
quickly is that the ecosystem is
constantly changing and and basically
when you write a contract I mean you can
make your contract upgradable but even
without the upgradability part you
really need to care about what is going
to be the life cycle of my contract and
are there Small Tricks that I could use
that will make my users life better in
the long run and that's for the users
but also for like the UI designers or
and basically anybody in this space so
these are just two small pieces of code
like 0.4s and five that I came up with
very recently and I think that's that's
things that are are interesting because
we never expect a hard Fork to happen
until it actually does and people start
trying to do a proof of work blockchain
and then the bridges that are on this
proof of work chain starts breaking and
that's a pain
so you could imagine having this very
small piece of code here that basically
takes no size on on chain that just
gives you two modifier that verifies
that the chain ID that you're currently
using is the one that was registered in
immutable storage when the contract was
deployed and then you could do that to
create some kind of bridge where
actually most of the function remains
completely trustless with this only
initial chain modifier but if for any
reason uh there were to be hard Fork the
version of the bridge that is on the
chain that changes the chain ID then all
those would be automatically disabled
and you get into recovery mode when some
like multisig would be able to take over
and this multi-seek is not a threat for
the user on the legitimate chain because
because of this only fork chain like
this admin cannot do anything nasty to
your users but that's that's a mixing
point that would have saved some pain I
mean it wasn't the proof of work chain
so maybe we don't care a lot but who
knows maybe there will be more
legitimate Forks at some point in
ethereum's life cycle
and another one is that that's something
we provide as open the screen and that's
what we call the multi-code contract and
that's very simple it's just one
endpoint one small functions that allows
you to delegate to yourself with an area
of data and that's very easy for you to
integrate into any of your contract and
I don't think there is there is any
reason not to do it and the way it's
being done is earlier we saw this
example here and here you have this
multiple that maybe you didn't see
because it's red on black so it's not
really visible but what it allows you to
do is when you went to create a new
vesting for one of your investors or
someone when if you have 10 or 20
investors maybe you don't want to do 20
transaction that do 20 calls to this new
wasting function so what you do is just
that you encode like you have a map of
entry and you record the function using
like e server.js or F3 of whatever you
like and then you just have to do a
single call so there is a single
transaction here that you have to wait
for in order to do it will basically
run like all these these operations so
deploy Trend investing at a time or you
could do an approve and some something
else or you could batch transactions
together like you don't need to wait for
Icon abstraction to batch transaction
you can already do it at the contract
level I mean providing that the target
is the same contract for all the
subcodes and that's as simple as
including that so yeah it keep in mind
that there are always this nice tricks
that could possibly help your users down
the line and I think it's it's important
to have that in mind when building
contracts and try to be creative
that's it
[Applause]
yeah so I'm going to repeat the question
for for the stream and the live and uh
the question was about like can access
control be used for smart toilets is
that that's it basically I think uh well
uh it really depends what's kind of
Smartwatch you want to build
um there are different kind of smart
wallets if it's just something that QRS
sole owner of I'm not sure it brings
anything new to the table uh but if you
are doing a multi-sig maybe it will be
relevant I mean my opinion is that a
time lock for example is a kind of North
wallet because it's just someone that
will manage asset and do operation with
three specific rules and in the open zip
time lock we use Access Control to
separate the role of the proposers from
the executors from the admin that may
have the right to cancel potentially so
yes if you are building a multi-cig and
you want to have different privileged
access maybe I think an overseer that is
able to recover in case of of issue
having signers having proposers that
basically you're turning your emergency
into some governance mechanism which
which it basically is what time will see
is a governance mechanism so yes you
could use Access Control
uh hey uh in an example with a multico
that you've shown we are deploying the
same method like a byte code for this
method in every contract
wouldn't it be better if we have it
deployed separately
yes it would but it's not possible right
now so like if we had a EIP 3074 live we
could just have this make use this OS
and oscore mechanism to do batching
transaction and and you would not have
to include that in your contract the
thing is that this is not available now
it will not be available until at least
Shanghai and maybe later
so I think the bytecode increase is is
really small compared to the the value
that is added to your contract right now
but yeah in the long run hopefully we
would have already supported at the at
the execution level later
hey uh great talk by the way uh in the
ownable ERC 721 part you were talking
about how you could basically ditch the
ownable the ownable library right what
what advantage I I kind of missed the
point of like what's the advantage of
implementing the ownership
inside the erc721 logic instead of just
bringing ownable is it just like byte
code size or is there any other
advantage that I'm missing no the weird
advantages in in composability so
examples for example your your own Apple
contract it could be tied to assets
maybe you would want to consider that as
a class of its own that you would
be able to land against collateral or
maybe it's uh maybe it's like a vessing
wallet that is basically a future uh
financial future that you want to sell
on unisa on openc uh right now you
cannot sell a non-able contract on openc
but you can sell an nft so the way here
is to make sure that your contract is
compatible with all the tooling that
exists out there openc and others also
just being able to see the ownership in
your zirion or any palette you'll use
that's also something nice
thanks
thank you