Horizontal vs Vertical Scaling Debate

Transcript

welcome back to the rollup today I sat down with Abby zurlo from nil Foundation nil Foundation is focused on a concept called ZK sharding and they believe in this idea of horizontal scalability today we discuss The Primitives of horizontal versus vertical scalability modular scalability versus monolithic scalability and some of the core ideas which Abby believes is the future for scaling ethereum we're big fans of of the ZK work that they're doing and we had a really informational and Technical conversation hope you guys enjoy real quick here's a quick Insight from some of our partners and then we'll Jump Right In [Music]

[Music] [Music] he [Music] welcome back to the rollup today we're

going to talk about some of the scaling Solutions present today and also some interesting mental models for the modular scaling space um as well as for evm rollups uh today we have ai from nil Foundation nil is working on some really cool ZK Tech as well as just general scaling technology um AI welcome to the show man would love to uh learn a bit more about you but first first and foremost welcome bud thanks Andy appreciate you having me excited to be on the rollup love you guys you guys are doing some great work in the space yeah I appreciate you coming on that the Twitter space the other day as well and um positing some some horizontal versus vertical scaling mental models which I think got the people going which we'll

definitely dive into but why don't you tell us a bit about how you got into nil and kind of why why you're passionate about this uh you know this this role in the space yeah oh yeah definitely um and uh hopefully we get the people going a little bit more today you know get some provocative takes maybe um I'm so I'm Obi Zer I'm our chief product officer at nil Foundation uh I joined last fall prior to that I was at Dela digital uh running and helping lead Investments uh part of the deli Adventures team uh just shy of three years and that was an incredible experience but Builder and nil Foundation was you know an

incredible setup for me as a sort of business minded product oriented individual um nil has been around for a long time established in 2018 it's been at The Cutting Edge of ZK research and engineering and just technology broadly uh and uh this year and last year the focus of the company has been on developing nil uh new ethereum L too and that's where I've sort of come in and I'm helping lead a bunch of different things build out a team and we're really stoked about uh rolling some product releases out in the coming months nice and OB real quick before we jump into the tech more of a just like a life

question you uh being a being part of like a venture capitalist um firm you're it's it's very much like speculative oriented research oriented consistently trying to stay ahead of the of the market stay ahead of kind of like the broader crowd uh always open to new things willing to kind of change your your your thesis but then being a builder you kind of almost have to do the same thing day in day out just keep knocking down the wood just putting those Nails in just keep and and staying very consistent like not going to like the shiny objects and and different things and you know I'm just generally curious like how this this change in your life has kind of happened from a career perspective and like what are some of the key differences that you

have noticed um you know from like this more strictly investing speculating to more of building and product focused environment MH yeah great great question I got ask this a bunch you should ask my girlfriend she'll probably say that I'm a lot more stressed and a lot lot less available um but I mean seriously it is like a very different like space to be operating in um I think one of the clearest distinctions for me especially in in a lead product role right at nil Foundation um when you're trying to solve product problems you're essentially thrown like hundreds of different small problems that you need to solve and you need to make uh

decisions that you know can have a multitude of outcomes and there can typically be you know from every problem a number of decisions that you have to make all to shape and craft this sort of Amorphis like product Vision that you have right and and Steve Jobs has like a really good quote about this where you're you're making thousands of decisions to kind of polish out this sphere that you have in your mind um which is totally different from investing right investing you're spending a ton of time consuming and synthesizing information uh you're you have pretty long decision-making Cycles right so um as long as the markets AR like ridiculously hot you know you you

can have a few weeks to really think and research and understand a company or or a piece of technology and then make a pretty binary decision about what it is that you want to do so all in all uh it's a very different experience it's been incredibly fulfill I love it um I you know I don't don't don't regret it at all I love all of my investing friends and and the investing lifestyle uh it's it's great and sometimes I scratch my head why did I do this to myself but uh you know I I wake up every morning just amped to like be work work on the products that we're working on with the team and the engineering talent that we have so I'm super happy yeah yeah we kind of play both roles here as

well and feel the uh feel the feel the tug right like when when we're in a speculative ver in the market as well as over the last six months we've done a ton of angel stuff and so it's it's very it's very uh you know it's very uh methodical and synthesizing your information and and trying to make uh comparative valuations and and and estimates and run numbers and then when when you're you know building the products and and working on the business it's like yeah it's very much like putting out fires and then like constructing systems to not have to put out more fires in the future and it's like a consistent process of like systems and yeah it's it takes two different uh mindsets but yeah I was generally just curious about your path

um now moving towards more of like this rollup conversation I think that the let's just call it the fragmentation problem lay the land we have a ton of rollups in space uh we call I think you guys and you call it State fragmentation effectively we have all these different rollups existing in in parallel with their own rollup State um and we kind of have this state fragmentation problem where users have to still bridge and and there's there's some concerns around the rollup Centric road map really taking shape if we've got all these different execution environments um within the etherum umbrella but it's sometimes it doesn't really feel like it's all under the ethereum umbrella um so let's talk about your perspective on the state

fragmentation problem for evm rollups um and I know that you've just put out a piece about this so yeah would love to learn about your perspective yeah definitely happy to share a little bit more here I think to start there's an important note which whenever you spin up a new chain there is inherently State fragmentation right and because by definition that new chain isn't necessarily shared sharing the same Global state of the other chains within that quote unquote ecosystem um and uh this is just you know this is just baked into the way that blockchains are designed this actually baked into the way that you know databases and distributed systems are designed the the issue that we see with

State fragmentation and how it's playing out in the ethereum ecosystem specifically is that uh we're seeing a PR proliferation of it right and that proliferation is of it is effectively manifesting in the many different um l2s and l3s that do not share some notion of a global state right and the notion of a global State here doesn't necessarily have to be that every rollup is executing and processing over the same state route for example which was um but that they at least can arbitrarily call one another and and so that you have this like unified notion again a unified notion of state and what we've seen is a

ton of rollup companies as I think everybody expected this is you know one of if not the most important market and you know product to be built within the ethereum ecosystem right to scale blockchains yet we've gone kind of off the deep end in that we have now like hundreds of chains and applications are spinning up their own chains left and right and we still have not yet solved for the ability for these chains to arbitrarily communicate with one another and in our view is actually this problem isn't an interoperability problem it's actually a scaling problem in that uh

the more that you can actually scale the rollup itself right or the the L2 itself the less State fragmentation you induce on the ecosystem at Large right and that what we're seeing is app chains are spinning up or applications are spinning up app chains or app specific rollups because current rollups aren't offering the product features that they're looking for which is you know speed um you know avoidance of the tragedy of the commons and congestion fee pricing um Security even at times and to us that's indicative of uh not a desire for you know application to say run all of their

own infrastructure um it's more of just a function of the limitations of current rollups and this is where we think uh we need to kind of revisit some of the mental models about well how do we actually scale blockchains um including not just the L1 but also how do we scale a rollup right what are what are the processes and Frameworks that we can Implement to handle more throughput at lower costs um or reliably lower costs yeah I think a lot of the push back that um we get for from the ethereum perspective is that the L1 is just not fast enough it's not it's not performant enough so is are rollups not

performing enough performing enough from your standard is that due to to ethereum L1 not being performant enough to allow for rollups to scale or is there different reason why uh you know it's from from your perspective it's not an interrupt problem but rather a performance problem yeah I think scaling the L1 helps right and we see that with uh the uh you know blops right that you see immediately a reduction in your fees at the L2 layer because data availability costs are dropping um and so there's work to be done that effectively scales

the L1 that then benefits the l2s right and blobs are actually uh right a a scaling solution for ethereum towards dank sharting right and it's effectively a form of sharding um which is a very tried and true practice for horizontal scalability um now uh for the L2 at the L2 layer right one of the sort of low lifts for l2s is say the paralyzation of a virtual machine and this very directly uh increases the performance and capacity of an L2 right um yet what we've seen is

a lot of kind of naive implementations of the evm right across layer tws and across rollups um we've also haven't seen sort of really good architectural models for at the layer 2 level that allows for horizontal scalability right and that um horizontal scalability gives us the power to Simply add new machines to the system of interest and access many machines the power of many machines at once um while maintaining the ability for say applications to arbitrarily call each other um so uh the yeah the spirit here is like almost like a call to

action for for L2 so you know let you know just simply running a naive implementation of the evm isn't going to cut it anymore right we need to find new ways to offer a product experience for essentially product application product Builders to get the requirements that they need out of a blockchain cool so I think we're in agreement um we've we've invested in a ton of alt VM or next gen VM rollups also are in D layers and kind of generally see this idea of this go of of this path uh my my only concern with with with this situation is we are

pushing for more scalability which I think is is a noble cause we need this to onboard new new users developers really just get this space to Next Level but like at what at what uh rate do we sacrifice some of the censorship resistant properties of using evm or ethereum for da um or just the the the the tried and true methods versus kind of engaging in something like your uh ZK sharding or horizontal scaling or other kind of um for like a better term like uh inser insertions to to create a better system H like like how do you kind of balance this this desire for ux and speed versus like censorship resistance in trying to

build a super resilient system yeah I mean good question and I think so I think this is you know kind of an opinionated question right because there's this like balance and I think you're you're right generally speaking there is this balance between um oftentimes scale and like how censorship resistant you are right or like what are your decentralization guarantees um and but but I think there's also an important very nuanced Point here which that is is actually a constraint that is inherent to the single Machine model of blockchain design in that in blockchain design

historically you have a single machine that is the bottleneck of processing and building blocks onto that blockchain and this means that if you want to increase your scalability you need to increase the requirements of that machine ma or you increase the utilization the hardware utilization that that that that blockchain node is actually being is able to access right and um and eventually what this Trends into is centralization because you're you're increasing you know you hit the limits of what the you know original Hardware requirements are and if you want more scale well you've got to boost your Hardware requirements and this is where

horizontal scaling really shines in that you you can add you can simply add new machines to this this blockchain to the system of interest and you're just Distributing the workload across those those machines um right across those those clusters those shards uh those shards you can be you can run decentralized consensus algorithms over it decentralized you know protocols you can run um you know in our case we also run uh validity proofs and you can get really nice decentralization and censorship resistance properties uh with without um having to make really significant tradeoffs um or

because you don't have to make significant tradeoffs on on the hardware end of things um now when it comes to the like say the role of ethereum right the grandfather the like hands down like like the OG censorship resistant most operationally resilient blockchain in the you know in the world um that plays a critical role and I think how every L2 should be thinking about you know their future right and how does it play even today and that it needs to be the Arbiter of Truth like ethereum needs to have I say a final stamp on what is going on for you to legitimately call yourself an

L2 and you know there's ways to do that right you can have da guarantees and you can have uh say settlement guarantees guarantees that uh you know whatever your proof mechanism is that attests to what's going on on your network can be verified on ethereum um and uh you know the the the trade-offs between them are da are are the largest the line share of costs so if you want low fees then you're probably going to need to find a different da solution um I think we've seen a lot of l2s hesitant to offer this right uh because there is this you know this feeling of well you know da makes

everything like it is is the most important thing for end users the reality is it's not and instead you see users and applications just moving to running like optimums or you know you know optimistic l3s and uh you know validium anyway um and so I think the L2 landscape really needs to like take a hard look at well what is the product experience that we want to give to end users um have really clear values about what are the tradeoffs are willing to make and what are the tradeoffs are not willing to make and then go from there and I feel like it's kind of been opposite and we've kind of left the product

experience side of things a little bit by the wayside um interesting yeah so okay so more vertical scaling more machines brings us to higher cost of Entry higher barriers to entry more centralization uh horizontal scaling just expansion of machines um in in in in a sharding esque environment allows for uh arguably more decentralization and more throughput um and doing all these things under ethereum is like kind of like the ultimate end goal um and such that ethereum as a settlement layer um and even potentially as a data availability layer um is is going to continue and should continue for like

this web three moral compass kind of conversation um and so I generally think that that there's that that there's kind of this idea here that that that we're getting at with with horizontal scaling and what's going on with this with these app chains this kind of modular expansion that we've been talking about quite a bit is that we see we we're seeing a lot of these applications uh go onto their own app chains um and kind of go L2 L3 to in your mind is this vertical scaling not necessarily when it comes like hardware and CK but is this is ethereum scaling vertically or is that a form of horizontal scaling in its own

right yeah it's kind abstract but no no no this this is a great qu I mean yeah this is an awesome question um and I think you're kind of like yeah you're hitting the nail I mean one hting layers on top of like existing systems like that that is not a form of vertical scaling right like vertical vertical scaling and this is a little confusing because you know you're stacking layers right you are kind you are going vertical in the architecture of the blockchain but vertical scaling and and you know vertical scaling is like a technical framework for you know scaling databases and distributed systems and vertical scaling is um like by

definition uh the scaling frame work that increases the power the computational power of a single machine right so in order you know scaling is the ability to handle increasing or growing number of transactions right the only way that you can do that is if you increase your computational resources right every you know the unit of power and you can do that by increasing say the computational resource of a single machine or you can do it by Distributing the workload over many machines and adding new machines right which is horizontal scaling and so um I think this is where like coming to

the the mental models discussion like modular versus monolithic kind of kind of gets a little uh a little iffy in how in its relationship with scalability because for example let's say I have three tasks right now in the world of machines and you know digital machines we can run things in parallel right and so if I have three tasks I can Outsource those three tasks over say three CPU cores on a single machine or I can Outsource those three tasks to three different machines with a single CPU core now the latter is a modular architecture the uh former is a

monolithic architecture now neither of these are more scalable than the other right I still have three computational resources three computational units to to spend if I if I add another machine to the modular scenario I now have four computational units yet I'm still just as module I'm still like a a modular art you know blockchain right um yet I'm now more scalable than the monolithic but let's go back to the mon olic and I had a CPU core now I have four CPU cores right and now my monolithic my monolithic architecture is just as scalable as my modular right so the and this is where I

think the you know the modular monolithic um it serves a great purpose in understanding kind of like flexibility and customization and the freedom right of of what you can do with your modular stat but it doesn't explicitly say things about how you find fundamentally scale the system and so there's this almost other axis that we kind of need to um I think like reckon with which is well then how do you actually scale each of those systems um yeah does that does that follow yeah yeah yeah yeah and so and so in this example where we have all like three or four cores in one machine I think like you hit it on there you hit on it at the

end there like the the the coord differentiator there may not be the difference in scale however you know if you're an application on in this in this kind of Monolithic four core system you're at the mercy of the other cores if you are a an application in your own core or in your own um computer uh system as a standalone um then you know you're more you're more modular in in in the sense of of your sovereignty um but again it just comes down to this to these design choices which which I think are uh yeah it's definitely a blurred line but I I think that you've helped clear it up for sure now how about Cosmos versus ethereum so Cosmos has

these all these app chains is this horizontal scalability versus ethereum rollups being vertical scalability or is this not a good is this not a good model well no I think this is this is a this is a actually totally valid question um and and you're I think you're you're right except for the last piece um I mean Cosmos is I think in spirit and so was polka dot for example right the uh a manifestation of sharting right and that like you have these many chains but uh they are able to arbitrarily communicate with one another through IDC right and so um we have this notion of a global state right because we can arbitrarily

call one another now the other piece that we we didn't discuss when it comes comes to like a a notion of global state that I also think is important to include is uh some some form of like shared consensus right um and in the world of Cosmos the uh you know the ability to use interchange security right from the Hub and uh re reuse the security that is offered from that validator set that's a very true form of sharding in my my view um now ethereum also has like a sharting road map right Bank sharting is going to

be you know one of if not the largest development for ethereum in the you know in the coming years and this is a form of horizontal scalability um and it will bring about significant scale now the one piece where I just want to you know clarify is that you know the rollup rollups are are effectively scaling the the consensus of ethereum right um in that you know now ethereum's consensus is able to validate all of the activity and uh the the blockchain that is of a rollup um given you know the appropriate

da and proof mechanisms um now this isn't strictly a form of vertical scaling right because rollups typically Implement kind of a naive evm um and so we don't see the ability for a rollup to say um you know paraly transaction execution rollups aren't a form of vertical scaling they and in fact okay this is I'm actually maybe going to retra what I what I had said before um and say something maybe a little bit more provocative which is uh rollups aren't a form of scaling all period um and because it doesn't satisfy

the requirements that we would want from scaling which is the ability to arbitrarily call other other state other addresses in this system of interest and when we think about sort of ethereum right we have ethereum ethereum state and ethereum consensus and now we create we spin up a rollup right this rollup has no idea what is what the state of of ethereum is right it is not interacting and cannot arbitrarily call ethereum State it is secured right by ethereum consensus so and this is where I'm explicit about rollups scale the consensus of ethereum but they're not a

scaling solution for ethereum right and this is why we call it like a separate thing this is why it's an L2 right it's not a you know an L1 scaling solution ution now if you if you adopt this framework the um rollups now have the onus of then scaling themselves right in that they can share the same consensus guarantees from ethereum they get that out of the box but then they need to be able to arbitrarily call one another and what we've seen is you're not able to do that um we've also seen that rollups have been hesitant in altering the evm which is coming to the paralyzation

point right of well we can scale a rollup without adding new rollups right we can scale a rollup by simply paralyzing and increasing the hardware utilization that that rollup can access um we can also in the case of nil increase the scalability of a of a single rollup system by introducing horizontal scalability through sharding um Direct into that L2 right and you know in in our view we feel this is in the long term the most scalable um path forward in that we're you're always going to hit limitations if you want a vertically

scale of a single machine and if you ever care about decentralizing you're always going to be inducing some sort of prohibitively expensive lower bound if you want to ch more scale so you need to find a way to distribute workloads across many machines and you know that's kind of the the first principle starting point that we took in designing me yeah so so talk us through a bit bit more about the design of of ZK sharding and how that like how and why ZK is involved um why that design Choice was made and and what does that practical implementation uh potentially look like leading to more

um unification of this General fragmentation problem that we spoke about in the beginning good good question um and I'm gonna start with maybe an obvious Point um and a little bit of an ironic one which is we want to solve stay fragmentation by building another L2 right and it's like oh well great like technically speaking that is just another you know for of State fragmentation um the difference is is we believe and we actually are are really large supporters of of everybody else who's building more scalable l2s so you don't have that that second order effect

where an application wants to come build their app but they you know are afraid that they're not going to be able to get the product requirements that they want out of your L2 so they spin up their own one right um so uh what is nil right nil is a a sharded rollup a sharded L2 that pretty much brings a lot of the work and ideas from ethereum's original sharding Vision to a layer two and what that does is it allows us to essentially access the power of thousands of machines from a single unified Network so we get thousands of rollups right that a

developer can essentially access from one sing interface an integrated developer experience we also are decentralized right we're designed to be decentralized so it's not only that you're getting access to thousands of say rollups you're getting access to thousands of decentralized rollups and in our case because we are a true sharding protocol those are called shards and inside of the protocol there's baked in communication between each of those shards and we have several layers of essentially security of decentralization and censorship resistance the first layer is every Shard is assigned a

committee of validators right and you could think of this almost in a way analogous to like you know a shared sequencer set right um or a committee of validators from a Cosmos app chain right they're running some form of a fast bft consensus and they're agreeing on what is the a block a block every second now every n number of blocks those that committee is generating a validity proof that the last n number of blocks were executed and built correctly all shards do this and all shards uh send their validity proof to a main Shard where

they recursively verified and sent and batched down to ethereum for the final stage where you get guarantees and settlement of the entire nil Network on ethereum okay great so I understand the the the mechanism of of of why ZK is is present how the sharding works with your um validity proofs and also kind of how this works to unify different rollups and I think they they make a really good point as well like we shouldn't just build more of the same optimistic rollup using evm and then even just throw like a data availability layer under it like Celestia or a veil and call it a general

purpose L2 like sure like maybe you you can get some very domain specific users on that or like an Enterprise chain or something but even still those are like we should just keep striving to improve the scalability so I think that we're on the same page there um kind of coming back to one one of the original questions that I had was uh with regards to the tradeoff of decentralization and kind of scalability kind of coming to a similar Point here which is um why what kind of extra trust assumptions do I as a rollup operator for rollup a as well as rollup b c and d have to uh accept in when using nil for scaling and for interoperability with your ZK Tech good

qu good questions okay so well first like we're this this isn't a system that's backwards compatible with existing rollups right you don't the the the it's not designed to say have uh you know an OP stack roll up now just plug in to nil sharded Network um nil is a general purpose blockchain itself right um it is and it's not a compatible solution for say an existing rollup to Simply plug into this sharted architecture and this is frankly I mean this is the uphill battle that we have to we have to go against right that um we are a new general purpose blockchain and we are not looking to you know have

this like you know necessarily like hurah like everybody is going to just plug into everything um we think that is a really like noble noble path like and in any way that we can we want to work in that capacity but we do fundamentally have this view that you should be building general purpose l2s that scale to a sufficient um you know degree such that you unlock all of the product experiences that you get on say salana and I'm an ethereum I don't know if I'm I mean I am an ethereum maximist like we are I mean our entire company is an ethereum maximalist it's just it's just

the culture um but if you look at things like objectively salana has done something really interesting in that it's built a completely self-isolated um and prosperous ecosystem of applications because it's effectively offered the product you know product features that application developers want and sure there's a trade-off that they made in you know how they say you know design their architecture right and they've really gone down far the vertical scaling route and I think that's a very noble cause and that's actually a route that is going to allow them to unlock unique applications like potentially onchain order books right

you need a single you actually need the single machine bottleneck to run those really low latency applications right and they've done they've done a great job at that um but we obviously come from a slightly different camp and we we really do see that there needs to be this Arbiter of truth that is operationally resilient like like fundamentally we want to build a system that is decentralized autonomous runs in perpetuity long you know long after my involvement or anybody else currently at nil foundation's involvement in building and contributing to this network the only way that we can do that and underwrite some of the risk in transferring power

right in these organizations over decade long you know Horizons is to decentralize and to have base layers that we can rely on and that's ethereum and you know right now there's really like no I I really don't think there's any way around I think I think the Bitcoin L2 stuff is interesting but again we we have our opinions yeah sir sir I I appreciate the decentralized harah now what technical trust assumptions does one assume by using nil is is like so I thought I was more so of the opinion like oh if I'm an existing rule up I could plug in but you're saying it's more of like a Grassroots effort where you you guys kind of uh work together with teams to help them

kind of launch within no kind of talk us through this and yeah yeah totally totally so as I mentioned there's there's effectively three layers of like what you can call finality right so um the first layer so we'll actually just zoom out to give you kind of like context for how those finalities actually like emerge nil is a uh there's a global validator set behind nil right nil nil has like a traditional blockchain validator set that validator set is randomly sampled right and assigned to a Shard right and that Shard is essentially like an app chain or like a rollup like I was I was saying earlier and you have this Committee of

validators that are again randomly selected um on a you know every EO and build blocks running so with some sort of bft consensus and we run um you know syn Hot Stuff a multi threshold bft so and that's that's where you get our sort of one second you know finality right every every every block boom you get you get some sort of decentralization guarantee that's includes essentially the entire validator set the selection um at that committee level and then you factor in the random sampling aspect of it right which is one of the yeah yeah sorry is the random sampling

similar to like an Erasure coding like a read and Solomon kind of type of concept or it's slightly different um it's slightly different but I think it's like a similar Spirit um I mean the point is that you um yeah I mean you you randomly select from this this Global set so you um I mean if you were to say just assign say just imagine you have 100 validators if you were just to say well these 10 validators you're always going to be running this sh you have you effectively just have like a a validator set of 10 for that chart right in perpetuity now when you actually start randomly sampling you uh you pretty much increase

your resistance to any sort of 51% attack because it's harder to coordinate between those entities awesome and so you were you you were putting the pieces together of the of the broader Network yeah so then so that's F that's layer one or layer one of a of of finality you might call it um then you have the vality proofs right where every every committee right at every Shard is generating a validity proof for n number of blocks and those validity proofs are they're generated and then they are sent to a main Shard where they're verified now over time we actually we hope that

you know we get real-time validity proofs right people are talking about you know proof generation and there's a lot of really incredible work being done at the hardware level of this um there's also just the state-of-the-art of proof systems has come a really long way and we do think we'll get somewhere close to realtime proof generation but we recognize we are not there yet so while we live in this world where we have delays we opt for the bft consensus right as the first layer of Defense um now uh as things get faster we can actually eventually hopefully get rid of the consensus Al together because we don't need it because we can prove

things in real time um now the validity proof layer it gets verified on uh the main Shard right which is actually run by all validators so you have the entire Global validator set behind this that that layer and then the final layer is ethereum right where ethereum receives one single proof kind of similar to polygon's agair and uh verifies sort of the execution of the entire network sweet sounds bullish I uh I don't have that much time for too many push backs the only one that I'll push back on is what's the validator uh count uh in in on like testet going into live is there

a maximum validator count is there a reasonably decentralized validator count that you guys have have in mind I can't give you I can't give you hard uh numbers for all of them we're targeting for 400 and that's what we've run uh sort of our internal test on uh that's where we got sort of the 60,000 TPS number um but uh you know who who knows we're going to be launching a private test net in this summer and from there we're going to collect really valuable feedback on what what are the things that you know Builders need I mean we we are building you know a decentralized network we are building a blockchain but we really do think of it like a product

and we want to be collecting that product feedback so if folks are interested in learning more H H in the Discord uh hit me up on telegram hit me up on Twitter we're going to be running kind of an exclusive group um where you know people are are testing and we're Gathering product feedback and making alterations um but uh yeah that's all going to happen very soon yeah bullish uh we had just a couple minutes uh last question is there a a point in which adding more validators to a network it has diminishing returns or doesn't really do much like is it 100 200 I've heard you know in this range but curious what you think yeah I mean this is a good question We're not gonna have enough time to talk about it but but

there there obviously are they're trade-offs right um the major trade-off with like sharding in general it's it's complex like it's not it's not like a simple thing to implement um if you want to do it in a decentralized setting it's even more complex right it's it's complex as a just a scaling solution for databases let alone the all the consensus guarantees um there are upper bounds to how many you know validators you add but you could just imagine say with even out like just to give you an intuition even without putting hard numbers on upper bounds if you were to say split every contract onto its own Shard right you may think well oh well now I have a

really scalable system the issue is what if those contracts or addresses want to want to call call between each other what if they want to send transactions between other exactly and this is where um sort of the task on our end for optimizing the sharded architecture comes into play because we can't just split everything because everything will then have an asynchronous call right and everything will be communicating with you know some sort of delay and and also in a different programming Paradigm than the synchronous programing Paradigm um and so we can have synchronous execution inra Shard but when things go outside Shard we either have to you either have

to program in an asynchronous manner or we have to build some sort of emulator schedule or like module similar to what salana has done to try to build off build that synchronicity um but this is I mean I'm not going to sit here and like say like we have that salt we don't have that salt right and this is why you know we're really deed to bring in some some sharp Engineers to like come and let's let's break what we have and you know see how we make it better brings us all the way back to one of the first points is about whether it being an interoperability problem with regards to State fragmentation or a scaling problem and um it's it appears to be a problem unsolved ABY thank you for coming on and

uh best of luck I appreciate your time thanks Andy really appreciate it cheers