The Rollapp Stacks | Sovereign Labs, Slush
21 Feb 2023 · 49:12
Kalman Lajko and Preston Evans lay out competing theses for the optimal rollapp tech stack on Bell Curve, comparing their Slush and Sovereign Labs approaches to rollup infrastructure. They discuss how developers choose between the two designs, how rollapp infrastructure projects can monetize, whether the market tends toward a winner-take-all outcome, and what it takes to attract developers through tooling and business development.
Speakers
Topics
Transcript
all right everyone welcome back to another episode of bell curve before we jump in quick disclaimer the views expressed by my co-hosts today are their personal views and they do not represent the views of any organization with which the co-hosts are associated with uh nothing in the episode is construed or relied upon as Financial technical tax legal or other advice you know the deal now let's jump into the episode the internet of Roll-Ups is this idea that in the same way that cosmos had this vision for an ecosystem of blockchains where each one was Sovereign could make its own rules and control its own destiny and that would allow for much faster innovation in l1s we want to see the same thing applied to Roll-Ups
all right buddy welcome back good to see you this is gonna be a good one we've got um Preston uh who is one of the co-founders at Sovereign labs and and Coleman who's one of the co-founders at uh slush SDK uh you want to give a couple words about why we've invited these two guys on so you know all season we've been you know kind of teasing out the benefits of a full stack app Chain versus sorry on the other end of the spectrum an app specific roll-up you know even an L3 and in the middle you've got Celestia you know this modular approach and Sovereign Labs which is leveraging that to to let applications build you know Sovereign app specific Roll-Ups um that that really handle more of the stack
um or as close as possible to a full stack app chain as we've seen yet so I think you know we have within this family of app specific Roll-Ups builders that either end of the spectrum um and I think today we just want to talk about you know what they think about what goes into a minimum viable stack for for applications um you know what are some of the network effects associated with sdks um that that has let the cosmos SDK be successful how do they plan to replicate that from an adoption standpoint and uh yeah really excited to dig into it with them all right let's Jump Right In all right everyone welcome back to another bell curve uh you're joined by uh bile tonight
um and today we've got Preston from soften labs and Common from slash SDK so this is probably going to be another relatively technical episode so I think maybe we can start kind of high level and then drill down uh you know miles and I have really been trying to explore this kind of um Spectrum right where you've got sort of the full stack software and blockchain kind of pioneered by the cosmos ecosystem on the left and then on the right you've kind of got a uh you know a roll app type environment that settles down to ethereum and then we've kind of got the middle which is going to be represented here by uh Sovereign Labs um so Preston maybe I could kind of kick it over to you I know you sort of have a vision for kind of the the uh internet of Roll-Ups
uh so to speak so maybe you could just sort of give us the high level on uh your vision and kind of Direction at Sovereign Labs uh and then you know it's as much as you want to drill down into the specifics of sort of the what and why that'd be uh super appreciated the internet of Roll-Ups is this idea that in the same way that cosmos had this vision for an ecosystem of blockchains where each one was Sovereign could make its own rules and control its own destiny and that would allow for much faster innovation in l1s we want to see the same thing applied to roll-ups so a roll-up is just a blockchain right it's a blockchain that outsources some of its security to another chain and the big advantage of having a roll-up as opposed to a later one blockchain is that you don't have to pay
the capital costs of recruiting a validator set to do work for you um so there's only room for a few l1s in the world because each one of them needs billions or more of dollars in security budget and realistically like nobody wants to spend that much money to secure you know whatever a chain that only trades a few Niche nfts or something like that but we do think that you know bottom-up Innovation is where much of the the good work comes from and so you need a vehicle to allow that so the internet of Roll-Ups is this idea that you should have Roll-Ups which are able to communicate with each other in the same way that Cosmos chains are able to communicate um but without sort of relying on each one of them having their own valiator set to facilitate that so what we're
building at Sovereign is this tool called The Sovereign SDK which is inspired in many ways by the cosmos SDK but trying to improve it and Target application specific roll-ups so the core thesis is that these roles should be efficient and they should be able to communicate seamlessly and the way to do that is by using zero knowledge proofs to let them talk to each other in a way that's trust minimized that's great I appreciate you kind of laying out the uh the broad Vision there um and you know I'd love to sort of dig into the different flavors of Roll-Ups now um you know you you're talk you know totally understand the thesis here you're trying to basically give all the benefits of a full stack app chain or as many as possible without the Pains of spinning up you know your own validator
set and and really the security concerns around that as well um and so maybe I'll kick it to Calvin here just to understand exactly where you're building on this spectrum of Roll-Ups um you know as I think about it three big buckets you have Smart contract Roll-Ups you have l3s that are built on settlement Roll-Ups uh and then you have Sovereign Roll-Ups um much more like this offered SDK um so Coleman yeah I would love to hear a little bit more about uh where slush feel you know falls on that Spectrum um what do you think the different trade-offs are you know as you're as you're from the perspective of the Builder looking at these three options so we're built building alfreeze uh slush currently focus on the stock net
and the ebm systems uh the way we see it is uh sovereignty is great but interoperability is more important and for interoperability uh being able to bridge to and from trusted sleep between the l3s state proof Bridges will be the most important most important component and for this having the same virtual machine and the same circuits is essential and inside the given ecosystem you will be able to trustlessly break between the different alfrees and the different alphys can all settle onto the same L2 and this makes them ultimately all rely
on the same L1 security but the fact that they are settling on dl2 means that they are all secured that they can they can quickly settle on to the L2 and bridge between each other very quickly so it's basically you get the level of interoperability of Cosmos chains right with some sort of like iron bridging capability but within the same ecosystem of that you know L2 everything settles to yeah so maximum maximum security basically got it got it and then press it how how are you thinking or how would you compare that approach to to what Sovereign is building um uh how do you think about
interoperability if you're making trade-off to own your own settlement yeah so our view here is that there's actually no trade-off and so there's this really interesting set of results that shows that basically bridging between two separate blockchains is a fundamentally difficult thing to do so something like Cosmos you sort of necessarily have fragmented liquidity and anytime you want to bridge across two different chains you're in a bad place right you're trusting both validator sets and if one of them is unreliable then you can lose your money um so it's risky for example to bridge from the cosmos Hub to some new IBC chain that nobody's really used before that's not true for Roll-Ups so with Roll-Ups bridging is fundamentally easy in the same way that making a
cross-contract call ethereum is fundamentally easy um so at Sovereign you take full advantage of this and basically the most important property to remember is that we're all on the same d a layer so you all have the same consensus and that means there's no way for one chain to roll back without the chains rolling back together so if you want to send a message from you know roll up a to roll up B you can be sure that either that message got sent and delivered or it never got sent but there's no middle state where it got sent on one chain but not received on the other job um so at Sovereign between Roll-Ups without having to go through a shared settlement later and the big advantage of that is that we can
support platforms that don't have Smart contracts so if you want to build an L3 you need some sort of L2 smart contract in the middle which can sort of pass the messages between chains and verify State routes and that sort of thing in our construction you don't need that at all so we can run on a platform like eigenda or like Celestia that doesn't have any scripting capability whatsoever and we can still build Bridges between Roll-Ups that are completely trustless that's fascinating I mean it's it's too both using zero knowledge proofs but definitely taking a little bit of different approach in terms of you know the amount of flexibility you have um with these different you know Stacks so I guess when you started building what did you what did you have in mind for what we've been calling the minimum viable stack so what are the components
that go into the minimum viable stack and how do you really package them in the best way for developers you know balancing ease of use with customizability and configurability yeah it's a really really good question and I don't think we really know the answer yet like there you don't know what the minimum viable thing was until it starts working so at Sovereign we're taking this approach of very iterative iterative development you know we're hoping to come out with a minimum product soon which we expect will probably be too minimal and then we'll just keep adding features until it sort of starts to get traction but at a high level what developers want is they want interoperability and they want some way to not have to roll the whole thing from scratch right so they should be some way
of getting them a full node implementation that they didn't write themselves there should be some way for them to for example get access to cryptographic Primitives like Merkle trees for State commitments like hash functions like digital signatures without them picking all of those things for themselves because those decisions require kind of a lot of expertise um so it's often we're going to roll out a very minimal product in a few months here and then we'll keep on iterating and and getting bigger and bigger and in the fullness of time we hope for it to be much like the cosmos SDK where you can essentially just write a few lines of code and the whole thing works out of the box yeah and in common maybe just to compare that to the slush side you know I think you spoke to the the importance of sharing the same VM
um obviously these will all share the same settlement layer and so I think it you know correct me if I'm wrong it sounds like you're leveraging a couple more building blocks in building the stack you can set you so I understand that Sovereign can settle anywhere that it wants to but you know why would you you can settle on well-established uh layer ones and layer twos which have do have you know very complete virtual machines and this allows you to access very large developer community of a very large liquidity pool and you know most of the current liquidity and developers are on existing uh platforms and if you can allow them to scale then
I think that has bigger implications I have a you know question for for sort of like Coleman like you you have uh you know if you hit the the slash website right like you guys are starting on in kind of the Stark net uh sort of ecosystem but it seems like the intent is to kind of bridge out of just that and build a more general purpose kind of SDK uh press you you started from a very different angle right and it's kind of plug and play across a whole bunch of different ecosystems can can both of you just kind of walk me through from from your perspective what was the decision to start a little bit more specific culminant in your case versus Preston it seems like you've taken a broader approach so for us we really wanted to you know serve existing developers
provide decentralization then and we didn't truly know how the ZK EVMS have come along uh so we started on with stock net which you know was has been running for more than a year and now that the ZK EVMS are coming along and being open sourced we are also focusing on those and here are the focus is to you know really easily spin up new nodes uh new Roll-Ups make them decentralized allow existing um applications to move and you know to allow existing users to bridge their funds from L1 or tl2 to the new outfits cool yeah and then on our side we started from the very first principles approach so we asked ourselves the
question you know what do we think blockchains are going to look like in 100 years and the answer that I was really hoping to get to was like we'll have some perfect version of ethereum or a smart contract platform which scales with the number of users so when you add 100 more users you also get you know more capacity that matches those new users basically everybody can process their own data and yet we all have a shared view of it so that was the end goal well it turns out that's like fundamentally impossible to do if you're actually executing transactions because executing transactions is something that inherently has to be done by everybody but it is possible if all you're doing is putting data in order because you can make cryptographic commitments to the data that are sort of much lighter than
the actual data itself and then you can use data availability sampling to make sure that sort of everybody can retrieve the data when they need it so you can you can build what we call hyperscale data availability systems this was pioneered by the good folks over at eigenlayer they came up with a lot of these ideas and also Celestia um so what we wanted to do was we wanted to figure out how do you turn a hyperscale data system into a blockchain that supports every imaginable use case because you can share security if you're using this hyperscale VA across a bunch of different logical State translation functions so different ways of processing transactions so so for example in theory you could build ethereum and near and Solana all on top
of this shared da layer and in some sense they would inherit the same security so in order to support that you have to design for an environment where all you get is data you don't have access to these Primitives like smart contracts but then as a consequence of doing that you get to find all these other magical properties so suddenly in the process of Designing this sort of hyperscale system we just stumbled into the fact that suddenly you could Bridge across these Roll-Ups in a native way um with that sort of being blocked and you get other nice properties like um if you're in an L3 on top of an L2 when the L2 gets congested your fees go up as well but if you're Sovereign and you're not relying on someone else from settlement then your fees are very predictable
because all they depend on is the capacity of the underlying da layer which is extremely extremely large right da layers can hyperscale so that's sort of how we arrive where we're at today so you know actually ethereum will have plans so for the first principles approach is great but the ethereum community will have plans you know integrate da the da layer into ethereum itself and they will also have plans for but you know and this is all being currently 400 on how to integrate this hyper scaling which is not possible with the current I agree with the current layer one layer two layer free ecosystem but they also have plans of figuring this out and I think this will also be done there just
to you know focusing on the current community and allowing them to scale yeah thanks for raising that so we're big fans of ethereum uh my co-founder Jam was an ethereum quartet for a long time and you're totally right they are adding sort of more scalable data availability the problem is that the data availability will scale much beyond the smart contract support so while you have lots of data you have very limited capacity for the L1 operations that we needed to to check that data availability and that's again fundamentally fundamentally impossible to scale at least with the current technology that we're aware of I'd like to kind of get back to this idea of uh because miles has sort of asked about um you know this idea of like a minimum viable stack and maybe we'll wait a little bit into the realm of uh speculation you're pressing
because I agree with that answer we don't necessarily know right now but even if we just had to do like kind of high level Frameworks I think there are so few sdks that have kind of like escape velocity and a lot of people probably listening to the show be familiar with the cosmos SDK and the sort of framework that you're in is like how do I build a sovereign type blockchain so you have like uh you know tendermint and IBC and that sort of thing I'd be very curious um and maybe uh common I could sort of Kick this to you first as someone in the you know ethereum ecosystem or the starkman ecosystem like there's very different design criteria I would guess right so like what are like what are the different um needs for someone who's building kind of on on the Stark net layer as opposed
to maybe some of the design principles that went into the cosmos SDK like what are the core differences do you think so in the ethereum ecosystem it's much more focused on security and you know the three main design choices are some people need decentralization the most other applications need cheap data availability and the first third choices you know past bridging between the different uh Roll-Ups and you know maybe games or an nft roll ups only their own data availability Solutions so that they can really host a lot of data there D5 applications were going for they will need a lot of decentralization and for applications where composability
is needed and they will need really fast bridging got it so uh like kind of walk us through like what what does that actually um sort of like if you had to prioritize I guess across those those three needs but then and then how does that actually you know end up looking in sort of SDK form like take us through to like the need to what actually uh is going to wind up in there okay so so you want to launch your application you've been running what's for on a layer of two for some time and you know you're Gathering users but you know you have two more throughputs too much latency you can launch for example if you're a D5 act you can launch a decentralized L3 or you can make it
centralized so there's a single sequencer and Groover if you have a single sequencer and Uber it makes the latency much smaller because you can confirm to your users that the application that the transaction has been accepted much earlier and also settlement can be much faster or you can have a decentralized solution in which case you know it's more expensive it's more slow but it's also more secure so it's more it has more security when it comes to liveness every rule up is secure because it's all secure fundamentally by layer one uh and it's more decentralized and then you know you can have uh the d8 it's another
question for some roll-offs we'll need to store all the data on layer one other Roll-Ups which will you know technically not roll ups but validiums or zika Porters or uh can store some of their data in different solutions this can be sourced stored by either the the centralized uh or decentralized validators of the network or they can also settle this to an external data over to layer like again later Celestia Etc and uh they will also be able to specify you know how often they want to
settle on to the L2 this also changes the speed of bridging because you can also only bridge between different layer freeze once you've settled on GL2 but it increases your prices because more settlement means more prices I mean one one thing you said that struck me I think um is the the position of the app developer who is you know going to move to slush and right you said that okay maybe they're on a general purpose L2 and they are you know need more throughput uh they need you know more customization something like that and so it kind of leads me to think you know who who do you who who do you think you're building for are you when you think about your own go to market
adoption are you thinking about the existing applications that you're trying to basically recruit over to your stack and you want to build in ways that are flexible enough to accommodate those existing you know VMS or other parts of their application so it's more frictionless to migrate over or are you really thinking about you know a new class of applications that have have not been built yet but you're building for what you think they will move um how do you strike that balance so you know there's a huge amount of innovation going on in all of the ecosystem from account abstractions to you know wallets to waltz and you know we on the infrastructure layer I don't think we
are capable of anticipating all the needs and you know of the different applications so what we can do is we can only provide the most General thing that anything can be built on and this is you know a fully fledged virtual machine either you know an evm started virtual machine but basically any virtual machine and then the different app developers can choose for themselves what they want to how what kind of accounts abstraction contracts they want to deploy there um they can they will be able to choose basically everything on top of that but the basic infrastructure will have to be the same so that you know it's um
so that it's bridgeable and so that it's extendable no it makes makes a lot of sense um and I think you know Preston correct me if I'm wrong but I think you're building with a little bit more flexibility in mind um maybe something that feels a little bit more like the cosmos SDK stack where you know you're actually can build features into the chain itself since you own settlement and so maybe just to kind of uh come on you know contrast that with with the slush approach that would be that'd be great yeah absolutely so we absolutely do want to support sort of traditional VMS like the evm or like move or uh like Solana's z-level runtime but there are a lot of applications that you just can't express
in that Paradigm so for example if you want to build an automated Market maker or a Decks that processes things at a batch level so everybody gets the same price within a block there's fundamentally no way to do that inside of the evm because you need a hook at the end of the block that you can invoke to settle all these transactions at once um and that's not uncommon there are many many things for what you would want sort of VM support and you fundamentally just can't do that on top of an existing VM and you know we take the same approach as common we don't think we can anticipate what all of those things are right we think that's something that app developers will have to make up as they go along and many of those haven't even been invented yet so we want to support
existing VMS but we want to be flexible enough to allow people to create brand new VMS and also to do things which don't require a virtual machine so for example if all you're doing is building a decks you actually don't want to have all the complexity of you know having pre-compiles to to verify for example BLS signatures like ethereum does because you pay for all of those things in several ways in security budget in runtime costs all those sorts of things so we take an approach much like the cosmos SDK we try to be flexible enough to support general purpose virtual machines but not really to push developers into that Paradigm and a lot of what we spend our effort on is building the little modules that you would need to plug together in order to
make a very standard like Dex chain I think osmosis or Duality um or the pieces that you would need to build um you know an nft chain those sorts of things so when you have different virtual machines and different uh you know State trees how can you how can you bridge between them securely yeah it's a really really good question so there's two pieces of the stack one is the zero knowledge proofs um so we only support a certain subset of the Urology proving systems which are essentially turning complete and if you're in that subset of proof systems then you have this awesome property that you can take two separate proofs and you can create a new proof that says you verified the two original proofs so
using this recursive technique you can compress 10 or 100 or a thousand proofs down into a single proof which is just as fast to verify as the original was so as a roll-up what that means is you can be chugging along processing your own transaction and then somebody off chain can create a proof that says hey roll up B is currently in this state and roll up C is currently in this state and whenever you want you can check that proof and that allows you to get a view into what their current state is so all you need to do is essentially add a smart contract which understands what it means that they're in a particular state so so for example let's say that I have locked some tokens on chain B on chain a you need to verify okay has Preston really locked the tokens and
does that mean that those tokens are intended to bridge to chain a so should I meet them over here so you need a little smart contract to do interpretation and then a powerful enough zero knowledge proof system um so one of the things that we focus on is trying to enable different proof systems which support very different operations to talk with one another and there's there's lots of like hairy cryptographic details we could get into but essentially all you need is a proof system and a interpreter smart contract and you can Bridge from any kind of change how do you make sure if you have different uh virtual machines architecture how do you make sure that the thing that they are claiming to do is what they are actually doing because you know if you have two different smart contracts because there are two
different virtual Machines of both erc20s let's say or the equivalent how do you make sure that they cannot you know somehow mint 100 new tokens and send those out of Filipino yeah so you're asking like what if you have a bridge to a malicious roll-up yes is that is that the question yeah exactly um so it's the same answer as in any bridging system like if the other chain is malicious then they can they're oh we enforce it that they follow their own rules not that they're good rules um that's fundamentally the trade-off you make when you're bridging between entity so that's why we think that you know on the system level you have to stick first to a trusted virtual machine which will have to be a standard and that's you know well uh probably the
evm which is you know adjusted virtual machine and then on top of those you can put any proof inside the evm you can handle any proof uh which you know your decks your amm whatever you can design any virtual any virtual machine on for that you can prove it you can settle it inside your in a sense a shell evm and then this evm can Bridge inside the ecosystem so you know that's how we imagine security and extendability for other virtual machines and other approver systems in a sense got it so I think the thing that you're missing there is that these faults are not contagious so let's say as role at B you're connected to 12 other Roll-Ups and one of them is malicious
users who aren't bridging their tokens onto the malicious chain have no risk from that malicious Bridge so as a user if you bridge to a chain that says like hey burn all my funds like yeah you lost your funds because you talked to a malicious smart contract that's the same risk you have on the evm um so Cosmos already does this exact same thing and it works extremely well so okay so then maybe what we will have is that in our system any two roll-ups so all of them can easily interoperate and you know bridging between any two ropes will be super simple so in our case it will actually be contagious I I just want to uh you know kind of move the conversation a little bit uh more towards like one question that that I have frankly is like uh as a as a more
non-technical founder here is I try to wrap my mind around like what is a traditionally understandable uh business model right so I very much understand kind of uh what you guys are both providing like the service but I'd be very curious to understand maybe I can just ask this question both you guys like what are your kind of Core Business challenges like when you guys are going to bed at night like what are you sort of thinking about like man if I could just get like these two things then like I'd be feeling much better than I'm feeling right now um and then if you could like anything that you could describe around like the business model here and how you guys actually monetize I think that kind of makes things uh I just be very curious about how that works so for us uh we you
know in a decentralized ecosystem it's very hard to monetize anything because you know everything should be open source everything should be forkable and you know you can run your own system so for decentralized chains it will be much harder to monetize but we think that a lot of change will not need to be decentralized and will need uh centralization and uh added speed that this guarantees and for them we will be able to guarantee a platform that helps them with this yeah I completely agree with what common said you know we we really believe in open source everything's you know Apache licensed and you can freely Fork it and change anything you want which makes it very difficult for us to monetize directly so
our stuff is free and open source and kind of always will be so the way to make money then is to is to do things like offer premium support in the way that red hat does or include a finder's reward in the default token implementation and just tell people like hey if you don't like it you can easily Fork it out here's the code here's how you do it but if you like the product consider supporting us and developing it um and then the last idea is that all of these ZK Roll-Ups need like proving services and they need some relay nodes to talk back and forth so you can have an aws-ish business where you you know stand up all that infrastructure for people so that as a developer you just write your business logic and click a button and the rest of the chain
magically appears so so there's a big space of potential monetization here but frankly you know we want to have a working product before we worry too much about that I think that makes sense and um you know how do you think again a little bit of a non-technical question but you know we think a lot about end-state Market structure um and how do you think that you know the end State Market structure of roll up or I would say app chain Stacks will look look like how powerful are some of the network effects around interoperability standards you know we just shared VMS that that could you know result in a winner take all our winner take most and then what what what factors would would cause you know an end-state Market
structure to look like a lot more fragmented yeah it's a really good question comment free feel free to jump in here if you have any thoughts um I guess it's it's pretty early for us to say anything for sure you know in general we expect to see Power laws pretty much everywhere so 80 of change will probably be on one or two common standards think like Cosmos SDK and substrate today you know there are other options but everybody's on one of those too but at the same time there are lots of things that you might want to do which are more flexible so for example there's penumbra today who's building a fantastic chain and they use a lot of ideas from Cosmos but they don't use the cosmos SDK we expect there will be chains like that forever as well yeah so as we see it uh for any kind of similar
chain like penumbra or you know kind of separating with a separate virtual machine you're able to be able to prove that and settle its onto to a very standard virtual machine and the benefit of having the standard virtual machine is a is the interoperability between all of them and I think this is very crucial which if I then understood correctly you will not have Preston so this interoperability will also mean very strong Network effects inside that ecosystem and um that's how that's why I think that you know this is unfortunate you know diversity is great but unfortunately this is a video takes all situation does
remind me a little bit you know in hearing about the differences in your approaches to interoperability um you know comment on one side you know I think everybody like sharing the same settlement layer with having the same VM right this sounds begins to sound a little bit more like the original kind of L1 race where you're recruiting as many apps as possible to be under this umbrella of shared properties right um whereas I think you know Sovereign labs and Preston's approach sounds a little bit more like uh IBC right where you retain uh much more sovereignty and in customization of your stack um but you know you are kind of at the whim of who you uh you know agree to
connect with vibc um you know at at any point I mean the risk is isolated right to each individual connection but it is that a fair approach to say that you know it may be one difference is that Preston this is a little bit more of a Bottoms Up heterogeneous you know ecosystem versus common this is you know looking at to be kind of a little bit more like a more scalable version of what's on a a general purpose L1 chain except each application has its own rollout I do think that heterogeneity is possible in the actual virtual machine you will just need to know a thin uh thin standard virtual machine to cover it and
I think this allows The Best of Both Worlds the seamless Center of ability and the customization that you want so I do think that you are compatible yeah great we love to see bottom-up Innovation um from our perspective yeah yeah we want to be very bottom up um the one thing I would maybe correct is I I probably explained this poorly earlier but when you connect to a different chain you don't accept any risk from that chain only the people who Bridge their assets to that chain except risk right so it's the same way that like someone displaying deploying a smart contract on ethereum doesn't have any risk for ethereum but if you as a user send your money to the smart contract then like of course it can burn your money same thing with the chain here so in our ecosystem even if you bridge your
money to that chain you will not face any risks because each token standard will be the same and there will be no risk but if you send your money to a Smart contract you can lose it right just like you can oh yeah so really are equivalent to Smart contracts okay that's a good way to think of it yeah I I guess I would I would just be curious um you know for for the two of you right like the the challenge I would I would guess like kind of looking from the outside right is getting uh application developers to to build stuff right leveraging your leveraging your SDK like just talk to me from even like a BD standpoint I know we're in a bear market right now so it's kind of head down and building and uh you know shipping code kind of mode uh
but there's definitely like a BD component to both your businesses as well so I'd be curious like what um what's your kind of strategy for going out there and recruiting application developers what are some of the value props and messages that that resonate with them sure I'm happy to start us off here um yeah so we're very early so it's it's pretty early to be thinking about BD too heavily right you got to build a product that users love and then and then you can worry about BD a bit uh but we've actually been pretty surprised by the volume of inbound communication that we've got a lot of people are pretty desperate to have any way at all to build a ZK roll-up that lets them control sort of the details of how that actually looks in practice um so we can't announce anything yet but
we've had some teams that are pretty anxious to build demo applications with us to sort of get a sense of what this will look like um and then you know we think we think the demand for Block space will continue to grow as it gets cheaper so certainly there is some work to be done recruiting existing apps to come over to more scalable architectures but we think 90 of demand will come from from newly entrants to the space who we probably can't even imagine their applications yet because blocks are just too expensive right now yeah and for us you know I think I think there's just a huge amount for cheap transactions and cheap uh block space and uh yeah app developers just really want to run their own chain so that it's cheap for
the users and that so that they can also it also serves the app monetization issue a bit because if you're an application developer that's running their own chain then you can also collect revenue for that and you know even the code can be open source and forkable but you can still get Revenue unlike pure protocols that are already here and then you know kind of going off of the the adoption standpoint you know you're building tools that you hope developers will love and that are easy to to use um and then once they build the applications you know you need to make it as frictionless as possible for users to come over and for service providers to start servicing the team what do you think you know what are what are kind of
your top priorities in terms of the infrastructure required for user onboarding you know developer tooling things like block explorers how how important are these that you know you know these kind of details that that you may not think about but um you know we're trying to build a mature ecosystem right at some point so how do you think about you know prioritizing those pieces of infrastructure in the sequence of they come in so for us you know they are already Giants in this industry so it's not really worth it to reinvent the bill uh what we are focusing on is backwards compatibility you know making sure that existing tools and existing infrastructures work yeah and for us we're starting a brand new ecosystem
from scratch so there's there's nothing there yet so there's there's a lot a lot of work to do um so a lot of our focus is on sort of making sensible design decisions we have the benefit of having had a lot of people come before us um so you know for example we can bake in account abstractions from day one and allow things like social recovery wallets and those sorts of things but frankly we're still in the early stages of thinking about wallet designs and those sorts of things and we probably won't have anything ready to announce as a spec or anything like that for quite some time all right guys um well you know miles I think we we got through a bunch of the the sort of burning questions that that we had for the two of you and it's been a fascinating conversation I guess if if
you want to leave uh listeners with a couple words about either your ecosystem or what you're trying to do or something you're you know particularly excited about at either one of your projects I think that'd be a great way to bookend the conversation follow us on Twitter slush .dev it's our website short and simple I like it yeah um it's Sovereign we think scaling should be really simple and we're excited to build an open way we'd love to have anybody come contribute share your Visions with us let's build a better future together great parting words uh all right guys this has been a ton of fun thank you for your time um we'll have to do another uh conversation like this soon cheers great episode um what'd you think yeah I thought that
was great um you know we got a two uh projects on I would say opposite ends of the spectrum within this family of of app specific Roll-Ups um you know air Preston talk about what they're building at Sovereign Labs it sounds a lot more like the cosmos approach with the full stack um full stack app chains in terms of what it's trying to you know in terms of its primary objectives that approach this architecture sounds as close as possible to getting the benefits of a full stack app chain um to me when I hear you know things like being able to batch transactions together when you because you own your
own settlement layer um versus I would say you know the other side of the spectrum with with slush and just in general you know l3s settling to a shared L2 on ethereum you know you you're going to have the benefit of I would say you know users that are already on ethereum from an onboarding standpoint and you're going to be able to basically reuse a lot of components um from these applications that are that are already using you know the same evm um and within that family of l3s you'll have the seamless interoperability but you know they are putting a much higher
priority on on security and so it does not you know allow for some of the customization it would like will likely have you know higher levels of friction to go in between different l3s or you know going from a full stack app chain to an L3 um so very different ends of the spectrum here but both very very valid approaches uh that I think are solved for different things I think one of the one of the challenges uh recurring challenge of this season has just been you know when you sort of ask these guys some some questions about what they're thinking about or what they're building it's just so so early right like even that question I think that you and I were both kind of dying to get answered of what is the the minimum viable stack
look like the the honest truth you know that we'd prefer not to hear is that it's just too darn early to to get to the bottom of that right we we have some ideas right um we know they need some sort of VM on top they need in you know bridging infrastructure to some extent um and we know that they need you know a process to sequence transactions to prove their validity um and you know there there are just so many flavors to to I guess put these different components together um and again we've only seen the SDK Cosmos SDK really in action um and so it's hard hard to evaluate exactly you know which apps might be
suited for which type of Stack just yet yep it was also uh you know the other thing I think that you and I were very curious about is what is that the network effects looks like look like around those those sdks as well and I think there was a little bit of confusion uh you know with with being Cowman on on which uh where the network effects were accruing to that to the SDK or to the actual protocol uh sort of network itself but um yeah I think Preston answered us there that yeah there are significant Network effects for sdks which is what I would have naturally kind of thought made sense exactly and I think you it's a balance of really trying to you know have as many sort of common properties as possible uh between different apps
that use the same stack um and you're balancing that against you know giving those app developers as much customizability as possible um and so you know I think I think Sovereign Labs will will have many different you know flavors of of applications that are using you know different levels of customizability um across that stack and so you know that may lead to some being more interoperable than others um and you know I think but it's all it's all very early I totally agree 100 and I think you know one uh concept that both common oppressant were kind of going back and forth on is this sort of
this recurring challenge or need to balance between sort of building in a place where there's distribution but there might be some amount of kind of uh tactical debt or limitations in terms of what you can build versus kind of going out on your own uh and building something new where you have less restrictions around what you can build that account for but you don't necessarily have the benefit of people existing in one uh on an ecosystem and it'll be very interesting to see you know Founders make that that trade-off uh and it's very hard to know I think at this point who is going to ultimately be successful in that approach I could kind of see it going either way yeah I think you and I are both not Technical and uh maybe maybe that's the reason that we put such a big emphasis on BD
um yeah but I think that's you know uh an underappreciated component here um in that and how strategic you are about uh recruiting applications I mean just out front are you are you building for existing applications and and thus making you know your stack as backwards compatible with their existing applications as possible or are you building for applications that have not you know been developed yet um but you're building you know infrastructure that will allow these applications you know to be really differentiated versus what is a it you know what's out there at the moment um because of the limitations that the existing apps have and it does sound
like you know again server Labs is more building for the latter there for for applications that have not have not been developed yet versus slush is putting a much higher priority on on making you know their SDK backwards compatible with say existing applications that are on ethereum 01 or on Stark net already um and so yeah I think it's I think it's it's interesting to to ask them about those different approaches um because it's very different there's a uh there's a saying that first-time Founders think about product second time Founders think about distribution and uh it's kind of one of those cute little saying but it but it is but it is true you know I mean the it's not to be underestimated the power of BD and and
distribution I think maybe in crypto one slight caveat or addendum to that is what you don't want is for your brand to be about BD you know uh because I think that's a that's a signal to your community that the tech isn't is of second priority um so what you almost want is this this happy medium where your brand is to be very Tech focused uh and developer friendly but you to be you know vicious on the BD kind of low-key you know so that's the the golden ratio of balance for the to the extent that you can get some early adopters and you know at least appear to have a Grassroots approach um and letting those early adopters you know sing your praises and and you know provide that Viral
marketing for you um you know I think I think that's extremely effective um so you know I'd be very curious to talk to these guys a little bit more about you know who are you how are you approaching getting a couple pilot customers um on your stack you know and and what what are the qualities that you want in those pile customers um you know I'm sure this is the case I think it's the case everywhere but uh it's very important and I think in crypto I'm saying this as a Founder who struggled this myself but it's very important to think about brand and um you know you very you want to be very conscious about creating something that people can root for you want to be very conscious that you are positioning
yourself in the market and sometimes positioning yourself the thing that feels very uncomfortable is sometimes positioning feels like you are limiting yourself um and by that you mean I'm going to focus on this one thing I'm going to do it very well I mean they're going to focus within you know this particular ecosystem or I'm going to focus on this one particular use case and most the vast majority of people react super negatively to that because they say well I I could do all of these things why would I limit myself but it's very yeah you know when you're deep in it it's hard to take the perspective of someone else who you need to know you get like an association and you can broaden that Association over time and grow it but brand is a uh you know we had a very technical discussion
but if brand I think is something that bears and and the positioning um standpoint because you know as I would put myself in their shoes it makes things a little bit more approachable by by being um having you know specific Direction with your positioning um and going after either a certain you know sector or going after a certain ecosystem first but at the same time you want to really let demand kind of dictate what your positioning looks like and sometimes you don't know where the demand is going to come from um you know I think we saw this on Solana right they were originally kind of a positioning as as the nicey you know built on blockchains and over time
you know the the demand really came from from the nft and from the the gaming side um you know that's that's where they've now begun to shift their positioning maybe um but you know I think keeping I agree with the with that point where you know by could limit yourself if you're wrong about where the actual demand is going to come from and you need to be nimble enough to Pivot to to you know meet that demand all right miles this has been another fun interview as always I will see you for next week [Music]