Anna Rose (00:00:05):
Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we'll be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online.

(00:00:27):
This week, I catch up with Ye and Sandy from Scroll. We check back in on the zkEVM L2 project and find out how it's developed over the last year. We talk about the founding of a fully remote organization, the technical evolution of the project, the ecosystem, and more. A quick disclosure, I am through the ZK Validator an investor in the project, and it's been fun to learn about their progress. Now, before we kick off, I do want to direct you to the zkJobs board. There you'll find jobs from top teams working in ZK. So if you're looking for your next job opportunity, be sure to check it out. And if you're a team looking to find great talent, be sure to add your jobs to the jobs board as well. I've added the link in the show notes. Now, Tanya will share a little bit about this week's sponsor.

Tanya (00:01:11):
Ever feel like developing zero-knowledge proofs is a daunting task? The team at RISC Zero is here to remind you that it doesn't have to be that way. Their out-of-the-box tooling allows developers to access the magic of ZK proofs from any chain without needing to learn custom languages or building custom zk circuits. Bonsai, RISC Zero’s most anticipated product, is a proving marketplace that enables any protocol or application to leverage fast ZK proofs in languages like Rust, Go, C++. Visit https://r0.link/ZKpodcast to learn more and signup today for the Bonsai waitlist.

Anna Rose (00:01:47):
So today I'm here with two of the co-founders of Scroll. Ye and Sandy, welcome to the show.

Sandy (00:01:52):
Thanks for having us, Anna. Very excited to be here.

Ye (00:01:55):
Yes, thanks for having us.

Anna Rose (00:01:57):
Ye, you were on last year in I think June 2022. We did an interview with yourself and your third co-founder Haichen. So that was like our introduction to the project on the show. And yeah, something that I'd like to do with this episode is definitely do a catch up. Before we do that though, Ye. Why don't you quickly introduce yourself?

Ye (00:02:16):
Sure. Hi, my name is Ye I'm the co-founder of Scroll. I work on ZK research, hardware acceleration and prover acceleration, some algorithm side and some application side.

Anna Rose (00:02:26):
Nice. And Sandy, this is the first time you're on the show. So why don't you tell us a little bit about yourself. What got you interested in this space and kind of where was your sort of journey to Scroll? Where did that start?

Sandy (00:02:38):
Yeah, no thanks for having me. So my crypto journey started a long time ago, around 2013 and 14. That's when I first read the Bitcoin White paper. And you know, had that aha moment and just been kind of researching and dabbling and socializing in the space. My first kind of full-time crypto job started in about 2017 when I became a crypto investor full-time and the journey for Scroll started when I was getting deeper and deeper into protocol level research. And it became very clear to me at the time that Ethereum was gaining traction, both as a protocol and also on the social layer. There were just the amount of talent and creativity surrounding the main protocol was astonishing. And I kind of came to this realization that this was the future of the crypto space, and I wanted to see whether there are any kind of major open problems I could contribute to. And that's when I met Ye and Haichen, we met online and we didn't actually meet in person for the entire first year of working together on Scroll.

Anna Rose (00:03:50):
Whoa.

Sandy (00:03:50):
Yeah

Anna Rose (00:03:52):
But you were not anons, you knew each, like you were yourselves, I guess?

Sandy (00:03:56):
Yes, yes, yes. So well, yeah, couldn't have been an anon because when we met he had a paper pending publication on prover acceleration. And that's how we originally found him. And Haichen was working at Amazon at the time you know, as a system architect. And he worked on a lot of the stuff that we're currently using for Scroll.

Anna Rose (00:04:21):
Hmm. This is actually interesting, the co-founding online. How, like, where were you chatting? How would you have like, met and almost like vetted each other just online?

Sandy (00:04:34):
Yeah, I think there's, with every kind of meeting, there's always a little bit of serendipity involved. How does anyone meet anyone in this day and age? So it starts with, with an online conversation, and then there are some like offline connectivities and personal relationships. And so initially I was connected to Ye through one of our mutual friends and you know, started talking online for a really long time and then decided to kind of go for it, you know, what was the Scroll project at the time. Like, almost like very quickly, but it was a research project and then just, you know, it just kind of continued to snowball from there, really.

Anna Rose (00:05:19):
So I really liked that idea of like founding a company purely online where you don't, I mean, I guess it's like what year was this that you were starting to look at this project?

Sandy (00:05:32):
It was during the peak of Covid, so it was about 2021. And I think it's the same process for most of the people on the team. I think there are at least half the people on the team whom none of the co-founders have met in person in the first.

Anna Rose (00:05:51):
Wow.

Sandy (00:05:51):
You know, and it's still very common for us to

Anna Rose (00:05:54):
Yeah. Yeah.

Sandy (00:05:54):
Not meet someone in person until, you know, three or six months after they've been working with us. We're very decentralized as a result of this kind of type of origin and we have members from every continent apart from the Antarctica and so spanning over

Anna Rose (00:06:14):
Yet

Sandy (00:06:14):
Yes. We'll see. Very keen on, you know, taking over that piece of ice. But yes so essentially I think that's part of our founding DNA and that's resulted to you know, Scroll core-contributors being you know, all over the world. Really.

Anna Rose (00:06:36):
Cool. And so you sort of mentioned that you were excited about Ethereum. This is like the project is kind of coming out of the Ethereum ecosystem, but like, what was, like, had there already been proposals for ZK EVMs at the time? Or things like Scroll that you were playing on or use, you know, kind of being inspired by?

Sandy (00:06:55):
I can talk about it from my perspective. I think there's already been a few L2s that are ongoing when we started. We were inspired by a lot of years research and a lot of the research that were coming out of academia at the time. And we thought there was something that we could offer both by means of outsourcing proofs offline and also this way of organizing a completely open source kind of effort. So maybe Ye can talk about his experience as well.

Ye (00:07:28):
Yeah, yeah. I think what, by the time when we started, as Sandy mentioned, there are several Layer 2 efforts, but I think none of them are really building a like EVM by code level zkEVM. So some, I think the most, the closest one is building a language compatible, but I think we are targeting a deeper level of compatibility, which means we will suffer from a larger proving overhead and like much more engineering work. And we kind of make sure that we can, through hardware accelerations, through this crypto like advanced crypto algorithms can make the efficiency become like order of magnitude like better than before. So that's why we start this. And with the deepest level of compatibility,

Anna Rose (00:08:11):
Had things like Jordi and the Hermez zkEVM proposal already come out when you guys started, or was it happening at the same time? Like, I know that there was like the sort of, I don't know if Starkware proposed something, but it was like, I know zkSync could proposed something, but there was all these different types of zkEVMs. But I do wonder, was there anything like yours or was, was your research kind of like really this new direction?

Ye (00:08:39):
Yeah, that's a great question. So I think the very original story that we start with something our own version of like how we build a virtual machine, maybe the zkEVM or like the key virtual machine and we can make this really efficient through hardware. So that's our initial version. And then like I talk with Barry Whitehat at the Ethereum Foundation and he's thinking of exactly the same idea of building the zkEVM for Ethereum Layer 1. And I think our idea overlaps a lot for like why we think supporting a virtual machine is possible. And then so our like collaboration start very organically, like with, with Barry and with Ethereum Foundation, and I think there are some nice idea for using lookup tables to handle the virtual machine memory part of the zkEVM. I think the same idea also inspired Jordi to start the zkEVM. So I think they

Anna Rose (00:09:33):
That's kind of how it comes from. Okay.

Ye (00:09:35):
Yes, yes, exactly.

Anna Rose (00:09:36):
Same original source, but like kind of happening at the same time.

Ye (00:09:40):
Yes, you got it.

Anna Rose (00:09:41):
Cool. Yeah, actually we will add a link to the previous episode. What I wanted to actually do, at least with the first part of this was do a little bit of a check-in on some of the decisions that were kind of being discussed back then. Like I wasn't sure if those were like finalized or if they were like still in the works or if things had maybe changed. So just a quick throwback a year ago when we talked about kind of what was the underlying ZK stuff, it was like PLONKish arthimetization and Halo 2. Is that still what Scroll is based on? Or has it brought in, I don't know, some of like new techniques or other proving systems?

Ye (00:10:19):
Yeah, I think the tech stack is still like remain the same. Like we are still using PLONKish for writing our circuits and using KZG at the back end, using Halo 2 to write our circuits. But huge improvements have been made on the completeness, performance and the robustness. So for example, on the circuit side, I think when we talk, we implement the majority of the circuits, but there will still be some circuit left. And by now we have already implemented all the opcodes, all the error cases, and they have already been sent to the auditors to audit. And on the prover side, I think we make extremely fast GPU implementation to make prover really fast and also we publish our paper. So I think by the time we talk, we only have one paper talking about how you use FPGA ASIC to make prover faster.

(00:11:07):
Now we have published another paper talking about how you use GPU to make prover faster. And also we done a bunch of ZK research, reducing the memory consumption and also the recursive cost. So basically I think the day one we are running our zkEVM full version, we require like one terabyte of CPU memory to run such a large gigantic circuit, but now we reduce that to only like hundreds of gigabytes and we are still keep improving on that.

Anna Rose (00:11:33):
Wow.

Ye (00:11:34):
And as for, as for the tooling, I think we are using some derivative of Halo 2, which is called Halo 2 CE. It's CE referred to a community edition. So it's a derivative version from the cash branch and because they make many changes to this library, and also we want to, because it aligned with our philosophy to always develop with the community and sharing all this like proving stack and all the tooling with the community. So it's a community effort to own this proving stack and we are leading some discussion to add more components into this library. I think a lot of project actually reusing the same proving stack like people are contributing to that, even for some new like optimization from FRI it's totally different, but people are still implementing like Goldilocks Field, FRI Gadgets to this community owned the library. So yeah, that's like aligned with our philosophy a lot. Yeah, that's on the ZK side.

Anna Rose (00:12:32):
Cool. I want to check the naming really quickly. Halo 2 CE?

Ye (00:12:36):
Yes.

Anna Rose (00:12:36):
Is that what you said?

Ye (00:12:37):
Yes.

Anna Rose (00:12:37):
What does that stand for? Community

Ye (00:12:39):
Edition.

Anna Rose (00:12:40):
Edition. Okay.

Ye (00:12:40):
Yes.

Anna Rose (00:12:41):
And is this sort of like, I mean, is this the, the work that like PSE, the, what is it, Privacy and Scaling Explorations group from the EF and 0xParc had been kind of like championing? Or is there one track? Is it yours? Like did it also branch out into other ones?

Ye (00:12:59):
So originally we are using a fork of Halo 2, and the upstream is in the like PSEs GitHub library and we, we just changed the economic commitment part from the inner product argument to a KZG, but then we want to make this more modular and shared by even more projects. So there depends on like, you know a separate organization called Halo 2 CE, and there will be more project contributing to this library like for example Axiom and some other like, you know, projects are contributing to this and we are leading some kind of more open discussions about how we can improve this library. So initially it start with we want to use the zkEVM, we want to use KZG, so we use this for and then we want to make this more modular and like more people can use that. So that's how it's branched out.

Anna Rose (00:13:49):
How do you sort of split your time in that regard? Like as a development, like you're developing like something, you have a goal, but at the same time there's like a lot of research and work that could potentially contribute to other projects. Like would you say you as a research team are like super focused just on the things that you need? Or do you think it's a little bit more fluid? It sounds like you're also contributing just kind of more generally?

Ye (00:14:12):
Yeah, I think our philosophy like trying to support open source and more community driven and shared like tooling stack. So we are happy to kind of either contribute to this like shared infrastructure and even upstream to the upstream, which is initially developed by the Zcash. So yeah, we definitely like spend a lot of effort on like how we can like maximise like different projects like, you know, progress compatibility and also like, because it also enhance our security, right? Because if many people are like reusing the same proving stack, like there will be more people, more eyes looking into a code base and review, you also get to share like you know. So that's our philosophy.

Anna Rose (00:14:54):
That's actually an interesting incentive there, the idea that like you may actually just want to make something more general to be used by more people.

Ye (00:15:03):
Yes.

Anna Rose (00:15:03):
So that people try to break it early. Right? I feel like there's been some chats actually in the ZK channels right now about like security of some of the systems that a lot of things are being built on. And I do think if you can have more eyes on it, obviously that's a really good way to like, hopefully spot bugs early. You talked a little bit about the GPU implementation. This is for the verifier or the prover?

Ye (00:15:27):
Oh, this is for the prover, like how you can make prover journey prove faster.

Anna Rose (00:15:32):
And when you talk about a GPU implementation, is this different from the rest of your tech stack? Is this like some like lower level, like how to better interact with a GPU? And I guess the second question is to this is like, do most rollups in zkEVM teams need to do that? Because I don't think I've really heard about like the teams themselves working on the hardware.

Ye (00:15:56):
So you can imagine that, you know, when you are running your algorithm initially on CPU for example, it takes like one hour to generate the proof and you think it's, it's, it's too slow and you want to, to utilize the parum inside the approving algorithm. So you incorporate the GPU into your like CPU device and like, you know, it just connected and then you will outsource some very expensive computation to the GPU. And GPU is very good for doing some paralyzation work and it and it can do that very well. And the most computational heavy part inside prover is paralyzable. So it's very easy to accelerate that on GPU. It can make, you know, become like 10 times faster. So you are basically the high level idea that you move the most computational intensive part to GPU and the GPU can make that faster. Yeah.

Anna Rose (00:16:46):
That's what you are doing? Like on the software side, you've made the decision what needs to be used by GPU and what is it?

Ye (00:16:52):
Yes, exactly.

Anna Rose (00:16:52):
But are you actually dealing with like how the GPU processes it as well?

Ye (00:16:57):
Yes. We also need to implement like how you kind of run this on GPU you need to design the kernel implement using CUDA. So yeah.

Anna Rose (00:17:05):
Oh, wow. And yeah. Then I guess the second part of that question is, is that something that a lot of zkEVM teams need to be doing? Or is it because you had this background in hardware that we talked about in the last episode that you were like, oh, we're going to also do this hardware part?

Ye (00:17:19):
Yeah I think for GPU it can make all the zkEVMs become faster, but I think currently, currently, from what I know, most EVM teams are using GPU's, but some don't need because it depends on like your proving algorithm if you heavily rely on some kind of elliptic curve-based operations which can be massively paralyzable and can be considered really fast on GPU, but if you are relying on more like smaller field hash function, then maybe you can run that on CPU efficiently. But I think overall if you have GPU it can always be faster in most cases.

Anna Rose (00:17:56):
Okay. So I guess most of the zkEVM teams, if not building it themselves, will be using some sort of open source

Ye (00:18:01):
Yes.

Anna Rose (00:18:02):
Version of this because it's kind of an inevitable thing. Do you feel like this is just part of the engineering challenge in general? Like this is where you can get some improvements so you will inevitably want to go for it?

Ye (00:18:12):
Yeah, I think it's definitely part of the engineering effort, but also like one direction we are working on this, we should also align with our like decentralization philosophy that we want to reduce the requirement for like, you know, for example, the memory requirement for GPU and we are trying to lower that requirement, for example, like maybe miners because people believe that you will move from Proof-of-work, you will have a bunch of GPUs and one direction might be how we can adapt our algorithm and generalize this algorithm tend to adapt to other cheaper GPUs so they can still reuse their machines to run our premium algorithm.

Anna Rose (00:18:48):
Like I've done a few episodes recently on hardware kind of looking through the lens of the ZPrize efforts, do you feel like, do you expect sort of just like a standard for how GPUs and ZKPs are going to be used? Or do you think that there's still a lot of room to like develop unique solutions there?

Ye (00:19:07):
Yeah, that's a great question. So it depends on the algorithm. I think eventually it'll become a problem which involves software and hardware co-design. So for example, like, you know, recently people are really creative about Nova and you might need some special components for making Nova faster. So because they're proving algorithm, they keep, you know, evolving. So it's very hard to say that, you know, oh, "this is your final version of GPU". But I think most algorithm are reusing almost the same like primitive like FFT multi-exponentiation and some vector level computation, maybe some hash function. So I think the large modules are fixed, but if you really want good performance, you need to twin like, you know, the workflow and for your proof system. So I think that haven't been fixed. It depends on the software stack. So eventually it'll become, I think a software and a hardware co-design problem.

Anna Rose (00:20:02):
But then do you think it won't be GPU and you'll just like move towards FPGA and then ASIC like just if if it becomes a little bit more, you know?

Ye (00:20:12):
Yeah if

Anna Rose (00:20:12):
I think if even you can like figure out which things you need to focus on, could you start to go in that direction?

Ye (00:20:18):
Yeah, yeah, definitely but I think in our current version, we are still mobilization, like using GPU for short term because firstly like people have more like general prepared GPUs inhouse and they can run prover

Anna Rose (00:20:29):
True, true

Ye (00:20:30):
Without buying like expensive at FPGA and ASIC and also one iteration from our conversation with different hardware company that single port FPGA is very hard to beat GPU performance. You have to connect many FPGA boards together to beat one GPU performance. And ASIC might be better. So long term it might be ASIC you know, if you are like kind of having one protocol become dominant protocol and they are ASIC for this protocol, then that might be the best combination. But now like, because algorithm hasn't been fixed, then the GPU is still general prepared, people can buy that. And so I think yeah, yeah, short term we are still more,

Anna Rose (00:21:09):
Yeah. Cool. Sandy, I want to sort of ask you a little bit about the kind of ecosystem and like Scroll world since, I mean, you weren't on the last episode, but like since maybe you started when you first founded the company, was it just the 3 of you or was there already a team and like how has kind of the world around Scroll evolved?

Sandy (00:21:30):
I would say day one there was just the 3 of us and but the snowball effect happened very quickly and I think the first turning point was when you know, I think as Ye mentioned that when PSE team, when when Barry started supporting the project and we very much became a global community effort overnight. And having that, you know, very strong partnership meant that we're able to scale and gather resources in a way that wouldn't be possible otherwise. And then I think the second turning point was when we started having an MVP and when our vision started become clearer and the vision was to build a product that mirrors the developer experience on Ethereum Layer 1 as much as technically feasible. And once that positioning is clear, it started attracting more and more talent who are like-minded and who also sees the same vision.

(00:22:34):
I think that the wider vision is that we're in the first of 9 innings of the, you know, global, you know, if we think blockchain will be the value layer of the internet then we're in the first of 9 innings and if we're able to kind of have the leg up of inheriting all the tooling and all the great things that have been built on Ethereum over the last few years, then we're off to a good start, but it's still a start. So I think once that vision is well articulated and you know, shared within the wider Ethereum researcher and developer community, we started to see a effect where people are applying to Scroll and people are reaching out to us on Twitter. And I think from early on we had this policy to hire the best talent globally, so you're not restricted by where you live and you're not restricted by your identity.

(00:23:33):
And obviously we do KYC on anyone that joins us full-time, but essentially we started building this culture of like hiring straight from Twitter and hiring straight from Discord.

Anna Rose (00:23:42):
Oh yeah.

Sandy (00:23:42):
And that was very energizing for a lot of our community members who can see people who actively contributed to open-source research. So this is kind of I think one thing I often explain to web2 people how Scroll has grown so quickly in head of headcount is that, you know, the great companies from 10 years ago all built from a very kind of employee:corporate structure, but now we're very much a kind of, you know, we need to articulate our vision and set up in a way that anyone can see what we're building kind of week to week. And anyone can catch up and contribute as they as they wish.

(00:24:20):
And if someone does have value to add to the process, then we'll bring them into the, onto the core team and train them and equip them with whatever they need to like succeed in this endeavor. So I think that's how we quickly scaled. And we have a 40+ engineering team now and I think it's,

Anna Rose (00:24:39):
Wow

Sandy (00:24:39):
It's very difficult to find ZK engineers and especially ones with prior experience. And and I think that's very much due to, you know, one is the division and the architecture that Ye has so well articulated. Another thing goes to kind of Heichen's ability to, you know, run an agile process, run a global development engineering team and making sure everyone is, you know, well supported to work on this. Really.

Anna Rose (00:25:11):
Yeah. How do you do that? Like, especially if you're, because yeah, you are, you're more, I think of you a little bit more on the research side.

Ye (00:25:20):
Yes.

Anna Rose (00:25:20):
Is Haichen more on the engineering side?

Ye (00:25:23):
Yes, exactly. Haichen leads our engineering team, and I'm more on the research side and protocol research.

Anna Rose (00:25:30):
If you're like getting kind of contributors in, are you growing in a very like flat way or is it sort of like you're starting to create these structures? Yeah. I'm just curious how you do it because like, I guess how big were you last year?

Ye (00:25:42):
I think last year when we talk it's around like, it's still like 30 or something, researcher, engineer, but it's like,

Anna Rose (00:25:50):
Okay, you've grown by 10. Okay. So it's not too much too crazy. Yeah but

Ye (00:25:53):
That's only, only technical. But

Anna Rose (00:25:55):
Maybe just from that starting point to that Yeah. Like from that starting point of just like a very small team to the 30 or to the 40, actually, I think there's a lot of teams out there who could really, like, who potentially really want to know how you did that. Because I think there's sometimes it's hard to maybe create those structures on the fly as you're going really quickly.

Sandy (00:26:14):
We have lots of mini teams. It's not like, you know, there's the zkEVM team that collaborates with the PSE very closely. And then there's the infra team.

Anna Rose (00:26:23):
Okay.

Sandy (00:26:24):
And then the hardware team is part of the infra team that talks very closely to them. And we try not to have teams to across more than two time zones in order to make sure everyone has a good work-life balance and

Anna Rose (00:26:38):
Interesting.

Sandy (00:26:38):
We're also starting to have some kind of regional kind of city offices. So we don't have any city where more than 3 'Scrollers' right now, but we're starting, we have 3 in New York and we have 3 in San Francisco. So we're in the process of setting up like many kind of co-work offices. And we're hoping, you know, the, at least in New York, one has proven to be a reasonable kind of hub for ZK researchers to stop by and hang out and we're hoping to have more of these types of kind of pop-up offices everywhere.

Anna Rose (00:27:11):
Nice. Ye, on that research front that you're kind of more in, would you say like you have your inner team, the folks that are on the Scroll team, but I feel like you must, I mean you, I've seen you actually collaborating with lots of different groups. How does that all work and like yeah, I'm kind of curious like how much of the new research are you letting in? Like is there a point where you have to kind of cap it and say like, we can't do any more changes, we can't add any more of the like, cool new stuff? Or are you, do you feel like it's still very, very fluid?

Ye (00:27:41):
Yeah, that's a great question.

Anna Rose (00:27:42):
I feel like there was two questions in there. Sorry there's like, there's like, what's it like working with other researchers outside and inside and then there's how are you incorporating new research? Yeah.

Ye (00:27:51):
That makes sense. Yes. So the way like we are like operating on the research team is that we define some larger scopes, for example, like there is ZK research working on like more efficient provers, more efficient aggregation. And we are definitely looking into like new constructions, like recently people get the Nova appeal. Then how, thinking about how we can move some primitives to Nova and combine integrity in our current system so that's on the, the research side. On the protocol research side we are looking to, for example, decentralization of prover and the sequencer, the mechanism design between and how we handle MEV and also like how we use multi-prover to include the security. And maybe eventually when we, like, you know, when you move to like Danksharding we will be bottlenecked by this execution. We are looking to improvisation and more efficient client implementation.

(00:28:42):
So they are actually, and also like some resource pricing portfolio too. So there are some large scopes there. We are always looking toward what's the problem we are going to solve in 1 year or 2 years. So we're actually working on that. But you know, you also mentioned there is a product going on there is like, you know, you always need to bounce some stable version, you need audit, you need stable.

Anna Rose (00:29:02):
Totally.

Ye (00:29:03):
So we will have multiple versions and in this like recent version, stable branch, which engineers are mostly working on, and they are looking to more stabilize and battle-tested, well audited as our version 1. And then in the next version we'll think about how we can kind of merge those different research results into those kind of our current versions and how they can integrate with our system and what a kind of changer part we need to audit and how we kind of coordinate across different teams. So it's more like, you know, even for EVM it has EIPs, it has like small changes to make that works and in the next version, so we will also have versioning and so it's like version 1, it'll be very stable sound and complete EVM, but the next version might be like, you know, we make some tricks, we change the proving algorithm a little bit and then like make that even faster. So yeah.

Anna Rose (00:30:05):
Cool. I want to talk about, so this sort of speaks also to the sharing of research, but like the competitive landscape last summer in, I think at EthCC there was like all the announcements of zkEVMs, right? It was like the week of zkEVMs. And I remember that like at least the Scroll zkEVM announcement. I think you kind of put yourselves on the stage with that. I think a lot of people didn't really know about what you were doing, and I feel like this was kind of like an opener. How has that changed? Tell me a little bit about, you know, what you're seeing on the competitive landscape.

Sandy (00:30:41):
I think I would probably challenge the framing that all L2s are competing in some fundamental sense.

Anna Rose (00:30:48):
Okay.

Sandy (00:30:49):
I don't think this is a productive way to think about the space. We were never thinking about the competition when we did the initial testnet launch. And we're not thinking about it now. What has changed is that we're more and more confident with our testnet results. Our testnet with proofs have been running for a few months and and we can talk more about the roadmap and what we've learned since the Paris announcement but, you know, taking a step back, I think the fundamental view is that there are still very few users in the space. So there are like 2.5 billion monthly active users on Instagram, for example. And that's just one single app and there are 5 billion active internet users in the world.

(00:31:30):
So I think crypto as a whole probably has about like a million active users and even that's being very generous with, you know, what we believe to be users in terms of definition. So if we believe in a future that has potentially a thousand X users, then does it really make sense to think about like competition endlessly? I think we're all just kind of, you know, in the first of 9 innings. And I think the real landscape is that the, you know, the space to be gained is so large and the design space for infrastructure to tackle is also incredibly large. Like the feedback we've had are from a very, very small subset of the internet population and whether that's real or true, and whether that's like enough for like a real world testing that that's still like, you know, can be somewhat called into question.

(00:32:24):
So I think, and and also another thing that's changing that's not related to the L2 space in particular, but in the wider internet space, it's just that, you know, the definition of user and developer have been framed very differently so far in the crypto teapot in in the crypto bubble. These two categories are framed very differently. But in the real world, you know, every user in the world will eventually become a developer because of natural language that can be used to produce functional, you know, programmatic instructions. And so the line between these two are blurring and the number of active developers, you know, like dApps and Infras and so on, is about a 100K in the space. And once again, that that can easily double or 10x because of this particular change that's parallel to the crypto like universe.

(00:33:13):
And so, you know, we don't believe we're in competition with anyone. I think the landscape is still evolving very rapidly and we care about our users and we're building and we're set up for longevity and for impact and you know, we actually pay very little attention to what the next L2s are doing. But overall, I think having more participants in this space is very bullish for Ethereum and it allows for more experimentation. And that's a good lesson for all of us. And I think one thing that, you know, even if there are like hundreds of rollups, you know, when we go on the call again, is that I think amongst all the rollups I think legitimacy is the only thing that truly matters when you're thinking about trusting your life savings or trusting your assets or value to a network at the end of the day.

(00:34:05):
I think the sense of like security and trust and legitimacy although these are like very ambiguous terms, but what you trust a network to kind of put your life savings into it, it's a very nuance and multifaceted thing. It has a lot to do with the development strategy and you know, the trust you can build and maintain and the systematic things you set up and I think it ties a lot into the core values like, you know, decentralization, security and like, well thought out design principles, et cetera. So I think we're on this in the process of figuring out like what that is exactly.

Anna Rose (00:34:43):
I really like what you just said in the sort of focus more on the collaborative part or growing the pie instead of trying to split the pie. I still think in the space there is a competitive nature. Some teams I think are already at least competing on the marketing front. Do you see any benefit in that? Like, it sounds like your strategy is to definitely focus on collaboration, but like, do you think it also brings a bit of attention that might actually be good?

Sandy (00:35:10):
I think any attention to the L2 space is, you know, net good for the, for the world as a whole I think the fact that we're seeing like, you know centralized exchanges now issuing L2s rather than their own L1s is a move in the positive direction. It's a sign of the wider crypto ecosystem adapting to the mindset that L2 is the way forward to is the way for scaling. And so anything that moves people away from the L1 rotation trap, I think is a good step forward. And I think any kind of marketing in that sense is positive.

Anna Rose (00:35:49):
That's interesting. I just, I have a question. Like, I feel like the Scroll project is borne so deeply and within Ethereum, but have you as a team paid any attention to Cosmos or like the Polkadot models, like any of these other sort of like networks where they have the connectivity through different ways? I mean, I know the project is very Ethereum, is there any cross-pollination of like, ideas between those ecosystems and Ethereum?

Sandy (00:36:14):
I would say I learned a lot from the Polkadot ecosystem in the sense that I think there is a culture of putting developer first, and I think that's also part of the Ethereum culture as well. And you know, the things that made Polkadot so successful we're also keen to kind of learn from those lessons and do the same for Scroll, just putting developer first and being steadfast and being a kind of friend on the developer to founder journey as well. From the Polkadot ecosystem, I think there's also a lot to learn. I think the lesson there is that certain projects have specific needs and sometimes they would like to share economics at the protocol level, and I think these narratives are yet to be played out.

(00:37:00):
But one thing that keeps me building in the Ethereum ecosystem is that if I have to spend a day figuring out how to bridge stablecoin into any new L1s, then I'm going to give up. And I think that applies to both of these things both of these ecosystems that my test on how long or whether I should kind of consider seriously, like spending a significant amount of time or resources on any ecosystem. So that ties into the second point, I think it's a value that, that we try to kind of prioritize at Scroll, which is just putting developer and also user experience first and making it as accessible as possible. So you know, hopefully the process of bridging stablecoins onto Scroll will be, you know, a lot easier than, you know, you would for Polkadot and Cosmos.

Anna Rose (00:37:56):
Interesting. I kind of want to ask a bit about how you envision the Scroll rollup looking. Do you actually imagine it as a single instantiation or do you almost, like, could it be that there's like multiples of it for different uses? I don't know if that's like a roadmap thing or if that's even something that's been thought of like currently are you just thinking about it's like a single version that like, that's where you want all of the dApps to live.

Ye (00:38:24):
Okay, I can talk a little bit more from the technical perspective. So I think we start with like, you know, solving the problem of EVM because EVM is congested expensive, so that's we want to build a platform that can solve this problem. Like, you know, all the transactions, all the applications can deploy here and cheaper, faster throughput and harder security. So that's the starting point. And I believe that layer, so imagine that in five years, like, you know, be because, you know, Layer 1 will be even more expensive and all the interactions with the EVM application will be moved to Layer 2. And because Layer 2 as a network has this strong network effect for, you know, application have this dependency and how many users you have. So I think there will be like very few Layer 2s who will be general purpose and lying on EVM directly.

(00:39:17):
And then there might be some other chances to kind of build their protocols on top of Layer 2, either as as Layer 3 or some more, creative form. We don't commit to any future because you know, it's like even Layer 3, the new concept proposed by people we are not making like any choice among like, you know, we have to think future is like one Layer 2 multiple Layer 3s, but we are thinking something like more creative. Maybe there are some other form like, you know, can also extend our Layer 2, but we believe that as a Layer 2 we should, you know, firstly inherit all the kind of, not only from the technical perspective, we inherit the security we are cheaper with a higher support, but we also want to inherit this kind of legitimacy, this branding of Ethereum because all the users will interact through there too.

(00:40:04):
We want to kind of keep this spirit to be the same. And then like more people can like build more creative stuff on top of Scroll you know, like cheaper, minor and, but still like different teams are betting in future but we are still like looking towards because also like, again, like many, many futures are like, you know, people are talking about this future, but they're hand waving about the technical details. We are thinking more in the long term that we propose something which is technically feasible. And also it's good for building like the entire, like, you know, it's almost like an entire country and then like people can build their own like island or cities on top of Scroll

Anna Rose (00:40:45):
On top of it.

Ye (00:40:46):
So Yeah.

Anna Rose (00:40:46):
But you don't imagine deploying two Scrolls, that was kind of what I'm wondering is like just generally like with once you build the stack, you could, right? Like you have all the software.

Ye (00:40:56):
Yeah, yeah, yeah.

Anna Rose (00:40:57):
But I guess there's no real use case for that right now.

Ye (00:41:00):
Yeah. People can still for our code base for ZK EVM and launch their new zkRollup, but again, like back to the question, like when Sandy mentioned, when they're the hundreds of rollup, like including all the folks and legitimacy and the trust you build for certain layer tool will be, you know, the biggest issue, like biggest reason why people choose you. And then there will be a like massive network effect why people will choose build on you. And also because we are building a zkEVM, which are general purpose ZK rollup platform, so we are not targeting at specific use cases so all the applications we are deploying on us and also like, especially specifically for some DeFI, like they need this comparability. So, which means it's hard to kind of launch many app chains and having the same comparability, same UI and UX for users. So that's why we believe that there will be some dominant layer to with strong network effect. And then like, you know, even if other peoples are working, they need to have their own feature maybe tailored for specific applications, but we believe that's part of like, you know, Scroll family instead of something in parallel.

Anna Rose (00:42:05):
Got it. And that, that's actually sort of what I'm trying to sort of envision, this is like a very general like roll up future kind of vision, but like, do you sort of picture these like large generalized L2s being few and far between, but then smaller L2s still attached potentially to the main chain, the L1 that are specialized, and then obviously on these larger L2s, you could also have that L3 in certain cases. But I wonder like, is that sort of what you envision, like have people talked about that?

Ye (00:42:36):
I think all the people either envision like a similar future either like multiple Layer 2, multiple Layer 3, like build on top of each other but again, like, you know, I think our point is that we are still doing more technical assessment for how practical this is and what's the interpretative for example, between Layer 3s and what's the benefits you get from there. And so we think there might be even be some more creative format, even like not Layer 3, not Layer 2, but maybe some more creative thing like in between to build a future. I think no one can 100% that the future is look like this, but there are like some reasoning behind like having Layer 3s on top of Layer 2, for example. Like imagine that if all the activity are happening on Layer 3, people need to deposit and withdraw, they also want to do this cheaply on their base chain, right? If you do this, for example, if you use some special application as a Layer 2 and then like your deposit and withdraw is also, unless you have some way to have this kind of user want to leave, put all their money on your platform. So unless you are very attractive that user want to kind of deposit & withdraw very frequently, then like most application will do this still. And if you're building Layer 2, then this will be very expensive. And if you're Layer 2, then like, you know

Anna Rose (00:43:53):
You're saying if you build on L1, it would be very expensive, right?

Ye (00:43:55):
Yes. If you're building on building your Layer 3 on Layer 2, then like you're depositing on with job will become much more like cheaper and also like

Anna Rose (00:44:04):
Got it.

Ye (00:44:05):
You know, because people have the reason to put their money on Layer 2 and then like, you know, if, you know, for your own application people are just, you know, interacting and play with that for a while and then like they still need to like, you know, do this interaction with the base chain very frequently, which will become problematic. Yeah. And also I think if you imagine the future to be all the applications on Layer 2 then like know it's beneficial for Layer 3 to launch on Layer 2 to kind of directly get the users, get the liquidities on Layer 2 and build some featured applications. There are already been some experimental like Layer 3s deploying on Scroll and also that's what we plan to explore like adding more verification algorithm supporting that our Layer 2 to support more creative experiment.

Anna Rose (00:44:55):
Do you actually, do you ever look into things like Eigenlayer or sort of the DA levels? Like is that something, because that is sort of being built for the EVM, the L2s, right? In a way?

Ye (00:45:09):
Yeah, yeah, yeah. In a way that technically like, you know, if you use use other DA solutions, it can be cheaper in some sense, but they are still

Anna Rose (00:45:18):
Oh, by the way, by DA we mean data availability sort of should've said data availability. DA.

Ye (00:45:24):
Yeah, data availability, thanks for explanation. Okay. So yeah, so I think for us for our own purpose, because we believe that as a Layer 2 platform, we want to inherit all the security properties of Ethereum. So that's why we decide to post our data onto Layer 1 to maintain the same security because whatever the DA solution you are using there will always be trade off. Like, you know, for example, like if you become a validator like, and you mistake across different platforms, there might be some risk for kind of, you know, if one platform has some problems, then it brings some systematic security issues. So I think for us, we just want to stick to this very traditional model to inherit all the security models and become like by definition a rollup. Because there are some like interesting debates also around what's your definition for rollup.

(00:46:19):
And I think it a more popular opinion that you post your data onto Ethereum and let Ethereum decide which is your economic chain. And so which that's the reason why believe posting this data on chain will always bring your like highly, highly security and maybe for some other applications depend on Scroll. They can decide by their own community either they want to have their own DA solution or running their own sequencer. So that's another reason why people want to launch on Ethereum. They want to have some kind of, yeah, like governance over this process.

Anna Rose (00:46:54):
As you describe all this though, all I can think of is like the bridging between the different L2s and I think in when I first had, when we were first talking about this, I always imagined almost like a one-to-one like these little bridges, but I feel like there are newer solutions now kind of emerging. Can you talk a little bit about that? Like how you picture, like do you still imagine people actually using the L1 as the transaction layer or do you actually imagine the L2s kind of speaking more to each other?

Ye (00:47:22):
Yeah, I expect Layer 2s speaking to each other, but I think it's almost the same hard to build bridges between different Layer 1s. Like even if you are sharing the same, I think people have the impression that, you know, if you're building a bridge between two different Layer 1s and that that's one kind of bridge. And if you are building bridges between, like, you know, if you are sharing one Layer 1 you build multiple Layer 2 and Layer 2 bridge, it might be easier, but in fact it's still very hard to kind of bridge between Layer 2s. I think, so I think my prediction is that because all the transaction, all the activities will move to Layer 2. So that's the reason why I think bridging between Layer 2 will be more frequent, but it's still almost the same hard to build bridges between different Layer 2 because still, even if you, like, there are some ideas like where, because all your stake route will be posted on the same Layer 1, there might be some way that you can read data from stake route and prove that, you know, but it still, you know, takes either takes a longer time to generate proof or you don't have very great kind of atomic interpretability.

(00:48:27):
So I think it's still hard. I think it's still like unexplored like space and so people are still doing more experimentation there.

Anna Rose (00:48:35):
What about bridging that isn't token bridging, but rather just like message passing, because I know there's like some really interesting things around that.

Ye (00:48:42):
Yeah. I think my my own prediction for this is that because arbitrary messaging is even harder than just token bridging because

Anna Rose (00:48:51):
Really?

Ye (00:48:51):
 Because you can like make your kind of token transfer

Anna Rose (00:48:55):
Because there's more things?

Ye (00:48:55):
Because you can make your token transfer become part of your arbitrary message, right? Like if you want to kind of send

Anna Rose (00:49:00):
Yeah true.

Ye (00:49:01):
Some token to another Layer 2, it's kind of part of your message, right? So it's, I think it's even harder, especially if it's like a smart contract function call or whatever. So yeah.

Anna Rose (00:49:12):
No, that's, that's interesting. I want to talk a little bit about, I kind of want to revisit the ecosystem topic and you know, the connection now that Scroll is a standalone project with the team, it was grown out of the PSE group or like it was, you know, connected to the Ethereum Foundation and stuff like that. But what is the rapport? What's the relationship like? Does Ethereum support anything in Scroll? And then I also kind of want to ask about 0xParc if there's anything because I know that like, at least in terms of the libraries, there's a lot of overlap. Are there any sort of like clear collaborations between those three groups, yourselves and PSE and 0xParc?

Ye (00:49:48):
Yeah, I think, yeah, because part of our philosophy is like developing the open source way and we are really grateful all the contributions from this community and they are several like open source collaborators we're helping working with, as you mentioned, like they're the PSE team and we have been copying the zkEVM over the same code base for nearly two years. And we drive into like our layer to the ZK EVM, but we are also helping them to build Ethereum equipment for Ethereum. So that's the relationship is pure, like

Anna Rose (00:50:20):
Interesting.

Ye (00:50:21):
We are in the same community pushing the same dream.

Anna Rose (00:50:25):
Yeah.

Ye (00:50:25):
And so that's the relationship and we start together and we have been like long-term collaboration and I think for 0xParc, I think we, we hosted many workshops around our toolings, so that's why you see a lot of overlaps and why people are reusing the same tooling.

Anna Rose (00:50:40):
Yeah, yeah.

Ye (00:50:40):
Because we have done a lot of like workshops with teaching like people how to write Halo 2 Circuits since early last year. And also we give lectures about like proving cost and zkEVM circularization. So it has some impact for, you know, the candidates there, like why they choose this library. And I think education is definitely super important for like why people are using this tooling instead of, because you just get more tutorials and more help like when you bootstrap this.

Anna Rose (00:51:08):
Yes, yes.

Ye (00:51:08):
Yeah. I think, I think our relationship is more like, you know, we believe in the same goal. We are value aligned and we believe in this open source. And so that's why we came together and sharing some educational resources and discuss. And more recently there will be a lot of discussions about new provling systems like Folding, Supernova, Paranova, Hypernova.

Anna Rose (00:51:29):
Yes.

Ye (00:51:29):
Like, you know, it's, you know, we find something together and then we are excited to see like how far it can go. And we also want to support this ecosystem and this community grow as much as we can. Like how people are like using this and how it can enter into our system.

Anna Rose (00:51:43):
I personally just really love watching and seeing how these ideas are developed. Like how like some very compelling proving system or new research is introduced and then you see a tutorial.

Ye (00:51:56):
Yeah.

Anna Rose (00:51:57):
Or someone wants to teach about it. And I think the Nova example is a great one because, I mean, it was almost a year ago that Justin Drake was like, I want to do, he wanted to do a whiteboard session about Nova, and I didn't know what that was at all. And now you can see like, at least in the sort of PSE, 0xParc and you guys, like, you see this sort of like, there's a lot of people who are really excited about it. And now you see that also spreading too. I know Ariel got Nova pilled recently.

Ye (00:52:22):
Yeah.

Anna Rose (00:52:23):
And like there's like new kind of, there's people who are getting introduced to these ideas.

(00:52:28):
And then what's, it's interesting to watch that happen and the material that gets created, but it's also sort of interesting to see like, why are there proving systems that also might be really compelling, aren't quite getting the mind share and like as there are more groups popping up. Because I don't know if you've noticed, but like, there's new ZK everything every time, like every week there's like a new ZK newsletter, a new ZK event. And that's awesome. And I do wonder if we're going to see sort of these like, areas of research, these sort of like clusters almost of shared research. I think this is one and it's really fascinating and kind of amazing to see it in action. That was my little community take there.

Ye (00:53:05):
Yes. I think part of ourself is like, you know, we want to geographically extend this ZK community to everywhere. I think Sandy may have more to say about like how we build this kind of ZK community around every corner of the world and how we spread this kind of information because through education, through some other local events.

Sandy (00:53:25):
Yeah, no, I was going to add to that and say I think, you know, any team essentially that is you know, aligned with the open source culture and focused on public education can join part of this development process. It's not, definitely not exclusive to Scroll, PSE and 0xParc and you can see a lot of amazing ZK researchers you know, as a part of this group that are expanding you know, whether it's new folding schemes or Nova and trying to but I think the starting point is that there is a critical mass of projects and researchers and project and engineers who subscribe to this way of thinking and we're hoping we're one of the factors that makes this kind of philosophy more widespread amongst the wider ecosystem. So the idea that you have to build everything yourself or, or like hold it back from other people, you have to keep things, keep it to yourself. I think that sort of mindset is, you know, slightly outdated and we want it to be like, outdated for the ZK world as a whole.

Anna Rose (00:54:30):
Tell me a little bit about the roadmap for Scroll. Like I think we've done a really good job of catching us up to hear what's happened in the last year. And I think yeah, you did, you've teased sort of what was coming and stuff like that, but like tell us a little bit about the roadmap. Where is Scroll at? You said there's testnets. Is there a launch date? Are you going to be careful actually like announcing launch dates? Yeah. Tell me what's up.

Ye (00:54:54):
Yeah, I can talk more on the technical roadmap and Sandy can talk a little bit more about our ecosystem building. So on the technical side I think currently our first priority is that we are launch very soon like everyone's talking about it, but yeah,

Anna Rose (00:55:09):
Soon

Ye (00:55:10):
And so the first priority is that we want to build the complete and send the zkEVM with the robust infrastructure, which means test of time and like battle tested by all the community members. For example, our current testnet have been like, there are over like 20 million transactions. It's a very large number and over like 1.5 blocks and I think around like 4 million addresses, it's like a lot of people are like actually playing with our testnet. So making that more robust, providing feedback and also we already sent our circuit to the auditor. So that's our first party building something complete, and then next step will be decentralized approver. So the point of decentralized approver is actually different from the like, traditional point of decentralization, which is censorship resistant, but building a decenteralized prover network actually have two biggest purpose.

(00:56:03):
One is that make your network more resilient because prover needs a larger cost to run, right? Like people need to buy special like hardware maybe. And if our prover goes down, then other people there will be a bunch of backup who can still join and prove for you and also it can incentivize people to build better and better hardware. Like, you know, if you are incentivized to run as a prover, you are incentivized to make that more efficient to save your own money, right? Like, you know, it can make our network this kind of finalization time on Layer 1 proof generation time becomes smaller and then next step will be decentralized sequencer. So even if, you know, as a Layer 2, even if we are running a centralized sequencer, you still have some way to avoid kind of censorship resistant, for example, you can enforce some transaction on Layer 1

(00:56:48):
To enforce that execution on Layer 2. But it's still good to have decentralized sequencer because there are some problem of real-time censorship. Like for example, you send, like, you are going to be liquidating in one second and then I reject you, and then I will include this transaction in one hour, which is still bad. So that's why like, you want to have this and also some regulation and also like depends on your philosophy for how you capture MEV value and what this kind of value and mechanism, how that flow to different roles. I think that's the 3 biggest thing, our roadmap on the technical side.

Anna Rose (00:57:24):
Yeah. With a very quick side question here. With a non-decentralized sequencer, does that sequencer collect all the MEV? Pretty much. Is it sort of like an unfair advantage to that sequencer?

Ye (00:57:38):
Yeah, it has this power to

Anna Rose (00:57:40):
Maybe not all MEV, but like a lot of it

Ye (00:57:42):
Yeah it has power to kind of collect all the MEV fees. It depends on like, you know, like whether you believe this Layer 2 will kind of operate

Anna Rose (00:57:50):
Yeah. How you define it

Ye (00:57:51):
Badly or not. But yeah, currently, like, you know, I don't think like any Layer 2s are purposely like leveraging this unique advantage to run MEV to run some bad things, but there are also good MEVs like, like, you know, arbitrate to kind of make like, you know, balance your price and something like that. But I think eventually all the Layer 2s are committed to decentralized in some sense, but it's just a very complicated design problem because you need to consider the value and like how that flow. And there will be a lot more things happening like not only decentralized prover and sequencer, but a lot more things also happening like in our roadmap which will happen in parallel, including some efficient client implementation. Like for example, we will think about having multiple clients and having EVM optimization, having that more efficient.

(00:58:41):
And also we want to enhance our securities through multiprover and also like, you know, because Ethereum is also evolving, we are part of this large ecosystem, we need to think about like after they have, for example, in protocol PBS, which is shot for product like proposer builder separation, if they have this infrastructure for account abstraction which is ERC-4337, and how we can engage and how we can maybe even overlap with this infrastructure. So that's a large problem, like how we can coordinate changes with Ethereum Layer 1 because one important thing which differentiates from other Layer 1s is that Layer 2 can actually drive the changes of Ethereum Layer 1 because we have the same goal to scale. So that's something like we are also thinking, okay the talking with the Ethereum ecosystem and talking with the thought leaders and how we can collaborate in a more open way and generate, you know, like generalize our research, post our research and having more open discussion and even maybe in the future form some standard for all Layer 2s.

Sandy (00:59:42):
We're really excited by how much interest we've gathered in the permissionless testnet that we've been running for the last few months. As you said, we have more than 4 million unique wallet addresses on Goerli which I think is a meaningful number and it's very interesting and you know, that there's so much interest in a testnet. And and also it gives us confidence that we're processing over a half a million transactions on a daily basis. It means our code base has been battle-tested for about you know, more than four months now with no critical failures. And there's still a ton of like optimization to be done, but I think this is a very good basis and it gives us the confidence to start talking to protocols and ecosystem partners and gearing us for a mainnet, as you said.

(01:00:36):
So on one part where we're trying really hard to onboard all of the tooling and infrastructure providers that are existing on Ethereum. So for them, the integration process should be no more than a day. There's no difference from deploying on Ethereum Layer 1 other than RPC. So it's a very quick process and but there is a conversation to be had and we're very actively having those conversations. On the other side, we've recently launched a permissionless kind of page for ecosystem projects to register themselves and so that they can find each other

Anna Rose (01:01:11):
Cool.

Sandy (01:01:12):
And where any prep work is required to collaborate, they can use that as a forum. And within the first week, we've had over a hundred projects kind of submit their information through this site. And and we're in the process of thinking about how to organize it a little bit better and to provide like, you know, collaboration between various protocols and just bring a little bit of transparency. And on day one, I think users will be very interested in, you know, what are the things that they could play with, what are the things they could interact with? And we're trying to build a very good kind of streamlined user experience so that traffic can be directed to whatever kind of, you know, fund rise they want to play with, so to speak.

Anna Rose (01:01:55):
What's the name of that website, by the way?

Sandy (01:01:56):
Ah, so you can find it through the, I think the easiest way is to find the @buildwithscroll handle on Twitter.

Anna Rose (01:02:06):
Okay.

Sandy (01:02:07):
It's tagged on the main Twitter account and there's a form which you could kind of go into and then it would be, I think it's linked to the main website. And I think over the last few we've been hosting a lot of kind of local, you know, hackathons and also local meetups and hacker houses.

Anna Rose (01:02:26):
You guys were also at zkHack Lisbon?

Sandy (01:02:28):
Yes we were

Anna Rose (01:02:31):
And there were a few projects built on Scroll. I think there was the zk-zk-rollup.

Sandy (01:02:36):
Yes. There's a

Anna Rose (01:02:36):
I guess an L3 righht?

Sandy (01:02:38):
Privacy L3. I think using yeah, using a lot of the, the, the Aztec tool stack. So that's very exciting. And yeah, so I would say you know, one thing that surprised me in this ecosystem building process is that there's a lot of organic ZK dApps and ZK implementations. And I think partly that's because of our team's DNA and ZK research. And so that's kind of, you know, through osmosis inspired a lot of, you know, ZK engineers to build things that are adjacent to Scroll. And also on the other side we have a very active group of grassroot developers and you know, they're just hacking away and thinking of new things to be built. And there's almost like one or two games popping up every other week, and I try to stay on top of what's happening and playing with them.

(01:03:32):
But you know, there's a lot of interesting native things that are being built and, and preparing fo our mainnet launch. And also I think that there's a team that's working really really hard on kind of bringing on the existing more well-known protocols onto Scroll. The idea is that we want Ethereum users who are familiar with certain brands and certain protocols to find things that they're familiar with and they already know how to use. So there's a sense of familiarity. And then they can also find, you know, new adventures, like new protocols to, you know, play with and new games to interact with.

Anna Rose (01:04:10):
Do you see gaming as one of the key spaces that you want to sort of develop in terms of like, just do you want more games? More blockchain games on there? Is that a focus category?

Sandy (01:04:23):
In terms of product? We're building a generalized ZK EVM, so we don't have to choose, so we support everything and the pros is that that means, you know, we offer something that's interoperable and something that can interact. You know, if someone were to build a game fire project on Scroll, it's more interoperable with the DeFi stack and so, and vice versa. So I think that's the interesting thing. So we are seeing, you know, games as a whole, it's easier to build in a silo and it has less dependencies. And I can see that being very popular amongst more isolated kind of devs or studios that are more organized around the single game type or processes. So I think that I can see a lot of games happening organically. As a platform, we're just focused on building exactly the same platform infrastructure experience as Ethereum Layer 1, which a lot of games have been known to thrive in

Anna Rose (01:05:28):
Got it. Cool.

Sandy (01:05:31):
Maybe we could talk about hardware just very quickly. I think in terms of ecosystem building, I think we're quite unique in the sense that there are like more than 10 hardware companies building solutions for Scroll. And I think that's like one example of open source collaboration that's reaped or energized a whole adjacent industry.

Anna Rose (01:05:56):
Well, I want to say a big thank you to both of you for coming back on. Well to Ye to coming back on the show, Sandy, for joining us on the show. It was really great to get a chance to find out what's been happening in Scroll this past year.

Sandy (01:06:07):
Yeah, it's a pleasure to be here. Thanks for having us.

Ye (01:06:10):
Yes, thanks. Nice to meet you again. Anna.

Anna Rose (01:06:13):
Cool. And I want to say a big thank you to the podcast team, Henrik, Jonas, who's editing this episode. Rachel and Tanya. And to our listeners, thanks for listening.