Anna (00:00:07):
Welcome to Zero Knowledge, a podcast where we talk about the latest in zero knowledge research and the decentralized web. The show is hosted by me, Anna.

Fredrik (00:00:19):
and me, Fredrik.

Anna (00:00:27):
This week I chat with Matt and Brecht from Loopring about how they launched the first live zkrollup on Ethereum. We explore the evolution of Loopring, how their system works, how they're introducing the concept of AMMs to L2, and what's next for the project. But before we start in, I want to say, thank you to this week's sponsor Parity Technologies. Parity, is a company building the core infrastructure to power web 3.0. They strive to write the fastest lightest and safest core technology in blockchain. And they write a lot of open source code. They're currently looking to fill a number of job positions. So for the Berlin office, they're looking for an experienced creative and enthusiastic content marketing manager. If you love attracting people with your writing and love, creating high quality and engaging content that drives business success, they want to hear from you. And also there's a remote position where you'd be working with a distributed team. This is for a CI/CD engineer. And the role would have you working to automate an ever-growing set of open source repos in GitHub. You should have experience with GitHub actions, Github CI, Linux, as well as compiler experience like Docker. There are several more positions to be filled as well, including many in engineering, business development and marketing. So if you're interested or know someone who is, you can find out more at parity.io/jobs, I've added the link in the show notes. So thank you again, Parity Technologies. Now here is my interview with the guys from Loopring.

Anna (00:01:58):
So today I'm here with Matt and Brecht from Loopring, which is a zk-powered L2 solution. And this is the first time I actually have you both on the show to talk about Looping the protocol. So welcome Matt and Brecht.

Matt (00:02:10):
Thank you, Anna. Thanks for having us.

Brecht (00:02:13):
Yeah, thanks Anna.

Anna (00:02:14):
By the way, I'm calling you Matt, is that okay? Should I say Matthew?

Matt (00:02:17):
Yes, Matt is fine. And just for the listener's sake, I am Matt. The other person is Brecht.

Anna (00:02:26):
So, Brecht, you've already been on the show. You actually were on the show for an an episode. It was kind of like a combo episode, right? Interviewed four different people about trusted setups or maybe it was five. It was like the trusted setups explained episode. But why don't you just for the listeners who are listening to this episode, give a brief introduction to yourself. Once again...

Brecht (00:02:49):
I was indeed already on for the, like the least fun part of our zero knowledge proof, how we use zero knowledge proof, so...

Anna (00:02:56):
The trusted setup, nobody want´s to talk about that.

Brecht (00:03:01):
Yeah. So yeah. Um, uh, back to us, I'm the chief architect at Loopring, so I kind of work on the main protocol and all the zero-knowledge stuff for Loopring.

Anna (00:03:12):
Cool. And Matt, this is the first time that you're on the zero-knowledge podcast. So why don't you let us know a little bit about yourself?

Matt (00:03:20):
Yeah, sure. Uh, rightfully so. It's my first time, because I am just, uh, on the business side of things of Loopring. So the fact that I'm here is, uh, gracious of you, but yeah, I, I kind of lead, um, the business side of things where mostly a team of engineers about 20 plus at this point and very little on, uh, on the business and ops side, although that's changing. So that, that's what I take care of.

Anna (00:03:44):
So I think, you know, like we just said in, in the episode that Brecht you were on, we didn't actually talk much about what Loopring was we really focused in on the trusted setup that you had run as part of, like, it was the... It was kind of the phase two from the Perpetual Powers of Tao. Um, but now I'm wondering, or I'm thinking we should probably start from the beginning about this project. Cause it's, it's also a project that I know has evolved a lot. So what was the original idea for Loopring?

Matt (00:04:17):
Okay, so I'll, I'll take this one because it's something I could speak to before we get into the weeds with the, with the practice. But yeah, that's, that's very right Anna. Loopring has been around for nearly three and a half years. So kind of born in the initial ICO boom, we started life as a DEX protocol. So zero knowledge or anything, scalability related was not in our mandate. We were a DEX protocol, specifically, an order book, DEX protocol, what was kind of like the hybrid style back then. So off chain order books and order messaging and matching off chain and then submitted to Ethereum for settlement. But even with this hybrid approach, the scalability was still pretty pitiful. We were able to do like settle, I think, three to five transactions or trades per second. Um, and because we were, we kind of fancied ourselves as an order - This was before AMMs and all that, right. This was to kind of just be a suitable order book exchange. We started looking into scalability approaches. I want to say in my mind the marker is around Devcon Prague. I remember being there and hearing about zkRollups and then I kind of re maybe I'm imagining this a bit, but I remember like texting, I think Brecht and Daniel being like zkRollups. So what are these things? It sounds like it could solve our problems. Yeah. And then, you know, sure enough fast forward, like a year or a year and a half, and we were the first zkRollup or the first roll-up of any kind. And, um, yeah, we use zkRollups to scale our order book, DEX protocol. So it was a quite application specific route, but that's, that's kind of the real short of it, where we were and how we got to being Zk.

Anna (00:06:10):
Cool. So the DEX idea at that time, there were few other DEX kind of projects around. Would you have compared yourself at the time to like Kyber. Were you in that realm or you kind of mentioned that the order book was off chain. So I guess it was a little bit unique that way...

Matt (00:06:26):
Right. It was much more of the 0x model. So they had their relaters, that hosted stuff off chain. Um, whereas Kyber was like, uh, on chain, uh, reserves and market makers like that kind of a request for quotes. In fact, like it used to be like, when I would explain Loopring back in the day, it'd be like, Oh, so like 0x. And I'd be like, yeah.

Anna (00:06:51):
When you first created the project, like, were you able to actually ship something relatively early? Like this DEX that you're describing, like, was that an actually a live product on chain? Like this was something that was being used or was it still kind of a Testnet thing?

Matt (00:07:05):
We did ship something. I mean, so we were purely protocol focused. We were building the protocol, but then we built like a prototype, but on main net that it, it worked, but it wasn't a real lovely experience at all. Like the fact that anybody used it as a miracle and, and it was, it was only lightly used to be honest, but yeah, we shipped Loopring V1, and then V2 had some kind of, just a bit more fancy features. And then V3 was the zkRollup. That was a, what took like a year.

Anna (00:07:38):
A big change.

Matt (00:07:38):
Right.

Anna (00:07:39):
That's cool. So you're like, this is the part of the project that I've always kind of been curious about because you Loopring kind of appeared on my radar, I guess once you had the zero-knowledge stuff in it as like a real kind of contender in the space, I do wonder like the problem that you were trying to solve, was it purely this idea of like transactions per second or orders taken per second and you saw zkRollup as a potential solve for that? Is that the pain point that you were looking to solve or was there like some other features of the zkRollup that appealed to you?

Matt (00:08:11):
Right. The zkRollup was meant to solve the transaction per second. And just to kind of replicate the centralized exchange. I mean, we, I guess we were slightly naive for us. It was just like, yeah, it was just that one aspect. It was scalability because in our case, I mean, as an order book exchange, the analog that everyone is comparing you to is, you know, the centralized exchange. And then when we would try to like espouse the virtues of, "Hey, use a Loopring decentralized exchange". It's like, okay, I'm really sacrificing a lot of UX. And I'm really going through a lot of hurdles just to, you know, have this nice property of my own keys, which of course is very meaningful to many of us. And probably the majority of your listeners, a DEX is useful for that, you know, non-custodial aspect and no KYC and stuff like that.

Matt (00:09:04):
But so that's how we started life trying to just, you know, build... Cause actually are like our main founder, our CEO operated a centralized exchange before Loopring. So he operated like a small one, a regional one in Shanghai, I believe. And then, you know, as a, as a technical person, he saw Ethereum and said, I want to build this on Ethereum. And then the throughput, it was just, it was just a poor experience. You can't build an order book exchange that people really love using, especially that market makers need to be able to provide liquidity right, quite quickly and easily to place an order to cancel an order, not pay 30 cents in gas for those actions. So the zkRollup was to bring us into the realm of competitiveness with legacy centralized exchanges.

Anna (00:09:54):
How did you though, when, as you were going through this process, like, how did you, what did you make of Uniswap? And actually, I don't, I've never had Uniswap on the show. We, I, I don't know how it works under the, under the hood, to be honest, but is it, it's all on chain and it's not an L2. So when you saw that, were you like, Oh wait, it is possible. Or were you like, no, we still have to push this are our system kind of off chain?

Matt (00:10:19):
Right. That's a really good question. And I like to say, so first of all, one, even when we started, when we started Loopring, Uniswap wasn´t around, even when we started the zkRollup research, I don't think Uniswap was around or maybe it wasn't, you know, as insanely popular as, as it is today. But Uniswap is an automated market maker right. It's a, an AMM. I like to think that they have that model and them specifically has such success because it is uniquely strong in Ethereum's environment. It's like the apex predator for this like slower, murkier, Ethereum, like an automated market maker is automated. So you have this formula. So liquidity providers don't need speed that you're, it's almost like your hands are tied. So the ability to do things fast and cheap is not so important. You just dump assets into this automated, market-maker this really elegant formula that says the proportion of asset A to B is the exchange rate.

Matt (00:11:25):
And so I like to think that it emerged out of like the, uh, the swamp or like this junk, this new, but swamp in a good way here, right? Like it was like the apex predator of its environment. Like you so-so, that's why AMMS on layer 1 had been so successful. Uh, liquidity is easy to bootstrap, whereas on an order book for us to go to like a legacy style market-maker, liquidity provider, someone to that we can just say, Hey, here is a venue, please, quote ETH in DAI terms, they're going to be like, I cannot do this to the best of my ability because you are too slow for me. But Uniswap said, "Hey, anybody" - forget even sophisticated market makers. - "If you have $20 in DAI and $20 in ETH deposited here, and now you are kind of like funding this formula", which is just this function. So that's why AMMs has have been so successful and order book exchanges have not been, but with the emergence of layer 2, we could now see order books become competitive because they regained what they were good for, their, their speed and, and allow market-makers to be, you know, to do their thing. So I'll leave it there.

Anna (00:12:34):
Cool. Brecht, what was your, what were you actually doing at Loopring before the ZK stuff? Were you working there already?

Brecht (00:12:43):
Uh, so yeah, uh, uh, briefly before that I was working at Loopring, but I only joined when we were already working on V2. So kind of like my history with Loopring is that like I was working for a game development, a small game development, uh, company. Uh, so I was, I was comfortable, but optimizing stuff and optimizing stuff puzzle of course also very important on L1. So Loopring had, uh, optimization bounty, uh, for their V1 and V2 and I kind of joined the V1 optimization bounty, and I was quite successful. So I kind of was noticed to, you could, you could say, uh, and then a little bit after that I actually joined Loopring full-time and started working on V2 for a couple of months. Uh, mainly, uh, just implementing, uh, the existing design and then like all the, all the ZK stuff started happening. So, uh, I was actually on aware of most of the stuff. And then Matthew, uh, sent me, uh, some, some links and then I started looking into it and starting implementing, uh, our V3. Uh, so with a lot of help, external help as well. Uh, next to Matthew,

Anna (00:14:06):
The talk that you're describing at Eth Prague, that was a Devcon 4, that Barry Whitehat talk?

Matt (00:14:14):
I am quite sure.

Anna (00:14:15):
In that little side room, cause I was there too. And I remember like even having known, like I had been doing this zero-knowledge podcast already for a year and a half or something and had been studying in a way the ZK stuff. But I remember that talk was one of the first times that I could see he, it was very, there was some like, very clear articulations of how the ZK, like how the, how the snark can be used for this. And, um, I don't know if he fully fleshed out the roll-up construction. I just remember him explaining SNARKs really clearly, but that's so cool. Like that, that inspired this potentially

Brecht (00:14:55):
Basically, basically we, we started from there, work on roll-ups, so I wasn't in direct contact with them yet. Now I'm more in contact with Barry Whitehat now and like other people that worked on the original roll up design, I would say. So, yeah. Then that basically was the original idea. And we just built on top on top of that.

Anna (00:15:18):
Cool. So now we've kind of reached the point in the story where loop ring has discovered the zkRollup concept and is like starts working, I guess the team starts working towards this L2, um, at the time that you were doing, this was the L2 concept already somewhat defined, I guess it was because there was like Plasma and I don't know if there was anything else, but...

Brecht (00:15:42):
Yeah, I think it was mainly Plasma and that was also one of the things that we were working on in parallel to our zkRollup. Uh, but then I think we got quite far, but then like a couple of months in, I think like March or April, probably probably 2019, I would say.

Anna (00:16:04):
And that's when the Loopring zkRollup version was released, I guess. Yes. And that was that released. Was that like the final version on mainnet or was that still kind of like in Testnet phase?

Brecht (00:16:18):
Mainly it was final. So we did some small changes afterwards, but not much basically has changed. So there were like with all the V1s of stuff, uh, it had some stuff that could definitely be improved, which we we've actually shipped now, uh, like a couple of weeks ago. Uh, but yeah, that was final for the time.

Anna (00:16:40):
Cool. So I'm thinking now it would be a really good time to kind of explore a little bit more of the Loopring construction. With this introduction of the zkRollup concept with, with it becoming sort of this L2 Dex actually, would you consider Loopring a Dex or as Loorping a construction in a protocol? What is it today?

Matt (00:16:59):
It's, it's both the Loopring zkRollup, uh, is a protocol, uh, an open source protocol. It's also a Dex that it's like, it's an exchange product that we operate on top of it, but so can anybody else? So yeah, it's both, it's, it's kind of, it's, it's interesting to describe our identity and our evolution, but yeah, there's the Loopring protocol team then there's the Loopring kind of relayer team, which I won't uncover all this now, but then there's also an exchange that we operate a topic.

Anna (00:17:35):
And so starting in 20- end of 2019, I guess, did you release all of this? Like when you talk about Loopring v 3, is it the protocol that's the new version or is it the DEX? That's a new version.

Brecht (00:17:50):
A it's a, we, we call the versions for the actual protocol because like all the other stuff, like the, the website, the relayer that hooks up into the protocol, all that stuff is of course we just keep working on it to make it better.

Anna (00:18:02):
Okay. So that, but those aren't like that you don't have kind of this like release schedule. Cause it, you might even still have the same interface, but behind the scenes, something changed. Yeah. Okay. So let's talk a little bit about this, I guess, start with the protocol. How does the Loopring zkRollup protocol work and maybe how is that different from other zkRollup if it is...

Brecht (00:18:28):
Well, well, of course it's, it's, uh, all zkRollup are basically the same, but of course there's a lot of, uh, flexibility on how you can implement stuff, but we are, uh, an app specific zkRollup. So we don't try to be like a general purpose where everybody can just build about, uh, so we just tried to do a couple of things very well and very optimized, so we can do transfer, straights and like yeah. AMM swaps and that's it. So that's, that's what we can do. We can extend it a little bit with the help of contracts, but like the, the optimized spots are those basic operations and like how, how it differs from all the zkRollup is like, yeah, it does those things very efficiently. So all the zkRollups can only do maybe transfers and atopic or atomic swaps or stuff like that.

Brecht (00:19:17):
So we kind of do those three things and try to do those three things well. So what, what, what the AMM swaps are kind of like the new stuff in our new protocol release. Uh, but our things have, have changed as well. So quite a lot of things were quite expensive to do on our previous roll up. So getting people on board cost like a lot of gas which we optimized a lot and also like a lot more flexibility on, on the stuff that we can actually do onchain. Uh, so like, so because we can only do a limited amount of operations in the zkRollup, we do try to make things easy to work with, even if you do some logic onchain. So that's kind of like the main things, I guess, that we have to be approved upon.

Anna (00:20:10):
So most of our audience is probably familiar with like a zkRollup, but I actually wouldn't mind hearing how you describe this. How do you explain zkRollup from your perspective, maybe to your audience and how you use it?

Brecht (00:20:25):
So basically, like, of course the, the, the, I think the easiest way to understand this, like, uh, maybe like just a compression of the transactions and it's like, what's with the validity proof, so we can compress all the transactions and we can actually verify that that the compression worked or something like that.

Anna (00:20:48):
Yeah, So You create, you kind of compress it into one proof that you can, and this is where I'm curious, like, do you verify, is the verifier a smart contract on-chain that verifies that proof? Where does the proof that you've created live?

Brecht (00:21:04):
So the proof generation is completely done off-chain. So, uh, that's kind of like one of the main computational heavy parts of zkRollup solution. So, while something like optimistic roll up, uh, you don't have to do any prooving and you just push all the data on-chain. We do have to generate this whole proof off-chain, which is quite computational expensive, but on the other hand, it's not really that expensive. So I actually calculated the costs for the proof generation compared to data on-chain, even pushing one byte of data on chain is more expensive than generating a proof for a whole transaction. So for our system in the particular different prooving systems have their prints, proving complexity. So it will differ a bit, but mainly the one thing that we want to optimize for is the amount of data that we actually push on chain. And not so much the proving complexity.

Anna (00:22:05):
Who, like you sort of said, the proving happens off-chain, but who are creating these proofs or what is creating these proofs?

Brecht (00:22:12):
Yeah. And that's so our relayer system. So our relay system bundles, I like all collects all the transactions and uses those transactions to fill up a block. And this block we send to the prover, the prover generates a proof for this block. And then we submit this block and the proof to our smart contract, to our zkRollup smart contract. And then we verify the proof. And if the proof is valid, then the state is update in the zkRollup smart contract.

Anna (00:22:41):
Is the relayer an entity, or is the, relayer a mechanism that's actually built into the protocol? Like, is there a, is there an agent there or is it something automatic?

Brecht (00:22:52):
Well, it's, it's completely off-chain as well. So there's a couple of ways you can do zkRollups, but like multiple people that can create blocks and submit them on-chain. But we don't do that for now. So there's one entity, which is us for now, which runs this three layer software software that creates the blocks and then can push it on chain. So in our smart contracts, we only accept blocks if they come from our ETH address.

Anna (00:23:19):
Got it. And are, are you also the prover then? Yes. Okay. But do you, you see, you kind of mentioned these as very, as distinct roles, the relayer and the prover, but if in the future, you, it isn't just you doing this, would it still, would it be a joint role or is it, do you imagine it being kind of two separate roles?

Brecht (00:23:37):
Yeah, it could definitely be two separate roles. So, um, we just use, I think AWS to generate our proof because we have that many transactions yet. So, uh, we don't really need that much compute power to generate the proof, but yeah, in the future, and there's like very optimized hardware to generate those proofs, then it could make sense to just, uh, send the blocks to those entities, let them generate the proof. And then we just be that operator basically just pays a small fee for the proof and then they can do it as,, it's completely trust this process. So you just push the block to the, to the prover and you get approved back and that's, there's no trust issues there.

Anna (00:24:21):
Is there any concern? I mean, I'm sure that this is a question that's come your way and maybe you have a kind of a plan for it, but, but you as the central entity or Loopring as a central entity that somehow doing the relayer and the proving, like I think it's optically, at least it has the sense that like, maybe that's a centralizing point in a potentially a potential vulnerability. So how do you kind of respond to questions about that? What's, what's your plan?

Brecht (00:24:46):
We don't offer full, uh, censorship resistance. So, but we do offer full, uh, censorship resistant for withdrawals. So while we can mostly decide what goes into those blocks, so which transactions are actually executed, people can still do a withdrawel requests on-chain, just using Ethereum, and then we have to withdraw their funds. So if we, if we do something that users aren't comfortable with or happy with like censor all their requests, for some reason, they can still do an Ethereum transaction and they get their money back without having to count on us actually being fair.

Anna (00:25:25):
Got it. Is it sort of like, is it, I guess it's in the logic of the smart contract itself or is it in the logic of the off-chain part where it like automatically will reimburse or like allow someone to withdraw

Brecht (00:25:38):
And say it's a completely, it's a, in the smart contract

Anna (00:25:40):
It´s in the smart contract. And I guess, cause that's sort of what I wondered about this. Cause like in that smart contract, are people depositing into the smart contract and the funds are then locked there and then kind of redistributed after the fact?

Brecht (00:25:53):
Yeah, exactly. So you deposit to the exchange contracts, zkRollup contracts, and then they are stuck there, uh, which allows us to do whatever logic we want with those funds. So that's actually one of the, like previously you asked, like, what are the benefits of zkRollups and one of the things is scalability, but the other kind the important usability benefit is that these funds are lock there and we can actually use those funds immediately off-chain. So we, we can depend on those funds to actually be there so we can offer like what we call like "apparent finality". Uh, so, uh, if you do a trade or you do a transfer in our zkRollup, then it's basically instantaneously final because we will just do all those transactions as they happen. That's, what's kind of like quite a problem with like full decentralized exchanges, because if you trade from your own wallets, then you can just do a trade. But before that trade actually settles on Ethereum, you can just transfer those funds out and the trade will either fail or it will have like a different outcome than you expected. So it's kind of like not what you would expect from like an order book actually. So that's kind of like the other, I think big benefits of doing it with the zkRollup.

Anna (00:27:18):
Now you, you did say that like as a user withdrawals are always possible and there's no sense that like the funds could be taken away, but it still does have that kind of, as you described, it's not censorship resistant, like is there plans or is there a thought to become that way or is it kind of a design choice where that's not going to be the selling point that you focus on, but rather speed, because I know that like having spoken to some other DEXs and also L2 DEXs is it's like, you're you have a particular target audience and they may not care that much about some of those things. So I wonder is that actually something that matters to the Loopring project and do you have a plan for it?

Brecht (00:27:58):
Yeah, it matters a bit, but it only matters basically. We think if things go wrong, so if we go offline and people just can't do normal transactions, then of course it's a bad user experience, which if we would have like multiple operators, which could create blocks and separate blocks, that wouldn't be a problem because at least one of those operators would be alive. Uh, so if, if we detect that our relayer would be down or something like that, then it would be interesting for us to still allow other operators to do stuff like withdrawals or, or like transfers or something like that. So at least there's some basic, some basic basic service, uh, level. Uh, how do you say it?

Anna (00:28:46):
Functionality? Yeah, I kind of like that there's some basic like is working somehow. It's still, would work.

Brecht (00:28:54):
Yes, it's still functional in some way. Maybe not like a hundred percent, but still for the basic functionality it's still there. Uh, so that would be one of the things that we would look into, uh, multiple operators. Uh, but otherwise, because we have like this order book exchange, uh, doing that with multiple operators and still have this like "apparent finality". If you do a trade, you swap, you immediately get your funds. Uh, like, like it's, you need to see the outcome. And on the, on the UI, that's a lot more difficult to do if there are multiple operators, which can do stuff at the same time. And then they, the, they have to do a like compete in some way or, or, or whatever, uh, set up, you want to like proof of stake or some of auction mechanism to, to be able to create this block. Uh, so that makes things a lot more complicated and I guess not much benefit to normal users that just use, use our products.

Anna (00:29:53):
Got it. And so it's, yeah, it sounds like it sort of falls in that camp where like, you really do have customer in mind, so it's not like decentralization for decentralization sake. It's got, it's got to have a reason for you to include it. Um, I have a question about something that I saw as I was reading through some of the documentation. What is a ring miner? Because I was kind of expecting you to say that like the prover or the relayer or someone is a ring miner, and are they the same thing or is that a different entity?

Brecht (00:30:24):
It's an old concept for version one and two of the protocols. So if you look at some of the documentation, like like the white paper, I think, which is still on our website, those things are basically not relevant anymore for the, for the newest version.

Matt (00:30:42):
Right? Yeah. Maybe I should have brought this up in the, in the history portion, but Loopring, when we started, where we get our name from is - so order book, but with like combinatorial matching. So like from one pair to another, could all be like in a ring to settle. So if somebody is trying to go ETH to DAI and there's no like match in that book, you could go DAI to US.... You could go up to n-pairs in these loops or these rings. So that's where we got our name, but that is since deprecated. From My understanding is because like the zkRollup became so primary and that is very not ZK-snark or -circuit friendly. Um, these ring matches. So we, we dropped that to kind of funny enough, we dropped our name, our name, our namesake, and yeah. Ring miners are nowhere to be seen. We much preferred, uh, just the scalability and like normal stuff than like a fancy matching mechanism.

Anna (00:31:43):
Yeah. It sounds like did that potentially inspire - Cause if you look on Uniswap, do you have that too? You have these like multi trading pairs, is that sort of taken from the original Loopring concept? I wonder.

Matt (00:31:56):
Yeah. I mean, I don't think we like invented this like combinant tutorial or like routing from like A , to like F and going like that. But, um, yeah, maybe I think we kind of were the, the ones doing that since 2017, but I'm not so sure we directly inspired it, but what was kind of a little side anecdote will also around like a Devcon 4 in Prague. I remember speaking with the Gnosis team and they started like, I think at the time it was so funny, they were working on some type of roll-up or plasma scaled exchange. And then when I was speaking with their team there and they weren't so aware of like exactly what Loopring did and I said, Oh, this combinatorial ... like these order rings, is it, Oh, we're working on another product that does that. And that was called deFusion at the time, which they have since, you know, productized and that's like the Gnosis protocol, which, which works now they have these, these ring miners or these like solution finders. So they kind of took what we were working on and ran with it and now have like a nice product with it. Like Mesa works on the, the gnosis protocols ring matching system. And then we dropped that and took their scalability focused thing. So we went different ways. Um, yeah.

Brecht (00:33:13):
Yeah. It's, it's, it's kind of like a funny situation indeed. So I remember me asking Daniel if it would be okay to drop ring matching in the V3 while was working on it because... Yeah. So that's the reason why we dropped it is because it doesn't fit very well standard zero knowledge proof circuits. So the circuits always need to do the same thing every time. So if you want to support like two or three or four orders in a single ring, then we would always take the hit of doing like four orders instead of like only matching two orders, which would be the most common one. Uh, so it kind of like was a, an efficiency, uh, consideration, even if that was the, like one of the important features of, of the previous version.

Anna (00:34:01):
Now you just mentioned, I kind of, the next thing I want to talk about is this kind of new release in the AMMs. But before I do that, you did mention Daniel and I don't know who that is. So I'm curious, like how big is the team? Who is the team? What does it made up of who is Loopring? Probably something I should have asked earlier, but I forgot

Matt (00:34:20):
We're giving him this, uh, this mystique now of Daniel, but Daniel. So, so he was the person I referred to that founded Loopring he's our, uh, I guess like he's a CEO and founder. He's who I said ran the centralized exchange. So, so Daniel, yeah. Daniel Wang and he's um, yeah, he continues to be our, our CEO and he's, uh, he's based in Shanghai. Most of the team is based in Shanghai, actually Brecht and I are actually two of three in the West. Um, and I think we're probably maybe 23 total right now. So that's 20 mostly engineers, um, in Shanghai and then, um, Brecht in Europe, me in North America. So yeah, that's the team. I mean, we've been hiring more with these recent product releases, but I think it's, I think it's under 20, 25 and mostly based in Shanghai, which is also, uh, gives us a bit of, um, you know, in terms of like the main Ethereum builders. There's, there's not, it's not as robust, uh, over there. So that's, it's an interesting vantage point.

Anna (00:35:25):
Cool. All right. Let's talk about v3.6, I guess this is the most recent version of Loopring that came out. And I, it was around the release of this, that I pinged you, Matt, because I was like, "Whoa, I want to find out about this. What is this like an AMM on an L2 ZK powered..." Like there, it just seemed like there was a lot of things that we talk about on the show that you are touching on in this release. And I wanted to talk to you about it. So why don't you tell me what, you know, what is version? I think it's 3.6, right? That's the latest, what, what was introduced.

Matt (00:36:04):
Okay. So I'll go over a few high level features and then maybe Brecht can talk about the technical ones, but our zkRollup has been running on may net for nearly exactly one year, December, 2019, which kind of surprises some people cause L2 seems like it only came about this summer when gas prices spiked or not came about, but really it became top of mind. But so we've had the benefit of running a zkRollup for a year, seeing how people interacted or did not interact. You know, it's kind of funny. We always broke like 1000 X L1 scalability. We could do two, 3000 transactions per second, but in practice we have like 0.1 transactions per second of people. Um, but, but nonetheless, you know, we've like before v3.6 launch, we had around 8,000 users on our layer 2 over the course of the year, uh, we settled 2 million transactions.

Matt (00:37:01):
So yeah, so basically v3.6 had, was a bunch of design improvements that we had in mind, but also that we just learned from real usage and real users. Nice. One thing is just like, so we created our zkRollup to scale order book Dexis, but then it was actually this sticks out in my mind as quite a funny thing. And I often mentioned this, but in the summer as gas prices started taking up a lot of like Ethereum researchers and scalability enthusiasts. And honestly like Vitalik specifically in my mind, like I would just see these conversations happen on Twitter. Mainly it'd be like, "Hey Loopring, why don't you enable transfers as well? Like you're a zkRollup that's live. Like, why are you only doing order book trading? Why can't you just allow people like, look at the biggest gas guzzler on etherscan and it's USDT right. And now gas prices are becoming high enough that even a transfer is no longer negligible." So people, we expanded our scope just by yeah... little nudges from the community and, uh, obviously respected community members. And just cause we're like, it was an identity thing. Like, Hey, why not? Why don't we do a bit more than just order book trading. So we enabled transfers. So if your on our zkRollup in earlier, you could also do transfers, you know, gas free and apparently instant on the L2. So at that point,

Anna (00:38:26):
Between users, I guess, or accounts?

Matt (00:38:28):
Exactly right. You had to be, but that's actually a great question because, because we came from our legacy angle, that means we only allow transfers between pre-existing accounts on layer 2, which is pretty crummy. Like you it's like anti network effect to like, you have to invite somebody on before you could send them one DAI. In version 3.6 says, "Hey, now that we are transfer aware, why don't we allow the ability to send to any Ethereum address? Not just pre existing one." So that's a big improvement in 3.6 that we allow, you could go from L2 to any, uh, Ethereum address that there was not L2.

Anna (00:39:09):
But it would the person to be able to claim it. They still have to go onto the L2. Right. Like, but it's, it's, it's attached to an, an L1account, I guess, like the equivalent on the L2.

Matt (00:39:21):
That's exactly right. That's exactly. I'll leave. Maybe a Brecht wants to say a few more words about some of these other nice tweaks that 3.6 has.

Brecht (00:39:29):
Yeah. So, uh, like just general improvements. So there was quite a lot of extra logic that basically nobody really cares about. So, uh, so we always did like the posits and withdrawals, like first in, first out, but basically nobody cares much about that and it made stuff much more expensive to do deposits or create accounts on chain. So that's kind of like things that we optimized for. So basically we tried to make things cheaper for users, especially, but also provide like much, a better user experience because of the things we do now. So one of the other big things is that we had like these transaction specific blocks that needed to be submitted. So we could only do like a block with all trades or a block with all withdrawals. And this was kind of like quite a big of a problem because, because we don't have that much transactions yet that many projections yet on our roll up, people would have to wait quite a bit of time before they, the withdrawal was processed because we waited until we had like quite a few withdrawals.

Anna (00:40:35):
You're batching them and this was delaying stuff. Got it.

Brecht (00:40:39):
Yeah. Yeah. So now we can just do all the different transactions type in sync and the single block. So we can also do like all the traits and then just do the single withdrawal and people get their money as quick as possible. Of course we will also have like more advanced features, like the, the, like the fast withdrawal stuff. Like we can do withdrawals even before the withdrawals is actually processed, so we could send people money instantaneously and then do the patrol actually afterwards. Yeah.

Anna (00:41:08):
Is that almost like an optimistic one then? Because then you're, you are doing the transfer before the proof.

Brecht (00:41:14):
Yeah. You could say that. So we have, we would have to depend on liquidity providers and like the optimistic word used is kind of like fitting because it's much, much more important for optimistic roll-ups because they have like very long finality times. We with zkRollups we can just, yeah. The withdrawal is final. Once we publish the proof, which we can do pretty much as fast as we want, but yeah, of course the faster we do it, the higher the gas price we have to pay and the less transactions we can fit in the block, which makes things more expensive. Got it. Uh, so we can do, like, within a couple of minutes, we could make things final on chain for users so they can get their withdrawal, but for optimistic rollups where its 1 to 2 weeks of finality times, these fast withdrawal mechanisms are much more important because otherwise, people would have to wait for 1-2 weeks before they can get their money out.

Anna (00:42:09):
One of the other announcements that came out was this idea of an AMM function. What, what does that mean? Like what exactly, how does an AMM fall into this? Where does that work? And you define this earlier, Matt, AMM stands for Automatic Market Maker. So is there an automatic market maker in this new version?

Matt (00:42:30):
Right. So there is that, that AMM, which has seen a lot of success on layer 1, because as I say, it kind of grew out of that environment made for that environment. Now we say, let's bring that to layer 2. So it has the nice properties of gas free and like apparently instant, um, swaps and adding and removing liquidity. So, yeah, it's, it's very exciting because AMMs have just become such a big thing on Ethereum. Now that they're on layer 2, as of like a week and a half ago, we'll see how, how the take-up is already the big from a practical point of view, like what it allows us like or in my mind from the, you know, like the business or just what users want to see. It allows anybody to become a liquidity provider before to add liquidity, to make an order book. Like, like if we're, you know, listing Anna token versus Eth today. Okay, that's a fake, that's not a real token.

Anna (00:43:28):
We're not shilling anything I promise.

Matt (00:43:29):
Yeah. Necessarily, but this new token, like to just put it on an order book where it's like an empty desert does not accomplish anything, right. We have to get somebody who is willing to say, I will sell, you know, ATC at this price and buy it here. Uh, you know, like I'll sell this, going to buy, like you need a person being active. And really that is like a robot that is a trading bot that does that. And those are, that is, you know, very, well-defined like legacy style players who have low latency bots, and they're doing that. So that is not so friendly to bootstrapping a liquid environment. You have to speak to these, just speaking to this entity is a time consuming thing, right. And maybe making agreements or getting them interested via incentives, but the AMM, which I'll allow Brecht also to expand further how we like zkRollup, is it an automated market maker, takes the strategy, a unique strategy out market-making and replaces it with a function, just a math function.

Matt (00:44:35):
There's different ones. And liquidity follows this function, this curve. So it's like deterministic it's automated. So it allows anybody you, me and a sophisticated wall street firm all have the same advantage or disadvantage of just the positing liquidity depositing tokens here. And it being a suitable environment that people could come then take trade against our liquidity without us needing to be active or sophisticated. AMM like, just to sum that up, they really are nice because it levels the playing field. It means that anybody with some amount of assets could put those to productive use by supplying liquidity, to other people who want to take that liquidity without needing to spin up a trading bot, be like, without those kind of more sophisticated considerations.

Anna (00:45:26):
Brecht you like, can you share with us a little bit how the zkRollup plays into this? Like AMMs I think we understand, we do know them somewhat from like the Uniswap model, but like now you have an AMM on L2, so people would have to lock on the main chain move, like their funds then appear on the L. Is it sort of following the same idea that you just like deposit every, you know, you deposit the two sides of the, of the2 trade and you're, you're generating either a percentage on trades or a token, I guess, from being the contributor to this?

Brecht (00:46:01):
Yeah, exactly. Uh, so, uh, it works exactly how you would expect it to work. So it works the same as L1. So instead of doing an actual deposit, looks like there's no special add liquidity or remove liquidity operation in zkRollup, but it's implemented with the basic building blocks as transfers on the zkRollup. So basically it was easy for us to implement because we already did trades and trading is now as like a special flag now for AMM traits, because AMM trades are just special orders. You could say that just define a minimum price that they expect. And so if people want to pay more than that, we'll be fine. But like, if the trades actually matches that minimum price of the AMM, then we just allow the trade to happen. So it's kind of like a very elegant way with what we already had to implement stuff.

Brecht (00:46:59):
So we could actually do whatever trading that we want so we can do, uh, if people want to buy a specific one. So there's like a specific order, then we can still change on how we actually want to fulfill that order. So we can do that against our trading book, or we can do that against the AMM. And that can be like AMM against AMM trades. Uh, also that's also possible. So that's kind of like how it works in the zkRollup specifically. So there's, there's also like the one, the proof mechanism. So the people allowing people to deposit their funds, not that complete mechanism is done inside the rollup. Uh, so there's a little bit of logic for pools on L1 that just matches how the tokens are actually transferred. So if you deposit something, if you want to add liquidity to a pool, then you just do two transfers. Like if there's two tokens in the pool, we just do two transfers in the pool, and then you get the liquidity token transfer back. And that's how we kind of build the pool mechanism on top of the, the basic building blocks that we already have.

Anna (00:48:09):
Cool. Do you think that there might be a chance that you revisit or reimplement the ring trading one day? Just cause I'm thinking like what you're describing there, it's like, well then you are getting maybe in a situation where you do need to like jump a couple pairs, especially if the volume gets high enough.

Brecht (00:48:27):
It could definitely be an interesting one. So, um, we, you could say that we could implement like some of the benefits of ring trades just by doing multiple to order trades, but that doesn't always work as optimally, but like the advancements in zero knowledge proofs, like I said, like before, like we didn't do it because we currently match all the logic that we have to do directly onto a circuit. And so the circuit always needs to do the same, but, but like these, these more advanced zero-knowledge proofs and like these more advanced general purpose languages on top of a zero knowledge proofs, that isn't always the case anymore. So you could do, if you do more operations and it's actually more expensive to do on a zero knowledge proof circuits, if you do less instructions, it's actually more cheaper to do so in the future, probably this, this consideration won't be 100% valid.

Anna (00:49:18):
Like you won't need to worry about it as much, I guess. Yeah. Yeah, exactly. So you will be able to do a bit more. Yeah. There's some other projects that we've had on the show that talk about the zkRollup model, for example, Matter Labs and zkSync or Deversifi and their work with StarkWare. Where, how do you sort of see yourselves in comparison to these other zkRollup generally like the ecosystem, like you kind of see yourselves as competitors, do you like learn from these models? How do these different groups interact?

Matt (00:49:52):
So that's a very good question. In some cases they're competitors, but I think we really think of them as like, we're really on the same team here and the advancement together. Like it's so nascent and like, I personally, I'm not just saying it, but I love, I like to see success by the other projects you just mentioned, but like practically speaking, the differences or similarities are... So Loopring works now look across the whole stack. We have the Loopring protocol, we have the Loopring relayer/ prover, by the way, going to that, I wanted to jump in there. Like the operator might be like the word that combines them all - "relayer plus prover" people's operator. Yeah.

Anna (00:50:34):
And in general, there needs to be a word that's used for this role in the L2s, because we ha- we are seeing like, every there's like groups that are calling it a committee, there are groups that are calling it like a validator, even though it was kind of like not a validator in the way we've thought about it before ... operators sounds good. Relayers, one provers, one. So, yeah, there's a lot of ways that people describe this agent that is basically kind of checking what's happening off on L2 and bringing it onto the L1.

Matt (00:51:04):
Yeah, exactly. Often in like our group chat, I just like to users, I say, no, the relayer (The thing that makes the roll up run) like that that's all right. But, um, yeah, so, so we have the protocol, the relayer and now like, increasingly, products. So like that is, I believe quite unique or like strictly unique, like deversifi uses StarkWare's stack and tech, and like deversifi operates just the product, like a really also beautiful fast order book, trading experience. Um, but you know, not, not the lower level stuff and similarly StarkWare doesn't operate the full extent. So that like, that's the difference there. And similar with, um, with zkSync and Matter labs, they are really building a protocol. Um, they at least insinuate the disinclination to operate anything above it, which is fine to, to take their word for it then I'm sure like, so, so they're, they're concerned with building a protocol that everybody could come on to and build,

Anna (00:52:09):
I guess it's a little bit more generalized in that way.

Matt (00:52:14):
Right! So from like the business or goals, point of view, there's differences between where and what Loopring wants to be versus what StarkWare, Deversifi and Matter Labs want to be. But there's also important technical differences, not least of which is like StarkWare using Starks and all that, but also just like they're tending towards becoming more generalized platforms. Whereas Loopring right now is as Brexit just focused on doing a few things as best as possible. But yeah, the, the, the age of generalized ability in zkRollup is nigh, I guess. And, uh, that's, that's something very exciting and something that we could very well benefit from and work from and borrow from, and, and, you know, uh, incorporate into our future versions of the protocol. But yeah, maybe Brecht has a few words on the technical differences between the zkRollup family here.

Brecht (00:53:09):
Uh, yeah. So, well, the technical ones are, well, maybe not that important, but yeah, of course the, we all use different, uh, zero-knowledge proofs to do what we want to do. And basically I think the, the main, the main difference is like Matthew said, let's say if one year from now we wanted to start using zkRollup for scaling. Would we still build our own stuff if, if like general purpose solutions would already be there? I guess the answer would be no, because we are more interested in building the products, but like one or two years ago, that just wasn't possible. So we want to do the scaling for our apps. And the only way that was possible was to build our own scaling solution as well. So that's kind of like the situation that we are now and, and, and that, that was like the good decision to take, because otherwise we would still be on a full layer, one solution, and we wouldn't have any, we wouldn't really have any, any other, uh, options available, but that will probably change quite soon. So I think definitely one of the more interesting approaches, uh, to take in the future.

Anna (00:54:21):
I was wondering about the SNARK itself that you've decided to use, because like you say, it's, it's quite limited in, in what it needs to do. There's like very few functions that it has to prove for, kind of, aren't maybe functions is the wrong word, but like actions that it needs to prove for, but what, what kind of SNARK is it? Is it like, and yeah. What is the circuit size and like, is it a smaller, easier snark to actually use?

Brecht (00:54:46):
Yeah, so we use Groth16, uh, which is kind of like the, well, you could say it's the oldest one, in the standard, the standard and the oldest one that's that's currently available, like zkSync uses Plonk and StarkWare using STARKs. So the reason for that is that yeah, it was when we made it, it was the only available one, uh, that we could use and we are not cryptographers. Uh, so we kind of limited with what was available to be used in like a production environment, which was Groth16. Uh, now there are a couple of more options, but still quite limited if you want to really do everything yourself. But yeah, so our circuit sizes, like one of the important ones that we use is like Poseidon for the hash function. So our Merkle trees and all the other stuff, we use Poseidon to limit the complexity of our circuits.

Brecht (00:55:41):
And that's basically the biggest part of our proving costs. So that's like Poseidon for the Merkle tree and SHA-256 to hash the, all the data that we get on-chain. We hash it using SHA-256 because it needs to be efficient on-chain as well, as well as, as efficient as possible in the circuits. So that's kind of like the, the only hash function that can be used for that. And so the total cost for a Loopring transaction is now around 130,000 constraints per transaction, which is kind of like quite, quite okay. Uh, it's like double the cost of our previous release because we can now do all this stuff together in a single block. So that's kind of increases the cost. We also made like the Merkle trees quite a bit bigger. So we, now we can support more tokens, more users and stuff like that, but yeah, that's kind of like double the cost, but by the complexity cost, but still the actual dollar cost for the proof generation is very low. So it is like a $0.0002 to prove a single transaction, uh, which, which these gas prices that are currently available is just like, like I said before, the data is much more expensive than the actual zero-knowledge proving costs.

Anna (00:57:01):
Very cool. So the little last part of the kind of Loopring world is this wallet. We didn't actually get a chance to speak very much about it. So why don't you tell us, like, tell our listeners a little bit about the wallet that you built and why that's kind of exciting.

Matt (00:57:17):
Yes. Thank you. Um, that is another recent release. So as in your research, you've kind of found that all Loopring protocol version 3.6, just launched with the AMM that we expose in like a new web UI, but the big thing, and another big thing is the Loopring wallet, which is a mobile Ethereum smart contract wallet with our zkRollup kind of tucked in natively to every possible action in the wallet. So it's really exciting because it's the first time that somebody could interact natively with the zkRollup and kind of feel this like legacy performance of zero cost or, or, you know, gas agnostic, like not subject to spikes and stuff and, and, and delays. So, so yeah, the Loopring wallet is a mobile app. Currently Android only, hopefully iOS in early 2021, and it's a smart contract wallet. So it does a way with seed phrases. And instead has, um, the concept of guardians, which you could name as another hardware wallet you control, or a friend or family like your guardians more than half of which have to be kind of faithful to you in order for your assets to be safe in the smart contract wallet and, um,

Anna (00:58:38):
Is it like a multisig in a way, or like, um, like it can be recovered through multisig?

Matt (00:58:43):
Yeah. I think about it as a, as a fancier multisig, it has some extra logic, like you could have like daily quotas and like white-listed addresses, but I guess in there in the recovery sense, yes. Like two out of three guardians have to turn the key for you to recover your wallet. So it's, it's, it's also like a, a new set of UX challenges to expose to users, their Ethereum L1 account and L2 in the mobile app, right. Like we're trying to abstract that away as much as possible. So this could just be like a global Venmo or, you know, global WeChat pay. So it's a, it's a whole bunch of new like UX, um, hurdles, but ultimately really good reception so far. It's just really cool to be able to send from your phone, uh, you know, half of a US dollar stable coin to anybody...

Anna (00:59:37):
And not get charged crazy amounts of gas for that. That's pretty useful actually. I have a poker online, poker game that I play weekly and we end up sharing. We send funds very small amounts because it's very, very low, low amount games, $5 here and there. And so actually what we don't use crypto because it's just too expense the gas, but it wouldn't make sense that the gas prices...

Matt (01:00:01):
If you're on Android, please get your poker game to onboard to a Loopring wallet. But, uh, yeah, that, that, that, that, that, that sums it up with, with also the AMM within the wallet at the end. It's exciting for, for me, like, as opposed to like, you know, like Brecht builds all this, you know, beautiful stuff, but at the end of the day, we like just distill it into a mobile app and say, Hey, this is a really powerful product. And the user doesn't necessarily care about the intricacies of the zkRollup, although it is really important to our value prop that we can never mess with your funds. This is not just any type of trusted scaling solution. When you're on layer 2, we could turn evil, go away be pressured, and no matter what, you could get your funds back, as long as Ethereum exists.

Anna (01:00:49):
That's really good. But I want to ask about how the ZK, how does the zero knowledge proof work with the wallet? Like, is it being cause it, is it sort of just sending, this is just the L2 part is working on the wallet. It gets sent to Loopring, and then it gets written to chain, or is it the smart contract? I'm just kind of curious where the, where the proving and the relaying happens. It doesn't happen on your phone. Does it?

Brecht (01:01:13):
I say no, no, no. So, um, it works with the API. Uh, well, anybody could actually build products on Loopring because we have an API. So it just, you sent transactions on Layer 2, if you want to do on Layer 2 you send them with API to our relayer. Got it. And then we just batch them, like no other cases.

Anna (01:01:32):
I just do know that there's some projects that are talking about doing ZK proofs on mobile. And that's like what I'm hoping for one day, but I think it's still a little ways off.

Brecht (01:01:42):
I think that's mainly for privacy stuff, because if you use it for scalability, you kind of have to, uh, like you have to do batches as well. So you need to send them somewhere so they can, can be batched together.

Anna (01:01:54):
Actually, that was a question that I had was, is there a privacy part of this because using zero-knowledge proofs, I mean, a lot of the other projects that did only use ZKPs for scaling now, at least like consider privacy, is it something that you're thinking about and PS it's okay if it isn't, but I'm just checking.

Brecht (01:02:11):
And it's definitely not in the, in the near future, of course, if we could enable privacy and, but no, no drawbacks or of course we would do it, but it's not really in our roadmap, for now, because it's about always also increased costs probably. And yeah, it would make things quite a bit more complicated because privacy isn't, isn't that easy to do. So we just, yeah, we just focus on their scalability for now. Cool.

Anna (01:02:39):
What happens to Loopring with the advent of like Eth2? Is there any sort of plan or thought of how to continue to be this sort of L2 solution as they roll out new parts to the kind of original underlining main chain, maybe, if they do.

Brecht (01:02:58):
So in any case, even with updates coming one to two years from now, it actually improves all zkRollups or whatever roll-ups, it will improve any, probably any, any scaling solution, because the only thing that will be available will be the data shards. And that's the main limitation of zkRollups and optimistic roll-ups, it's, it's really data part, that's the main scalability bottleneck. And so with ETH2 and with the 64 data charts, the amount of data that we will be able to put on chain will increase dramatically. Uh, so it will basically like, like Vitalik calls it, the ultra scalable zkRollups. We will be able to use all that data through our roll up, which, which increases our scalability from like a couple of 1000s TPS to a 100k TPS. So zkRollups will only get better, uh, in any case, uh, even if, uh, even if there's like, there's like a whole post from posts from Vitalik about this, even if they enable Ethereum 2 execution environments with those execution environments, scalability will only be a couple of thousands of TPS. So zkRollups in any case are like the way to go. Uh, so that's kind of like unsure if it will be able and they will still been able on Ethereum 2 those execution environments, or it will just be the data availability shards. And that will just be a couple of roll-ups that we'll use those data shards to actually do transactions on top of it.

Anna (01:04:32):
Cool. So, well, it sounds like there's some very exciting things on the horizon and, um, I guess, good luck with the project.

Matt (01:04:39):
Thank you so much, Anna, for having us.

Anna (01:04:41):
Yeah. Thank you for being on the show and for sharing with me a little bit more about Loopring and having this conversation about kind of a fully live L2, zkRollup, using SNARKs and actually a project that's been around longer than I thought. I didn't realize that it had been a year. You're like you're the first zkRollup to be live for a year. That's pretty cool.

Matt (01:05:02):
You should know Anna, maybe this is a nice way to end it. It has been my goal to get on Zero-Knowledge Podcast. And I thought as the first zkRollup we earned that right in December, 2019, but December, 2020 is good enough. So, so thank you.

Anna (01:05:19):
Thanks for coming on. Sorry, I didn't have you on earlier.

Matt (01:05:23):
Our pleasure. Thank you.

Anna (01:05:25):
Cool. And to our listeners. Thanks for listening.