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.