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.