[Applause]
come in the native clock is new
application design principles we need
2.0 but the structure this talk first
I'm going to talk about some of the
technical organizations that application
vault for space and I think I'm gonna
try and talk about it in a way that
Ellie's time you can granularity yeah is
it usually puffed up and then the second
half will focus on kind of solutions
that we're seeing in space right now and
then what we're gonna see in terms of
trends especially as you start scrolling
around so what are the big technical
challenges
the first one is transact transaction
latency so it's what is fairly obvious
but with the theory on 1.0 main chain we
block their balls eight seconds even
with e 2.0 the block interval is going
to be at least some target is from three
to six seconds in three to six seconds
it's good compared to eight the natives
of alligator compared to say ten minutes
but I would argue that users are
accustomed to responsibly and see
hundreds of all sizes so there is a coke
but around saying or Amazon every 100
milliseconds of latency a possible
percent profit come to the same thing to
say web search queries and their
correlation a trek views or even mobile
apps and a response latency in their
correlation with education so I'd argue
that you have three six seconds which is
not quite good enough and it gets even
worse
if you have to do sequential
transactions so an example that as I'm
sure a lot of you know the along with
spur DRC a contract before transferring
your asset to any contract for this one
contract you have to do to support
intersections and I think that deep
black holes are not fast enough
another one is as the complexity of a
smart contract increases the gas
transaction fees also increase with it
and from an engineering perspective it
seems fairly natural but I would argue
that for most users on the internet they
don't really like them this way most
users a lot of the complexities
abstracted away
they're accustomed to say free
applications or low-cost applications
and I think one of the key reasons for
this dissonance is that with smart
contract applications all the dough's in
that work can have to Lou basically
recompute offense action every single
time they want to verify it another way
of saying this is that it's not possible
for a single computer to Mexican
transaction and then generate or prove
that every other no time a network
official verify and then the third point
is you can't really do transaction
valuation with the tools that are given
to us right now and one consequence here
electrolyzer you're familiar with is a
user and submit a transaction without
paying for it
great they have to have Eve under
account in order to submit a transaction
they're not allowed to delegate from
Haven to someone else and I think
another consequence that we talk about
so often is that contracts themselves
can't really initiate transactions if
you think about a traditional
application developers are pretty
accustomed to things like cron jobs that
are able to execute a transaction on
some kind of set interval to maintain
the state of the server you can't really
do that with smart contracts or them and
then the last one is that it's just
difficult to have two users that get the
other side of the transaction and then
how
a contract it's a lot more natural right
now with what's available or a user to
only settle transaction with a smart
contract directly and I think a pretty
good example this would be you swap
where despite the fact that it's an
exchange and I think it's fairly natural
to think about exchange in terms of sale
like a decentralized border book where
you find a counterparty and then you
sell the counterparty they figured out a
way to create exchange where you only
sell with smart contract and that leads
to a better user experience but then
unfortunately most applications you
can't really design a smart contract
that way so yeah those are kind of like
a big technical limitation that I see
right now when it comes to designing
applications the first one high
transaction latency the second one is
the gas cause tend to increase with the
complexity of the smart contract and
then the third one is also that you
can't really delegate a submission of a
transaction with someone else then in
terms of like solution what we see right
now one I think there is some different
names for this but I'm just gonna call
it the optimistic framework and this is
a partial solutions transaction latency
so generally how it works is first the
user makes some kind of sumption
basically they put some trust and
another participant in the contract it
once you make that assumption then
you're able to delay submitting the
transaction because you don't really
need the guarantees of the smart
contract or sorry the blockchain to
secure the transaction
and then once you're able to make that
assumption you're able to just you're
able to only submit the most
economically relevant transactions on
tape and everything else can be pushed
off shape and that means that certain
transactions you're not bound to the
block your whole watching and then it
just becomes something like like network
round trip which now goes back to like
the hundreds of milliseconds and now 36
seconds or eight seconds
another one is meta transactions so I
pronounced Malay what these are so the
gas station network is pretty good or a
well-known implementation that's live
right now and this solves or at least is
a partial solution to the delegation
problem and they're specifically
attacking the issue where users
sometimes don't want to or can't be
every transaction and the general flow
here really is that user sends a
transaction and then instead of
submitting that directly to the mempool
and what amendable I'm just talking
about a set of transactions that are
pending into their network or it's a
submitted the blockchain instead of
somebody well first they submit it or
send it to a relay and they exist
outside of the network point right and
then the relay er does some kind of
transformation create some are turns
outside message into a real transaction
and then they're the ones that submit
the transaction to the network and
they're the ones that make the videos
and they're the reason why they do it is
because they're compensated through some
pre-funded account and usually every
funding account is paid for by maybe the
operators smart contract so again this
is kind of partial solution to the
evaluation problem somehow I I'm not
going to go through all these but the
point that I'm trying to make by the way
if some of these words don't make sense
that's okay but the point I'm trying to
make is that there are all these
solutions are popping up that are kind
of tackling those technical limitations
that I was talking about and the
critical thing here is that no these
solutions are you layer one solutions
they're all going to be layer two
solutions they're all going to require
some kind of network infrastructure and
that's probably one of the biggest
takeaways that I want to take here which
is that there's going to be the merging
of a target market and they're going to
be parts of spins that are economically
incentivize to take side messages and do
some time transformation on it before it
gets submitted to the middle and all of
these solutions kind of use the same
pattern and spot pattern go quick
the first step is the user signs message
and again instead of spinning to the
mempool they're going to send it to
every layer and this real layer is going
to be incentivized to perform some kind
of computation and then submit
full and the third part is fairly
critical and the smart contract or maybe
the nose in the network they have to be
able to efficiently verify the
computations and this kind of goes back
to what I was talking about earlier
where one of the reasons why the
transactions are so expensive especially
the smart contracts get more complex is
because right now everyone has to
compute the transaction in order to
verify that everything is correct but if
you can kind of separate that and if the
verification is cheaper than the
computation that's a very powerful
pattern that's also why if you've heard
of like ZK roll-ups that's why they have
so much potential because depending on
the implementation of terminology proof
deep in the roof can be verified and
lock n where n is like the number of
steps to perform a calculation and then
I'll also comment that this is very
relevant for Phase two of each to one
each to starts executing transactions
because Beacon knows have to be able to
verify transactions that are happening
on the char chain for their 1,024 char
chains which means that there has to be
some kind of efficiency gain when we're
verifying transactions but on the flip
side or at least taking a step back
there is the reason why
market doesn't exist and why it's kind
of difficult someone up right now the
biggest one is that a relayer market or
some additional piece of infrastructure
it's gonna retire system it's gonna add
more complexity possibly for the
developers and then also for the users
that we're not able to properly absorb
for existing contracts so the gas
station networking pretty good example
this where right now if you want to
integrate the gas station network to an
existing contract needs set up some
proxy contractor part of it and that's
additional gas costs and another
security pool as well another third
thing is there's no standardization
right now so I think this is okay we're
still trying to figure out the best
solutions all right now but I think as
we figure out what the best solutions
are there is going to be some kind of
standardization there's probably gonna
be some general new labor market anyways
yeah this is the last slide but it's
really poor the application developers
are thinking about writing in use of our
contract right now and I would say try
and keep the smart contract as simple as
possible but there's a caveat which is
that writing a simple contract that's
also useful is really really really
large but if you decide that or if you
you they're convinced that it's
impossible it's great smart contract
look at layer two look at these facing
solutions but then also think about the
real a market in a way that's specific
to your app
and see if there's any efficiency games
there that you can make specifically for
application I mean the third thing is if
you do go with the layer 2 solution
think about what you use with your layer
2 solution with all their applications
and maybe consider create some kind of
accommodate researcher yeah that's it
[Applause]
you