[Music]
he sorry about
this okay hello everybody thanks for
being there I know it's the lunch break
so thanks really for for being there so
my name is arur I'm a product manager at
Linea and so like today I will be
talking about YC 30
3668 um so yeah let's get started
basically the agenda is quite
straightforward I will explain what it
is uh why do we need it right um and how
does it work the use cases behind it and
I will spend some time uh talking about
the cool integration that we did at
linear to benefit from this standard so
maybe to set the context let's just talk
about how we can access external data I
think most of you knows but natively
right a chain cannot access data from
the external World whether it's over
chains or the web but like over the time
we build some other protocols that solve
those problems so the the main one are
bridges right if you most known to if
you want to bridge assets so coins nfts
but there are also message bridge that
let you send a transaction on chain a
and it execute a transaction on chain B
um there are also oracles that are well
known for like price feed most mostly
but most recently they have creating
more generalized implementation such as
like chain link functions and other and
lately we have also uh co-processors
that are uh enabling those kind of use
cases um so the question you might ask
yourself is okay why do we need another
solution and basically ERC
3668 uh also known as a CCP read was a
standard proposed by the ens team
especially Nick because they had like
unique use cases where they wanted to um
access um the information for L2
especially for managing like domain name
in a with cheaper like gas cost but uh
the they have some constraint and the
design is reflecting that so the first
benefit is that it doesn't require any
trans transaction to send on chain
compared to over all the other solutions
that we mentioned um so this is more
efficient in a way if you don't need to
store the data on chain because you
don't have to pay the gas cost you also
avoid external depend dependency sorry
on external prod protocols because it's
an ERC and it's uh like B on top of the
protocol but doesn't have those
dependency and extern additional trust
assumption as well so let me tell you a
bit how it works there is three part to
it um it starts with the client and here
we are not talking about execution
client or consensus client but more like
the uis or like backends that are
calling the the blockchain and uh like
the client will uh call a smart contract
right standard if call to to get some
information uh something that happens
quite generally and the main um part of
the design from ERC 4668 is this uh
allows the contract to revert with an
error that's basically tell the client
actually you need to give me a bit more
data so that I can do my job
so uh at this point so the client will
uh add the job to fetch the data on a
Gateway so a standard HTTP call and uh
of course the Gateway will send the
result and then you the the client is uh
like giving back the information to the
contract uh through a callback function
and at the end of the day you have an
answer so here I talk about call but
actually the call back function can be
also sent in a transaction so that means
that at the end of the day you have some
logic that can be executed on Shain in a
block um the nice thing about this
design is that if you look at the
offchain data um error there is all the
information store on there there to uh
explain to the client what he needs to
do so in advance the client doesn't need
to have any information about what what
are the gateway to call what is the
information that I need to send to the
Gateway which is the call data uh or
what are the Callback function and so on
so this mean that the client can have a
standard implementation and you don't
need to integrate each time like a
specific use case so if you want to
integrate like a chain like I don't know
optimism and a chain like linear you
don't have to do it
twice um so if you are following like
attentively you might ask yourself but
okay like it seems that you have to
trust the Gateway and like thanks to
during the introduction we said it was
like a secure and Trust minimize way to
um fetch data and actually you don't
have to trust the Gateway uh necessarily
if the Gateway provide also proof of the
information uh that were given and the
nice thing about it is that you know
that l2s like in the design of rollup
are posting their state on the on the
layer one and so you can like just fetch
a storage proof on the L2 and then like
verify it on the layer one uh so that
you can be sure that the data is
accurate so that's what is uh shown here
when you are doing when the Gateway is
doing the HTTP request actually the
Gateway will uh call L2 RPC will ask for
the information for if call and then
also like do something like a if get
proof to to get the storage proof and
then when the contract receive the
information it will call the rollup
contract which can verify the proof at
the high
level so I think like the design is
quite of cool but uh what can we do with
it um as mentioned in the introduction
like ens was the one proposing it and
actually they have they had a very
specific use case in mind which was to
enable to manage like domains on L2 for
cheaper like gas cost and that's the
main use case that we are seeing today
uh one example is the linear names that
we introduce on linear where you can
have like names like brian. linear. if
or a.l. if um it's something that uh we
built and that can be reused by like the
ecosystem to build any uh integration
with ens and if it works like everywhere
ens is resolved as an example like we
have a nft collection on Linea which are
called eogs that wanted to give ens
domains to all the holders so for
instance know if you have a um you type
743 if. if it's it resol to the
owner of this nft and if the nft is
transfer like the the name is
transferred with it as well so this is
kind of cool but it's just a first size
and it doesn't stop there like um it can
be used for
any type of um use cases where basically
you want to either compute or store data
on the layer two or even of chain and
access it on on layer one so some
example include like Dow governance
where with solution like um sorry we
with like governance solution like
snapshot X that are providing like
voting on chain you can vote on linear
or other L tools that are much Sher in
gas and then you can just take the
result and use this call this result to
execute transaction on the layer one one
other interesting use case for instance
is to like gate access to Smart
contracts so for instance like if you
are doing an airdrop or nft mins you can
require people to have specific
credentials that are minted on Layer Two
for in attestation for
instance um so okay you might ask your
question how how do I need to implement
that it seems really complicated you're
talking about proof and so on um the
nice thing is that we already
implemented all the smart contracts uh
so so like all this complicated logic or
not so complicated but all this logic is
already taken care of we have a Gateway
that is running we have all the smart
contracts the one that are verifying the
proof which for Z kol up is esec
especially difficult because uh the the
ZK layer 2 usually have a different way
to uh store data uh because like um the
standard Ash function can be a bit
complicated for ZK so for instance on
linear we have like Spar Vel tree
instead of merel tree but basically all
of that is to say that uh we have
contracts that are open source and that
can be called to verify the the data to
also fetch the data directly so
basically uh on the smart contract level
it's much more simpler and uh on top of
that there have been team like the unrug
team that have built additional layer of
abstraction that simplify it even more
and Abstract the chain so it can
seamlessly like work on different
chain so to summarize the benefits uh
like ERC 3668 is efficient because you
don't have to send a transaction on L1
when you don't need to it's secure
especially when you are working like on
a layer two with like zero knowledge
proof like like Linea you don't
introduce additional dependency to over
protocol and like the development uh
overhead is minimal because all the
contracts the Gateway everything is
already for you to to build
on um and so if you want to get started
uh those are some links to our doc
documentation open source Trio uh but
most importantly we are doing a a
workshop just after the lunch break
where we will Deep dive into really code
example and you will be able to have a
live version running on on your laptop
at the end of the
session so yeah that's it thanks a
lot just a reminder guys uh if you guys
have any questions you can ask them
through mircat scan the QR code um looks
like we already have some more coming in
uh the first question is it possible to
read L1 data from L2 and so yeah in
theory it's POS it's totally possible
like RC
3668 allows to fetch any data the only
thing is that you you need to have like
the state of the blockchain that you
want to to query onor on the Chain where
you want to from which you want to sorry
I will go go again uh but you you need
to on the blockchain that is quaring the
information you need to have the the
state of the blockchain that is being
queried and so like it's not most collup
doesn't have that at the moment maybe at
some point we will see like Oracle fun
Oracle that are uh streaming this kind
of data on Shain um but it's it would be
something really cool to
build uh the last question we have
doesn't it make the process more
centralized so indeed like the point of
centralization here is the Gateway uh
but uh if we come back to okay um
actually like the smart contract can
like pass multiple URLs so you have a
kind of redundancy here because you can
have multiple different Gateway not to
rely on a single point of failure but
since the Gateway is passing a proof
like it cannot be tempered with uh so
there is no additional trans assumption
regarding like the um accuracy of the
data we have uh another question keep
them coming guys we we still have time
um does it open up to a temporal attack
if the L2 storage proof is not posted on
L1 yet yeah that that's a very good good
question so you are aware that like l2s
are not finalizing like like every
second or minutes on on L1 and so
basically you don't have the the state
of L2 uh like before is getting
finalized so on the like Z rollup can be
uh from a few minutes to to hours
depending on the layer tools on
optimistic rollup it's like the seven
days so this means that you need to to
wait this period in order to fetch the
data so there is this latency uh but
like as the space evolve and we are
going to faster finality uh hopefully
this will get better I don't think there
is an attack uh it's just that like the
client and smart contract need to be
aware of this limitation and like work
with it at the
moment what libraries already implement
this
behavior um if if that GS for sure uh
wag me as well uh unrug is creating a
like higher level abstraction to work
across chain so you don't even have to
worry about like uh the specific of the
um each gateways and so on as a builder
that wants to to rely on your own
Gateway um those are the libraries I
know is there any L work latency when
reading
data um so yeah the it's the
finalization latent latency so as I
mentioned like from a few minutes to
seven days if you're on optimistic
rollup but like from the network latency
really like it's really uh quick like
usually less than a second or even less
so you you can test it and like type for
instance like arur do.if on the on your
metamask or on the ens website and you
you will see like the answer is almost
uh