Why Crypto Is Following A Similar Path As Cloud Computing with Polymer

Transcript

GM and Gan Bo what is going on welcome today we are going to be talking about hyperscaling interrupt capacity welcome to igen lay unlocked an interactive educational Journey Through the igen layer ecosystem created by technical Founders and builders for the entire crypto Community a special thank you to our partners allair polymer authentic skate and lrange for helping to make this happen our goal is to raise the collective knowledge of the igen lair AVS ecosystem and unpack the technical designs of the top teams in space welcome to igen layer unlocked G GM and g bo what is going on

welcome welcome back to the show uh today we are going to be talking about hyperscaling interrupt capacity and uh all of the Integrations that you guys have with Ian layer um and uh as always thank you for the support you guys are the main sponsor for the Igan layer ABS series Igan layer unlocked and uh we're very grateful for your support and uh very excited for this presentation so uh without F Ado Bo here we go yeah happy to be on the show um you know really excited about the topic today um you know I'm talking about you know how we're working with IG layer to scale interrupt capacity I'm going to Define what interrupt capacity means and what what the result of uh working with

with igen is so um I just do like a quick brief intro on myself um a technical co-founder at polymer Labs I previously worked in web 2 as a database engineer across a number of different startups mostly on the infrastructure side love databases now love blockchains and and interop so interesting transition there cool so the lay of the land today from my perspective is that we have uh a lot of applications that exist on chain that kind of sit at this intersection of regulatory Arbitrage and social coordination and this intersection represents you know a tiny subset of the total possible applications that could

be built on chain and then this begs the question of how can we make building on chain the best option for future applications in totality so I try to break up this problem into four quadrants it's a bit of a simplification but bear with me the four quadrants are network effects time to market performance and cost time to Market is important because a startup needs to survive they need to get to launch the faster they can get to launch the more attractive it is to build with a certain set of tools or in in a certain ecosystem the network effects or platform effects uh represent the distribution problem so it's the question of if I build for Apple's Apple Store well I get get maximum

distribution versus building somewhere else aws's Marketplace and a few other marketplaces also represent this performance represents the question of can I build an application that is competitive with other applications in my category and cost is pretty straightforward it's the it answers the question of if I build this application and this application scales to perhaps millions or even billions of users can this still be a profitable business for me cool let's jump into uh each of these categories so for the time to Market quadrant we can see that if you have a lot of application building blocks or

application Primitives it can drastically reduce your time to Market in web 2 you have a number of software as of service apis so many different things infrastructure Primitives application Primitives different types of apis for information and others other things that you can build off of uh to speed up your time to Market and in web 3 in the future the hope is that we're able to build application Primitives that can help future applications get to Market very quickly for example if we bootstrap a driver Marketplace on chain it means that applications building on top can leverage this existing Marketplace primitive versus having to do all the bootstrapping work themselves

and uh there's a lot of bootstrapping waste that happens in web to takes a lot of funding and a lot of human and Social Capital to uh get a lot of these platforms off the ground especially a lot of these dual-sided marketplaces execution and data capacity affects performance and cost the supply and demand relationship means that the more execution and data Supply that we have relative to man to demand means that the cost will come down and the more execution Capac we have applications can scale their app both vertically and horizontally across many chains eventually next we have interop capacity

this influences Network effects performance and cost as well so three quadrants its influence on network effects uh shows that if you have if a builder builds within a specific ecosystem or with a specific technology if they have the ability to leverage application building blocks that don't exist on the same chain on other chains or maybe even other remote ecosystems that improves the network effects of building on chain whereas for performance and cost the latency cross chain latency of an application affects the performance while the overhead of the Cross chain interaction will affect the cost or profitability of their application as they scale to hundreds of millions and potentially billions of users lastly we have latency latency

affects the performance of the application for example over 10 years ago Amazon did a study showing that for every 100 milliseconds of latency added to their application they lost 1% in sales this translates to in today's terms billions and billions of dollars in loss Revenue per 100 milliseconds and you see this trend happen across other types of applications as well not just in e-commerce social media search the drop off rate when you increase latency is is is tremendous which affects user attention and and profit to the application ultimately so to make building onchain work for all apps we must improve in all four quadrants to be competitive the

applications of today need to drive improvements across these quadrants that enable the future applications of tomorrow so where we're at today we can support protocols like story which can build what they need to build using a single app chain optimized for their particular work load meaning that they can unlock or create this massive IP graph with thousands of layers for their specific use case but the issue is story today is still orders of magnitude in terms of scale removed from what Uber operates at so in Uber runs on 20 plus different building blocks or database systems on the back end each of these database systems you're going to be looking at hundreds if not thousands of

nodes uh on really you know High hardware specs supporting these systems just their analytical database alone processes over or their analytical backend processes over 100 plus pedabytes of data within minutes this is a a completely different scale than than than we're dealing with in web 3 today and next I I really want to dig into the per how do we can improve in the performance and cost quadrants to make building applications like uber onchain possible so where we at in the scaling Journey on ethereum well the good news is that we're currently scaling execution data capacity and latency so I da recently ran an experiment where they

processed over 15 megabytes per second or all the raw block data from 15 plus chain simultaneously this includes chains like Bitcoin ethereum itself salana celo Celestia Avalanche and so on and on the other hand we have projects like Mega eth which are scaling execution capacity and latency they do over 100,000 TPS with 1 millisecond block times so as we scale all this execution uh data capacity and um latency we also need to scale interop capacity across these chains and this is kind of where polymer comes in so in this uh in this diagram here we show that polymer is

responsible for scaling verification capacity while we leverage IG da to scale the data capacity of our product and I'll get into the definitions next so what is interop capacity well we can Define interop capacity as the maximum amount of verification and data capacity that a protocol can handle where verification capacity is the overhead of the verification logic and the protocol Logic for the inal protocol different INR protocols have different features this results in different uh levels of overhead different security models have different verification costs which also affect the overhead the data capacity represents the packet proof or signature data required by the

protocol packet data is required for the actual payload proof and signature data is required for the various verification modes that an interop protocol can support interop overhead is then defined as the amount of interop capacity that's utilized to achieve a certain level of latency and security and we can see this relationship between interupt overhead and latency in this chart here so on the far left we have proving layer one to Layer Two settlement in the middle we have a LR State committee and then on the far right we have a sequencer P2P verification mode and we can see that as

latency goes from high to low interop overhead goes from low to high So the faster you go the more inter interrupt overhead you you incur let's review the different types of connectivity modes here we have a sequencer P2P verification mode where verification happens over a peer-to-peer Network we have a lrange state committee where a a committee of nodes attests to the valid execution of a rollup after data has been has been published and then we have the rollup native Bridge which represents rollup settlement to ethereum the sequencer PDP has latencies of between as low as two seconds or as low as block time is as lo as as L as a

block is produced and gossiped over a network a lan committee has you know roughly latencies of 15 to 16 minutes this really depends on how often a rollup publishes data and how fast that data finalizes on ethereum and the rollup native Bridge can take anywhere between an hour up to seven days this really depends on the U mode of settlement of the rollup whether that's using ZK proofs whether that's using an optimistic fraud proof um and the size of the or the length of the fraud proof window as well okay cool let's look at the data overhead of each connectivity mode using base as an example so for the sequencer PDP client we see that this takes you know every two seconds or at the two

second connectivity rate takes 7.5 kilobytes per second of data or 648 megabytes per day for lwan State committee which operates at every roughly every 15 minutes we can see that this takes 675 bytes per second or 58 megabytes per day day and for a rollup native Bridge which operates every hour we can see that this takes 2.7 bytes per second or 233 kilobytes per day and what this translates into well let's review the data bandwidth on ethereum first so the data bandwidth on ethereum is roughly 5.5 gigabytes per day of blob bandwidth this is based on the blob size uh ethereum block times and number of blobs uh per block

currently we're sitting at roughly 36% U ization of this data bandwidth where is data bandwidth utilization heading well projects like Bas optimism and others are currently increasing their uh I guess Target gases over time and this is what the goal of and Bas has this goal of getting to one gig Giga gas per second on base they started with uh 2.5 Mega gas per second uh back in March currently they're already pushing it to 12 Mega megag gas per second as you can see in the update below and this trend is expected to continue so we expect that ethereum da will be properly utilized

soon um probably to the excitement of of many eth folks and and eth holders so the issue with ethereum da is that we can only support a small number of chains over these various con connectivity modes especially the low Lany connectivity modes um e theet at 5.5 gigabytes per day and this accounts for current utilization rates so over sequencer PDP we can support up to five chains or approximately with the Lan State committee we can support 60 chains approximately with the RO of native Bridge it's a little bit better we can support 00 chains but obviously there's trade-offs between latency here now what is the data bandwidth on a well we have 1.3 terabytes of data

availability bandwidth per day currently this means that igda can support a much larger number of connected chains we can support over SE sequencer PDP over 2,000 chains with the Lan State committee we can support 22,000 chains while with the world of native Bridge we can support an egregious number of chains 5.5 million hopefully we get we do get to that number one day um but it but it's going to take some time and the important thing to note here is that the number of chains that are connected in real time increases the network and plat form effects a building onchain when a building block is more accessible remotely that uh increases the uh usability or composability of that

building block so we want to get these latencies down and we're only able to do so at scale with with uh by leveraging IG da let's look at verification overhead next so what is the verification overhead of connecting a 100 rollups using a peer-to-peer protocol or a point topoint prot protocol the sequencer PDP client or verification mode results in a cost of $155 million per day this is egregious uh luran State committee results in a cost of $1.9 million per day uh the role of native bridge is more I guess practical in this sense like you can do

approximately like with $40,000 per day can can I can I hop in and ask ask a question here because is there anyone that's using I mean let alone sequence uh pointto Point uh model is anyone using like the lron state committee and and or the sequencer point-to-point model and paying $155 million A Day No One is using the sequencer point-to-point model I think anyone would look at that cost and be like this is just not practical we're not going to do this um the Lan State committee there are a few Integrations that lrange has um I don't believe the valume over those integ I don't know what theum is over those Integrations today um yeah so that that's a that's that's a question mark

and this this this this would require L gron State committee every update every 15 minutes and this like factors in uh like the data cost and everything associated with it as well um so my understanding is that the way there's a difference in the way some Protocols are using lrange and and there's a difference in I guess how much valume is flowing over that protocol which uh results in like the number of updates and so on got it and then even even down to the rollup native Bridges per day it how are those costs paid are those gas costs that say uh you know an optimism native Bridge optimism is paying those gas those the the this inter this execution overhead is uh paid in eth to the ethereum

validators oh actually this is not the settlement cost of the rollup sorry I I should clarify the rollup native Bridge Is You using the already settled rollup State on ethereum and proving that on a connected rollup so this is literally saying like Okay this rollup already settled let me prove that some event or something happened like a a message event was emitted on this rollup uh that's connected over ethereum because every rollup has access to ethereum State already the cost of these this is the cost of those proofs got it okay okay cool cool and like very few people use like rollup native bridge for anything um and the way a lot of rollup native

Bridges work today is that you make a right to um the rollup you make another right with a proof on ethereum first and then you make another right um on the other counterparty rollup at Palmer we do support verifying packet scent over the RO of native Bridge directly without having an extra right to ethereum and this is kind of like factoring hypothetically what that could look like like even though I don't believe anyone is doing that today okay yeah cool now let's look at the execution overhead across all these 100 rollups using polymer with the sequence your PDP client the cost decrease dramatically to $330,000 per day which

is why we have a separate chain for this or L2 for this the gr State committee uh costs come down to $686 per day and the RO of native Bridge comes down to a very digestible $4 per day very very cheap um let's look at the reasons for this massive cost difference so the reasons aren't just that you know our chain is optimized there's fundamental reasons for why there's such a big cost difference there's a difference in connectivity model so if you compare the uh connectivity model of polymer which is an L2 a rollup hubman spoke model with a point-to-point model you can see that the point-to-point Model Auto all connectivity comes with a certain level of overhead um The Hub and spoke model

does make that connectivity more efficient and especially more efficient at scale where you have a lot of chains and a lot of chains are communicating very frequently with one another the other thing is that there are currently extremely high profit margins for optimistic rollups so you can see that base is currently operating at a 98.5% profit margin this is taking the uh cost That Base charges for execution and subtracting the cost to base or the expenses to base for settlement to ethereum this means that if you funnel verification logic directly to base instead of offloading it to a hub and Sil model like polymer you're end up

paying these margins if that makes sense polymer can like greatly reduce these margins optimizing for the verification costs of a lot of these models um and also by optimizing how performant we are for that particular workload let's step back a little bit and talk about the practicality of building onchain versus building just in the cloud or just a regular web app or web to application if we compare the cost of sending a packet across rollups versus the cloud currently across rollups in production on a production uh in point too in our protocol today it can cost roughly 25 cents per packet whereas if you send a packet in the cloud across availability zones and this is the more

expensive cost there's like int availability Zone costs which are a little bit cheaper um so looking at the more expensive Network costs in the cloud you get approximately like 0000000000 z7 cents per packet and this is this is a 357 million times difference in cost and like when you when you look at this number and you like put yourselves in the shoes of an application developer like basically trying to decide whether or not they're going to build on chain in the first place this is a number that just doesn't work for them because any application at scale that handles like millions of users and potentially billions of users especially these like realtime applications have realtime requirements to be competitive in a in a in a market where there's a lot of different apps what it means for them is that if the

answer to their question of like how much is it going to cost me to scale to like a million users or go from a million to to 100 million that it's going to be 357 million times more expensive to scale horizontally it just makes building on chain a no-go and this is one of the main problems that pollmer wants to solve to make building on chain practical so if we're able to solve this problem and get these costs down what what could the future look like this is a diagram of what a microservice based application in the cloud looks like today you have an application API which routes over a few microservices you have a few different databases you have a a queuing service uh you have a a message queue in Kafka

you have some background services that does some data processing for for some analytics um this is roughly what it what it looks like usually it's like much like larger scale than this um I think at one point Uber had more microservices than Engineers which is absolutely ridiculous um not all of them were like well maintained but like you get you get the picture so what does this look like transitioned into the applications of Tomorrow the microsurfaces could become rollups the background processes could become avss and the message cue could become polymer with all this settling down to ethereum and to really be able to enable that architecture on chain we need to be able

to scale a lot in those two bottom quadrants that we highlighted earlier in performance and cost to make internet scale decentralized applications possible and this is an invite to folks to build with us towards infinite infinite connectivity and Beyond uh we have some links to polymer we have some personal links for myself for my Twitter um feel free to reach out directly if you want to build with us or if you're just interested in uh discussing some of these topics that were presented in the presentation awesome so so the main goal here is to bring the performance and scale of building onchain uh to the level such that it is

comparable to the cloud yeah exactly although I'll caveat that it likely will never be better per or more performant but that's fine because there's four quadrants there there's the network effects there's a time to Market as we get more at building blocks time to Market becomes better especially for certain categories of applications and as we gain like a larger user base more liquidity more other things the platform and network effects like the distribution effects of being onchain become uh very digestible too as those two quadrants uh improve it actually helps like application builders digest some of the increased costs or performance penalties of building

onchain but the gap between those two cannot be too large and I feel like the Gap today is just way too large of a Chasm we just need to bring them closer it's fine if they're never as performant that's okay um but it needs to be a little bit more balanced yeah or a lot more balanced and the reason that we've we've heard to you know why it may never become cheaper or faster than building in AWS or the cloud is because this is inherently a decentralized system and in order to uh derive that property of verifiability um we need we need multiple different nodes and so uh on on the one hand in a cloud format you could

coordinate with just one maxed out Mega node right yeah and and that would be okay but you'd have to trust them and they could you know increase the the scale and the uh the uh processing uh scalability and efficiency but the capacity uh is much higher because they don't have to coordinate amongst different different nodes but as long as we want to derive that property of verifiability we have to coordinate in a decentralized way that'll have that'll have the benefit of verifiability but it'll have some cost in in latency and and uh efficiency um yeah I I actually think that the exe that we can get the execution cost down to pretty much Cloud

level um I'm really bullish on the idea of or the design space that mega mega eth is exploring like why why can't we just have like like centralized execution environments where we like max out hardware specs and that gets you like as close or like pretty much like very close to the performance of just a regular web server the one difference in my mind is like the data costs it's very difficult to get the data costs exactly as it were with a traditional database because a lot of these database systems they're working with like a replication factor of like one maybe two so it's like yeah I have like a um like like hot backup or or something for my database where I stream updates to that's very different from a data availability

network uh like you can get the cost like close-ish but like the da networks they have certain like encoding schemes that they have to add on top there's this overhead and like uh gossiping data I think I and da is exploring interesting trading trade-off space there where they're like okay like screw the PTP Network you know we still have to pay like the like the encoding cost and so like like disseminating the data but we have like this like P2P coordination layer between our nodes which does improve the performance a little bit can can theoretically get us closer to that cost of like uh just a single database with a single backup got it um yeah I I so that's interesting to hear execution overhead may may come down but it's the data bottleneck that is the main limiting

factor with relative to to Cloud um I I want to like kind of dive in on that a little bit so I'm going to hop back a few slides here uh let's see to uh let's see I think it was I want to get back a few slides here because generally I think base is actually a good example here and here's the data bandwidth this is the main bottleneck so we had a a podcast conversation with Justin Drake not long ago and he mentioned how uh he actually you know there's a lot of back and forth

with him and uh the benefits of composability and then they on on a podcast he looked at Bas right and and originally the idea was that base's Revenue was primar and I think you even had the revenue on here maybe in the next slide uh I want to find it because you I think you did have like their margins were um oh it's in the execution over slides I'll pull it up okay this one yeah yeah yeah so their margins here 98% they're they're making 86,000 a day like this works out to you know a couple hundred million bucks per year and the the discrepancy was that

you know Justin Drake was saying that almost none of that came from me almost all of that came from um from execution overhead uh and gas cost right but it turned out that um this this wasn't the case it turned out that most of this was coming from meev because every time uh base ends up running into their congestion limit they end up raising the gas limit and so you know that the me is maybe here and it stays there and then every and then congestion fees will rise but every time they start to rise too much and and surpass the the Mev they end up knocking the cost back down by raising the gas limit and so and every

time they raise the gas limit it kind of adds more data bandwidth right so yeah like how are they how are they able to just you know raise the gas Li raise a gas limit is that is is that just abundance like can they just can they just continuously raise the gas limit and not force their users to pay significant uh congestion fees eventually there's they're going to re they're going to reach capacity right and they they can't just keep raising the gas limit in perpetuity yeah uh they're going to hit the the like bottleneck um the other thing that people talk about a lot is State growth um we don't need to get like too deep

into the state growth problem uh now but yeah State growth is definitely an issue um there's like solutions to State growth but it's a really tricky problem when you have like a generalized compute system where there's a lot of different apps and ever growing number of apps and the way those apps are utilized or the utilization patterns of those apps is just very different and there's a lot of like user accounts some of them real users a lot of them probably aren't real users um the state gr problem is very real uh there's like some like temporary solutions to that and there's some like long-term solutions to that that folks are folks are working on got it okay um that that makes sense so generally

you you see that the uh the data processing bottleneck here is our main limiting factor when we're when we're trying to get to Cloud level scale yes and and with that being the bottleneck why why do you think ethereum is not at capacity like the blobs aren't aren't filled up utilization rate you know isn't 100% why do you think that's the case given that you know that that's the main bottleneck but we're not it doesn't seem like we're hitting it yet my my thesis is that we're we we already started with like a limited subset of applications and then we took this like limited subset of applications then we replicated these

applications across all these different chains I think that in order for us to truly like I guess break through to all the because now these people talk a lot about like infra not having customers we have too much infra to really break through that problem it seems like we need to expand the scope of the type of applications that are built on chain and then we kind of have this a bit of like a chicken and an egg problem where like the performance penalties and the cost of building on chain suck like they they they just suck and but then on the other hand like if you don't incentivize folks to even build these initial apps this is kind of where like incentives and other like cryptoeconomic things do come into play that if you can't get people to

build these initial app building blocks in the first place it doesn't make sense for future Builders to build on build build on chain if that makes sense so this bit of like a chicken and egg boot trapping problem where like we need the first two quadrants to really level up to help the the bottom two and we also need the bottom two to level up when the bottom two levels up like a little bit faster than the the the first two quadrants then we end up in a situation where there's too much infra and like like where's the demand and like like e e eth price goes down eth bad kind of sentiment the last three to four months yeah yeah yeah like the last three to four months of like the world is falling apart and like oh salana is winning because they're targeting use cases in theory um

or or so people like claim on on on on Twitter and like I I can't validate this because I don't um follow enough of these projects but claim that like they have other or people explain other use cases Beyond just like meme coins and Defi and speaking of salana do you think like if you know they are more consumer facing and so they claim and and we end up getting a lot of applications that do really really well but are only on a single chain those don't necessarily lead to more demand for interrup or right so do if that's the case do do you see this evolving in such a way that we end up with high levels of composability applications on bunch of different

chains and we're doing these more like Atomic transactions and super transactions that occur on multiple different chains or do you think there's going to be a few General purpose rollups with a a few killer apps on each of them and people that are on like in these ecosystems will will stay in these ecosystems yeah I guess the way I'll frame this is uh imagine you put this this is not going to work like Amazon runs at like an insane scale they have an insane amount of Hardware backing their their internal system so this this wouldn't work in practice but I'm just going to propose this like hypothetical situation so like imagine you put Amazon on salana and Amazon's like okay in theory like Amazon all of

Amazon's computer runs a salana you can like buy and and and sell in this Marketplace and and everything's on salana but the issue is that there's a minimum like 400 millisecond Bound for a transaction like it you can get the inclusion rate down they talk about multiple concurrent proposer and like all these other things but the execution latency is still going to take 100 milliseconds if not seconds I think it takes more than like seconds to actually like uh get to see if it if a transaction failed or not that's just not good enough for Amazon like at the very least Amazon's going to lose 4% of their revenue which is going to uh equate to probably like $20 billion a year in loss revenue and this is not practical for them and once you

get to seconds it's like it gets even worse they're losing like hundreds of billions of dollars and my take is that this is the reason why I like the design space that Mega is in is that latency matters like there's so many applications that already exist offchain where if you're entering like like defi is a little bit different right like defi is a new category if you're entering a new category your performance is not great that's fine if you're entering the existing category and your performance sucks you will never you'll never make it in the first place to give an apps of fighting chance they have to at least not be super handicapped and the performance of the application and the cost of running the application onchain are huge like massive handicaps so if if you like

shoot yourself in the leg and you try to run a race like you're probably not going to win this race when everyone else is already running at the speed of Usain boat like there's there's a there's there's a bit of a um a a gap there I would say so I think long term we'll see a lot of like localized Roll-Ups meaning that we'll see rollups that are deployed in specific regions where to power a real-time application if you're accessing that application from Singapore you're probably not going to be writing to a node in New York if you're asking the application in New York you're probably gonna like uh do rights essentially locally on your so like local rollup so maybe there's a future where there's mega mega eths in every region where an application is

actually split across all of these uh these rollups to deliver the right kind of ux to be performant within its category and so if we cycle back to like one of these earli slides where you illustrate the tradeoff um and we have uh which one the the essentially that yeah the this one here like basically that you know the amount of overhead uh scales with as as we lower lower latency there's also like a geographical re Regional component to this is what I'm hearing and so we can actually uh load uh yeah could I mean how how do you think about geographical location in

terms of this this dichotomy between overhead and and latency where where does the regional component fit in the regional component fits in the far right of the diagram so I would imagine that if you have applications that want to optimized for ux or the user experience of using their app that you would have very low ly Communication in localized clusters of rollups so if I'm building off a building block like um let's say we have like a real-time building block like a rider and Driver Marketplace just Just A Primitive not like any of the ride sharing application Logic on top or anything uh so just this Marketplace alone this Marketplace would be split across

geographically naturally anyways and then you would imagine that there's like a bunch of applications building on top of this Marketplace each one of these applications whether they bootstrap a rollup or whether they build an application on an existing rollup those are like you know two options that they can take they're all they're leveraging this real-time Marketplace to perform their application uh I guess like functionality and there's going to be a lot of communication in real time between these rollups together so I'm imagine the future communication will look like the cloud today where there's a lot of like very like dense like heavy Network utilization within like availability zones within like server racks and then across it because the price is going to go up too across like A's um and and like with with like the

distance and whether you're paying the cost in latency whether you're paying the cost in other other forms it does come at a cost so uh I would expect less less Network traffic between uh like between clusters of rollups even regionally and then across regions you would see even less Network traffic so like uh we're building we're trying to build a system where we can enable this like really high throughput dense connectivity between rollups that's very very frequent uh very very high rate and make it as cheap as possible uh to to make these like types of applications practical in the first place got it and and P like practically uh looking at the polymer AVS maybe we could hop over to that slide um oh we don't have a AVS no but the the

way that you guys work with AVS is there was a a slide oh okay uh here so you know you kind of describe this polymer sorry sorry uh this messaging queue right and then this is like the que that the abss are are running through the the tasks in this queue um the way that you guys are submitting these messages to like the very densely connected clusters of rollups could you explain generally how I think at a high level in theory I understand that there's there there's like the the dense connectivity of these rollup clusters

but H how does that work when you guys are submitting these these messages to the ultimately to the abss are down to ethereum yeah so my mental model for this and you know obviously this is just conjecture here is that polymer in my mind is very similar to Kafka so Kafka is a message and que it's open source uh it was the Kafka team at Uber was probably the most leveraged team across all infr teams so many teams relied on the Kafka team for their services and I believe Kafka at one time probably was processing the most amount of data um across all these Services

because when you have a system where demand is kind of like up and down up and down up and down you want I guess this like message CU or buffer in the middle for handling additional load meaning that like if rollup 2 can't keep up with rollup one you can have some backup for some period of time now once utilization comes back World up 2 can start like processing the the backlog and you know do what he needs to do after afterwards so a lot of like microservices that I'm familiar with heavily leverage this design pattern of putting like slapping a message cue in between everything and just making everything async so that like under normal circumstances there's never a backup but if there is a backup these

messages are not lost and they're stored somewhere uh that's verifiable and that's the messaging Q yeah that yeah exactly and that that's kind of like my mental model for for polymer okay okay um and so Kafka um that's something honestly I I didn't hear until this presentation like I was unfamiliar with it um but it but cafka in the general Cloud architecture is are these messaging cues between microservices yeah yeah that's how most people utilize them okay okay very cool and so when you're when you're looking at like some of the some of the

different interrupt Solutions out there um and and thinking about like scaling interrupt capacity um are I'm trying to I'm trying to I have this question in mind but I'm generally curious how how you're thinking that this is going to expand as we so what I'm taking away is basically that you your thesis here is we're going to continue modularizing we're g to continue to get more and more microservices and then polymer is able to fit as this me just generalized messaging cue between these different micros um when when you guys are building polymer are you doing a specialized Q for like

microservice a to micr service B that path has its own q and then like service B to service C has a different Q or is everything generalized and like everything goes into one polymer Q and A to B to C to D all of them all of the the messages that are going between them go into this one generalized polymer Q that's a great question it gives me an opportunity to show IBC um so so with IBC under the hood we can support IBC has this concept of channels which means that you can authenticate a cube between two services so that those two Services May own that Quee themselves and no one

else has access to it then those Services can then like send messages over their like own queue that's can be process in parallel to everything else that's going over polymer um people aren't forced to use this where actually planning on supporting other forms of uh interop with our system but if they want to use IBC semantics they can do what you described with those IBC semantics got it okay okay that that's very cool yeah I think IBC is like you know something that everyone knows and loves but like just you guys are helping to like bring that to the world um I think my my last question here and you know a little bit deeper into the igen layer integration

um you know you've got kind of like the couple of arrows here between rollup two goes through the messaging of polymer and same with rollup three goes through polymer and then ends up to to AVS one here so what exactly are you guys using these abss for or this Igan da like what is the nature of the integration with igen layer this is just uh graphical in nature so the services that a roll up will use since I kind of see abss as providing these like software as of service apis similar to software as a service apis in the cloud um it's really up to the ABS themselves I feel like

there's not enough avss to really like and and enough rollup microservice to really craft the story for this at this moment um but I would imagine that this is roughly how it will it will it will evolve where like these abss will provide these apis that RPS can use obviously the RS can use it use it directly as well well but polymer kind of requires like a messaging interface a type API for that interaction um and then it would it would evolve from there so like if the ABS perhaps is doing some sort of like verifiable background processing I'm making this up right now so some verifiable background processing of like the historical state of the rollup so that it can inform some like AI agent to like take some sort of

action upon this verifiable data so the ABS is could be like lrange where they like crunch some like zero knowledge proofs to do some like data analytics so there's like this long running query over the rollup State uh that then can get fed into a um into some like AI agent that then then does some like rebalancing of some D5 protocols like liquidity pulls across all these different chains maybe that's the future that we'll that we'll live in yeah okay that that makes sense another another one just cuz we've been hearing a lot from some of these avss um and I had a conversation with uh predicate yesterday and they're doing some of these they're doing like

pre-transaction checks um yeah and and so like you know one thing is like uh kyc for instance like making sure you know they have some like data providers uh who you know are going to check like ofac lists and and anti-money laundering maybe kyc you know if they were to if they were to have some sort of queue of transactions uh you would be able to hook like these rollup microservices up with their API their API would basically like check check check each of these different tasks and then you would you would service the Quee of transactions and make sure that they execute appropriately based on based on the

checks that they get uh and whether or not they pass yeah it would be probably like two different ways to interact um one method would be that they just have or build Integrations themselves so that they understand the transaction format of all these different rollups meaning that they they basically take the transaction inspect it like basically act as like a like a screen before submitting the like the post screen transaction to the roll of M pole this doesn't stop the like someone else from submitting a non-screen transaction so like I'm not exactly sure how their system works to like handle that case and the other case would be like hypothetically like if they if the entry point of the system was their rollup or chain or however their system

exists then if poll were to link that to the different rollup they could perform the screen onchain and then issue an action over polmer messaging to the other rollup and that action would already be post screen and authenticated so that the application on the end knows that okay this is from predicate this interaction is is uh is already a pre-screened interaction um I'm going to to accept it got it I I mean I'm very I'm getting very very excited this happens every time we do one of these educational series because it's like you know we we explore these really really deep ecosystems and I'm learning that I can layer is so early in the nature of like like you said there's

only a handful of abss on there right now we haven't even scratched the surface with how how these micro services are going to evolve and then you know there's opportunities to connect all of these services with one another so that you know we can get fast finality and ZK and lrange state committees and they're all pulling information from you know from onchain and offchain sources and then you know all of this is very very deeply connected I I think we've gotten this explosion of infrastructure now all of that is out on the table but we haven't been able to connect this infrastructure so that it can work together ultimately providing a better experience to app

builders then and then uh and then to to Consumers of these apps as well um yeah yeah so you guys are one of the ones that you know you're not you're not building one of these um one of these microservices yourself you're building you know the connectivity between these microservices which I think is just as important if not if not more important so yeah this been MH yeah would love to add some points on the connectivity front I think a lot of people like don't understand like where we stand in the space and like what we're focused on our primary focus is on what we described here like trying to imagine this world where you have like low

latency interactions uh like high density interactions across like clusters of rollups that are deployed to like specific regions and these rollups are like imagine like immense scales these like 1 million TPS they uh you know they do like are producing blocks every millisecond or even potentially even faster than that like basically trying to support these real-time applications and really trying to like think in that mental model of how can we take that cost that 357 million times uh more cost of sending a packet really get that closer down to uh like a small multiple um and and and like this kind of would be a big unlock for for this space and because of this architecture

we're very focused on rollups very very focused on rollups on ethereum we have number of Innovations in the I would say like on the safety front of how we conduct cross chain interactions um that are very interesting we're actually um I'm working on and we'll soon release a rollup Improvement proposal uh around this concept of cross rollup contingent transa transactions this is uh a specification for how to conduct cross L2 communication based on a shared understanding of the mutual L1 history across these rollups so where the contingency comes in it's on the L1 State itself so it's trying to establish

some safety in variants for uh what's safe communication what isn't safe communication how do I conduct safe communication and we're trying to like push for like industrywide adoption um of these Concepts and these security and safety Primitives epic and and so you imagine that uh rollups will implement this um and then when we're doing some cross rollup transactions uh then we'll have a more consistent process for reading the L1 State and conducting those transactions across rollups yeah so the requirement of the rollup side is for them to track their L1 origin or their L1 history and the requirement on the interal protocol

side is to perform contingency checks uh around this shared L1 history across rollups wow so you're not one of the you're you're very much in the async camp for interop yeah I'm very in the in the very much in the async camp just because like I feel like having like worked in like web 2 and seen the amount of scale or just the sheer amount of Hardware it takes to like run these types of businesses um I I just can't imagine putting all that on a single computer like it just like it doesn't like like people say oh yeah I can just you know up the hardware I'm like you have to realize like these companies run uh for each database system they have every single one of

these database nodes is on maxed out hardware and there's like hundreds of database nodes thousands of database nodes many different clusters of these nodes just to support one team and it's like it's it's it's it's a ridiculous amount of Hardware already so like it's just like how do we on a single like reduce all that to to a single like max out Hardware node like it just like doesn't um doesn't make sense me you just can't compress the amount of data that much yeah yeah exactly exactly fascinating um cool man I mean is there I I feel like you know we've had plenty of conversations and I I all of these interop Pro providers are just

continuing to like dive deeper and deeper into different solutions and I think you know a lot of this there is a very common goal um and everyone's approaching this this problem from a few different angles and so appreciate you guys kind of taking like this ult scale uh uh approach to it um and I think it I think it is different from a couple of these other uh interrupt providers but uh you guys have a a very vibrant Vision um that I I hope to see play out yeah I mean I'm like I very much want to see this play out because I think if if this doesn't play out then it means that the web 3 as a whole probably is going to be stuck with like a subset of applications

and not be able to service like this like much larger like grander vision of like bring the whole world on chain that a lot of people talk about yeah yep awesome well thanks for coming on it's a pleasure as always uh where can the people uh find you maybe on the last slide we'll we'll okay I'll go back to the last slide there we go yeah yeah just find me at zerox Shake on Twitter and then uh our organization Twitter is at polymer laabs and our website is up there as well awesome thanks B awesome nice