Episode 120 of the Public Key podcast is here !! The Ethereum blockchain and the entire crypto ecosystem has long been plagued with scalability issues and the user experience being too clunky for the average user. In this episode we speak with Dima Romanov (Co-founder and CEO of Layer N, which is their highly anticipated Ethereum’s StateNet as he walks us through his team’s journey in tackling blockchain scalability, empowering lower transaction fees and leveraging a spectrum of custom Virtual Machines for diverse applications.
You can listen or subscribe now on Spotify, Apple, or Audible. Keep reading for a full preview of episode 120.
Public Key Episode 120: The Evolution of Performance and Scalability in Blockchain
“The best, the winner of this [web3] space, or the biggest player of this space, will be the one who will provide the best experience for developers and users.” – Dima
The Ethereum blockchain and the entire crypto ecosystem has long been plagued with scalability issues and the user experience being too clunky for the average user.
In this episode, Ian Andrews (CMO, Chainalysis) speaks with Dima Romanov (Co-founder and CEO of Layer N), which is their highly anticipated Ethereum’s StateNet.
Dima shares insights on tackling blockchain scalability, empowering lower transaction fees, and leveraging a spectrum of custom Virtual Machines for diverse applications.
He explains why thinking more like a web2 company vs. a web3 company has attracted investors and given their team a competitive edge for developers seeking performance and innovation as they prepare for their DeFi focus upcoming mainnet launch.
Quote of the episode
“People cannot sustainably pay $50 per transaction. People cannot use network because it’s 15 [Transactions Per Second] TPS” – Dima Romanov (Co-founder and CEO of Layer N)
Minute-by-minute episode breakdown
2 | The existing challenges with the Solana and Ethereum blockchains
5 | How the Layer N team was able to secure investment from Peter Thiel’s Founders Fund
7 | Layer N’s innovative blockchain scaling solutions for enhanced performance and usability
13 | The current state of the Ethereum multi-stage roadmap and how that impacts Layer N
17 | Why is Layer N described as “An Ethereum Statenet” and what does that mean?
20 | What are XVMs and GVMs and how do they differ from the traditional EVM used on Ethereum
27 | Migrating smart contracts from Ethereum EVMs to Layer N’s XVMs
30 | The process of developers building on Layer N in Beta and being ready for mainnet launch
34 | How do you attract developers and build a community of users in web3
Related resources
Check out more resources provided by Chainalysis that perfectly complement this episode of the Public Key.
- Website: Layer N: Enable unrestricted on Ethereum
- Blog: Layer N Launches Liquidity Program With $20M Commitment From Amber Group
- Blog: Testnet Launch—Phase I
- Blog: Zero-knowledge Fraud Proofs
- Report: The Chainalysis Money Laundering and Cryptocurrency Report
- YouTube: Chainalysis YouTube page
- Twitter: Chainalysis Twitter: Building trust in blockchain
- Tik Tok: Building trust in #blockchains among people, businesses, and governments.
- Telegram: Chainalysis on Telegram
Speakers on today’s episode
- Ian Andrews * Host * (Chief Marketing Officer, Chainalysis)
- Dima Romanov (Co-founder and CEO of Layer N)
This website may contain links to third-party sites that are not under the control of Chainalysis, Inc. or its affiliates (collectively “Chainalysis”). Access to such information does not imply association with, endorsement of, approval of, or recommendation by Chainalysis of the site or its operators, and Chainalysis is not responsible for the products, services, or other content hosted therein.
Our podcasts are for informational purposes only, and are not intended to provide legal, tax, financial, or investment advice. Listeners should consult their own advisors before making these types of decisions. Chainalysis has no responsibility or liability for any decision made or any other acts or omissions in connection with your use of this material.
Chainalysis does not guarantee or warrant the accuracy, completeness, timeliness, suitability or validity of the information in any particular podcast and will not be responsible for any claim attributable to errors, omissions, or other inaccuracies of any part of such material.
Unless stated otherwise, reference to any specific product or entity does not constitute an endorsement or recommendation by Chainalysis. The views expressed by guests are their own and their appearance on the program does not imply an endorsement of them or any entity they represent. Views and opinions expressed by Chainalysis employees are those of the employees and do not necessarily reflect the views of the company.
Transcript
Ian:
Hey, everyone. Welcome to another episode of Public Key. This is your host, Ian Andrews. Today, I’m joined by Dima Romanov, who is co-founder and CEO at Layer N. Dima, welcome to the show.
Dima:
Yeah, pleasure to be here. Thank you for introduction, Ian.
Ian:
Dima, we’re going to get into a wide range of topics today. You’re pretty active on Twitter, so anybody out there that is still on that platform, I guess we have to call it X now, you’re @Dima_Null. Not afraid to air your opinions, but I think most of what we want to talk about today is actually your company, Layer N, because I think you’re creating some really interesting technology, but maybe before we get to that topic, share a little bit about your background. How do you find yourself as CEO of a layer 2 blockchain company?
Dima:
Yeah, totally. I think my crypto journey starts a couple of years ago in ’21, where I and literally friends who I knew since high school, so we go way back years, built a ton of things together, decided to venture into crypto, and was like our background scripted out an industry which moves so quickly and so rapidly that it’s inexcusable to not try to build something, right? The problem at large seems so big, and the opportunity was so big to essentially create a strong impact in the world of reinventing financial systems, et cetera, et cetera, and I think we also saw the appeal of Solana at the time, right? We heard a lot of the claims like Solana going to build the future of Nasdaq, it’s going to be the future of financial systems, and it also, in hindsight, made a lot of sense, and then, as well as we were like, “Hey, we want to build products that are for everyone.”
So when we tried Ethereum, it’s like, “Okay, we got to wait 15 minutes for our transactions to finalize, got to pay $200 to buy a meme coin,” or whatnot, whatever was happening in early ’21. So that part didn’t make sense, so we tried out Solana. We decided to build a company there first. We decided to start with an exchange as well. We were like, “Hey, this Nasdaq vision makes a lot of sense to us. This opportunity is so big.” In hindsight, it feels like we were a bit naive, in a way, when we started off, and then we realized a lot of problems with existing blockchains as we started to try to scale more and more. Specifically, after we launched, which was ’22, we saw that, hey, Solana’s premise around Nasdaq is great, but, in practice, Nasdaq does 200,000 transactions a second, and that’s two magnitudes more than all of the blockchains did at the time combined.
And then you’re trying to figure out different solutions, like how we can work around this problem, what can we do on engineering side? And then you start to struggle with Solana congestions, and you struggle with latency, and, in the end, by the time, it was May ’22, we realized, “Hold on a second, this is not working. No matter what we are doing here, there’s just this wall that we cannot overcome because of an underlying infrastructure layer,” and our first thought was, “Let’s talk to other infrastructural areas. Maybe there are other people who are thinking about it who are solving this problem.” So you go around talking to L2s, L1s, before some of them even go live, and realize more and more is that it feels like most of the blockchain solutions are actually trying to build the solution in a search of problem, instead of being like, “Hey, here’s a stack. It’s going to be used tomorrow for this specific problem. We know this is the issues that all of the users are struggling with, so we’re going to solve it.”
And, because of that, we decided, “Hey, let’s reinvent a bit how infrastructure works,” and that’s how we came to an idea of Layer N, and a theorem, the roll-up, which can actually scale, which can actually solve all the problems that we face as developers that we heard from other people facing, and actually open up the space for innovation, open up the space for new opportunities to build in crypto, and we essentially finalized our vision, finalized our initial drafts of architecture around March last year, raised our first round back in the summer of ’23, and since then, been scaling the team. I think we’re almost 20 people now, and I think Layer N is probably the most exciting thing in the blockchain today from our point of view, at least.
Ian:
Yeah, it’s been, I think, a wild ride for you from maybe the lows of ’22 to the highs last year of raising from Founders Fund, right? Peter Thiel’s venture capital firm. Talk to me a little bit about how you got Founders Fund interested in Layer N. I’m curious what compelled them to invest. They had been in crypto in the last cycle, and then had seemingly left the space pretty much entirely. So you’re a bit of an outlier here. I’m really curious how you approach fundraising in general and then specifically with them.
Dima:
Yeah. I mean, we started a raise in June ’23, and our anticipation, it’s going to be tough. We probably not going to manage to raise much money, given the environment that we are in. We know that everyone’s scaled down, we know everyone took a step back, and we were actually surprised. I think, in the end our thinking around product, around how we approach things differentiated a lot from most crypto teams, right? We had these clear problems in mind that we wanted to solve. We had a clear product in mind which we thought would address it, and I think it resonated with a lot of people, and I think, in the case of Founders Fund, it might have also strike the corporate. It’s like we are thinking more like some of the Web2 teams, and not Web3 teams, where we avoid a lot of talk around alignment, around higher level philosophical ideas, and try to be very focused on the engineering side, very focused on how we think what we are building will make blockchain space more usable, more user-friendly, and actually can enable a new generation of products.
And I think that allowed us to get a ton of useful investors, a ton of helpful folks from all over the place. We’ve got people who have [inaudible 00:06:20] background, who are very crypto native, or market makers, exchanges, and Founders Fund as well. So we got a really strong backing, making sure that we have the support in every corner of crypto, essentially, but, overall, our hunch was that, yeah, all of this came to be because of how our mindset was so oriented on problem solving, and our experience as well allowed us to see how exactly we can solve these problems long-term, and how we can shape our network in such a way that it can scale to new use cases, and bring in more users on board.
Ian:
Yeah, let’s talk about some of the problems you identified. You’ve touched on scale a little bit, and just kind of one measure of scale, obviously, is transaction throughput, but talk about some of the other problems that you identified in that journey over the last two and a half years that led you to Layer N.
Dima:
Yeah, absolutely. Essentially, I think crypto, or any industry as a whole, over short-term, midterm, can deviate from the correct courts. We can have LUNA, sometimes we can have FTXs of the things pulling the industry in different directions, especially when it’s so financialized, that you realize that there’s people walking in very different directions very quickly, because then incentives that kind of get screwed up, and what we observed in crypto is that people more and more embrace more of a horizontal scaling, starting to realize that we cannot build everything on a single chain. We can even make it super performant, but it’s not going to be enough, right? We see even Solana is struggling with the demand for just trading meme points, right? It’s not enough to handle that.
Now, think about what is the goal is to put Binance there, and Binance is handling 700,000 transactions a second, has millions of users. How is it even possible? Sure, we can continue scaling, but, at some, point we reach an upper limit when we try to put everything on a single application, Google is not running on single server, even like financial applications like rarely do so. So, obviously, we see this horizontal scaling. We also see people starting to embrace more and more roll-ups, like alternative DA layers, realizing we need higher throughput. I think that’s one like what it does, it also justifies it. Yeah, people cannot sustainably pay $50 per transactions. People cannot use network because it’s 15 TPS.
So, overall, what we saw is just requirement for horizontal scaling, requirement for low transaction costs, and we’re requiring for high transaction costs, and another factor is that, as applications try to improve their products, they resort to custom input. They are no longer using the same EVM chain to build everything. They start to build custom stats, and when we think about the most successful applications over the past few years, all of them took some stack and tried to modify it, make it better. Take a look at HyperLiquid today, dYdX, EVO, Farcaster, and a bunch of other examples who all opted in for the chain, and a lot of them not even opted in for the chain, because some being [inaudible 00:09:34] and whatnot, but because that’s how they can provide the best user experience, right? That’s how they can build a product which can satisfy that.
But the challenge was there is that whenever you build a custom chain, you lose all the composability angle, and you can no longer composers everyone, which was the main factor of success for Ethereum, and Solana, and all the other chains that you have one shared environment. So seeing all of these ideas and progress, we felt like, hey, how can we make blockchains work in such a way that you still have a shared liquidity layer, you have composability across potentially thousands of applications, but you still can scale them horizontally and in a custom way, such that each application can be run on a separate server, so that it doesn’t share compute and benefits with everyone else, and how we can increase throughput. So all of this culminated vision for Layer N and how we see Layer N is a network of roll-ups, where each individual roll-up can build their own infrastructures, optimize for their own performance, capture their resources of an entire server node, instead of sharing it with thousands of other applications, and, at the same time, can pass messages to each other seamlessly.
Ian:
The concept is really compelling, right? Low fees, high transaction throughput, flexibility of implementation that becomes app or domain-specific, so that we don’t have a collision of resources between competing applications, and also a universal liquidity or access layer, because I imagine, in the future, not all these applications are financial in nature, but this avoidance of needing complex bridge layers or third party tools to kind of move your data and information, which may be financial, or may not, between them, that all makes a lot of sense to me. It seems like there’s a lot of people going after this same problem. The problem set is fairly well known. The one that came to mind as you were talking was Cosmos chain, where I think they’re very into this notion of app-specific chains. Compare and contrast, if you can, at a high level first, before we really dive into the depths of what Layer N has built, how should people think about you versus the other layer twos that are out there, and especially something like Cosmos, who’s going after this app-specific chain concept?
Dima:
Yeah. I mean, I would say that Cosmos and aggregation layer probably is the closest competitors to us and the closest comparisons, right? And we spend a lot of time figuring out the best design, and the best approach to that, and how can we create the best environment for developers? Because, at the end of the day, our thought process is that the best, the winner of this space, or the biggest player of this space, will be the one who will provide the best experience for developers and users, right? Who will gain the most adoption, whose stack will succeed in that the most, and, when we look at Cosmos, we see a lot of friction points, right? For developers, when you use IBC, you deal with delays. It’s not instant communication, it’s not one second. So this friction limits this communication aspect.
And another one is performance, right? It’s not enough to just connect everything; each individual chain needs to have high performance capabilities, and Cosmos is severely limiting that, right? If you need to run nodes for your chain, your latency goes down, and it becomes a lot harder for you get adoption, because you need to deal with that, and sometimes, it also limits the security of your chain, because you need to put up your own validator set, you need to figure out the economic incentive there, and, in the end, it’s inferior to your umbrella structure if you do have fraud-proofs, if you do have all the required components of an Ethereum side to guarantee that people can exit safely. So that’s a comparison to Cosmos. When it comes to aggregation layer, we specifically opted in for zero-knowledge fraud-proofs, instead of going 100% zero-knowledge is because we care about a user experience, like I mentioned earlier, is that, and zero-knowledge has its limits. It’s progressing very quickly, right?
And teams like Row Zero, Succinct, are rapidly improving the space to make it faster, and Polygon as well, but it’s still not enough to run enterprise-scale applications who serve millions of people, or hundreds of thousands of users, and, for that matter, we decided to, let’s focus first on performance, let’s focus personal new use cases, because before making that production ready, and ready for proving real time, right? We don’t want to be spending tens of millions of dollars a year just on proofing costs. It’s got to make our livelihood pretty difficult, or we’re going to have to upset all of these fees to users, which is not ideal either. So, because of that, we have an edge in performance over Polygon’s approach and aggregation layer side, as well as we believe our messaging design makes it a lot simpler for people to build applications, and this is more nitty-gritty, but I think the question is how quickly can people build cross-chain applications within our system, versus Cosmos, versus aggregation layer? And we target that specific use case for a lot of this, right? Because our goal is to create this fly-below ecosystem, where each individual chain not just brings more users on board, but creates more of a flow of assets, activity, data, between all those chains to build a better ecosystem.
Ian:
Yeah, super helpful explanation. I guess the other thing that’s on my mind is Ethereum itself is not a static ecosystem. So there’s a pretty ambitious roadmap that’s been laid out for where Ethereum goes, and I think it’s also aiming at solving some similar problems to what you’re going after. What’s your perspective on the state of Ethereum at this point? Has it been successful, and if they ultimately kind of pull off the multi-year roadmap that they’re building toward, does that remove some of the need and demand for what Layer N’s creating?
Dima:
I think what’s nice about Ethereum ecosystem is that, at this point, it feels like it’s no longer one team marching forward. Here’s one way of doing it, right? EigenLayer was never part of Ethereum roadmap, all of the data availability in the shape or form that it is today on [inaudible 00:16:25] side has never been a part of Ethereum roadmap, and, for sure, we can take a look at Ethereum roadmap, which, I think, given their focus, might take a long time to implement execute, and a huge question mark is what it will look like in the end [inaudible 00:16:44] also changes his opinions over time on a lot of things, his system shapes. So our general view is that we no longer see it as there’s one team building Ethereum. It’s more of people trying different things, and what we care the most is what we can do today to bring users in, what we can do today to build new applications, and, obviously, pay attention to all of the developments.
And I think building on Ethereum has been a decision more so on the fact that Ethereum researchers and team approach all of their developments with a focus on stability, making sure that every update is stable, that there’s no crazy updates that breaks the system, break roll-ups with mod, and so that allows people building on top of them to be very confident that everything’s going to be all right in a year or so, and [inaudible 00:17:36] like ours, hey, you can focus and experiment our layer, knowing that the underlying infrastructure will continue to exist, and we don’t particularly see that in a year, or two, or five Ethereum will approach the same performance as us, given how we’re detecting our system, but what matters to us is that, hey, there’s a lot of lessons to learn from there, as well as we can be confident that they will continue to push out any updates with a sense of security in mind that allows us to experiment a lot more ourselves.
Ian:
Yeah, it’s great. Let’s dive into the technology a little bit. When I go to your website, the headline is, “Layer N is an Ethereum StateNet,” and I’m going to just take a wild guess, because my personal reaction was, “Huh, I’m not sure what that means,” that most of our audience maybe is also wondering, “Well, what’s a StateNet, and why do I need it?” So maybe you can start there, and lead us into why is that the description, what’s underlying that and what does this really start to solve for users of the blockchain?
Dima:
Yeah, I mean, obviously, with StateNet, it’s just a name that you could try to come up to describe architecture, to use some kind of label to what we’re doing, right? In the same way how Layer N is a name of the network, whatnot, but, in reality, I think you want to shift the perception that prologues should be just one application, one server node, and move towards the concept that, hey, it should be a network of things. It should not be this. We should not be building towards like, “Hey, there’s going to be L2. This L2 will have L3s, and these L3s will have L4s.” This feels like a very bumpy road ahead for anyone who’s trying to use this entire system, and how we see it is that Layer N is not just like a roll-up, it’s a network of rolls, it’s a net state spread out across a network of things.
And the nice part about it is that, hey, you join Layer N, you use one chain, here’s a dozen other applications running under separate chains, right? And we are also not targeting, hey, we want to have a dozen EDMs, right? Ideally, we only have one maximum, two EDMs in total, and the goal is to, essentially, for people to come in, and build new apps, new completely from a different stack, et cetera, et cetera. So you create this network of highly scalable applications which unlock new use cases. So, as a user, my sales pitch is like, “Hey, come join this ecosystem, because you will not see the same problems you see on other chains. You will see newer products, which can leverage infrastructure a lot better than anyone else. You will see new things, a lot more performance, and you will not have to deal with all these withdrawal periods, like on every other single chain, and that’s where the progress will be for the next few years.
Ian:
That’s cool. So, in the architecture, you talk about a couple components that were new to me, and one is this idea of something called an XVM. Can you explain what that does, and how I might use it if I were a developer building on top of Layer N?
Dima:
Yeah. Yeah, absolutely. I think our question is how we can make our framework for people to build as versatile as possible, right? XVM is essentially a framework to build your own VM, and we want to make it as simple as building a website, or launching a smart contract, but, as a chain, the advantage there, though, is that if you’re using XVM, you have a lot more resources, you have a lot more flexibility, because I remember building on Solana, you have to think about compute units, on Ethereum, you have to think about gas optimizations, you have to think about fee market, and all of these concepts which are very distracting if your goal is to build the best product, right? And so that’s the idea of XVM, how we can lift these restrictions, and what it does, essentially, it’s an awesome environment. So, ideally, by the end of this year, anyone can come in and build their smart contracts in C++, Rust, Solidity, as well as Python, even, and multiple other languages which compile to [inaudible 00:21:49]
So the end goal there is that, hey, we want to enable every language that we know that you can leverage to build a smart contract for your chain, and leverage as many resources as you need for it to scale, for it to work permissionlessly, and that, essentially, is the best place for people to take whatever smart contract they have, whatever ideas they have, to the next level, right? And that’s the end goal. Move beyond OP stack, and make it simpler, make it easier, make it more direct, so people don’t need to jump through the hoops, and spend hours and hours on things that don’t actually make their product better.
Ian:
Yeah. One of the things that I’ve always thought was interesting about the EVM architecture, the Ethereum Virtual Machine, is that it enables us to run tens of thousands of nodes globally in a fairly protected and secure environment, even though none of the hardware is, in and of itself, particularly trustworthy, nor the operators, and it does that by constraining pretty tightly the things that can run inside of that EVM, relative to a general purpose virtual machine, where I have a full operating system and complete programmability. Now, I can still do lots of things inside the EVM, but it doesn’t really give me a useful attack service to disrupt the whole blockchain network, for example, and I get the sense reading about your XVMs that they’re more flexible, and you just rattled off one way is you’ve got more languages that you can support. Are they also general purpose computing environments? Can I take any code and run it inside of an XVM, or is there a limitation on that capability?
Dima:
Yeah. Obviously, it’s not going to be everything. You cannot run a supercomputer there. There are some limitations. I would just say that they’re a lot more similar to running a regular AWS server limitations type things. There are some things, like restricting memory, but, overall, it’s a lot simpler than building a smart contract, which should enable a lot more things, and I think, so far, what we’ve been doing is taking, A, we are running EVM, which was built specifically for a distributed system usage to make sure that every node can leverage it. So, now, let’s run it on a centralized server, and my immediate question is we are running roll-up on a centralized server for advantages of that, so why are we reusing EVM?
Why are we not thinking bigger? Why are we not trying to do more things? And the end goal is to just make sure that whatever you’re building is easily verifiable by every other person. So you’ll be able to run on your computer verification code to essentially make sure that nodes are operating in a valid way, but, at the same time, you don’t need to worry about making sure that there is a consensus mechanism in place that every XVM has 1,000 nodes in sync. We just need to replace a state, right? And that makes the development a lot easier, and allows a lot more new possibilities, in terms of what can be built, and I think it’s been a long time coming in this space, and it’s surprising that we’ve primarily had only EVM roll-up so far.
Ian:
Yeah, and I guess that leads to my second question, which is when I deploy a smart contract that gets replicated across every node on the network, there’s not a similar replication strategy here with an XVM, right? I deploy one, or maybe if I need a few nodes for availability. Is that the right way to think about it? It’s much more like a Web2-style application runtime.
Dima:
Yeah, it’s a lot more Web2-style. Obviously, if you’re not counting on a single server, there’s a lot more happening on the backend side, in terms of replication of messages, making sure that logs persist. We just saw how recently Google Cloud just accidentally destroyed a huge amount of data for some financial institutions holding $82 billion. We don’t want to be in the same space. I guess there is one also nice aspect of building in blockchain, is that all the data ends up being distributed because of DA layers, but we are not just thinking along those lines, but also thinking about long-term viability, how we can make processes a lot better, and I think, on a roll-up side, it’s the progress being pretty slow, in our opinion, given that a lot of the problems which robots are facing are more Web2-related, and people have figured out how to solve them, right? Why do we still have a lot of these issues? And a lot of the techniques that we are leveraging on our side as well, and we have incredibly talented engineers with 20-plus years of experience each. So definitely the goal is to build an incredibly robust system.
Ian:
There’s another part of the architecture called GVMs, or generalized VM environments. Talk to me about what that ends up getting used for. Is that facilitating the kind of network operations, and maybe it plays into the data availability layer that you’ve referenced a few times, or is it doing something else?
Dima:
Yeah, so the goal of GVM, I would say GVM is more of a subset of EVM or of XVM, but GVM is we’re referring to EVM, SVM as more of GVM environment, generalized virtual machine, where we think people can, it’s not just one application running there, it’s where people can launch smart contracts. We realize we don’t want to be very dogmatic and say, “Every person in Layer N ecosystem, go build an XVM,” right?
Ian:
Yeah.
Dima:
For some use cases, you don’t need that much customer visibility, right? Sometimes, you just need a simple smart contract. So go launch it on EVM, essentially, and so we want to bring in more environments like this. For now, it’s just EVM, but maybe, down the line, it’s going to be SVM as well, Move-VM as well. We’ll see how everything evolves, but that’s essentially the purpose of GVM, a more simpler environment for potentially lot simpler applications to be building on top of Layer N.
Ian:
Got it, and so if I have a simple, say, smart contract, I might deploy that on a GVM, whereas, if I had something like a DEX, or an on-chain order book, that would probably go into an XVM? Is that roughly-
Dima:
Exactly, exactly.
Ian:
Okay, cool.
Dima:
I think another thing is that we also see it as potentially transition, right? There’s a protocol who’s building a lending roll-up, right? We launch, initially, on EVM. It can be [inaudible 00:28:43] fork or compound fork, or some custom implementation, and, at some point, we realize, “Hold on a second, all of these lending roll-ups are not that great,” right? Or lending applications are not that great when you think about it, in terms of what can we do more if you have more compute? And then they move their application to XVM, essentially unlocking a ton of new use cases, making their app better, right? Essentially, a way to scale for apps without having to launch their own Cosmos chain, or build their own roll-up from scratch, and without losing access to their users, and telling them, “Hey, can you bridge your assets? Please do,” and then you lose access to every other application in the system.
Ian:
Okay, and the final piece is the inter-VM communication protocol, or the IVC, which I suspect is maybe the secret sauce in tying all this together, because it’s really what seems to enable high throughput, but consistent data availability. Talk about what you’re doing in that layer.
Dima:
Yeah, essentially, the goal is once all of this application is deployed, so you can pass messages instantly, sub one second, essentially, delivery time, and that’s essentially, like you said, a secret software. We believe it’s not enough to just build performant apps. Performant apps encrypted to be betters than Web2 apps need to access to everything else in the ecosystem, and that ability to pass messages instantly is what makes Layer N a better platform for everyone to build, is what differentiates us, what makes us a lot more appealing for people, teams, to come in and build, and as a way we are also engineering our system is that we are enabling, potentially, even thousands of roll-ups, or thousands of applications to launch as separate XVMs while still being able to communicate with each other, and another nice part is the way it’s architected.
Even when we need to settle on chain, the system doesn’t need to pause, right? The system can keep on pushing blocks, and it can gradually update each single XVM or roll-up node to a new block. So that’s another nice aspect of Layer N, but there’s a ton of ways how is this going to be leveraged, right? If we start with DEXs, and you think like, “Hey, next stage is market making roll-ups, and it’s structured products [inaudible 00:31:04] exchanges, and it’s AI trading agents,” and a ton of other use cases, and then, even you build a gaming application, which can directly leverage DEX for payments, or conversion, whatnot, and I think that’s what excites us the most.
Ian:
Yeah, and so, right now, all of that is you’re in private beta, right? If I want to sign up, I need to track you down on Twitter and get into your DMs, right?
Dima:
Yeah, and you do have-
Ian:
But-
Dima:
Oh yeah, go on.
Ian:
Well, I was going to say, let’s play that forward a little bit, and assume that you’re going to open this up more broadly in the near future. As a developer, where do I start?
Dima:
Yeah. I mean, right now, like you mentioned, it’s more of we are working close up with a lot of teams, a ton of talented people who’s been in [inaudible 00:31:51] for 20 years, or got PhDs, or been a crypto [inaudible 00:31:56] whatnot, but we do want to open the doors to everyone to work permissionlessly, not that we don’t want to help, but we want to make it easy to work without talking to me, or without talking to anyone on our team if you don’t like us. I don’t know, but the goal is, essentially, to arrive at that point by the end of the year, you can essentially open layer on website, here’s a tutorial of how to build XVM, here’s a place where you deploy, here’s a code that you need to run, et cetera, but, for now, it’s more of a partnership basis, where we have a lot of teams working with us with the novel ideas.
And I guess, at this stage, what’s nice is that it helps us shape how exactly is the final framework look like, how exactly is that going to look like at the end stage, right? So we can adjust, and iterate, and help us, but, at this time, if you’re interested in building something, feel free to shoot me a DM, or Layer N a DM, or one of my co-founders, or people on the team. Everyone is super eager to help, and we’re also scaling a lot, and adding more people to the team, so we can actually accommodate that, and ship a ton of new products this year, which hopefully will bring us to the next evolution of crypto.
Ian:
Yeah, and that’s where I really wanted to go, is, so I’m a developer, and I’ve got some great idea, and I’m kind of frustrated by scalability, and throughput, and fee expense on my favorite L1, and so I say, “All right, I’m going to give this Layer N thing a try.” As a developer, what am I doing as step one after I’ve gotten in touch and gotten access?
Dima:
Yeah, essentially, we would hop in a call. We both can hop on a product set, even. We have a ton of folks who have a lot of experience both in [inaudible 00:33:42] and crypto to ideate, finalize it, and then be, “Hey, here’s some code base. You can build on top of it, and we can figure out more tiny details, or we can adjust it to make sure that everything is compatible,” but it’s more of we let developers build by themselves, but also help them guide, and also adjust our internal infrastructure, and so that’s, I guess, what’s nice to be building today with us, is because if you actually work with us directly, and have this opportunity to tell people, “Hey, I don’t like this infrastructure layer.” It’s not like how you can change anything on Solana or Ethereum, and be like, “I really don’t like this [inaudible 00:34:19] code. Can you change it tomorrow?” “No, good luck.” So that’s the nice part, and another [inaudible 00:34:26] because just how involved you are with schemes, because that’s what we care the most about, the applications that got launched, the new use cases that get unlocked, and how we can enable this next big idea to essentially succeed in crypto.
Ian:
Yeah, and I’m curious, at a technical level, what would I have to change if I had been building on Ethereum for the last few years, and I’m like, “You know what? I’m done with the gas situation. I’m done with the throughput challenges. Now, I want to build on Layer N,” help me understand what it takes to migrate my smart contract-based infrastructure onto an XVM.
Dima:
Yeah, I think, for now, we are exploring how to essentially easily port over smart contracts in Solidity directly to an XVM, but I think there’s two optionalities, right? You can take your smart contract, deploy it on EVM, which is going to launch end of summer, or you can figure out how you can build something new, and I’m sure, as developer, you probably not only work with Solidity, but probably some other languages which can be enabled, and we can work together on that as well, and that’s another option now, right? So, for now, it’s an experimentation stage of how you could potentially port over your existing smartphone into individual XVM, right? I think there’s a ton of interesting things that can be done. If you want to enable [inaudible 00:35:52] trading, you can actually just create an XVM with just Uniswap L2 and enable GPU acceleration for that, because it’s so easily paralyzable, right?
Ian:
Yeah. So that’s interesting. So, step one, I’m probably not going to reuse my Solidity code. It sounds like you’re ultimately going to build a compatibility layer, but, ideally, if I want to get significant advantages, and probably rewriting and Rust, or maybe as you onboard other languages via your WebAssembly compatibility layer, I’ve got some choices there. So, now, let’s say I also happen to be a Rust developer in addition to Solidity, I’m multilingual, and so I go ahead and rewrite my app into Solidity, and I’m ready to deploy. What then?
Dima:
Yeah, I think, as soon as ready to deploy, we have a few launches slated already for June, July, depending on auditing. So [inaudible 00:36:56] along very soon, and, essentially, if we are building results, we can be even launching end of summer, right? If everything works out great, that’s something that’s on the horizon, and we are also trying to move as quickly as possible. Obviously, not at expensive security, but more of trying to ship out as quickly as we can.
Ian:
Yeah. I saw you guys had an announcement, I think, recently where a liquidity provider has committed a fairly large dollar amount to the ecosystem, I imagine, to support and encourage projects to onboard as quickly as possible, right?
Dima:
Yeah. I think I mentioned when we were raising, a lot of the stuff that we were talking resonated with a lot of people. On Amber’s side, they been market making DEXs, working with teams for years now, right? They know all too well all the issues, all the problems that they have encountered before, and they’re very eager to build or work somewhere where they don’t have to struggle with these issues, right? You would much rather work with teams who are building on a better infrastructure stack, and I think that’s like we had Amber announcement, we have a couple of other announcements coming along, and getting a lot of support from not just investors who are not using protocols usually, but actually for people who are working with teams, or actually working with projects, or regular users, and that’s what I think excites us the most is that, on the product side, we see a lot of confirmation that what we are building, makes sense, what we are building is needed, and it’s going to be used, and it’s not just five users on the chain who are moving assets back and forth.
Ian:
Yeah. You’re pretty outspoken as I sit at the top of the podcast on Twitter about the state, I think, of crypto right now is we have a lot of smart people working on infrastructure, but they’re often, it seems, building with no users in sight, and I’m curious how you’re managing around that with your own project. What is the strategy to actually build toward and ultimately for a large amount of utility and real users?
Dima:
Yeah, I think our question has been always we don’t want to build something, and, like I said, it’s not going to be used. It’s just going to exist as a network, and we’ve been constantly focusing and figuring out how we can actually get traction, how we can actually get real people, and it feels like, in blockchain, we got very complacent, and oftentimes rely on cycles, and justifies issues with our product is because it’s bear market or it’s bull market, and we are trying to build beyond that, and trying to figure out how whatever we are doing is going to survive all cycles, and can move forward to its direction of more users coming along, or more adoption, and how we can solve real problems, and I do get, I guess, maybe too outspoken sometimes on Twitter on that topic, but it is what bothers us the most, because we have come through the space with huge ambitions, and with an idea of, “Hey, we want to build something that changes the world for the better.” It’s that we are not here to just see only meme coins, not that I’m against them, but we want to see more. We want to see more products, more projects, and we do believe that what we are doing can drive that change, and we’re really eager to see it in production on mainnet, and getting real users trying it out.
Ian:
Yeah, don’t ever slow down on Twitter. The outspoken is why I’m there. So I’m curious if you can share any details; the projects you mentioned that are going to launch later this summer, even if you can’t name them specifically, maybe give us a flavor for the types of things that you expect to work really well in Layer N.
Dima:
Yeah, I think we made a strategic decision to first focus on DeFi, because we thought every ecosystem initially starts with some financial activity, right? Even when you think about SocialFis, there’s “Fi” in the word itself, right? DeFi, same thing, and so, for that matter, we thought a lot about initial products, and how they can leverage Layer N, right? We are first also starting off with DEXs, where we can actually boost our initial volume, initial activity, get users on board, get initial traction, so people can actually actively build on top of us, and use the products aggressively, and, from there on, our thinking process would bring more teams to the board. It’s not like, “Hey, can you join us, and build on us?” And we will move on to the next target, but more like, “Hey, you’re building this cool product, or you have this cool idea, and here’s how it can work within the ecosystem,” right?
And I think I mentioned a couple of interesting ideas, which included structured products, that included, besides structured products, market making, raw logs, AI training agents, and all of these aspects, who can leverage existing DEXs to build their own products, essentially, creating a really strong flywheel effect of things, where like this product launched, and this product launched, and then it brings volume to each other, it brings more activity, users get to use more applications, et cetera, et cetera, and we continue to think through other ideas, and have a lot of other folks as well joining to bring some of these that we even haven’t thought of before, and that’s what’s exciting, and I think that feels like a better way of building ecosystem, instead of just going through a checklist, “I need the lending, I need the DEX, I need the 10 swaps protocols,” whatnot, and trying to be more strategic around that, and how can it actually build into a really integrated space, where people will come build on top of us, actually realize that they can leverage a lot of other protocols to build their ideal vision, right?
Ian:
Exciting. Well, my customary closing question is to get people to look out to the future, because I always get excited about what’s coming next. Obviously, you’ve got the mainnet launch coming up, but, beyond that, what should we be on the lookout for from Layer N this year?
Dima:
Yeah, I think mainnet launch coming up. I would recommend to just join Discord, join our community. I think that’s what we started to target more and more, building not just the tech, because that’s obviously exciting, but I think crypto only makes sense when there is a social consensus around it, which is something ineffable, hard to describe, but that’s what makes it all work, that’s what brings the security, and users as well, and if you want to be a part of it, just come along and join also, communities, of the projects that they’re building on top of us, who have been announced so far, and we are just really excited to what’s to come, and really want to get more people on board as well.
Ian:
Fantastic. Dima, thanks so much. It’s been really exciting to learn more about Layer N today.
Dima:
No, it’s been a pleasure, Ian. Thank you for having me.