Using scaling to address Ethereum congestion is undoubtedly helpful for larger adoption. As we all know, expensive on-chain transactions and spiked user experience are reasons why Ethereum network urges for scaling. Optimistic Rollup and ZK Rollup are two prominent Layer2 solutions. Optimistic Rollup is EVM-compatible with low technical cost, while ZK Rollup has shorter withdrawal duration and lower on-chain computing cost. zkSync, as a EVM-compatible ZK Rollup, is showing robust momentum.

The Layer2 Hackathon held by IOSG Ventures and Chainlink rolled out the second workshop, The Future is Now: An EVM-Compatible ZK Rollup for Scaling dApps, in a cool way of an online interview. The interview is hosted by Xinshu Dong (Partner, IOSG Ventures) and we’re pleased to have Alex Gluchowsk (Co-founder/CEO, MatterLabs) as our guest. They will lead you to dive into zkSync as an EVM-compatible ZK Rollup for scaling dApps, as well as its logics, mechanism, progress and merits, and respond to questions about what our hackathon participants care most about. The future is here! Don’t hesitate to check the following video in case you missed the on-air. We also share the wrap-up dialogues below for your reference. Here we go!

🎙️ Xinshu：

Hello everyone! My name is Xinshu, IOSG Ventures. I’m a partner at IOSG Ventures. Today we have Alex from Matter Labs with us. It’s our great opportunity to hear him sharing some of his thoughts about scalability. Today we are going to have a change of format. Instead of a monologue from Alex presenting the project, we’re going to turn it into a dialogue, where I’m going to ask some of the questions that I’m fascinated about. Then towards the end I will also pick some of the questions from the developers in this Hackathon. So for those of you who are not aware of layer2, this is part of the programs from the layer 2 Hackathon we are co-hosting with Chainlink.

IOSG Ventures is an early stage venture fund. We work very closely with early stage projects helping founders and developers build their projects along the way. So without further ado, let’s just get into some of these questions. I think we all know Alex, and we all know Matter Labs and zkSync. So to me, zkSync is a great piece of technology. It has everything we want, scalability, security, and decentralization. And with the recent introduction, the launch of Zinc now we even have great programmability as well. So this is something that sounds very futuristic except that it’s ready now today. Alex, share a little more about the secret sauce behind how this is even possible.

🎙️ Alex：

Sure, first of all, thank you for having me. It’s an honor to present here. So zkSync is indeed built on zero knowledge proofs. They are considered a kind of magic technology because they really solve a lot of problems in very interesting ways that were not possible before them. zkSync version 2, with EVM compatibility, is not quite ready.

It’s still in the works, we will open the public test very soon.It will still take some while to make it mature and ready for production. But it’s actually here. So the technology, the components are available. It’s a matter of pure engineering to complete them. I’d say that why it solves so many problems in a seemingly easy way is because a lot of thought was put specifically into making this technology very user friendly or developer friendly. Because they developers are our users, we actually architected that in such a way as to make it as seamless as possible for existing projects to migrate. Without this deliberate thinking, it would not be possible. If we just took the technology and shaped it the way that is more suitable for technology, we would probably have a lot more rough edges. But we deliberately designed the system with the ease of migration inside, this was the first priority for us.

🎙️ Xinshu：

Yeah, that’s great. Can you just share a little more on how you can make this even happen from the platform perspective? You know this key cornerstone of zk-based validity proof? How does that fit into the bigger picture? How does that make all these desirable features possible?

🎙️ Alex：

We had a couple of videos about this which explain it in detail, but I’ll just quickly say that the key innovation which made it possible is recursion, recursive proof composition.

This allows us to have different types of transactions with different execution traces to be combined together in one big block, then we can prove the execution of this one big block with Ethereum compatible virtual machine aggregated and proven to Ethereum is one single proof, so this was a key technology. Once the recursion became available last year, the rest became a matter of engineering, just gradually adding one by one pieces to make this composition practical.

🎙️ Xinshu：

Yeah, that sounds really fantastic! I think the beauty of a technology like zkSync is that, on the one hand, you have very sophisticated mathematics governing the security of it. On the other hand, you have made it very user friendly and developer friendly, so people don’t have to know every single bit of it to actually leverage it and harness the power of it, right?

🎙️ Alex：

I think if you imagine that we basically have this very scalable, very fast and secure platform to run applications, conceptually speaking, we might have two approaches in interacting with today’s Dapps, basically, smart contracts.

🎙️ Xinshu：

Why is that you could consider migrating the smart contracts from layer1 to layer2 through either rewriting, returning into Zinc, or through some compiler to compile Solidity into Zinc,

🎙️ Alex：

That is one approach, basically migration, after that, everything’s done, you just work on layer2, but there’s another approach, which is that you could actually aggregate the users and the assets in layer2, and interact with the layer1 contracts and Dapps directly. That’s the approach taken by some of the projects, such as Aztec and Layer2.Finance.

🎙️ Xinshu：

So what are your personal thoughts on these pros and cons between these two approaches.

🎙️ Alex：

I really like the invention of this approach, you can do interesting things like what Optimism is doing: privacy application DeFi that gives you private access to DeFi. I think the major difference between the two, which will push everyone eventually towards embracing the native layer2 functionality is the user experience.

User experience will suffer a lot if you are adding it sort of from the side, because if you are aggregating transactions. That means the moment you make a transaction, it’s not final. You have to wait for all the other users in the batch to also do their transaction, and then you need a lot of users, who want to do a similar kind of operation.

If you just want to swap, say some very rare token on Uniswap, then you have to wait for a lot of these users who want to interact with exactly the same pair to justify this transaction to make the batch. The costs of the batch are advertised across all of them and this will take time, this can take several hours, this can take days maybe before you collect in a few days. Whereas when you have something natively in layer2, when projects migrate, your transactions will confirm essentially instantly, you will still have to wait for the finality, maybe like an hour to get this transaction final. But you will still have an instant confirmation with economic guarantee of inclusion in the block, and most users will just take that and they will be fine. If you’re not receiving millions of dollars, this economic guarantee will be sufficient for you. The user experience of just having something immediately confirmed is so great that it will just provide a very important emotional feedback that will make users stick to those kinds of solutions.

But on the other hand, you also have economic advantages, like if you have to wait longer then the price may move, so you need to increase your slippage. Instant interaction is always a lot more efficient, so traders will prefer that, and the transactions for non-traders will also be a lot more profitable with low latency.

🎙️ Xinshu：

Right, yeah, I guess there’s some trade-off there as you mentioned in terms of latency, maybe certain kinds of DeFi applications are more suitable to one or another, right?

🎙️ Alex：

If you are too sensitive to price movements and volatility, then probably you’ll have to migrate application into layer2 and just run in there.

🎙️ Xinshu：

Speaking of running smart contracts or programming smart contracts on layer2, since most of our audience are from the developer background, can you just share a little more on your personal thoughts between the zk-languages. We have Zinc, we have Cairo, we have Noir, what are your thoughts? how developers can best choose which is the most suitable zk-language for them to implement their applications?

🎙️ Alex：

I would separate the zero knowledge languages like Noir from languages like Solidity, Cairo and Zinc. They just are generic smart contract programmability languages, where you build normal applications, something you would build for layer1.

Noir and similar approaches are aimed at building private smart contracts, they take an entirely different paradigm. You don’t write your code with normal functions that just imperatively executes the code, you write predicates that work with commitments, and you have to wrap your head in a very different way.

So let’s put that aside. If you need to build private smart contracts, you will have to go for those languages and learn these paradigms, and actually have to understand how these things work. If you just want to write scalable smart contracts for layer2, you don’t need all of that, you can either take Solidity and write your code there, or take some new approaches, such as Zinc, what we are building, or Cairo and write your contracts in these languages.

My advice would be, if you have an existing application for Ethereum, for layer1 or layer2, maybe you are on Polygon, maybe you’re just experimenting with layer1, don’t bother much, just take the same Solidity code, and you will be able to deploy on zkSync without modifications, unless you use some very specific things like cryptography. Everything should just work without modifications in your code. If you’re planning a new application, you might benefit from the functional languages, more advanced languages like Rust. Zinc is a subset of rust, just a better way to write your code. You have immutability out of the box, you have functional properties. Lot of this syntax is nicer, it’s easier to audit, it’s harder to make arbitrary mistakes because the syntax is very safety oriented, eventually we will support full Rust. Zinc VM is actually based on LVM compiler.

So we will be able to take the normal Rust code, and transpile it into this virtual machine. So if you’re writing something from scratch, just for specific layer2, such as zkSync. You can take Zinc and deploy this code. Alternatively, maybe you have an application written in Rust, which you want to reuse. This is also going to be a good benefit for you. But most users can just take Solidity, so it sounds like the toolchain nowadays is so good that Solidity is no longer a problem. You can even convert Solidity at least most of that, into running on zkSync.

🎙️ Xinshu：

Exactly. I read from the release note of V2, that there are just a few corner cases, a few instructions are not fully supported yet. But I assume they can be substituted with other instructions. And then for SHA3 and Keccak, it’s replaced by something else, but eventually it’ll be supported. Can you just share a little bit from the perspective that do developers have any considerations around these corner cases? Will there be any incompatibility issues? Or there’s really nothing for them to worry about?

🎙️ Alex：

Sure, there are just a few areas which are not supported in the first release. They are coming later. But they are not just going to be part of the first release. The first class is cryptographic operations. This means modular operations, add mod, sub mod, move mod and coding of the precompiles into cryptographic functions such as EIP 1962 and things like this, like verification of pairings and so on. So these things are not going to be supported, but they are required by very few applications.

They are essentially required only by applications that are building zero knowledge proofs. Or that are building some alarms with cryptography and most DeFi smart contracts do not need that. So if you really need these kind of things then you will have to wait if you wait a little. You will be actually much better off on zkSync, because it will provide a lot of cryptographic primitives out of box. That will be a lot cheaper than Ethereum.

So cryptographic verification of recursive zero knowledge proof on zkSync will be essentially not a lot more expensive than a normal transaction, a normal transfer now the second class of operations is some specific things that are a little harder. They require more work to be added such as Keccak hashes which is the native Ethereum hash and Ethereum cover and a couple of things like this that are listed in our block post. So they are not going to be supported in the first version. All invocations of Keccak will be replaced with invocations to a different what we call an algebraic hash function so if your program only uses hashes internally. It won’t be affected. If your contract needs to do some hashes external and verify them in the contract. Then it will be a problem that you will have to wait in those cases. The same applies if you need to verify Ethereum signatures when your users sign something externally. You have to verify them in your contract, so this won’t be supported in the first version.

Not many contracts use this but those who do, they have to wait a little. Specifically for the Keccak part, the algebraic function will produce exactly, the same hash result in terms of specification. Of course, like all non-algebraic hash functions such as SHA256 and Keccak. We will just work exactly as specified and produce the same hash as Ethereum. And we will support all of them the difficulties we always support, Keccak and SHA256 for signatures, for example. You can sign and you will not need a special signer MetaMask. You will be able to use your MetaMask or any other wallet to submit transactions to zkSync. The challenge we have is with variable hash function. When you make a hash of variable length, it requires you to add an additional thing like a precompiled for zkSync, this is just a little more work. So we have to wait till this work’s done.

🎙️ Xinshu：

Got it. Now let’s switch our topic a little bit on this grand level. We have this zkRollup architecture. But nowadays I think increasingly more popular. People are talking about Validium or even the combination of the two called Valition. So you guys have also worked out the zkPorter. I think people understand that the main differences in terms of data availability and the guarantees at this moment or even the stronger guarantee that would be possible, once Ethereum provides a data availability layer. But my question is around whether developers need to be aware of such differences how they are supposed to divide their logic between these two architectures. Or do they need to do anything at all? Will there be some tools to help them separate the logic and data across these two architectures. So developers actually do not need to be aware of anything?

🎙️ Alex：

Because from the point of view of zkSync, it’s the same system. We have two different account types, but the system, they are completely indistinguishable from one another. You can interact from one account with the other. You can make calls that span across multiple smart contracts that are located in different addresses and interact with user addresses in zkRollup and zkPorter parts. You will not see any differences except that in the cost of transaction which will be different but it will be on the validated level.

The users will decide what contract they want to use, so as a developer, you don’t worry about this. The users will decide, do I want to take the maximum security and pay slightly more transaction fees and use zkRollup account type or do I prefer very low cost transactions on the side chain and I’m willing to take some security trade-offs and then I’m going for zkPorter accounts. They just pay one cent for every transaction. There will be ways to optimize your smart contract to take advantages of this approach, but they are going to be purely optional.

So we will have a special guide on how to construct your smart contract in such a way to reduce transaction costs for users on the zkPorter site. But it’s completely optional, if you don’t do anything. If you just take your Solidity code, it will work without any modifications without need to re-audit it. So it sounds developers only need to develop for one platform and have that deployed once automatically it can be used for both deployments, right? Because it is one platform, it’s just one platform with two different account types.

🎙️ Xinshu：

Got it. I think we could probably imagine either end users will make the choice or more likely some of the user-facing applications or front-end will help users make such choices exactly. What’s your personal estimation on this, eventually, let’s say one two years down the road. What’s the percentage between users choosing and applications helping users choose the zkRollup deployment versus the zkPorter deployment?

🎙️ Alex：

That’s a really good question, in terms of deployment, all applications will be just deployed on this layer2 system. Right. So the users can decide what the users will pick depends strongly on the prices on gas prices. Personally, I think that the gas prices will go up, because I expect that there will have a lot more adoption of Ethereum and blockchains in general once the system becomes more affordable for many people.

So we’ll have new waves of millions of new users coming in starting to use DeFi and NFTs and all these things. This will massively drive the prices up. I think it will be similar to how you have your bank account with savings accounts and current accounts. Do you put most of your funds in the saving account. You have some disposable funds on your usual account where you just make some daily transactions there you’re exposed to more risk of fraud, because your credit card can be stolen. But you don’t have much limit there on the card. I think it’s going to be similar. Most of the value will be held in zkRollup accounts. This is where the whales, big funds and big traders will hold and most users will hold all their gold storage assets. But the casual activity will be done from zkPorter accounts which are a lot cheaper.

🎙️ Xinshu：

Yeah, that sounds very practical. I think that’s really a nice thing to do the beauty that one deployment can automatically serve two transactions or types of transactions. I think that will just make it adopted from day one. I assume that’s going to be the case for all applications deployed on zkSync, right? You don’t need to do anything else.

🎙️ Alex：

No. That’s fantastic. So, would you like to give any estimation in terms of the latency and TPS of transactions or anything once it goes live in a minute. Is it still due in August, the main net launch. The test net will be launched probably this month, we will probably open it to the public this month. The main net will depend on how much our system is so we don’t commit to any specific dates, but it won’t take too long in terms of TPS. The zkRollup will have the limitations of Ethereum, so it will share the Ethereum blockspace with all the other rollups. All the rollups will compete for the space. And of course, zkRollups are in a lot better position.

Because they require less on-chain dataTPS, it will have higher TPS. If we utilize all of the Ethereum blockspace, we will be able to provide 2,000 or 3,000 transactions per second. It also depends on the transaction type, like 3,000 transfers per second. But not all transactions are DeFi transfers, some of transactions are DeFi operations that take a lot more storage checks. You need to pull probably a lot more data for them, so they will be reducing the throughput. But we won’t be able to take all of that. There are other applications and also other Ethereum users. Realistically, we will be somewhere like thousands, hundreds of transactions per second. But on the zkPorter part, we don’t have any limitations.

So, it can go up to like, well, we do have limitations of the decentralized validator sets. We still have to run another consensus in layer2 to decide on what goes on the block. This is going to be the limiting factor, not the zero knowledge proof part because it’s important to have these transactions decentralized, not run by some central server. It will be similar to the best consensus mechanisms. It can supportFacebook Libra. If you look at Facebook Libra or at some of the Ethereum killers, like the levels they can support, this is what you will get there. So the limit is very high, but there is still a limit in terms of latency.

🎙️ Xinshu：

From the UX point of view, the users will get the confirmations instantly. The finalization on Ethereum will take longer . It will take from minutes to hours, depending on the transaction lot checkpoint. The more transactions happen, the more frequent checkpoints we can introduce, which will be subject to the decision of validators. But let’s say, if you have 1,000 transactions per second, there can be a checkpoint every minute or every half a minute. But if in the beginning you have less than that, if you have dozens of transactions per second or maybe like even less, then you have to wait for enough of transactions. Some like three to ten thousands of transactions to be collected in the block before this block can be submitted to Ethereum. And if I’m confident of my own infrastructure, I can also run a node and do my own validation. Then, at least for my application and my liquidity, I can support almost instant settlement. Is that possible?

🎙️ Alex：

I would not say that this is possible, because just like in Ethereum, if you’re on your full node, you still depend on the miners to finalize their transactions. It’s not like an Optimistic rollup, zk Rollup. With zk Rollup, you fully rely on the security of Ethereum. You don’t have to run your full node or verification in order to be sure that your transactions are final. But the finalization of the checkpoint on Ethereum only happens after you have a big block. But you have a confirmation of your transaction before this block is collected.

So if you submitted, you get it in the same second. Until the block is submitted to Ethereum, the miners could decide that they rearrange the transactions in this block, which will be visible to you. And you will be able to claim a compensation. So that’s why I was saying that, you will have an instant confirmation with economic security. It’s sufficient for you to be confident this transaction will come through.

🎙️ Xinshu：

If it’s the medium value transaction. But of course, if you are transferring one billion dollars checkpoint, you will wait for the checkpoint to be sure that is final or fail, right? So who funds the pool for potential compensation?

🎙️ Alex：

It will be done by the validators. So validators will act as block producers, the consensus of the validators. It can be considered to be a decentralized sequencer. But in the beginning, the sequencer will be centralized. It will be just a server that accepts transactions and puts them in a block, and then users would have to trust the sequencer to include their transaction checkpoint. If they don’t trust it, they have to wait for the checkpoint. But with multiple validators, it will be consensus that collects the block so that it appoints one of the validators to submit this block to Ethereum.

🎙️ Xinshu：

Got it! And then of course the fees are covered by the user fees. Alex, got it, thank you very much. Alex, I think it has been very intriguing, I guess a lot of very cool technological stuff. Maybe we can talk about some of the higher level but also very important questions as well. So, as I mentioned, zkSync. zkSync is just like very fantastic, futuristic technology that’s available today. And I feel it has all the strength to be very competitive in the ecosystem. I’m wondering what worries you, is there anything that worries you? What could possibly go wrong to hinder the adoption of zkSync and zkPorter?

🎙️ Alex：

Sure, this is a great question. I would say that if you have some Black Swan event , generally anywhere in the ecosystem, if something goes wrong with layer2, it will hinder the adoption of all layer2 projects. And of course, if it happens to your project, then it’s going to be even more. So it could be anything that, if there is some bugs in the code, bugs in smart contracts, some hacks because of this, or maybe just reliability issues that something goes wrong with consensus, with servers, system is down for some time. It will diminish the trust in the technologies and all of the projects that are currently launching. So we have zkSync version 1 running in production for one year, and it had a few down times. We never had any security incident, we are very, very careful about security. But you can never exclude that the tail risk always remains. You have to be prepared for that . The way we prepare for it is that we have a multi-layer defense strategy.

How we protect the user funds? We wrote a blog post about this some time ago. It’s on our Medium blog, where we have a kind of multi-factor protection. So before transaction is included in the block, it has to be verified by the server and by the validators. Only if the transaction is valid, then we produces your knowledge proof. This is the second factor, because the smart contract will verify this proof. Then, we have an upgrade mechanism. If something is wrong with the system, we can introduce an upgrade and fix the bugs there. But this upgrade comes with a time lock. So if we, the team, become malicious and try to introduce any changes that will steal user funds or corrupt state, or do something illegitimate, the users always have a time window to exit. And this is a longer time window, this is not like one week Optimistic Rollup. This is more than the window for Optimistic Rollups. But in certain situations, you need to act faster.

I can imagine the situation, where there’s some bug and it’s very, very unlikely, in the case of zkRollups that there is going to be any exploit to steal funds. But it’s more likely that there’s going to be something that will just stop the system and the system becomes unavailable. Just down time for some period of time and you need to make an upgrade to accelerate these upgrades. We introduced a security council. We asked some very respected people from the community. We have fifteen members of it to be available in case something goes wrong, they can accelerate the upgrade period, they cannot bring it down to zero. It will still depend on how many security council members vouch for this upgrade. The average period will be reduced to two weeks or one week or three days. But we will have shorter respond times for fixing things, so it’s all laid down in the strategy. I encourage the users to take a look.

🎙️ Xinshu：

Yeah, it sounds like that you have really carefully thought it through all the possible risks where things could potentially go wrong. And thank you for giving us these assurance that zkSync developers should feel very safe to build on zkSync. Shall we spend maybe ten or fifteen minutes to quickly go through some of the questions raised by our participants?

🎙️ Alex：

Absolutely sure

🎙️ Xinshu：

I think the first question is about hardware acceleration. I remember in one of your earlier videos, I heard you talking about that. Do you have any updates for us, especially in proof generation? What are your thoughts or plans for hardware acceleration? Are you able to share, whether it is more like ASIC or FPGA-based?

🎙️ Alex：

We will have an update very soon. We have our hardware proof is fully functional now and we are working to improve the performance. Will soon have something to tell you. It’s FPGA-based because we have cloud resources with FPGA instances available on demand and we will be able to use.

🎙️ Xinshu：

Got it, but the cost could be high, at least in the beginning?

🎙️ Alex：

No, the whole point of hardware acceleration is reducing the cost.

🎙️ Xinshu：

Okay, but you know, sometimes when it goes to mass production, ASIC can even give you better cost saving.

🎙️ Alex：

This is true, but with regard to ASICs, FPGAs are actually quite efficient for this kind of task, because what we’re doing there are some specific mathematic operations which are called multi-exponentiation and the transformation. Both of them depend on memory strongly, and you can’t accelerate memory much with ASICs. The benefits of ASICs will be maybe 2x, compared to FPGAs, but no more than that. So there is not much need, like you won’t get much benefit compared to FPGAs. FPGAs are available already pretty widely. They can be reprogrammed and even available on demand in the cloud.

🎙️ Xinshu：

So that’s why we decided to go with FPGAs. I think that will help the decentralization process of the validators as well.

🎙️ Alex：

Yes, correct. Because any anyone can rent this FPGAs instances

🎙️ Xinshu：

Yeah, I guess the community is looking forward to hearing more from you. The second question is about zkSync. Whether zkSync is going to be compatible with sharding? I assume sharding means Ethereum sharding. Eventually that’s going to come. is there any consideration in terms of compatibility?

🎙️ Alex：

So sharding should work out of box. We are still waiting for the final details of eth2: How sharding will exactly be implemented in eth2? And it will still take some time for sharding to arrive. So first we will have to launch proof-of-stake PoS. And then the proof-of-stake has to prove that it’s working fine. And then on the sharding, it depends on how exactly it’s going to be implemented; to what extent will it benefit the applications; can you access different shards simultaneously; is there coordination of synchronous and so on. But sharding is supposed to work. It just increased the throughput of the network and serve as this wider data availability bandwidth, which will simply lead to more capacity, more transactions per second. So we don’t have to plan any specific compatibility with sharding.

🎙️ Xinshu：

Okay, got it. Here is a quite a quite long question. So the question asked about zkSync. Whether zkSync still has a significant room for improving scalability once Ethereum itself, let’s say, layer1 gas improves its scalability and gas price will be reduced? I think it’s merely asking about, let’s say, after Eth2, some key milestones of Eth2 have been achieved, how does that affect not affect the scalability of zkSync?

🎙️ Alex：

That won’t affect it at all. So the only thing in Eth2 that can improve scalability of Ethereum itself is sharding. But as I said, we don’t have exact details of how sharing will work. So most likely the shard will become a synchronous and you won’t be able to have a composibility across shards, and this will not work for for most DeFi applications. So this is why Vitalik announced the Ethereum rollup-centric roadmap, where rollups will still fulfill the same function as they do in eth1. We’ll bring the same scalability factor; you will multiply the throughput boost of rollups by the throughput boost of sharding. But we have to see exactly how it is. The devil is in the details. We need to understand what sharding exactly gonna accomplish, then we can comment more on this.

🎙️ Xinshu：

Yeah, I mean the new roadmap rollup, as you mention, Ethereum rollup-centric roadmap, I think, probably that will guarantee that the roll ups won’t be affected when sharding eventually comes to life. Another question is about DDOS. It probably has something to do with the process of decentralization as well. So now this person is curious about how zkSync is going to be defending itself against the DDOS attacks？

🎙️ Alex：

DDOS attacks on the network? All blockchains have mechanisms against DDOS in Ethereum, it’s just paying the fees, so it’s going to be very similar. So I don’t see a different attack factor on zkSync than what you have on Ethereum, and if it’s not working on Ethereum, why should a different attack factor working on zkSync? There is no difference. It’s the same approach.

🎙️ Xinshu：

Got it! Next question is about when EVM will be launched. But I heard in one of the earlier videos that you could possibly support EVM ？But that’s not the point, right? You don’t have to with zkSync; you can already support the functionalities of EVM. So I don’t know whether we have anything to add to this particular question.

🎙️ Alex：

So maybe I can clarify how this system works exactly with EVM on Ethereum. You take your Solidity smart contracts and you compile them into EVM Bytecode. With zkSync, you take your Solidity code and you compile it into the zkSync Bytecode. The bytecode of this virtual machine; it’s a different bytecode; it’s very similar to how Optimism works. They have Optimism virtual machine, and you compile a Solidity into that. But for you as a developer, it doesn’t make any difference; what you do is you take your code and you compile it and you get some bytecode, which you deploy on in the system. It’s a different bytecode, of course. It’s optimized to be efficiently runable in their knowledge proofs, but it fulfills the same functions; it passes the same set of tests from Solidity and so on.

🎙️ Xinshu：

Right, so it supports Solidity at the source code level.

🎙️ Alex：

Exactly, don’t have any immediate plan to do bytecode conversion at this stage,

but if you use assembly in your Solidity smart contracts in your source code, the assembly will work just fine; because it will be actually supported at the instruction level.

🎙️ Xinshu：

Got it. Now I guess this is a common question: how does the zkSync compare with other layer2? But I guess there’s already very good coverage. Delphi Digital, for example, did a debate. I would recommend any participants to take a look at that as well. But for now, maybe you can just share one or two most important advice you have for developers who are trying to choose between different layer2 solutions; what would be your advice?

🎙️ Alex：

Well, absolutely I will answer the first question: How zkSync compares to other layer2 solutions? I will say that I don’t see anything but zkRollup that will prevail in the long run. This is going to be a very strong statement, but I can explain why. zkRollups are the only layer2 technology which is extendable with something like zkPorter or Validium counterpart, where you have the the best worlds of rollups and sidechains combined in the same system, atomically composable; no other layer2 tools can do this

This is very, very important. This is important because we see the rise of the adoption on systems like Polygon and Binance chain in this; clearly indicates that there is a whole class of users who care about the low fees, first and foremost. They don’t care about security as much as they care about the low fees.

On the other hand, we see that most transactions still happen on Ethereum mainnet, which means that there are a lot of users who don’t care about the high fees. What they want is highest degree of security and they are going to prioritize the absolute high degree of security; and of course it has to be usable, you should not wait like one week to withdraw the funds. So you have these different systems optimized for different use cases; zkRollup is the only technology which can combine them together. Imagine that Ethereum would be strictly interoperable that you had users from Polygon or Binance Chain Uniswap, who can interact with Uniswap on Ethereum in the same transaction. They can make a transaction that goes to Uniswap and Aave and to other protocols, and then bring all the funds back toPolygon to their account, and they are paying the low fees of polygon.

It’s not possible with the two systems. You have to like first move your funds from one to another. It takes some time and then you can make trades, and it’s expensive; then you move them back, and it’s expensive. It takes time again. But with zkSync, it’s possible. You have accounts on zkPorter site, and super cheap. You have accounts on the zkRollup site they are as secure as the theory itself; they have the highest degree of security; they like they are completely transparent to each other and so this is why I believe the zkRollups will absolutely prevail like there is no way that anything else will be there long term. So there will be other zkRollups of course, other projects are working on this. We have Starkware with Cairo. We have other newer projects that are working on zkRollup technology. I think no one is as close as zkSync.

Starkware at this point, like everyone else is far behind with Starkware, making emphasis on Cairo. They are not doing as much Ethereum compatibility, so it will be a question of do you need Solidity and EVM compatibility and you want to reuse existing applications, you want to be in the ecosystem of projects who will migrate to the system from Ethereum because they don’t want to reaudit the code. They have excessive code base; they just want to use the same products there or are you comfortable with building an application from scratch in a different language, and like start it in a completely new ecosystem?

So this will be your choice. If you care about the ultimate performance, you prefer this programming language over Solidity. Maybe because you like Python, or you know the syntax of Cairo is more similar to that then you can go for this. But if you want to remain in the ecosystem, you want to interact with Uniswap, Aave, Compound, Curve, Balancer , etc., like all the existing products that already committed to remaining in the Solidity ecosystem. Then you might be better start at zkSync.

🎙️ Xinshu：

It sounds like zkSync at least something like zkSync has this in built native capability of interoperability, even across different chain ecosystems. So that sounds like really something very beautiful to have!

🎙️ Alex：

Absolutely.

🎙️ Xinshu：

Got it. Let me wrap today’s session up by asking just one last question. This is also related to what we just discussed. So the question is about whether you see the zkSync going to launch different rollups, some might be more suitable for streaming; some more suitable for data intensive computations; some might be for other kinds of applications; or you are seeing just one zkSync behind the scene, you have a rollup and zkPorter. But it’s just one thing, which way do you do envision to be the case?

🎙️ Alex：

We definitely focus on one thing. We’re not gonna get any distractions. We’re going to build zkSync with a single system Solidity. Solidity support optimize for DeFi NFTs and these use cases. We want to bring DeFi to the masses. Our mission as a project is to bring public, decentralized blockchains to mainstream adoption to connect the mainstream users with the technologies, we’re just gonna focus heavily on this.

🎙️ Xinshu：

That sounds wonderful! Alex, thank you very much! It’s been a very inspiring session for everyone watching our session. I hope we enjoy the session as much as I did. Thank you, everyone!

🎙️ Alex：

Thank you, and thanks to all the watchers, it was a pleasure!

We’ve learned a lot from the interview. Thanks Xinshu for such a profound interview and Alex for sharing knowledge and vision as well as MatterLabs’ solid support. We hope it will bring different thoughts to the Layer2 Hackathon’s contestants and incentivise them to explore more. What’s more, we are going to invite more guests into interactions, either in interview or speech so as to commit ourselves to inspiring those who are intended to make contributions to the Layer2 space.

🤩 About Guests

Xinshu Dong:

Dr. Dong is the Partner of IOSG Ventures, and obtained his Ph.D in Computer Science in National University of Singapore. He is a computer scientist by training, having led several technical projects in cybersecurity for critical infrastructures and blockchain for enterprise use cases funded by Singapore’s National Research Foundation (NRF), Energy Market Authority (EMA), and Singapore Exchange (SGX).

Alex Gluchowski：

Alex is a software architect with over 15 years of experience in engineering and startups. Currently, he is a co-founder and CEO at Matter Labs, an R&D company on a mission to solve blockchain scalability challenges with zero-knowledge proofs. Alex is deeply passionate about individual freedom, self-ownership and decentralization.

💃 Upcomings

We have The Graph, who has successfully conducted their webinar about Building on Ethereum with GraphQL, The Graph, and Next.json on July 18th. Please check our medium/twitter if you missed out. And stay tuned for more online workshop from Polygon, Aztec, etc., coming soon.

Polygon

• Topic： Scaling Your Dapps using Polygon
• Time：2021.7.20

👀 Live here：http://live.bilibili.com/23288126

Aztec

• Topic：TBD
• Time：pending

👀 Live here：http://live.bilibili.com/23288126