Polymer: A New Era for Interoperability...on Ethereum! - Bo Du. Ep. 563

Transcript

when we first started polymer uh the interoperability landscape was very different I think the thesis then was there's going to be potentially millions of l1s and millions of these app chains uh what we started to see was the landscape began to shift and you started to see this rise in the number of layer 2os and not just layer twos originally these layer twos were just individual layer twos but they changed into layer 2 Frameworks we retained what we called virtual IBC this enabled us to permissionless expand the IBC network but we gifted the underlying architecture from using common bft as a layer one to using the op stack for settlement uh and chain derivation from ethereum what this allows is that for ethereum rollups that implement the EIP

4788 standard where there is some layer one information uh on that rollup that we can utilize we can allow those rups to communicate essentially as close to block time as possible welcome to epicenter the show which talks about the Technologies projects and people driving descent ization and the blockchain revolution I'm sebas and today I'm speaking with Bo who's co-founder and CTO at polymer they're building an inability hub for ethereum before I sh with Bo here's some information about our sponsors this week car one 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 stti

with corus one including institutions like bitgo and Ledger sticking with course one not only gets you the highest years but also the most robust security practices in infrastructure that are usually exclusive for institutions you can stti directly to corus one's public note from your wallet set up a white label note or use the recently launched product Opus to stake up to 8,000 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 sing today at chorus.

one this episode is proudly brought to you by nosis a collective dedicated to advancing and decentralized future nosis leads Innovation with circles nosis pay and metry reshaping open Banking and money with Hashi and nosis VPN they're building a more resilient privacy focused internet if you're looking for an L1 to Launch your project nosis chain offers the same development environment as ethereum with lower transaction fees it's supported by over 200,000 validators making nosis chain a reliable and Incredibly neutral foundation for your applications nosis Dow drives nosis governance where every voice matters join the nosis community in the nosis

Dow Forum today Deploy on the evm compatible nosis chain or secure the network with just one gno and affordable Hardware start your decentralization journey today at nosis doio hey Bo thanks for coming on this week yeah thanks for having me yeah so we're talking about before the show so actually you've been on my podcast inop 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 um yeah how's your summer going it's pretty good uh gearing up for for mainnet soon uh 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 uh you know it's been uh 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 uh just disclaimer here I'm an angel investor in polymer uh but with that out of the way I think we can have a conversation about the technology about uh the polymer uh hub and the SDK that you guys are building and and also you know your fervent I guess defense and and love of IBC you know as like the standard for interrup ability in crypto which I tend to agree with and I think uh you know you're sort of like spe speaking to the choir uh

preaching to the choir here um 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 polymer and and like how you guys got here yeah absolutely uh I can do a quick uh guess self background on myself for the folks uh that are that are new that haven't heard me talk before so my name is B I'm a technical co-founder at polymer my personal background has mostly been in web 2 worked at a bunch of different startups worked at Uber uh 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 inro I would say that when we first started

polymer uh the interoperability landscape was very different I think the thesis then was there's going to be potentially millions of l1s and millions of these app chains maybe a few large l1s and a I guess a law and tell 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 l1s uh starting with different ecosystems like ethereum we were investigating ZK we investigating all of these different Technologies because we wanted to make it cost efficient to connect securely from like a cosmos chain to ethereum um but as we were

working on this problem and as and as we had developed some of these like proof of concept Technologies to enable this uh 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 and and fall of interest in the cosmos uh I think it kind of rose with terara and then after terara and FTX and like the the bare Market kicked in uh interest started to die down a little bit um 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 changed into Layer Two Frameworks and this concept of roll up as a server became really popular and I've seen a number of folks uh tweet that and

mention that in different talks and it kind of makes sense uh when you have a later one blockchain you're paying for consensus you're paying for uh these things which comes at a cost in order to have decentralized trust uh but with these like later 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 seems like a more pragmatic scaling model in terms of cost and efficiency so our thesis changed from okay 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 uh we realized that building this layer one solution wouldn't be effective

in connecting different layer 2s uh the technical Nuance of which you know we can get into a little bit later in this call but I'll say that it it revolves around the legancy cost safety and all these other properties uh for us to make the best solution for layer 2s we realized we have to the pivot to being a layer 2 ourselves so we uh re architected the polymer solution we did not change the I say the application layer protocol that we had built um we retained what we called virtual IBC this enabled us to permissionless 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 uh and chain derivation from ethereum uh and this

with this new Solution that's basically what we've been working on on for over a year now and what we'll be launching mainnet with very soon yeah very cool yeah I think like this this idea that you know we would have thousands and 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 um settlement consensus you know I think logically app chains have you know now kind of moved into this L2 territory which allows them to run uh with you know sufficient for most I think sufficient sufficient

guarantees on censorship resistance and throughput um while maintaining your reasonable cost because as we've seen throughout this this um this cycle you know maintaining a chain in the traditional kind of Cosmos app chain sense running your inv Valor set there's just like a lot of inefficiencies there um starting by the fact that like most Cosmos sa chains have the same validator set at least like there's a huge overlap um yeah but um but this this new model kind of makes makes sense um you know like you you guys you guys published this article on on the scaling limits of l1s and l2s uh which I thought was really interesting and it seems like

with l1's there's kind of a hard scaling limit that um that the space is you know established and and is aware of but then with l2s it's it's a little bit more blurry or at least the scaling limits are not fully tested um can you talk a little bit about what those scaling limits are and what we know about them yeah uh before we talk about it I wanted to mention one thing because you're on the topic of this like app chain thesis moving from a bunch of layer ones to to layer twos uh it's like ethereum is speedrunning the cosmos Playbook uh 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 of the scaling limits I would say that there's if so maybe the way to frame this is uh from if you have imagine a chart going from low scale so like very low TPS uh very high latency to really high scale which is uh really High TPS really low latency uh you can imagine that there's a number of bottlenecks you're going to hit as as you go from one technology to the next uh and in the article I create this diagram where I I try to help us 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 uh data transaction data to be gossiped over some peer-to-peer Network um these are just kind of algorithm 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 bottleneck meaning that if you want to account for home stakers uh home internet connections are only so fast uh like for example you can only or it's very hard to get a gigabyte internet connection in most parts of the world uh I think many folks in the west are fortunate to be able to have fiber optic cable into their um a neighborhood and can get some of these uh connection

connection speeds but even then like the real connectivity speeds are are far less than 1 Gigabyte uh and if you look at you know some chains like salana where they're requiring 10 to 25 gigabytes per second Network links it it doesn't work with home staking uh you end up having to put your software into Data Centers because data centers can offer anywhere between 10 gigabytes to 100 gabt or more and not only do you put them in the same data center you're actually in some cases uh 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 network

bandwidth limit that kind of like presents itself as a ceiling for how fast or how scalable a layer one can be and then if you step beyond that you're in this layer 2 territory where the layer two doesn't necessarily need a consensus algorithm uh it doesn't necessarily uh or isn't necessarily Network bandwidth bottleneck because you could run like a central like a single proposer single sequencer and just run extremely high throughput through it and there's a number of uh teams exploring this design space Mega E being one of them and this 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 salana monads doing that as well uh and and now you're seeing the layer 2os you know push even further so the the ceilings there maybe in a few years Time 1 million TPS on a layer 2 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 um different ways to scale uh like l1s I think like that that's space has been explored as you said and then now l2's you know in the end do like you know when I when I hear of a team build like like another framework to build rollups I think like

oh yeah yet another rollup framework like and and um 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's not like that many applications and end user applications being built it's a lot of infrastructure what's the the endgame here for all these rollup Frameworks yeah I think it's everyone's going to have a different opinion and I think people over index on uh zero knowledge here um I say that because not because I'm a I'm not a fan of zero knowledge I in fact I I've thoroughly enjoyed learning about zero knowledge Tech and also working on zero knowledge

Tech as well um but from the perspective of uh cost and scale I think Zer knowledge Tech isn't a 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 uh teams will end up optimizing for different workloads and that's kind of why the app chain thesis exists I to give you an analogy here or maybe uh something from my a story from my past when I was working at Uber in 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 uh and you and then you like run it in this runtime which is actually emulated in a in a in an actual runtime on your Hardware but from a um 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 as Uber scaled as a business they started shifting away from okay 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 Tred to save on these infrastructure costs they started developing specialized databases they

were like okay 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 are huge benefits right like uh 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 uh I'm going to create a search algorithm custom just for this one workload indexing algorithm custom uh and and now you get into a world where like you can save 90 95% on your infrastructure costs um by running these specialized uh databases for these specialized workloads that you couldn't get otherwise with this generic like evm or generic like regular database right so in this case like you you're talking

about like using postgress versus building something custom inhouse or like using some framework that allows you to do your own custom database yeah yeah exactly um like there was like I believe they were using Cassandra uh for their time series data at one point but they were ended up using way too many resources so they switched over to building their own uh called custom time series database which I ended up working on called m3db no that's interesting okay I mean uh 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 postgress

and nodejs and like off-the-shelf components uh when you get to like a certain scale you you you have to build your own highly scalable uh highly cost effective uh systems where 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 deploy it on the evm deploy it in existing blockchain and look for pmf first uh 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 uh Journey so far um maybe not some of the social commentary going on and in in uh in Twitter and some of the uh um I guess like social tension there but from a technical perspective it's very interesting so uh they had this journey from writing a bunch of smart contracts and then they were working on building over like a generic op stack evm L2 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 uh envir 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 s uh and and are building what they um call like a purpose built chain for their specific use case okay yeah no that makes sense so let's maybe um talk a little bit about IBC here because uh I think a lot of people you know see polymer as uh like building IBC for ethereum or like implementing IBC on ethereum if you've just like sort of heard of polymer I 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 IBC a little bit and I think there are still some miscon ceptions 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 um so maybe just give a high level overview of like what is IBC and you know H how is it how is it fundamentally different from some of the other inability products that exist uh that people are familiar with you know like hyperlane or Axel like you know layer zero Etc so actually since we've had that conversation

uh I'll say that there are a number of protocols that are kind of moving in the in the same direction in terms of splitting out the stack so uh you'll notice that like since then layer zero has kind of like modularized their stack they're like oh we need to separ separate verification from execution uh 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 uh you have application transport and U verification or or state that most Protocols are trying to move into this area where they are splitting those layers up they are kind of allowing people to supply different verification mechanisms and so on um so now I would

say the the major differentiator is is not in that like three- layer design it's in that IBC just offers a lot of features in that transport layer and a lot of these features are for forward looking so from a from a practical perspective uh 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 uh messaging related meaning that I can send a packet I can receive an acknowledgement or a timeout to things like authentication to things like uh versioning and upgrades uh because even when you 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 um 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 automically do that so you have to handle all these edge cases um and one Edge case could be just to give you an example is uh the crossing Hello's problem uh what if you have an upgrade initiated from three different chains all at once how how do you solve that what if what if you have messages that aren't flush for the old version um that you know in the middle of the upgrade how do how do you handle like flushing of these old transactions uh and like the IBC designers have had a lot of conversations around this if you go look

in the specs there's a lot of debate on every single topic um and it's good to be able to build off of that that debate uh another interesting thing for us is obviously also makes coordination happen on Chain versus offchain this something that we didn't get to talk about in the last podcast uh but it's something that is becoming very clear that is a differentiator of IBC from its competitors is that uh a lot of competitors they you they'll use identifiers such as uh chain ID uh 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 uh meaning that you have to have social consensus around

chain IDs because anyone any chain can join a network and say like you know what my chain ID is also ethereum or like I'm also ethereum um and From ibc's perspective you have this concept of connection IDs and channel IDs Channel IDs uniquely identify an application uh connection IDs uniquely identify a chain and think if you think about connection IDs and and channel IDs from the perspective of a map so let's say you have this like uh 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 uh each of these chains it 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 enforcable so that all of all coordination happens on Chain versus like having had having to have social consensus having to have a centralized relayer set that just knows what to do um and 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 IBC H how much of ibc's design do you think uh is inspired by uh designs of like tcpip and networking protocols I would say that it is very much inspired by tcpip I think I believe they use uh like Chris go and a lot of the original IBC team used tcpip as a

model for which to uh base their protocol off of like the handshaking protocol is to prevent like man- in-the middle attacks there's um authentication baked in uh kind of similar to like a TCP connection which is like an authenticated like Port essentially and even the port concept is I think pulled 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 uh in IBC land is kind of like a a spark contract and and a port in TCP land is a is an actual uh socket on your on your computer in yeah yeah that's interesting yeah you gave a talk at um modular Summit you

know describing um 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 um one one interesting thing about that talk was your description of like how Network topology um manifests where you have like when and then you have you know lands and then you might 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 l2s um but also sort of l1's you know how does that overlap with the landscape and the typology of applications and in l1s in um in crypto yeah uh to give viewers some background here in dur early 70s and 80s you had a lot of different internets 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 and wanted to have those devices networked are 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 rollup landscape each rollup ecosystem is essentially building their own like native interop solution and these Solutions can be like made analogous to local area Network protocols from thly internet uh I 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 rollups in that Network or either directly or have one degree of separation in between them so

either they're connected through a central Hub or they're connected directly to one another and optimism is doing this um arbitr is doing this and now you start to see you have all these different virtual local area networks that are spawning up each kind of with their own separate protocols this is very similar to what happened in in the 70s and 80s um but you also started to see that there was the growth of arpanet so arpanet adopted tcpip and I kind of equate 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 and uh an early screenshot of map of zones where you have just a few of these

Cosmos l1s connected to each other and now as we're entering a growth phase for the IBC network with the interchain you start to see a lot more of these uh different ecosystem or different virtual local area network clusters being connect connected to this wider area network or or W and over time this Wan I I use the term virtual Wan in the in the blockchain setting uh starts to consume these uh virtual local area networks and at some point the um 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 mirror is tcpip and all the other ones are uh 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 uh credible neutrality where uh tcpip like IBC was adopted across different ecosystems and ultimately became not associated with

any one uh company whereas a lot of these rollup ecosystem specific Protocols are used within a single ecosystem this is not to say that there may be contenders because TCP also had uh 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 interal protocol today whether that's a native interupt protocol a rollup ecosystem or a third party interupt protocol made by some of these other interupt providers you'll see that IBC is the only interrup 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 one degree of separation so maybe there's like two chains in this network that are separated by 10 hops they can still efficiently communicate directly to one another uh via multihop IBC channels which is different from multihop IBC packet forwarding uh those are kind of like two different solutions um but yeah IBC is the first 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 um I guess time will tell what what happens what happens here right so that kind of mirrors

routing uh 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 uh of data centers that like will relay those packets uh through you know the internet and like oversee cables Etc interesting yeah and and it's only protocol that allows you to um I would say that the difference is because you can try to do multi-hop packet foring with some of these other existing interal protocols but the major difference is that with uh multihop IBC channels what you're actually propagating through the network is

compressed State meaning that it's the um 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 mitted at the source and the destination so this uncompressed data does not flow in between which makes for far more efficient communication than with uh with alternative methods okay I didn't know that cool well let's talk about the polymer Hub so um one of the questions people on Twitter said that I should ask you is when main net and um so I guess I guess you don't have an answer for that yet but but but we can talk about what is going to be

mainnet which is the polymer Hub um 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 rollups and um different rollups have had to implement you know their own probability Solutions applications have had to implement their own inability Solutions um which is kind of crazy when you're coming from Cosmos right but um so yeah let's let's talk about the Hub and what role you it to serve yeah I'll say at a high level it

does implement IBC we will bring that feature set that we just discussed to these rollups and using the like wide area network local area network analogy here um polymer Hub straddles these rollup ecosystems IBC has a standard similar to tcpip straddles all these rollup clusters and provides connectivity across cluster and with the rest of the inter chain as well so from like a API surface perspective you get the standardized API for accessing all these different chains um additionally I'll say that the so back to 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 rollups such as Mega e push towards 1 millisecond block times uh 100,000 TPS and perhaps even a million TPS and uh with realized that we needed to build polymeriza L2 to be even able to scale to the point that we can support uh these these rollups because if you imagine you have a sovereign layer one Hub and spoke inall protocol and you're trying to connect two Mega eats to one another but just consensus alone put puts your block time at you know like aund like a few hundred milliseconds uh at at the at the very uh very least usually like a few seconds then it's very hard to

match that um that latency it's also very hard to match that that thut U without making the solution very very centralized of course if you put three 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 U but then you're like very centralized and you don't really have the decentralized properties of a layer two because which which inherits those from the layer one so there's like this scale reason why we built polymer Hub this way um and the other reason is from a uh cost efficiency uh standpoint and latency standpoint so uh it's it's coste 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 uh cost inefficient from checking things like data availability ordering and even validity uh because you imagine you partner with a a company like we're partner with a company called L Grange they're working on a solution called L Grange State committees which offer I guess a quote unquote like client for optimistic rollups and perhaps even other rollups 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 uh 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 add stations to our Central Hub and only generate one proof for in Chains uh this becomes much more cost effective for us from a validity standpoint uh and we're able to uh 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 uh talk about ZK proof aggregation in the

context of the AG layer they're talking about um ZK proofs of validity meaning that this is a ZK proof of the execution of a chain of the full execution of a chain uh what I'm talking about here is a ZK uh attestation so L Gran State commit nodes are not generating a ZK proof for the execution of the chain they're generating a ZK proof of the add a station so it's much more similar to uh a like client like a tender like client than it is uh I guess like a ZK evm like like validity proof ZK validity proof okay got it C can you talk a little bit about polymer hobb's um architecture and what it's built on yeah

so we're Cosmos SD uh at the application layer and we use this framework called mon uh for us to be able to deploy this Cosmos SD app as a rollup over the op stack and the uh 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 there's some technical Nuance here so I'll dig in a little bit uh is that there is logic in op stack that deres 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 Two block with a specific layer one block uh what we can do is we can essentially communicate across different layer twos beneath ethereum finality so today most protocols either wait for ethereum finality or they'll go faster than ethereum 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 uh and what we were able to do is we developed a rework protect protection protocol for subf finality communication across l2s which essentially builds a

dependency graph of transactions based on some history of the layer one and at the end of uh this finality period so once ethereum begins to finalize we we can have a condition that says if these transactions that were built on the history of ethereum 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 uh dependency graph so it offers additional safety guarantees around communication at lower latencies therefore bringing reor RIS risk from the application Level uh down into the protocol level and handling it in protocol while providing extremely low latencies and we're trying to Target

less than 10 seconds okay maybe this is a good time to talk about the different types of finality and fast finality uh mechanisms that exist I was recently researching this for uh um in the context of movement labs and I saw that like tal was um getting into some some some debates with with rousi about like what is a rollup and Final Etc so you know maybe just um uh going across like the different types of finality finality mechanisms and like you know if for listener is explaining okay like what are these pre-confirmation and what are the different tradeoffs and like if we

add fast final to that like what of the trade-offs there as well yeah so I think there's uh some some confusion around like what finality means um so I'll start I'll start off by saying no protocol can guarantee finality on behalf of ethereum ethereum has its own finality mechanism uh if you if you attempt to guarantee finality what you actually get is a completely different rollup construction so if you know hypothetically you were to say there's this other consensus layer that I'm going to Define my the the canonical ordering of my chain or my finality on now that chain becomes a rollup of that other consensus layer so um and if you

move down the direction of this analogy you 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 uh Define your finality based on that consensus layer and then you post a state commitment to to um to the ethereum layer one uh and that's basically a side chain more more or less um so for rups that do Define their finality or like final finality on ethereum you can have something called a pre-confirmation uh and what this is is it's a guarantee or it's a guarantee that if a um a block proposer gets a specific proposer slot that they will include your transaction in that slot um 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 um however ever if there is a reorg and that proposer slot now becomes maybe perhaps moved further away now you find that that guarantee doesn't uh doesn't hold anymore because uh the proposer no longer the proposer has essentially like lost their slot for for the full guarantee you have to wait for full theor finality which is roughly 12 to 16 minutes okay and so this this mechanism that this um uh this reorg protection mechanism that you're implementing I

think the term you used was it it sub plants ethereum finality is that oh no no it it it does not it cannot replace ethereum finality uh instead it's a u it's it's sort of like a guarantee around eventual finality so it's an optimistic guarantee the same way that pre-con bu the same way that Builder proposer pre-c confirmations are also an optimistic guarantee so it's an optimistic guarantee on the ethereum on ethereum's finality yes yes and but but it has guard rails in place where if the um 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 okay and then what happens to those transactions if they're invalidated so like as the user of the rollup 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 uh 99 Point like 9% of the time uh their transaction is going to go through this is not so dissimilar to using a layer two today so if you use Unis 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 two 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 uh your your swap will just like disappear you be like oh

actually I never made this swap I have my original asset um and and that's a nice guarantee because you if you have all these different transactions interacting with each other across chain you you never want to get into a state where there's a double spend you never want it to get into a state where like one actor has made money on one chain and also like not never transferred their funds on the original chain so in order to um be able to make this guarantee across any number of rollups uh we had to have this like Atomic like protocol like Atomic or conditional like commit or revert protocol um so it's better to be it's better to revert all the actions than to end up in an inconsistent State across the different chains and so how does um how does this mechanism

facilitate interoperability between different ethereum rollups what this allows is that for ethereum rollups that implement the EIP 4788 standard where there is some layer one information uh on that rollup that we can utilize we can allow those rollups to communicate essentially as close to block time as possible possible um 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 at 100 milliseconds um with I guess additional account for additional like actual Network latency of this communication since we're still on the topic of the polymer Hub here um you know for for rollups that want to

utilize polymer hub for interoperability so like arbitrum you want to send assets on to base what is required for those rollups in order to uh onboard 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 um there's some IBC like specific setup that's required but uh there's no opt in by the layer 2 like the layer 2 doesn't have to opt in using some like you know uh special process they have to run they don't have to change their

deployment infrastructure um like nothing needs to change on their end okay so so it's it's permissionless for the rollup a user can't uh permissionless use polymer interoperability without the roll up having implemented it uh without having polymer integration deployed but uh technically we 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 uh we're planning on automating all of this so that uh perhaps you could have like a permissionless pipeline uh or some like

Loosely permissioned pipeline of just requests to like new deployments and this is true in the IBC Network today which if anyone spins up a chain uh 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 um but we plan on providing some like more userfriendly front end for for that sort of thing so we've talked about ethereum so like essentially polymer will allow any any rollup on it any ethereum based rollup uh to interoperate over IBC what about the existing IBC ecosystem and and sort of cosos broadly what does that look like and you know is is it is it the case that kind of Palmer sits at the middle and interoperates

with IBC um as that kind of middle hop our our ethereum based rollups going to be able to send assets directly to and from um IBC the the IBC Network so can I move assets from like osmosis to like some decks on base um permissionless yes so do we be able to use a protocol permissionless Le although because of how our virtual IBC protocol works uh polymer handles IBC execution and implementation on behalf of the rollup so uh for a rollup 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 rollup that natively implements IBC technically that that rollup could communicate directly with the IBC Network so yeah let's let's talk about monomer a little bit um so so monomer is an is an SDK I guess the polymer Hub uses monomer um but you can also build your own rollup using monomer it's a I guess a generic rollup uh SDK that uses the op stack you know who do you think what kind of applications do you think will use monomer um and what is the kind of differentiating

factor uh you know as opposed to using like some other rollup framework or you know using the op back 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 I'm going to use a cooking analogy even though I'm I'm not the greatest Chef in the world uh I love cookies that's awesome little know fact in during the co during the pandemic I spent like six months trying to perfect the perfect chocolate ship cookie because I wanted to build a business oh wow where you could buy your cookies fresh from the oven but then I went back to crypto I mean that that that um I love cookies that that that sounds uh that

sounds very tasty um like a like a very interesting service so I guess from a a monomer and to compare like the like or cooking with the cooking with monomer or cooking with monomer and the cosmos s versus cooking with uh the just Opie stack today uh it's what you have in your kitchen cabinet so if you were to cook with the op stack today uh you have the evm you have like this limited set of ingredients uh in in your in your in your uh kitchen cabinet and maybe it's just like a salt pepper uh oil like very very basic ingredients uh the obac 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 and modernware what you have is you have this like great kitchen cabinet full of ingredients everything ranging from different spices to fennel to uh different herbs to different um uh to different types even different types of salt like Himalayan salt um like all all the different colors is uh there so and you get this because there's a number of

teams building in the cosmos SD 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 can have this built-in Oracle directly into your app chain without having to like like uh negotiate a contract with chain link and like uh get these price feeds at much lower latencies um and a broader selection of price feeds and also custom price feeds as well in in a simple way uh another example is uh recently uh did a little bit of announcement with Fair block Fair block has an encryption module for the cosmos

s that allows you to have um encryption in decryption or pre-execution privacy is what they call it uh in your applications you can have um like Mev protection you can have uh like encrypted limit orders uh encrypted M pole for these like type decks or or defi applications and that's hugely beneficial for a large class of different apps yeah okay thatan 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 and all its modules um but uh have that roll up settle to ethereum which gives you you know which gives you access to ethereum

liquidity gives you access to that whole ecosystem of of applications um does monomer uh allow developers like is is moner opinionated about like da and and settlement and sequencing or can developers choose you know if if they want to use like Igan da or Celestia or some other da instead of using ethereum data availability can they can they swap that out easily you know if they want to uh Implement their own sequencer um is that something that's possible or like use some decentralized shared sequencer or yes so mon inherits all of these uh Architectural Components from the op stack uh which is a benefit

because any support for alternative da support for fraud proofs different fraud proving mechanisms uh Force exit mechanisms Force withdrawal mechanisms or Force transaction inclusion mechanisms these are all sour 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 uh and settlement logic which is quite complicated we want to rely on this uh open-source uh Community built infrastructure that would improve over time so with OP stack there are modifications to use all da uh I believe there may be some modifications to use different uh I guess people are calling

them superb Builders now uh so there's a lot of these kind of modific modified uh or op stack modifications that developers would be able to leverage like is is the goal here to build an ecosystem of applications that you use monomer and 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 um you know ethos is one you know that like utilizes i d a uh or us IG L reaking uh you know we have now like um I guess is now it's called grug uh Larry's project uh km wasm demon you know there's like

uh Lair like J Jake hartell's um project that also uses like more more uses cosm wasm I'd 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 cosm wasm can surp pass it as a more flexible cuz like I've talked to a lot of developers that you know love the cosmos 6K cuz 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 um like a there's like like a lot of configurations to you know for for modules whereas building you know natively with kmms lot easier and you know osmosis of course has like built

most of their infrastructure using km kmm yeah like do do you see kmom perhaps you know surpassing the SDK itself as you know um a scalable and kind of faster way to build applications like with any sort of um like VM and building for that VM versus just building in like uh like native go or some a native runtime of a particular language there are inherent trade-offs I think the applications will decide like what fits best for them uh 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 um 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 Block building a blockchain that I could find the docs are incredible the support the tooling is incredible um 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 uh but ultimately I think it'll come down to if they just want to build an application to get something out the door I think they probably are better off starting with KM wasm or some like existing VM and perhaps not even building in their own chain just deploying some smart contracts through some existing uh blockchain Network yeah know that makes sense yeah

like compared to some of these other you know Cosmos SDK Frameworks why would someone choose monomer over say like uh you know ethos um for example you know like oh before I talk about that I don't want to add one point uh to this this the scaling and uh I guess control the question of control so if you use something like km wasm you don't have Hardware level control uh if you use or like I guess uh kernel level control um for certain applications that they want to be fast or they want to like make certain op a they will want that level of control they kind of have to break the abstraction boundary um but that's not for every application I think only a

few applications will will want that or feel like at a certain scale they'll want that um but yeah it just uh it depends on the the app from a framework perspective a lot of the Frameworks that you listed uh I believe are like like ethos that's uh providing like I restake security for like Cosmos chains uh those are still technically layer ones even though they get their security from somewhere else they're not technically Layer Two uh the cost of security is you're paying for security budget versus paying for settlement costs which is uh a layer two consideration and also the architecture of your chain you're not inheriting censorship resistance you're

not inheriting some of these uh blockchain properties from the layer one and uh some of these blockchain properties are some of the hardest to achieve like censorship resistance is probably uh the most difficult when combined with liveness uh to achieve properties to achieve within uh within blockchain so um it depends on what the application cares about if they don't care about sensorship resistance they don't care about these uh fundamental blockchain properties um they just want to have some like security budget they borrow make that makes a lot of sense uh so it depends on what what they're what they're looking for okay yeah thanks for clearing that up okay so like monomer is squarely a rollup framework and so therefore it

inherits all the properties of a rollup whereas like some of these other Frameworks may be still considered like an app chain framework or at least inheriting its security from in the case of ethos like reaking restake eth um in the case of you know building on the cosmos Hub like you're inheriting security from The Hub yeah and and also you're you're making a bet on uh on the technology like when uh to uh 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 10year Time Horizon maybe even 20- year time Horizon and we have to look at things like do we think think this technology that we're building on will continue to improve and scale for the next 10 years um what are who are all the contributors uh what is the pace of development in this project uh 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 framework that

are ABCI compatible whether that's Cosmos SD 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 the op stack and the op stack will continue to improve for the next 10 years or more so depending on um how you look at the space and how you look at technology H you'll pick a framework based on like what you want to bet on long term because if you pick pick a framework that perhaps you know is maintained by one part party or one or two parties and that maintenance gets dropped um then you're kind of stuck maintaining this thing on your own and that's not a great position to be in so what's the what's the next steps here like ter of yeah main net and where

can people follow you and follow polymer updates to uh get the latest on what's happening with protocol yeah so definitely follow us on Twitter uh it's polymer laabs we have our website and Discord information in there as well for for folks that want to join our community uh you can follow me personally at zerx Shake on on on Twitter or I guess zeter now it's uh since since the since the Rebrand um but yeah like May'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 uh and uh they look out for a lot of updates in the in the in the coming months cool well I'm excited for for it

um a really uh big fan of what you guys are doing and I think you know bringing inability like better inability between Cosmos and ethereum is something that like I've been waiting for for a long time and like I'm very bullish on like that space generally and um yeah excited to see you guys going to main that yeah thanks so