S1E03 [EN] - Abdel: The Future of Starknet and Cairo 51:55

Welcome to ABCDE. I'm the host, P-Man. I am Lo Bai. We are super excited to have Abdel in our podcast. Abdel is the export region lead of Darkware. So Abdel, we want to say hi to our audience.

Hey, hello everyone. Very happy to be there. Thank you for the invitation. It's a pleasure. Yeah, of course, of course. So Abdel, first of all, I think you can give a little introduction about yourself and your background, how you joined Starware. Sure, sure. So yeah, I come from an engineering background.

specialized in computer science and system security and electronic banking. Then after that, I worked for a fintech startup for eight years, specifically working on the cloud-based payment solution, enabling users to pay with their smartphone using contactless technology. So it was at the very beginning of NFC technology for payments.

So I was working closely with Visa, Mastercard and big banks in France and Europe for this. So it was a good opportunity for me to get to know more of the financial system, how it works. So I used to say that before joining crypto and fighting banks, I was working with them because they were my customers. And so it was before crypto and then

Around 2012, I discovered Bitcoin, played a bit with it, running some loads, going through the code, and I was pretty excited by it, but it was not enough to convince me to leave my company and to work fully on the space. It was really when I discovered Ethereum in 2015, it was like a revelation for me.

When I discovered Ethereum, it was clear for me at this time that I wanted to work on this space. I saw the potential of something really big that could change the world, really.

I am really attached to the philosophical aspect of the blockchain and how they can provide more fairness in the world. And I think they are very good, amazing social tool to improve the society and many aspects of the world that are currently broken, especially on the financial system.

So I was really attached by those philosophical aspects. And I wanted to work on Ethereum. It was clear to me. So I decided to leave my company and I joined ConsenSys. I worked there for four years as an Ethereum core developer. I have been working a lot on...

EIP 1559, which was a big change in Ethereum monetary policy. This was a change that introduced the burn of keys in Ethereum. It was a very huge change in the protocol. And it was interesting because, you know, there were the miners that were really opposed to this change because it was reducing their revenue. So it was interesting also to see the governance of a decentralized protocol

where you have different entities that have different goals and different interests. It was really interesting to see that this is not only about technical choices and code and whatnot. It's also about social coordination, about how we can

to work together on the same protocol and make sure it will be robust. We don't want a single entity to take the control over the protocol and whatnot. So it was very interesting to see those aspects. Then after that, in 2021, I wanted to discover Cosmos ecosystem. So I decided to leave a bit Ethereum ecosystem. And I have been working on Cosmos ecosystem for a year or something like that.

I was interested by the vision of interoperability between different chains and the application specific chains and philosophy and IBC communication between those chains. I was curious to discover more. I still think the tech is interesting. Cosmos has interesting technology, but I had some disillusionment.

I was a bit disappointed by some aspects of the protocol and the ecosystem. And after that, it was clear to me that I wanted to focus only on Ethereum, which I believe is the more credible layer one that is sufficiently secured and decentralized and

natural and have the best chance to succeed because I see that all Alt layer ones are doing too many sacrifices on some important properties. This is why now I strongly believe that Ethereum is the most robust layer one. I'm also still a big fan of Bitcoin and those are the two main protocol I want to focus on.

because they are the most credible and decentralized and secure. So I decided to come back to Ethereum ecosystem. And then I discovered, I wanted to focus on the scalability problems of Ethereum. And this is when I discovered the layer two solutions. I did a deep dive on all the different solutions, optimistic rollups. And then quickly I realized that I prefer the scalability

the properties of ZK rollups that I think are way better in terms of security and UX mainly. And then I did an analysis of the existing ZK rollup solution and my conclusion was that StarkNet was the best promising, but I guess we will talk a bit more later about that. And then I met some people from Starkware and then I joined Starkware and now I'm leading the exploration team, but I guess we'll talk also a bit about the goal of this team, etc.

So this is my background. Wow, that is such an amazing career. And yeah, we have been in the Starware ecosystem for a long time and we are amazed by the community. And it's such a community of innovation and full of talents. So we are curious how you build and establish an open and collaborative developer ecosystem.

Okay, yeah, I guess I can speak about the genesis of the creation of the exploration team and why I wanted to create it. So it was end of last year, around October. Specifically, the main event that triggered the creation of the exploration team was StarkNet CC Lisbon. There was a...

an event called the Hacker House with 60 builders in the same building, 60 builders from StockNet ecosystem, spending a full week hacking together on some projects, et cetera. So I spent a lot of time with them. I really wanted to understand them more,

to see more of the pain they are facing when building on StarkNet and so on. So I really spent a lot of time with them and it was very helpful. And from this experience, I realized that

that I think we can do better at Starkware in using our own tools and technology. You know, it's better when you build an ecosystem to really get a sense of what you are building. That means also eating your own dog food and try your own tech so that you can understand the pain of the builders and you really feel their pain because you live their lives and what they are facing. So this was my first learning from this.

we are really a bit too far from their needs and their pains. So I thought it was interesting to try to build more with our own technology. This was the main learning from this building. I also realized that

you know, we attracted a lot of young builders in the ecosystem that are very young, okay? Because we have an exciting tech and specifically on some verticals like gaming and stuff like that. So that means we attracted a lot of young builders, which is amazing. I really like that because they think out of the box and whatnot. But on the other hand, some of them lack experience, obviously, to build some production-grade software, which is hard, obviously. So I thought it was a good idea to

try to build some very high quality projects that could be showcase of the best practices when building on Stockmit. So I wanted to do that, like have some strong reference projects for them to have example of what to do, not to do, et cetera. So because there is a big difference between the tutorial you can do

do a tutorial and an application on production, there is huge gap. So I wanted to kind of fill this gap by having some real world applications and projects using Cairo and start post technology.

for them to have reference and being able to help to increase the level of quality of the ecosystem. And also I wanted to stimulate the open source mindset of the ecosystem and this idea of collaboration between people that work together on some projects. So this was my main idea after that. And this was the genesis of Kakarot's idea.

wanted also to showcase the power of Cairo. And we thought that building an EVM with Cairo was an amazing showcase of the power of Cairo because building a ZK EVM is obviously very hard. People took years, literally, to build a ZK EVM.

And we wanted to show that with Skyro you can do it really fast. And fast forward three months later, we did it. We actually managed to do it really quickly. So I kickstarted the Kakarot project. I found some builders. This is basically during this event in Lisbon, StarkNetCC. This is when I met Elias and Clement, who are the founders of Kakarot now. So we spent time together. I was, yeah...

talking with them, trying to onboard them on the project and guide them on the technical front and whatnot. And then they took the lead naturally on the community progressively, and this was amazing. And I'm very happy that they did that. And I guess, yeah, today they announced on Twitter that they completed the procedure around. Yeah, it was very good news. So this was the first project, the first exploration project

And then I wanted to reproduce the same thing with different projects, but we can talk about it later. But yeah, this is the main goal of the exploration team and how we try to stimulate the innovation of the ecosystem.

I see. So we've heard some descriptions from the developers that StockQueer developer community looks a little bit like 2014 of Ethereum foundations. There's so many different strange or fresh ideas comes up every day and there's a new phase built.

So you agree, right? Exactly. Yeah, I totally agree on that. This is a very good analogy. And this is literally what I felt when joining the StarkNet ecosystem. I felt the early vibes of Ethereum. This is exactly what you said. Like people seeing the potential of an emerging technology that has the potential to change the world, etc. And I really felt the same thing with StarkNet, which is something very special. And honestly,

Maybe you can say I'm biased because I'm working at Starkware, but I don't see this vibrant ecosystem in any other layer 2 solution. None of them have the same vibrant community. People really working together. I like to say that Starknet is a big family.

Like really people know each soldier individually. We know all of them individually because we took time to grow organically, to work with them, to talk with them, to understand their needs. And this is amazing because then they become your best soldiers actually because they will educate others and then you will spread the culture like a virus. And this is amazing. I'm really happy to have this culture in StatNet and none of other ecosystem have it honestly. So yeah.

So speaking of these super energetic ecosystems, since we've got Kakarot, Madara, Beerus, etc. What would be on the roadmap or the future plans for the software? I mean, is there any more comes to build something new or something fresh is being planned?

So yes, actually, yes, there will be more projects like Cacao and Beavis and other in the future. I have some ideas. But this time I want to...

take a bit more time to consolidate those existing projects because it's hard to... You know, I don't want to leave them too early because I want strong people to take the lead on those projects. Like, for example, once I have strong people taking the lead on all those projects, I can safely create new projects. But, you know, I don't want to move too fast to a new project because I can keep the momentum on those projects.

So for Kakarot it's fine, now the project is fully autonomous, so I don't spend more energy on that. Obviously I'm still helping them, giving some technical guidance and whatnot, but only when needed, so the project is autonomous. Beerus is almost there, there are some people from the community that are taking the lead and can likely do the same as Kakarot and create a company and whatnot.

If you want, I can do an introduction if you are interested. Progressively, once they do that, I think I will start a new project. But for now, I have two big projects with Beerus and Madara. I don't want to leave them now, especially not on Madara because the momentum is huge and I believe it will be insane in terms of potential for Starkneta chain, layer 3, etc. So I don't want to kill the momentum. I want to consolidate.

But then, yes, for sure, we'll start new projects. I just want to find the right time before starting a new project because it's a lot of effort actually when you start a new project. You need to find some people to work on that or to take time to onboard them. It's an investment of time and resources, et cetera. So I will do it, but I'm just waiting the right time. And also I'm scaling my team. We are hiring people.

So it will be easier when I have more people with me internally that can help me because you know

We need to do a lot of coordination, project management to make sure that contributors from the community are not being left. We need to really guide them. We want to keep this strong culture of a family. So for that, you need to spend a lot of time talking with people, teaching them, et cetera. So the short answer is yes, there will be more exciting projects. I already have some kind of idea.

I don't want to tease all of them right now, but yeah, definitely some idea. Some of them can be related to

more collaboration between StarkNet and the Ethereum ecosystem. I have some idea that could consolidate the link between Ethereum and StarkNet with some research topic with the Ethereum Foundation and Vitalik. I discussed with Vitalik on some potential topic that could be good project to start. But yes, and aside from that, I also have other idea. You will hear about more projects in the coming months for sure. Yeah, don't worry.

Yeah, that's super exciting because we can see a lot of innovation like Mandara, KaggleRot, Hereditas, Garage. And these projects have a lot of synergy. And so I think many of our audience might be curious about how they can participate in the stockware ecosystem.

Yeah, yeah, definitely. There are many, many opportunities to contribute to the StarCore ecosystem. And we need to expand a lot in Asia, actually. So I'm really willing to, and if you guys can help us on that, we really need a strong presence in Asia. So definitely willing to collaborate with you guys. It will be amazing. Definitely, definitely.

There are many, many opportunities for Asian people to contribute on the stock net ecosystem. And not only on coding stuff, but also in terms of marketing, communication, education, design, product design, web development. There are a lot of opportunities

opportunities, organization of events, basically. So feel free to reach out to us and to Starkware and the Starknet Foundation. If you have an idea, if you want to organize events in different countries in Asia, we really want to support those initiatives and have very strong

local people that can have to grow organically in some strategic countries in Asia. And therefore people, for our builders, feel free to jump in on any project that is open source and there are many, many of them. We can also find you some opportunities to find a job in the company and in the ecosystem. We obviously need a lot of Cairo developers. So I would recommend to learn Cairo and then

I'm sure you will find opportunities because there are many projects that are hiring KRO developers. So definitely if you learn KRO, you know that there is way less competition than the solidity market. You can start by

Yeah, like tutorials, the Cairo book. I strongly recommend you to read the Cairo book. This is a very good start. And then once you read the Cairo book, reach out to us on Telegram. There are many channels on Twitter. Also you, if some people reach out to you, you can show them to us. And then you can...

Once you are confident and comfortable, you can directly start to contribute to open source project. There are some incentives to do it and financial support. Then you will be more visible in the ecosystem. Once you contribute to a project, we will get to know you and we will talk and see if you need something and we can help you there.

So yeah, I strongly encourage the audience to learn Cairo and contribute. And there are plenty of opportunities. Also, we have some grant programs. You can reach out to Louis Guzman, my colleague, who is responsible of the growth of the ecosystem and responsible of the grant program. So if you have an idea, if you want to build something, you can reach out to him. He will guide you.

Yeah, that's it for the coding part. And then, yeah, for events, stuff like that, reach out to us and we can provide you support to organize events in different countries. I would suggest to check if there are existing groups in your country. Like there is StockNet Vietnam, I think. There are a few StockNet local groups. And if there is no group in your country, please take the initiative of creating a group, gather people, and then we can organize events and gain more visibility in

Asia. So yes.

Yeah, awesome. Awesome. We are also happy to contribute to start with Mandara. We are super excited about that. And I think you have mentioned another topic that the Asian developers might be interested in. In what way do you think the application written in Cairo will be different from those written in Solidity? Yeah, very good question actually.

You know, let's take a step back and talk about the reasons of the creation of CAIO and why StarkNet is not EVM compatible like other Layer 2 solutions. There is a big reason for that.

You know, initially when Ethereum was created, the EVM was designed, but it was not designed to become one day zero-knowledge frenzy, actually. So it was not designed in mind to be provable one day. Because obviously at this time in 2014, zero-knowledge proofs were not at this point. They were not mature technology, so it was not clear that they could be used one day for Ethereum. So

it was not designed to be ZK friendly. And this is very important. That means that the choice, the choices that have been taken at this time in terms of architecture, et cetera, are now a big pain to be, to create ZK EVM. Why? First of all, because

All the logic of the EVM is heavily based on binary arithmetic, where on all zero-knowledge proof technologies, you need to work with modular arithmetic, or only with polynomials, basically.

which is a specific mathematical construction that is very different from the binary arithmetic of the EVM. And this is a big pain because when you need them to translate the EVM into something that can be proven through the SNARKs or star proofs, you will lose a lot of efficiency, basically. And also,

There are some operations that are widely used in the EVM that are a nightmare for zero-knowledge pools. Like, for example, the hash function used on Ethereum, the key check,

is a pain to be proven. This is well known that this is really the final boss of all the K EVM. It's really hard to prove a key check. It's very not efficient to generate a Knox or stock proof of the key check operation. So StarCare

decided not to have this overhead basically in terms of efficiency. They said, okay, the EVM was not designed to be ZK friendly. We know that the best chance for Ethereum to scale is through ZK rollups. Then let's build something that will be efficient in a zero knowledge context. So first they decided

Initially, it's funny because it was designed as an internal tool initially. Because before that, before Cairo, at the beginning of StarCax, so StarCax is a

platform as a service that is actually what we call a value jump. It's almost a ZK rollup, but the difference is that the data are off-chain and not on-chain like a ZK rollup. So Starkex is a big platform. This is the most battle-tested zero-knowledge proof infrastructure in the world, actually. It has been battle-tested for years in production with big projects like DYDX, Sora, et cetera. All those projects are on Starkex, okay?

And StarCraft has secured more than $1 trillion in cumulative volume. So this is huge. And initially, when they created StarCraft, the engineers at StarCraft were creating the

the primitives of the solution by hand, literally by hand. You know, when you want to prove something with zero-knowledge proofs, you need to translate something, a statement like someone did the transfer of X to someone else. You need to translate that to some mathematical constructions that can be then proven. And literally, they were doing this exercise by hand, creating all the polynomial constraints, et cetera. So this is

huge in terms of pain because it takes a lot of time. And you know it's not flexible because if you now want to prove something a bit different, you need to do this process again of creating those mathematical constructions. So the engineers--

were lazy, which is good for an engineer. They were thinking about creating a language to do this work for them instead of doing manually. And this was the original idea of Cairo. And they came to Eli Bensasson, the co-founder of Starquare. And they said, look, Eli, we think we need to create a language to do that.

It's very painful. And the first reaction of Eddie was, no, it's not a good idea. It will never work. You can try it, but it won't work. And he was totally wrong on that. And this is cool. So it was a very good idea because then they created Cairo. And now we have this

very powerful weapon that enables to write any kind of general purpose program that will be efficient to be proved using a stock zero-knowledge probe. So this was the original idea. They said, OK, Solidity and EVM was not designed to be SDK friendly. Let's create something that will be efficient in this context. OK?

So this was the original reason. So unlike our competitors, we are not EVM competitors. Of course, for adoption, it's harder for us because developers in the EVM world cannot take their existing applications. They need to write, again, their application in Cairo. They need to learn a new language. So obviously, for adoption, it is harder for us. But...

The promise is that you have a really efficient language for your needs. And now I will answer your question about

What you can do with Cairo that you cannot do with Solidity and the EVM, because you have some things that are very efficient, you can do a lot more computation. So that means that all applications that are heavy in terms of computational resources are a more natural fit on StockNet than any other ZK-EVM. Two examples: gaming. On-chain gaming is a very, very good example.

you cannot do, it's very hard to do on-chain games on the EVM because it's so limited in terms of computation. And you know if you want to put the logic of your game on-chain, you will need a lot of computation resources. This is why on StarkNet we see a lot of adoption and the gaming vertical is very growing fast. There are people like Dojo who are building gaming engines for people to build games on StarkNet. So this is, yeah, this is the first example.

Another example is AI, machine learning and AI, which is a big trending topic with all chat GPT and whatnot. We suddenly see that

All the world is trusting some big entities to train their model and we don't know how they train them. And with Cairo, you can imagine a world where you could have a proof of how they are trained, et cetera. And this is very powerful and this will be so much needed in the future once those solutions like ChatGPT and others

evolve and will be more used. So there are very specific verticals that are very natural fit on stocknet like on-chain gaming, AI. And generally speaking, even for DeFi and stuff like that, they were limited. So they had to

to construct their application to fit with the EVM. But now, suddenly we remove the limits and now I'm sure we will see a lot of innovation because people realize that now they have much more computation power. So now what will they build with this new power? We will see, but I'm very sure that people will come with crazy ideas even on the DeFi industry.

I see. What about the parallel processing? Would that be possible on the Cairo on stock net, mainnet? Right now, it's not possible to execute transactions in parallel.

So let's talk about the architecture. So there is the sequencer and there is the prover. So the sequencer takes transactions and then execute them and then create blocks. And then the prover takes the blocks and generates the stock proofs and then submit them to Ethereum. So the sequencer runs transactions sequentially, so not in parallel, but the proving is done in parallel. The proving is massively parallelizable, actually, through the recursion of proofs. So this is a technique that enables to...

instead of doing a big proof, you can aggregate multiple proofs and do some kind of recursion. And that you can do it in parallel. That means that you can have a bunch of machines that will enable to generate faster the proofs. So we can do the proving in parallel using a recursion. But for now, we cannot execute transaction in parallel on the sequencer. And it's fine for the moment because the proving is not the bottleneck. For the moment, the sequencer is the bottleneck. But once...

This won't be the case anymore. We will need a way to improve that. And in the future, we already have an idea to enable parallel execution on the sequencer with Cairo. We have some idea, but we have not implemented it yet because for now there is no need because we have plenty of room for optimization, even sequentially. But then, yes, in the future, we will work on enabling parallelization of transactions. Yeah.

Cool. Glad to hear that. Yeah, the reason I was asking that because I think as you mentioned, to onboard new developers,

Carol have is good and bad. I mean, the better thing is you have to learn something new, right? The good things is the solidity has been there's heaps of developers there is like a red sea already, you can come to this new place is a blue sea. And then they will be facing two different options. Why is Carol ways move. So move is another language which is popular, having some advantage announced to be more secure treating everything as an asset instead of object. And I

and also they have some parallel processing that's why i thought well what it's a good um

Yeah, one small comment on that because it's a very good topic. Actually, we also have the same model as Move and Retreat. We also have the same model on Cairo. We already have it right now. The resource model, we have it. And it's good for safety, as you said. So we also have it in Cairo. The same model as Move. And we took inspiration from Move, actually, to build here. So we have it in Cairo. Yeah.

the safety guarantees that comes with this model. So it's actually enhanced both security and the performance compared to Solidity. Yes, exactly. I think another question our audience might be interested in is that do you have a mid-term goal about the Starware ecosystem? What will the ecosystem be like in the next three years? Okay.

One interesting thing to see is if we can scale this culture, actually, because I said that this is one of the main strengths of StockNet, but it will be interesting to see when we 10x or 100x the number of developers, if we are able to keep...

the same culture. I think we can because we took the time to grow organically, but it will be an interesting challenge to see if we can scale and spread the culture as we onboard more developers. Also, in terms of

I think we will be able, once we prove that Cairo is actually superior than the EVM, and we prove it with real applications and real use cases where people say, wow, we cannot do that on the EVM. This is a very valid reason to move and learn Cairo. Once we have that, I think it will be amazing. I think we will see a huge boost in adoption very quickly. What I foresee is that

I don't know what kind of application it will be, but what I have in mind is someone will at some point create something that will be mind-blowing and only possible with Skyro. And after that, it will be a 0 to 1 because suddenly people will realize that it was not on your provides. Not only you have more computation power, but also you can do stuff that are impossible to do with the AVM, etc. So I think at this point it will be a 0 to 1. So I think that probably it will be

So adoption will be growing slowly for six, 12 months, something like that. And then suddenly, once there are some concrete applications that are impossible to do with the AVN and people realize that this is a zero to one,

there will be a renaissance of application like the same kind of renaissance at the epoch of Uniswap. It was 0 to 1 actually when Uniswap was created. And I think we will see another 0 to 1 with Cairo. And then suddenly I foresee a boost in adoption of Cairo. Not only in terms of application, but also then for users that will come because there are suddenly those innovative and amazing applications that they have nowhere else

And if they want to use them, they will have no choice but to come on StarkNet. I also think that we will be able to onboard a lot of Web2 developers, much more than Solidity. Why? For many reasons, but first of all, because

We have a language that will be more friendly for web2 developers because it's closer to Rust. So all Rust developers, it will be easier for them to learn Kygo than Solidity. So this is the first thing. And also because we have a lot of adoption in some verticals like gaming and AI,

The reality is that there are a lot of developers from Web 2 on those verticals, and those will see that there is this technology on StackNet that is very friendly for their needs, and that represents good opportunities for them to jump in Web 3, and those will jump directly from Web 2 to Cairo. This is my guess, because this language will be more adapted for their needs.

And maybe they are not interested in Web3 because there are no use cases that they like. Like, for example, game developers, they are very limited by ZVM. They will say, why would I come to Web3 for such a limited thing? But with Skyro, it won't be the case anymore. So I think we will be able to attract a lot of Web2 developers. And again, I think this will be really a huge boost in adoption. So we'll not only attract people from the Web3 space, but a lot from the Web2 space, actually. Yeah, I see. So, Abdel...

As you mentioned, you're expecting a zero to one, like a killer DApp or some applications that only exist in StarCraft ecosystem where you could not see them in the Solidity or Ethereum ecosystem. Yes. Speaking of that, I might have questions on Kakarot, because Kakarot, which is the current famous star project in the

stack where it's still like an EVM compatible chain, right? Its direct competitor would be ZK-SYNC, Scro or Polygon ZK-EVM, et cetera. So I was thinking...

Would KakaoWorld still be able to utilize the advantage of Kero, the infrastructure or the atmosphere or the culture of Kero? Because currently we are seeing there's lots of EVM compatible stuff like Aurora on Nier, there is NEO on Solana, there is EVMOS on Cosmos. And it seems none of those EVM compatible chains are those uniquely ones being able to attract those EVMs

either developers or the users. So that's why I had a bit of concern on how Kaku Road would make a difference compared to those EVM compatibles. Very good question. So first of all, for those projects like Neon, Ohoho,

The big difference is that they are not Ethereum ecosystem. So this is one big difference. Where Kakarot and Ethereum layer 2 is very different. Like for example, we can see already adoption on Optimism, Arbitrum, and we would like to see adoption on ZK-SYNC, Polygon, ZK-AVM and whatnot.

So this is a big difference because the culture of the EVM is not really spread outside of the Ethereum ecosystem. So this is the first difference. So I still think there is place for Ethereum layer 2 EVM adoption because they are on Ethereum ecosystem. And because Ethereum is adopting a rollup-centric roadmap,

The idea is that gradually applications and users will move to layer two. And ultimately the layer one, Ethereum, will become only a settlement layer. And it won't be used by users directly, but by layer two solutions directly. So that means that those applications will need a new home and TechArts can be one of such home. This is the first thing. So it has all the same chances as a scroll or zk-sync and all those. This is the first thing.

The second thing is that Kakarot has one big advantage over all those ZK EVM, which is KO. And why is that? The thing is that it's not like the EVM was immutable. It's not immutable. It will still evolve. There are already some EIPs that will change EVM, etc.

And the problem that will be-- that those ZK-EVM will face, all of them except Kakarot, is that it will be harder for them to adapt to the evolution of the EVM because they don't have this high-level language to code the ZK-EVM. They did something roughly similar to what I explained before, like doing the mathematical construction by hand. This is more or less what they do, actually. They take the EVM--

operations and then they kind of build ZK secrets from this and this is painful. This is a lot of work. It needs a lot of audits and security research, etc. So

Well, with Kakarot, the future changes of the EVM will be really easy because it's a high level language. The impact of the changes of the EVM will be really simple to manage for Kakarot where those EKVM, it will be hard for them. So slowly, Kakarot will fill the gap and have

a competitive advantage over the zkvm even if it is now the outsiders the smaller as the kvm obviously because they are competing with giants like polygons uk vm scroll and and consensus as well but they have this competitive advantage and also the

because of Cairo again, they can have some interesting design where not only with Cacaro you can have EVM compatibility, but also you can interact, you will be able to interact with native Cairo contract on stock net. So that means this kind of interoperability can be also a huge advantage that they have.

And also, Kakarot will explore the possibility of having this ecosystem of EVM layer 3s on top of StarkNet for a specific EVM app chain. So this can be also a very strong opportunity

So I think it's a matter of timeline because the EVM has the network effects. So it will take time for it to kind of die and become obsolete, et cetera. So during this period, Kakao can have adoption on StarkNet ecosystem that will gradually

change over time and people will also have the benefit of being able to interact with the native Cairo contracts, for example, to have new features that are not possible in the AVM. So it's not only a ZKVM, it's a ZKVM++ in the sense that you can easily add more features on top of it.

It is more flexible, so it will be easier for them to add new precompiled features in the AVM because they have this high level language that is Cairo where it's easier to add new features and it's flexible. And you know, for example, Vitalik was amazed by the number of lines of code of Kakarot, which is very small compared to all the ZKVM. And this is a great advantage.

Small is good in terms of security, everything. Because doing an audit on those very small codebases obviously takes a lot less time, etc. So the fact that it's a high-level language is an amazing advantage for that, also in terms of security, etc. And another advantage is that

cacao team can really focus on the evm part and interoperability stuff and they don't have to bother at all with the zk part because this is a work of stock where because they use cairo they don't have to bother at all with the zk part where those dkvms they have to focus on both the underlying pooling system and also the avm part etc uh where the account can focus only

only on EPM and onboarding developers, etc. So they don't need to bother on the underlying infrastructure because they leverage on existing infrastructure. I see. We can see a lot of ZKROV and ZKEVM out there using ZK-SNAG. Why did, you know, Astartware finally choose ZK-STARK? So can you tell the difference? Yeah.

So short answer, I think everyone will be moving to ZKStacks and this is already happening. The main differences are the following. So first of all, snacks, they require a trusted setup. So a trusted setup is a kind of a ceremony where there will be some participants that will do some cryptographic operations and will contribute to generate some entropy and randomness. And this ceremony is very important for the security of the system.

And if the ceremony is broken, the whole system is broken. This is the first problem. And also, it's not flexible because it comes with some limitation. You need to configure some parameters during the ceremony that might be a problem in the future if you want to change them. You will need to do another ceremony and whatnot.

So in terms of security, this is a big problem. So stocks on the other hand, so the T in stocks is for transparent and transparent means that there is no need of a trusted setup ceremony. So you don't need to trust participants to do a ceremony in a good way, etc. So you have less trust assumptions with stocks. So this is an important aspect. Another important aspect in terms of security is

the fact that stocks are quantum resistant. So that means that they are more feature proof because they are based on hash functions which are quantum resistant. That means there are more feature proof solutions because once quantum computers become more powerful and straight, stocks will be safe, whereas stocks won't be safe. So this is another big difference. So those are the main big difference. This is why

everyone is gradually moving to stocks. There is another advantage of stocks, which is the efficiency in terms of the proving time and the verification time as well, especially for big computation. But the only disadvantage of stocks versus stocks is the size of proofs. The size of proofs is bigger on stocks.

So indeed, stocks have a slight advantage in terms of the size of the proof, which can lead to less expensive costs because the proof is smaller, especially for small computation. But overall, I think...

There is a strong recognition that stocks are a better solution in terms of security and efficiency overall. And that's why people are gradually moving to stocks.

Also, it's not as binary as it was. I mean, before there was a strict separation between stocks and stocks. Now there are hybrid models that combine both. So yeah, the separation is less clear now. There are some hybrid models and hybrid solutions. But yeah, generally speaking, stocks are more pure and probably more secure and efficient. Yeah.

I see. As we all know, Starware is founded for the problem of Ethereum scalability and we can see that there are still a lot of problems about Ethereum scalability. What is the biggest challenge you think that we are facing in terms of Ethereum scalability? For the moment, the biggest challenge is still

data availability. So there is a big change that is incoming on Ethereum to try to start solving this problem. This change is called prototank sharding. This is EIP-4844. So this will be a big change in Ethereum protocol that will be focused on trying to solve the data availability problem. You know, the problem is that all the swap solution, all the layer tools,

they are publishing a lot of data to Ethereum. Like you know, you do some transactions, then you need to prove them and you submit the transaction as well as the state of dates or the transaction data. That means that those systems consume a lot of data. So there are many problems with that. So the first problem is that data is crazy expensive on Ethereum. This is the most expensive operation, obviously.

And the problem is that there is a single fee market on Ethereum. You know, there is a unit that is the gas and the gas in the end represents very different resources. Some resources are computational resources, some are storage and whatnot. And there is no separation between this. And this is a big problem. Why? I will give you a concrete example.

If there is a spike of demand on the layer one, the gas price will increase, obviously. And that means that all layer two will suddenly pay much more to consume data. So this is a problem because a spike on the layer one can affect drastically the cost of all layer two solutions. For example, to give you an order of magnitude, you need to know that, for example, for REST at Starkware,

The cost of operating the sequencer is composed of 95% the cost is data and 5% only is the computation of the proof verification and whatnot. So the data is really what costs more for layer 2 solution. So if there is a spike of usage on the layer 1, all layer 2 solutions pay much more because there is only one fee market for the gas which is a single resource.

So the protodong sharding, this change will introduce a new fee market specifically for a new kind of data. So there will be a new type of transaction on Ethereum, which is called blob transaction. And this format, this new transaction won't be for users, but for layer 2 operators, they will use this new type of transaction to submit those data.

And the market for this will be separated from the market of the gas. So that means that if there is a spike of usage of the layer one, it won't affect the price of publishing data, which is good. And also, if there is a lot of...

data consumption by layer 2, it won't affect the price for users in the layer 1. So this separation is very good and it will enable to have way cheaper data for layer 2, which is good, and a higher throughput for data because this is also the big bottleneck for layer 2 systems. We are bounded by the data we can submit to the layer 1. So for now, this is one big, big challenge we have.

Also, there are many challenges that all those Layer 2 will face, including us.

mainly about the governance of the protocol and the fact that we all have some smart contracts on the layer one that are not immutable. That means that we can upgrade them and it comes with security risks because if there is an operator that is malicious, it could lead to some damages for users. So we need to, at some point, to fix that and try to find some robust model. But it's not easy because

You cannot just say I want an immutable contract on the layer one because if there is a security bug, you will be blocked and you cannot fix it. So it's not an easy question. So we need to think about defining new governance models that can work in this context. I think also there is a challenge I see on Ethereum.

not related to scalability, but more on the ossification of the protocol and the frequency of upgrades. I think at some point we need to consider slowing down the frequency of upgrades and to start ossifying the protocol because I think it will be very important and I think Ethereum should try to

minimize changes in the future and focus on removing technical debts and whatnot, but not adding more features and focus on being only a settlement layer for layer twos and gradually push for shifting users to layer twos. I see, I see.

Thank you Abida for the information and the insights. I guess the last question our audience would love to hear about is your advice. Do you have any kind of advice for the Asian developers? Yeah.

First of all, be curious. I would say this is the first advice. The space is evolving at a fast pace, so you need to be really curious to get all the updates. So I would strongly advise to read the community forum of StarkNet. There is a lot of interesting information. You can follow the updates and the discussion. You can also be part of the

the process of thinking about the future of StarkNet. We really want to decentralize progressively the governance of StarkNet and involve the community. So if you have some idea about what should be the future of StarkNet, feel free to jump in and create a discussion on the community forum. We are really open to suggestions. And then for opportunities, you can

always contribute to open source projects. As I said, we really encourage people to jump in and show up. And if you have questions, the community is very welcoming.

So if you need support, we will find you some people that will literally take time and do calls with you if you need to guide you, to give you some tips and advice. And yeah, and we can help you to have financial support if needed. If you have an idea of application, jump in, implement a proof of concept, then talk with us to see if you can get a grant to make it an actual project and business.

read the technical documentation, specifically the Cairo book to learn the language. You will have amazing opportunities because it's a fresh language. So learn through the book and then practice on the field directly contributing. This is the best

the best school actually. The best school is to practice on real projects and we have plenty of them. We have projects in Kaivo, in Rust. Yeah, an important aspect is that you can definitely contribute to stock net ecosystem if you are a developer and

And even if you don't know Cairo, you can contribute in Cairo, of course, but also in REST or different language for the tooling, the infrastructure. Because the ecosystem is still young, we need to build everything. So that means there is room for opportunities at every level of the stack, not only in terms of applications, but also in terms of infrastructure, tooling and whatnot. Yeah.

Yeah, yeah. Appreciate that. Thank you, Abdel, for creating such an open and collaborative developer community. This community is full of vibe and really appreciate that. And really appreciate your time to give us such amazing talk about the Starware ecosystem and hope that we can have some other meetings and events that can communicate directly with the Asian developers.

That would be amazing. Thank you very much. It was such a pleasure to chat with you and we're looking forward to collaborate more with you. Yeah. Yeah. Thank you. Thank you for your time. Appreciate that. Thank you. Bye bye. Bye.