This is Epicenter episode 522 with the Asian Co founder of
Scroll introducing the next generation
of dydx and the next version of the dydx token.
Welcome to the dydx chain. New token mechanics mean you can
stake to secure the network. Staking is fully decentralized
and controlled by dydx token holders.
All fees are distributed to stakers.
Earn rewards from using the dydx protocol with rewards plan for
traders and early adopters too. New governance means you are in
control. Trading has been democratized.
You can vote on protocol improvements, token
distributions and more. Bridge your Dydx to seamlessly
transition to Dydx chain bridge now at bridge dot dydx dot trade
and contribute to the evolution of dydx chain.
Open source and community driven.
Run your own validator validating is fully
permissionless. Join us on our mission to
democratize access to financial opportunity today.
Welcome to Epicenter, the show where shocks about the
technologies project and people driving decentralization and the
blockchain revolution. I'm Federica ANZ, and today I'm
speaking with Yeah, from Scroll AZKEVM, roll up on top of
Ethereum. Yeah.
Thank you so much for joining us.
Hi, thanks for hosting. Nice to meet again.
Cool. We first met at EDCON this year,
so probably about six months ago, and had really good talk
about kind of like, you know, L2 landscapes and L1 landscapes and
so on. So we'll definitely get into
that a bit later. But for everyone who doesn't
know you, tell us a bit about your background.
It's also glad to meet you and also your background is very
impressive. I remember our long conversation
debating around like here too and there one.
OK sure, so hi everyone. My name is yeah, but I'm the Co
founder of school. My background is more from
academic. I will call ZK and crypto
before. So I think before like three
years before school I was working on purely on $0.00 proof
research. I work on hard work solution for
$0.00 proof because five years ago that's the biggest
bottleneck for using $0.00 proof in practice, because a proof
generation is just so slow. It takes like several minutes or
several hours to generate proof for any computation any program.
So my my first task is like use hardware like GPU and ASIC to
make this poor generation faster to solve this kind of poor
efficiency problem. And later I work more on the
theoretical side, looking to how like how this kind of magic
works, like how you generate proof, how you compress a large
program into a very stink proof, and more like theoretical
construction and later like you know I.
Because you know the most fundamental problem of
efficiency has been improved for order of magnitude.
So that's why I moved to more on the kind of application side
where how we can use this kind of magic technology to scale for
privacy and for use cases. So my background is more on the
kind of DK research side, like hardware acceleration for the K
theoretical construction behind the K and DK applications escrow
and mainly work on like. Taking research and some
strategy stuff to bridge between non tech and tech.
That's about me. Tell us about the hardware
limitations that we currently face for ZK technology.
So why does it place so big a burden on regular CPUs?
And why have why did you resort to GPUs?
Yeah, that's a great question and I think so.
So just high level context. So the only proof is that where
you can generate proof for so you have a program and but it's
like too large to to execute for for verifier for example like
I'm on a phone, I'm on a device where I can't execute the
program myself so there's a prover which it would generate
proof to prove that it execute the program correctly.
This is a result, this is a proof and you only need to
verify the proof very efficiently.
So in this case. Prover is more like a powerful
machine where it can execute a program and a generate proof to
save verifies effort to to kind of re execute without re
executing. You know the result is correct
but the magic comes at some trade off where because you
can't just magically save what's cost.
So the cost is that the prover need to generate proof with a
much larger cost. So imagine that the program like
execution takes like for example one second.
And then like the proof generation might takes hours
time so which is like once on or even larger overhead to generate
proof. So which means like initially
prover only need to run like this program like very quickly
but but generate proof is like you need to pay for once on the
times overhead to just to save verifies kind of effort.
And this kind of computation for genetic proof involving a lot of
operations on elliptic curve is based on something called
probabilistic shadow proof. And it would map into a lot of
operations on evetic curve which involve large finite like large
finite field operation like you know modular 256 bit large
integer and that's very very expensive but luckily it's very
very easy to parallel because. So that's why I like you know
using GPU and and FPGA or async can make this become like order
of magnitude faster. And we are the first one to kind
of tackle this problem from a more academic like perspective
and decompose proving into several components.
Some components are like ellipse curve operations and some
operations are like FFT over finite field and we can make
both parts become secularly faster and then the end to end
proof generation can be like order of magnitude faster so
then like practically. You just run this proof
generation over hardware and then like everything got really
fast. And currently the state of art
is that a lot of like companies are building different
solutions, some are more ASIC driven like Seisig, Excel they
are they are more leaning towards this ASIC solution which
is highly customized and super fast, but a lot of like open
source invitation like from from super rational from from a lot
of teams. More like GPU based and that can
also achieve a very very significant speed up like 10
times or even 100 times compared with depending on the device.
So the magic is in the parallelization.
Yes, yes, exactly. Perfect.
Cool. So you guys started 20/21 and
when I say you guys, I say, I mean you and your Co founders,
Sandy and Hai Chen. How did you 3 meet?
Yeah. I think that's a very different
story like we we we actually first meet meet online.
So my background as I mentioned like I was working on academic,
I was working on ZK purely into that rabbit hole and the other
two Co founder Sandy and Hai Chen we work on totally three
totally different separate area. Sandy is more working on the
like business side, I like non tech site ecosystem building
side and like high Chen is more leading the engineer effort.
So it's very interesting that we we might actually through the
ECM community. Because Sandy has been doing
like before Scroll, he had been like, you know, doing his own
her All Star hub and doing regulation stuff and doing a lot
of investment in crypto. And he's a, she's more like a
builder in the whole ecosystem and she has been paying
attention to the whole, you know what's happening in the crypto
world. He she noticed that there might
be a huge opportunity to Layer 2 because Layer 2 will become the
entry point for. Of users to enter ECM because
ECM is just very very expensive for no more ordinary user to
use. So there is a huge opportunity
there to to scale using layer two And then like I would
building like you know like thinking about how to improve
proverse efficiency to kind of scale ECM year general like more
general purpose way and then like high Che is more leading
some engineer effort He he has the PhD in system from from from
University of Washington. He has been like working on AI
and beauty system but his system is very comprehensive.
He builds system including like GPU compiler, it's very, very
complete system and turning that into product.
So it's more like what research which you know how proof of
concept idea have you know research and architecture idea.
One is like can actually turn this idea into implementation
into product level like system and as I know like how to kind
of you know like how you scale, how to fit this kind of
technical. Component into the whole like
ECM scaling like in diagram. Three of us are both in like I
met Sandy through ECM community. We actually met through ECM
research forum which I post some early idea for.
Oh, here is you know how you can scale ECM and here is you know
how you can Accelerate Prover and how you make that possible.
And then like I met Hutchins through like also like our
common friend is the ECM community and also like he he
has been doing some like competitive programming and mass
you know like competition. So that's how we connect and
it's more like very organic and a very kind of you know like
different not different way where there's the research
forum, there's community discussion and that we we talk
about this interesting idea and why it's possible now.
And there are three of us just met online start to kind of.
OK, so let's work on this. And then gradually it grows
like, you know, totally uneffective.
But yeah, that's a different story.
That's a super cool origin story because kind of like purely
online. I think it's maybe also a COVID
story because it happened in 2020.
One that's definitely a big yeah, yeah, So kind of.
Real life events were kind of suspended for a while, but yet
to me it's really amazing because kind of Co founding with
someone. It's a very intimate
relationship, right? So basically you have to work
really well as a team and they're kind of finding that
purely online, that is, that is such a cool story.
How was it when you guys met for the first time?
I think we still have some like share some common friends, but
all the discussions happen like in the, you know, either
research forum or like in the community discussion around like
layer two skating and then like we feel like.
The value is pretty aligned. We want to scale ECM and we
observe that there's a very vibrant ECM research community
there. Like that's why I'm attracted
and there is a vibrant ecosystem.
They are liking ECM and that that's why how Sandy is
attracted and hygienicing this technology is so amazing.
I want to turn that into a system.
So it's like there's still some common friends, but you know,
it's more like community thing and then like people meet and
like got to know each other and yeah, yeah, but you guys have
met in person, right? Yes, yes.
It's only after I think the the earliest in person meet up is in
devconnecting Amsterdam, where that's the first time we
followed. That was 2022.
Yes, yes, I think so cool. What Scroll puts front and
centre is that it is EVM compatible.
What drove you to this decision Because I mean we recently spoke
with a number of other ZK roll ups and some of some of which
kind of also went this route like Hamas with with Geordie,
now Polygon, ZKEVACKEVM, but others haven't.
So kind of like for instance we recently had on Aztec and Ellie
from Starknet and they were adamant that the efficiency
losses that you suffer from doing an op code by op code
based translation is not worth it.
So how? How did you kind of settle on
this design choice? Yeah, that's a great question.
So I think a big, a big part of that is that like you know think
about your motivation from first principle, like you know why you
want to even build a layer two solution.
So I think for me that we observe that ECM is congested
and it's very expensive and applications on ECM want to find
a place where it it's very cheap.
It's auto secure. It has a security from ECM So
that's why we think you know like reducing the effort that
applications can find such a solution either way to go and
also like I think from and like. So that's that's our first
motivation, like why we ought to build a very seamless scaling
solution that all the developer, all the users can reuse
everything they have to migrate to, to scroll in a seamless
manner. And the users can reuse all
their familiar like toolings and developer can use their kind of
foundry and all those tools directly and also like.
So that's the first intuition where we don't want anyone to
change any of their kind of habit to only get the benefits
which is faster, cheaper with a faster like pre confirmation
time and high throughput. So that's our first intuition.
And second thing is that I think it's actually from the security
perspective where EVM has not only has a ecosystem but also
has proven itself from years of of of time where you know like
all the all the application deployed on this model like
hasn't been, there hasn't been any any problem with that.
So that's why like we think inheriting the security from
this kind of test of time model is very important.
Even like we we are reusing to the code level where we are
trying to reuse a code. They kind of know the invitation
from ECM. We are trying to use Go ECM
which is ECM's client invitation to generate block to generate
our block to make sure that the behavior is exactly the same.
So using that it's definitely increases the security and also
because developer don't need to change any layer of their code.
So like imagine like you know if every layer to require you to
make a significant changes to our code, then like maybe
largely JIT application like Uniswap Avi might worry that you
know. Why should I migrate to this
chain with some risk in changing my code and we're doing this re
audit so that's why I like we think this is very important and
and also like I think EVM just have way more like toolings than
like any other VM has like even if you think you know software
has has put a lot of effort in kind of Carl but like if you
think about how many invitation how many toolings you can use to
deploy on on Carl that like. It's very limited compared with
with the whole EVM ecosystem. So that's another thing which
you know like enhard the ecosystem build your own network
effect and then like only then like you can think about you
know what things you can you can provide some actual value to to
the developer in your community. And I think one last last thing
is that this even distinguish us from several other like language
compatible, they grew up is that we we are like by core level
compatible with EVM. So which means like per OP code
we will have some circuit mapping to kind of prove on the
bicycle level and so and reuse all the kind of invitation like
Go ECM to kind of generate our block.
So this guarantee us that every time ECM is doing any upgrade,
it's very easy to apply to our chain like for example like you
know there is, there is some kind of Eips, there's hard fork
and it's easy for us to adopt those changes if we are EVM, but
if you are. Totally work on different paths.
It's very hard to kind of follow what is what what the ECM layer
one is doing, adopt all the innovations from the ECM
community. So even if like you know there's
so many innovations like new pre compilers, new discussions
around like you know ECM layer one and we can directly take all
those innovations and apply that to layer 2.
Even some like infrastructure like 43C7, PBS, all those kind
of great ideas like MEV, all those kind of infrastructure to
solve those problem can be reused on.
Or scroll directly. So that's why like you can
always, you know stay up to date with being very ECM aligned,
reuse all the innovation from the research community without
too much fragmentation. And eventually I think you know
later might become especially us might become the the the kind of
like we can go you know one one step ahead of ECM to test some
kind of Eips and adopt some innovations and then like if
it's proven to be successful then like.
Maybe ECM has a larger possibility to to kind of adopt
to push this innovation. So always stay ahead, always
stay on top of this kind of nice solutions and to benefit the
whole ECM community. So yeah, there are multiple
reasons but that's all like you know, I can, I can think about
definitely like TLDI that developer and user expenses, the
same security model, the same ecosystem and toolings are more
vibrant. And last thing is like you know
stay always ahead on this innovation and research.
And benefit eventually benefit the whole ECM community and I
hear that 100%. But can I just kind of poke into
this a bit more? So if if you kind of look at,
what would you say the efficiency gains you could get
from not using a ZKEVM would be and kind of, is there any way
kind of to make up the efficiency you're losing with
respect to other roll ups that are using more optimized
languages? Yeah, that's a great question.
So I think that's actually the biggest like reason why you know
like so many row OPS want to choose other virtual machine
model because they used to think like you know being by code
level compatible building such as the KVM will have a
significant larger overhead. Maybe they they are imagine like
10 times, maybe like 100 times, maybe like larger overhead than
they are. They are kind of the key virtual
machine. But the reality is that I think
they didn't expect even like us do they expect like the prover
technology has been proved so much I I think two years ago,
two or three years ago. I think when we start school,
compared with five years ago where the technology of the K
lies, it's like the the efficiency of poor has been
proved for three order of magnitude like by this kind of
advanced proving system by the underlying hardware
acceleration. By proof recursion.
So the efficiency has already been improved for like 1 sum of
times. So that's why I think compared
with different ZQ virtual machine, I don't think ZQ VM by
code level ZQ VM had that much overhead.
I think had most probably like two or three times even like
sometimes like can be even lower and that's only talking about
the poor cost which is not the dominant cost for a layer 2
transaction. So think imagine like you know
for our kind of layer 2 transaction if you want to post
data on chain. That might takes the majority of
the cost which is over 90% of the the cost and then like among
the kind of rest of 10% of time. You know like maybe using some
other Z key VM can save the proving cost for like 2 * 3
times and that's only portion 1 portion of this 10%.
Which means like you know it won't differ that much even if
you are using other Z key virtual machines.
But the the the hugest loss is that you lose compatibility.
And you have to rebuild your ecosystem from scratch.
So and you will really suffer from that.
So I think that's why I don't see kind of too much loss on the
on the on the poor side and especially with the technology
keep improving and we predict like the the technology will
still improve for another 10 times like in my prediction is
like in six months or one year we can make a 10 times even
faster the KVM. So it's really not that painful
as as people predict like five years ago.
So, so you think it's kind of, is it fair to kind of compare
this to say no longer building applications in C++ just because
I mean just because C++ may be a little bit more efficient at
some things and kind of the convenience and the developer
mindshare that you kind of get with more?
Common developer languages more than makes up for this.
So are you talking about like using SIPS also to write smart
contract versus Solidity or? Like, Oh no, no no, not not
smart, not smart contract, just general general code.
I mean, so basically I went to university a while ago, and back
then whenever we kind of took home large batches of data,
obviously C++ was kind of the go to thing to kind of use, just
because it was much more efficient than Python for
instance. But you you're saying that kind
of using Python And other more convenient languages for
developers, this is kind of the parallel, right?
Kind of it's kind of like you you, you you're saying kind of
the technology has made such tremendous advancements that
kind of the fact that two or three that you're possibly
losing doesn't really matter much.
Yeah, in some sense, yes. Like we want to keep the kind of
Python level developer experience but magically reduce
the overhead of back end to some degree that you know it doesn't
matter like you know you optimize safely for C plus
because that doesn't really influence your overall cost in
some sense yes but it's more similar to like I think other VM
are trying to kind of like compel like I, I I I think like
it's very similar but one thing which is quite different is that
if you run C++ and Python like the the the complexity of the
underlying like CPU is like still like influence on
efficiency. But here like especially if
you're looking at the transaction cost, it's not just
execution cost, it's also like data cost, which means like make
this kind of difference become even smaller because it's like
5% or more all the cost and then you save this 5% to some degree.
But you know you you give up like this, compatibility either
user, but the transaction cost overall will be similar, yeah.
Yeah, perfect. I want to talk about kind of how
the cost for an L2 transaction is made-up later and kind of
talk about data availability then.
So kind of I I would like to table this for now, let's talk
about kind of the the creation of scrolling a little bit more.
So I remember the ECC presentation where where Jody
for the first time. Talked about building a OP code
by OP code transposition into a ZKEVM that was in June 2021.
Blew everyone's minds. How did you?
How did you guys fit into your timeline?
Because I know scrollers. Scrollers also founded in 2021.
Yeah that's a that's a really great question.
So I think a lot of people are like maybe don't know the the
the story behind. I think, I think while we
started, we start in early 2022 in January, I think that's the
earliest we have this idea for we want to build a layer 2.
But the first idea of score is that because we have this
hardware idea in mind, so we want to design some
decentralized poor network where we can use a network of miners
or prover to generate proof of us to provide enough computation
power for us to generate proof for large applications.
So that's our initial idea firstly having this architecture
and then the key VM, the key VM is just application.
And then initially we are thinking about more even in our
initial posting I I think in April 2021 is talking about like
the key virtual machine how you the key CPU how that you know
cycle works. But later I think I talked with
I I met, I met Barry from ECM Foundation who is like who
actually invented the key. Rob the the the, the concept of
of the key. Robber Barry Whitehead, right,
Yeah. Barry Whitehead, yeah.
And he he, he has been thinking through like whether the QM is
possible whether by code level like the QVM is possible or not.
And then like we like he he, he read our documentation and then
like say said OK so if you also want to build something like
this we also had some idea why not like you know we collaborate
on this and then like share if you think this is the right
approach to to build why don't we just building the open
everything is open source and then like just build that.
I think at that time that's where I think all the the QVM
even including like like Hermes, like there's the idea for from
from Geordie like all start from there.
So I think it's Barry's discussing some with someone
else to about this idea for how you use lookup to solve the
biggest problem for read and write to storage.
Because because like is there not proof you to prove program
for for some static program which for example you have some
sorting, you prove this fixed program but VM needs to read and
write the state, the storage and that mapping is very costly
because you need to use a merkle tree every time you read from
element you need to prove a merkle tree branch.
And the idea is that we can use look up to solve this problem
like totally like because you only need to build a look up
table and then you can do efficient batch look up to into
that that that table. And that's where all the ideas
come from including like Jordis. I think Barry has been talking
with a lot of teams like including like Jordy, us as well
as some other layer two teams and that we are the first one to
commit to world to building the open and we want to kind of
build with with their team as as exploration to kind of because
we believe that building the public is a one of the core
spirit of of ECM community. Why it's so vibrant like because
people can kind of contribute freely.
People can kind of collaborate freely And then I think Jordy is
more leaning towards like stark based approach but the
architecture is very very similar.
It's all originally from the the like the the very like old doc
where you use look up to solve this problem and then like he's
he like I think then like he's back out like he want to use
Stark he takes some different design choices and then like he
choose to like build build with this this Polygon and build
their own like I think he he builds their own like
instruction sets to and also interpreter to interpret by code
into that instruction set. But we are more firmly believe
that directly build circuit for each op code so that you can
have per op code mapping. You don't need to build any
interpreter you don't need to build a a sequencer from
scratch. You can reuse everything that
ECM has. So that's why I like us and the
PSE team which is short for privacy and scaling exploration
team led by Barry Redhead and work towards the direction where
it's OP code level compatible maximum the usability of there 1
sequencer and then Jordy leads towards a stock based back end
and some kind of other instruction set with an
interpreter but still like with this kind of by code level
compatibility. So that's where different
approaches differ but it's all actually arranged from the
breakthrough or the idea for OK use look up to do this use
custom gate to kind of express your your op codes.
So it's very similar. It's I think it's exactly the
same timeline actually like because I I remember like you
know Barry's talking with with many teams about you know
whether they are interested in kind of building this together.
But there will be different considerations behind teams
around like how this need to be built and like different design
choices. And we are more aligned on the
other side, like, you know, use this kind of KDG, use snark, use
maximum usability and build something like in the public.
So yeah, that's the difference. But everyone starts the same
point with a similar architecture for how you handle
this memory thing. Yeah, this is super interesting
to kind of fear that it kind of all started with Barry
Whitehead's idea of kind of how to do the look up.
So you guys recently kicked off your mainnet.
If I remember correctly, it was mid-october.
So tell us about that. Yeah, it has been a Really.
Really long journey from from search to to mid.
I think we we we officially launched the the genesis happens
in like October 10th and we we encode some like the future is
open using like a word language to to to try that you know we
think the word need to be connected it's global and the
future is open and then like I think the official opening is
mid-october I think before it's it's really exciting like the
whole team is in Vietnam doing some offsites like we we
actually they're like celebrating in person with each
other like because it's a joint effort not only like research
not only engineering but also like the whole team in like PD
Devro like OPS all those different teams like joint for
us to to build this together not only a product but also like not
only a like just engineer effort but but it's a it's a community
effort. I think we we have been like
really doing a lot of lot of like preparation to make this
happen like our test net have been running for over like 15
months from pre alpha test net to alpha test net to beta test
net lot of upgrades a lot of testing I think we like before
before man launch we are very nervous about you know the
security because you are really launching something play with
like users assets like users can really deposit our money on your
chain you really need to be responsible.
So we we pay huge attention to like security monitoring system
everything else to to kind of make sure it's a successful
launch we have done like for example we we even like before
we launched we fetched in our testing environment we fetched
all the transactions from from Polygon from finance from from
different chance that to kind of repay our in our testing
environment to make sure that we can generate proof for those
connections to kind of stress test.
And also like we we we spend a quite amount of money on
auditing like internal and external.
Internally we have some kind of red team to looking keep looking
for bugs attacking our our test net and the environment and how
to make thick proof how to kind of attack the system.
And externally there is like we contract the best the word class
level of like auditor like including like open zabling
Zadig for for for node and and the contract auditing a lot of
complaints like that. We also like set up like $1
million back bounty to to for for for the community to support
any bugs in our in our system. So it's like a lot of
preparation and also like we our team has been like you know
talking is a lot of project to to deploy and test their
application on Sympolia. Yeah I think I think it's all
like it's very exciting moment that you turn you literally turn
some open source project, open source demo to a product like
like like 100% like ready products online.
So I think that's a very very like incredible journey for me
and also like you see like your your research results from from
paper to a product and used by a lot of people.
So it's it's it's quite exciting and we are really looking
forward to kind of things after like you know how we build the
community how we keep improving attack.
Yeah, I think it's yeah it's it's really a moment that we we
can't we we will remember like forever like you know it's
launched and very exciting. Yeah, congratulations on that.
Tell us about the Scroll community.
So kind of who is your community and do you have people who are
building on Scroller exclusively?
Yeah, yeah, that makes sense. So first thing I think my
definition for community is that there will be like engineer and
researchers who are part of like they can build their own
product, they can build their own project, they can do their
own research. But we we communicate, we
collaborate, we talk in the open, we call build some kind of
talk about some some benchmark stuff.
So those are I think are part of our community And by for example
we are hosting ZK symposium which is like like due to the
money that is currently recently reducing frequency a little bit
but we will catch up very soon is that previously it's like
biweekly cadence where we invite the ZK researchers and
application developer to talk about their idea for building ZK
like what application they are building using is AK.
Because I think a lot of if if you look at Twitter like all the
kind of places where people only like talk about like some
marketing material. We'll talk about how great they
are like how how fast they are like why they can achieve like
you know 100% privacy all those stuff.
But no one really dig into details about the architecture
and want to build a like a place where people can like dive
really, really deep into like what they are building and the
architecture stuff. So I think it more happens in
like Zika study club where people dive into like like very
academic papers, some mathematical constructions.
But very few people have some place to share very deeply about
Zika application ideas like how they build this app, Zika
application, what technology they are using, what the
architecture look like. And then that's where Zika
symbolism sit where people have one hour time to present their
idea, be in depth about what applications they are building
the technology and then people can like ask questions.
So I think that those are like in that way we are building our
like research community and also because everything is building
the open like as I mentioned like our our the key VM reuse
all the toolings from for example like the pre library
from from the cash team. And there are a lot of other
teams like also building on top of this this this crypto library
that those are also I as part of our community like the key
community to to build that's what one part and second part is
more like developer community where people deploy the
applications and we introduce after after Minet we introduced
something called scroll or Ranger NFT.
So you really I'm not a big fan of of of this kind of NFT thing
but it's actually a SOAP bound where if you deploy applications
you you you are early in our ecosystem you you can claim
you're like you know one really cool scroll or Ranger NFT from
from us I think that's design. I don't know if you have noticed
that it's totally different from like just images like you really
have to just images stored somewhere else and then you put
some kind of link on on chain which is a a fake FT What we do
is that we do something similar to like Unicorn with three which
is a generative curve. It's a polynomial where if you
deploy a contract you pick because the time you deployed
because of the kind of the sequence like how many contract
you are deployed. Then like you can get a
different polynomial and then like we can draw this polynomial
like on chain like you know you get a different like I think if
you deploy earlier that the the degree will be four or five I I
can't remember. So it's like you get this kind
of curve with with different like so many kind of turning
points and to show that you are early in our ecosystem and we
really appreciate our effort because you know being in a
ecosystem early it definitely introduced some risk for OK, so
whether it's better tested or not so we will come the early
builders to to join our ecosystem that's only for
welcome and like to prove that you are you are there and you
are there earlier. And so like everything we do is
like I think it's very cool and very it's based on like
fundamentals that make as possible which is 0 know proof
and polynomials and then like you know application you deploy
you got a polynomial you got a NFT like you know which draw
this kind of really cool polynomial.
I think that that that will definitely introduce some kind
of a lot of people are just trying to trying to kind of
deploy maybe a bunch of like ERC 20 contracts but that's within
our prediction our our kind of motivation objective is that
encourage more people to try deploy your first first contract
and in a neutral way it's not like we select or we give you
this we give you that in a unfair way but we we are more we
are we we want to hold this kind of like a blockchain's principle
of being credibly neutral and then people every people you
deploy you you can get something as and also experience like how
seamless that is. So I think that's that's
something like which there are some community from there and
also like there are some more native applications which we
share the same value. And then they believe that you
know we believe our value of being open, being commit driven,
being credibly neutral. And then they come to us because
we we we don't provide brand to applications specifically
because we think that will make your ecosystem become a 0 sum
game because basically like there will always be new chance
like new layer one, new layer two.
They always launch their, their token with they they raise a
lot, much of money. They can give a lot to, to a new
developer. Like I give you this money you
come to our chain to deploy but then like it will become a
competing game which I give you this amount the other chain give
you that amount and then you go to the other chain.
And it seems like it's not like we are we are making the whole
ecosystem grow. We are like making this kind of
small pie for crypto larger but it's more like I want to compete
with with with each other. So what we want to do is that we
want to attract. We want to focus on like
building stuff and attract more organic community where you know
they are very organic, attract the best because they see like
there is a huge opportunity I'll scroll by being early and and
also like it's one of the most legit and general purpose like
top top layer two and there will be a huge opportunity there.
So what we are focusing on is that we introduce we we make we
get everything ready for developers for example like we
have ether scan support so users and develop can use your most
familiar infrastructure. We get chat link as Oracle
support which means like you know all the kind of defy can
use your your most familiar Oracle.
We get we get all the kind of indexing RPC provider ready.
So that's something we will focus on like build a
environment that developer are easy to build but we don't like
enforce you to to build like what we want.
We we just create this kind of foundation.
We keep improve our documentation tutorial workshops
and then like a lot of people are actually attracted by this
it's like for some more like commercialized application for
them. One is there is versa like you
know there are some other one is which are native to school and
there are some like new D file like coke finance and some other
financial applications on scroll.
And amazingly it's like a lot of like small AI games like
happened to our scroll like I think days ago like I don't know
who build this but it's like there's a game called chat MPC
where you you chat with with the AI image and then like you could
try to negotiate through this conversation about how much you
can get the and then like you end up if you end up being being
high you can get some score. It's it's very simple game but
it's very fun. So I think being fun is really
one important. Way to attract attract builders
I I think a lot of I know like a lot of like applications are
still building the because the more serious and more like
commercialize more ready the project is it will take a longer
time to to build and being ready.
But for for every laugh with listening like pay attention to
our ecosystem account our main account you will notice a lot of
good opportunities good projects at building on top of us which
will come out in the next few months and in terms of like also
support a lot of grassroots hexons.
We have been I I think we we probably participant over like
20 hexons maybe like around the world like everywhere almost and
then like we a very recent one is at East Global in New York.
We it's the first time that we surpassed all the all other
chance in term of deployment and with small price.
So you already like you know it's it's not just you know
people offer high price or people deploy on you.
But if I realize EVM and then like you can provide something
kind of subtle changes or like something cool like you got the
most deployment And then like it's very welcome in this kind
of hacker group And it's very exciting because it's even like
before our minute launch where a lot of other chance have all
those kind of even better infrastructure support but we
can still we get so many hackers interesting kind of building on
top of us. I think it's definitely
something like which we are kind of celebrating like because this
is very organic grassroots hexon project.
I do believe that in this way like you can you can grow your
grassroots community to a large extent.
So those are like the all developer communities we have,
you know including like as I mentioned like some wallets,
some some games, some some kind of like DF applications and
there's a lot of Hexon groups. And the other other step, I
think looking forward we will expect more regional community.
So we will start seriously building community in several
places including like Turkey, Nigeria, Malaysia and Argentina.
That's our our, our plan for like we are.
We seriously want to put some efforty to grow the community
there because our our our mission is really to scale to
scale Etherium to sometimes like you know if you have like we
want to codify trust and like empower this ownership for for
individual and chief financial inclusion.
So and you see that all the blockchains are not scalable
enough for BF users for even like they they don't even know
like where all those run BI users come from.
So we have very clear goal for how to guide those users because
the the the users like we need crypto app where the 1 billion
people really come from. And you do see like you know in
US, in even in China, in some kind of other more like in
Europe a lot of places people don't really need crypto and
because they have really established like financial
system they only do that for cross-border like you know
payment and maybe people use that.
But in a lot of places like like Africa like you know I have been
there for for for 10 days for this year to trip and to really
understand like how people are using crypto in practice.
You figure out that a lot of people are really suffer from
this kind of currency inflation and they have a lot of problems
that can be tackled by blockchain.
We really want to kind of help those users and onboard user use
those users to ECM ecosystem. So that's why like we we
selectively choose those places which they suffer from the the
problems of and they have really need for crypto And then like we
want to double down effort in building regional community.
And eventually I think I I'm imagine like in a few few months
or like a few years school will be think about as a the layer
tool that has the most real users coming from developing
countries from from from from someplace in Asia some.
So all those places where if application come to deploy they
know that there is real user there.
It's not just the same group of people like in migrating from
this chain to that chain because it's a new chain.
So that's our like mission and I I consider that to be part of
our community but we are still building that we we just start
on Turkey but we was like putting somewhere like.
So if you look at like you know this year a lot of like project
was out to from from from DEM connect but we are still like
building a very very large probably largest ever event
called layer today with layer to beat we are Co hosting that it's
like over 2000 people capacity to to kind of talk about layer
tooth and we are seriously building a commuting starting
from Turkey but other places we will if you are like you know in
the regions you really want to change change people's life
there then like you know you can you can talk with us and we we
we want to kind of build the committee there seriously we are
I think I see like where our community can come from.
OK. So basically what what you're
saying is you're trying to grow the community organically
through culture rather than through kind of like monetary
incentives, which is kind of often the way that it goes in
crypto. Speaking of incentives, what's
this, the token situation First role, Yeah, it's for our legal
reason like you know, we we we haven't like you know, really
publicly. You know, I'm more thinking like
you know, it's more like a mechanism We are thinking about
like why you, why you even need this.
Like you know, maybe there are some reasons for decided
sequencer disapprover, but there might be some other other other
models for that. So I think we asked you thinking
through what's the best mechanism and and like incentive
a model for for our system to work the best instead of OK so
just this this this token thing. But yeah we we we have been
working on some mechanism design which aligned with our system to
make our system become more stable and more useable.
But you know for some legal or some some other concerns like
you know we are not yet. But but currently.
Yes on scroll is paid in East, yes yes.
You already alluded to it in your last answer.
You currently still have centralized sequences.
It's kind of it's been normalized over the last like
year or two. But in principle, what it means
is that you kind of you have one or several permissioned
sequences, people who can, or entities who can actually build
blocks, which is very much not. What block chains should strive
to because kind of in the in terms of decentralized
decentralization, kind of your least decentralized component
kind of determines how decentralized like the entire
system, right. And so if you have one
centralized sequencer, you have essentially the entire chain is
built by a single entity. What, what are your plans
towards decentralization? Yeah, that's a great question.
So I definitely agree that you know that's in some sense like
it's different from like whole. Normally like a layer, layer one
blockchain works and like why only a few parties can can
produce block. But I think when I think about
this desensitization problem, I I think about like you know
again like from first things for like why you need
desensitization. And there are several reasons
like in layer 2 contexts specifically they are like maybe
maybe 3 aspects. I I think one is sequencer who
generated block for you. So who can you know produce a
block and like then pass that prover.
Prover is basically generated. They keep proof for each block
and to prove that OK so all the transactions at this block is
valid and then like finally some in this, this, this block and
the proof on chain and then on chain.
Verifier will verify this. So there are two parties, one is
sequencer generate block, one is prover like generate proofs.
And two parts definitely need to be decentralized but for
different reasons. So for for a sequencer the
reason is that so actually like one thing I can just to to add
to this is that even if we are using a centralized sequencer
like what every layer twist is doing is that it doesn't
influence your users fund security.
Because if you think about like So what what the bad things can
do like from a single perspective.
So you can set a transaction sequencer includes that
transaction block, prove our genet block, genet proof for
this block. So if if we are operating a
sequencer we want to do something bad right.
If we insert a bad transaction then we can't generate proof for
this bad transaction. Because you know the case the
key proof, well kind of only attached to like the right
transaction, the valid transaction.
So we can't insert any bad bad transaction.
So that's number one because of the key proof you can't do
something bad. Second thing is that what you
can do is that you can censor transaction.
If users send their transaction to a centralized sequencer, send
your sequencer say no I want to include you and but that can be
like you know solved by OK so if users find that one one layer to
accept their transaction, it can send this transaction on chain
and then like layer one like verifier where you force that if
you don't include this transaction in maybe 20-4 days
that anyone can send me the block.
So in that way like you know you can't avoid this kind of
censorship resistance problem like and and users will never
suffer from the problem of you can't withdraw fund because you
can always do that we can't you know even if you reject like you
you can you can do that and then so let's go back to so
sensorized sequence of that influence the the system's kind
of security but what it really influence is that there are some
censorship like real time censorship resistant problem.
So imagine like you know you will be liquidated in your next
one minute you send a transaction to to deposit some
money, but that we reject and then you are liquidated.
And then even if like your transaction is like guaranteed
to be included in in next a few blocks, it doesn't really matter
because you're already being liquidated.
So that's a problem and that's where you can you decide
sequencer to to to help. But again like there are still
maybe some other way to solve this problem.
Maybe you can encrypt your use some equipment pool where you
increase the transaction where sequencer can distinguish which
transaction which and that it had to include and then like
after decryption, you know like what's what's he included that
can also solve this problem right.
So like it's decimation. Sequencer is a tool not like we
have to kind of oh we we have to for decimation we decentralize
but it's for solving some problems and we we do think
that's a promising way to solve this real time censorship recent
problem. And also there might be some
legal legal issues where there are multiple like you know
entities running sequencer in different regions than like
there's a risk for like being more censorship reasons can be
reduced. So that's for sequencer and for
the prover there are some kind of problems The thing that you
can solve is that it can it can be very scalable where imagine
that there is a network of of of minor or or prover running
running or kind of proving proving algorithm.
So it's very different from proof of work, even if you also
have a high requirement for hardware because they give proof
is that like proof of work is basically like 10,000 people
computing for the same randomness and then who get the
answer who gets some meat. But the key proof is that you
have a fixed deterministic algorithm and anyone can execute
and get it and that's it. So it's it's it's quite
different. And so in terms of it's more
like outsource computation, outsource this useful
computation to the provers. And then like having this
essential prover network can help you to kind of having some
backup if you know one prover party just like goes down and
then like other other prover can still generate proof for you.
So you have some backup, you have some more stronger liveness
guarantee. And also you don't need to buy
machines yourself, it's more scalable, like people can use
their own machine to generate proof.
Yeah, it's more resilient. So kind of to to actually gain
the forced inclusion that you talked about earlier if you're
being censored on on the A2? You need to make all transaction
data available on the L1. So basically this is kind of why
we're now getting Deng sharding with blobs, where kind of data
is going to get where temporary data is going to get much
cheaper and so on. But it's still the main cost
driver for L twos. So it's on the order of 95% or
upwards of that as compared to kind of just?
The check insurance that you kind of need to do to kind of
prove the state right. So there's a couple of L twos
that kind of have gone the villidium route recently where
basically they decided to not actually post all transaction
data to L1 just because it kind of drives up price on the L2.
Currently prices aren't crazy, but I mean they have been crazy
in the past. They have probably become crazy
again at some point, which were kind of mean.
That lots of applications that are currently viable, kind of
like the AI game where you kind of you negotiate with an NPC,
they will no longer be viable on L2, right?
So what's what's your strategy there?
So I mean basically even when den clotting comes, call data
will become maybe 10 times cheaper or so, but this is still
pretty expensive for lots of applications.
So what are your thoughts on kind of going the Validium
route. Yeah that's a that's a great
question. So I I think for this with Idi
think so I I think with DDM definitely trade off some
security for being cheaper. But for for us I think currently
we are sticking to I I think schools mentioned we'll stick to
posting data on ECM and strictly you hide the same security from
ECM. So because because our I I think
for most of the row up, like different row up can have
different value proposition. I think for us it's always like
security first is always like drive most of our design
decisions including like that's why we we do this auditing this
way. We open sourcing this way.
We have backbounding this way. So it drives almost all the
decisions because we do feel like there will be a a crucial
amount of applications that need this level of guarantee and then
like we we we make this become our first priority.
So for a lot for for quite a long time we will stick to this
like approach and get the what we what we think is that I think
we're telling you recently just post A blog post about like
different layer tooth and there is actually a spectrum for what
applications need like on the on the kind of left hand side
there's a key store you know which is the the fundamentals of
of all the smart contract wallets storing their keys key
mappings, key value mappings which need extremely high
security and then there's ENS which store your identity
information. And then the more on the left
side the the higher security you want like maybe C5 institutional
money and some government we they want to kind of issue some
something important they need security on the right hand side
it might be gaming like some NFT or some kind of those things.
I think our value polarization is that score man chain will lie
on the left hand side where we want to kind of attract more
security driven applications. And then like you know if that
Shard is not there yet we we we might spare some effort in
helping ECM to kind of build this solution for for for all
for everyone in the whole ecosystem.
So that's that's our goal like in the whole how we handle this
situation and if if we really reach the point for where that
Shard is not even enough. I do see like maybe some some
other teams building layers 3 on top of us they can be validium
they can kind of you know do other trade-offs that on top of
us they can even use state diff host data on in a different way.
But that that's what I see like you know how this world world
goes it's like we will remain a very very high standard for
security to attract the most kind of legit large the most
fundamental applications. And then like if you if game
really really require you know like high high throughput or
like extremely high throughput or like that saying they can
build a layer three as well idiom on top of us and like yeah
I think it can be either can be layer three or some other other
side solutions like at the same secure level.
We were trying to kind of reduce the cost like when we are also
working on data compression like how you kind of compress the
data you post on chain. So there are some way like which
which you can reduce your your data post on chain become like
three times smaller. So there are some way for for
doing compression. We are looking into that how you
reduce the bridging cost but everything like stands like it
can't. Like you know security should
should always be the baseline and this would be never
something we will compromise. Do do you think we'll be able to
do data availability optimistically at some point?
Because that would solve a lot of problems right.
So I I I think it still depends on the like secure assumption I
think for to me like you know I think for schools man chain
like. So firstly I I don't see any
kind of very very well established like optimistic
database solution even if it's like you know there are teams
like Igalias last year is building some DA solution.
But I think it will still take some time to test whether this
works or not whether there's some other issue related to
because I know like you have been running this infrastructure
layer one you know like how many things subtle things that it
needed like there's Oracle RPC provider all those things might
require direct access to the data and ideally on the same
chain. So you don't know like if you
switch to the other solution what the subtle changes you need
to make and whether and I don't think they are all the most of
the solutions is mature that mature enough for for men
chained to migrate from. But I I think we are still
remaining optimistic. We will kind of always pay
attention to like the progress from other companies from from
other solutions. But right now we think you know
it's it's not there yet and we will stick to this kind of
security principle and encourage all the kind of layer three to
consider that as an option if you know you will have some
trust assumption. Yeah, you posited earlier that
there'll be a whole ecosystem of air tools with different trust
assumptions and different associated costs.
I agree that that's kind of like the the goal, but we're
currently very far away from that goal.
So just before we started recording this this podcast, a
tweet from Joseph Delong came out.
And it literally read L2's don't actually skate etherium, they
just fragmented into a bunch of unrelated chains obviously
alluding to the fact that into L2 bridges currently are not
operative. So basically it's a way to kind
of go between L2 is to kind of bridge or higher theorem, which
is obviously very costly. So in principle it seems like.
Bridging across different L2's should be possible because they
have the same security assumptions and kind of building
on top of Ethereum. When, when do you think we'll
get there and how do you see it happening?
Yeah that's a great question. So I think in terms of like in
turbo like between layer Two's, I do think like people are they
are like 2 directions like people are going towards it's
it's orthogonal it's not something that contradicted to
each other. SO11 approach is that as you
described like in all the layer tools are based on insurance so
they post the same state root on on ECM layer one.
So what you can do is that so for especially for the kill up
with with a faster like shorter finality that.
Imagine there's this exam layer, one you you post 22 state root
like the for for example there is scroll there is like the
other chain A&B and then like what you can do to access this
data is that you can read the state root of.
Of another layer 2 from ECM layer one because your route is
also there so you can read that and then provide a proof proving
that the the story slot the element you want to read from
the other layer two is a like provide this Merkel path to that
route and that you can trustlessly read and like
operate over the other chance like state.
So that's how you can do this. Yeah trust this way because
think about like you know two different layer ones because
they have totally different valid like validator set.
You you the bridge had to be kind of like multi seagull some
other like validator network where you don't have this kind
of shared security but for different layer tooth because
you're they could basically you can read the other chain state
through this proof like Merkel path from the other chain then
like but this seems to do some latency because you need some
time to generate proof and it might break the because because
of this this latency and so I do feel like in some sense it's
possible to have some standard in messaging between different
layer tools but it's still not super practical and user express
friendly to kind of do that here fully translated people still
use bridge to to bridge regardless another I I do feel
like you know as a proving technology has been improved as
as you know one layer to become adopting some similar standard
for how you how this communication can happen it
might be solved so that's one One Direction that direction
like people keep talking about is shared about shared sequencer
So shared sequencer is basically like where the same party
sequence to sequence like you know like transactions from two
different chance so that's how like that's where you can if you
want to interact with the other layer two and the same sequencer
know the order so that's like how you kind of maybe possible
like you have. This kind of you know some level
of compatibility between different chains but there are
like still a lot of problem related to this because mostly
shared sequencer are only ordering the transactions they
don't guarantee that like 1 transaction successfully done
like you execute the other it done has that level of
atomicity. So I like both are still very
early. I think we are we are kind of
watching closely to those those research directions but
currently it's just for example building building 1 chain.
I think eventually different layers will have different
communities and it's good to have some standard to talk with
each other because it's read at least compared with different
layer one fragmentation. It's theoretically possible to
to do that in a trustless way, but it it still takes some time.
I mean when you say different L twos will have different
communities, that's kind of at odds with what you said earlier,
that kind of different applications will choose
different L twos based on. The security assumptions they
need, right? So basically I may want to play
some game that doesn't need a lot of security assumptions, but
I still want my smart contract while it living on a different
chain, right? Yes, exactly.
Yes, Yes. I think due to this kind of
different property and assumptions like eventually
different layer tooth will have different like because they have
different value proposition. They have totally different
mission and vision like someone to kind of you know get users
through marketing and that may be part of their brand and some
might you know like want to build a totally different new
community from EVM and but we are like yeah we we we trying to
kind of be more like. But you don't see, you don't see
like the same users kind of using different chains for
different applications right now, yes, it's because most
chains don't have that many, like, you know, exciting
applications. It's like you know this same
suit for for defy and like but I do think like you know as you
know but but you you can feel like different chain had totally
different brand right Like some chance like the first impression
is this some some chance first impression.
This like first first impression for most people is like super
high SEM alignment, high very Regis for their tech and and and
and security assumptions. So if you go to kind of say if
you go to the field in Turkey or Malaysia or Nigeria or
Argentina, any of the countries you mentioned earlier, well
users who will actually use this to kind of solve real world
problems where they care which chain they're on.
So I in my view kind of the the DAP developer will kind of
decide what kind of is the best security or the needed security
model for their DAP and then the user ideally.
Down the line, they won't know which chain it's on, right?
They don't. They don't have to care about
the vibe. It's just like you and I browse
the Internet every day and we don't we don't really think
about TCPIP just happens in the background.
Yes, yes that's the most ideal situation.
So by developing communities there I'm more saying like in
the doing more like developer education and and growing like a
grassroot developer community because what what's different
like in developing community versus developing a global
community is there is that like local community can spot a lot
of like local problems because if I'm I'm I'm here I don't know
if I haven't traveled to those places.
I don't know like you know what people are building there like
what what problem people are facing.
So like getting developer there and like a track value of line
developer there grow community there can help getting more
local developer to build application on top of you and
then like potentially get more users.
So that's also like some. So that's how we grow.
This is not like we are acquiring users and then like
user have to choose their chain. But it's more like from
application level we can kind of help more grassroots developer
to to build to solve local problems and then like users
will use them and then use square as default chain.
So what does the road map look like for scroll?
I think the very very kind of short like technical road map
will be we will use data compression to massively reduce
the transaction cost. So like anyone can expect like
you know transactional scroll will become like you know way
cheaper like in in a few months. And why it takes a few months is
because we were trying to minimize the the frequency for
doing upgrade. Because doing upgrade is very
very kind of scary because you are using mostly things to
upgrade the most important part of your your protocol.
So being cheap using data compression is very important
part thing we will do. And second thing is that we are
keep focusing on improving the security.
So as you mentioned like censorship resistance, we are
trying to like you know have some some solution for that and
this kind of proposed A sequencer failure If if you know
we are not producing block then like what will happen.
So we are we are working on solutions for that that will
also like be solved like in in in around three months like you
know after that large upgrade what happened at that time and
then you will see like layer to beat which is a reference for
checking layer to security like a lot of red area will become
green And also we are exploring how to like even add more
security more than just what layer to be they're talking
about like people worry about like Ziki has bug, Ziki has bug.
So like we have exploring like multi multi prover system like
where we can add another additional prover.
So if they keep that work out the other prover can still be
back up to kind of like make sure like it's secure.
So security is very very important for us and then like
if application care about security they can come to us and
then that that will be a like short term goal.
And for the research we are we have been keep focusing on like
thisization, we will have some proposals published to kind of
discuss very broadly and we we are keep focusing on like
working on the next generation, the key VM to make the key and
become time time faster. There are already some we
designed there. We are still doing benchmark for
which process I want to use, how to architect the next generation
the KVM. So it's also there as a long
term, long term thing and in term of ecosystem community
building. I think we will get all the kind
of necessary infra as I mentioned ready like China just
integrated like days ago and the UNICO pass their governance and
a lot of like basic building blocks will be there like in a
few weeks or so like you know common build.
And then like we will have some like community initiative for
the community to to to interact to to kind of engage and more
'cause on on discord to kind of like really understand what what
our community really need. Yeah I I think a lot of
initiative will come out and also start community building in
the regions we we select and then like double down effort in
in kind of helping builders there to build.
So those are like a a short term like you know yeah and also like
internal security also definitely security console like
which we remove this what is it to some really credible security
console members that they will control like upgrade so that we
are not controlling like the the schools like upgrade.
So those are things where we're having short term like like
being cheaper ultra ultra like high security and also a lot of
community initiative and keep doing research.
So that's for that's what you can expect in in the next like 3
months. And I I, I know a lot of
projects are coming to to scroll ecosystem.
So like follow up like ecosystem account and scroll account and
scroll our our male facial account will man for protocol
upgrade update our our members event Hexas all those stuff
ecosystem we're talking about ecosystem project there's weekly
like what will happen. So if you know, feel free to
kind of interact and then like use what would like understand
what's happening there. And what's the best way to kind
of get in touch is, is there are all the links on your website.
The best way should be like our Twitter where Scroll underlines
AKP is our official account and then there's another ecosystem
account which is build with scroll build on scroll.
I need to check but that's that's like we have another
ecosystem account for following the recent ecosystem updates.
So if you follow that very closely, there's weekly updates
around everything happening on Scroll and we will support multi
language community. So if you are Chinese you are
like Spanish speaking Turkey speaking like it.
Like there will be like corresponding account like you
can follow to know more about school and join our discord.
Definitely yeah. Perfect.
Thank you so much for joining us today.
Thank you for joining us on this week's episode.
We release new episodes every week.
You can find and subscribe to the show on iTunes, Spotify,
YouTube, SoundCloud, or wherever you listen to podcasts.
And if you have a Google Home or Alexa device, you can tell it to
listen to the latest episode of the Epicenter podcast, go to
epicenter.tv/subscribe for a full list of places where you
can watch and listen. And while you're there, be sure
to sign up for the newsletter so you get new episodes in your
inbox as they're released. If you want to interact with us
guest or other podcast listeners, you can follow us on
Twitter and please leave us a review on iTunes.
It helps people find the show and we're always.
Happy to read them. So thanks so much and we look
forward to being back next week.