Camila Ramos Garzon, Avihu Mordechai Levy, Laurence Kirk, Toghrul Maharramov, Alex Gluchowski

Yeah, it's a panel about ZK and the future potential.

So let me get my guests, if they'll come through now.

we'll give you a chance to introduce yourselves.

So to start with, I think it'd be useful if you could just give your names, the company you're working for, and your role there before we get started.

First, I'm very happy to be here today with lots of familiar faces So I'm a view.

You can probably find me shit posting on Twitter a lot But it's fun to

I'm co-founder of matter labs, which is the company by a zk-sync the creator of the kissing

Hello, I'm Danny Holland If you were here a few minutes ago, I'm with Vega Protocol, I'm a smart contract developer, and I just gave a talk about 5 minutes ago about ZK Rollups, so yeah, hi.

And thank you for coming in at the last moment to follow the panel.

All right, So our topic today is around the future of 0 knowledge proofs.

So maybe it would be useful if you would, can you give a quick idea of your roadmap from your company for the next few months, year, or that kind of thing, where you're heading?

Yeah, I think in this context, I'll say a couple of words.

So we are 1 of the companies in the ecosystem developing Starknet.

It's still on alpha mode, so it has all kind of training wheels.

And the next few versions coming this year will be mainly focused around significantly improving the TPS, then reducing transaction costs by enabling different data availability modes, so not just layer 1 data availability, but also L2 consensus, and then later on other layers.

And then following that towards the end of the year we'll also work on adding fee market to improve user experience and enable all kind of levels of service.

Maybe we can mention it later in the panel but I also would like to say that there are a bunch of efforts on top of Starknet, around Starknet to create the right frameworks for privacy, the right framework for gaming around that, which is also touching privacy in another way.

I feel like for us, the next few months are gonna be mostly about launching the main net.

There are still a few things that need to be added and things that need to be audited.

But it should be coming in the next few months.

And once we're on the main net, the next plan going forward is to start working on removing the training wheels.

So because when we're going to launch, a lot of the internal operations are going to be centralized, like a sequencer, brewer, et cetera, et cetera.

And there's a lot of research that we've been doing in the background for the last year, even more on how to decentralize those components.

Because while the user could use and interact with a protocol the same as with ZK Sync, StarKnight, and everybody else, there are still risks involved that will not eventually be there.

And the goal is to make sure that we minimize those risks as fast as possible and to make sure that the system is trust minimized and secure to use without a lot of additional assumptions.

At ZK-Sync, we are also working on a number of things in parallel.

So we don't have a sequential roadmap, because we have many teams working on different aspects of what the guys were talking about just now.

The scalability aspect, the decentralization of the sequencer, decentralization of the prover, the scalability includes the cost factor and the throughput factor.

There is the ultimate vision of what we all want to accomplish with rollups.

We want to build, we want to turn Ethereum into something that can scale limitlessly, that doesn't have any bounds on scalability.

And this can only be solved in some hybrid data availability model, like with using Volition, using ZK Porter, in some decentralized way.

Like, we don't want it to be run by centralized operators.

So there is this final North Star that we're achieving.

And it also involves probably having multiple chains, not just 1 chain, not 1 roll up that can handle infinite load, because that's just not feasible.

You cannot run all of the internet on a single server or in a single data center.

We'll be in the internet of these chains, and they must be connected in some seamless way.

So these are the priorities, and we prefer to talk about them as we ship.

And we are about to ship something really interesting in the coming weeks.

So I encourage you to follow us on ZK Sync on Twitter, and you will see some cool stuff.

So I actually got into ZK Rollups specifically to solve the gas problem for our multi-sig bridge.

So the biggest challenge at the moment where sorry the roadmap at the moment is there's not really 1 because we can't find auditors for CIRCUM.

Yeah we can't find and even if we could I mean all the techs too new all the cryptos too new like how do you guarantee it's going to be safe especially when working with something like Ethereum?

So, I mean, all of you are working on your own full ecosystems, but our usage of zero-knowledge proofs and whatnot are in interaction with Ethereum.

So it's weird because you cross security boundaries and whatnot.

I'll come back to security a little bit later on.

Okay, so some very exciting things ahead of us.

Is there 1 breakthrough or in the technology over the last year that has really impressed you, has really excited you?

For maybe not last year necessarily, But on the continuum of the last 2 years, I think zero-knowledge proofs in general have achieved a breakthrough in terms of going from, basically that was the period of going from 0 to 1.

Maybe it was not 0, it was 0, 0 something, but we definitely are at 1 now.

So the 0 knowledge proofs are productized.

We are at a point where the transactions are very cheap, the proof generation is very cheap, very affordable, you can scale it and you can also do proofs for individuals, you know like Individual stocks, individual stocks for privacy from the user perspective.

You can generate proofs in the browser or on a mobile phone.

This is a moment where now we go from 1 to many.

Where we actually take that and just roll it out into production.

So there will be more waves of innovation in the prover technology, in the protocols themselves, but we're past the point where we have everything we need now to actually build stuff.

If we're talking specifically about ZK in the past year or so I would say folding schemes have been quite a breakthrough and also another path to scale going forward And in terms of crypto in general, there are too many things to mention.

A lot of things on the incentive side, on the protocol side, on the consensus side, so for example, Hot Stuff 2 was published a few months ago.

There are a lot of things happen and the good thing about this space, there are still a lot of things that haven't been discovered yet and are yet to be discovered.

So there are even more things to come going forward.

So That's why I'm excited about this field in general.

Yeah, on the proving front, I guess, like in the last year, we saw so many teams doing so many breakthrough on so many different directions that I can mention.

Like we saw a huge improvement on working with smaller fields.

There are some all kinds of thoughts on combining different fields.

That's another topic that I think is now gaining some attention.

On the use cases front, I think the 1 thing that I would mention is the use of storage proofs that we haven't seen a year ago.

And now it seems that it's going to be leaving its effect on rollups and Zika rollups in particular.

Maybe we're seeing some things like with Axiom and the co-processor idea And the fact that we can interact then with data on Ethereum, how do you see that moving ahead?

I feel like the idea of storage proofs is great because it allows us to and to create cross-chain bridges that don't actually pass the messages as long as you can read the message from the message that was stored on the other chain.

That's more than enough for you to have a trust-minimized way to interact between chains.

And that can potentially have a massive effect on the UX and the way users bridge between chains, et cetera, because especially going forward with Ethereum, we're going to have a lot of chains trying to interact with 1 another, et cetera.

And a lot of effort is going to go into optimizing that cross-chain communication, and storage proofs are a good way to do it.

So Vitalik had a recent blog where he's talking about the problems of having multiple addresses across L2s and different chains.

And then you were talking about having many chains.

How do we solve this problem of interoperability and having something that is useful, is a good user experience?

I think this problem is a little more fundamental.

So Vitalik mentions 3 problems in his last post about privacy, scalability, essentially, like the cost and the usability with smart contracts.

I would add the fourth 1, which is going to be the segmentation or fragmentation of liquidity, fragmentation of the users, which is not solvable.

You won't be able to solve it alone with standards, unfortunately.

We could just get all the rollups together and say, OK, let's have a unified URI for addresses on different rollups.

There are already proposals for this, like if, with a prefix, if colon address, or z casing z colon address, or scroll colon.

And eventually, it's just 1 string, which you copy-paste, or you encode in QR code, which you can display to someone.

The problem is that even with storage proofs, even with cross-chain message passing, which theoretically can, or even practically, can be done, at least between ZK chains, the optimistic chains are out of the equation.

But in ZK chains, the latency will eventually fall to just a few seconds.

So you will be able to finalize your block on Ethereum.

And then the other rollup can read the state of this block and can access the messages that are committed in the block.

Problem is, you cannot still bridge assets natively.

You would still have to pass it all over Ethereum.

If we're talking about NFTs, you actually have to pass the individual NFT all the way through, from 1 chain to another chain, because you cannot blindly trust the implementation of another roll-up for reasons out of for non technological reasons Because the other roll-up can be upgraded by the team or by Security Council by its governance in a malicious way and then the risks of this upgrade must be contained to that roll-up.

It's a very fundamental security isolation assumption.

So like, and if the bridging goes all the way up through Ethereum, you can imagine it's like we have a lot of cities, but they are all connected with a single, like, very narrow bridge that everyone has to pass through, which, like, doesn't matter how many highways you have inside the cities, if the road that connects them is like a single pedestrian bridge, you can't carry much over a lot.

So I'm afraid we will see fragmentation where there will be ecosystems emerging.

Inside the ecosystem, there will be seamless bridging, and there will be many chains connected within it.

Between those ecosystems, it's going to be hard.

Some countries have really good infrastructure, have many cities, many railroads, many highways, et cetera.

But some countries are less developed, but still good.

But between the countries, there are checkpoints and customs, and you have to pay for moving things across the border So like this is kind of a scenario to which we're coming.

I don't see how we can overcome that like from

I do I think it'll kind of solve itself because there will be less roll-ups.

They will fail and those that remain, the builders will come and they will find solutions to this.

So that's honestly going to be a big 1, I think.

Yeah, I'm just optimistic that maybe not for all assets but for messages and maybe messages will include other this is a very complex issue.

So I think that in between the roll-ups and the challenges

have a complex interesting use cases, not just votes, you still have this way to bridge not going through a theorem directly.

But I think that we will, in between the roll-ups, we'll try to overcome at least

Bridging is probably the most complex problem that

So I don't want to say that it's an impossible feat, but it's definitely a difficult problem to solve.

But I'm just hopeful that at some point someone's going to come up with a way to do it.

Because if you look at what the bridges were like 5 years ago and what we have now, that the difference in trust assumptions and security is drastic.

And so I don't see a reason why we should stop here.

There will be nothing else discovered and nothing else that helps us make it more seamless in the future.

All right, I want to move away a little bit from scalability now and move on to other aspects such as privacy, but also this conference, if you've been to them before, they have quite an unusual manifesto, perhaps, compared to other conferences, they talk a lot about social good.

What, as people in the CK world, what can we do to further all of that?

Build community, share the knowledge you guys have found, you know, as actually I said that in my talk a little while ago, be involved, ask questions on, you know, Stack Overflow and whatnot,

We gotta find that weird basement nerd who's like, oh no, no, this is how we solve this, and he has to get his voice out, and it has to be there.

This is why I think we have a pretty high bar in Ethereum on the way we should interact with...

Like ZK-Sync is a license under MIT, Apache, and I would even scratch that if we didn't have to carry over the dependencies.

You have to be completely transparent about things, like the protocol specification, protocol design.

And then you have to give things over to the community.

And the ultimate owner of the protocol must be the community.

So things like decentralizing the sequencer, decentralizing the proofs, is non-negotiable.

It's not a question of whether our strategy is to build it or not to build it.

It's the fundamental core values of crypto that we represent, which go deeply in the roots of this original cyberpunk movement, which the party, the police, this place has played a big role in that.

It was a meeting point for a lot of crypto punks in the past.

I know Scroll, this is a very important thing for you, isn't it?

The mindset of the community and being community led?

I mean, we started essentially as a collaboration.

So the scroll was born as a collaboration between us and Ethereum Foundation.

So it's in our DNA and our roots to be open source and be friendly to the community, make sure that people should be able to contribute and should be able to get in touch with us, understand certain things that are, for example, are not well documented, et cetera.

So we always welcome people to come and speak to us.

And I feel like that's important and it's central to Ethereum's values.

Ethereum was built on this value of collaboration.

Like even if you look at the number of founders over there and with their mad like 30 40 founders and like it still goes on to this day you can't just say that oh yeah if your foundation is responsible for everything or somebody else there are a lot of different teams working and interacting with each other and collaborating with each other.

Even between us, we spend time talking to Starknet, to ZK Sync, to Optimism, trying to solve different problems together, trying to propose different standards and stuff like that.

So even if From the outside it might look like we all just hate each other and we're just trying to like completely dominate and like make sure that nobody else succeeds.

We have quite a lot of conversations and like discuss how we can work together to help Ethereum grow and become a better protocol and a community as a whole.

I know with StarkNet you have a very strong community.

Yeah I wanted to say something around that.

I think the decentralization, sure there is the part where you want to decentralize the sequencer and the prover and there is the part where you want to decentralize the sequencer and the prover and there's the part where you want the core infrastructure to be open source, but I think 1 crucial thing we're trying to achieve with Starknet is that you don't want you can't

have the project fully dependent or even largely

dependent in 1 or 2 or very small set of companies.

So, 1 thing that is happening, I think, in front of our eyes is that some companies are taking larger and larger shares of the work on some infrastructure part.

there is going to be a huge improvement in TPS, and a large part of this work was done by a different organization, not Starkware, but Lambda class.

And we see those examples also with ZKVMs being built on top of Starknet, so Kakarot

example, infrastructure of the provers, so there are multiple teams building a prover that is compatible with Starknet, and this is all done outside.

And I think that it's a huge step for a project when some significant shares in the core work are done by different companies.

To comment on that, I would say, remember when parity and Geth both were coming out, having both parallel tracks was very useful for the community as a whole.

Can I pick on a point, I think Alex said, but also maybe you, about standards in ZK?

And I know there's ZK Proofs, Rorg, who are trying to establish standards, but do we have a good idea of what those standards are?

For example, we were talking to StarCore and Polygon and we were trying to have Ethereum make an EIP that implements Poseidon pre-compiled.

And we couldn't agree on a specific standard of Poseidon that will work for all of us, because there are so many different configuration, et cetera, that it would be difficult.

Yeah, just to work more on this example, the challenge is not that we don't want to collaborate on how exactly will Poseidon be implemented, but at this point, we work with different technologies that require some different changes.

And It's not as simple as it might sound.

There is a common name, but the implementation can be pretty different.

So I think we're in this phase of exploration where we just experiment and it's good.

And then eventually some technologies will crystallize and stabilize over time, and then we will say, okay, this has been time-tested, we can now all agree on putting this uproot into Ethereum and making it pre-compiled, for example.

I mean, we don't even know what hash functions and signing schemes and whatnot will even be solid in 5 or 10 years, so everyone's implementing their own, and we don't know which one's gonna be the the 1 that actually stands the test of time like like Shah has and whatnot.

We will likely know it's gonna be not what we're expecting.

I think if 1 thing is open in this discussion is that we have some support from Ethereum when it comes to working on those primitives because sometimes we are coming and asking something and it requires a lot of flexibility for this to fit with all other networks at the same time.

So I do courses for developers in this area.

And the things that they ask me, I present about, I think, all of your products, and I teach on those, but a lot of the developers say to me, which 1 should we use?

And it's become easier a little bit because Rust is having such an influence now in this space, particularly with Cairo 1 now, it's become a lot easier.

You're just trying to get people to learn it so someone can audit it for you.

I think the future is, unfortunately, for Zircon that we will be very flexible in terms of support of languages.

And in the very short term, we'll be able to support basically everything from obviously Solidity, which is already the case, to Rust, to anything else that people use on the system.

So ZK Sync, for example, is based and our compiler is LLVM based.

So we can integrate any language which doesn't use things like garbage collector, but has a LLVM front end.

And it would be possible to prove execution trace of things like risk in other machine.

So I don't think it makes sense to learn any specific esoteric language today, because even privacy can be implemented with private smart contracts.

They will be implementable in Solidity and in Rust.

So why do those are very rich ecosystems where a lot of tooling and things get improved.

And you want to work on something that has future as a developer.

I don't know, man, the solidity thing, that's a lot of gas.

In the context of, I'm talking about the proofs.

You would be able to make a proof of something, like you will just describe some private function in solidity.

Think of it like you describe a smart contract and some of the functions you mark them private and they don't become just private from you know like you cannot call them from outside and they're not public but they actually private or the node functions some variables are private right so they they are part of the state but no 1 can see them except for the owner of this contract, who can then make a state transition by calling some function, which will be not called on blockchain, but they will generate the proof locally.

And there will be basically 1 function of the smart contract, like accept the proof and make a proper transition.

So developers will not need to bother about correctness of the proofs or details of implementation of zero-knowledge proofs, which is great.

So I want to say something about it that maybe, like in some ways, it's on similar lines, but with a slightly different conclusion.

So we have this framework being built on top of StarkNet that is called Dojo.

And that in particular also means that you need a client side for the users.

And well, it's not a server side, but a blockchain side.

And today, The way it works is that you have many developers using Siricom on 1 hand, and maybe they understand a bit what is happening.

And by the way, it's not just for gaming.

And then you have on the other side the Solidity smart contract.

So they already have to handle 2 different tools that are not necessarily looking similar.

And I think the reason many of them are still using Sircum is because Sircum offers this very convenient and efficient platform that you can use in your browser.

And I think what we are trying to do, and I believe that others here as well, is to create an intermediate level, and in our case, in StarGate, it's Cairo, that is both very efficient, and at the same time is easy to

use, easy to learn, and I think that Cairo

gets to the point where it's more like Rust-based, it's

pretty efficient, it's easy to use, and, yes, I do think that there will be compilations from other languages to Cairo that won't necessarily go through Cairo 1 but I think that if you have a language where you feel comfortable with like our 1 where you can write both the user side that runs on the browser and it's efficient enough and smart contract site that is also can be deployed in efficient network, then you get 1 framework, 1 language that you can use to write your game, your DeFi application, your logic, or whatever, anything else basically.

So to answer your question at the beginning, I would say yeah, learn Cairo.

So, as you pick up on that area of games, for me this area seems very exciting at the moment, and I've seen a lot of enthusiasm around this in CK.

Do you have examples or how do you feel about the area of developing games in ZK?

See all Parallel Polis transcripts on Youtube

Exploring the Future and Potential of Zero-Knowledge Technology