When we first started Polymer, the interoperability landscape was very different. I think the thesis then was there's going to be potentially millions of L ones and millions of these app chains. What we started to see was the landscape began to shift and we started to see this rise in the number of layer twos and not just layer twos. Originally, these layer twos were just individual layer twos, but they've changed into layer 2 frameworks.
We retained what we called virtual IBC just enabled us to permissionlessly expand the IPC network, but we shifted the underlying architecture from using common BFT as a layer 1 using the OP stack for settlement and chain derivation from Etherium. What this allows is that for Etherium roll ups that implement the EIP 4788 standard, where there is some layer one information on that pull up that we can utilize, we can allow those roll ups to communicate
essentially as close to block time as possible. Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization and the blockchain revolution. I'm Sebastne Quito and today I'm speaking with Bo Dew, who's Co founder and CTO at Polymer. They're building an interoperability hub for Ethereum. Before I start with Bo, here's some information about our sponsors this week.
Cars 1 is one of the biggest node operators globally and help you stake your tokens on 45 plus networks like Ethereum, Cosmos, Celestia, and DYDX. More than 100,000 delegators stake with Chorus One, including institutions like Bid Go and Ledger. Staking with Chorus 1 not only gets you the highest years but also the most robust security practices in infrastructure that are usually exclusive for
institutions. You can stake directly to Chorus 1's public note from your wallet, set up a white table note, or use the recently launched product Opus to stake up to 8000 ETH in a single transaction. You can even offer high yield staking to your own customers using their API. Your assets always remain in your custody, so you can have complete Peace of Mind. Start staking today at Chorus .1.
This episode is proudly brought to you by Gnosis, a collective dedicated to advancing a decentralized future. Nosys leads innovation with Circles, Nosys Pay and Metri, reshaping open banking and money. With Hashi and Nosys VPN, they're building a more resilient, privacy focused Internet. If you're looking for an L1 to launch your project, Nosys Chain offers the same development environment as Aetherium with
lower transaction fees. It's supported by over 200,000 validators, making Nosys Chain a reliable and credibly neutral foundation for your applications. Gnosis Dow drives Gnosis governance, where every voice matters. Join the Gnosis community in the Gnosis Dow forum today. Deploy on the EVM compatible Gnosis Chain or secure the network with just one GNO and affordable hardware. Start your decentralization journey today at gnosis dot IO. Hey, Bo, thanks for coming on
this week. Yeah, thanks for having me. Yeah, so we were talking about before the show, so actually you've been on my podcast, the Interop, a couple of times, but this is your first time on Epicenter, so, you know, we'll have to set aside all of those interesting conversations and, you know, maybe start from a high level here. But yeah, how's your summer going? It's pretty good gearing up for for main net soon.
We're working hard, going to a lot of these different conferences and and trying to talk about what we're doing. Yeah, it's exciting and you know, it's it's been it's been a long time coming. You guys have been working on Polymer for some time. In fact, I first heard about you
guys two years ago. Just disclaimer here, I'm an Angel investor in Polymer. But with that out of the way, I think we can have a conversation about the technology, about the Polymer hub and the SDK that you guys are building. And and also, you know, your fervent, I guess that defense and and love of IBC, you know, as like the standard for interruptability in crypto, which I tend to agree with.
And I think, you know, you sort of like speech, speaking to the choir, preaching to the choir here on Epicenter, at least, you know, as a lot of folks here are like familiar with Cosmos and familiar with IBC. So yeah, maybe a little bit of background on Palmer and like how you guys got here. Yeah, absolutely. I can do it quick. I guess self background of myself for the folks that are that are new, that haven't heard me talk before. So my name is Bo, I'm a technical Co founder at Polymer.
My personal background has mostly been in Web 2, worked at a bunch of different start-ups, worked at Uber. I worked in a small startup called Chronosphere which became quite bit quite large. Switched over to working in D5 for a period of time and ultimately ended up switching to Interop. I would say that when we first started Polymer, the interoperability landscape was
very different. I think the thesis then was there's going to be potentially millions of L ones and millions of these app chains, maybe a few large L ones and I guess the law until these like L1 app chains and that world has changed a bit. So our initial product was focused on on that we were building an L1. We wanted to connect all these different, different L ones, starting with different ecosystems like Ethereum.
We were investigating ZK, we're investigating all of these different technologies because we wanted to make it cost efficient to connect securely from like a cosmos chain to Etherium. But as we're working on this problem and as and as we had developed some of these like proof of concept technologies to enable this, what we started to see was the landscape began to shift.
So instead of this like L1 thesis playing out, it kind of you kind of saw this like rise in and fall of interest in the cosmos. I think it kind of rose with Terra. And then after Terra and FDX and like the, the, the bear market kicked in, interest started to die down a little bit and you started to see this rise in the number of layer twos and not just layer twos. Originally these layer twos were just individual layer twos, but they'd change into layer 2 frameworks.
And this concept of roll up as a server became really popular. And I've seen a number of folks tweet that and mention that in different talks. And it kind of makes sense. When you have a layer one blockchain, you're paying for consensus, you're paying for these things, which comes at a cost in order to have decentralized trust. But with these like layer 2 systems, you can essentially run it in a fairly centralized fashion to get some of those blockchain properties from the layer one.
And that that seems like a more pragmatic scaling model in terms of cost and efficiency. So our thesis changed from, OK, there's going to be from millions of layer ones to we want to connect millions of layer twos. And because the thesis changed, we also had to change our focus. We realized that building this layer one solution wouldn't be effective in connecting to the different layer 2's, the technical nuance of which, you know, we can get into a little
bit later in this call. But I would say that it revolves around the latency, cost, safety, and all these other properties. For us to make the best solution for layer twos, we realized we had to pivot to being a layer 2 ourselves. So we we architected the polymer solution. We did not change the application layer protocol that we had built. We retained what we called virtual IBC.
This enabled us to permissionlessly expand the IBC network, but we shifted the underlying architecture from using common BFT as a layer one to using the OP stack for settlement and chain derivation from Ethereum. And this with this new solution, that's basically what we've been working on for over a year now and what we'll be launching main net with very soon. Yeah, very cool.
Yeah. I think like this, this idea that, you know, we would have thousands and then perhaps like millions of of app chains hasn't, hasn't really changed. It's just like what has changed is the level of sovereignty over
settlement consensus. You know, I think logically app chains have, you know, now moved into this L2 territory, which allows them to run with, you know, sufficient for most, I think sufficious sufficient guarantees on censorship resistance and throughput while maintaining your reasonable cost. Because as we've seen throughout this, this this cycle, you're maintaining a chain in the traditional kind of Cosmos app chain sense running your valder
set. It's just like a lot of inefficiencies there, starting by the fact that like most Cosmos app chains have the same validators that are at least like there's a huge overlap. But but this, this new model kind of makes makes sense. You know, like you, you guys, you guys publish this article on, on the scaling limits of L ones and L twos, which I thought was really interesting.
And it seems like with L ones, there's kind of a hard scaling limit that, that the space is, you know, established and, and is aware of. But then with L twos, it's, it's a little bit more blurry, or at least the scaling limits are not fully tested. Can you talk a little bit about what those scale limits are and what we know about them?
Yeah, before we talk about it, I, I, I wanted to mention one thing because you're on the topic of this like Aptain thesis, moving from a bunch of a layer ones to to layer twos. It's like Ethereum is speed running the Cosmos playbook, both from the tech perspective and also from the problems perspective. I think the arguments being had in Ethereum or arguments that happen in the Cosmos or have been happening in the cosmos for many years now, which is kind of
funny. So more, more on the scaling limits. I would say that there's if so, maybe the way to frame this is from, if you would have imagine a chart going from low scale, so like very low TPS, very high latency to really high scale, which is really high TPS, really low latency. You can imagine that there is a number of bottlenecks that you're going to hit as as you go
from 1 technology to the next. And in the article, I create this diagram where I try to help user readers visualize that you end up hitting the first bottleneck, which is consensus. And every consensus algorithm requires a certain number of rounds of communication. It requires data, transaction data to be gossiped over, some peer-to-peer network. These are just kind of algorithmic things and, and data throughput things that that need to happen.
And above the consensus layer or the consensus algorithm bottleneck layer, you have this network bandwidth, a bottleneck, meaning that if you want to account for home stakers, home Internet connections are only so fast. Like for example, you can only, well, it's very hard to get a GB Internet connection in most parts of the world.
I think many folks in the West are fortunate to be able to have fiber optic cable into their a neighborhood and can't get some of these connection connection speeds. But even then, like the real connectivity speeds are are far less than one GB. And if you look at you know, some changes like Solada where they're requiring 10 to 25 gigabytes per second network links it, it doesn't work with
home staking. You end up having to put your software into data centers because data centers can offer anywhere between a 10 gigabytes to 100 gigabytes or more. And then not only do you put them in the same data center, you're actually in some cases push to put it in the same cloud provider because a lot of cloud providers maintain high throughput between their data centers.
But if you want to go across different cloud provider data centers, you may not have the network bandwidth that that that you need. So there's this that were bandwidth limit that kind of like presents itself as a ceiling for how fast or how scalable a layer 1 can be. And then if you step beyond that, you're in this layer 2 territory where the layer 2 doesn't necessarily need a
consensus algorithm. It doesn't necessarily or isn't necessarily network bandwidth bottlenecked because you could run like a central, I guess, single proposer, single sequencer and just run extremely high throughput through it. And there's a number of teams exploring this design space,
Mega Eats being one of them. And this now becomes very interesting because this is kind of like the Wild West of blockchain scaling, where like for the past few years people have been working on L1 scaling and have really kind of pushed the limits of what, what we can do there. Like Solana monad's doing that as well. And, and now you're seeing the layer twos that, you know, push even further. So the the ceilings there may be in a few years time 1,000,000 TPS on a layer two could be the
could be the new normal. Yeah. I mean, one, one question. I, I, I guess like from the perspective of experimentation, this is great, right, Because we're getting lots of different teams working on different ways
to scale like L ones. I think like that that space has been explored, as you said, and then now L2's, you know, it in the end, like, you know, when I, when I, when I hear of a, a team building like another framework to build roll ups, I think like, Oh yeah, I could like yet another roll up framework like and, and it, it feels like right now, at least in the cycle, we're still in the infrastructure phase or like if you want to call it that there there's not like that many
applications and end user applications being built. It's a lot of infrastructure. What's the end game here for all of these rollout frameworks? Yeah, I think it's. Everyone's going to have a different opinion and I think people over index on zero knowledge here. I say that because not because I'm a I'm not a fan of 0 knowledge. I in fact, I, I've thoroughly enjoyed learning about zero knowledge tech and also working
on zero knowledge tech as well. But from the perspective of cost and scale, I think 0 knowledge tech is in a catch all. I don't think that everything in like the future state is all going to be ZK verified. And I think that different teams will end up optimizing for different workloads. And that's kind of why the app chain thesis exists.
To give you an analogy here, or maybe something from my a story from my past when I was working at Uber, internally at Uber, you could use like generic database systems. So maybe the analogy here is like, use a generic database, use the EVM. So EVM is like generic compute. You can pretty much write whatever program that you want in it and you and then you write, run it in this runtime, which is actually emulated in a, in a, in an actual runtime on
your hardware. But from a efficiency perspective, these generic databases are not cost effective or you need to add a ton of hardware to get the same amount of work done. So when I was at Uber, what ended up happening is that as Uber scaled as a business, they started shifting away from, OK, we can't actually use these generic databases. This is costing us way too much money. We need to save on
infrastructure costs. And as we were trying to save on these infrastructure costs, they started developing specialized databases. They were like, OK, we have these different workloads. Let's take each workload, make a database that's specifically optimized for that one workload. Because you get these huge benefits, right? Like you get benefits around how you encode the data. Because you can say that I only have a certain type of data that
goes into this. I'm going to create this compression algorithm custom just for this one workload. I'm going to create a search algorithm custom just for this one workload indexing algorithm custom and and now you get into a world where like you can save 9095% on your infrastructure costs by running these specialized databases for these specialized workloads that you couldn't get otherwise with this generic like EDM or generic like a regular database.
Right. So in this case you're like you, you're talking about it like using Postgres versus building something custom in house or like using some framework that allows you to do your own custom database. Yeah, yeah, exactly like Edward there was like I think, I believe they were using Cassandra for their time series data at one point, but they ended up using way too many resources. So they switched over to building their own called custom time series database which I
ended up working on called M3DB. No, that's interesting. OK. I mean, I guess like, yeah, if you haven't like worked in that environment, right? Or like built a custom database, like most, most, most developers will build their web app build, you know, using whatever, you know, like Postgres and no jazz and like off the shelf components. When you get to like a certain scale, you, you have to build your own highly scalable, highly
cost effective systems. Where or like where do you see the overlap with between that and you know crypto as things are currently going? I think the applications need to find the a balance here. So I'm still a proponent of if you have an application, you have no users and you want to like get an MVP out, write it in Solidity, deployed on the EVM, deployed in an existing blockchain, and look for PMF
first. I think like going out and building an app chain ahead of finding PMF is probably not the right approach unless there's like clear reasons for why it doesn't work. So I, I like, I really like the story protocol journey so far. Maybe not some of the social commentary going on in, in, in, in Twitter and some of the, I guess, like social tension there, But from a technical perspective, it's very interesting.
So they had this journey from writing a bunch of smart contracts and then they were working on building it over like a generic OB stack EVML 2. They tried implementing a graph traversal algorithm in that EVM. It turned out to be highly
inefficient. And they're like, we should, we need a different environment execution environment for this and we need to something that's a little more efficient for what we want to do. And they ultimately ended up arriving on the Cosmos SDK and in our building what they call like a purpose built chain for their specific use case. OK. Yeah, No, that makes sense.
So let's maybe talk a little bit about IBC here, because I think a lot of people, you know, see Polymer as like building IBC for Etherium or like implementing IBC on Etherium. If you just like sort of heard of Polymer, think like that's probably a, a, a very generic way to think about what you guys
are doing. Of course, you know, it's much broader than that, but like I do want to talk about IBCA little bit and I think there are still some misconceptions about what IBC is and confusing the transport layer and the messaging layer. This is something we talked about on the last podcast together early in Europe. So maybe you just give a high level overview of like what is
IBC and you know, how is it? How is it fundamentally different from some of the other interoperability products that exist that people are familiar with, you know like Hyperlane or AXLR, like you know, layer 0, etcetera? So actually since we've had that conversation, I'll say that there are a number of protocols that are kind of moving in, in the, in the same direction in terms of splitting out the
stack. So you, you notice how like since then layer 0 has kind of like modularized their stack. They're like, oh, we need to separate, separate verification. From execution which which, which is a valid design and that
that's the design that IBC took. So if you think of IBC or interop is in three layers, you have application transport and verification or or state that most protocols are trying to move into this area where they are splitting those layers up there are kind of allowing people to supply different verification mechanisms and so on.
So now I would say the, the major differentiator is, is not in that like 3 layer design, it's in that obviously just offers a lot of features in that transport layer. And a lot of these features are forward-looking. So from a from a practical perspective, a lot of applications may not want or need these features at the moment, but there will be a time where applications are complex enough that they'll be able to leverage a lot of these
features. And these features range from everything messaging related, meaning that I can send a packet, I can receive an acknowledgement or a time out to things like authentication, to things like versioning and upgrades. Because even when you think about one problem alone, like upgrades and and versioning of an application across many chains, it's actually kind of a
tricky problem. It's not as simple as I'm just going to like easily upgrade my application across all these chains because each chain is, is, is a different place. You can't atomically do that. So you have to handle all these edge cases. And one edge case could be, just to give you an example, is the crossing Halos problem. What if you have an upgrade initiated from three different chains all at once? How, how do you resolve that?
What if, what if you have messages that aren't flush for the old version that you know in the middle of the upgrade? How do you, how do you handle like flushing of these old transactions? And, and like the IVC designers have had a lot of conversations around this. If you could go look at the specs, there's a lot of debate on every single topic and it's good to be able to build off of that, that debate. Another interesting thing for us is obviously also makes coordination happen on chain
versus off chain. There's something that we didn't get to talk about in the last podcast, but it's something that is becoming very clear that is a differentiator of IVC from its competitors is that a lot of competitors that you, they'll use identifiers such as chain ID for communicating between
chains. And if you think about what a chain ID means, you realize that that's not uniquely enforceable or programmatically enforceable on chain, meaning that you have to have social consensus around chain IDs because anyone, any team can join a network and say, like, you know what I, my chain ID is also Etherium or like I'm also Etherium.
And from IBC perspective, you have this concept of connection IDs and channel IDs, channel IDs, uniquely identified application connection IDs uniquely identify a chain. And think, if you think about a connection IDs and, and channel IDs from the perspective of a map. So you, let's say you have this like universe of chains and every chain has a map and every chain has a unique map that they own of the rest of the network. That's what IBC gives each of
these chains. That means each chain has sovereign ownership over what they see or their view of the rest of the Galaxy. And, and this is also programmatically enforceable so that all of all coordination happens on chain versus like having had, having to have social consensus, having to have a centralized real layer set that just knows what to do. This kind of prevents bad actors from, you know, misrepresenting themselves and, and, and and so on. So it's it's a very unique
design and and unique to IVC. How much of Ibc's design do you think is inspired by the designs of like TCPIP and networking protocols? I would say that it is very much inspired by TCPIPI think. I believe they use like Crisco's and a lot of the original IBC team used TCPIP as a model for which to base their protocol off of. Like the handshaking protocol is to prevent like man in the
middle attacks. There's authentication baked in kind of similar to like ATCP connection, which is like an authenticated like port essentially. And even the port concept is I think port from this, this concept of like TCP ports. So there's, there's a lot of similarities there. The ports are a little bit different. Like port in in IBC land is kind of like a a spark contract and and a port in TCP land is a is an actual socket on your on your computer in.
Yeah, yeah, That's interesting. Yeah. You, you gave a talk at Modular Summit, you know, describing the evolution of network protocols. And I, I didn't realize that there were so many, you know, that kind of came up in the 70s and 80s and, and then died out even as late as the 2000s. And one interesting thing about that talk was your description of like how network topology manifests where you have like Wan and then you have, you know, lands and then you may have like
virtual lands. How does that overlap with the landscape of interoperability protocols today? But but also, you know, as we have more and more L2's, but all sorts of L ones, you know, how does that overlap with the landscape and the topology of applications and and L ones and in crypto? Yeah. To give viewers some background here, in the early 70s and 80s, you had a lot of different intranets being built.
And the what was happening was a lot of different companies had, maybe they had a lot of devices like Xerox is, is an example, one of them that wanted to have those and wanted to have those devices networked or connected to each other. So they developed their own protocols for how these clusters of devices would communicate. And, and let's just call these like local area networks and these protocols, local area
network protocols. We're starting to see the same thing happen in the roll up landscape. Each roll up ecosystem is essentially building their own like native interop solution and these solutions can be like made analogous to local area network protocols from thirdly Internet. I in in the talk I call these virtual local area networks.
If you think of maybe the AG layer as one virtual local area network, and I define this as the roll ups in that network or either directly or have 1° of separation in between them. So either they're connected to a central hub or they're connected directly to one another. And optimism is doing this, arbitrary is doing this. And now you start to see you have all these different virtual local area networks that are spotting up each kind of with their own separate protocols.
And this is very similar to what happened in in the 70s and 80s. But you also started to see that there was the growth of ARPANET. So ARPANET adopted TCPIP and I kind of equate ARP, the early ARPANET to the early Interchain. And I, I have these like diagrams where I show early ARPANET where you had a few colleges connected to one another and early a screenshot of map of zones where you have just a few of these Cosmos L
ones connected to each other. And now as we're entering a growth phase for the IBC network with Interchain, you start to see a lot more of these different ecosystem or different virtual local area network clusters being connect, connected to this wider area network or, or Wan. And over time, this Wan I, I use the term virtual Wan in the in the blockchain setting starts to consume these virtual local area
networks. And at some point, the custom networking protocols that are used within the clusters are deprecated in favor of TCPIP or I believe in, you know, perhaps like 10 to 20 years will be deprecated fully in favor of something like IBC or a variant of IBC. Why do you equate IBC to TCPIP? Like what?
What gives you the certainty that IBC is the protocol that, you know, in this kind of Internet story Mirrors, TCPIP and all the other ones are, you know, equated to like Apple Talk and all these other, you know, networking protocols that no longer exist? I think there's a angle of credible neutrality where TCPIP like IBC was adopted across different ecosystems and ultimately became not associated
with anyone company. Whereas a lot of these roll up ecosystem specific protocols are used within a single ecosystem. This is not to say that there may be contenders because TCPIP also had competitors as well. So besides the credible neutrality point, there's also a technical angle.
So if you look at or if you evaluate every single interop protocol today, whether that's a native interop protocol, the roll up ecosystem, or a third party interop protocol made by some of these other interop providers, you'll see that IBC is the only interop protocol that's even capable of operating in a wide area network fashion. Meaning that it's the only protocol that allows two parties or two chains to communicate directly while being physically indirectly connected.
Meaning that there could be more than 1° of separation. So maybe there's like 2 chains in this network that are separated by 10 hops. They can still efficiently communicate directly to one another via multi hop IBC channels, which is different from multi hop IBC packet forwarding. Those are kind of like two different solutions. But yeah, IB, CS, the 1st to have this property and, and, and this technology and, and behaving this way. So it's kind of, it's in the
lead now. I guess time will tell what what happens. What happens here? Right. So that's kind of mirrors routing in TCPIP where, you know, I, my computer is nowhere near your computer and there may be like four or five degrees of separation, but we're still able to communicate because, you know, there's a network of, of data centers that like will relay those packets through, you know, the Internet and like oversee cables, etcetera. Interesting.
Yeah. And and it's only protocol that allows you to. I always say that the the difference is because you can try to do multi hop packet forwarding with some of these other existing interop protocols. But the major difference is that with multi hop IBC channels, what you're actually propagating through the network is compressed state mean that it's the like compressed state of all of the chains is being gossiped across the the network and the packets themselves.
The actual data which is uncompressed is only made it at the source and the destination, so this uncompressed data does not flow in between, which makes for a far more efficient communication than with with alternative methods. OK, I didn't know that. Cool. Well, let's talk about the Polymer hub. So one of the questions people on Twitter said I should ask you
is when mainnet. And so I guess, I guess you don't have an answer for that yet, but but but what we can talk about what is going to be main net, which is the polymer hub. So what what is the polymer hub? And like what role does it serve as this interoperability hub for Ethereum? Because I think like one very important thing for people to realize here is that there isn't a single interoperability standard for Ethereum roll ups. And different roll ups have had to implement, you know, their
own probability solutions. Applications have had to implement their own input and probability solutions, which is kind of crazy when you're coming from Cosmos, right? But so yeah, let's let's talk about the hub and the what role you know it in Sysserve. Yeah, I'll say that at a high
level it does implement IBC. We will bring that feature set that we just discussed to these roll ups and using the like wide area network, local area network analogy here Polymer hub straddles these roll up ecosystems. IBC as a standard similar to TCPIP straddles all these roll up clusters and provides connectivity across cluster and with the rest of the interchain as well. So from like AAPI service perspective, you get the standardized API for accessing all these different chains.
Additionally, I'll say that the So back to the kind of earlier in this conversation we talked about the difference between layer 2 and layer one scaling limits. We're starting to see these roll ups such as mega ETH push towards 1 millisecond block times 100,000 TPS and perhaps even a million TPS. And we realized that we needed to build polymerize the L2 to be even able to scale to the point that we can support these, these roll ups.
Because if you imagine you have a sovereign layer 1A hub and spoke in our protocol and you're trying to connect 2 megahertz to one another. But just consensus alone puts puts your block time at, you know, like 100, like a few 100 milliseconds at, at the at the very, very least, usually like a few seconds. Then it's very hard to match that, that latency. It's also very hard to match that that throughput without making the solution very, very
centralized. Of course, if you put 3 nodes in one data center in the same server rack and you throw on some consensus, you can probably go very, very fast. But then you're like closer to, but then you're like very centralized and you don't really have the decentralized properties of a layer 2 because which which inherits those from the layer 1. So there's like this scale reason why we built Polymer Hub this way. And the other reason is from a cost efficiency, a standpoint
and latency standpoint. So it's it's cost efficient in that we can add different safety features in a much more cost efficient way than if you were to add those safety features in a point to point protocol. So with a lot of point to point protocols, perhaps you can handle the scale because you're connecting these chains directly, but it's very cost inefficient from checking things like data availability, ordering
and even validity. Because you imagine you partner with a, a company like we're partnered with a company called LaGrange. They're working on a solution called LaGrange state committees, which offer, I guess a quote, UN quote like client for optimistic roll ups and perhaps even other roll ups as well. The issue there is if you want to connect using the state committee solution in a point to point fashion, you would have to generate a state committee proof per chain in the network.
So this is going to be in chains for like in connected chains at some, some amount of latency. And then these proofs are not going to be free or, or cheap to, to, to generate With Polymer, we can stream all the attestations to our central hub and only generate 1 proof for in chains. This becomes much more cost effective for us from a validity standpoint and we're able to to kind of like validate this information across all these different chains.
So is this like ZK proof aggregation that you're using? So I wanted, I think when people would talk about ZK proof aggregation in the context of the AG layer, they're talking about ZK proofs of validity, meaning that this is a ZK proof of the execution of a chain, of the full execution of a chain. What I'm talking about here is a ZK attestation. So LaGrange State committee nodes are not generating AZK proof for the execution of the chain, rather they're generating
AZK proof of the attestation. So it's much more similar to a light client, like a tenement light client than it is, I guess like AZKEVM, like like validity proof, ZK validity proof. OK, got it. Can you talk a little bit about Polymer Hobbs architecture and what it's built on? Yes. So we're Cosmos SDK at the application layer and we use this framework called Monomer for us to be able to deploy this Cosmos SDK app as a roll up over
the OP stack. And the Monomer framework kind of establishes a compatibility layer between the engine API, which is expected by the OP stack, and ABCI, which is expected by the Cosmos SDK application. And the reason we wanted to build it this way, and so there's some technical nuance here, so I'll dig in a little bit, is that there is logic in the OP stack that derives the L2
chain from the layer one. And this is useful for us from an interoperability perspective, meaning that if we can associate every layer 2 block with a specific layer one block, what we can do is we can essentially communicate across different layer twos beneath Etherium finality. So today, most protocols either wait for a theorem finality or they'll go faster than a theorem finality and push this reorg risk onto the applications themselves.
Then there's a trade off here to be made and we're thinking of, so how can we break this finality barrier? And what we were able to do is we developed a reorg protect protection protocol for sub finality communication across L twos, which essentially builds a dependency graph of transactions based on some history of the layer one. And at the end of this finality period.
So once the theorem begins to finalize, we can have a condition that says if these transactions that were built on the history of Etherium, let's call that L1 prime. If L1 prime gets finalized, we will commit this entire dependency graph of transactions. If L1 Prime does not get finalized, we will we will revert this entire dependency graph so it offers additional safety guarantees around communication at lower
latencies. Therefore, bringing reorg risk, risk from the application level down into the protocol level and handling it in protocol while providing extremely low latencies where we're trying to target less than 10 seconds. OK, Maybe this is a good time to talk about the different types of finality and fast finality mechanisms that exist.
I was recently researching this for in the context of movement labs and I saw that like talent was getting into some some some debates with with Rushi about like what is a roll up and find out etcetera. So, you know, maybe just going across like the different types of finale finality mechanisms
and like. You know, if our listener is explaining OK, like what are these pre confirmations and what are the different trade-offs and like if we add faster finality to that, like what are the trade-offs there as well? Yeah. So I think there's some some confusion around like what finality means. So I'll, I'll start off by saying no protocol can guarantee fidelity on behalf of Ethereum. Ethereum has its own finality
mechanism. If you, if you attempt to guarantee fidelity when you actually get is a completely different role of construction. So if you know, hypothetically, you were to say, there's this other consensus layer that I'm going to define the, the canonical ordering of my chain or my finality on. Now that chain becomes a roll up
of that other consensus layer. So, and if you move down the direction of this analogy, you'll, you'll start to find that like, actually, this looks very much like the first version of Polygon. You have this like separate consensus layer. You then define your finality based on that consensus layer. And then you post a state commitment to to to the Etherium layer 1. And that's basically a, a side chain more, more or less.
So for roll ups that do define their finality or like final finality on Etherium, you can have something called a pre confirmation. And what this is, it's a guarantee or it's, it's a guarantee that if a a block proposer gets a specific proposal slot that they will include your transaction in that slot. But this is an optimistic guarantee, meaning that they
can't fully make this guarantee. Basically what they're saying is that if my slot does not change and I proposed within that slot, then you will have your transaction included in the
chain. However, if there is a reorg and that proposer slot now becomes maybe perhaps moved further away, now you find that that guarantee doesn't doesn't hold anymore because the proposer no longer the the proposer has essentially like lost their slot for for the full guarantee, you have to wait for full theorem finality, which is roughly 12 to 16. Minutes OK and so this this mechanism that this this reorg protection mechanism that you're
implementing I think the term you use was it it's sub plants etherium finality was that oh. No, no, it it, it, it does not. It cannot replace Etherium finality. Instead it's a, it's, it's sort of like a guarantee around eventual finality. So it's an optimistic guarantee the same way that pre, the same way that builder proposer pre confirmations are also an optimistic guarantee. So it's an optimistic guarantee on the Ethereum, on Ethereum's
finality. Yes, yes and but it but it has guardrails in place where if the the guarantee is not met then the all the transactions that were committed or like I guess pending by the protocol are all invalidated, which is a very important guarantee. OK. And then what happens to those transactions if they're invalidated? So like as the user of the roll up like how does that translate into your user experience of like having just made a transaction that gets that gets
rolled back? Yeah. So from user experience perspective, 99 point like 9% of the time their transactions going to go through. This is not so dissimilar to using a layer 2 today. So if you use unit swap on optimism today, you'll make a swap, it'll say it's confirmed you get your assets and it'll look like it all happened in like 2 seconds. And that's what it'll look like to the user most of the time. But then in like a tiny fraction of the time, your, your swap
will just like disappear. You'd go, oh, actually I never made this swap. I have my original asset and that's a nice guarantee because that you if you have all these different transactions interacting with each other across chain, you never want to get into a state where there's a double spent. You never wanted to get into a state where like what actor has made money on one chain and also like not never transferred their funds on the original chain.
So in order to be able to make this guarantee across any number of roll ups, we had to have this like atomic like protocol, like atomic or conditional like commit over protocol. So it's better to be. It's better to revert all the transactions than to end up in an inconsistent state across the different chains. And so how does how does this mechanism facilitate interoperability between
different etherium roll ups? What this allows is that for Etherium roll ups that implement the EIP 4788 standard, where there is some layer one information on that roll up that we can utilize, we can allow those roll ups to communicate essentially as close to block time as possible. Meaning that the they'll be able to, if they're producing blocks at 2 seconds, they'll be able to communicate at 2 seconds.
If they're producing blocks at 100 milliseconds, they could technically communicate 100 milliseconds with. I guess additional accounted for additional like actual network latency of this communication. Since we're still on the topic of the Polymer hub here, you know for for roll ups that want to utilize Polymer hub for interoperability. So like Arbitrum you want to send assets on to base what what is required for those roll ups in order to on board or
integrate Polymer? Yeah. So with our virtual IBCU protocol, it's completely permissionless to integrate. So either the Polymer team or a third party would be able to deploy our smart contracts through the setup work. There's some IBC like specific setup that's required, but there's no opt in by the layer 2 like the layer 2 doesn't have to opt in to using some like you know, special process they have to run.
They don't have to change their deployment infrastructure like nothing needs to change on their end. OK, so so it's it's permissionless for the roll up a. A user can't permissionlessly use Polymer interoperability without the role of having implemented. It without having polymers integration deployed, but technically we plan on making this very easy to request connectivity to a new chain.
So for users that maybe aren't sophisticated enough to like run these scripts to do these deployments, we're planning on automating all of this so that perhaps you could have like a permissionless pipeline or some like loosely permission pipeline of just requests to like new deployments. And this is true in the IBC network today, which if anyone spends up a chain it, it does require some technical expertise to be able to set up a connection, set up a channel and
so on, or set up an IBC relayer. But we plan on providing some like more user friendly front end for for that sort of thing. So we've talked about Ethereum like essentially Polymer will allow any, any roll up on it, any Ethereum based roll up to interoperate over IBC. What about the existing IBC ecosystem and sort of cosmos broadly, what does that look
like? And you know, is it, is it, is it the case that kind of Polymer sits at the middle and interoperates with IBC as that kind of middle hop are are Ethereum based roll ups going to be able to send assets directly to and from IBC the the IBC network? So can I move assets from like osmosis to like some decks on base permissionlessly? Yes, so they'll be able to use
the protocol permissionlessly. Although because of how our virtual IBC protocol works, Polymer handles IBC execution and implementation on behalf of the roll up. So for a roll up that doesn't isn't communicating through Polymer, they don't actually speak IBC so they wouldn't be able to connect directly with the IBC network.
However, we are working on our monomer framework, so if you do have a Cosmos SDK roll up that natively implements IBC, technically that that roll up could communicate directly with the IBC network. So yeah, let's let's talk about monomer a little bit. So, so monomer is an is an SDKI guess the Polymer hub uses monomer, but you can also build your own roll up using monomer. It's I guess a generic roll up
SDK that uses the OP stack. You know, who do you think what what kind of applications do you think will use monomer and what is the kind of differentiating factor, you know, as opposed to using like some of the roll up framework or you know, using the OP stack or something like that? Yeah. So the way I would describe this, and I'm, I'm going to use an analogy here, I'm going to, I'm going to use a cooking analogy, even though I'm I'm not the greatest chef in the world.
I love cookies. It's awesome. Little known fact in during the COVID, during the pandemic, I spent like six months trying to perfect the perfect chocolate chip cookie because I wanted to build a business. Oh wow, where you could buy your cookies fresh on the oven? But then I went back to crypto. I mean that, that, that I love cookies that, that, that sounds, that sounds very tasty and like a like a very interesting service.
So I guess from a, a monomer and to compare it to be like the like built or cooking with the cooking with monomer or cooking with the monomer and the Cosmos SDK versus cooking with the just the OP stack today. It's what you have in your kitchen cabinet. So if you were to cook with the OP stack today, you have the EDM, you have like this a limited set of ingredients in your, in your, in your, in your
kitchen cabinet. And maybe it's just like a salt, pepper oil, like very, very basic ingredients. The OP stack doesn't come with a lot of custom modules and they don't have like this like huge library of custom modules that you can just like pull and, and use within your, your app chain. So it's very hard to customize. You can customize it, but you have to make your own ingredients.
So like, if you want, I don't know, fish stock, you have to go make your own fish stock and then add it to your. And like, making fish stock is a lot harder than just having powdered fish stock in your in your kitchen cabinet.
And if you're cooking with the Cosmos SEK and modern rare, what you have is you have this like great kitchen cabinet full of ingredients, everything ranging from a different spices to fennel to different herbs to different to, to different types, even different types of salt, like Himalayan salt, like all, all the different colors there. So, and you get this because there's a number of teams
building in the Cosmos SDK. There's already this great collection of Cosmos SDK modules that you can just use off the shelf. So you can build something a really cool custom app chain without needing to make these ingredients yourself. And maybe a great example of
this is Skip's Slinky protocol. So you could have this built in Oracle directly into your app chain without having to like like negotiate a contract with chain link and and like get these price fees at much lower latencies and a broader selection of prices and also custom price fees as well in in in a simple way. Another example is recently did a little bit of announcement with Fairblock.
Fairblock has an encryption module for the Cosmos SDK that allows you to have encryption and decryption or pre execution Privacy is what they call it in your application. So you can have like MEV protection, you can have like encrypted limit orders, lower encrypted mimpole for these like decks or defy applications. And that's hugely beneficial for a large class of different apps. Yeah, OK. I mean, I mean, that makes sense.
So essentially like what you're saying is, you know, monomer gives you the benefit of being able to use the Cosmos SDK, all its modules, but have that roll up settle to Etherium, which gives you you know which which gives you access to a theorem with the quiddity gives you access to that whole ecosystem of of applications. Does monomer allow developers like is, is monomer opinionated about like DA and and settlement
and sequencing? Or can developers choose, you know, if, if they want to use like Eigen DA or Celestia or some other DA instead of using a theorem, data availability, can they, can they swap that out easily? You know, if they want to implement their own sequencer, is that something that's possible or like use some
decentralized shared sequencer? Yes. So Modern inherits all of these architectural components from the OP stack, which is a a benefit because any support for alternative DA, support for fraud proofs, different fraud proving mechanisms, forced exit mechanisms, forced withdrawal mechanisms or forcing the transaction inclusion mechanisms, these are all sourced from the OP stack
itself. So one of the design goals for Monomer is that we don't want to rewrite all this chain derivation logic and settlement logic, which is quite complicated. We want to rely on this open source community built infrastructure that will improve over time. So with OP stack, there are modifications to use LDAI believe there may be some
modifications to use different. I guess people are calling them super builders now, so there's a lot of these kind of modified or OP stack modifications that developers will be able to leverage. Like is is the goal here to build an ecosystem of applications that, you know, use monomer in the Cosmos SDK And like, you know, how do you see monomer fairing against, you know, some of the other Cosmos SDK frameworks out there? You know, ethos is 1.
You know that like utilizes Eigen DA or that utilizes Eigen layer restaking. You know, we have now like I guess it's now it's called Grug Larry's project Cosmos and demon. You know, there's like layer like Jake Hartnell's project that also uses like more more uses Cosmos, I might say more so than the Cosmos SDK. But is the future of Cosmos development? Does it lie in the Cosmos SDK or does it, do you think, do you think that Cosmos and can surpass it as a more flexible?
Because I, I've talked to a lot of developers that, you know, love the Cosmos SDK because it's great. It has all these modules and everything, but also kind of hate it because it's so hard to build new modules and, you know, go it, it makes it like a, there's like, like a lot of configurations to, you know, for, for modules, whereas building, you know, natively with Cosmos is a lot easier. And you know, Osmosis, of course, I was like built most of their infrastructure using Cosmosmosm.
Yeah, like do do you see Kazumwasum perhaps you know, surpassing the SDK itself as you know a scalable and kind of faster way to build applications? Like with any sort of like VM and building for that VM versus just building in like like native Go or some native runtime of a particular language, there are inherent trade-offs. I think the applications will decide like what fits best for
them. My hunch is that when they want to hit a particular scale or when they want to build something very specific, perhaps they will select the Cosmos SDK like coming from like Web 2 like myself, I pick the Cosmos SDK because it's maybe the analogy here is it's the closest thing to React for blog building a blockchain that I could find. The docs are incredible. The support, the tooling is incredible. There's a lot of momentum behind this project like binary builders is great, Marco is
great. So I I am very bullish on the Cosmos SDK. But ultimately I think it'll come down to if they just want to build an application in to get something out the door. I think they probably are better off starting with Cosmos and or some like existing VM and perhaps not even building in their own chain. Just deploy some smart contracts through some existing blockchain network. Yeah, that makes sense.
Yeah. Like compared to some of these other, you know, Cosmos SDK frameworks, why would someone choose monomer over say like, you know, ethos for example, you know, like? Oh, before I talk about that, I didn't want to add 1 point to this. This, this scaling and I guess control the question of control.
So if you use something like Cosmos and you don't have hardware level control, if you use or like I guess kernel level control for certain applications that they want to be fast or they want to like make certain optimizations, they won't want that level of control. They kind of have to break the abstraction boundary. But that's not for every application. I think only a few applications will will want that or will feel like at a certain scale they'll
want that. But yeah, it's, it just, it depends on the, the app from a framework perspective. A lot of the frameworks that you listed I believe are like like Ethos that's providing like I can layer restake security for like Cosmos chains. Those are still technically layer ones, even though they get their security from somewhere
else. They're not technically a layer 2. The cost of security is you're paying for security budget versus paying for settlement costs, which is a layer 2 consideration and also the architecture of your chain. You're not inheriting censorship resistance. You're not inheriting some of these blockchain properties from the layer one. And some of these blockchain properties are some of the
hardest to achieve. Like censorship resistance is probably the most difficult when combined with liveness to achieve properties to achieve within within blockchain. So it depends on what the application cares about. If they don't care about censorship resistance, they don't care about these fundamental blockchain properties. They just want to have some like security budget they borrow make that makes a lot of sense. So it depends on what what they're, what they're looking for. OK.
Yeah, thanks for clearing that up. OK. So like Monomer is squarely A roll up framework and so therefore it inherits all the properties of a roll up. Whereas like some of these other frameworks may be still considered like an app chain framework or at least inheriting it's security from in case of ethos like restaking restate ETH in the case of you know, building on the Cosmos Hub, like you're inheriting security from
the hub. Yeah. And also you're, you're making a bet on on the technology like when. So I guess to give some insight into how we thought about technology at a company like Uber when we decided on, you know, using a particular database technology, building our own, we're taking a long term bet at Uber size and scale. It's very hard to change course. Like moving to a new database system is very costly for the
entire company. So the way we would evaluate is we look on like a 10 year time horizon, maybe even 20 year time horizon. And we have to look at things like, do we think this technology that we're building on will continue to improve and scale? For the next 10 years, what about who are the contributors? What is the pace of development in this project? Which direction are they going in what, what are they optimizing for? How customizable is this?
There's all these questions that you want to answer. And if you bet on Monomer, essentially you're betting on a number of different technologies. You're betting on there to be a great application frameworks that are ABCI compatible, whether that's Cosmos SDK, whether that's another framework such as Grug, you're making a bet there. You're also betting on the OP
stack. You're betting that there will be a continue to be a lot of contributors to OP stack and the OP stack will continue to improve for the next 10 years or more. So depending on how you look at the space and how you look at technology, you'll pick a framework based on like what you want to bet on long term. Because if you pick a framework that perhaps you always maintained by one party or one or two parties and that maintenance gets dropped, then you're kind of stuck maintaining
this thing on your own. And it's not a great position to be in. So what's the, what's the next steps here like of, yeah, mainnet. And where can people follow you and follow Polymer updates to get the latest on what's happening with protocol? Yeah, So definitely follow us on Twitter. It's Polymer under score Labs. We have our website and Discord information in there as well for the for folks that want to join
our community. You can follow me personally at 0X Shake on, on, on Twitter or I guess Zieder now. It's since, since the since the rebrand. But yeah, like maybe it's coming very soon. I can't give an exact date, but I promise you it is, it is, it is coming. It is coming very soon. And they'll look out for a lot of updates in the in the in the coming months. Cool. Well, I'm excited for it. A really big fan of what you
guys are doing. And I think, you know, bringing interoperability, like better interoperability between Cosmos and Ethereum is something that I've been waiting for, for a long time and like very bullish on like that space generally. And yeah, excited to see you guys going to main that. Yeah, I think so.