hello I'm Zaki I will be your MC for this uh this morning and uh let's kick things off uh first up we have Adrian Brink co-founder of anoma no one knows what the Noma is and I don't think you'll find out in this talk um um but uh Adrian will be talking about shielded data availability all right yes indeed this talk isn't about onoma um if you wanted to find our Nomas you should have listened to Chris's talk yesterday [Music] um if you haven't seen it watch the recording it was a great talk cool I will very briefly today uh could I get a timer up well we'll see how long it takes um cool yes I will talk about chilled data availability on Celestia today or the ability of how we can retrofit privacy guarantees and also forward fit privacy guarantees into existing protocols without needing to make changes to those protocols which as you'll see in a little bit is going to be quite important especially when you start thinking on how do you want to build privacy preserving rollups on a lot of these systems so before I start let me give you very quick chill Dr on what narmada is how it works um and sort of why we need unified privacy sets so Nevada and nutshells it's as agnostic multi-chain privacy um until really no matter at least on The Interchange we didn't have the ability to have asset agnostic privacy privacy was always tied to specific assets right like when you think of what Monero or Z cash do they provide very good privacy guarantees let me scratch this zcash provides very good privacy guarantees um and Monero provides you should do your own research privacy guarantees but they provide them for specific asset types as in in the case of zcash they they have zek and in the case of narrow they have XMR and so users are now forced into this model where for some reason they have to hold or like pay for their milk in a store using zek even though I think most people would much rather use usdt brings it's it effectively adds an extra type or an extra feel to the notes in a zcash-like system to provide a unified shielded set where all assets no matter where they were created or how they were created can live in a unified children set this has the tremendous property that you get low volume but high value assets that inherit the Privacy guarantees of the low value but high volume transfers so for example a very trivial example here is all the usdt private transfers in Armada provide privacy guarantees to your like 100 000 nft and this is really the only way to get privacy guarantees for long tail assets which don't have a lot of inherent volume but due to this you can inherit the Privacy guarantees of sort of the entire Shield set and the other big thing is it means we don't have to keep forcing users into accepting specific assets in order to be private users can bring user generated assets I would assume in most cases it's going to be something like usdt usdc but if people sort of from two years from now want to create a new fancy stable coin that fancy stablecoin can inherit the last three years or sort of shielded set activity and as a result has a much stronger privacy set at launch um the way this works with Armada is that Ramada is a basically a chain it's a sovereign L1 that connects to other systems via IBC site on IBC if you are thinking about building a bridge don't like read how IBC works this mostly solves all your problems Uh custom bridges are terrifying and they're very prone to errors um so with Armada you get permissionless connections to other chains for IBC so in the future if other chains pop up or assets on other chains pop up those assets can also freely flow into nomada and maybe one of the coolest things is we have Shield set rewards in Armada which means that the namara governance unit can effectively incentivize rewards to be paid for holding Assets in the shield set and this is actually very important because most people at the moment treat their sort of privacy as in I want to like have privacy right now for my asset but this is actually really problematic because that means you sort of go from a transparent system into a shielded system and then back out now we have a lot of statistical attacks that you can possibly pull off against this so the much better idea is that you mostly want to hold all your assets in a shielded set all the time and when you want to use them somewhere else that doesn't work with the shielded set then you want to make them transparent and the cool thing with Armada is you get Shields and rewards within the shield set so as in if you hold some eth in the shield set there may be incentives there that get paid out in the shield set in the native asset of namata and just by holding Assets in the shield set Also if anyone here is thinking of building private lending platforms you need the convert circuit that enables Shields at rewards because it's roughly the same idea you have a transparent list of sort of conversion rates for specific asset types and you can then upgrade specific Assets in the shield set for example you can go from like osmo at Epoch one to osmo at Epoch 5 and at the same time when you do this upgrade you claim the rewards for it yes this convert circuit is fully documented if you like cryptography you should check it out um cool now coming to Schiller actions um once you have Assets in the shield set you want to ideally have the ability to interact with the rest of the ecosystem whether this is on the interchain or sort of within other specific l1s from within the shield set right you don't want to have to take out your money from the shields at all the time in order to use let's say a osmosis pool so shielded actions is really the generalized case of how you interact from within the shield set with application logic somewhere else and really this can mean with specific dapps for example on ethereum but this can also mean with specific app chains like Celestia or like osmosis and let me quickly walk you through an example here for osmosis because this is sort of very instructive I think um you hold some Assets in the shielded set you want to make the choice that I don't like the atoms anymore I want to now hold some osmo um traditionally what people would do is they would um personally take the money out of the shield set transfer it over IBC to osmosis swap it on osmosis swap it back right and this is sort of normally they would go to their standard osmosis address and then sort of do the swap there with Armada you can instruct the validator set to do actions on your behalf this is really the right way to think of this you can instruct the Val data set to take some action elsewhere while staying within the shield set so you can construct the factory using an arch proof in Armada it says I would like to swap x4y then the valid data set will take the assets via an IBC method bringing to osmosis on osmosis use the IBC memo to execute the swap the counterpie or the person that executed that swap is the Nevada vowel data set it is not some specific person it is the entire chain sort of wanted to do a specific swap on osmosis that swap gets executed the assets get returned from osmosis via IBC again and they enter the shield set again at which point the user has full control over these those assets again and there are some downsides here which is specifically due to latency if you start thinking like what does this actually mean under the hood this means at least one IBC message which means at least like one or two blocks confirmation on the origin chain as well as one or two blocks confirmation on the sending on the receiving chain so you talk on like maybe 30 seconds so you can see here this is like not instant um if you're on a system that has sort of like one second block times this is it's going to be hard to get the same kind of latency guarantees as soon as you want to hop between multiple chains but the really cool feature now is that you have Shiller tops um and none of these none of the core systems need to actually change what they did osmosis provided Shield swap provided swaps and no matter provided privacy um and but we can start integrating these systems using IBC in order to actually have very complex user flows where we can start in a really modular way combining all these different systems in order to get something that is like from a user perspective much more useful than individual components um let me quickly also walk through the architecture how this actually works um this is sort of the heart of an armada is The multi-asset Shield pool if you're familiar with the sapling circuit on zcash this will look very familiar to you you can really at a high level think we've added an extra identify an extra field to the node types in the sapling circuits in order to have an asset identifier so that all assets can share unified child set what happens in sapling actually is that you can instantiate sapling for other assets rather than Zack but I can identify as an external Observer which soft Shields that you interact with whereas in Armada an external Observer can only see that someone was interacting with the shield set but they don't know what actions were taken this could mean that I transferred this to an address that I control myself this could mean that I transfer the student address at someone else owns this could mean I wanted to execute some shielded swap somewhere else or I want to create I want to submit some data to Celestia in a shielded manner so this is really powerful actually has some abstraction because it can work with arbitrary assets um yes and so the basic idea is that you can sort of go into Armada transparently then go into the shield set do whatever you want to do in the shield set go back out if you want to take your assets back out and then go with wherever you want to go via IBC again um so this is sort of the entire architecture and I will won't go through the entire sort of slide but just to highlight a couple of things here Nevada comes with cubic slashing which actually means that if you should be really careful which validators you select the more uh percent the high percentage of a value I said commits an infraction the higher the sort of the slashing rate Rises exponentially so if you have been slashed on Cosmos for example slashes are constant um if 30 onomata commits a fault um slashes are going to be tremendously high so there's really now an incentive to actually start splitting your delegation across many different valid leaders that run different security models um yes Nevada on the hood just used comment B of T so you get fast finality bft you get all the IBC integration the state machine isn't using a customer SDK it's using uh it's written by hand and rust to implement a bunch of this cryptography um yes and sort of we also have a custom ethereum Bridge mostly because we don't have ABC adapters to Theory mat if anyone in the audience wants to like do cool work please work on integrating IBC into ethereum uh it's not that difficult but it just requires engineering effort in order to get it done and this is also true really like the way the interchange ecosystem or the multi-chain ecosystem is going to work is we should be building IBC adapters for other systems for example there's no reason why something like near or polkadot um or any fast penalty mod on bft wouldn't be able to speak IBC yes now coming to shielded data availability actually work and why is it useful um again the model is roughly the same thing which is a users in the shield set they want to interact with Celestia they want to be able to post some data to Celestia the user has to generate as your knowledge proof ideally on an edge device within Armada this instructs an armada violator set to effectively submit data to Celestia on behalf of that user and again the so the interaction that the world observes is that the Nevada validator said submitted data on Celestia this could mean that there's an individual person this could mean there's sort of 100 people behind it but the world doesn't know um and when you start thinking on like what kind of Roll-Ups you want to be building this is actually becoming incredibly important especially for privacy preserving rollups if you have privacy preserving Roll-Ups where individual users want to be part of this roll up and have to submit data to Celestia it means that in the current model without Shield of data availability they would need to figure out how to safely submit those individual transactions to Celestia without revealing who they are so in the current model even if you had a privacy preserving roll up on Celestia users would need to be incredibly incredibly careful and this is almost impossible to achieve that they can sort of privately pay transparent fees on Celestia um with Amara Celestia doesn't have to worry about this problem anymore and how you like get private fee payments working rather we can say well we have these two systems that each do their unique thing but by combining them you can start submitting using the feature sets of both effectively so whatever feature set Celestia may even offer in the future um using shield.da you can always submit that data privately on Celestia I think there's also an interesting other aspect to this where privacy has a lot of benefits but it also has sort of its complexity and end user because all of a sudden data moves from the center of the network right like when you think of something like ethereum data all lives in this globally distributed globally readable database in a privacy preserving world this data starts moving to the edge devices where individual phones need to hold this data so one big question is are users going to store all this data themselves or are there going to be Services where users can for example offload encrypted nodes too and this is I think sort of a future direction that um I'm not exploring too much in this talk but that is really interesting think about for future research on how can we leverage data availability solutions to provide guarantees to users that they can get back their data for example the encrypted nodes which they will need in order to access their their funds an interesting other research area here is oblivious message passing or how can you query a data source like Celestia in a privacy preserving manner because one of the so in my opinion the most valuable data set most likely in this space is actually in Fiora because everyone has access to all the rights to the chain right like if you scan a theory you will see all historic rights but inferior is like one of the only companies in the world that has access to 99 of all the reads which is the much more difficult to obtain data set in solving the world of blockchains and so with oblivious message passing we can actually start thinking on how do we have reads Against full notes that do not reveal exactly what kind of key in a Merkel tree I'm looking for as in like right now I go to follow and go I would like the value of this key with oblivious message passing you can live in a world where you create a range of keys and it's not clear to the full node exactly which key I wanted to ask for um yes this sort of leads into the modular thesis a little bit on we should be splitting concerns uh not every chain needs to do everything um there's a clear benefit to standardization and specialization um if and only if we have decent interoperability protocols that can actually make this um specialization still composable um so I think we're clearly going to head into this direction and sort of a type of execution settlement consensus and data availability I think we're also going to see more specialized chains around privacy guarantees around um sort of transferability tradability I think we're clearly heading in this direction but this becomes much easier to build for effectively as an engineer because so yeah instead of writing everything like if I think about this in terms of software instead of writing everything as one large monolithic mono repo we start writing individual libraries that individual other systems can start consuming um yes and this is sort of I think one of the last slides privacy is a service um this is namata is going to start providing this where you can use lamada to drive actions on systems that you actually want to use for other reasons but you want to retrofit as a personal choice privacy into those systems for example maybe some people want to trade a lot maybe other people want to use Celestia a lot no matter actually doesn't care Narada just wants to provide really good privacy guarantees for whatever other for whatever users want to do on other systems and I think this is we're going to see this more and more because there are lots of interesting ideas being built and very few people have or very few teams have the amount of cryptography engineering required to make these systems private as in making every system inherently private is a very difficult task because all of a sudden you need to start thinking like how do I build proof of stake fully privately that gets very very complicated it's very interesting when it gets very complicated and so with privacy as a service we can rather say we can build individual applications and individual dapps and we can retrofit privacy into them in a very transparent way for users yes if you'd like there are more resources here Discord Twitter the normal test net um yeah thank you very much [Applause] great job Adrian all right uh next up we have Magnus co-founder of skip uh talking about uh sort of modular user experiences uh and definitely like an increasing trend of people who think about Mev uh now coming around to being able to sort of apply that mindset to improved ux yeah are you taking this yeah hey everybody nice to meet you uh so I'm Magnus um first time public speaking for skip so we'll see how it goes if I crash and burn but uh when I was a kid uh I really like this game Neopets anybody played that before maybe when they were a kid yeah so little game um you know you basically like raise these animals and you did things with them I remember the first time that I tried to play Neopets uh I went home and I just typed in Neopets into my browser and it didn't work right because I missed the www dot and I missed the.com and I was confused I didn't understand like why didn't this thing just work like I went back to my friend I asked like how do you actually put this thing thing into your browser and then once I learned uh I was like okay I guess I just have to do that that's just what you do right in the internet um and then comes a time like later in your life when you understand the internet right you understand TLS and you understand DNS and understand the name servers and how they all route together you probably get a little bit too lost in the sauce so to say like you you understand it maybe too well but the internet still works right there's still that kid who just does that puts it in and everything just happens um understanding it isn't required for uh you know making the internet work um that is to say uh the internet has great ux right you have you don't have to understand it at all for it to actually work and I'm going to transition that into sort of like IBC which I would argue has ux it should be clicking Maybe there we go IBC is ux trust me on it um and I'd say this is sort of the same thing for crypto in general right you really have to understand the tech in order to make it work you have to understand wallets you have to understand the bridging protocol has anybody ever done an IBC transfer by chance and I don't just mean like you know using osmosis which is like easy mode I mean like uh you know sort of like having to put in your channel ID and understand what paths it has to go through and you know basically having to know the underlying protocol in order to actually use it so one of the really really really annoying things about IBC ux is that you have to understand this concept of pathing right so if you want to go from one chain to another chain you uh might not be able to take the most direct route there so for example in this case if you know you want to go from uh Alice's source to Alice's destination you can't go directly there you actually have to unwrap it by going initially through the token origin right and so it's very different than the internet and that you really have to understand the underlying protocol in order to use it properly and it makes sense why it's like this right like you're picking up the security assumptions of each underlying intermediate chain therefore you have to unwind it through those to sort of you know basically have it become the token that it once was so you end up with this situation right where you have all of these IVC genomes all over the place they're all interwoven with each other it's just like look at all those tokens right what are they all doing why are they there I don't need them I don't understand what they are so I love this quote by Chris goes it's uh do you think God stays in heaven because he too lives in fear of what he's created it's obviously not an actual Chris Rose quote um but it is from Spy Kids and that's sometimes how I feel when you know I'm using IBC so we tried to solve this we tried to make basically what that neopets-like experience is for IBC where you don't have to think about you know the www the TLs the DNS the name servers you just use it right you just use IBC in the way that you want to right so this is that same issue right so like starting on chain a you want to go to chain D you every path that you go through basically uh will change the token right it's like you and your friend are basically on the you know Upper East Side you want to go to a bar together I take the 4 train you take the six train does different number of stops and you end up as different people and you're just like what's going on um that's essentially what happens to IBC tokens as they Traverse they interchange different paths will actually change the token and that of course does not intuitively make sense and users will lose their funds if they don't follow this right they will end up in a denom that maybe has no liquidity uh and there's no decks and maybe they don't even have the gas token and so basically interchange ux is screwed by all these different problems and it's true for Cosmos you guys can learn from Cosmos we know we've done many different things and we've screwed up a couple of them but when it comes to the roll-up world it's going to become 10 times worse absolutely because you'll have way more pathing and you'll have way more gas tokens and you expect users to understand all of that and have all those gas tokens so basically One does not simply send over IBC you can't just use the protocol you have to use it very specifically how do we fix this well basically we need to do unwinding right so this concept of if I want to go in this case from chain you know B to C I need to First be Unwound through chain a and I can have somebody tell me okay here's a transaction that will actually unwind you through chain a or wherever you need to go automatically so that you end up in the right place and Abstract that into something super easy to use basically you know abstract that into a browser URL so that all the routing all the DNS everything else just happens underneath the hood that's what we've built at skip um basically this is you know somewhat of the structure of the the API the user gives the intent to transfer we send back this multi-hop IVC message oftentimes it does a massive unwinding flow the front end sends sends back the user signed receipt and then they get a success and so all they see on the front end is basically I have my token here on this random chain I don't know how wound it was I wanted to go there and maybe it's even a different token right uh and they just end up with that experience but wait there is more so uh the ideal experience in our minds and this might not be right but this is what we believe is you want to go in the future over IBC from any chain any token to any chain any token and that of course might require a swap right so now you further complicated this workflow where you're not just routing the same token you actually have to at some point change into a different token and you want to do that in one click right you don't want to have the user have to go to different applications and figure them out and have to use them so you want to just have this sort of all done in one transaction so this also works with the skip API the way that we figured this out was there was some credible middleware Tech that was built inside of IBC called packet Ford middleware which allows you to once you get to a chain it will automatically forward it to the next chain and you can chain this together so you have multiple chains in a row and then you use these things called IVC hooks that allow for arbitrary smart contract execution on any intermediate chain so in this case oftentimes it will happen is you know three unwinding flows a swap on osmosis and then more unwinding all-in-one transaction so this is basically what it looks like if anybody's interested in trying it out we built this fun little front end called ibc.fun and it's just what you think it is basically it will show you the different routes and swaps that it's trying to do and then it all completes in one transaction so I don't know if this is going to play um maybe looks like it's not going to play but this is a demo of me actually doing it going from osmosis to a different token and just seeing sort of like how fast it is it went over five different routes which is you know in IBC quite complicated and then you know it all sort of completes extremely quickly so we're trying to figure out these other ux problems that we think Roll-Ups and IBC chains already have right and we we argue that these main ones are these gas token issues where you have to have so many different gas tokens and you know that's like a big ask for the users to have um this concept of sponsored payers so basically you know you can subscribe to a wallet and they'll just figure out some of these issues for you maybe they give you like a gas tank model where you have all your gas in one place and they'll just swap it out into whatever you need um best price Dex aggregation then also instant cross chain settlement you know there's been a lot of conversations I assume about intense I don't know what they are but some people seem to um and how those might solve ux in the future where you might just be able to give this intent of this massive cross-chain workflow and then a third-party actor might be able to come in solve that intent and you know basically give you whatever you need on the destination uh so if you're interested at all the API is free um it's something that we made sort of as a public good um I think it might be technically interesting to just delve into sort of like the reality of IBC and you know what you can do with it um this is a problem that will be true for all bridges this this this unwinding and winding problems will be true for hyperlane it will be true for many others and if we want to have a permissionless IBC standard or permissionless bridging standard we really need to fix these issues right we really need to turn the internet into or when you really need to turn IBC into something like the internet where you don't have to think about all of these different problems you can just you know type in Neopets and that's it thank you so much appreciate it all right that's excellent now we are going to Pivot to a panel on bitcoin where we have Eric uh Sunny uh Conor uh uh Sam and uh John talking foreign so good yes yes all right so I don't know has there been a lot of panels about Bitcoin or any talks about Bitcoin so far at this conference has anyone seen any Bitcoin talks not specifically about Bitcoin uh so Sunny uh I want to go to you first uh I saw that you wrote a completely insane tweet a couple of weeks ago I want to give you a chance to elaborate on that um and you feel free to introduce introduce yourself also um you wrote that proof of stake was a mistake could you was that a joke or is that something that you um it was a little bit of a uh just in a moment of frustration I guess but uh it was mostly just around like I was frustrated with like staking derivatives at the time where I just saw that like we built or like how these like stating diverters Protocols are evolving is we're effectively turning our systems into proof of authority systems and because like the staking derivative providers are just basically hand selecting the validators and I was like you know we spent so much time designing like security mechanisms into proof of stake and like slashing and like making sure like there's bonding programs like we've just like undid all of them and it's like what is especially frustrating was just the fact that the core protocol developers are pushing these things and it's like wait why did we spend all that time on proof of stake we should have if we wanted to we could have probably just built a proof of authority system into the protocol like actually maybe have token holders use governance to vote in uh validators and stuff like that so I think that was like the main point I was trying to get across no I think it's super interesting um because we have in crypto um lots of proof of stake systems and we have the largest cryptocurrency is Bitcoin and the users proof of work and I don't think that any one of us can for sure know how the economics of these proof of stake systems are going to end up and how these centralization due to staking derivatives are going to impact these systems so even though like you can approve a stake as your preference uh you can think it's much better than proof of work but it it's kind of it's kind of nice that there's a proof of work system there is there that we can use as a backup plan if there turns out to be some issues with with proof of stake um I think though like at least when I look to myself if I think about Bitcoin and I think about how is that system going to reach like Mass adoption or scale it feels like the Bitcoin Community to today have significantly tied themselves to the Mast of the lightning Network so the lightning network was invented by in a white paper in 2015 by touch dry John Joseph poon um that basically connects a bunch of payment channels together and leverage that system to Route payments across the network and I was I was listening to a podcast with David Marcus from um who worked who was the president of PayPal previously and then worked for Libra for a while and now has a company called light spark where they are trying to make lightning work and one of the things that he said is that in light spark they have a functionality called light spark predict which uses AI in order to figure out how you predict which path you should try in in lightning to make a payment and I would kind of I would kind of say that if you're if your payment system requires AI in order to just find a pass that you can send the payment that's not necessarily this doesn't sound like a functioning payment system um so I want to maybe maybe we'll um is there is there anyone here that sort of has uh do you see if uh necessarily a future for lightning or do you think that there's if we want Bitcoin to work do you think that there is actually a good reason if we want to take the biggest cryptocurrency out there we want to make it usable for payments is there a reason to perhaps explore other layer 2 Technologies on top of Bitcoin I I will uh yeah have an opinion about that so I think I think lightning and payment channels generally speaking makes sense for high throughput kind of use cases fast um you know gives you fast really fast High throughput payments and I think it would be good for payments that the whole world doesn't need to know about because like with any blockchain whether it's a layer one blockchain or roll up um you kind of have to tell everybody in the network about this payment and they have to store it forever um and so for payments like maybe machine to machine payments or other kinds of micropayments something like lightning or payment channels specific you know generally speaking I think maybe makes more sense for that kind of use case um but yeah it still remains to be seen what that model really gets product Market fit for I agree with that especially because I don't know like about lightning technical problems and like the um the progress on that too low but definitely when we're talking about in the context of Roll-Ups on bitcoin at the end of the day Bitcoin has a maximum of four megabyte data throughput every 10 minutes and there's a limit of even if you're use leveraging a roll up there's a limit of like number of transactions you can compress squeeze into that as a result of that lightning definitely serves a pretty interesting purpose especially in the case of Bitcoin payments are the original use case for cryptocurrency it's the least speculative proposed use case for cryptocurrency and payment channels have some amazing properties they can be extremely low cost they are good as finalized instantly as soon as you receive it you don't even have to wait for a block time even though in ethereum and the rest of the blockchain scaling research has sort of started to focus on things like Roll-Ups now and we sort of Left Behind payment channels those properties are lost on Roll-Ups and it's certainly worth trying to make the technology work if we can to get them back to be fair if you can scale data throughput to the levels that um your payment like payment Network can like Leverage it really well and we know that we can scale data quite well in a way that we can't scale execution so we can still have similar throughput like systems with data scaled da layers da layers like Celestia but especially in the case of like Bitcoin you just can't have to you just can't do that so Sunny uh do you care about Bitcoin at all these days is it something that I mean I know that you work in the cosmos ecosystem and like is there a sort of a Vibe um in that Community that's you know Bitcoin is a lost cause or are there actually people that care about improving Bitcoin and coming up with solutions to improve the system and how do you feel about it personally so for me personally I like spend a lot of time thinking about Bitcoin I still you know I got into Cosmos because I wanted to build the app layer for Bitcoin I was like you know what I was working at consensus for a little bit and I was like ah they're doing all this like this all this ethereum stuff is cool but like what is this each coin and like we got to build for Bitcoin and you know Bitcoin is an app chain I was like oh okay good this is simple we're going to do payments and issuance here but then you know blockchain was the one who came up with the idea of side chains and that's never really shipped it right and like I just saw Cosmos was the like place where people are actually building side chains and app chains and like so okay we're gonna issue Bitcoin on the Bitcoin blockchain and then the BTC asset is going to flow off into the causeless ecosystem and be the money of this like ecosystem and so that's kind of you know five years ago that's how I got into Cosmos then you know got busy with shipping and building all the product and stuff but now I think it's time for like I really I personally really want to shift Cosmos back towards that like original uh mission that was there for a lot of us and so I I really do think that like the ethereum ecosystem like it it has this like base money and it has this like huge ecosystem of applications around it I do think that the cosmos ecosystem has the second biggest ecosystem of applications but we lack a base money and I do think that this is like if I do think the future of Cosmos is to figure out how to bring Bitcoin and be in and build this like application ecosystem around Bitcoin that's where we've been working with like uh we're working with axler to build like a a property centralized Bitcoin bridge that like British is not just Bitcoin but a little Bridge ordinals a little Bridge BRC 20s um we're talking about the light spark people about making so you can Bridge via lightning and stuff so I do think that that I personally think that Bitcoin is the future of Cosmos obviously causes a very decentralized distributed group of people um in communities so different people have different views though I love that answer is it possible that I could get you to where um a Bitcoin Builder had a hundred percent thank you thank you well we we used to have a culture of like Innovation and and fun and building in Bitcoin I know John do you want to do you wanna wear one too I gladly accept I I think like honestly the whole ordinals thing was really exciting to me not because of like the technology behind it it's not that like crazy or anything but just the fact that it like brought this like renewed excitement to the Bitcoin Community again and like I think it's the first time in years I've seen bitcoiners be excited about things and I think it's just restarted this conversation that like I I can reasonably see that at some point in the next two years we're going to see more soft Forks into Bitcoin get new protocol upgrades which I just I I I'll admit I did lose faith in like this the rate of development on bitcoin core in the last couple years and I do feel this like sort of renewed excitement and like cultural shift in the community honestly a big part thanks to like the work that you and Judy have been doing yeah I've heard a lot of people say that there's like a sort of a Renaissance of building culture coming back back to bitcoin and one of the reasons that I want to talk about Bitcoin roll up specif specifically here is because we have this like massive modular ecosystem now where there's executioner environments and there's proof systems and there's all these different tools that's being massively invested in innovated upon that like if Bitcoin can just tap into all that Innovation and try to bring some of that home then we could sort of LeapFrog the Bitcoin space several years into the future so on the topic of Bitcoin roll up I think it's maybe it's a good idea to sort of give a lay of the land so that people understand uh our rollups on bitcoin even possible so we've had this conversation in different formats and different podcasts like 15 times so I think we can just summarize it super quickly um so in Bitcoin what what you can't do for example is that if you have one transaction that sex says x equals five in another transaction you can't multiply that value by two so X becomes ten Bitcoin doesn't have like State and and variables and values in that sense all the only thing that Bitcoin has is unspent transaction outputs so when you what you can do in Bitcoin is you can reference an on-spend transaction output you can combine it with a script and now you have a new on-spin transaction output but you can't really reference other variables in Bitcoin so you can't really build like a roll up on Bitcoin today but what you can do with Bitcoin so for example we put jpegs on bitcoin so that means that Bitcoin works as a data availability layer um all you need in order to build a sovereign roll up on a blockchain is that you need some space to put that data blob so in the context that we're talking here it's uh like initially we're talking about using Bitcoin as a data availability layer in sort of the modularity sense we can build Sovereign robots from that and then there is this whole body of discussion around okay what upgrades would be necessary at the Bitcoin base layer in order to enable Roll-Ups and then I think the um the consensus it that we would need some some way to sort of store State on the Bitcoin chain either through a covenant construction or something else and then we would need a way to validate the fraud proof or a validity proof so we need we would need like in Bitcoin right now for example you can't look at the Merkle root and verify that a value belongs in that Merkel route you also can't validate a your knowledge proof you can own Bitcoin is like a super primitive calculator you can only do like add two values together and you can't even store that value anywhere but you can use it as a data availability layer so we're going to talk a little bit about Sovereign Roll-Ups so for those of you who don't know the difference between a sovereign roll-up and a real roll up like arbitrum or starknet or optimism it's basically that The Sovereign roll-up doesn't have a bridge between the layer 1 system and their layer 2 system uh maybe we shouldn't even use those uh layer numbers anymore I think that the modular space trying to move away from that but you basically can't Bridge Bitcoin trustlessly into the second layer the Bitcoin asset and Bridge it back but you can use Bitcoin as a data availability system to store um a bunch of transactions and execute the state from that uh and and create expressive layers on top of Bitcoin basically so um if we put ourselves in the situation that okay we think that Roll-Ups on bitcoin are interesting and the first step to get there is to build a sovereign roll up and then build some type of bridge some trusted or crypto economic Bridge into that second layer uh how so I think it's more interesting than going back to the conversation like how is it possible to build Bitcoin rollups it's more interesting to talk about okay giving given the tools and applications that are out there today if you if I gave you like a challenge and I said okay well by the end of this year we need to have a first Sovereign rule up on bitcoin how should we how would you if you have that like as your mission right now that's what you have to do and you will get fired if you don't deliver on that um how would you what would you what tools would you leverage from the sort of the existing domain uh uh of modularity or or whatever in crypto in order to reach that goal we can sort of start here and then make our way to the end of the end of the row uh okay perfect uh to start I want to de-emphasize the idea of real Roll-Ups versus solver Roll-Ups solvent Roll-Ups just don't need a smart contract or any execution at the base layer to verify your fraud proof or your validity proof but that only means that uh at the start without like verifying that bridge it doesn't have like it doesn't have that bridge however the security guarantees of a smart contract roll up and a solvent roll up are the same we just create a proof of the sort that we read all the data from the base layer and we processed all the transactions correctly later on these uh like solver Roll-Ups can also have Bridges so you can still derive all of the Bitcoin security and build an application on top of it and the only thing that you'll be lacking is the ability to bridge Bitcoin and to be fair that's a big like that's a big missing Point um so yeah [Music] um about the stack that I would use to build a solver roll upon Bitcoin I'm extremely biased we at Sovereign Labs we work on Sovereign SDK um so there's already that are already teams working on a Bitcoin adapter to make Sovereign SDK build rollups Deployable to bitcoin and so I would definitely go with that and I would choose our ZK option we provide both optimistic Roll-Ups and CK Roll-Ups using ZK single round proofs or ZK ZK Brewing everything but I would go with ZK because the block times on bitcoin are quite long so you don't take the full advantage of being an optimistic roll up so you guys are already you already are working with a team that is building an adapter to leverage Bitcoin as a data availability layer correct so maybe to you Connor um perhaps you could give a little bit of an intro to what rolekit is and I think that you are you also working on a similar similar problem uh yeah roll Kit's also a SDK for provisioning Sovereign Roll-Ups it's it's meant to be quite customizable you can put in any kind of virtual machine that is compatible with the ABCI interface which should be any VM you could conceive of because it's a very flexible interface roll kit also wants to support all different kinds of proving systems we have fraud proofs for Cosmos SDK already we hope to add different kinds of ZK proving schemes as well um and also we have a integration into Bitcoin already we we developed a implementation of The Da interface for the Bitcoin Taproot witness that was done by Javed Khan on my team who should be here and unfortunately couldn't make it but we miss them um and as for design considerations for a sovereign roll up on bitcoin what features would you want what token would you use what kind of VM would you pick ideally you would use Bitcoin I think bitcoiners want to use Bitcoin I don't think they want any coins uh but you can't trustlessly do Bitcoin up to a sovereign roll up like we talked about so would they accept some sort of trusted bridge I'm not sure if the answer is yes then that's what you should do you should have some sort of trusted Bridge or ecosystem of trusted Bridges to get Bitcoin up there so that they can use the money that they believe in if they don't want to trust a bridge or a committee to attest to those Bridge transactions then you've got to make sure the token on The Sovereign Roll Up is something that aligns with Bitcoin do something without a pre-mine do something without insiders maybe even airdrop it to the Bitcoin utxo set when you launch the roll up for features there's a bunch of things you could do you could add payment channels you could give a lightning Network to this thing and it would have more capacity to open and settle those channels than Bitcoin does because I think it has more block space with the four megabyte Tap Root witness that's enormous that's bigger than this is not bigger than a Celestial block I can't remember but it's pretty huge you can do a lot on there you can add privacy to it you could add a zcash style privacy that Bitcoin base layer doesn't have uh and it would have the security of Bitcoin a sovereign roll-up is basically an app chain but with the with close to the full security of whatever it's deployed on so I just I just want to stop here for a brief second and reflect over the fact that there are two modular Builders here that have already built hooks into the Bitcoin protocol to start leveraging that as a data bank so all that stuff that is happening like out there in the ethereum world in the cosmos world in the modular world because we have these hooks into the Bitcoin base layer as a data storage all of that stuff can start creeping back in to uh the Bitcoin ecosystem now so like Bitcoin Builders they're gonna have to um you know they're going to get challenged by this whole other ecosystem that has been practicing and building applications for these layers for years now um do you guys sunny and light do you guys see any risks with that is there um is it maybe in bitcoin's best interest to just stay as pure and as far away from all that staking derivatives and the Mev and serial knowledge proofs and complex math like is it is there a risk that as we bring the Innovation that has happened sort of outside the Bitcoin space that we also bring with us the issues I I think the point is that like you keep the Bitcoin core chain like as simple as possible uh there's a few upgrades I would like to see mostly around making bridging a little bit more trustless but beyond that I think like all all the stuff like should be experimented with at the edges on on these like new chains yeah from from the research that I've seen um Mev tends to be um stay on the layer that the transactions are actually where the transactions are actually executed so if you have like Roll-Ups on bitcoin the sequencers might be capturing Mev but there is uh not a really opportunity for the Bitcoin miners to get involved in that um you know directly like as the mining Network um and so I'm not too worried about Mev in the context of either Sovereign Roll-Ups or even like Layer Two Roll-Ups on bitcoin um and like sunny I think the changes that we want to make to bitcoin um would be relatively minimal just to enable like trustless bridging um and then beyond that I think that the application design space that is opened up by Roll-Ups is um huge and and would be really valuable to bitcoin whether it's more private transactions like Conor was talking about or um you know whether the focus is on scalability because you can do like massive like witness aggregation into zero knowledge proofs and get transactions down to like you know just a like a dozen bytes or so um which would be huge for um throughput and improving scaling um so I'm not too worried about it in terms of like the original question about the stack um I think you know what these guys are building is it would be a really great foundation for like a sovereign roll up I also think that there are interesting possibilities that are opening up like if we don't have trustless layer 2 Bitcoins or Bitcoin Bridges we do have things like crypto economic Bridges like what threshold network is built or nomic which is a a Bitcoin side chain in the cosmos ecosystem once you can get Bitcoin onto let's say nomec you can use IBC to connect Bitcoin to any other Cosmos chain and so you could either you know build like a modular system there um where you know you move Bitcoin into the cosmos and then you could use you know Celestia as a data availability layer um to have an even more you know High throughput chain on top of that so I think there are a lot of possibilities that are either already here or like just around the corner like as these systems start to mature so sunny I saw that you were nodding a lot is there is there any connection between this and sort of IB is there a way to connect IBC to bitcoin using a roll up um yeah I mean I mean I've thought about like what what would IBC on bitcoin look like and really the point of IBC is to bring the trust assumptions of your Bridge as close to the trust assumptions of your consensus protocol as possible and I think I don't know I think the direction that that I'm most interested in right now is mostly around Drive chains I think it's basically like you know it I think drivetrains are the proof of work equivalent of IBC where it's saying hey let the bridge be operated by instead of the validators of appreciation but let it be operated by the miners of your proof of work system yeah we I know that we have at least three fans of Drive chance uh on this panel um so I want to talk about something uh uh slightly different which is the that the um I've at least made an observation that if you look at the roll-up space in the ethereum world these days you see that for example uh optimism has the op stack and ZK sync came out recently with the ZK stack and at the FCC events darknet announced the Stark net stack I think what is basically happening is that these different Roll-Ups that exist on ethereum today are trying to modular modularize their specific Stacks so that other builders can deploy app chains and other instances of the same roll up which we have seen with example for with binance launching pnb op stack and coinbase launching base which is built on built on opstack and I think that the reason that these teams are doing that is because they want other builders to sort of use their tools so that everything that they built everything that coinbase builds on base everything that binance builds on this BNB opstack chain will become compatible with sort of the mothership so everything that happens there optimism will just be able to integrate with no friction at all so I'm thinking that is that is that is that is that a trend that you guys have seen also that these sort of Stacks are emerging and is that maybe something that we could leverage for Bitcoin like could we do something like uh taking op stack and putting it on bitcoin to could we take ZK stack and putting it on bitcoin could we take the start net stack and putting it on bitcoin and how would that is that like a direct uh like orthogonal thing compared to what you guys are building with these sdks that are building Sovereign Roll-Ups on bitcoin or are there synergies here like could you take ZK stack and then use roll kit to put the data into Bitcoin or how do how would how could you take like a stack like that that I think May emerge as really powerful software Frameworks could we leverage those with with the types of tools that you guys are building um so you can totally take these stacks and modify them to work on bitcoin the key part is roll kit and Sovereign SDK is inherently being built to be like for solver rollups to start and then you can add Bridges to them and that makes it really easy to integrate into Bitcoin because we're just using Bitcoin as a pure data ability layer with optimism even with the Integrations op stack even with the Integrations they did to Celestia so far ethereum is the settlement layer and then Celestia is like the data layer they still require that smart contract interaction so to derive full Bitcoin security would not be possible at least like unless they do heavy modifications to the op stack in a way that might currently might introduce like security vulnerabilities because they're trying to stay as close to get as possible but over long term it's definitely possible but they need to get out of the smart contract roll-up framework um I'm gonna I'm actually like personally like a little bit less interested on like using Bitcoin as a data availability layer for everything it's like I I see the Bitcoin proof of work is actually a really good data availability system because what it does is you put data on there and miners are incentivized to broadcast it as widely and as quickly as possible because they want as many people mining on top of their block as possible so it's really good as this like incentivized Fast propagation layer but also as this like hard time stamping layer and I think like using trying to put all your it we're trying to put all your data onto Bitcoin is uh to me at least right now seems like not a good use of like Bitcoin block space and resources but I think putting the types of data that you want the sort of hard time stamping for is what's more important so um I I'm an advisor to Babylon and what what they're doing is like say like hey okay what can we actually benefit from putting on here why don't we put our proof of stake blockheaders on here and that way we get this like strong time stamping system and we basically make it so we can by putting proof of stake block headers on there you basically can solve these like long-range attacks that you get in proof of stake get the best of both worlds golf proof of stake with proof of work um and I think like being a little bit more smarter of what kind of data like what I think different data availability Solutions have different benefits and like being smart about what type of data you put where it and so yeah blockheaders I think that belongs on bitcoin putting your entire block data and I don't see the point yeah but Bitcoin ordering is is very valuable to people we've had Stacks which is this thing that checkpoints its blocks onto Bitcoin and Babylon which is doing something similar and uh when roll could announce the Bitcoin Sovereign roll-ups a lot of people were confused on what the difference is and the difference is roll kit puts the full blocks in the witness but kind of you know what's the point of that uh it's it's not not so clear data availability is talked about a lot in regards to roll-ups um Sovereign and settled where there's an on or off chain light client where you have a commitment to the results of the state transition and some sort of proof that it's correct and then you want to verify somehow that the data is available and if you can verify that a lot of data is available without needing to download all of it then it can be described as very scalable uh uh you Bitcoin doesn't have sampling so if you want to verify data availability for Bitcoin you have to download the whole block that's the whole four megabytes so it's not like Celestia where you can verify the whole block is available with only some small samples of it um so there's a good argument that it's really the ordering that we care about and not necessarily the data availability and I like what you said previously Connor that if we're TR if we wanted to build a roll-up system and natively for bitcoiners for the Bitcoin ecosystem like maybe you would try to do this even without introducing a new token so are there other considerations like if you were to build specifically for the Bitcoin ecosystem um are there particular use cases that would maybe be more interesting to build for bitcoiners like are there perhaps something on the Privacy side but maybe there are some things that doesn't have all that negative connotations that some bitcoiners are worried about like what are some if we had if we had let's say we had an execution environment today that had expressiveness that was Secure uh was either had the full data on bitcoin or had some of the data but was basically secured by Bitcoin and used the Bitcoin native asset what would be some interesting use cases for that if we start with you John well assuming a good trusted bridge for BTC um I think the use cases that are already popular on bitcoin just being able to do those maybe in a more scalable way um so like a lightning Channel management roll up where opening closing rebalancing your lightning channels is like super cheap um that could be interesting um privacy is also a I think a significant pain point for Bitcoin users like if you've ever you know tried to make your Bitcoin private there's like these guides on the internet that are like 10 pages long and if you screw up any of the steps then every all of your work is for nothing um and so you know having like a zero cash you know just easy button for privacy that just encrypts all your transactions I think would be pretty useful um and then can't underestimate I think the utility of Bitcoin D5 it's it's a pretty big use case I think over one percent of the Bitcoin Supply is being traded or lent or borrowed against you know on different chains um and so yeah just doing that in a way that where you also get the full double spend security of Bitcoin through the you know Bitcoin da slash you know settlement layer I think um could be useful to a lot of people what about like a a Bitcoin backed stable coin like uh USD that's backed by Bitcoin do you think that could be something that would be interesting to bitcoiners yeah I I uh I think it could be because right now the stable coins that bitcoiners have to use are like Fiat stable coins you know backed by money in a bank somewhere so if we could if we could actually use stable coins that are backed by Bitcoin in a smart contract instead I think that would be better like we actually built one of uh you can kind of consider it like a proof of concept of this on the rusoc side chains The Sovereign dollar um it's a Bitcoin back stable coin and that's that's with over collateralization right over collateralization we're not getting into like a Terra Luna situation with us where it's going to end up with billions of Bitcoins getting sold because there's an algorithmic Peg that sort of detaches yeah yeah it's over collateralized there's like efficient liquidation mechanism so it always stays you know over collateralized um at least that's the design right like there could be a flash crash and maybe Black Swan event but um yeah it's it's not like a partially backed stable coin it's a fully over collateralized stable coin but being able to do that on a chain that you know gets the full double spend security of Bitcoin unlike roostock today which has its own independent security budget can be reorged like independently of Bitcoin you know I think it it brings that kind of um utility in a more I think Bitcoin native way totally but also to be fair in any like yes these little roll ups will introduce general purpose programming to bitcoin like using Bitcoin security and I think the Bitcoin crowd as I've seen at Bitcoin Miami is extremely excited for that but at the same time since bridging Bitcoin will definitely introduce new trust assumptions um any Bitcoin back stablecoin will definitely not have the um attractive attractiveness as like it would have had without any trust assumptions for sure um I think what's more like like a bit more interesting like something that like excites me is that in a solvent roll up since you're reading the whole data space of like Bitcoin and applying rules from there you could also read into like usdt transactions and represent usdt trustlessly on the solver rollup itself and introduce liquidity in that way and build a defy ecosystem I'll be a little a little bit contrarian maybe we shouldn't do a general purpose VM maybe you just want in Shrine defy so that way you can avoid smart contract bugs the fear of smart contract bugs uh the upgrade authorities that people introduce as Central points of failure to deal with those bugs and have something that's more Bitcoin aligned and without all the things that cause bitcoiners to push back so hard against defy on ethereum that's such a great point I actually wish that we had spent some more time talking about that that when we're talking about building ZK Roll-Ups and optimistic Roll-Ups on bitcoin we don't necessarily need to take the entirety of the evm we could actually go back to that thing that bitcoiners used to say that we're going to analyze what all these other altcoins do and then we're going to take sort of the best part the things that we really like about them and we're going to integrate them back home so maybe we wouldn't necessarily want to take the the all the complexity of solidity and the ethereum virtual machine and try to cram that into Bitcoin not only because there's sort of bugs in inherent with that but also because it's really difficult to prove the evm if you're using serial knowledge proof like they're basically it's basically a system that's hostile to be serial knowledge proven and there are other virtual machines out there like Cairo for example I had a conversation with vitalik and I asked him like what do you think would be the best sort of virtual machine and language to run on on bitcoin and um I I don't want to put words in his mouth but I think he sort of was trying to point me towards Cairo as a better language to be Serena serial knowledge proven so we don't necessarily I think it's sort of a mistake if people think that we're talking about taking all the complexity from these smart contract these ecosystems there are sort of narrow versions of that that could be more focused on privacy or could be more focused on payments only taking those uh with that we're we're kind of out of time is there some thing is there anything that you guys felt feel that you want to say before we wrap this up okay that's it all right thanks uh thanks everyone thanks for coming to the panel uh if you guys are interested in building on bitcoin uh I'm definitely in the business of um in um hearing your story wanting to introduce more Builders back into Bitcoin I also have a company we're hiring so if you want to build uh Roll-Ups on top of Bitcoin try to find me after this this panel and thank you very much for coming foreign that was fantastic are we actually going to do something with Bitcoin or are we just selling it to Blackrock um all right what the room cycle Bitcoin was very popular who would have thunk all right uh we have Ethan Buckman up next talking about modularism and money design co-founder of Cosmos CEO of informal systems here oh you've got a bike all right thanks Zaki thanks everyone so here we are about to talk about the future of France and all these losers just left the room so they're going to miss out but lucky for you guys uh so yeah so I'm I'm Ethan uh if you follow me or know anything about me you know I'm really into money monetary design trying to figure this stuff all out um when I told Nick uh so we've been excuse me we've been working on a new project that we call collaborative Finance or Kofi it's our response to defy when I told Nick I want to talk about Kofi he said well that's not really on topic you should talk about something else so I just changed the title to modularity and monetary design and of course he was then thrilled now the thing the thing Nick probably didn't even understand was that Kofi really is about a modular payment system design based on a system of intents over which we optimize with graph solvers that publish ZK proofs of Integrity so if that's not on topic then what is right all right uh hi do I have a clicker or something yeah don't break the third wall is that what they call it don't smile with the photographer all right uh so you know I've long felt that money is the killer app it's the ultimate multi-stakeholder or computational use case and yet we are still failing to actually have the impact oh I'm supposed to stand where right here all right thank you uh and yeah we failed to have the impact we'd all like to have right and so I'm going to talk a little bit about that if I can get my Clicker working which I can't in technical difficulties just keep talking uh all right so I believe what's on the next slide uh is a quote from me that says if home is where the heart is money is where the payments are uh because that's what I think money is for money is money is for payments and we can talk about the modular structure of money right everyone's familiar with the three functions of money uh the unit of account is for denominating debt the medium of exchange is for discharging debt here and now and the store of value is for discharging debt elsewhere or later it's a very clear formulation it'd be great if we had such a clear uh statement of the modular functions of of blockchains what I'd like to point out is that I wish I had to what I'd like to point out is that between these different modular functions are tensions right and and when we're when we're building modular systems modular designs part of what what they do is they allow us to focus in on the tensions between the different functions so it's not enough to just say okay these pieces are modular and so we've got this modular thing over here and and that over there there's real tensions between the functions that we need to tune to and so I call the tension between the unit of account the medium of exchange liquidity which is what much of what we're going to talk about um today and the other I'm writing a Blog series about all this so you can check it out but I won't go into it because I'm probably going to running out of time at some point I'm going to need my slides to work otherwise I'm just going to start wrapping all right I believe the next slide says something like okay armed with a unit of account we can denominate unlimited structures of liability right I can say you owe me you owe whoever right we can denominate all this debt but then the problem is how do we ensure that we can actually discharge it all right you go you create all this debt structure and then how are you going to discharge it all this is the this is the fundamental problem of the banking system of money of payments of finance that all this stuff is sort of sort of built on top of right and next slide um it's a good thing I actually practice uh so we call this problem liquidity right the ability to ensure that you can actually discharge your debts that's what liquidity means liquidity is not how much slippage you're going to have when you trade one coin for another right it's not uh you know how many assets are available on some amm we call that liquidity because the purpose of trading is to acquire an asset so that you can discharge a debt right if all you're doing is trading just you know to trade monkey pictures or see your the value of your assets go up we're not doing anything real in in the real world the whole point of exchange and everything we're building ultimately needs to be in service of discharging debt because that's where we that's where we ground ourselves in the real world and real trust relationships and and and and and so on right so we need to we need to keep that in mind now next slide uh the uh the way we solve or address the liquidity problem s look they're so pretty right here we go so we did this slide we did this slide just dwell on that meditate on this for a while okay this is this is this is pretty fundamental stuff yeah um we did this slide we are here okay so what's a payment system we defined a payment system as a set of obligations right these are the debts plus the liquidity Source we can use to discharge those obligations right now if you think about that definition for a minute you might be like well wait a minute all these things I call Payment Systems you know fintech banking blockchains all of them are just about the liquidity Source they're just about moving assets around none of them actually do anything to represent the obligations right so none of them are actually satisfying this definition of a payment system which is a problem because if we're going to build the next generation of payment systems we need to address this okay so let me let me briefly give you a critique of of existing payment system now we're working on a white paper for this Kofi stuff that's really what I'm presenting here um that'll be coming out in the next uh you know two weeks TM but uh you know so so first of all we'll cover this very very quickly none of these payment systems are designed from first principles they're all just like cobbled together over the years responding to you know various problems um it's all just about asset transfer and exchange but there's so much more to to the core problem of of payment and and finance and what we're doing then asset transfer in exchange we have to actually look at the underlying obligations now we're talking about exchange so much of exchange today both in in the banking system and in the real world uh uh sorry and in the banking system and in the blockchain world it's all about Market making and dealers that's what everyone's trying to do bring dealers on board you know amms liquidity all this stuff that is a new model that developed after the collapse of the banking system in the 16th century now I promised Tebow I wouldn't talk about the 16th century today so I'm not going to if you think that's great like oh great he's not going to talk about history your part of the problem because we all need to learn a little bit more history and fundamentally if we're responding to this issue of central banks we all think oh you know we're going after central banks central banks emerged in response to the collapse of a prior International banking system that ran in the 16th century that cleared all the Trade Credit in Europe without almost any money at all we need to understand that we need to understand what happened why it failed and how central banks emerged out of that chaos to lead us from a world of clearing to a world of liquidity providing right basically since then Society has been structurally short volatility all these dealers all these market makers they're short volatility that is not a way to set yourself up for sustainability it's a way to compound moral hazard at the heart of the system yeah so obviously they constantly fail because nature is not short volatility right and so at some point you blow up and what happens Central Bank shows up prints a bunch of money bails you out right so that leads us to the fourth problem which is or the fourth element of the critique which is the problem of issuance any payment system needs to Grapple with the problem of issues whether you're a blockchain you know issuing to minors uh whether you're you know a new currency like like osmosis issuing to issuing to liquidity providers or whether you're a Central Bank in a banking system doing issuance when you make loans or when you when you bail out bail out the whole system and so what we want to do is try to understand issuance in terms of the underlying obligations right one way to think about it is that hey when a when a Bitcoin miner does some proof of work right they have shipped a service to the blockchain and now the blockchain owes them the blockchain has a debt to that minor which it then discharges by issuing new Bitcoin right and so by thinking that way it kind of opens up new possibilities for thinking about the problem of issuance we think that's important because fundamentally we're going after two questions here right one is how do we design a payment system to optimally discharge debt and two is who should have the right to issue and according to what principles right now a lot of people in the blockchain space are focused on on problem two and there's a lot of you know concern around tokenomics and issuance and how we do all this stuff but there's almost no concern at all with option one no one's talking about how we discharge debt right hopefully we can start to change that hopefully you don't walk out of here being like oh he's crazy none of that matters and you're like you know I need to focus on this debt discharging problem and issuance in that context because right now who controls the issuance in the world it's the banks when they make loans they issue new money and it's the central banks when they bail out the banks they issue you know the base money what we want to do is restore the capacity to issuance to individual communities right and we need in order to do that and do that responsibly and sustainably we need to ground it in the actual Network structure of debts this leads us to uh ultimately to what we're building which we call collaborative finance and collaborative Finance we think of as a sort of semi-permeable membrane between the real economy and the financial economies that is that layer in the middle the yellow mtcs is our is our core algorithm multilateral Trade Credit set off of course that's a that's a well-designed marketing term that users are going to love um but but the whole idea is that we can protect people in the real economy in the bottom layer by focusing on the on the structure of credit and obligations but we can still Connect into the larger capitalist system you know so we don't have to overthrow everything at once we can sort of you know do this iteratively we can build a platform that allows lenders and and capital providers liquidity providers you know lending protocols Etc to plug in but still do it in a way that that's responsible and takes care of the real economy right and and that's really what Kobe is all about and what we're building okay so let's uh let's actually talk about the design of the system this is the the background even though I didn't talk too much about history I'm going to I'm going to briefly just talk about the missing primitive right the main missing primitive is the obligation right the the debt okay and we're going to use balance sheets here year the world would be a better place if everyone spent a little bit more time learning accounting and thinking about balance sheets so we're going to do some very basic uh accounting here on stage so on the left We Have Allison Bob we have their balance sheets assets and liabilities right not very complicated this is a simple asset transfer right Alice has 20 in assets she transfers it to Bob now Bob has the assets there's no liabilities involved there's there's nothing happening this is this is what you do every time you send a payment to someone else right uh on the right we have what an obligation looks like right so now there's a liability involved Alice is declaring that she owes Bob right so she has a 20 liability to Bob and that corresponds on Bob's balance sheet to an asset right we might call this if you if you manage books at a company accounts payable accounts receivable very simple stuff right the reason I'm pointing this out is because we can we're going to build much more complicated structures that are networking these different obligations together but there's two things I want to I want to highlight here one is when you do an asset transfer between two parties right from Alice to Bob in general we can say that is in service of discharging a pre-existing debt right you're not I mean okay it might be a gift but almost almost every time Alice already owes Bob money and that's the reason she's going to send him the 20 right now we're not representing that liability here we don't represent it on our blockchains but that's exactly what we're missing right and that's the whole point of what we're trying to do to bring those obligations on chain so that we can do something more constructive with them the other thing I want to point out is that declaring an obligation what we're doing on the right in in Part B is really a permissionless action it's very much like sending money you know I can send Gary Gensler some coins and there's nothing he can do about it if I have his address I can also declare that I owe him money and there's nothing he can do about it if I say I owe Gary money then who's he to stop me right so it's a sort of permissionless Declaration uh it is an intent if you will to pay okay so now we have these obligations we put them together into a larger Network and you get you know complicated structures you got single obligations chain Cycles if you've seen anything about Kofi if you're thinking about this to yourself you're like hey wait a minute if I can see the obligation and there's obligations in a cycle then we can clear any obligations that are in a cycle right and you can do that without any money at all I owe Gary and Gary owes I don't know Janet Yellen and Janet Yellen knows me and we can just get together and say hey we all owe each other let's just do set off right we don't need we don't need any money we can just do set off and that's what's possible when you start to open up the structure of the obligation Network and you look at the obligations you can actually save everyone cash flow liquidity you can clear more debt with less money that's what this is all about yeah okay so once you have all these obligations how do you actually discharge them and and generally speaking there are four ways to discharge or to settle obligations right almost all of modern Finance is built on the fourth one it's called Novation so when you actually change the structure of the payments graph right you do securitization or factoring or clearinghouses you you introduce intermediaries you sell your debt you factor your debt right all of this you know the economists claim this is all in service of like reducing risk and making things more efficient obviously all of that was uh was and we saw that very clearly in 2008 when when this whole you know house of cards came came tumbling down what we want to do is as much as possible as we can using the existing structure of the payments graph before we even consider Novation and it turns out there's quite a bit you can do you can do set off which we just talked about that's clearing right IOU you owe me let's just do set off or we can do it in Cycles arbitrary size there's assignment which is just normal transfer we just you know we'll use a fancier word because that's what we like to do you know I I transfer you money that's assignment it discharges the debt but then there's a very interesting thing you can do which we'll call overdraft right right this is where you say draw on a credit line someone makes some credit line available to you and you can draw on that credit line to pay someone so one way you can think about this is assignment is what you can do if you have a positive balance right you have a positive balance of some asset you can assign some of those assets to someone else and use that to discharge debt overdraft is what you can do if you have access to a negative balance right someone says okay I will allow your balance to go negative and so your balance can go into negative territory you can draw on that to pay someone else this is what happens when you take out a credit line from a bank it's basically a negative balance it's what happens when you have a Mutual Credit system in both of those cases you actually have money creation happening right when you when you have a credit line from a bank and you draw down on it the bank is actually creating new money it's expanding its balance sheet and allowing you to use that that new money uh to make payments and banks are allowed to do that because they have licenses from the government but why should they get to have all the fun right we want to seize the means of of production of of money back from the banks uh for communities and figure out a way to do that responsibly and that's really what this is all about but we can also do overdraft without money creation right a pool of investors could come together and say okay we're going to pool our our Bitcoin and our osmo and our atoms into some pool here uh you know we'll do it over IBC we'll put it in this little Kofi chain and you know we will make it available to people to draw on to pay their bills right and we can do it because we're going to have access to this network structure of obligations we can do it in a much more intelligent uh and optimized and risk reduced way so it's important to keep these these different things in mind the last thing would be Novation we're not going to focus on Innovation because we want to avoid it we want to do as much as possible of set off assignment and overdraft before we hit Novation okay the last thing we need to put it all together is as as promised uh the system of intents okay so we already touched on obligations we sort of beat them to death obligations are an intent to pay that's kind of obvious yeah so then to really round this out we need tenders and acceptances so a tender is an intent to use some liquidity to discharge your obligation so I have access to some dollars or some Bitcoin or or some atoms I think I have set sunny here I didn't I didn't pop osmo enough so I have access to some osmo maybe he'll stay uh and and I say you know I'm willing to use my osmo to discharge my debts wouldn't that be great Sunday if people could use osmo to pay their bills um and uh and and and then an acceptance is the flip side of that it's saying I'm willing to accept some osmo I'm willing to accept some atom uh or Tia you know if you will right right Nick yeah uh I'm willing to accept some Tia to discharge that's owed to me right that'd be great I like Tia I like Nick I like what they're doing at the modular Summit uh and so I'm willing to accept them to you and and so you can start to collect all these different intents all the obligations the network structure the different tenders people are making which means the different kinds of liquidity they're willing to use to pay their bills the all the acceptances the different kinds of liquidity people are willing to accept in payment of their bills and we can put it all together into a graph structure and then we can run a solver over the whole graph right and we can run solvers that that draw on Decades of you know Advanced Theory and algorithms in graph Theory essentially to to find Optimal results so we can actually optimize to discharge the most amount of debt with the least amount of money while respecting everyone's references right solving over a system of intents you all love it all right so This Is What It ultimately looks like right so we represent we have our graph here we have a bunch of obligations um we have at the bottom this VB this is our liquidity Source right you can imagine it's it's uh it's osmo it's Tia atom whatever you like and we have the A on the left that's the assignment source and the O that's the overdraft Source right so those are positive and negative balances that people are able to draw on and then on the right we have repayment and deposit right that's where the money goes back to after it's uh it's sort of used it either needs to be repaid or or redeposited and basically we can use the same algorithm we use to find Cycles we can use the same algorithm with liquidity to find even more Cycles right so the addition of liquidity into the network even a little bit of liquidity a small amount of tenders or a small amount of acceptances allows us to essentially close more Loops right so more people can benefit from their debt being discharged okay there's a lot to digest in the slide you'll have to read the white paper uh we'll go into a little more detail here here we have two different liquidity sources we're going to put overdraft aside we'll just focus on assignment here right so we have aosbos e we have D O's b o c right so an obligation chain now we have access to Fiat we have access to crypto and we have b b doesn't want to use dirty Fiat he doesn't want to use coins he's only willing to settle in gold bars but he's happy to do set off right if if you owe him and he owes you he'll do set off with you but he doesn't want your dirty Fiat he doesn't want your shitty crypto he only wants gold now what's going to happen a has a tender that says well I'm willing to use Fiat to pay my debts and C has an acceptance saying I'm willing to use Fiat to to discharge my debts D is willing to use crypto and and so is e to accept crypto and what ends up happening is B benefits from both of these things so B is benefiting from A and C using Fiat and from d and e using crypto without even knowing about it D doesn't want anything to do with them he doesn't have to touch either of them all he's going to handle is a set off notice that says his debts are reduced right and his debts are being reduced because other people are using Fiat and other people are using crypto right this opens very profound new ways to bring crypto into the real economy where so long as there's a small number of people willing to Tender crypto and accept crypto others can benefit from that without having to touch it at all so long as they're willing to touch a set-off notice which is just an accounting entry okay so this offers you know really really new ways for crypto to impact the real world economy to be used in real world payments and to benefit real people without them even having to touch it which is I think a knot that we've we haven't been able to crack uh really until now this is another example um this one's a little bit more more complicated but but also quite profound where we were not able to close the loop within Fiat or within crypto we have to combine see on the previous slide you know we didn't need both liquidity sources right if we just had Fiat we'd close the loop ABC if we just had crypto we'd close the loop dbe right in this slide see uh in this slide we're we're not able to close either of those Loops we need to use both crypto and Fiat together and in this in this system because the difference here is basically uh in the previous one you know dob um you can see there's sort of that not there's not the same overlap right so here you actually need both sources of liquidity to be able to discharge everyone in the path and so you end up you're able to complete a new cycle over both sources and so the more liquidity sources you bring in even with a small amount of tenders and acceptances assuming you have a large obligation graph you're able to discharge way more debt which is very very very powerful so ultimately you put this all together you get something like this right so here's here's uh based on real data simulated it with three different liquidity sources we could say one of these is Fiat one of these is crypto one of these is Mutual Credit that's the Holy Grail Mutual Credit is communities being able to issue their own debt sorry their own currency to discharge their debt right and you get this this stunning visualization of how everything flows in the network so that all the debt as much debt as possible can be cleared with the least amount of money while optimizing over and respecting everyone's preferences for which currencies they actually want to use uh with that I'm perfectly on time which is kind of amazing uh thank you so much I'm Buckmaster you can learn more kofi.informal.systems and check out the white paper when it's out [Applause] thank you Ethan all right up next we have Ismail from co-founder of Celestia uh you should all have heard of it uh and he's going to be talking about the past president the future of the celestial architecture [Applause] hello everyone I'm is my coffee co-founder and CTO of Celestia I'm going to talk a little bit about the architecture of Celestia how it currently is and give like a glimpse into the future um whoop they're not Mineo um how do I fix this oh okay um okay um first so on the agenda I wanted to talk like two parts like the first part is I'm gonna recap the Celestia architecture and in the second part as I said I'm gonna talk a little bit about like future directions so it's not like a full-fledged roadmap but what could be on the roadmap next year or so okay so first of all what is Celestia I think most of you know but for those who don't know I um gonna explain it from a high level but also how it's implemented roughly so Celestia is like the first modular blockchain Network and what it does is it decouples consensus from execution um so what does this mean um so in In classical monolithic blockchains um usually how every chain works is um a client verifies two things right it verifies that the header has consensus and it also verifies that all the transactions are valid right like it executes the transactions makes sure the state transitions are valid um and then in Celestia though um it only verifies if the transactions are available it still validates that like the header has consensus right but it doesn't execute the transactions it doesn't validate that what is posted on chain is actually valid it just very like it just ensures that these messages that have been posted on chain um are available right they are OPAC blobs to Celestia like every application can post their blob onto Celestia their message and it's just ensured that these are ordered um there's consensus on the order and then everyone can verify themselves that these transactions are available so that's the main differentiator and um um yeah and um I'm gonna explain a little bit on how this works as well um you may ask like where does the execution happen and the execution in Celestia happens in so-called Roll-Ups right um instead of this world computer model where like all the transactions are validated on on like one chain the uh State transitions are validated on a roll-up um and you might ask like how do uh like how how does that work in practice the um light clients for instance they uh um to validate that like a header is um and contains only valid State transitions there's two approaches to this which is like um via fraud or validity proofs right like the in the in the ethereum world these fraud of validity proofs are posted uh on ethereum or um they're settled on ethereum but like in Celestia as there is no execution layer whatsoever on on the on the main layer these can be on like a different layer like on a settlement layer or they could be on the peer-to-peer layer um I just wanted to stretch this as many people still perceive Roll-Ups as like um enshrined with like uh with an enshrined settlement layer like on ethereum [Music] um so now that already covered like how execution Works how uh the main chain works I I wanted to like uh mention the four guiding principles with which we designed Celestia or like goals that we wanted to achieve um so it should be possible that a block um is deemed valid only by checking uh block uh availability right um which means you can like verify a header as a light node without having to download the transactions uh just by verifying the availability um the second principle is application message partitioning which means every application only has to download their data right like they don't have to download all the transaction data of all applications only the transactions that are val uh like necessary for the application and then there's um application message retrieval completeness which is the same thing but um uh which means that they can verify that all the like application messages they downloaded all of them and nothing is missing and there's also application State sovereignty which means that all the um all they need to care about is their straight Transitions and their um yeah basically their state portion uh or um and they don't have to execute other transactions of other applications unless there's a direct dependency um so next I want to talk about like how is this achieved roughly I don't want to go too much into detail but like there's mainly three three key ingredients here in play one is Erasure coding of block data another one is a namespaced Merkel tree and data availability sampling so let's dive a little bit in um eraser coding is a technique that's very well known which is uh basically used like in CDs where you can like recover data um so yeah you add parity data and you can recover data even if parts of the data are missing right so how this works in in Celestia is the data is encoded in a certain way arranged in a certain way the original block data is um um split into equally sized chunks and then you add this eraser coating um in this Square construction that is depicted here the details do not matter what matter is that you um this enables basically that you can uh with like a portion of the data can always recover the whole data so here we also commit when like validators create a block they also commit to the Erasure coded block and not to like the the original data only as it is with like other chains um and so every every like row or column here uh basically forms a Mercury and these Market trees get committed to in a bigger overarching record tree um and that Merkle tree is not like a a simple like traditional Mercury it is very similar though the main difference is um that a namespaced Mercury is used which sorts the data according to their namespace like each application can have their own namespace and the data gets posted on Celestia gets prefixed with um with a namespace right like it's getting sorted and this is the data structure that ensures the property that I mentioned earlier you can like only download your portion of the data your namespace and you get like a complete test guarantee of that as well um so oops um the third and most important ingredient that makes it possible uh for Celestia to ensure availability is data availability sampling right so the as I mentioned before the block is radar coded here depicted slightly differently and then um [Music] light nodes or nodes or clients can download only a small portion like one percent of the data due to that Erasure coding um to guarantee like almost 100 certainty that the data is available um yeah and so from a very high level perspective this is how we build the system um we took tenement right and we modified um oh Comet bft call today uh so Comet bft uh previously tenement we took that modified it and we added basically um the data commitment that I mentioned earlier we also used the namespace Merkel tree for that data and the third component that I mentioned the data availability sampling is um done in a different layer in a different peer-to-peer Network we call the DNA networks heavily reliant on bit Swap and lip P2P a huge shout out to the node team that built this no one has built this before it's a huge effort um and yeah that's the high level that's a high level architecture overview so oops so let's go to the more interesting part which is like what are future directions for Celestia how could like a future roadmap look like or at least what could be some highlights here um so I mentioned this Erasure coding right [Music] um this is required for rollaps to ensure safety right like in in the sense that you have to be sure that the data that has published has not been tampered with like there's no validator this is like committing to garbage essentially or something else or some invalid data so how do we ensure this currently um currently um we have a a fraud proof type that is called bad encoding fraud proof that every node can generate it like downloads either the whole block or even a row or like several rows are sufficient they can like verify that the data matches the data root and can generate a fraud proof if that's not the case that has the downside that theoretically light nodes need to have to wait for such a bad encoding fraud proofs to not happen to ensure like full finality of the block right an alternative approach is to use kcd commitments I think if you saw uh avails talk yesterday that's a technique they employ which gets rid of the bad encoding fraud proof the question is can we do better than this um I think we can so with an alternative approach here is to use um a ZK proof of the Eraser like to use a ZK proof that proves to you that the Erasure coding and the construction of the data route was done correctly so you can still compute quickly like the data root as before and send around the proof if necessary if like you require finality right um so that's that's a research Direction um if if anyone is into like ZK proofs um this is something you could look at and I will later share a Research Forum link and the GitHub link um another direction or another topic that we certainly will look at after launch is a trust minimized Bridge or like a 2A Bridge from and to Celestia So currently if you wanted to use the base layer Celestia token on your roll up as a gas token you have to use like other Bridges and to use like other change or third parties to to get the token out and in to your roll up and back right um ideally you would like the the the ux of this would be more seamlessly such that developers can use the the tier token directly so one naive way to do this one way to achieve this is you could enshrine uh like a general purpose execution environment onto Celestia that um like that acts as a bridge right um that has the problem that it wouldn't be really neutral in the sense that um you have to choose an execution environment and also you'd basically reintroduce yeah like you would tamper with the original Vision which is like having only data availability and consensus it turns out that um you can do this without enshrining the execution environment Mustafa came up with this idea where you basically um Leverage that um ZK snark verification is more or less like looks very similar to cryptographic uh signature verification right you also have like a a like a public key and from that like if you look look at the how ZK snacks work it's it's like from from the public key it basically looks the same so um the user flow for how this would look like roughly from a high level is that a user would enter would send a deposit of tier to a verification Key address that's like a key address like a public key or an address on by like a ZK program so you deposit here to there it gets like escrowed or burned and the transaction gets confirmed and then the tier would get credited on the on the roll up and so you moved out of of uh of you moved Tia into your roll up seamlessly so this rollout will need to track the state of that verification Key address and yeah so the more interesting part is like how do you bridge back you would send Tia withdrawal transaction of your tier in the roll up right if the transaction gets confirmed by the state machine on the roll lab uh you generate a ZK proof and that ZK proved like kinda simulates or acts like a signature on the verification Key address on Celestia so that would trigger the withdrawal of of TL that's very high level um the the devil is in the detail there's a lot of like choices to make here um John would say a lot of implementation details um and indeed um yeah another Hot Topic is how to fix um Mev or rather how to apply current state of the art Mev research and techniques to like the modular stack right the like there are two like there are several teams working on this um I think Skip and flashbots are the most uh noteworthy here um the the specialty or like the difference here is that um Mev uh can trickle from the roll up into the base layer like the the base layer validators could delay or um like even sensor batches from from the roll apps right so the question really is like how do we apply solutions to Mev to this like more modular stack especially given that there's like a very heterogeneous application layer um I think um Evan's talk will cover this in Greater detail don't miss it it's like this afternoon um he will speak about how to break the proposal Monopoly uh don't miss that talk um so this is like the long-term goal here that we want to achieve is um one gigabyte blocks one million Roll-Ups and 1 billion light nodes so often when we mention this to people like one gigabyte blocks that sounds insane right and it kind of does but we won't achieve this immediately anyways it will be on demand but we do believe that this is um like as it becomes necessary we will tackle this and the question really is like how um I think we're very confident that we can go to like 100 or something very very quickly but to actually get like closer to that one gigabyte blocks goal we will have to optimize commit bft's peer-to-peer layer right like the mempool is not made for super large uh blobs and um the the content the consensus reactor like the gossiping mechanism is also not made for that there's a lot of like low hanging fruits and optimizations that we will do uh one of them's already started with like the content that has no pool um cat pool uh Callum implemented this already um similar to the peer-to-peer like the node P2P layer needs a lot of improvement to achieve this mainly uh block sync and dashing like there's a lot of optimizations to be done mostly very implementation specific um it might turn out that like in the future in like several years we have to merge the da layer and the consensus layer again like architecturally from a software perspective and we will might have to employ a technique called internal node charting to achieve um like the throughput on on the consensus layer another topic that I want to stretch is we want like like one billion light nodes how do you achieve this right um so we want all light nodes to run on all devices like on all kind of devices but I think the device we should Target the next is the browser because um this is what like people are used to interact with in their wallets and um um like they send transactions through like middle mask and everything what you want to achieve is running Celestia nodes dashing light clients in the browser um so there's two approaches to this one is uh having a different compile Target for Celestia node go implementation another one is having a rust implementation um for the sake of time I'm not going into detail but if you want to hack on this please talk to me um yeah there's plenty of other open problems in research directions a few were already mentioned for instance by Yuma yesterday uh the ZK quantum gravity Bridge um yeah and I think one thing that at last word that I want to mention is that we need to focus on developer usability and if you want to do usability research for developers in the modular stack please also reach out to me um yeah you can engage here with in our Research Forum and on GitHub these are the main things thank you very much [Applause] thank you very much Ismail yes gigabyte box I want a gigabyte block um I don't know what I'll put in it but it seems sign uh next up Sunny is going to be talking about Metro security hello uh I in fact will not be talking about master security I'll be talking about some other stuff but it'll show off a little bit at the end I think I've just been sending mesh security as the title for all the talks that I haven't come up with a talk for yet and you know they just they're like oh yeah that sounds good um no but I'm going to be today thank you guys for coming uh my name is sunny I work on I'm one of the co-founders of a project called osmosis and uh we're going to be talking a little bit about how osmosis will be interacting with the uh modular ecosystem uh so a little bit of background for anyone who's not familiar with what osmosis is oh yeah that's better uh anyone who's not familiar with what osmosis is um we are a DEX uh built on the cosmos SDK we have all sorts of you know we just launched we just launched uh you know we have liquidity swapping ability we launched a contrary to liquidity very recently uh you can do all sorts of um have assets from over 50 different blockchains uh on the on the osmosis blockchain we have over 100 million dollars in liquidity um we have all sorts of like Pro trading tools like uh basically the most advanced developed decks in the cosmos ecosystem and uh yeah you know liquidity from all different places both from within Cosmos and outside of Cosmos out of all of the assets you know like four out of five or biggest pools are from non-cosmos native chains right um and along with just the decks itself we have this ecosystem of applications uh really meant to build this like full unified defy experience on top so you know beyond just your basic spot trading you have your margin trading you have your perps you have your launch pads you have your Fiat on-ramps you have lending protocols so basically a full integrated defy experience everything you know the goal here is you go to binance.com you have all these trading tools you have all this like things and one unified experience osmosis is going to provide that in a decentralized way so um and you know as by being this like liquidity center for the cosmos ecosystem we are are sort of the center of IBC traffic today so if you look at you know on any metric by users or by IBC traffic uh by volume uh osmosis is sort of the center of that and has found itself uh as this like IBC Hub and liquidity Hub of the cosmos ecosystem and so now uh very soon hopefully uh we will have a new entrant to the cosmos ecosystem right the Celestia blockchain will be launching and as part of the Celestia blockchain launch you know the goal of the Celestia of blockchain uh node in node implementation is to be as simple as possible Right like you know obviously we need this thing to you know uh you know with Celestia we're going to have like this beginning of all sorts of like new modular chains and Roll-Ups building on top of the cosmos ecosystem and you know there seems to be this like thing about like oh app chains versus modular and like I think this is like some weird dichotomy because really the whole point of app chains is this idea of modularity right it's saying like hey we don't need to put everything into one blockchain we can you know break out what you need you know osmosis we're trying to be a DEX we can like say like hey we don't want to deal with bridging we are going to completely Outsource that we are that's not our not our problem we're gonna go find someone else to work with we're going to go work with the axillar team or the Wormhole team right we're going to go Outsource bridging completely this is part of the modular idea right or you know if it comes to things like data availability or like you know if we need a base money it's like okay we're not building that we're going to Outsource this this is all you know it's all modular so um so what I was saying was yeah so you know the goal of the celestial blockchain is to act as this app chain and to be as simple as possible because obviously you know we've got to run it on our Kindles and we're going to keep the keep the nodes as as light as possible and because of that the Celestia code base is actually like very very minimalistic you'll see that it actually Imports very few modules you know Ishmael just talked about how like you know what how can we avoid adding a general purpose VM or anything to this chain um so the one module that it does have though one of the few one of the few modules that it does have obviously is the IBC module which is great right and so this is this decentralized uh you know this permissionless bridging protocol that allows you to send tokens data assets anything between any IBC enabled blockchain and so IBC is uh growing it is uh you know built on the causeless SDK there's other chains as well now now we finally have it on polka dot we have it on uh the penumbra and a Noma stack so you know IBC is uh slowly growing but with Celestia now and this ecosystem modular ecosystem that's being built on top we have a whole bunch of new Frameworks being built right you have like uh the op stack now right you have roll kit you have the Sovereign SDK you have eclipse and it's like it is going to take us time to go and build out IBC for every single one of these because the goal of IBC is to really like build in uh your bridging protocol at the same security level as your consensus system it uses like client proofs and it will take time for us to get there obviously you know the goal is we want IBC everywhere but and there are people working on this right like polymer is working on adding IBC like uh like ZK IBC to uh all of these sort of different Stacks but it will take us some time to get there and so right now uh how do we how do we do this we're going to have to rely on other Bridges right and so this is kind of where so the question is how will all these Roll-Ups uh and you know chains and Sovereign Roll-Ups and everything on all these different Stacks access liquidity especially TL liquidity right because they need that Tia to pay for their data availability how are they going to get that Tia to to there well this is where osmosis comes in so osmosis is you know really expanding on its bridging support so obviously we support IBC today we work very closely with the axelar team uh Wormhole just announced yesterday at osmocon that they're launching worm chain which is going to be a cosmos SDK based chain and then the important one here is hyperlane right so hyperlane seems uh poised to be the you know Bridging the first Bridge that's available to a lot of these different Stacks because of the way that it's been designed as this you know very op modular bridging system where you can have you can choose what kind of security system you want and so we are working on adding hyperlane to the osmosis uh chain uh and be and you know because of its app defined security model we can write it as a cosmosum contract and with this we're going to be able to use osmosis as the connector between hyperlane and and IBC so now you have this flow where finally you can say Hey how do you get uh Tia from Celestia onto something like eclipse or onto an eclipse based roll-up well you can IBC from Celestia to osmosis and then hyperlane from osmosis to eclipse and and you know this will be and the idea here is that we're going to use hyperlane to connect to all of these sort of different uh Roll-Ups and get Tia onto them now well what do you do when you're at the center point of uh you know Transportation routes right well you build a trading center right you build you build Constantinople right you're you're at the crossroads you build you build a training center there that's what that's what we're building with osmosis so we want to be the place where we build up as much Tia liquidity and liquidity for the entire modular ecosystem and provide these uh services and like product that we've been building for the causes ecosystem but expand uh just beyond that um and so one of the things that I'm really interested in is like protocol owned Tia because you know if anyone remembers a couple of months ago like the arbitrum chain basically came to a halt because like some Dev account didn't have enough eth in it to pay it's like data availability and stuff right so we should be moving to a world where no you shouldn't be relying on some like Foundation or some Dev team to be like paying for your uh submission proofs to your da to Celestia right you should be actually moving towards a system of protocol owned TL and so you know there's a bunch of different ways that we can do this so one we have this protocol called stream swap which is basically a auction system built on top of the osmosis chain and I think a lot of the new uh projects that are launching can to can do these stream swaps you know it gives you this initial distribution but you can do it for Tia so that way you have this initial distribution of your token but now your protocol owns Tia in its community pool or Treasury and it can pay for its own D.A without directly from it from it from itself um we also have built this thing for the causes ecosystem called V abstraction and what V abstraction is is it's meant for transaction fees so what you can do is you can you can take a chain like stargaze right uh stargaze is an nft platform built on Cosmos people can start paying their transaction fees in stars but they can also pay their transaction fees in any token the campaign usdc they can pay in osmo they can pay in Bitcoin and what we've done with this fee abstraction module is that Stargate is going to accept these fees and all these different tokens but what the chain will do by itself is it will send all the tokens to osmosis swap them to its own native token and then send them back to the stargaze chain so that way they can be distributed SBS or burnt or whatever they want to do so this module is available it's you know available on our GitHub you can go to github.com osmosis lab slash fee abstraction you can import it into your Cosmos chain today and any Cosmos chain can start your 7th fees in any token okay what's the next step the next thing that we're going to build with this is Da fee abstraction how do you let all of these Roll-Ups pay you know let's say they don't want their own protocol owned Tia in their treasury but what you can instead do is say hey a chain like Manta can say oh we are going to hold our own native token Manta but we need to pay our D.A they can send it to a hyperlane into osmosis it will automatically swap it to Tia and send it to the Celestia chain in order to pay for the D.A and so uh we have we are working with some teams to actually build this out in production now um another way that uh you know beyond just for fee abstraction with you know with this whole modular idea a lot of these chain you know we we work very closely with the Argus team you know we we can build this idea of outposts where they don't have to build their own Dex infrastructure for their own chain they can actually provide things like swaps and everything over IBC so let's see if this works this is a demo that we built of the uh Cosmo swap which is basically this is a swap on the Juno chain you're swapping Juno sorry osmo Juno for osmo you make a single transaction on the Juno chain but what it's doing is it's actually sending the tokens to osmosis swapping them to uh the the osmo and then sending them back to the Juno chain so basically Juno doesn't need its own native decks all any that let's say you have a dow on Juno or whatever you're trying to do you can tap into osmosis is far deeper liquidity and so uh the fmos team has also built a similar version the same similar concept for the evm uh the skip team has you know you saw them present a couple like an hour ago about ibc.fun you can basically swap from any chain to any any chain on any token on any chain to any token on any other chain over IBC and we'll be working on like integrating hyperlane into the system as well um yeah all through osmosis anyways um so these are some of the ways that osmosis is like you know planning on uh integrating more deeply into the whole modular ecosystem one of the other things I'm actually really interested in is you know I will obviously I do have to talk about mesh security and how we want to incorporate data availability into mesh security so uh you know the con the premise of Cosmos and I think a lot of the module the thesis and a lot of the modular ecosystem is this idea that every chain is the L1 for its own internal State and a L2 Fort foreign state right this is sort of the whole idea behind these Sovereign Roll-Ups and so you know osmosis is the settlement for you know the osmo token but it acts like an execution environment for any axle that is bridged IBC to osmosis and so as part of IBC today you know we do these sort of like client proofs where like two chains are going along you send an IBC packet that includes some sort of like client proof but what we want to do is eventually make IBC or you know the security model between these chains better than just like client proof we want to start to incorporate things like fraud proofs and finally now thanks to things like roll kit we actually have Optima uh fraud proofs for the cosmos SDK now the thing is fraud proofs uh have this huge uh time delay to them right you have to wait the entire challenge period and the ux that people have come to expect in Cosmos is like very fast bridging right you can IDC between two chains uh in a matter of seconds and that's sort of one of the things that people really love about it and so we don't want to build in this uh you know fraud proof window into the IBC bridging protocol because it'll just massively deteriorate the ux but how we can use fraud proofs is in mesh security so mesh security is this idea of restaking where you can say like hey validators are going to uh give certain guarantees about the uh you know they're going to be restaking their osmo to yeah okay so and as part of this what we've done is you know the the initial version of mesh security is mostly about tendermen fraud proofs so it'll be able to detect hey okay this validator does something malicious and like the consensus protocol we're gonna slash them but the way mesh security is implemented is actually as it has this interface called slasher contract and you can write arbitrary slasher contracts right you can do it for things like oh um we're gonna do uh mesh security restaking for an oracle protocol and if you're if one validate is Oracle price is too far away from everyone else that is a valid slashing condition what we can also do is build uh roll kit fraud proofs as a slashing condition right and so I think that eventually every Cosmos chain will start to use roll kit style fraud proofs right and so that's great but then how do you make sure that you have these fraud proofs the idea is that like okay we're not going to block IBC bridging on it but if a Byzantine State machine uh sends an invalid packet in the future they will be slashable for it but to make them slashable for it we need to make sure there's data availability so this is what we can block for we can at least block on data availability before accepting IBC package so let's say chain one or say chain two wants to send to some assets to chain one what it can do is generate a transaction it will post the data onto something like Celestia or any da system and the validators of chain one will be running a data availability sampling like clients of Celestia so in the validator software we should be having this uh dos like light client built into the software and what they will do is when IBC data is sent from chain two to chain one the validators will basically use a vote extension to approve whether or not that they actually got the the they'll validate that the data is available so they're not going to actually validate the fraud proof itself they're just going to validate the data as available so that someone in the future can submit a fraud proof to the max security slasher contract if needed um anyway so thank you guys so much for listening and I hope you learned a little bit about osmosis and uh my security and what we're building thank you thank you very much uh continuing our uh sort of theme of Cosmos themed panels uh myself uh David from Galileo Ismail and Jack are all going to talk about uh the internet of modular blockchains oh and Ethan it's like uh yeah there is a recorder I'll take that give me that one cool awesome um happy to be here with everyone um and with a few Cosmos ogs um today I kind of want to talk about the internet of much other blockchains uh setting the stage um in the past and talking about a little bit of history of Cosmos which I'm sure Ethan will be happy to do because he loves history only from the 16th century that's right so um fast forwarding from the 16th century a little bit Cosmos came about somewhere around 2017 and set this vision for um an internet of blockchains uh a future that would Encompass thousands hundreds of thousands millions of blockchains and to accomplish that they came up with the first modular framework for blockchains which is a composable suite of software Primitives and the cosmos SDK what's now Comet bft and IBC so that we can live in a world of millions of interoperable blockchains so what I'd like to do today is talk about the future of those three different components and how different New Primitives like data availability and what's going on at Celestia with separating consensus and execution fit into what was the original Cosmos vision of a modular future maybe zucky if you don't mind talking about uh for a few moments the state of tenderment and where we see that fitting into this future comment Comet comment comment bft everyone um yeah absolutely so I guess the you know the like all right my my main thought process is so in a lot of ways this whole software stack was like designed in an integrated way with interoperability as like the end goal so we picked a consensus algorithm that had an efficient white client that didn't need a new Advanced cryptography techniques or new Advanced like zero knowledge proofs or New cryptographic Primitives like BLS signatures all of which were not very mature at the time but would still give you uh high performance uh like clients and bridges but we're also starting to see sort of the uh and so you know we built the system um I think like I'm talking a little bit about lunch about how um you know we sort of it is a the system was built with Bitcoin as like its only real reference point so like how do you build a Next Generation system from Bitcoin now we've got a lot with like in like the Bitcoin was the Bitcoin was very much the inspiration uh we are now sort of way past that um in in so many ways and really seeing the limitations of that system it's been a big breakthrough getting uh ABC I plus plus out the door uh which was the first big change to the uh consensus API and is a system like no one else is offering so it you know it is interesting that we still are able to like push the limits of the possible uh on top of this stack but there there there's a lot of work to be done and like you know where this stack you know like and what Ismail was talking about right uh you know the PD calculator was not expressive enough for to build Celestia so you had to build a Frankenstein of two P2P layers to build for uh uh Celestia and so as we kind of Advance towards the future I think we we're all gonna have to figure out um sort of where this software goes from here and uh how it sort of more or natively encompasses these different use cases thank you so continuing to like consider these pieces individually for the cosmos SDK do we need to consider alternative hosts for the SDK um and how do we 100x Cosmos uh with uh those Primitives yeah it you know want to call out Marco in his team who are doing great work on helping to expand the the cosmos SDK to help support more underlying data availability and other consensus algorithms that works extremely important and then on top of that also more VMS and you know when we talk about modular like this is what it means you want to be able to pull the pieces out plug new ones in and easily swap out those components and you know I think that the the sort of innovation of Celestia was making consensus breaking that down into different parts and like allowing those components to be swapped in and out and you know those that that does like require large changes to some of the software because I think when you're building something that's really easy to you know make assumptions and just like bake things in and um yeah it takes a little while to unwind that but a lot of that work's been done by the SDK team right now I think it's going to be a really interesting question to see like if the most value the most number of in in comet in the cosmos SDK is coming from common bft as a host or his role kid as always in like a year five years from now it's going to be a big I think that's like those sort of like one of the existential questions yeah so going back to kind of base later and security uh Ethan maybe you can touch on um kind of the merits of mesh security uh with uh all Cosmos blockchains uh that are IBC connected versus kind of data availability and consensus with uh Celestia and how those two interlinked sure yeah I mean I think what's Happening Here is look we um we had to First create the inner chain right so we had to stand up a bunch of I mean Once Upon a Time the multi-chain was a sort of uh you know Blasphemous idea we had to convince people group mistake was going to work there could be many change that sovereignty mattered and and so on and that you know what we needed to do was sort of go bottom up build a general purpose interoperability protocol uh for these you know individual chains to start to connect to each other and now that we sort of have that we can start to explore the different ways to actually share security over that interchange that that now exists and so all of these sort of different solutions you know using accommodated availability layer using things like mesh security or interchange security or so on there are all sort of different ways to explore you know different areas in the trade-off space for sharing security Over The Interchange right and I think the reality is we don't really know yet um how it's all going to shape out there's going to be some kind of you know complex uh uh you know arrangement of all of these different solutions and you know ideally chains will be able to sort of choose for themselves which ones they want to experiment with and if they're even able to experiment with multiple of them at the same time right so mesh security certainly uh you know holds forward a promise of allowing sort of tighter economic integration between um different chains and allowing them to sort of strengthen each other's uh Economic Security by sharing stake data availability offers you know a sort of different way to uh you know to offload or Outsource Outsource a certain element of security that's less about you know sort of sharing between many different chains and more like okay let's use the security of one big chain for a particular function Outsource to that and then focus on uh you know on on what we're doing but I can even imagine that there might be some way that uh you know Sovereign Roll-Ups or something using da Celestia as a DA layer might still find ways to to sort of uh you know anchor other definitions of security to each other and share and I think we frankly I think we still have very poor definitions of security we use that word as if like we know what what it means but it means like so many different things and there's many different um elements to it and so I think a big part of what you know what we need to do in this sort of new phase now that the interchange here is to actually get clearer definitions of what uh what we're talking about and the kinds of security you know what that means what what kinds of guarantees are really being offered and how people can actually reason about them yep thank you Ishmael I think um your views would be really interesting here given that you know you were one of the original Cosmos members and now you're internally at uh Celestia um and how your views on The Interchange Vision have evolved uh being inside a Celestia now and how you see that going forward so how I see it is that actually so that's just like the um like continuation of what we built before right like um the the first component of The Interchange was the the cosmos up to so to say and um basically what we're building is what the Cosmos app could have been right like it's it's a it's a version um of of like the Hub that has like actually a purpose in The Interchange or like in in a like in this vision of like application specific chains it actually serves a concrete purpose which is um offering like the service offering of Celestia is essentially just ordering your transactions and data availability right um so yeah I think I think it's very like very logical continuation essentially and um I think I agree with with Bucky that is like a lot of um there will be a lot of like experimentation happening right and um um Celestia will be well I'm sure like Celestia will play a crucial role in there and like it will enable um a lot more experimentation particularly because you offload the execution to these like applications or like the app layer you you enable much more like experimentation with like zero knowledge stuff and like um different VMS essentially which I think is will be way easier if if um compared to having to stand up your own uh like Cosmo Zone essentially yeah I think that's basically covers it yeah thank you I think that um the continuation of the experimentation is uh really something I'd like to press harder on which is more is more for developers experiences to be able to customize uh as granularly as possible uh to build the best application experiences and I think part of that is roll kit I'm wondering if you could talk a little bit about roll kit that coming out of Celestia and what that means for kind of the the internet with blockchains sure so roll kit is um basically a drop-in replacement for Comet so it's like it takes these same abstractions as Comet bft or previously tenement which is like the main abstraction here is ABCI which is like application blockchain interface it is an interface between the consensus layer and the application right um so we took that abstraction such that Cosmos SDK developers can continue like using the economos SDK as they're used to and or like people who who want to use ABCI and like build applications in other languages like there were teams building in Haskell in Rust and like other languages penumbra is building like in Rust for instance and anoma um like all these like all these builders that are used and familiarize themselves already with with the with the uh with the stack with the cosmos SDK they can like continue doing that while um not are not being forced to spin up their own Cosmo zone right like they don't have to spin up like a proof of stake chain they can use a roll kit um as like a sequence of software like that posts data to bitcoin as we've seen before in the panel or Celestia or polygon of whale right like it's a it's a it's a general like more General piece of infrastructure that we build such that the ecosystem can flourish and like experiment with different data availability layers yeah awesome um so 100x in Cosmos is something that I think we're all interested in doing um part of doing that is connecting um non-native IBC chains Jack maybe you can talk about some of the work that you and the Strange Love team are doing uh extending IBC outside of tendermint and maybe we can take that a step further and talk about um new clients for IBC and and how we get to that future yeah sure uh I think also like there is this strong place for Comet or other classically bft consensuses within this world we're starting to talk a lot more about shared sequencers and in some of these other pieces and I think one of the beauties of the way we've built this stack is these modular pieces these Primitives can be sort of like mixed and matched in all kinds of different ways and the experimentation that's happening now is helping us optimize that developer experience make it as easy as possible for developers to spin up their own systems and then go sell Services into this interchange economy you know Celestia is kind of a bringing New Primitives to the table but also a novel combination of existing Primitives and they're selling that as a service to chains over some of these basic interfaces uh we're I've got some more talk this afternoon about uh modular IBC patterns and I'm going to dig a lot deeper into some of these topics but in IBC there's this concept of a client and the client does all the authentication hey do I know which chain I'm talking to did users send these packets over on these other chains and that abstraction is really General enough to put all kinds of cryptography in the in whatever the trust assumptions of your system are you can encode them into that client so with the roll-up world coming there's all these new trust assumptions there's all these new models for how to verify the state from these uh Roll-Ups and the work that we need to do with IBC to ensure that this internet of blockchains continues to be connected is to build out all of these different trust assumptions into these clients so that it enables IBC everywhere um you know the I think that with optimistic rollups we're likely to see a lot of the IBC traffic go through shared sequencers or other committee based Solutions compiling the the fraud proofs and all those things a little bit too heavyweight right now computationally because you need to run the full State machine over on your counterparty um and it's a lot easier to to go through a tender mint committee that's a shared sequencer but in once the the ZK role of Technology matures a little bit more I think we're going to see that become the the dominant method in a lot of ways and that model fits much more nicely in IBC because all you've got is this little CK proof you shove it into the client and you're good to go a lot in you couple that with this Celestia data availability sampling like client as well and then you can fully prove the state of that chain so um you know bubbling it up a little bit where we are right now is like all of these Primitives work they're just centering production um but I think David to your particular question about bringing that mass adoption that we really need to see and really enabling developers the work over the next year is to sand the rough edges off of the developer experience and allow developers to launch one of these Roll-Ups in five minutes and any one of a number of languages um and you know all of the pieces that everyone on this panel here builds are a huge part of that system and uh it's really cool to see it coming together yeah thank you um so right now we're uh at a point in crypto where there's a lot of infrastructure a lot of new infrastructure being built and all of this is in service of building killer apps and whether that killer app is money as Ethan suggests or it's something more web 2 oriented uh social or not we need um maybe a little bit more infrastructure to make these experiences better so maybe you can go down the line and I'll ask you what's missing foreign take a contrarian piece here and say I think a lot of the infrastructure that we need is here today and I think especially with breaking consensus into different pieces a lot of people have talked about Celestia and data availability as the in-game of blockchains like I I do truly believe that that is the case so I think really what's missing is compelling developer experiences in ease of use for all of these products because at the end of the day infrastructure is a product and products need users and if it's really hard to explain how all these things work then we can't bring in the users what a product does is take a really complex idea like money and Kofi or data availability and puts it into a very simple developer experience or the developer with a few lines of code can express this very complex idea in an instantiation in the real world and you know I think that that's really what's missing right now like we've built out the infrastructure we don't need five more consensus protocols like let's use what we have because it's plenty fast enough great um I would agree um zucky since you have such a great taxonomy of the now hundreds of uh well close to 100 uh blockchains that use tender mint um maybe 65 or so connected IBC chains uh application specific or not what applications are missing for IBC chains that would bring in those new users that would then create the flywheel for more developers to come in I mean I think there's an interesting thing that's happening right now which is like there has been I think there was like as a practical matter a real lack of applications in the internet of blockchain so we like built out this interchange Vision we had staking IBC transfers it was all okay great you saw all of these new chains spin up we basically had one popular application which was osmosis um and uh and then there were a lot of applications also in the Terra ecosystem and like a lot of the interchain application development was happening over in the Terry ecosystem so Terra ecosystem explodes last year takes down takes out a lot of the application ecosystem uh in the inner chain and then you are end up in this sort of like we've spent this year where there's kind of like nothing to do but stake um now I I think in the last like few weeks we've seen just like enormous number of new applications some of them are Terror you know come from that Terror world and are launching on top of Osmosis now um you have teams that are funded by um you know various accelerators and Dows all launching so there's actually now quite a lot to do with your assets um there's you know it seems to be like a renewed enthusiasm for nfts on stargaze uh and all of these things are maturing uh rapidly like the user experiences are almost acceptable they're about to become actually acceptable with sort of the apis that like Skip and it's built uh so on the whole I think we're like we're like kind of at an interesting threshold point where one of the biggest challenges that like Cosmos needs to overcome is sort of reactivating our user base we have a user base that has kind of uh you know sort of you know built a relationship with the software that's basically like oh okay it's just like stake and occasionally sell my staking Rewards or whatever now there's all this new exciting stuff to do about with the Stout with with your staking rewards Etc uh now is the time to like actually get them to go out and experiment um again this is the time to wake go out adventuring in the inner chain and I think that's one of the biggest challenges another big challenge though is all of the growth tooling to to sort of to do that like as a product Builder you actually have to go out and reach users and and communicate with them understand their needs uh get them to engage build growth funnels that infrastructure is also being built on Cosmos yeah um Ethan what's your biggest hot take in the cosmos ecosystem whether that's technically architecturally or from a user perspective putting me on the spot um that a lot of it I mean it's not surprising but I still think a lot of it is um really like vapid uh they're still it's so much just like assets assets assets what are we doing with our assets and we might as well be Bankers you know that's what Bankers care about uh and we're supposed to all be here to like change the financial system but we're just kind of rebuilding it um yeah it's transparent and it's more decentralized and open and that's really important but what's even more important is is the underlying uh structure of debt really that that we're um you know that we're replicating and uh and so I think until we we really break through the like number go up and and have like real applications that aren't just about that um you know we're not going to make it so maybe you all think I'm not gonna make it because you know I'm I'm uh I'm the guy pushing back against speculation I mean obviously I understand speculations is is important for bringing in you know users and excitement and hype and narrative and memes and that's the stuff that sort of makes the world go around but you know I'm still looking for applications that that sort of move beyond that that aren't just about you know finance and I think there's there's an opportunity now with the sort of impending collapse maybe of the social media Empires there seems like an opportunity to to get in there of course it's also fragmenting which is um sort of interesting but I I think that's uh that's an opportunity that this community needs to figure out how to how to address now arguably we need more scalable infrastructure to do that and so you know what's what's the thing that's missing infrastructure wise I was going to ask for for Ishmael and say Celestia launch but you know he can answer for me too um but otherwise you know I would I would tend to largely agree with Jack that there is a ton of infrastructure here it's just about making it um more usable and accessible for use cases that aren't just about speculation right like if you talk to like some people I was just talking to someone yesterday at um at osmocon who was like telling me how they're kind of embarrassed to tell their friends that they're in crypto right um and this is like a serious you know developer in crypto building like infrastructure and real stuff but it's like embarrassing and and I still hear this from from people you know sometimes we try to hire people from web2 and they're like oh crypto you know that's just a bunch of scammers and right and so there's still that yeah uh so there's still some of us are proud of it you know we all like djans whatever um we'll show you but uh you know so I think there's a real image problem I think that image problem comes from the lack of sort of more real applications and and uh and you know that's on us to find those applications and it's hard I mean the early applications are going to be speculative and and that's okay but sort of moving beyond that I think is the next the next big challenge for all of us to make this work so um I do think that's actually like one of the benefits of moving to this data to like modularity that is uh sort of underappreciated which is one thing that I don't think we fully grasped until like we saw it live was that the incentive structure of building Cosmos SDK chains meant that you had to build like liquidity and narrative around a token uh long before you had a product that was useful to anyone um at scale and so uh I think like one of the most exciting things to me about like sort of these modular architectures is you've seen this in the ethereum world where people are able to launch apps build or build and build an app check you know build an application build an environment build a community uh build a lot of excitement typically a lot of excitement about the coming future airdrop uh but nevertheless uh that's a different sort of uh expenditure of energy than having to sort of build liquidity around a token right from the get-go um and I think we're gonna and and sort of the modular infrastructure and the way in which you sort of pay as you go for using that modular infrastructure rather than having to like build this like huge upfront cost um I think a lot of it was always described as like oh it's really hard to get validators I think most of us have experience that getting validators is not that hard there's like hundreds of them they're all looking for some new thing to speculate on which is your token um and you know they're all that's the that's the structure of their business but getting but like having to devote time attention energy to like liquidity of an asset and narrative around an asset before you have a product is just a huge disservice to everyone and like feeds into only building speculative applications yep I would agree um Ishmael maybe you can uh talk a little bit about um as we're seeing basically every ecosystem or L2 Converge on these modular Frameworks um Cosmos having started from a different perspective which was interoperability first ethereum having started at share Security First how you would position Celestia against other da Solutions building on ethereum versus building on Celestia and other Cosmos related blockchain Primitives yeah I think um Celestia is the least opinionated right like it's it's like tries to be as neutral as as possible by not like enshrining a settlement layer for instance um I mean for like other pure data availability layers then the main differentiator I guess like is that we probably the first like they would go to market and like the first attack has um certain features like data availability sampling live uh and running on like a test net so I I can't predict the future like like on on on how this like ecosystems will play out um but I'm like like I'm I'm a bit biased but I'm obviously convinced that um like the the features that the team the um the being like early like I mean Mustafa came up with the paper in like 2019 that the groundwork was done in like 2018 we've been talking about modularity long before it was like a buzzword uh or conferences being been made right um I think that is the main differentiator is like the tech and the cloud that we have yeah just to tag on to that if you think back to the the 90s we had Microsoft was the dominant operating system and that was like just one ball of closed Source software that nobody really knew how it worked it was incredibly tightly coupled and they built this whole ecosystem around that Linux came around it was a set of composable modules that allowed you to plug in any hardware and easily integrate that and Linux like grew a lot slower but it's ended up taking over the market for operating sources and Computing and I think that this is very similar in Cosmos we've come at this from modularity first and so let's just kind of taking that to the next level but in ethereum they started with this idea and it still is the fundamental idea in ethereum and you see this with the L1 L2 dichotomy l3s even people are talking about now that's being pushed the centrality of ethereum within that Vision has always stayed if the asset and eat the chain both of those instantiations are what everything else in the ethereum ecosystem sort of aspires to filter down to and when you build those assumptions deeply into your software it makes building actual modularity much much harder and I think that that's the advantage we have is we've built from that place from day one we've learned all the hard lessons on how coupling makes expansion difficult and we've had to push through a lot of those software barriers and like help make better interfaces and you know like yeah anyway it's a slightly informed thought but yeah yep um Zuki what uh what's the future for general purpose l2s on ethereum say we're all in Cosmos because we think that Roll-Ups or blockchains themselves will be application specific so what's the relationship between ethereum base layer l2s l-freeze and why developers would would need a gen L2 so I think like the my general view of general purpose l2s is they are meeting a need for rapid prototyping um ethereum itself as ethereum has gotten more expensive and has developed a lot of and as frankly like developed become a playing Ground for like large dollar value real use right so like large counterparties do use ethereum to like move move large amounts of money um uh and use like a set of of D5 building blocks to do so um the rapid prototyping sort of environment of experimenting with new applications I think one of the hardest things like you know one of the biggest challenges we've had for Cosmos is it's probably not the first thing that a new team should be building is an app chain like a general purpose environment is actually probably a better place because you have to sort of don't have to invent the world and you have to like fit you can figure out your uh uh product Market fit you can figure got who your user base is you can build your community and so I think the model of dydx is really like the model for the app chain world where d-way DX the app chain is dydx V4 and there was V1 and there was V2 and there was V3 and uh V1 and V2 were a general purpose product built on a general on the ethereum blockchain using it as a general purpose Ledger uh V2 is an application specific L2 rv3 was that application specific L2 and V3 is an app chain right and you and they learned along the way what the application what they actually like what was what had product Market fit what were the key features what did you actually have to Target and build and that then you know making that one year investment where they eventually stopped improving the existing Legacy product and built the option version of it could be make sense because they had like all of this knowledge and all of this experience built in and we're all going to see how that turns out but that's a more plausible like way of getting there and so I think like the ex sort of like now you have like a bunch of you know you have a bunch of general purpose Cosmos chains where you have functionally like neutral where you have Neutron and Archway and osmosis and like all of these new general purpose chains where people are rapid prototyping new applications and some of those new applications may eventually pave the way to be independent app chains but that's sort of how I see the relationship um and most of the modular teams seem to have bought into it on the on across it where they are launching general purpose chains now and toolkits for building your future application specific chains exactly do you see path for going from um like a web 2 app first to then an app chain like instead of starting from like the evm kind of environment or something like that yeah I mean I think the only big the the real challenge is like I mean in all ways like building decentralized software is just a lot more difficult a lot more but like the the biggest challenge is you we like non-cons like self-custodial money monetary systems are such an important value and that's really what you have and whether it's the app chain world or the or the or the smart contract world is like can you plausibly build um in the but you know also you know you do it it uh you know as a you know where most of us are or like you know most of us are Americans are exposed to like sort of the western system which takes you know where you have a lot of financial regulation the minute you have custody um and that's also a big sort of barrier to building so I don't know like you you'll probably see more like I've been watching what's happening with this like unibot thing um I don't know if anyone I think more of the degens in the audience probably are following it but it's basically like it's literally like it started out as an application where you're basically just like where there's like you're just like giving your private keys to a a telegram bot right and like moving money through that uh but it does seem to be like developing into like a real thing um to come back to to Bucky's Point earlier like I think it would be nice if developing uh uh like starting on web free would be as easy as on webtool like asaki said it's like much more difficult currently but like as Jack also mentioned before like I think what we like infrastructure is missing is like to make that easier so I I believe that will be the case like it might be there might be trade-offs right like there will be trade-offs hundred percent um but like just from uh from from from the usability point of view I think it will be possible to have something like AWS kind of style where you you code your thing you click a button and your chain is running right like that that is like not too far-fetched at all there are people there are teams working on that right now so I think that will be possible and then there's no reason to start a web 2 if you plan to be like a decentralized app afterwards right I think just to like there's a couple orders of magnitude more developers outside of crypto than there are inside of crypto but I think a big part of that is the developer experience that's been most pushed in crypto is this evm developer experience is somebody's worked in web 2 it's a not a great programming language to work in and I think one of the another Advantage we have is an ecosystem is we've got this proliferation of other VMS and programming languages that you can write in JavaScript with the gorick go with the cosmos SDK rust with wasm and many many others and uh that is I think going to be key to longer term developer adoption offering these developers something that they're familiar with meeting them where they are and yeah that that's also going to be key so developer experience is one thing user experience is another I'm curious how you guys see wallets playing out in an internet of thousands and thousands of blockchains our wallets application specific is there one to rule them all is there a WeChat tile uh wallet for crypto um what are your thoughts there I mean kind of far out idea is that wallets are just top of funnel for applications so wallets go find the users and bring them in exactly how they do that I think there's a lot of white label Solutions out there already and you know you could imagine a convenience store launching their own wallet that has their loyalty program that's running usdc and that filters back down into the inner chain and you know while it is this term that I think we need to unbundle a little bit but I think the way that we talk about it most is that sort of top of funnel of the users there's obviously the custody pieces there's the the technical infrastructure that's needed to make that happen and all of that stuff is really cool but at the end of the day it's about eyes and clicks and tokens and that's users Zuki if you could snap your fingers and make one thing happen in the internet of blockchains to accelerate growth and adoption what would that be well I think it it would it would have something to do with the wallet conversation I think we don't really I mean I don't feel like I have as a builder a detailed understanding of consumer Behavior regarding wallets the way consumers behave wallets with wallets mostly doesn't make sense to me and when I and like so like things that don't make sense to me is like why is metamask so sticky like why is that so sticky and why is it that the user feedback um but like at the same time like why is it that like users are like hey I use Kepler and now you want me to install metamask to use the similier app and I don't want to do that either like very confusing to me like what what exactly it is because I don't personally experience it and like one of the biggest challenges I think we have in general is that like we like a big part of like where application Builders lose contact with their users is in the wallet infrastructure like we have this third-party piece of software that we don't really have control over um like we we push a user into it and then like we maybe see the output but we don't know what goes on inside of it and it's like it's a real blind spot in understanding sort of consumer Behavior so like what wallets have to be like such that users will Mass to adopt The Interchange is I think like one of the like that is like one of the biggest pieces and we just have lots of theories um and those theories now need data to sort of validate them um and it's hard to get visibility into that I think that in the same way I was talking earlier about the ethereum community having this uh like core ideal of uh everything kind of filtering down to ethereum and how that shapes their world view in web 3 so much of what we do is a reaction to what we what we all really don't like about web2 and I think we have a lot of blind spots when it comes to some of the good things about web too and what Zachy is talking about with tracking users is a great example when you're an app and a user clicks through the wallet connect there's a lot of missing analytics in that flow that don't allow you as an application Builder to understand what the user behavior is and how you can help improve those user experiences and you know it's the same thing with the programming languages thing like we need to meet those users where they are and yeah it's that's a key message I think the thing that's Skip and is with ibc.fun and then they're announced Kepler integration is you know like I I was saying you know like one of the biggest pain points of Cosmos right now is that like there's this website tfm.com that no one has ever heard of but it makes the IBC ux 100x better um and it's like mostly what I use to interact with IBC now I used to use like the osmosis deposit page or whatever and and those sorts of things um but now we have I mean like that experience much of that experience is now coming also to be integrated into Kepler how will that change behavior um is I think is going to be a huge like data point so how do we bring those users in for uh things like TFM or ibc.fun if we don't have any insights into that behavior if you know we're in blockchains and most wallets are pseudonymous uh unless they're docs how do we gather any insight into uh topple funnel uh business development for applications and preserving privacy on the other end I personally think like um I I mean tracking users in in the browser like opt-in is an option show like Telemetry and stuff that would certainly give us insights but I think like it could start even much simpler you could like just do usability research talk to users do focus groups it sounds very like naive but I think you will catch most of the uh uh flaws of like our thinking of how users interact with things and they're actually interacting with things like I think you'll catch like 80 of that just by like doing proper usability research and I think that should be done independently of like one ecosystem it shouldn't be like driven by like oh we want to like figure out metamask we want to figure out Kepler it should be independent of that like here is a user they want to interact with like an app or web free or something and um it should be independent of these ecosystems in my opinion I think that would already move the bar much higher uh this is kind of really side but uh zoko from Z cash is one of the people I've seen do the best job of this every time you meet somebody for the first time he has them install a zcash wallet on their phone and then synthes ecash and he times every step of the process and keeps a record of all of these and like this type of focus on user experience is missing in a lot in a lot of I I think there's also like a kind of an interesting question like I don't think we're really clear on what the top of the funnel is for the modular ecosystem is the top of the funnel like ethl1 users or like so or like monolithic blockchain users is the top of the funnel like social media is the top of the funnel like web 2 application users it's Tron payments in Asia quite probably yeah not a joke you're right a quick survey how many people in the crowd raise of hands has a Kepler wallet yeah pretty decent amount okay maybe 80 90 um zucky let's close on this design uh tell us how to get into the cosmos ecosystem what is the path of least resistance as a user um Cato and Squid those are those are the things like uh squid router is great for bringing assets from any other ecosystem onboarding from lots of place Cato is a great Koto is a great experience for onboarding from uh Fiat um you know if you're in like sort of depending on jurisdiction et cetera but I honestly think that like again the one of the missing pieces like I know a bunch of ethereum people got excited about bad kids and wanted one they were all like how do I how do I onboard onto Cosmos and I was just like squid that it's like it's it's that easy an answer I think more support you know like with like uh uh uh the the worm chain and uh and like noble coming on wine and stuff like that there's going to be more options to that but that's right now the best you couldn't get them to install Kepler they did no Kepler was fine they couldn't figure out how to get assets into Kepler okay and you know this is like those core pieces of infrastructure that have gotten built out one of those is swapping forward on osmosis where users can send an IBC packet and have it swap automatically and send those assets out so in this particular flow you want to buy bad kits on uh stargaze with stars you need those Stars somewhere and you need to make those IBC transfers but the automation makes that easy it makes it a single transaction on ethereum for the end user and they end up on the Chain they want in the asset they want that's a key experience yeah and I don't think we're that far from being like I will I have eth I want a bad kid and like you don't have to do anything other than like sign and intent or an order or whatever and that and then there's like the infrastructure will just take care of it we're really not that far from that feature cool so if you're in ethereum go to squid transfer some assets over by a bad kid if not uh go to Cato install Kepler come on over to Cosmos we have a lot of fun boxing matches included um I'm sure everybody is hungry and looking forward to lunch so I want to thank everybody on the panel for all of your time and you guys for being here and um have fun today thank you David for moderating thank you foreign foreign Hello friends welcome to day two afternoon or morning of the modular settlement this is also known as pbs.day in fact um in pbs.day we will be talking only about peanut butter just kidding not that one public broadcast also not that one no copyright infringement proposer Builder separation we have a naughty speaker today who is recoining it into prover sequencer separation something along that line not sure so it's up to y'all to listen to their digest of the architecture of a particular Market structure that specifies the roles of the protocol actors and non-protical actors and trying to resolve an inherent conflict of interest of those who have the power to be the information fiduciary as well as the responsible for the execution so without further Ado we'll first start with tarun giving us a grand unifying theory of Mev last I heard and starting from there we'll dive into PBS land thanks okay um I think maybe these will show up there we go cool um cool so yeah so we're going to talk a little bit about something I've been uh probably working on for a few years um at this point which is to try to really come up with a good understanding of what the what the word Mev means and if you try to really formally Define it mathematically it turns out to be quite a bit uh difficult but it turns out there's a bunch of different components to it and this is the second of some number of parts I'm not sure how many there will be in the end [Music] but uh you know oh I guess this is a these are the the old ones you know but uh so basically the the idea is that you know understanding what Mev is from an incentive mechanism standpoint involves really undersing many different applications right there's of course the most common type of Mev with amms but amms of course add a ton of different properties that make it easy to understand them there's Mev for Liquidations in lending protocols and Perpetual protocols there's Mev for front running nft auctions all of these things have different sort of levels of understanding for the user and in theory right blockchain is supposed to provide audibility properties verifiability properties and other things that form to users so you might say how is there uncertainty that can come from from these things um so I like to to think about the uncertainties as falling on the Spectrum and the spectrum is sort of defined by how much the payoffs that users are taking uh vary and are uncertain and PBS uh is aiming to kind of change some of that uncertainty amongst the first four categories which are ordering inclusion atomicity and relaying so ordering uncertainty is I submit a transaction to a blockchain uh and I expect a certain payoff I expect to pay a certain price for a trade I expect to sell an nft for a certain price uh but my realized outcome is not that inclusion is censorship resistance like if I send a transaction does it actually get into the next block and it's slightly more severe than say just uh liveness which is I eventually get my transaction in I may want to have some time preference on how fast my transaction is accepted atomicity is of course the idea that I can compose two things under it's executed to sort of fill or kill like the entire transaction is executed or single transactions are executed relay which I'm sure you'll hear a lot about today is uh is the uh idea of having you know a networking layer and some sort of agents who uh who who convey transactions uh who may be more trusted than you think and I think that's certainly the the one part of the PBS system that we'll hear today has some of the incentive problems from many different speakers and finally since we're at the modular Summit we we should also remember the the highest payoff uncertainty for the end user can come from a DA layer if a DA layer doesn't work doesn't doesn't behave as expected you can have arbitrarily bad payoffs your roll up is not working as expected and one question you might say is like what does it mean to move from left to right on this diagram so just as an illustrative example and this is more a statistical learning theory perspective on this is is I have sort of a class of payoffs that's the script curly F I have sort of some functional say like a variance or some type of deviation and I have some sort of notion of the types of uncertainties and I say what is the conditional expectation of that functional and what does it look like what's the worst case so one definition of Meb you could use is any sort of mechanism that creates payoff uncertainties where unsophisticated users lose value relative to sophisticated users and the uncertainty is the key to the unsophisticated users uh expected payoffs so of course there's been sort of multiple different ways that people have tried to go about this um it's not lost on me that everything in the Communist side is only a paper and not a product and everything in the capitalism side is a product and not a paper so just as a funny aside but the communism side is things where the mechanism designers or the protocol designers are trying to enforce a lot of constraints on what types of orderings are allowed to be conveyed to the blockchain and the capital is inside the blue pill is how do you make a competitive market for transactions so flashbots sort of created that initially I guess arguably the the spam in the ethereum mempool prior to flashbots was the first version of this uh and then it sort of expanded and now we see this whole ecosystem built around this right so we have the red pill we have the blue pill are the really only these two options [Music] um well one thing that you know both purveyors of all parties will tell you that hey our mechanism reduces uncertainty for users it reduces payoff uncertainty it's easier for unsophisticated users or it's more efficient for the system as a whole but neither of these types of mechanisms neither the the full ordering complexity piece nor the economic piece actually can remove these uncertainties for users um so maybe we should take a step back and try to understand what fairness looks like in general so I found this actually very nice old paper from 1970s from from Hal Varian who's the chief Economist at Google Now um on you know distributive justice and Welfare economics and theories of fairness and the tldr of of sort of the principle of fairness he uses the maximum payoff for any particular individual is not so much greater than the average payoff average welfare of any individual and that's sort of the maxim for how to measure this type of uncertainty I look at the maximum payoff that any user gets I look at sort of the average payoff people get and as long as those two things are relatively similar you're relatively Fair um and you could argue that the the Communist the order fairness things focus on one side of this but they're very payoff agnostics they kind of can't tell you anything about whether you're getting the worst case or best case they just say hey well validator said you got this transaction first so I guess I'm putting in first Maybe and the economic mechanisms sort of focus on maximizing payoffs right maximizing Revenue that goes to validators maximizing Revenue that goes through the system uh but it doesn't really capture the externalities necessarily as well as you might think and so one question is how do you get this balance between maximizing Revenue which obviously can be good for the stability of these systems especially if they rely on Arbitrage versus making sure the expected welfare for all participants on average is not so far away from the worst case so one important thing to think about is maybe fairness should be done on an application specific level so the analysis we'll talk about is from the perspective of there being sort of fixed Universal transactions so adversary or malicious Wilder could have added or removed transactions before we analyze it uh and the only actions that the malicious adversary can take are reordering transactions so maybe it's I have a bunch of Sandwich attacks I'm reordering them so that the most expensive ones are first so that the later ones have to pay a higher price uh and the key thing that we'll talk about is we're going to view these as these kind of payoff functions that depend on a permutation and give you a a value a real number and that that's sort of the the fundamental objects we're looking at so in amms you have kind of this very smooth payoff with enough liquidity reordering doesn't really change the price impact enough and you can kind of smoothly vary how that looks but then on the other hand we have liquidations right liquidations are very not smooth you know if the price never touches a certain point there's no payoff to the user to say a searcher of course the price touches a single point uh you have a jump and discontinued in your payoff and so what we'll see is that these actually turn out to be the fundamental basis of all the payoffs uh of this form where you're looking at reordering so let's maybe try to demonstrate this in pictures so we take an amm like a unisoft at CFM and now consider a set of transactions there are uh seven transactions here and there are four transactions that are price goes up one unit those are the green bars there are three transactions that our price goes down one unit and as you can see if I permute the green and red arrows I get different price trajectories right and so you can see the first one sort of is like you know up up down down down up up and then the second one is up up up down down and at each point you can say given a permutation here's the price trajectory created by this ordering and so the x-axis is sort of the index as the transactions are processed so one of the the first part of the towards the theory uh sequence sort of showed that for amms this thing is actually bounded in a very interesting way in that provided you have a particular liquid deconstraint you the worst and expected Behavior are only separated multiplicatively by a factor of log n so that that sort of is actually pretty good um it means that realistically I'm not going to get that much worse of a price even if I'm sandwich attacked and that paper also showed some examples where people get better prices if they're sandwiches where someone takes a worse price but the end trades in the block get better execution and so there's sort of this somewhat surprising thing of course that these sandwich attacks these things that you know the re Jules of the world would call robbery can actually help the welfare of the system which is like a totally interesting and surprising result but the the thing is this doesn't really dictate all the other types of Mev right it doesn't tell you anything about nft minting it doesn't tell you anything about liquidations it doesn't tell you anything about cross chain so we'll start with the good onken like a thought experiment and the thought experiment is suppose we construct you know this is not necessarily a good D5 protocol but this is just one that you can analyze and so you'll see why this is important but imagine I have an amm I have two n Dex trades uh half of the trades are plus one so half are the green arrows half of the trades are minus one down arrows and given a permutation I get one of these charts right one of these three things you can see how like permuting the indices gives you different price trajectories right and if the price trajectory touches the red line the liquidation has a payoff of one and if you don't never touch the red line at zero so the idea is this is a very simple thing where I like say I give you some trades I look at all the permutations if it ever touches a particular point then you realize uh again if you don't you realize the loss so what you can do is you can kind of look through the sets of permutations say okay does this one give me a loss no yes does this one give me a loss no yes does this one give me a loss yes and I somehow found some Mortal Kombat uh fonts online and I wanted to write you know like you know the Finish him finish her thing I I figured writing liquidata in that font would be fun uh so one very very interesting fact is any payoff function that you can write in a blockchain that is a function of these reorderings of these permutations can be written as a linear combination of these liquidation games so any payoff that means for any application is written as a sum of these different liquidation games that's sort of something that's very unintuitive that that the these kind of very abstract things that you find in D5 for people taking leverage somehow are a basis for the set of all payoffs you can get but the interesting thing is the liquidations are much worse than the amms and amms we showed this thing where it's bounded by log n but in liquidations I can construct something where it's actually the ratio of the worst case payoff to a user versus the average case is O of n factorial which is obviously significantly worse uh you know you know with needless to say that's not really an ideal thing so that sort of says this idea that the space of these you know welfare metrics that you're measuring on users can vary quite a bit uh and again a lot of the kind of things people have made and said that would fix and make things more fair don't solve this problem like none of the ordering schemes in the Communist column actually can can correct this so you might say okay well what do we do to actually measure how fair these things are is there a way for me to say give me your function and tell me what the difference between the maximum payoff and the average payoff is and and give you some guarantees on fairness and so we'll we'll see that sort of some analog of a Fourier transform is the way to do this so one thing kind of just as a a reminder or you know if you haven't seen it well what what it what is the traditional Fourier transform so you know if you think about sound waves what you're doing is you may have this turquoise curve that represents the analog sound signal you're hearing but you can decompose it into high frequencies and low frequencies so maybe high-pitched voices and low pitched voices represent the red and blue curves and the Fourier transform lets you take different segments break up the curve into pieces and say okay this is the sum of these different components you might say what does that have to do with Mev it's like a smooth curve and someone's singing and all sorts of things like that but the interesting thing is it turns out all of these payoffs under reorderings you can write as the sums of liquidations and the analog of the the sinusoid curve the single pitch is actually a liquidation and so the high frequency modes are liquidations where there's very few permutations that can trigger them very few reorderings and the low frequency modes are ones where there's many permutations that trigger them so you can kind of think of it as it when I expand out of payoff I am looking at how constrained I realize that particular payoff uh uh and you know again like as I'm saying this is sort of a fundamentally in important thing is that something that we understand relatively easily and that people do in practice liquidations actually generates a set of all payoffs now this expansion might be very big right I have a sum over a subset of subsets of permutations there's two to the N factorial of those so there are many of these you might need to expand it but the key is that this is a basis like it represents the the core set of all these payoffs and I I put examples of people involved in the algebraic versions of Fourier transforms uh as pictures so one question is what do we again how do we interpret this Fourier transform like what does it really mean so one way of thinking about it is the Fourier coefficient f-hat and these are sort of heuristics there's a lot you know the Fourier Transformers over finite groups is quite a bit different than the continuous one is if a for a set is large of permutations and the Fourier coefficient or that set is large that sort of says the permutations have the function achieves its average value on those if the set is small but has a very large Fourier coefficient you're near the maximum value and so the idea is that this is why the spectrum of this thing captures what the maximum and average values are of these functions so you know there's a bunch of things you might need to talk about these we're definitely not going to talk about them and since uh it's a Celestia conference I had to put uh Jake Jacob always says weird aphorisms uh such as none of these words are in the Bible so I I've he he's mad at me though for picking this picture but it was if it's the first thing you find when you Google his name so uh you might say okay great I have this Fourier transform I can take any function you give me in a blockchain I can sort of write it as a sum of liquidations and that's like what the user gets paid but that's great but like what does that tell me about bounding the difference between the Max and expectation uh many of you may have heard of things mimetically like uncertainty principles but uncertainty principles exist outside of just physics in fact they exist in information theory in general as these sort of lower bounds on localization so I can I if I can squeeze a function and make it very sharp I can't make it's Fourier transform super sharp also and a very nice thing that turns out and this is exactly why we're you know the all of the stuff we're talking about earlier is important is a liquidations generate all the payoffs B the Fourier transform it gives you a way of going from your payoff to the payoff represented in the basis of liquidations so the Fourier coefficients really give you how to expand it in terms of liquidations and see the uncertainty principles give you a bound on the max over the expected value over the max value which is the difference in payoff for users so this gives you an explicit way to quantify this type of fairness and you can kind of think of this inequality as showing you fairness bounded by sort of these spectral properties uh I didn't want to go into any more details for this but you can read the paper uh but I'll just give you a very very tiny uh kind of understanding but the idea is if you allow a large enough number of permutations there's sort of a notion of the size of the number of orderings you allow is sufficiently large relative to the Fourier transform you actually avoid the maximally unfair payoffs where the expected value is extremely small relative to the maximum on the other hand if your sort of sets of orderings don't have sufficient overlap uh with your coefficients you will all you'll get a lower bound on fairness you'll always be at least some amount unfair and this sort of shows any of these types of ordering mechanisms whether they're the time-based ordering and arbitrum whether it's uh pure Fair ordering sequences whether it's sequencing rules they all only work for certain payoff functions right they only work if they they restrict the set of orderings to some set of order to a certain size set of orderings but that means they distort any payoff functions that depend on orderings with a larger size and so you get this kind of sort of Shannon sampling limit of like the payoffs are tied to how you're ordering algorithm you sort of can't you can't get a free lunch of like offering things like first come first serve and satisfying every possible payoff function which is what this says the second thing is you could think of this as like a sampling theorem so uh the sampling theorems are you know the most practical time you've ever encountered one of these is when you've you know maybe listened to an MP3 that sounds really shitty and then you go you know get a vinyl and you you listen to it and it sounds great and you're like oh why is the MP3 sound bad well the MP3 didn't sample enough frequencies for it to resolve correctly versus the analog and this is sort of a sampling it says like for a payoff you have to have resolved enough frequencies for you to be fair in that payoff so what what this sort of suggests is the Communist version of the world the fair ordering type of stuff things that are sequencing rules doesn't you know is always going to preference certain applications over other applications we always talk about Mev as being sophisticated users taking advantage of unsophisticated users I would posit that the Communist ordering world is sophisticated application developers taking advantage of unsophisticated application developers all you're doing is changing who the person who's enduring the penalty is because the application developer is defining the payout function and if they don't understand how all this works then they're they may have defined one that's extremely unfair on purpose and now you're forcing the application developer to understand that whereas that's not as true in the the unrestricted ordering case but what this says is application specific orderings orderings tied to these functions are actually can be better in practice and maybe that comes from marketplaces like Suave things that allow each application to specify some sets of rules as opposed to having these Global sets of rules uh and yeah it's much better than sort of some of the useless uh communist versions of things so what's part three well everything here is like a formal theoretical thing there's a lot of n factorials everywhere not all of us love Sharpie complete problems dot dot so the next part is approximation can you come up with measurements that you can make on real functions that give you some notion of measuring how much the Max and expected Mev are up to some error in production and monitor these types of metrics and see see how well people are performing and it's a paper so with that I actually finished 30 seconds early so if any any question yeah so you you gave this point about Council great point when I talked about the the O of log n thing calsop is achieving that so that's what I'm saying login is not that bad right like I If there's end trades and that and I'm able to knock it front run but I may have to pay in the worst case log in more in price multiplicatively that's not that bad paying n factorial is much worse right so like that that's the idea like this is like a way of quantifying how much the worst and average are and the point is once we can approximate these better you can run these on live systems and say like oh actually this particular payoff is like not that fair you should like loosen the orderings or or Shrink the orderings and the marketplaces can then adjust after that anything else if not thanks I'm around all day so [Applause] we I am zucky you've probably seen me already so uh I am this talk is like sort of a appeal to people who are protocol developers mostly but a little bit of sort of philosophy of protocol design and generally like my thoughts about like what constitutes a full node and the sort of changing uh uh definition so I've been working on building blockchain like protocols for 10 years uh I've written a lot of like I've contributed and worked a lot on different layer ones uh so uh that that's back basically my background and my general thought is that okay so we started out with this like piece of software that didn't come from essentially anyone in the present Community Bitcoin and Bitcoin worked a certain way and every blockchain Network that has been created since has been in some ways inspired by the Bitcoin full note by like that original Bitcoin software and its core property of the Bitcoin software was you have this notion of a full node and in the original Bitcoin sort of concept every full node is a minor uh so you have this whole network of binders uh everyone was connected to each other in an ad hoc basis so there were no like special roles it's just network of nodes this flat topology and that is how we've sort of imagined every every uh uh every blockchain since then but this hasn't been a true description of blockchains uh basically for as long as I've been involved in them um so instead there have been parallel networks like sidecar pieces of software specialized uh uh nodes uh everywhere like we couldn't use blockchains today if none of this existed uh so blockchains would be completely unusable um that's been true since you know uh since like 2013 2014 right you've had like Bitcoin has something called the fiber Network the fiber network does fast block propagation between uh with a completely different block propagation algorithm uh between mining pools uh there's mining pool software which has been which is incredibly important for the operating operation of Bitcoin you have things like Med boost and flashbots um so what this has emerged is is an enormous difference has has happened between the actual protocol like the protocol that our users use um and what's in the full node software um and the and that makes it very very difficult for anyone to like reason about maintain uh these entire systems um so just like to kind of uh so Bitcoin is actually like a pool driven block propagation system there's no widely distributed Mev tooling um but like mining pools are in charge the pr the like Network that actually matters is the network between mining pools uh the uh transaction propagation system is how mining pools is like how mining pools end up ingesting transaction um the de facto ethereum network is a network that has a consensus system and a peer-to-peer wear and a mempool that does not actually matter um because Mev boost builds most actual blocks and there's an entirely other network between block producers and relayers and block Builders uh that is essential to the functioning of the system uh and is potentially vulnerable to uh exploits but isn't part of the core protocol and then in Cosmos we have this thing called protocol owned Builders where validators Bill build and check blocks together with consensus enforced rules to do value extraction and it's actually cool because in Cosmos we do seem to be moving um to a large extent towards more parts of it the software being in like the core binary uh which is good uh and more maintainable uh but also uh also like sort of a represents better the expanding complex but we've had a lot of problems because our full node software was never designed to do this um so like questions I would ask is like why do we write blockchains that have mempools at all it's really unclear why we do this um uh Bitcoin was basically designed with this idea that like any node in the network could you know will once in a while produce a block so we need to disseminate by flooding transactions everywhere um we have uh like we really care about the like resilience censorship resistance and self-repair properties of p2b networks but it's probably the most poorly tested and specified property of any piece of blockchain software like you have all of these papers uh that clearly specify like the consensus algorithms the rules the attacks uh no comparable sort of uh material exists for the P2P networks um uh so yes why don't protocol debts put these overload networks in the core protocol um so the networking layer is the rest expressive spark of the stack wave of like these crazy expressive smart contract languages uh we have you know the ability to like uh we have very complex and sophisticated consensus protocols um but we don't really have much expressiveness uh in this part of the stack uh every blockchain team even invents the wheel they run into things that they can't build with like the existing software so they'll like slap on an overlay Network and like add it to the nodes as the way uh you know things and like sometimes those will have centralized Parts like in Cosmos when we have Skip and Skip has become sort of canonicalized into some of the cosmos networks but like that's it's not something people think about as like part of the cosmos protocol um so yes we have these like Frankenstein blockchains Ismail was talking about how Celestia has this like Frankenstein P2P Network which is part tenderment b2p part lib P2P and uh people are always building these things with like other custom components um so I do think that like PBS is just largely a good thing and the formalization of PBS because it's driving more Innovation and attention towards these areas it's driving I think enforcing the uh the P2P like Engineers to like do more on the networking level um it's forcing us to consider the entirety of the block of like the of the network and the protocol as a whole and it is allowing it's sort of getting us closer to a world where uh the entire blockchain behavior is like more formally specified um but again like we've been seeing attacks um so like I would argue that the direction of moving from like Mev boost which is a form of protocol Builder separation but not an enshrined one even though every single ethereum consensus client implements it um is uh sort of a worse solution than uh enshrining PBS in some form and we've already seen attacks on nodes and losses of funds and security incidents uh in the in the in the med boost system uh and that is would be better dealt with if it was part of the core protocol um I'm just like kind of the other thing that I would observe is that so in the spirit of modularity app chain Builders want a lot more control than like traditional general purpose L1 Builders ever had uh L1 Builders did not expect that they would be able to control the uh Mev for their applications um it's tarun was just talking about this about this like trade-off between sophisticated unsophisticated users and sophisticated and unsophisticated application developers well if you have a if you have a application specific blockchain the like you don't have to deal with that trade-off because like the team is the this application team is the team that built the blockchain um so if they're sophisticated they will end up wanting probably a lot of control and they'll want to have their own sort of fairness policy and they'll want to be able to like punish and Slash and observe um and so as people are building toolkits for modular blockchains people who are building toolkits uh for l1s I think we have an obligation to start building in more tooling into these systems to allow this kind of control to be expressed and like the fewer ad hoc systems that people have to build where there's like no abstraction in the full node the better things will be um so yes the fundamental goal modulism is lowering the cost of innovation it will hopefully result in more shared infrastructure there will be more libraries there will be more uh binary like pieces of software there will be more examples of uh Building Systems where like this block production and pre-consensus part of the network actually exists uh in the protocol in the core software um as we have like vendors for things like shared sequencing and intense mempools and execution like the more they can share components um uh it'll lower the cost of all of this uh you know the the sustainability of all of these pieces of infrastructure as like the market fluctuates up and down should be a concern to everyone um and is a big part of the long-term uh stability of the space uh so that's it thank you very much [Applause] thank you just got a bad kid's shirt you should get your own uh is it a talk text then okay uh Robert Danny okay I'm getting conflicting information does anybody have the what what's the Mev here maybe is here so I think we're unfortunately one of our speakers um due to bureaucracies um had been rejected had not been successful in getting into the Schengen area so she has to dial in for us but I think um this is an unfortunate reminder of the boundaries and that we live in and the world we live in and what we need to fight for all right I can't see myself um is is my slides up cool now I can see it all right um hi everyone my name is daning um unfortunately I cannot be there in person but um really glad to be here to share this um analysis or more like a data review about our current state of order flow blog building latency game um so I'm a data scientist at flashbots um quote I'll go through my agenda next um so I'll go through how a ethereum's transaction life cycle today look like with an Mev supply chain Theory or you can call it transaction supply network um and then the next is I will look at how the order flow market look like with cpbs or like Meb boost I mean your supply chain structure today um and then we'll look at how the block building market look like and how different Builders their behavior look like in data and also the latency game and time aspect of the blog bidding Market um next so we have two diagrams here um so quick intro about Mev and I assume everyone heard about Mev and PBS since you're in PBS day here today um but what is a menu supply chain um in the past in the proof of work day if you're making a trade The Miner had the full control about if they want to insert your trade or if they can insert any other Trader of their own or per their benefits to before to be before yours or behind yours um in the proof of stake date nowadays with a even more concerning problem about me we can cause centralization on stake and therefore call centralization of the network we introduced the PBS proposal Builder separation proposal and Mev boost is a implementation flashback from flashbots about it and the vanilla model of it is basically splitting the minor row into three rows from Searcher they will send bundles to builders and and then they will send um and there was in the Builder uh the builders will be for the full block and then propose to the validator validate will pick the highest value and then basically get the header of the block and then um settle it to um the chain and then nowadays with another thing called order flow auction this structure can even look like um like the one below where Searcher is sort of separated from this chain um basically they take a neuro as a bidder of the order flow auction but again the flow goes like user submit a transaction to the wallet wallet go through RPC potentially broadcast it to a bunch of Searchers or bidder and then they will try to search for the maximum extraction of this order and then submit a bundle to Builder and then to validator so this is a very how to say important structure that we should remember about the analysis because I'll go through each layer of the market next one please and so um How does a exact a user's transaction or order look like on a concrete example of an order flow auction we can use flashbots math share as an example here so you either user or wallet can submit in representation of user or a RPC provider they can basically send to a flashbot protect RPC basically an endpoint where you submit your transactions through which then actually make your transaction go through a private mempool and then it will broadcast to a bunch of Matchmaker Services which is the Mev share Services which will then broadcasted the transactions information based on users privacy setting to a bunch of Mev Searchers and they will try their best to see okay I'm trying to background this transaction without basically hurting users price and see if I can make any profits from making another transaction behind yours and then they will compete to send bundles to uh the math share services and then the service will try to compare what's the highest value um so to submit it to the builders um in the past flash brought started with submitting the bundles to flash plus Builder but for improvement on the inclusion of the transactions we also recently uh released a feature about allowing user to submit to any of the Builder their of their preference um in this case it will make the users sentiment to be faster and better and then the Builder will broadcast to a bunch of relay and then relay will then see who has the highest bid and the value they're going to take the highest one um even next one please um another example to make it a concrete concept on a DEX orders life cycle of today here's a lot of interesting thing to point out um so when the user comes into a Dax or a dexa aggregator what they will do is back basically they and we'll try to check across the differential liquidities on chain and of chain from their professional market makers that is quoting and making the RFK order for for the user they will compare the price with uni swap they will check what's the high what's the best price for your swaps which is why all the other MMS and then they will compare um okay this is the best order I'm going to send this to the public mempool likely as in the past how we operate the amm orders if they send into public mempool then will be broadcasted to everyone who is listening to a node and so here there's a bunch of math Searchers or basically you could call them whoever is like accessing the public amm orders will try to Arbitrage you or search search on this and submit bundles to builders another route is that if now Dex aggregator or basically the applications are submit their orders into a private mempool AKA OFA um then they'll have their OFA Searchers trying to background you you know in a much better informed and actually protected way um and then submit through bundlers and to the block Builders um so what are we what are we seeing here all these highlighted Red Blocks here um if we go next slides turns out today um in our current state is that pretty much the same entities the RFQ providers are market makers who are like professional trading firm um the toxic flow that is taking the Arbitrage on AML liquidities are market makers map Searcher block Builders are pretty much from a bunch of big trading firms um it doesn't sound so good um next slide please um and with the coming change in our um ethereum Network potentially account abstraction bundlers and maybe uni swap X fillers can again become the same players um that's some psyops next one please so yeah one conclusion or first observation is that the order is Flowing right now through a bunch of monopolies who are basically accessing each layer or basically they are touching the order flow in each layer of the markets um next please right um so another observation here is that um with some data analysis we collected in the past um earlier this year we were um trying to do a monitoring on the public mempool and we saw that um there are a bunch of transactions that got settled through different block Builders were never seeing mempool or in the public mempool which means there's a adoption going up for the private order Flow by different Builders we can pretty much see from January to March it grew from like one two or four percent up to seven percent per block Builders um and this data I assume will be only higher after all OFA launch in April um next slides please another angle of this data set is that when we look at different OFA order flow auctions transaction flow percentage out of all the evm transaction percentage we can see that pretty much like map blocker and a flashbots protect or flashbulse map share are having around like five six percent of Meb uh sorry evm transactions um out of um out of all the transactions calibra also have a few thousands every day getting settled um so yeah another observation is that private mempool will have adoption um going up along with the adoption of order flow auction um next one and then we look at the Block Builder market share um here the current summary will be basically it's a 2080 Market where basically a few leading winners are taking the majority of the blog inclusion share including rsync Builder Builder 69 Beaver build flashbots Builders and along with them there are a lot of new small and uh how to say strategic Builders coming out including like Thailand f1b we also have block Sprout and block native being playing in the blog bidding game for a while as well as important players um so pretty much we can see a diversifying of the participation of this block building game and then if we would summarize their behaviors in the next slide as a different type of Builder so we will be able to see that next slide please um so we'll be able to see that we pretty much can see a bunch of Builders they can Define they can be defined as neutral Builder flashbots runs non-profit Builder which means pretty much it's a very naive setting in terms of how you are transferring the profits in the in the line we're basically transferring everything to the proposer and include everything our bidding value it's mostly basically a bundle merging algorithm as of today there's also strategic Builder who are also neutral but they they may take more approach to be more competitive for example they may keep some profits from some more profitable blog when they know that potentially they're bidding higher than anyone else they may subsidize the block value when they know they're maybe slightly lower but they can win by just subsidizing a little bit they may attract also private order Flow by subsidizing and become better at inclusion rate and and we also have another big type which are I would say like the most competitive today as a block Builders which are Searcher Builder if you remember earlier we introduced this concept of like um in the math supply chain there's Searcher who are basically checking all the order flows and Mimi value or potential extractable value and then trying to bundle transactions with them as as their own private transaction flow um and then the next they will they will basically be able to submit their order flow to their build their own builder and basically to have a very exclusive amount of transaction which are highly maybe valuable so to compete with a Blog value which means those all those things are making them very competitive compared to others um next slides if you are trying to analyze or analysis their behavior on chain they may seem different for example if you are a typical Builder you pretty much going to put your address on chain as a recipient first and then you will appear as a minor basically for this block and as of today and but then in the end of the blog you will try to transfer as much as profit You are bidding for the validator to receive um as a transaction in the end of the block but if you are a zero profit Builder you pretty much don't even need to touch any of the profits you would maybe even just set the validators fee recipient as the miner of the block basically let them to receive everything to basically also save some gas next please and when we look at the open data set that EV boost is streaming for um everyone from each relay we can pretty much see that Builders um they have different behavioral preference in terms of which really they are connected to or submitting their um blog bidding to but pretty much every Builder would want to have a higher or better coverage of different relays and then most of them submit to the three major relays like flash files and Builder 69 but we also see rsync and the Blogspot there are submitting to five or even seven pretty much like every relay so to you know make sure they're competing as they're at their best um next please so there's a few more metrics here that's very interesting which is like when we talk about the time aspect of the bidding um it's a whole latency game for you to be competitive and taking the the basically like sniping at the very last uh second right before the validator is checking which block is the most profitable um so we call this validators get header timestamp which is basically whenever the validator is checking okay what's the available best uh bit I'm I'm getting right now um and they're checking with the relays and it's very interesting to see that different validators here they have different behavior in terms of when they will prefer to check the get header some may have very consistent data points of when they're gonna check it and that actually very interesting uh very interestingly a result into Builders Behavior which is basically they will never actually bid from the very beginning of the slot but only at the very few minutes of a very few seconds which is when the validators will check the get header um our flashboss builder in the past were pretty naive to check since the very beginning of the thought but we made some improvement after this um you know realization and we updated the bidding time to be um let's say as same as wrong like minus three seconds pretty much um next one please and another aspect is that if you check um how frequent each Builder can update their bids um as basically their bidding latency next slide please um we pretty much see that this is a block box plot of different Builders updating time for the latency basically a bit updating latency chart if we Zoom to the next one we can pretty much see the number here that on the very left on the very left and on the very right beaver and rsync are the one that has the highest performance where they can update their bids within 200 milliseconds or 100 milliseconds which makes them to be able to react very fast towards the market whenever they see a price shift say on centralized exchange their Searcher will be able to prepare a new bunch of Arbitrage transactions and then update their blog from their Builders this also caused a very interesting observation in the next slide is that with some improvement in some relay like optimistic relay from ultrasound which is basically allowing the Builder to skip a few hundred milliseconds by adding some collateral deposits we are able to see that Searcher Builder especially can benefit from this Improvement large safety if we see here the blue line is a wing rate of their optimistic submission and then the orange one will be the normal one so it can be even like seven or eight times higher um when there are so many optimistically um but yeah again like right now today only Searcher Builder can benefit from this Improvement because there are only one that can react this fast and update their strategy um yeah a few last metrics about the relays relay also um as of today they are supposed to be the one that's not taking any profits from the Meb supply chain but also taking uh taking a very important role of validating the blocks they are receiving from the builders um as of today a bunch of players are running a bunch of relays the the biggest one are flashbots gnosis and ultrasounds we can see pretty much how the Sun is the leading one here with a bunch of improvements I'm taking a quarter of market share and then it's flashbots next please one very important thing is uh for Relay is that the adoption from the validator side basically how many validators are checking the bids from the relay is pretty much a metrics here to show flashbots has the highest adoption as a relay um and then Vlogs around Max profit ultrasound analysis um next please on the time scale we can also see that like across different slot time we can see like per every 100 slots uh we can see flash rods having around like 90 and a little bit higher adoption by all the validators across a 100 slot um and then the next is blocks route Max profit and the gnosis and ultrasound um one last metrics here is that we can also see that the diversity of how many diversity of the builders basically how many Builders are submitting the bids towards a relay matters in terms of like how many total submission you will get naturally and also we can pretty much see ultrasound and Flash routes are leading towards the right and also are leading towards the higher market share so you can see a pretty strong signal here of the correlation um yeah so next please um yeah that's a data review of all the layers of the market structures and my final note would be if you're if you're a user I should definitely check out the flash Bros protect RPC today and so to avoid uninformed Mev and potentially get refunds from our OFA service me share um if you're Emily share me Searcher I have a few memes for you in the end um yeah so um if you're a mini Searcher please send us bondos um if you click through the next four slides okay cool thanks no memes today unfortunately sorry Danning okay uh I'm Robert Miller my slides will hopefully appear at some point in the future and until then you are stuck in silence with me I'm told they are running okay uh so I'm Robert Miller uh I had I have a talk here obviously and in thinking about what to talk to you all today about I thought first should I say something about PBS it's pbs.day and I thought no you you probably have heard something about PBS before at this point you know about it someone else will talk about it then I thought should I talk about Suave we just released a a new blog post outlining an architecture introducing the mevm I thought well I'm not sure that's the most interesting thing since uh you can go and read my blog post on how the mevm and our latest design for Suave works and uh looking at the past schedule that I had this week it seemed that there are a lot of new chains and domains that are interested in integrating PBS and they're interested in knowing about how Suave can support them if they do support PBS and so that that's sort of the premise of my talk is how does suave support many different domains heterologist domains that have different virtual machines different ways of ordering and what is the architecture that enables that and I'm going to begin by giving you a little bit uh maybe these slides are a little different than I expected but I will Begin by giving you some context on the thinking behind Suave and where we were a few years ago when the early ideas of suave started to coalesce for flashbots something like late 2021 so this is kind of the the first idea Mev is fundamental it's fundamental to every domain and that's for a few reasons the the first is this ability that blockchains give you to make commitments and you can commit to pay for some arbitrary State and that then Alters the incentives of the party that's ordering transactions second is that we use this ability to commit as a part of a common design pattern in Building permissionless Systems so these commitments are a fundamental part of something like defy in liquidations you give a permissionless bribe to anyone who will update the state of your collateral when prices have moved or in crypto kitties you give a permissionless payment to anyone who calls a function to update the state of the system so this permissionless bribe this permissionless commitment that anyone can capture is kind of this common design pattern to the systems that we're building and lastly mev's fundamental because even if you don't have Mev on one domain there exists Mev between the boundaries of different domains and that creates value extraction opportunities you know if there was no Mev on ethereum there would still be Med between ethereum and BSC as an example so that was the first idea second idea Mev has these negative effects so rational actors pursuing their incentives pursuing these permissionless commitments that make you money are going to create negative externalities in their wake if you don't deal with it appropriately so that's things like priority gas auctions spam latency Wars that lead to wasted block space Network load at the limit it can destabilize consensus itself which is which is where Mev began with Flash Boys 2.0 economic centralization of um you know validators integrating with trade firms and sandwiching you know et cetera there's all sorts of ways in which Mev can have negative effects if you don't um if you don't properly deal with this and we unfortunately have a slightly old version of my slides but we will roll with it um so what do you do about this uh this uh what what flashpots is trying to do is our project called Suave so that stands for the single unified auction for Value expression it's our project attempting to address this this really ambitious problem of Med being fundamental to you know every single domain and having negative effects and there being many different types of domains in the future that have heterogeneous different designs so you know there are non-evm chains there are chains that will order with first come first serve and we can't just copy paste flashbots and and other people's Mev infrastructure to every single domain how do we offer Med solutions to many different domains in a way that is actually decentralized and um you know what I want to get across today is that there's these two key ways that Suave addresses this in in the broadest way possible and again we're rolling with an old set of slides but that's fine so the first is the medm we just announced this last week it's this modular expressive composable programming framework that allows developers to leverage credible and private compute and I'll dig into that a little bit more in a moment but what that means is you can take what is currently centralized off-chain Mev infrastructure and turn it into a smart contract on a decentralized blockchain and the second is what we call execution predicates this is arbitrary preference expression on the execution you desire again we'll dig into that so first the mevm it's a modified version of the evm that flashbots is launching we've taken the normally evm we've added new pre-compiles to it for Med use cases that's really useful because by exposing every primitive in the Meb supply chain as a pre-compile you can program your Mev infrastructure as smart contracts on on a blockchain which you think is really cool and moreover you can do it within the familiar developer tooling of the evm you can do it in Foundry you can do it in your normal developer environment and it really lowers the barrier's entry of deploying new applications because anyone who knows solidity can do it uh so how does the mevm work this is what the architecture looks like there are a few stakeholders a few components I'll run you through each of it it's at the core of suave is this medm chain that we're launching again it's standard evm with extra pre-compiles for Med use cases that's things like take a transaction simulate it return me the result we have a confidential data store in the middle you can think of this as a data availability layer where encrypted data is stored because there's too much data to store it all on chain so this is decoupled from the chain State itself and we have an execution node this is not a consensus node but it's tightly coupled with the chain it's a a node that provides private and credible compute that can be called by the medms pre-compiles and the the way that these different stakeholders interact with swab is developers Define contracts like quarter flow auctions block building algorithms centralized RFQ routers Maybe users send what we call bids that's a combination of contracts that they authorize to access their private data and some private data like a signed transaction and executors who are your arbitragers your Searchers Builders are looking at bids seeing how you can interact with them and trying to background them merge them do Mev things finally Suave produces blocks for proposers that are listening to them to dig into the notion of execution nodes a little bit more because this is a really important concept the actual chain swap chain itself stores what bids are pending it doesn't start any private data that's stored in This off-chain Confidential data store but it registers a user's bid so it's a user saying like hey I have this private transaction I want it included on chain and it also registers these contracts that developers have programmed their Mev applications in and those contracts when the user authorizes them are executed within what we call execution nodes where an execution node will read the the code of a smart contract and execute it accordingly I'll give you an example in a moment but as an example a smart contract might say simulate this transaction and allow a Searcher to try to background it and if the Searcher successfully backgrounds it send that on to a block building algorithm we run these execution nodes in trusted execution environments like in sgx to provide some level of integrity and privacy to it that isn't contingent on centralized trust in a party like flashbots um this is an example mevm contract so it's it's standard solidity with a couple extra pre-compiles so you can see here you know the the Fifth Line we get ethereum State something that you normally can't do within solidity we're we're deploying this on Suave chain but we can have access to the latest ethereum mainnet state it takes a bunch of bundles that are sent as inputs simulates them so it's simulating orders of ordered lists of transactions against ethereum mainnet State we're getting the gas price of those sorting them trying to apply them to a pending block so it looks really similar to solidity because it literally is but it is able to leverage these new Mev pre-compiles that call out to the credible private compute provided by the execution node in a trusted execution environment to let someone program a block Builder which right now is this you know monolithic thing off chain in solidity on soft chain which we think is pretty cool and one of the ways that we are thinking about uh scaling Suave to many different types of domains is that you don't need to only run evm type execution and execution nodes so you can have an execution node that supports wasm or you can have an execution node that supports any weird roll-up VM that exists and then users can program their smart contracts to call out to that within native evm on Suave chain so you can do block building for non-evm chains so long as you have these execution nodes for different domains so for every given DM we'll have execution nodes that that folks will run in the stressed execution environments and you have this single unified platform for writing Mev infrastructure that can access many different types of execution nodes and it's one way that we are attempting to address you know Mev across many many many many different types of heterogeneous domains the other way that I think is really interesting to talk about uh is this notion of execution predicates you may have heard this as intents or preferences before but this lets users Define arbitrary conditions that they want to be executed for so uh in you know familiar Ned use cases I want to pay X if transaction has 0x Baba is included in one block 100 I want to include if the or I want to pay only if this array is included or things that you can't do today which might be interesting for some use cases like I want to pay if my contract emits a log and why I'm talking about this is because this unlocks new searching strategies that you can't do with current Mev infrastructure today so as an example I want to call I I want to pay one eth if you call my contract and it emits a log provides an incentive for either latency or spam Searchers to try to hit your contract until it's successfully called right so you could deploy this contract on on Suave have a corresponding contract on a low latency domain where spam is the the dominant strategy and it provides an incentive for this Marketplace of people to spam your contract on your behalf so democratizing Mev search on other types of domains even if they're not natively integrated into PBS itself which is very interesting or across domain I want to pay for X State on ethereum and why State on arbitrum gives this incentive for Atomic execution across two different domains and and you know since you are programming this in solidity as a smart contract you can get as bespoke as you want with these execution predicates which is really interesting because Searchers can express or users can express conditions that are more complicated than anything the market currently supports at the moment which either incentivizes people to collaborate together to execute on these conditions or it incentivizes the creation of new infrastructure to be able to support more complicated types of prep Goods um so that was my talk slides got a little bit screwed up so I had a little bit more content but that's okay so thanks for listening that's how we plan on addressing many different domains uh for for Suave regardless of whether you are PBS or not PBS we have a couple different callouts here so if you're interested in integrating as a roll up please reach out if your developer interested in building Med applications on Suave please reach out as well wallets if you're interested in maybe redistribution Searchers for private order flow and that is a QR code if you want to if you want to work at flashbots so thank you so much really appreciate it I think we have Mike coming and talking about PBS next so thank you Bert um the correct sets of slides are up um on MAV Dot Salon so if you go to mmv.salon you can find the entire day's agenda with the correct version of the slides so for the alpha that you missed next is our chapter one the ethereum L1 PBS starting with Mike neuter on PBS r d romap hey everyone how's it going cool looks like the right slides oh this isn't the right slide deck actually let's see okay this looks promising oh no no this is this is the wrong slide deck Tina one sec Tina this is the wrong side our slides have been reordered yeah well at the meantime you can have a sneak peek preview on mev.s Salon just click on the slides you can help yourself foreign we're fixing some technical issues here curious I'm modular Summit how many of you are here um are working on ethereum stuff raise your hand all right what other ecosystems are you working on nice wait is that ethereum ecosystem ooh it's well that's fair anyone else oh okay sizable contingency right there hi friends are we ethereum aligned do you want to do it impromptu a lightning talk of two minutes of Solana PBS let's go okay now we have our favorite milady I don't know about favorite Milady but Amy lady all right hello everyone go back one cool yeah so my name is Mike neuter I work at the ethereum foundation and today I'll be talking about ethereum PBS r d roadmap so a quick sketch of my talk I'll first go through what we Define as PBS this is kind of a buzzword lately so I'll Define it in terms of what we mean for the ethereum consensus layer and then I'm going to run through kind of Rapid Fire style five implementations of PBS there are some overlaps between them we can kind of see that see the similarities but I'll present each each of them kind of in their own right and then after that I'll try and synthesize by pulling them together explaining the design trade-offs between each one the timelines and yeah kind of try and connect the dots in a way that hasn't been done very well yet because I think a lot of the proposals and the discussion has been scattered across different Forum posts and and Twitter threads so yeah that's kind of what we're going to go through cool so defining proposal Builder separation in ethereum L1 this is a post from metallic in June of 2021 so this was already over a year before the merge and the idea here is to keep the proposer set which is kind of the decentralized set of validators that are selected through proof of stake to propose blocks for a given slot and we want to keep them relatively unsophisticated so we want it to be kind of accessible for people to run these validators at home on on consumer grade Hardware without much sophistication on the other hand the builders are the people who are going to construct very valuable blocks and what this means is they're they're capable of of extracting a lot of Mev this might require liquidity on different exchanges it might require a lot of compute intensive algorithms because you know there's there's a lot of different permutations of of transaction ordering to try and so these will be highly sophisticated actors and the goal is to decouple these two roles to avoid the centralization pressure and what I mean by centralization pressure is that if we don't kind of formally decouple these two roles then there's very likely to be a world in which Builders collude with large staking pools staking pools are incentivized to do this because they can kind of benefit from the builders who are really specialized at extracting Mev so they get higher Rewards and the um the the builders basically collude with them and yeah the the reason that the collusion is able to be kind of credible is because the staking pools have reputation and this reputation isn't something that would be accessible to the to the kind of everyday solo Staker and this kind of fits into the broader picture of the vitalik's endgame post which is the idea that um block production is going to be highly specialized we kind of have to accept that and firewall off the the centralization from the decentralized validator set in some way so that's what proposer Builder separation aims to do cool so this is the first of the five designs I'll run through and oh I should say the the designs I like to categorize in terms of in protocol versus out of protocol and what that means is if if it's in protocol then it's something we change in the consensus layer spec it's part of like the honest behavior of being a validator in the ethereum proof of stake Network oops sorry oh yeah this is right um but if it's out of protocol then it's it's kind of like the sidecar thing that that the consensus layer isn't aware of but maybe many of the validators are are making use of so Mev boost is what exists today this is the software that was written by flashbots um right after the merge and the idea here is that there's a third party to facilitate the relationship between the Builder and the proposer and this third party is called the relay they broker the trust between the two and and conduct this auction to give the proposer the highest paying block from the Builder so Builders are sending blocks to relays relays forward the headers onto the proposers and the proposers commit to a header without actually seeing the block so the trust assumption from the Builder to the relay is that the relay doesn't steal the Builder's Mev the proposer trusts the relay to serve them a valid header because they're signing some some header to a block without actually seeing that that header corresponds to a valid list of transactions so the the trust is brokered there and the way they relays interact with this is they run the sidecar software called nav boost so boost um kind of interacts with the consensus and execution layer clients and outsources the block production rights to this external block building infrastructure called the relay and we see very massive adoption like great product Market fit for Mev boost so 95 of ethereum blocks are being built using this infrastructure immediately after the merge it kind of skyrocketed from from 50 all the way up to to near to nearly every block being built through Mev boost cool the the next design I wanted to talk about is kind of the original two slot PBS design and I would say for the for the past two years about this has been kind of historically what people referred to as enshrined PBS or in protocol PBS and this is a post from metallic and he presents this idea where you separate each slot into two blocks basically or two slots so there's a beacon block the beacon block contains some commitment from a builder to build a block and the intermediate block or the Builder block actually includes the set of transactions so kind of logically we're just splitting one execution layer you know update one set of transactions into two blocks and it's this kind of commit reveal scheme that that we use in Mev boost it's just authenticated and the kind of authorized through the protocol itself and the way the testing committee works is it the the testers are the people who vote for different blocks kind of saying I think this is the head of the chain and the testing committee is split between the first block and the second block and yeah the the partition happens and the the kind of tldr of this is that it actually weakens the security properties of the consensus layer and I won't go into the details of this now but because of this we thought of a new design and this is this is pretty recent this is a a few weeks ago and it's called the payload timeliness committee and this is another in protocol solution I should say the previous solution was also in protocol so these are these are changes to the consensus spec that that facilitate the the PBS implementation so this is this is quite similar to vitalik's two slot design the difference here is that we have a consensus layer block similar to before it contains a commitment to a builder bid the Builder bid just basically says like this is how much value I'm willing to pay to produce the Block in your slot and it also contains the header which is like a commitment to the list of the transactions so this is voted on with the the testing committee this is all like as it as it happens today the only difference is there's kind of a hole in the in the block where the execution payload will go and the Builder reveals the execution payload once they're confident that the Builder block or that the the block that the proposer proposed will will become on chain and then we have this thing called the payload timeliness committee which actually makes these votes to the timeliness and availability of of the payload so this is it's quite similar to before the differences are mostly in the fork Choice rule but the important thing here is we think this has like Better reorg Properties in terms of securing the consensus layer cool um now I wanted to present one other kind of out of protocol solution for PBS and this is what we're calling optimistic relay and the difference here is that instead of kind of doing the in protocol version where you go through EIP process you modify the consensus spec you update the client software and then you perform a hard Fork we have this this relay infrastructure that's already running we already have 95 percent of blocks using the relays so we can make the the relay you know optimistic we can make the the med boost relay ecosystem look slightly more like than trying to PBS version by changing the code that actually runs on the relay and reducing the relay responsibilities so this this plot or this diagram shows the block submission flow for map boost and you can see there's kind of a lot of tasks that the relay does and a lot of latency involved in those tasks so the Builder submits the block the relay validates the block against the execution layer and then publishes the box to the consensus layer client so the idea is how can we make this look more like epbs and and when we say epbs that's enshrined or in protocol PBS like how can we take the infrastructure today and evolve it towards what we want it to look like in protocol and the idea is we can just work from what we have today and remove some of the relay responsibilities so optimistic V1 we say okay take the block validation out of the system this saves some latency it also makes the relays easier to run because now they don't have quite the the operational and and compute costs of of simulating all these blocks very quickly and the way we protect the proposers is we say if a builder ends up submitting an invalid block that wins the auction we'll have some Builder collateral and we'll execute some out of protocol Builder slashing so we'll just say okay we're going to use the Builder collateral to refund the proposer no no problem like that's how we get around the removing the validity check from the submission the second version of the optimistic relay is actually removing the block download from the the fast path so in the same way before if the Builder submits a block or doesn't end up sending the entire block contents to the to the relay we say okay we're going to slash the Builder that's a penalty that will be able to use the collateral to to refund the validator and the end game version of optimistic relaying and these these diagrams are kind of wordy so don't worry too much about the details but the end end game here is that the Builder and the proposer actually interact through the P2P layer so they gossip the Builder gossips the bid the proposers gossips the sign bid and the relay essentially just takes a snapshot of the the mempool of the P2P layer at given timestamps and the tests to the accuracy and the timeliness of different events and really if you kind of break it down this is kind of what the payload timeliness committee does but it's just being done by the relay itself and the relay holds the collateral rather than the protocol so this is kind of the the molding of the relay responsibilities and the relay efficiency into something that should potentially be more compatible with inshine PBS okay and the last PBS design and again bear with me it will you know the remainder of the presentation is about drawing the connections between all of these the last one I wanted to talk about is called proposer enforced protocol commitments again this is an in protocol implementation and it's it represents a much more General framework for allowing proposers to commit to things in the protocol and it's actively being worked on by by Barnaby and Diego and the idea is that you use block validity to enforce commitments so proposers commit to doing something and if they don't fulfill that commitment in the block that they produce that block just won't be valid according to consensus rules so the the kind of cool thing about this General framework is that PBS can be enshrined through these protocol commitments so you can have a proposer commit to a builder and then if if the proposer block doesn't include that Builder's bid then the block won't even be considered valid so the difference here is we check the the block validity we use that to enforce the the proposer commitments rather than the testing committee cool so that was kind of a fire hose but hopefully the next few slides will help connect the dots and draw the the relationships between all these things so on the top row I have two slot PTC payload timings committee and Pepsi so those are the in protocol versions of PBS the bottom row is that boost and optimistic relay which are the out of protocol versions so PTC and tuslot are really closely related but basically we trade off what's called reorg resilience or this is part of like the consensus stability the consensus safety we trade it off for Builder safety so we're saying okay we want if we're choosing between these two basically we decide how much we want to give the Builder assurances versus how much we want the protocol to be to have certain properties to go from PTC to Pepsi we use block validity instead of a committee so this is kind of like who is doing the enforcement of these these commitments and these checks uh um and Pepsi is is doing the the commitment at the Block validity level on the bottom oh I should say also this is the heart diagram so hopefully that will become clear in the next you know coming clicks um the bottom we have Mev boost which evolves into the optimistic relay and this is just really Evolution and this is kind of already happening some relays are running optimistic some relays have have private closed Source versions of their software so this is kind of like already in progress of of happening and if we want to go from two slot to Pepsi we can kind of view it as a more General version of um doing PBS so Pepsi doesn't put any constraints on what the exact mechanism you use to do the PBS it just says have some some way for the protocol to enforce commitments from the proposer now the the left side of the heart is as Mev boost evolves into two slot or the payload timeliness committee we can kind of think of that as just enshrining the existing commit reveal architecture of nav boost into the protocol so that's like the enshrinement path for those two things is is through through that evolution and then the right hand side of the heart is evolving the optimistic relay into the payload timeliness committee and this is essentially just as I was saying before replacing the the relay responsibilities with the payload timeliness committee responsibilities and the cherry on top is Nev burn and inclusionless so these are kind of two additional features that that are hopefully going to be part of the protocol I'll give a quick overview meth burn is the idea that we want to take Mev and instead of giving it to the proposer we want to burn it so kind of provably destroy it through the through the protocol and inclusionless is a way we can say we want a certain set of transactions to be kind of force included into a slot so this is a mechanism to to enforce censorship resistance and both math burn and inclusion lists depend on one of two slot payload timeliness committee or Pepsi so that's why the three arrows the three dotted arrows kind of come down and and show the dependency between those two and and one of the in protocol Solutions and the key takeaway here is that you can't do either of those things with an out of protocol solution so that's kind of one of the big cons of of having this out of protocol software cool so that that was kind of like a mind map of the relationship between all of the the five designs I also thought it would be cool to kind of go through a few specific categories and compare the designs kind of directly versus each other I clumped optimistic relaying and Mev boost into the First Column the second column is just payload time in this committee or two slot and the third column is Pepsi because Pepsi is is kind of its own variant of of a design space so the first axis I guess we can evaluate them on is the time to ship slash the protocol diff so the Mev boost relay is already running optimistic relay roadmap is is kind of in progress this is something we can do now oh I should say the the three colors red red yellow or sorry green yellow red green is kind of good the good outcome yellow is the medium outcome and red is the bad outcome so which that's why I call it the traffic light Matrix um so yeah nav boost is already running it's kind of party in existence today PTC we think of as a relatively minor diff like it's you know there's a big change to the consensus layer but it's not so dramatic that it requires a whole consensus layer recall essentially and Pepsi is is really dramatic in so far as it allows proposers to commit to kind of arbitrary things there's a lot of design considerations around what what those commitments look like how those commitments are like encoded on chain etc etc and you can kind of think of Pepsi as almost like an enshrined eigen layer so there's all sorts of kind of tail risk at least associated with kind of opening up the the doors and letting people to commit to arbitrary theme things as proposers the next axis I wanted to present was decentralization so Nev boost is kind of by definition centralized there's only about eight relays that handle all the blocks and um you know the that's kind of part of the expectation is that there there's only going to be a few relays and a few builders that connect with those relays PTC is extremely decentralized in that it shouldn't change the validating role at all basically being a validator changes um like the the role that the valid data plays in the ecosystem has has very minor differences so in that in that regard it has the same decentrality decentralization properties that we have today from the validator set and Pepsi I put as yellow because there's a world in which Pepsi involves many more commitments those commitments might require higher compute higher bandwidth and as a result there might be kind of a competitive advantage of joining a staking pool that is able to run more infrastructure in the same argument or the same vein of arguments that that present eigenlayer as a potential centralization Vector in the system bypassability so this is the idea that there's kind of some way to to get around the mechanism that we design and for Builders to collude with proposers typically it's the process is Builders colluding with proposers to avoid any kind of tax imposed by the system or any inefficiency imposed by the system so meth boost I say is is not really Bypass or it's green in that regard because the builders already have close relationships with the relays the relays kind of do the Builder's job of connecting to the validators so there's not really any incentive for Builders as as currently existing today to go around the relay because the relay is essentially like subsidizing the Builder's job for them for the PTC I put it as red because there's kind of no way to enforce that the proposer actually uses the mechanism that we put into the protocol the relay infrastructure would probably still exist they could just Outsource their block production to the relay rather than using the the P2P layer to get their blocks Pepsi I put is yellow because there's a world in which the enforcement of the commitments and the set of commitments that a proposer can make makes it harder for the Builder to circumvent the protocol and in that regard it might be better in terms of bypassability in terms of censorship resistance I put Mev boost as red because there's basically no way to do inclusion lists there's no way to force through transactions in today's relay ecosystem but both PTC and Pepsi are like very very like out of the box compatible with inclusionless and that's the censorship resistant um yeah design that that we're looking forward to in the future yeah the next one is flexibility so in terms of what you can do with the relays I put it as yellow because it seems like there's a relatively large amount of things you can do but since it's out of protocol you can't enforce things like MAV burn you can't enforce things like inclusion lists so the relays can evolve and it's kind of a latency game where the relays are maybe competing with each other maybe um May yeah maybe updating their their software in a closed Source way but in in the same vein they're not able to do anything through the protocol because it's this out of protocol software the PTC flexibility is red because really we're just saying this we're going to take an opinionated stance on what we're going to include in the protocol and it's going to be this commit reveal scheme very similar to map boost and we're just going to kind of make it happen in in the short to medium turn Pepsi on the other hand is is maximally flexible because you're saying these proposers can commit to any arbitrary thing essentially and we want to give them the flexibility to to decide if they commit or if they don't and those those commitments are going to be enforced at the protocol layer okay two more unknown unknowns um from the relay perspective I don't really think there's any unknown unknowns because we're we're already kind of in this regime for PTC we think the spec change would be relatively minimal and and something that we can Envision kind of in today's world Pepsi I put as as red because in in you know I keep calling back to the eigenlayer thing but we're just really not sure what people will commit to we're really not sure how those enforcements um will go it has kind of increased slashing potential um there's just a lot less we know about the potential tail risk events that that this type of system enables lastly Mev burn compatibility this is something that I I mentioned in the heart diagram but the idea here is that in order to do math burn you need one of the enshrined versions so you can't use the relays as is existing today you need to do either PTC or Pepsi and to wrap up I thought just kind of like a tldr Vibe check on each of the three I would say that the relay approaches kind of move fast and break things this is like the the Silicon Valley style of we're all gonna to play this game we're gonna compete and may the best you know relay win PTC is more like let's get something in the protocol like the relays aren't very sustainable there's talks about relay funding issues and sustainability around the current existing framework like it doesn't feel like we're in an equilibrium in any way so if we if we decide to go ahead with PTC we could get something in protocol in the next months you know yeah hopefully months um and that's that's the goal of of the middle column the Pepsi version is this is kind of an aesthetic thing it feels correct in terms of protocol being maximally flexible and and maximally um idealistic in some way of of letting the proposers to commit to things but it could be opening Pandora's Box so we're we're unsure what we're getting at there's kind of these tail risk events that I mentioned earlier but it could be the right approach in the long run So yeah thank you very much and that's all well since you can't you did very well catching up on time let's take one question well looks like everyone is an expert in the future of ethereum all right well next up we have um vitalik giving us a talk about zooming into the Builder role what more builder can do and the future state of PBS what could it be but I had it ask since tanning's memes were cut so would you please give us a PBS meme to make it up a real-time meme challenge this is difficult uh yeah I do not claim guaranteed success yeah so to get right into things um yodog what's up who here thinks it's a ceiling who here thinks it's the ceiling that's up with exits the sky who thinks it's like a cryptocurrency okay well let's just talk about aggregation um okay so the aggregation basically the core idea here is you have N Things and you're trying to take N Things and turn them into one big thing which is less than n times as hard to verify right so sorry it's it's hard to speak and be yelled at for my poor microphone performance at the same time but okay so no one more reprimanded I'm throwing this out and you'll have to listen to me speaking quietly okay so what is aggregation right it's uh converting end things and turning them into one thing which is less than n times is hard to verify now why do we want to do this well because we care about scalability we don't want to pay like 88 dollars a transaction or even 0.80 in transaction and we want to like cut down on chain verification costs right there are a lot of different use cases of aggregation and so in the ethereum consent this way or for example we have BLS signature aggregation and there's many kinds of aggregation that we'll have in the future so some specific areas where we are thinking about aggregate we might have aggregation erc4337 right so this is this off-chain protocol by which um users can send in user operations that have validity conditions that are different from the yeah the validity conditions of irregular ethereum transaction you might have a smart contract well what validation it could be a multi-sig could be some custom will winter knits to import signature could be whatever and those conditions get verified and it's this kind of off-chain ecosystem for like basically making these custom Smart contract wallets work but these um user operations all have to be wrapped up in a transaction right because ethereum the base protocol only accepts transactions now before erc4337 in the dark old days we would have protocols but which every single user operation would get wrapped up in a separate transaction right so I send a user operation and then whoever I send it to would have wrap that user operation in exactly one transaction and then the transaction would go on chain every transaction would have a a 21 000 gas overhead so it's not very efficient it also was not a very open protocol in erc4337 we have a custom mempool where users send user operations into the mempool and then bundlers exist in that mempool bundlers grab up all the user operations they can see in that block and then they publish that on chain right so this is a form of aggregation right because the object that went in the cost of verifying that object by itself would be n plus 21 000 right and whatever the cost of the user operation is 21 000 for the wrapper but if you take like let's say K of these and you put them together then the cost is just going to be n times K because you still have to process all the user operations actually sometimes a bit less than n times K because you can benefit from like warm uh cold uh storage reading gas stuff but and then plus 21 000 only ones right so there's some pretty significant gas savings from taking user operations and putting them all in the same transaction this is a type of aggregation and you know this is something that's uh actually being done even in the Builder ecosystem today BLS aggregation so this is a thing that actually has been recently a kind of in proof of concept mode it's been added to erc4337 there's a piece of code called BLS wallet that actually does this but the basic idea is we instead of using ecdsa signatures we use BLS signatures so why what do we want to do this this is especially valuable in Asia roll-up right because in a roll-up the computation is done off chain the data is still done on chain right and so the day the computation becomes vastly cheaper the data does not become cheaper at all and ecdsa signatures on their own are 65 times n bytes okay fine I'm using answer refer to the number of objects now and then with a BLS signature if you use G1 points for the signature then the signature can be 48 bytes four in arbitrarily large number of operations right um and so if you have like a hundred of these per block then for each one of them the amortized cost will go down from 65 by its per operation to like half a byte per operation on the computation side it actually does get a bit more expensive because instead of doing fairly easy elliptic curve stuff involving ads and multiplies um like I think at ecdsa recover as like something like three multiplies or somewhere in that range um but and instead you do a pairing which is like pretty heavy duty stuff but as I said on roll ups computation is cheap data is expensive we're saving on data and it's great right but how do we actually like do BLS aggregation right because the ethereum protocol does not currently have an execution layer BLS capability right and so if you imagine and different users each of those users is going to send their own BLS a user or operation and their own individual BLS signature that they created separately is going to be 48 bytes long right then what we want is we want the thing that goes on chain to b48 bytes we don't want it to be 48 times n right and so there needs to be some kind of actor that is grabbing up all of these user operations going into the user operations grabbing out the BLS signature adding them all together see that's uh let me know some kind of you know mechanism in the middle it's a big plus and you know create one aggregate signature 48 bytes and that aggregate signature can be verified against the aggregate public key which is created by taking all the public keys of the individual users and also adding those together right so this requires two types of weird stuff right the first type of weird stuff is the off chain Adder the second type of weird stuff is the mechanism for verifying these signatures we're basically instead of doing what ethereum protocol does today where you verify each of the signatures in sequence the protocol or whatever super protocol we use somehow would have to take these signatures then when you walk through each one of the yeah one of the user operations don't immediately just like verify pass fail it but actually record the BLS signature like first of all you'd verify it locally make sure it verifies individually if it doesn't you throw it out right but then record it and on and then if you're doing this inside the block here you just recorded right then keep walking through all of the user operations add up all of these signatures and then at the end do the one check at the ends right because adding two signatures is like very cheap it's like hundreds of times cheaper than um you know even and ecdsa operation right so the this requires like a different workflow where it's like walk through the operations then do a check and then execute everything now erc4337 actually already now has an extension to do this but this is again a type of thing that I call aggregation aggregation so this is the future right so BLS is like very specific what if I told you that in the future we're going to be able to take existing ecdsa signatures potentially even signatures that are made with existing tools and replace them all with a snark so it just says here is a signature and here's a proof that or or rather here is a proof that there exist valid signatures for all of these things right so this way you could replace an unlimited number of ecdsa signatures with like one snark and you could even apply this technique to other mechanisms right so um who here has used a privacy protocol um privacy Protocols are good right Now privacy protocols cost a lot of gas those cells one of the bigger challenges hampering their broader adoption right because inside of one of these privacy protocols every transaction requires you to have a snark that goes on chain now the synark 500 000 gas 20 times more expensive than a regular transaction at current gas prices that's going to be I guess about 20 gray multiplied by yeah 500 000 gas so that's uh you know 10 mil 10 million way which is uh 0.01 each multiplied by 1900 19 transaction fee who here is willing to pay an extra 19 to make your coffee more privacy preserving I'll do it as a gimmick you know um yeah so you know this is like not good right and so but what we can do is well we can use a snork to prove the validity of all the snarks right and so even if you have a hundred different users using privacy protocols within a block you just take their proofs you prove them all together and you have one proof of the proofs and now you have like all of the proofs of all the private stuff within a single block right now what does this require it requires aggregation right you need to have some actor in the middle you can that it basically takes all of these objects and replaces them with an object that proves the existence of all of those objects so this is all really nice this all increases scalability and this is all really good right so what does this all depend on it requires a builder ecosystem by the way who here remembers the cartoon character that this meme is based on Bob the Builder yay oh no he gets see him Bob the Builder needs more love you know like well you know we have like Barbie these days and you know we have like you know what else yeah there's all you know all the Barbie songs and like you know we need a Bob the Builder movie like did you really do like an Unchained Bitcoin bouncy for for a Bob the Builder movie and then like your zoo Pole to vote on the best one you know real world crypto applications please so yeah you know we need uh I mean we need Builders right Builders are you know the heroes of uh of ethereum block production right so okay final see I wonder if this style of Mike holding is better um so the block building ecosystem is actually really big right like we all kind of know that you know Bob the Builder is an abstraction and in reality you know there's like dozens of construction workers and then there is the people driving the trucks bringing resources over to the workers and then there's the janitor and then there's a whole bunch of uh other pieces of uh infrastructure and there's like really big teams that make up a construction company right so black building ecosystem looks pretty similar to that too right so basically you have a bunch of Searchers and Searchers all have their own different strategies for creating uh bundles that contain different types of transactions and then they all go together to a block Builder right and then the block Builder creates a block and then publishes it today to relays in the future directly to validators and like this is roughly how things work right now right and so one natural question to ask is well you know if we have a a builder if we have this kind of ecosystem then like who's doing the like who is going to do the snark aggregation or the BLS aggregation or erc4337 aggregation all of these things the most natural guess for the long term is like we'll have specialized Searchers right so we'll have like a Searcher that speaks the 4337 protocol and then we'll have a story show that does BLS we might have you know a Searcher that does a snork aggregation they might even end up talking to each other there might even be some multi-layer ecosystem where you know first you do the aggregating for the 4337 or for the BLS and the snarks and then you put that together into a bigger 4337 um Aggregate and that goes into a block along with non-4337 stuff but like I expect it will move towards something specialized like that but I also expect you know in the shorter term there's definitely going to be Builders so just like do this stuff directly right and there's like a I expect it going to be a growing array of these aggregation sub-protocols that gather these kinds of aggregate messages so challenges in these ecosystems right so we want an open mempool meaning a protocol that anyone can participate in right not um you know open in the sense of like anyone can you know see your stuff and use Advanced machine learning algorithms to like figure out when um okay what what should I even say here okay you know figure stuff out about you that you don't want to figure stuff out about yourself um you uh right you know we want a protocol that anyone can participate in for both users and for Builders and Searchers right we wanted to be open for users to send in their user operations we want it to be open for Searchers to participate and we want it to be maximally open for people to bring in new aggregation protocols now that does require them to kind of accept permission from one Builder or one Searcher but it should not require like Global permission from this from the yet ecosystem so that's a goal um and you know we want to try to avoid centralization and if centralization happens we want to avoid censorship now one of the challenges is that economics is weird right so in particular the issue here is that a lot of these types of aggregation that I talk about they have a high fixed cost and they have a low marginal cost so what do I mean what I mean is that if you think about like synark aggregation right if you put a snark on chain the cost of a snark is about 500 000 gas now that start can represent lots of things if that Stark represents one thing it's 500 000 gas if the snark represents a hundred things it's also 500 000 gas right it's fixed cost now the other thing part is that it has a low marginal cost the marginal cost does exist right because if you're approver then you have to like run more proving Cycles right like if you have to prove five more things the cost of doing the proof is five times bigger now this is you know if this is a cost but generally the uh these off-chain costs are I believe already lower than on-chain costs and I expect those these costs to continue to Trend lower as we have more specialized proving techniques as we have more specialized hardware and all these things and I expect gas costs to be much harder to be much harder to reduce right the amount of gas on the ethereum L1 has increased by a factor of five over the course of seven years but the efficiency of provers has increased by a factor of like thousands over the next the last like maybe four years right so when you have things that are high fixed cost and well marginal costs like economics get annoying right it's like public transit systems right like when you have a fixed cost to run a bus and it's like even like sometimes it might even happen that like the system can't pay for itself even if it makes total sense for the system to run because the system has to charge one price and it turns out that if it charges a high price it excludes uh too many people and if it charges a low price it doesn't capture enough of the value right and you're stuck right and so you know you have like weird things like this and unfortunately these kinds of like fixed cost to logical marginal cost economics do tend towards centralization and sometimes centralization may be an argument for saying like we want to give up on this whole higher layer ID and we want to just like protocolize it but the problem is like this stuff is so early that it doesn't make sense to protocolize it and like how do we navigate that trade-off in the meantime right is basically the challenge um another really fun use case proof aggregation for ZK Roll-Ups so let's say you have a roll-up and actually here is a part of a roll-up team who here is part of a roll-up team different from the roll-up team that the person over there is part of um we're here as part of the roll-up team that's different from both of these roll-up teams okay I can see I I see a few raised hands yeah so like we have at least three roll-up teams here right so the uh problem is each of these uh uh Roll-Ups are going to have to submit proofs on chain and submitting a proof on chain is itself something that has a high cost right so if you look at Ezekiel rollup it has to submit as he gets narcon chain 500 000 gas if you're a stark then it's like closer to five million gas and this is expensive what if we had multiple Roll-Ups and these multiple Roll-Ups could cooperate and basically replace all of their individual proofs with a proof of the proofs right so you just have one proof that proves that all of the proofs that they want to submit are actually correct right so this is kind of what the diagram says right you have like three different Roll-Ups and they make three proofs of three state transition functions and then you just make this kind of multi-proof which just submits as a public input the claims that the three proofs that are coming in are making and then it sends it off to a batch Handler and then the batch Handler basically just tells the roll up so like hey yo dog I have a proof of this I have a proof of this I have a proof of this and let me know the Roll-Ups accepted right so this like is a pro a kind of Layer Two middleware protocol that could actually be really useful and it could be like a lighter way to achieve the goals of uh reducing costs for earlier two is that's lighter than you know your threes and some of those similar ideas and like it could be you know it's more minimalistic it can be made to be more permissionless I mean I you know I believe like within the star core ecosystem there's a yeah version of this running already right but it would be good to have this as an uh potentially open you know protocol that's kind of shared between an even larger piece of parts of the ethereum layer 2 ecosystem and this is again a type of you're supposed to say the word yay okay perfect so the the goal of this is the proof Singularity right so basically my you know my dream is we have a block and that block contains a proof oh and the proof is a proof of proofs and each of these proofs is itself a proof of proof of proofs and each of those proofs is another proof so imagine the proofs at the end could be just signatures then the some of them some of them are signatures some of them are privacy protocols then the proofs in the middle are going to be aggregation proofs then the proofs on top of those are going to be layer two proofs and then with the layer 2 proofs you have a merged protocol and then it all gets into so it gets into one proof and then maybe over and above that you know you have a layer you know you have like one big Master proof to prove them all and that one big Master proof is uh just going to be as EK VM right so this way you know we're going to be we might actually be able to get to the point where we literally have like you know blocks coming in once every minute that just that prove everything and everything in the ecosystem is going to be super efficient and super uh super optimized right so this is um you know what I hope for the ecosystem and it would be amazing to see and um you know Builders are a yeah going to be a very important part of making this all happen um so this concludes my presentation thank you all for listening um yeah thank you thank you for the meme uh and we have one time for one question but I could uh also ask our next speaker to ask the question if you have one um extremely exciting talk about the future of blog building um my question would be these new protocols how should implementers be thinking about the complexity of the implementations and about shipping them in a timely manner that can fit um I can make sure that we don't end up in a dystopian centralize the future how do we think about implementing these protocols I think like just standardization is important and like cross ecosystem collaboration I think is important so I feel like we've been having a lot of that between layer twos which is good I would love to see more of that happen between wallets I would love to see more of that happen between privacy protocols like I think we just need to you know Identify some of these kind of verticals and in some I think you it might even be the case to like per vertical we might need like some an intentional effort to try to like really um you know figure out which what actually makes uh makes sense to do and to like try to sort of uh front run some of them some of the more centralized efforts at solving the same problem thank you so next we have uh Georgios who will be giving us a Grand overview of our next chapter the L2 PBS which is a brand new frontier there you go [Applause] so thank you all for coming and for not coming um um there's been a very exhausting week and also a week where we've made great progress on a lot of the concrete Parts about where the industry is going in this talk I would like to give a few questions for the audience to think about given that now we're entering the layer two part of the day and Layer Two part of the layer of two part of the day many people here that you're gonna hear next are working on it full time I'm no longer spending as much time on this but I'm gonna try to offer a zoomed out View and some questions for the audience to think as people do their talks and for hopefully to reach some deeper insights my name is georgius and this is the old faradam so we'll start with what is nl2 I see John in the audience and togul in the audience as well we'll see how that will go we'll talk about shortly what the differentiators between layer twos can be and what are net new exciting features that can be introduced then I will post some interesting hypotheticals for shared sequencers and then I will have a one slide for approver proposal Builders operation or whatever the canonical name ends up which our next speaker will also tell us about so we will talk about layer 2 just from the context of um not bridging because there's been many debates and I have no interest in engaging in any of them um the main thing about the layer twos that we care about right now is that you have some off-chain state some of the another place in another place and another off-chain state gets posted to layer one which is called the data availability layer and that ensures that anybody that wants to recreate the state of the layer 2 they can go and look in the layer one and they can very easily derive it typically there is a deterministic derivation function different in each system which allows you to do that beyond that a layer 2 is an L1 it's a chain it has a database has a runtime it has an RPC has a peer-to-peer layer it has a bunch of cryptography maybe it's a standard distributed system we know how to optimize them these systems the bottleneck on iO and state growth if the thing that matters to you is decentralization and the ability for individual to verify these are the two things that matter IO bottlenecks how fast you can sing a chain State growth bottlenecks how big your chain can be and if you want to scale ethereum or anything else how you do it is by launching many of these layer tools and the roll-up Centric roadmap is all about that now some problems for people to think about are one how are we going to do composability across the same flavor of the layer two so if I have two op stack chains and they want to talk to each other how are they going to communicate without necessarily going through the layer one if I have op stack and arbit room or ZTE stock or Stark stock or you know I don't know um is there some extra difficulty in making this to communicate are these systems even compatible or whatever runtime they need to support or are they just looking like it on the outside and things on the inside look a lot different and the natural follow-up question to that is what does change in the internals and how does that impact the externals how did the implementation detail make its way to the interface and one example could be that people maybe have optimized for MAV extraction on get because they understand okay these are the bottlenecks but maybe for example on the Paul guns KVM maybe it's different I don't know now let's talk a bit about what are the unique things that you can get from malayer 2. first and foremost from the side chains paper from 2015 by blockchain experimentation experimentation experimentation we can try new things without braiding the base layer and then I will pose some bullets with some questions about them so when we have faster block times and or soft confirmations what does that mean about the Mev extracted in these blocks does it really mean that more frequent blocks means less or more Mev what happens outside of that system and how does the synchronization time between these two systems change which directly of course affects the map extracted The Proposal said in rollups can be less decentralized without losing safety with some cost to liveness but not total degradation naturally having a distributed system means it's more it's higher SLA which is good if the system allows a custom transaction pool it also allows for custom ordering fcfs will hear Patrick McCory talk about that in a bit I also don't know but all of these are levers that one can pull depending on the Mev profile that they want the layer 2 to have or if you don't have a transaction pool and people just Hammer the sequencer what are you gonna do proof of work are you gonna add identity how are you going to prevent this spam that happens on the wire that comes from the client to the server and the obvious thing which is not I'm realizing the last bullet is off topic but I'll roll with it is that we have the bundle a bundled role a sequencer is both a proposal and a builder and naturally you want to keep the sequencer lean to allow for in the future as many of them to be around so the same this is for PBS on layer 1 applies to L2 separation of concerns how you build optimized systems I will not talk about the centralized sequencing I think it's kind of again an implementation detail in a centralized system you can replace it with a BFD version of it put it on tournament put it on some other consensus protocol and that gives you redundancy and some A's or B's here are do you enshrine the shared sequencer in your system for example um the op Stacks super chain is it the thing and is it something that gets you better performance than having something like an espresso sequencer on top of it I would think that like any time that you have a core protocol operation and you leave the metal that means that it becomes more expensive one or many shared sequencers do you aggregate them how does that go we saw the fractal aggregation of proofs that the vitalik showed earlier the aggregation Theory can play in any layer L2 specific or close flavor again same thing and the thing I want to drive home should sequencers are not magic you know they don't actually solve all the world's problems they give you Atomic top of block inclusion the most topic classic example being the best roll up the room for differentiation I also don't know um but I know that like nobody else either knows so what do um and these are two other questions around the bridge and the atomic success which I still have only seen strongman answers to and I think we should do better one concrete proposal on how to get to crocheting composer building and I realized this is kind of dense and low context so I'm happy to expand later but we don't have enough time is that maybe you can have a shared sequencer that indeed only guarantees inclusion without execution but then you can have a bunch of Builders where they cross chain simulate and vital kind of alluded to that that you can cause change simulate the broke the builders are indeed going to be running nodes and simulation engines for every chain that they support and the Builder is going to land a bundle that's going to be landing transactions for all up one two and three together and the Insight here is that we take the math Builder role and we just bundle more functionality like make it heavier and basically the shared sequencer is funny enough the map Builder poetic um this is my final slide um I want to talk a bit about this because the topic I deeply care about on ZK proofs and how the market will evolve um the proverb right now is again Ron Colo with the sequencer and the sequencer as we said is also a builder we really need to unbundle these two and there's many many ways that we could do it my favorite work was a paper by a good friend of mine Nike scottis was called the proof of necessary work and describe the way where you can introduce nonce grinding I'll approve of work in the snag generation process and that'll let you have a leaderless system or rather a system where the leader is not known ahead of time um for proof uh generation for proof proposal naturally anything that is like proof of work ask and has a lot of wasted effort but maybe it's like very egalitarian um so maybe like the next step from that is should we do a consensus protocol for the leader election um you know let's elect the proposal let's agree let's put up some stake or something we elect the leader the leader does it standard techniques that we have seen used in consensus Protocols are going to be used for prover selection and the other thing that I don't think I've seen anywhere so far um and I just added it as a strowman and I realized that it's probably broken and there's probably things to do but I wanted to say it is that as a ZK proof is generated you can actually observe that parts of the proof are generated in a pipelined sense the most trivial example I have a block with 10 transactions transaction one is executed it generates some witness data that witness data is supposed to get fed to a snark but while it's getting executed and it's getting proven another transaction is also getting executed and getting proven in another and another and another do the approvers need to be the same thing can there not be a market for proof aggregation the things that Italy was talking about can there not be something where proof one goes to John proof two goes to Nick proof two three goes to Josh you know and you can keep doing that it seems like we can come up with collaborative proof generation protocols that abuse this pipelined structure of like proof generation but if somebody is interested in talking to me about it please find me after the talk and the final question is how do you distribute the fees again The Perennial question in the Mev supply chain or compositional game theory is the new term I hear um how do you put the fees where does value accrue you know um I also don't know but it's something interesting to think about um I have three minutes and uh it would be good if we can do some questions perhaps thank you anyone has any questions from the audience oh I see uh can you elaborate a bit more on how cross-chain or cross-el2 interaction can be facilitated by this shared sequencer model for those of us who are unfamiliar with the literature yeah of course um can we get the slides back up um so the shared sequencer is an entity that is ordering things and doesn't really know how to execute them or if it were to know how to execute them it would need to have execution nodes for every chain it is ordering for because otherwise it would be ordering invalid things and ordering in wild things might be okay if your chain can support no Ops you know you just say anything that's invalid just like skip it this is a junk this live jungle and chain but maybe it's fine um so perhaps um what to do is that you have the shared sequencer which is basically a privileged entity for submitting um data to the chain and how does the data get ordered to get into that privileged entity you could have Builder one and Builder two but basically or Builder one for Simplicity who is running nodes for chain one and chain two and what they will do is that it will publish a bundle or a full blog template to the layer one where the first transactions in that bundle are going to be all the roller paid transactions and the next transaction with that bundle are going to build a role of B transactions and because that person is a builder and is has run the simulations on every chain they can guarantee that by being a top of the block they can guarantee that the transactions are going to be valid so by doing that you can hack your way into shared sequencing in a very clean way I realize this is a bit dense and I don't know if it answered the question sufficiently this also goes back to what vitalik says about aggregation I'm just wondering how this helps cross-chain interaction oh um well I don't think that you can do callbacks you know callbacks I don't know who has said that like you can do you know control a cold contract B and then it called back it's a bit uh unclear because people are doing like right now the way the Roll-Ups work is that they submit one transaction one big bundle per block if we could interleave bundles if we could say top of block part A is like bundle for roll up a and then roll a b and then roll up a again maybe we could do something where I can call chain a and then chain B chain a and then it calls me back um the main things that we support in this design are crochet message forcing passing and maybe cross chain bridging I'm saying a timeout so I don't know if I have time for more sure I think the person on the back goes first the person in the back foreign so um I just have a follow-up question uh regarding the shared sequencing and also PBS for the L2 like if we have sort of these um share sequencer actually two questions the first one that if it's really like sort of share sequencer do you think it will overwhelm that machine I mean if the sequencer used for multiple relapse yeah um like that's the first question second question that I um like three two one let's give it one oh sorry um so is the question that the shared sequencer can be very heavy I'm not sure I understood that like if that is the case the way that you do shared sequencers you basically need to make them like cross chain da aggregators before you land the chain before you land the bundle to layer one but you do not want them to be running the execution of these chains so by doing that you can keep the sequencer as a light da consensus protocol effectively which is what espresso is for example um and then you land your data to the real da protocol um sorry Joe quick one but in that case like for example if we really pass the message across the road Labs right where the sequencing but do we need to wait for the confirmation from one roll up um before like we really execute another message uh dependent on the for sure yeah yeah yeah obviously of course any transaction needs confirmations zero conf one confidence insecure I see so in that case it's like sequencing plus execution and da right thank you thank you so much then next speaker is dog rule who I don't think we've made before and is going to talk to us about proverb proposal Builder separation or whatever you're gonna call it hello everyone uh before I begin I wanted to thank vitalik and George's for warming up the crowd it's really nice from them uh so strangely enough I'm not going to be talking about roll-up definitions today I'm talking about something else so my name is tall girl I mostly posts on Twitter and sometimes pretend to do research at scroll and today we're going to be talking about pbsifying Roll-Ups prover sequencer separation so you've probably heard about zero knowledge Roll-Ups or for the starkware folk and the crowd so they understand validium validity roll-ups uh so you have sequencers and you have provers in the system and sequencers perform the role of of ordering and then the provers perform the role of computing the validity proofs for the given order and the way they work is the sequencer submits the batch the patch is also propagated to the proverb the proverb submits the fluidity proof and voila you have the finalized State on the layer one and so why should we decentralize because in l2's and roll up specifically you don't really care about correctness that much because it's already enforced by the L1 Bridge so why would you decentralize it makes more sense to just be centralized and be efficient so there are multiple reasons why you would do that so one resilience let's say if your sequencer fails what happens then if there's no backup or in many cases there's no decentralization then you're stuck and waiting for that sequencer to come back another reason why you would need to decentralize is real-time censorship resistance so while L1 Bridges guarantee long-term censorship resistance for a lot of applications that's not enough for example let's say if your app depends on Oracle updates and you're waiting for a long time and the sequencer is censoring you you're basically screwed in case there's a lot of volatility there's also throughput which is an interesting one because it might seem logical that a centralized system is more efficient because you have less overhead but in case of zero knowledge Roll-Ups because you can paralyze proving you can actually increase the throughput by decentralizing the provers and that's what I'm going to talk about later and so what are the requirements for a decentralized rollup so first we need to minimize the overhead it doesn't really make sense to add drastic overhead and make it really clunky and very complex it needs to have fast pre-conformations because if your lab has the same finality time as the L1 then especially in the l1s that are not very fast it's not a great Dux it has to be provable on change so what I mean by that if you use some sort of a mechanism that agrees on off-chain ordering you need to be able to prove to the bridge later that the ordering was agreed upon via a certain mechanism so if there's not there's some non-determinism in the way you agree on the ordering it might be possible that basically the bridge might diverge and so we need a way where you can prove it on chain that it actually happened and finally which is the reason why I'm giving this talk is balance incentive distribution so in and I'll explain why it is important so why is unbalanced incentive distribution an issue so since sequencer is in the protocol are in charge of the ordering they get to keep all the Mev profits and it's likely that in Roll-Ups the med profits are going to be the large share of the total protocol Revenue and if that's the case then what's the incentive for for protocol participants to become approver because if all the profits are collected by the sequencer then I'd rather become a sequencer but in case of ZK Roll-Ups we actually need provers sequencers we need a few but we don't need that many and so we need to incentivize provers and that's where PBS or proposal Builder separation comes in so in a proposal build of Separation proposal is installed either responsible for proposing and propagating blocks to the network and the Builder is a set there there are a number of Builders competing one one another in an auction to have their candidate blocks selected by the proposer to propose to the network and basically the whole point of PBS is that it outsources the computationally Intensive task of creating a optimal value extracting ordering to some specialized nodes that can actually do that efficiently and well in our case we don't have proposers and we don't have Builders so what should we do so we have prover sequencers operation so on top of doing what PBS does PSS also ensures that protocol generated revenue is relatively fairly distributed with the provers because as I described before the sequencers by default get to keep all the Mev and as with PBS there are two types of PSS there is enshrined PSS and external PSS and the role of the sequencers is essentially to emulate the role of the builders on the L1 and the role of the provers is to emulate the role of the proposers in PBS and so these are the steps in PSS and then Shrine PSS so the sequencer bids in an auction the prover selects the highest bidding thing the winning bidder reveals the contents of the block the sequencers reach consensus blah blah blah that's it we have the ordering well the benefit of this is that it doesn't have a lot of overhead because we don't need a lot of sequencers the consensus should be relatively efficient and therefore it should be relatively easy to run but the downside is that it actually creates sort of a PBS inside PBS because I might be a sequencer I might be elected as a sequencer but I'm not really good at building so I'm incentivized to Outsource it to someone else so it's possible that you can create a market where sequencers Outsource it to someone somebody else which creates this Loop in which the value is leaked to some external parties because the sequencers just don't want to do it internally oh no it's working uh and the second type of BSS is external PSS and it follows a similar pattern so sequencers bid in an auction Proverbs select the highest paying bid the winning B bit is revealed blah blah blah blah blah blah but in this case proofers reach the consensus and with external PSS sequencers don't actually exist in the protocol the protocol doesn't know about them there are some external parties that proofers deal with and they can even avoid them and build the blocks themselves but obviously it's unlikely to happen because proofers are not good at building blocks and extracting value so they're likely to Outsource it and the advantage of the scheme is that it doesn't really require two things thing roles in the protocol and therefore it makes the protocol simpler and the fee distribution much more simpler so you don't have to deal with like two different models potentially two different staking models etc etc but it also has a massive downside it has quite a big overhead because the idea is that you should have a lot of provers and if you run the consensus amongst the provers it's gonna cost quite a lot in terms of networking etc etc there are possibilities where you can for example use committees and do random sampling and do that but the security drops that way and basically you might get into a situation when you have where you have a liveness failure whereas if you use the entire validator set then it's much less likely that you're gonna end up having a liveness fee there so those are two options and we are not really sure which trade-offs are better and therefore the open question is I'll leave you with an open question to enshrine or not to enshrine that is a question thank you very much and if you have any questions feel free to ask [Applause] well the name of the game is that if audience have no question we ask Patrick to see if they're actually paying attention because these talks are sequenced and thank you Patrick from Arboretum Foundation hello Patrick how are you doing um I was making a joke I was going to troll him for his talk here's my opportunity but I'm bad at it no I was just going to ask School worked out how to do the incentives yet for the decentralized proving you know like how do you do the fee reward for example not really we're still thinking about it so I just want to be honest I guess it's relevant to the talk yeah now that I've warmed out the stage you can probably welcome welcome cheers awesome cheers GG all right thank you nice to the clicker oh yeah sorry yeah oh that was a hard one normally when before you're talking your heart's beating like this you're not really listening okay cool should I just get started then I guess so hi guys my name is Patrick McCory I work at the arbitrim foundation and today yeah there's my really dinky slides sit and have a cool intro before and I'm just going to talk about PBS across the layers for layer one and Layer Two and so let's just jump right in you know let's have an overview of layer one and let's have a consider about you know how Mev sort of evolved there so on a basic level for a blockchain system you have Alice and Alice wants to transact and she needs to get a transaction and communicate it to the block proposers but the question is how does she get her transactions across and historically speaking you would send this to a gossip protocol or a peer-to-peer Network so all is the center to the gospel protocol every peer will get the transaction validated and then pass it on to the next peer and the block proposers live on the Gaza protocol so they'll get they'll hear the transaction and then include it in their block as well now the question is who else lives on this peer-to-peer Network Searchers do and I'm sure most people here are aware the search will hear the transaction they'll inspect it they'll say oh I can extract value from this so they'll copy it paste it and get it to the block proposers first and they'll pay a higher transaction fee so it gets into the block proposers first or sorry their transaction will get in first but now not just one Searcher is there many Searchers are there and they're all typically competing for exactly the CM opportunity and we call this a priority gas auction so maybe let's raise our hands does anyone remember these gas auctions okay awesome and did anyone ever steal your your transaction that have you ever been a victim to uh the P the you know PGA game okay maybe maybe one or two hands there anyway so what is a priority gas auction why is it important so what happens is that I stole this graph from someone from this really nice article about it but basically within that 12 second window one searchable place a bid another search rule plays a higher bid and very rapidly throughout those 12 seconds you could have a hundred different bids that are all competing for exactly the same Mev opportunity the block proposer will simply take the you know the bid with the highest fee because that's going to pay them the most money and so there's two problems that happened here with you know these priority gas auctions and this is sort of like 2019-2020 one was wasteful and failed transactions because the successful transaction would get in alongside all the field bids so this is a waste of block space and two is sort of unrestricted Mev as well you're sort of ticking the user throwing them to the wolves and you know their transaction may or may not be executed at the very end and so when flashbots emerged they sort of resolved this problem so has anyone ever used a direct transaction before with flashbots a few people here are awesome cool cool so the way they solve the problem was very simple they set up a direct communication Channel between the user and the block proposers okay and so you just basically bypass the peer-to-peer Network you bypass the the Dark Forest so they cannot eavesdrop on your on your transaction but what can we extract from this scenario so first we have to consider the transaction ordering policy so when a layer won't blockchain we typically use the highest fee first you ever passed the most money is going to get ordered first the second is the communication protocol Connor Searcher eavesdrop and learn about the user's transaction and then extract value from that and finally we have to consider is the user experience you know what guarantees did the user get and how long does it take until they figure out oh my transaction is being confirmed or someone's extracted value from me and so what do you do about this in the layer one world you know what do do you defend against Mev or do you try to embrace it and you know just take it sort of you know it's going to happen anyway that's embrace it and use it to protect the protocol so we'll let in the layer of one world we've sort of gone down the path of embracing Mev I'm PBS games and why is that and that's because to this day I am not aware of a protocol that can defend against Mev when we take into account 500 000 validators you know at the protocol level we just don't have a protocol that can defend against Mev in any meaningful manner at the layer won't be a Slayer because after all one of the overarching goals of a system like ethereum is to maximize who can be a validator you know maximize that set and make the operators of the system as decentralized as possible and one of the other problems is that well one of the reasons why you would Embrace Mev is because one of the assumptions at a layer 1 blockchain is that all validators roughly get the same reward you know if I get the same reward as the other validator then we'll both arm rewards at the same amount I know will be equal Partners or you know well equal competition if one validator can take the Mev for themselves and it's not shared amongst the validators then they'll grow bigger than everyone else because they'll earn more rewards than everyone else as well and that's a terrible outcome you know if we knock we're not careful of how Mev is embraced will break the property of fair reward for the validators and one validator will grow on you know you know basically defeat everyone else and so that's why foxbots and PBS sort of solves that problem when you think about what flashbots have done is that they've taken this onto an auction protocol and took it off chain and what they enabled was to allow block proposers to Outsource the work of Mev and then a Marketplace of Searchers can all compete to extract the Mev and of course you know share some of the rewards with the proposers and then they get some of the reward as well and this is also acknowledging that someone in their bedroom can probably do Mev better than someone who's running like a you know a validator farm for ethereum you know outsources to the best people who can do the work and share the rewards between both parties and that's why it's really cool you can share the reward and you also reduce this on-chan spam now what about a roll up you know like just just a highlight you know that's why we have PBS for the layer one to protect the decentralization of the validators but what about a roll up is the environment any different and it's exceedingly different a rule up already assumes that we have ethereum we already assume that we have this decentralized platform with hundreds of thousands of validators we don't need to replicate this at the layer two we don't need 500 000 validators we just need a handful maybe one two three four five sequencers and that's it and as we'll see you know the sequencers there that offer the user experience and the fast path they don't actually impact the cfd of the system but that's cool if you only have a small sequencer set that's a much more tangible problem to deal with in terms of Mev um you know the scenarios of our history of forward Alice has a direct communication Channel with the sequencer so Alice can give her a transaction over then the sequencer can give an instant response the sequencer has ample time to do whatever they want with the pending transactions they have a listing of the basically like a basket of pending transactions they can apply any ordering policy that they want and they could do this within a few minutes or up to a few hours they have ample time to extract as much Mev as they want if they wanted to do that and of course eventually the sequencer will take the list of order transactions and pass it on you know maybe to the executors the provers ETC so all they're doing is ordering transactions and that's it so let's again compare the core components so Layer Two is very different and Layer Two the sequencer can apply any ordering policy that they want the communication channels vary different it's a direct communication channel to the sequencer there's not necessarily an opportunity for a Searcher the eavesdrop on this communication and finally the user experience you know the user sends a transaction the sequence can give instant response it's a bit like claim of the Legacy we have two worlds where you get less instant response when you sort of interact with a website but as we're going to see as you try to improve the user experience you're going to impact Mev its ability to be extracted and there's this sort of weird trade-off between extracting Mev and how users experience using a robot or a layer 2. so as I mentioned lots of ordering policies you can consider no has extraction first has fee first first come first serve it could even be Cal swap that's an ordering policy any order and policy that you want there but most Roll-Ups today Implement first come first serve what is first come first serve you know very straightforward I give the sequence for my transaction they time stamp it they respond to me then they order the transactions by timestamp you know it's extremely extremely straightforward and you would think with first come first serve there's still no Mev here so raise your hand if you think there's Mev let's see there we go awesome now of course there's Mev why so what arbitrim tried to do at least is that the sequencer has a data feed so you know we get user transactions we do first come first serve and then we reveal that in a data feed every 250 milliseconds and the reason for this is that we want to provide you know coinbase etherscan and fura with up-to-date data so user can send their transaction look at Arby's gone and say oh my transaction is confirmed well if you have a sequencer feed where you're given out this pending data to these infrastructure providers Searchers pop up of course they do and what do they do well they listen for the transactions if they find a back burning opportunity bomb you know they send it out immediately oops look at that there's a Searcher right now sorry always listening aren't they um but this is it that you have this rise of this latency again because in arbitrim you didn't just get one Searcher you got a 150k websocket connections to this data feed and so one is a latency game because they're all competing with each other and two it's a bit like an analysis attack on the sequencer because you have to maintain 200 150k websocket connections because it's not an ideal scenario so the option Labs guys came up with a really elegant solution in my opinion but there were some outcry already laughing about it aren't you um you know they basically wanted to implement has cash because it's basically you create like 20 priority Lanes you do some proof of work you have the Lewis proof of work you gain access to the priority Lane for 24 hours to reintroducing proof of work in order to solve this problem but as you can imagine there was a lot of outcry people don't want to use proof of work to solve this problem was of course for me as an elegant short-term solution but it doesn't really solve the problem long term but this is really frustrating right we have this trusted sequencer this ideal scenario where we can fully trust them not the extract Mev on the Mev Mev Bots are still there I mean look at this guy he just doesn't go away does he that's full of Diane by the way from flashbots don't know if you know who he is Drew a little evil eyebrows on him but he's always there doesn't leave us alone well what a guy the Dark Forest is always lurking so then the question is you know what's more fair are these latency games fair you know clearly not you know as a denial a service attack on the sequencer and you know there's just fighting amongst each other so then it brings you back to the question well what about auctions you know that's how it was so often the layer one we create this auction and let them bid for the opportunity and those are the idea behind the time boost proposal by Ed Felton from off chin labs and I'll give you a high level overview of basically I mean it's very straightforward as you're going to see maybe they have an academic paper that's slightly more complicated but the idea is simple you know all this gives a transaction to the sequencer the sequencer still has this data feed where they reveal the transactions but now the sequencers compete in these little bundle auctions very rapid auctions and then of course the winning bundle gets sent to the sequencer then the sequencer then decides okay here's the transaction batch but the point here is that this bundle auction is configurable it could be really rapid it could last 500 milliseconds it could last three seconds and what you're really doing is purchasing the right they go back in time so within this auction window you're saying I want to go back 250 milliseconds in the past another way to think about it is that you're buying for a specific position in the ordering maybe you want to be the 20th transaction the 30th transaction but that's you're buying for that opportunity and you can be selective so in the time boost proposal their goal is only to allow back running because back running is not seen as bad Mev you know there's a lot of moral questions around that but it can be configurable you could allow front running you could allow sandwiching and because the bundles are so small and the auctions are so rapid you could probably inspect it look at the transaction say okay I will accept that type of Mev but I will not accept this type of Mev and so my last slide is basically some interesting questions around that should the sequencer be allowed to inspect an Mev bundle and then decide not to include it you know this could impact the credible neutrality of a rule up because now they're sort of being subjective over the transactions they include but if it's better for the user then maybe they should do that the auction time window is set to only enable back running but you know should we allow front running in some region as well and maybe the last one because these are rapid auctions we want so the whole point here is to enable a Marketplace of Searchers you can all compete to find these opportunities but if it only losses 500 milliseconds and there's only five transactions they know there's probably only one Mev opportunity so maybe you want to set the time window so there's 50 transactions or 100 transactions and so then you can get more interest in Mev marketplaces out of that because they're all competing for different opportunities but for me the time boost paper sort of inspired this talk I thought it was really interesting and I've been just thinking a lot about it so it's not really my work at all it's just whatever I've gathered from reading so I hope you enjoy the talk anyway Gigi gmgm thank you Patrick well uh someone wants to give you a question back he has been waiting oh he is here look at this they're going to get roosted yeah I waited for the end of the talk to us and I'm very important question I cannot borrow my flight without knowing the answer to it should we should we be allowed to refer to distributed ledgers as databases sorry I was just getting trolled earlier by bartick from L2 beats because I keep describing it as yeah this should be a database I mean that's that's what they're all roles is building databases okay so that's a bit of an inside joke but I've been getting trolled all day for it sorry just for contact so basically when you think of these systems when you deploy a blockchain system what you're really deploying is a database and the blockchain has an audit Trail for recomputing that database and that's it and people don't make that analogy do you guys like it raise your hand if you like that analogy there you go someone take a photo and show bar Tech thank you Camden GG guys awesome perfect we're doing perfect on time thank you next we have Tomas um who wear many hats one as a researcher at flashbots um architect and also as a the founder of nethermind talking about Meb garden and cross domain markets hi everyone uh so I was told to stand here the Mev Garden so that's very very sweet name because we've been talking about the Dark Forest for a long time so my name is Thomas steinchak and mated flash Bros founder netamind uh trying to wear a few hats and we'll be talking about how to connect through PBS many different domains with Suave so this is not an announcement of a product it's not a suggestion that was going to build it it's more like building the open presenting you a bit more of undercooked ideas that potentially will be rejected like maybe something will be missing in quality maybe it will be not really aligned with the values all the values that are at large but so Illuminating through the bringing transparency to maybe activity providing permissionless access to Mev extraction and distributing fairly the Mev Revenue all right so once again I'm Evie Garden we'll move away to something that's a bright Place clearly divided into components PBS and with kind of conditions for everyone to participate so we're talking about connecting everything with the existing ecosystem and making sure that there is place for everyone especially that the users feel very good in the second system there's one of the small steps really what we'll be showing and hopefully we'll end up with something like this and maybe a little survey like how many of you know what PBS is okay it's going better and better so now we divide it slightly more but just slightly more so obviously the builders will divide them into the sequencers and Builders sequencers will be choosing the transaction sequencing transactions and the builders will be building blocks out of the transactions that are pre-selected so it may happen in some of the setups and it's particularly might be important if you start talking about the shared sequencers so start to forget for a moment that sequencers are what in the Roll Up is like everything together and how nowadays we see the PBS down so I'll go quickly over maybe some very simple visualization so what we have what we can end up with so nowadays many of the Roll-Ups are like simultu and the centralized native sequencer in it um the decentralization very often is seen as like just introduce a few sequencers and leader election and they start proposing blocks one after another depending on some some rules uh with a shared sequencer we say that the sequencer is actually shared between multiple l2s l1s and we may have some atomicity with it and then the something that is like ethereum nowadays would be you start splitting the sequencers into proposals and Builders so there's Builder Market they're bidding for the for the best block and there's proposers so you know all of this right now I start saying that we will say that shared sequencer is a native sequences like centralized sequencers all of this can coexist and it can start to have various combinations of all those setups and also a very important thing is that PBS does not necessarily require that the proposers are decentralized you can have a centralized proposal native to the roll up and still create a builder market so they can be bidding for the best block and the proposal may decide to either capture that value for the operator of the L2 or to maybe burn it for the protocol foreign all of this may coexist and because we can have many different protocols arriving at the solutions at very different times with different like we see in our bedroom proposal we see what scroll was proposing what starknet is working on and so on and so on so maybe in this world for a few years where we want to create the market start building the markets for Mev and for PBS and and still connect all of those different protocols so when we know that we want to achieve that we set some design goals for the protocol that will allow to do the PBS with the cross domain mov and we want to support that heterogeneous sequencer space different designs we want to enable permissionless and transparent cross domain Mev Market we want to be in line with the whatever happens on ethereum but also be in line with what happens with other chains right so think about not too much pushing the protocols themselves to change we want to operate slightly outside of the protocol maybe opposite to what what Zaki was saying or maybe not opposite but related to what what saki was saying um we want to respect the position of various Market players that are building shared sequencers middle words riskaking Solutions and so on so I want to make sure that everyone feels like oh well there is a Marketplace arising there's a game which I'll be able to play with uh play inside we want to make sure that it's 12 aligned so that's my internal goal like make sure whatever we're working on at flashbots is actually part of our greater Vision that is strategically well tested and discussed and one thing is that now if you think about it we need to ensure that their equal rights are there for the solos takers and large operators to participate in that game and this is for the for the validators or proposers and now this will be the proposal for what we really can build to try to support all of those requirements so first of all we want to have some kind of change it can be swap chain it can be something on the side of swap chain which is just like a global ordering system so a set of Oracle so whatever construction and the construction here is not really defined on the technical level more on the on the vision idea level we want to order the blocks on different chains and have a way of looking at this ordering from the outside just to use it for construction of the proofs and slashings so I'm saying I'm looking at Twitter's construct net polygon and many other chains potentially and maybe even things outside of the L2 or ethereum space and I want to keep order of everything that I can do possibly within all of those domains and I say that I want to introduce a definition of synchronized block proposals so if I'm a shared sequencer for example and practically in some cases I'll be sure that I'm proposing blocks that will happen at the same time like so I know that I like if it was a base roll upon L1 I know that every 12 seconds I produce block and within that block I'll be producing blocks batching blocks for multiple roll ups so I can start making some promises but to describe those promises we need to agree on some definitions and I'm not sure what those definitions would be over time in the market which of those would be the most makes the strongest and and here for example saying something like a very strict definition like we're looking at two different domains and we don't allow anything in between so um on the screen the ethereum block 100 will be synchronized with the Stark net block but not with the following ethereum block and not with any of the blocks before this darknet block because they belong to a different domain and and there is something in between so I want the blocks to be exactly next to each other but then maybe this will be difficult and maybe we would sometimes not care about the other domains because I'm trying to synchronize to blocks to extract Mev and maybe not always I will believe that for some other chains construction I can extract that Mev before before this happens before the synchronous execution happens so maybe I want to define something that is like strict but within the domain so as long as there is no other block that belongs to the same domain as the two blocks that I'm talking about in between that it's synchronized so here the ethereum block is synchronized with startnet Block it's also synchronized with the polygon block because there is nothing from ethereum or polygon in between so it's only start Network in between and it belongs to another domain so I don't care and the more domains that we'll see there the more I will probably want to restrict the number of domains that I care about when defining what does it mean that it's synchronized and I may say that well I really care only about the situations when both domains that I'm synchronizing between or multiple domains like we can probably extend it to many domains if if no set of blocks happened in between that would belong to the same domains then then everything is fine so here I really say that even one of the last polygon blocks is still is still synchronized with ethereum ethereum block 100 but the start Knight block 202 is not synchronized with that block because we see above the ethereum and start Network in between so this is not very strict I'm just proposing something that may be relevant when making an announcement like if I'm a if I'm a sequencer proposal as a proposer I want to so shared sequencer proposal I want to make commitments to what I'm going to do and I have to describe it in somehow and as I as we were working on it we discovered that well that definition is not that obvious we may still need to work about which definition will stick um the communication about this the announcements may happen through something like nowadays through the relay but potentially may happen through the attestations and P2P Network so there should be no difference whether we keep the existing ideas of ethereum and existing roadmap whether we change it towards the epbs and Trend PBS no really to the to the way we approach this the solution and maybe Garden and when you look at the proposals of Pepsi like protocol enforced proposal commitments you can think of this a bit like a cross domain Pepsi so cross chain PBS we're adding communication layer from proposals to builders so the other direction proposers make announcements like in Pepsi like some some announcements of what I would like to commit to and I Define asynchronization between the blogs that I'm about to commit to and I can be slashed if I don't deliver that so we'll show how to do that and once again think of it maybe as a cross domain Pepsi um and this is part of the design goals we want to create the permissionless and transparent market so you start to feel maybe it's permissionless because we created that chain and anyone can start announcing announcing this like proposals defining some kind of we can have some format description of what I'm going to do as a shared sequencer I can say polygon ethereum Block in 10 minutes there'll be synchronized according to the strict domain rule and and if I don't deliver you can slash me if I do deliver then I actually can start bidding on that proposal and any of those shared sequencers native sequencers decentralized sequencers may start judging themselves how much of the probability of delivery of that of that commitment they have do I only propose it to only announce it if it's 100 if I'm sharing sequencer or sometimes I want to start extracting value even if I have five percent chance a 50 chance of success and I know what they want my deposit is what can be slashed so this is both the global time with the set of proposals we look at this chain and we see that we start noticing blocks and there is a commitment from a proposal saying how do you synchronize Stark net ethereum blocks and then we start seeing beads from the Block builders that are now across domain block Builders and are bidding on on what what will be the best payment to that synchronized proposal the block is selected when it's accepted when the bid is accepted then from now on WE practically have a promise that there is some slashing so the deposits were exactly it's deployed it's maybe not the most relevant it can be something on this chain I mean something outside some restaking solutions and so on and then if we at the end either I delivered synchronized blocks according to that definition or I failed if I delivered I get the beat that was promised if I failed I'm gonna be slashed why is it important in the Suave roadmap alignment well if you have seen the presentation from Robert about Suave we were talking about this promise that a Searcher can say I pay you one if if you deploy something on two different chains so without this maybe the the one problem is that I may make this promise but on the other side the executor has to have some kind of expectation about How likely they are to achieve that success of landing something on two different blocks and I want to have someone else promising that yes they can do that for them so the executor want to have a bid but also a promise that they can operate on that beat and start simulating and building blocks so this is the component that is needed for swap to connect for the cross domain and this one thing is here in yellow because it's kind of missing this is risky it's uh it's to be explored how the solo stickers solo proposers validators can compete with the large operators that have huge overlap between two networks so shared sequencer is a simple case but if I'm large operator to networks for example 70 of blocks on one network 70 of blocks on the other network more likely 30 or so then I will have overlaps very often I can make these promises of cross domain extraction all the time so I can capture more and more value so if in these we have to make sure that as proposals between the solo Staker solar proposers can be somehow coordinated and that we know what exactly happens if the slashing happens who is at fault for not delivering and I was the roadmap well ensuring that the design is actually satisfying all those goals so I'm forwarding PBS on multiple chains so they can be connected to this solution and this is not trivial as we've seen there are different questions about what consensus mechanisms are used like if it's standard means how this will work there if it's ethereum L2 how it will work there how it will work with provers and so on and so on so that PBS work already started many uh we look at many protocols and try to help them to build pocs so reach out if you would like to have those conversations with the flashable Steam and yes would love to hear from all of the l2s all of the domains of what exactly works here what doesn't work is there much Mev to make here how the market makers think about it is really needed and is it value aligned yeah and just to summarize Maybe the slide was initially in the front but we didn't know about the time so um The Flash would stand in mind collaboration started around 2021 and there's a bit of invitation for many Builders teams or like protocol engineering teams to to maybe start collaboration with Suave with with flashbots on swap for multiple components we do lots of research materials together frps but we also do engineering so I hope that the journey or being totally outside of flashbots and enjoying the fantastic time on research and building can be your journey as well thank you so much that's all from me thank you dimash um we don't have time for a question but we have Joe um coming up from Aztec hey everyone uh thanks for having me cool so um my name is Joe I'm one of the co-founders of Aztec and I'm going to run through PBS Mev and some of the considerations on our twos it's not quite as simple as we may think oh I've never used one of these clickers before yeah it's not working ah okay thank you so I was blinding someone in the audience uh I'm Joe uh so so what is Aztec um we're a fully private ZK roll-up on ethereum um we have private State um and we have fully composable contract calls between contract a and contract B we also have hybrid execution so that is Mev um we have things like uh public function calls for amms and as such we're trying to think through what does decentralization look like um and we have a big focus on on launching decentralized you can follow me on Twitter and uh follow Aztec for more info on that I'm going to try and get through this in 15 minutes but um we're going to go through why we should care about decentralized sequences um differences of block building on L2 versus L1 um there are some key key distinctions um a walk through of two proposals we received in our RFP process for decentralizing the sequencer and a little kind of some thoughts on enshrining Mev auctions in L2 protocols so firstly why should we care um about decentralizing sequences um I think it's fair to say the industry doesn't really care right now um l2beat has an amazing dashboard and I think no one including Aztec connect has made it past stage zero or stage one on the training wheels framework um if this was kind of like a report we're doing pretty badly you get the meme I think like some of the actual reasons we should care a lot of Roll-Ups are designed to be first so we want to be the first private roll-up the first CK evm and this actually kind of has pretty harmful consequences I think we should start designing things to be last they need to stand the test of time um decentralized systems need to be really robust we learned this the hard way with Aztec connect trying to decentralize a system with hundreds of thousands of users is way harder than just going to the Whiteboard and getting it right first time um and if you're at the Whiteboard I think we can start to solve some of the issues in the L1 block supply chain and try and get to a world where maybe more than five people are producing blocks and the last one won't be a surprise I think regulation is a key reason to to do this um crypto's cryptos Global uh but regulation definitely isn't and having a very centralized uh point of failure is something we need to kind of work around especially with headlines like this between the differences between the UK and U.S for example all right so let's look at the differences between blocks on L1 and blocks on L2 um I think the first base to start is around the size of transactions um so for kind of non-private chains um you just submit a signature over kind of like a request or a transaction request but for a privacy L2 you submit a proof of execution so a zero knowledge proof of the transaction this leads to kind of much larger transactions um with Aztec if we use something like Goblin plonk and very wide circuits they could be kind of 20 times larger than a normal ethereum transaction this isn't a deal breaker but it just means that the same infrastructure or same things we need on on our one may need to be adjusted on L2 uh the second area is compute um so just a quick look at kind of like the CPU cycles that are needed to actually produce a block on on these different kind of domains uh first of all everyone's kind of familiar with searching there's a lot of compute that goes into uh the knapsack problem trying to figure out the correct ordering for a block on L1 and then you've got to execute all the transactions and uh duke it doesn't really stop there for zkl2s we also have proof construction um so constructing a proof of correct execution can be a million times slower than actually executing the transaction so when you're going to put all that together the summary has kind of block building on l2s is not really the same as block building on L1 so should we use the same systems to kind of produce our blocks I think the main point of this slide is just this is like a huge centralizing Force if you need 10 times the compute 100 times the compute to be a block Builder and you're the fifth best block Builder is it really worth it to turn on your machine um so that's something we need to design around we don't have all the answers so we did an RFP to try and crowdsource some of them we had some fantastic input from teams like espresso systems and flashbots and Austria so thank you everyone who participated I'm going to run through two of the proposals now one of them was um written by me and one of them was kind of written internally but also it learns a lot from some of the espresso systems work they also have drinks names which I don't know where that came from if you want to kind of look at the in-depth uh write-ups you can scan these uh QR codes just wait for five seconds so the first one finet um it really isn't that different to ethereum it tries to kind of take what works on ethereum and mold it a little bit for L2 and it really focuses on Fast transaction pre-confirmations to do that we use an L1 smart contract to like administer the whole process and we have a proposal Builder separation like we're all familiar with a proposer likely with the help of Mev boost will submit a block header to the L1 contract and that will include commitment to The Ordering of transactions um like hiding hiding the actual ordering but a commitment to that through just a commitment scheme and a vrf output on their staking public key all proposers have to stake in this model and the vrf output between proposer a and proposer B will differ on each block um after kind of the proposing phase ends for a given slot or Epoch The Proposal broadcasts the block contents to L2 and provers who are listening to kind of uh the L2 can compare the vrf outputs look up on the L1 contract and see if it's a winning a winning score for the vrf if it is and all the data is available they can start constructing a proof from the contents so the cool thing here is that like anyone can submit that proof back to the L1 and it doesn't have to be kind of submitted for the gene to move forward like at that point in time it's needed to be submitted for finality but um you can kind of look at the chain and be like if I've got all the data and this is the winning vrf output I can I can move forward and eventually the block which has a valid proof and the higher sphere vrf output will become canonical this means that we can get soft finality by building or proposing blocks that build off um kind of unfinalized blocks if all the data is available and you can use this with shared sequencer designs um and kind of it's quite extensible much more like ethereum yeah if no proof submitted you kind of roll back to the last canonical block in B-52 this is where things get a bit more controversial um my kind of goal with it was let's try and get rid of the proposer and to do that we enshrine an Mev burn auction in the protocol and we instead focus on decentralizing the prover Network so firstly I guess why does the proposer exist on L1 which may lead us to kind of see could we get rid of The Proposal on on L2 and I think it exists because you need to check or the work of other proposers it's the main reason it exists a proposer on our one could technically lie and other proposers check that work that's kind of the power of the ethereum consensus model and it also exists for censorship reasons um The Wider the setup proposes uh the higher the chances are that eventually someone will come along who's not willing to censor me so it's pretty good reasons for it to exist on on our one and as such the block rewards on our one kind of incentivize creating a very large validator set on a zkl2 my claim is that these properties don't really hold so we don't need to check the work of other proposers you can't lie um ZK proofs mean that if the proof system is correct we just submit a proof to our one and we can inherit the checking work of all the proposals on L1 and we also don't need the censorship property because we can force direct Force transactions in directly from the L1 smart contract so these two kind of main reasons for having a proposer don't really exist on a on a zkl2 so what's the point of enshrining a proposer into the protocol who can really just sell their right to produce blocks to someone else instead we could use a block reward to incentivize a proving Network or something else in the protocol so how that works we split things in B-52 into two distinct phases there's a block proposal phase and proof acceptance phase a bit like finet um there's no proposal here so the Builder is doing everything in this scenario um the Builder broadcasters broadcasts a block header to the L2 Network this contains a commitment to the transaction ordering uh like before and a bid in the Mev burn option this is the amount they're willing to burn for this block to become canonical they also connect to payment to the staking Network who's going to help them make a proof later on stakers then vote on the L2 for which proposals they will construct proofs for um likely based on how much they get paid but there could be other factors like censorship or other factors which influence this and each vote is waste weighted by a vrf output from the stakers public key um the builder then kind of Aggregates all these votes on on the L2 and they assemble a transcript of the block this is committed directly to L1 and it kind of allocates who's going to do what uh in the proof construction phase and also lets us Define a total score for the block and the L1 roll-up contract can uh rank these uh proposals by the score and the two weights are kind of the the sum of the proof of votes and the amount they're willing to burn we're still modeling this so it could be could change significantly um again like with fernet um because this is on our one at this point the prover Network can just look up on the contract and see which blocks have data available for them and are they safe to start constructing proofs for anyone then can submit a proof to the L1 roll-up contract and the same property kind of applies the the proof with uh the highest score becomes ahead of the chain and you can play you can pay a block reward uh to the winner uh plus uh Uncle proofers as well to keep liveness so these proposals differ quite a lot on what happens to Mev and we don't know what the right answer is right now um but we can look at kind of other other l2s and see what's happening and see how we compare so an optimism um I think the the rough the rough model is a centralized sequence circuit moment extracts Mev to fund public goods that's a great a great outcome on arbitrum I think with the time boost proposals um any Mev that comes from that or like fees will go to a dow potentially Aztec if we go forward with the finac proposal will look very much like ethereum you'll have a proposer and a builder who can extract uh Mev from the protocol and this will be facilitated by a market like flashbots for example if we go forward with B52 we've deleted the proposer so it's the protocol and the Builder that can extract the Mev via an M protocol Mev auction so to help us decide on these uh we're doing a lot more research but I've tried to put together some rough economics of what I think the different variables are in this so if we look at kind of the revenue stack for a proposer today it's roughly transaction fees block reward and the bribe they get from the Builder to get the block on chain and the costs are pretty straightforward there's also obviously the builders Revenue stack the ordering preference fee is designed to kind of just Encompass all of the different Arbitrage opportunities that exist or for the different builders and there's kind of unknown relay costs we don't really know who pays those at the moment but I guess it's species and some costs associated with searching um if we were to kind of remove the proposer the Builder's Revenue stack could look a bit like this um so they would get the full transaction fees the block reward and the ordering preference fee and in return they have to increase their costs by doing some in protocol Med burn so yeah I guess my claim is that these are the same thing um so the bribe that's currently paid to the proposer could be paid to a protocol for a zkl2 lots more research needs to be done on this to see if this is a good idea there's research on ethereum uh around maybe doing something like this but for a zkl2 I think the requirements are a lot uh less strict um because we can rely on the L1 for a lot of these censorship properties so the main takeaways so far of where we've got to in our decentralization of the sequencer Journey um the two proposals were kind of going forward with at the moment um slightly based so it's not for Anarchy um you can't just submit Roll-Ups to L1 whenever you want but they do use an L1 contract to decide which blocks canonical and there's some scoring logic in that contract for both proposals they also both used a vrf this helps us kind of protect against 51 attacks and someone kind of uh acquiring too much of the stake or other attack vectors here for net decentralizes proposers like ethereum and B-52 tries to decentralize the proving Network we need a lot more research on uh enshrining Mev markets and that's pretty much all I've got time for so instead of you guys asking me questions I'll ask one question to you guys should we enshrine Mev the protocol or not if you have any thoughts please come and talk to me afterwards all now [Applause] thank you very much sir to Joe I mean I think Aztec's approach to all the proposals has been one of the most thoughtful in the space when it comes to PBS um now though we turn the stage to Ben Fish um apply cartography Professor from Yale and also the co-founder of espresso systems take it away thank you Reid thank you very much um right so I modified the title a bit from the original one where do you there's the clicker let's see there we go okay uh PB espresso this is not my idea this is quintus's idea I stole it from him he has all the creative ideas so I'll be talking about pves for shared sequencing and responsive consensus protocols these are sort of two unrelated topics well maybe not completely unrelated because responsive consensus is the espresso's consensus protocol for shared sequencing but the talk will be split into these two uh two different subjects on PBS so first just to quickly introduce what is shared sequencing so roll ups are horizontally scaling the application layer of ethereum uh the idea is that when you add new applications then you can have those applications add new servers that execute some of those applications are Roll-Ups that support other applications but I view rollups as basically applications that support other applications and the the layer one is now not doing any execution they're just verifying fraud or ZK proofs um it's also leveraging this heterogeneity so you can have powerful servers on the application layer you can keep the servers on the layer one very weak they just they just verify proofs they don't need to do any extreme execution the problem is Roll-Ups control a lot and that is uh that leads to the need to either decentralize the rollups themselves and add some kind of decentralized process for each roll up to decide on The Ordering of its own transactions or it um it moves us towards a different model where they share the L1 so um the other problem which remains if each roll up just runs its own consensus protocol for its own transactions is that they remain very isolated from each other um and so the currently even though we're sharding the application space of ethereum we're sort of ruining this amazing property that ethereum has which is the interoperability of contracts one contract that you deploy can easily make function calls to another contract and they share liquidity with each other so roll ups don't scale ethereum without changing its fundamental properties and that's not really scaling that's scaling and changing the target so how can we regain the functionality of ethereum as it is today while still scaling ethereum so one idea that has come out is uh for Roll-Ups to share a consensus protocol for ordering transactions um so this is this is this idea of separating ordering from execution where the L1 doesn't build or execute right the rollups do that but the L1 can provide finality on transaction ordering availability of data verification of State proofs and transactions submit their Trend they're they're directly to the L1 and the Roll-Ups just read from the L1 and um and and execute so there's a question of would does this give us uh interoperability um it's also good to note that this layer that's shared by the rollups for ordering doesn't need to be ethereum itself it could be some layer 1.5 that sits in between and the main reason for that is protocol modularity perhaps we would introduce a new protocol that has the ability to provide faster pre-conformations than ethereum does ethereum has a slow confirmations time so this is a reason to to design shared sequencing layers that are not ethereum itself but some other protocol that sits on top as whose sole purpose is to provide a different property to Roll-Ups like higher throughput and faster finality the concept is though the same users are submitting their transactions to the consensus protocol that is independent from the Roll-Ups Roll-Ups read from this consensus protocol and only execute and Report State results so does sharing an ordering layer help interoperability if the ordering layer is not doing execution that is the main question of the first part of this talk today um so I'll say there are three advantages but I'll focus on one that has to do with PBS proposer Builder separation right there are also advantages such as simplifying Crossroad bridging mitigating systemic security risks for Bridges um we've written about this in in blogs from espresso systems but I will focus on this topic today of supporting cross-roll-up building with economic bonding and what is this so first um you've been hearing about proposer Builder separation all day but maybe everyone has a slightly different way of describing it so I'll just do a quick review and present sort of my view so the proposer is is a fundamental part of the consensus protocol because all consensus protocols today have are based basically on leader election if we use consensus protocols that are not based on leader election then we might end up with something different but consensus protocols like ethereum and like the consensus protocol used in espresso or tenderment or any of these systems have a leader that is elected to propose transactions that then get ratified or signed by others so if there's always a proposer if someone says that uh that we can remove the proposer what it really means is that you can only you can just use the layer one proposer and you don't need to introduce new proposers in the layer too but there's always a proposer from the system that finalizes the ordering of transactions so um Builders today can compete and then produce a block the proposer doesn't need to build a block it can it can play this passive role of accepting a block from Builders and if we design this if we leave it up to proposer to do this and don't design anything into this building layer then what ends up happening is a first price auction where the proposer will just accept the most valuable block that comes out of the Builder Network and so that's a reason to take a different design approach where either we might do this in terms of implementing some smart contract that in introduces some rules that we hope proposers will follow or it can be some kind of other ideal functionality similar to what Suave is designing that implements some kind of order flow auction among users and Searchers if we can design something that is not just maximizing the profit for the proposer but is stable and better for users and users are only submitting their transactions to this ideal functionality whether it's a smart contract or a protocol like Suave then the um the proposer will have no choice but to accept the block of transactions from this ideal functionality because there's no transactions going anywhere else and this only works because the consensus protocol is decentralized right if the if the consensus protocol was not decentralized then a proposer could say I'm going to ignore this smart contract this isn't good for me I'm going to ignore this ideal functionality I want people to submit to me the most valuable block I want to extract all the Mev because I'm a monopoly right the decentralization of blockchains breaks this Monopoly so that a proposer is a monopoly for only one slot and that is why if we design an ideal functionality stable for users the proposer cannot influence what happens the proposer can either take it or leave it if it leaves it the next proposer will pick it up the most it can do is delay so that's why extreme decentralization is so important from an economic perspective this is one of the most fundamental properties of blockchains from an economic perspective so proposer Builder separation over shared sequencers looks the same as over ethereum today because ethereum is a shared sequencing layer so if we introduce a layer 1.5 it's just introducing a new modular layer on top of ethereum which runs an order finalization protocol but still has some proposer as part of the consensus protocol that will accept blocks from a builder Network and we can design that Builder Network to be smart and do things in a in a way that's good for users like Suave or or some kind of smart contract design um so one of the things that let's we're I'm not going to really focus on Mev as much as how this problem of regaining interoperability and atomicity among um among app Roll-Ups that are sharing an ordering layer is that through PBS Builders can actually uh can actually make promises to users about atomicity and they can be slashed if they violate those promises so a very simple example is the following a builder can say I will process your trade on optimism and your trade on ZK sync which may be taking advantage of some Arbitrage opportunity to two amms on the different Roll-Ups and I promise that I will only execute them I will only include them on building a super block for both Roll-Ups and I will only include these transactions together if they both succeed if one of them fails I won't include either and this statement can be cryptographically signed so it can be used as evidence against the Builder if it violates This Promise so it can be slash it can build up a very large collateral that gives the user confidence uh it will it will respect its promise and the builder then provides this to the proposer of a consensus protocol that's not executing at all but is basically auctioning off wholesale a super block that produces a sub block for every roll up simultaneously to the Builder Network okay very simple um without a shared sequencer this would not work at least it would not work as well the Builder would have extremely high risk that if it tries to make this promise to the user it's possible that the independent sequencer or consensus protocol for zksync will accept the transaction but the independent sequencer or proposer consensus protocol for optimism will reject it right it is not now there is now two independent auctions and it doesn't have a guarantee it will win both whereas with a shared sequencer and a single proposer that is elected there's one option for both together so the Builder could be slashed and lose its high collateral even if it doesn't do anything wrong so um that's why sharing a sequencer allows reduces the risk of Builders allows for more Builders who can make these atomicity guarantees uh so the builders sit on this layer on top of the shared consensus this is how it looks in espresso a slightly more complicated example would be a flash loan so let's say a user wants to get a loan from a from Ave on one roll up of one million usdc deposited into a smart into an amm trading usdc against dye so now I can't immediately Bridge its funds over and just deposit it directly into this curve contract on roll up B so we'll introduce a bank contract and we'll explore the bank contract is going to have a branch on both roll ups okay so there's a branch on roll up a there's a branch on roll up B um we'll explain how this how the Builder can ensure this atomicity of these two of these two events but basically the user will send die to the bank contract and roll up a and it will get die from the bank contract on roller B then it will deposit into the curve get back is usdc and do the reverse right deposit into the bank contract and roll up B get it on roll up a I haven't explained how we ensure that those can happen atomically I will in a moment and then return the usdc to Ave on roll up a and keep the profit right all of this needs to happen in a single transaction that's a flash loan um so how does a builder enable this well the Builder who's building the block for both Roll-Ups simultaneously can provide a signature right again backed by some collateral uh and that just gives an instruction to this Bank contract on roll up B that says this action happened on roll-up a all right so you can release the funds on roll-up B and uh the the Builder creates a super block the bank contractor will be just trust the collateralized Builder signature if the Builder lies it's accountable and loses the collateral and roll up B is not the is not absorbing the risk all the risk is absorbed into the bank contract so it can become a business to design these contracts um and uh and specify your requirements for what Builders need to put up in terms of collateral and other possible conditions um and it's uh it's it's assuming some risk but it can also be taking a fee so this is an example of something that's enabled by shared sequencing which would not work without shared sequencing right of course it's not exactly the same as what you can do on a shared execution environment but it opens up a wide design space and really this is just a straw man simple construction I encourage people to come up with with more creative ideas um the Builder signature would do the same for roll up a bank contract as well it's symmetric there are some concerns that having Builders execute for all Roll-Ups uh may lead to Builder centralization um the reality is that executing for all uh smart contracts sorry for all roll ups is is not actually that high a barrier to entry right in fact compared with ZK proving it's not that high barrier of Entry ZK proving is extremely expensive it can be like 10 000 times or more expensive than executing um and the requirements of the Builder Market don't need to be the same exact requirements in terms of decentralization as the consensus protocol we need many many nodes participating in consensus so the proposers act passively and don't monopolize um we don't necessarily need 12 000 competing Builders to have a competitive market that takes care of um of monopolistic forces um so it can just be sufficiently permissive and open and free entry and have low enough barriers to entry such that it's sufficiently competitive in fact the barrier to entry for Builders is much higher without shared consensus because Builders take on more risk as I Illustrated a slide earlier Builders would require more Capital to win simultaneous auctions they would absorb more risk they can't promise user atomicity without the risk of being slashed so uh well there's a where there's a will there's a way um it's better to have shared sequencing we will lower the barrier of entry for Builders rather than increase so um Now for Something Completely Different I will talk a little bit about um PBS for responsive consensus protocols uh so ethereum's consensus protocol the um doesn't is not responsive meaning it has a fixed block time um if that is 12 seconds ethereum's finality is not actually 12 seconds it's um it's much longer than that because the transaction needs to be several blocks deep to be confirmed so it takes about 15 minutes to finalize in ethereum a responsive protocol um does uh doesn't it does not maintain the the extreme availability uh that ethereum has these two properties are incompatible but what a responsive protocol can do is it can it can it can give finality as fast as the network will allow fundamentally it will stall if the network is not doing so well whereas ethereum can continue even if only 10 of the network is live so due to the cat theorem these two properties are essentially incompatible um but uh optimistic responsiveness is the property that can get you as close as possible to the performance of a Sandfly sequencer in a decentralized way and the nice thing is you can compose them together because you could run optimistic responsiveness on top of a dynamically available protocol so consensus protocols that can return an answer immediately under optimistic Network conditions are called responsive okay there's no block time in is in in responsive protocols so how does this affect uh PBS so let's look a little bit at the round structure of Hotshot which is a based on pbft and is a responsive protocol in the first round the leader proposes a block collects back signatures then it will aggregate these signatures form something called a quorum certificate it will broadcast it again aggregate them and um and collect signatures on that um so again this can happen if if the network is very well connected or maybe there's even a Content delivery Network that assists this to proceed very at very at very high rates then as soon as the signatures are collected the protocol doesn't need to wait it can just move on finality has been achieved so under optimistic conditions we we can finalize blocks as fast as the network will allow the problem is with PBS if a leader has only one proposal before the next leader comes up uh then it's incentivized to delay because in order to run an awk it could it could for example run the auction for longer and obtain a more valuable block from builders um so one solution is not to rotate leaders based on uh on blocks but rather to rotate leaders based on some time window okay so we can allow the leader to propose and obtain finality on as many blocks as it wants consecutively until this time window expires I'm not going to go into the details of how you do that in the consensus protocol but that's the main idea it doesn't completely get rid of all incentives to delay but it goes very far to to mitigating this this primary concern um when is it safe for a builder to release data so in PBS for ethereum today the Builder releases data after receiving a block hash and then it races with the with the the uh the the proposer to relay that uh that that uh that block hash in order to get that block accepted and at this time it releases the data because ethereum nodes won't accept the and vote for the block without receiving the data now if the proposer proposes a conflicting block hash it could get slash but sometimes that slashing amount is low compared to the amount of profit it could make from stealing the Mev from the Builder so they really do engage in this race and it's even possible for the next proposal to Fork the block and steal the Mev so the protection for Builders today and ethereum is not actually that high and I'll argue that it becomes a little bit better when we when we were looking at a responsive protocol with a responsive protocol once a builder has received the signed proposal it can ensure the network reaches strong finality within a certain time window and under good Network conditions of course it's possible for the network to experience a fault but it it has it can gain confidence given its observation of the network that it has a and again a much higher confidence that it will be able to succeed in getting this finalized and not allowing the proposer to steal the Mev and do something else for even stronger protection the Builder may only release the data after seeing the first Quorum certificate on the original proposal remember there's two rounds this just brings it closer to the finalization gate and it doesn't really need to release the data until the second part um there are some caveats of that now we only have one round to broadcast the data instead of two um that's easily solved by broadcasting an encryption of the data starting at round one and then releasing only the decryption key starting at round two uh the decryption key is small and can be broadcasted faster so that solves that problem it's harder to pipeline proposals though with this idea so one of the nice things about protocols like Hotshot is it allows for overlapping rounds but if we hold on to the data and we're already proposing a new Block in the second round then this gives the builder of the previous block an advantage for building the next block since it's the only one who really knows that information ahead of time this might be addressed by order flow auctions right these ideal functionalities might be able to take care of that they essentially create one Builder abstractly that is the ideal functionality and have all the real Builders just participating in it as a multi-party computation so thank you very much that's what I had to tell you about today and next up we have Evan Forbes who is going to tell us something exciting about uh ending the proposer Monopoly [Applause] hello hello sometimes it takes a potato okay so I work at Celestia I'm a cordov my name is Evan and I'm here to talk about exploring Mev capture in modular systems and really start a discussion about a few ideas that they already exist if we combine them we can create a very powerful tool and I to be honest I just don't think enough people are talking about it and now before I get any further this has trade-offs everything has trade-offs only siths deal in absolutes so just getting that out of the way the alternative title to this talk was how to make validators cuts and on one sense I'm just being playful but on another sense I'm being very real weirdly real so like the status quo validators is capturing large amounts of value right this is how it works today and this stems from the fact that they have a monopoly over that given block now it is a small Monopoly it is only for one block but sometimes like in the context of a builder it's very important we can have a builder build a block it has three heart emojis that's a lot everyone loves that block but that's not the block that gets committed that's not the canonical block that's because a different Builder found a way to exploit more Mev or do something else and ended up bribing the proposer more so now we pick that block so the proposal is getting most of the money now that's not the end of the world it's not even the worst thing in um ideally like uh the proposer can up the security budget there's it's not even sure that like this is not ideal like all Mev has to get captured somewhere going to the proposer is not the worst place however it would be really nice if it was more programmable if we had a way for l1s and l2s or roll-ups to be more programmable so we also have to consider that with roll-ups this has to be scalable not just in the sense that there's like a thousand different instances of the setup but also in the sense that roll up devs only have so much brain capacity they can't be playing like these 5D chests when they're thinking about these things so shout out to skip if anyone from the skip team is here for pushing The Narrative of sovereign Mev now all I'm trying to say here with Sovereign Mev over solving Mev is that there's many different solutions to capturing Mev there's not just one there's many we're picking winners and losers here all right so that decision is between like a community and their God that is not like a decision that you can make for everyone all at once that's at least what I believe so in order to solve this to make Sovereign mov you have to move it on chain because when something's on chain it's programmatic and when something's programmatic it inherently in the context of a blockchain is verifiable so so if we want it to be Sovereign all we have to do is choose to change our binaries by simply switching our binaries right we now have changed how Mev gets captured assuming that we can get it in protocol so in order to do this you have to break the proposer Monopoly this must happen so this is a meme that I stole from Elijah Elijah works at Duality he's done some amazing work in this area of ending the proposal Monopoly and if you recall the first slide right if we don't end the proposal Monopoly then there's always going to be some sort of censorship that they can do in the context of Mev to game the system so we can write whatever clever rules we want on chain but it doesn't really matter because the validator can always or the proposer can always accept a block that gets built to game the system so also shout out to special mechanisms groups a lot of this work is just like repurposing their work uh highly recommend um so we kind of have to think about different things differently instead of building a block and then coming to consensus over it we have to come to consensus over an unbuilt block and then we build it right we we build it using a deterministic function so there's two things necessary here we need to have a way to have for proposers multiple proposers include their input for what they want to be in the next block in the next block Elijah refers to this as Multiplicity so there's many different ways to do this one of the simplest ways or one of the ways that I keep coming to is just some different flavor of narwhal and or tusk and um that is great because it makes the entire block censorship resistant there's other ways to do this so skip does top of block auctions they already have this implemented if you want to go try some of these ideas out you can literally go do this by building a cosmos chain right now thanks to skip and you have self-assembling blocks so this is the second part the second part is that you need a deterministic function to build a block and you can't just it's very important that the order of the inputs doesn't matter right it's addition you can add two numbers in any order and you'll get the same result that's the important part here once we have these things we are now free to Define Mev capture so this is again in the context of l1s at the moment where for the simplest case all we need to find all we need to Define is a less than or equal function of what a bundle is now what's the only thing better than one fire emoji three fire emojis correct so um if we have this if we have this we can do something that's similar to a four Choice rule but now we have a bundle Fork Choice well for so you imagine we have a less than function that's all you need for it to sort now we can now we can sort these transactions or these bundles and if there are any conflicts then we go back to that rule well which one has more fire emojis okay well we're going to pick that one and you can replace fire emojis really with anything but this is has a cost this has trade-offs this is not for every state machine this is not for every blockchain in the context of Celestia there's one thing you can do you can pay for data to be included in the block that's it it's payments this this means that there's basically no conflicts conflicts are incredibly rare so that dramatically that makes it so this it's like a very viable thing to do in Celestia now if you consider other chains like most chains today are like these permissionless Turing complete smart contract platforms that whenever you see a transaction you can't even know what state is accessed until you execute the transaction that's not really like a viable thing you can't just have like a deterministic function not only that is that if you have a lot of like Mev to be exploited then it turns out that you have something that I'm referring to as death by gas auction you just get completely overwhelmed unless you have some sort of private member that's not like a hypothetical that's like a well-tested thing that happens all the time so this is this is like it's very dependent on the chain fortunately for Celestia you can do this so now the proposal Monopoly has been broken we can Define how we want Mev to be captured on the L1 rollups should also be able to easily Define how they capture Mev and they can do this too right the proposal Monopoly is broken we can submit multiple different roll-up blocks as if they were a builder like in PBS to the same Celestia block and now it gets included right and now we can Define similar how do we've defined a bundle Fork Choice Rule now we can define a just four Choice rule a normal four Choice rule except for it's completely arbitrary we're used to Fork Choice with like hash power and stuff right this is just completely arbitrary what does heart means it could mean judging by Twitter sentiment people love to burn tokens I hope we get more creative than that but that is like a perfectly functional thing whoever burns the most roll-up token not the L1 token the roll-up token whoever Burns that that's the canonical block right four Choice rules rule because you can just have anyone build you can make it so that I can have like literally anyone can submit a block Roll-Ups do not have the same issues that l1s have where you have a limited set of block producers Roll-Ups can have however many they want it just has to be defined in your four Choice role so you can like again like you can this can be very arbitrary Rock beat scissors but the coolest thing about this is that if we ever decide that we want scissors to beat rock all we have to do is change our binaries right we can just do that and in the context of modular blockchains in the context of these uh we have these trust minimize like clients right these light clients are the ones that are verifying the chain the node operators right so they decide like clients decide how this actually operates how Mev gets captured oh and as a side note you know you can decentralize how your rollup gets sequenced just by simply having a four Choice Rule and relying entirely on the consensus of the base layer no big deal shout out to row kit they're working on this if you really want to get your minds blown talk to a roll kit Dev lastly again not everyone can do this this is extremely limited it's almost requires privacy Tech you can ditch sequences entirely you can just have a bundle for Choice Rule and again and um it will the blocks just build themselves so there are trade-offs this will not work for everything okay so it has increased demand for Block space currently that's DOA it won't work but can we imagine a world where block space is abundant thank you Nick so if you now if voxace is abundant this is actually more feasible than we think and increase full node requirements there's no way of getting around that this has increased full node requirements however it's very application specific if it's very dependent upon your fork Choice rule it's very dependent on so many different things so we can build around this if this is a property that we that we want really bad and I mean this isn't really say anything new but like in order to have good Mev we need more privacy tools and um same thing goes for here so when Mev is defined in protocol and when light clients can verify the protocol right that means that like clients can determine how profits are captured in a system that's pretty crazy right that's pretty that's pretty damn crazy right power changes hands it is no longer just the validators the politicians the technocrats and yes even the token holders who are deciding these things it is like clients they are cucking all of these people okay so that is how I would like to end my talk um if you're interested in anything else if you're interested in anything else I have a GitHub Evan Forbes or just find me on Twitter or anyone from Celestia thank you very much Evan and next up we have John who will take the stage all right we use this thing okay cool I've had a lot of coffee and have a lot of slides and I don't have a lot of time so I'm probably gonna be bouncing for this a bit I'm going to be talking about why like proof of stake like kind of makes sense but like kind of maybe doesn't make sense um and particularly I'll be there we go so this will be applicable to like pretty much any proof of stake type chain but in particular I'll have like a lens on rollups for this so I'm talking about it so we've all heard there's like a million different sequencing decentralization options shared sequencer you can run auctions proof of stake like all these different options in particular I'm going to be focusing on these last like kind of sub-components of that which is applicable to a lot of places so that's proof of stake and proof of authority and kind of like variations thereof and my goal kind of by the end of this talk is to convince you that those two are like actually kind of the same thing when you play out like how this rationally looks at the end of the day whether you have a proof of stake mechanism or you just like literally let your governance just say hey these are the people that we want to be our delegates and just don't even bother mistaking they kind of end up in the same place roughly so starting from really Basics what is proof of stake for it is not to slash people's money the like fundamental reason why you have proof of stake or proof of work or similar things it is fundamentally a civil resistance mechanism we need people to vote for us and if you just let any single person one person one vote you get simple attack so we need to like meet her who can actually contribute into this system so the simple way to do that generally in any permissionless protocol is you tie it to some kind of real economic resource so proof of stake you put up stake proof of work you prove that you burned energy so you've submitted some real costs the other way around this is also you could just have basically like a permission setting noting that the difference between permissioned and permissionless is like actually kind of subjective and like how people Define it but you could just basically have some form of trusted set up really we say like hey these are the people who are voting for us we know who they are we trust who they are um so okay so looking at proof of stake how does it play out when you like actually look at what happens and where the uh incentives go so simple delegated proof of stake um if you don't do it in protocol it'll rise out of protocol but basically there's a clear separation between the people who have capital and people who like actually want to run the operation so you naturally need some form of Delegation like I might have Capital that I want to stake but I don't want to run this stuff so I delegate it to someone else that's super Capital inefficient among other issues so you end up with liquid staking tokens like this is what we see on ethereum this is why Lido popped up so this helps provide people liquidity do the auto protocol delegation for them hands people back like okay I don't want a stake so I get my steep token and like someone else they go figure it out like how to manage that for me one of the problems with liquid staking that like people talk a lot now about is this like kind of inherent principal agent problem between someone like Lido and someone like ethereum or any other protocol is Lido may have like a profit incentive that is not aligned with like my values and my governance of my chain so this is why something like dual governance is like pretty much necessary in my mind for like any kind of liquid sticking to be viable in the long term it's like some way for that protocol to align itself with like the underlying protocol so in the case of like Lido what they're talking about is like okay what if we get instead of just letting you know ldo tokens decide everything we gives teeth holders of veto rights who are like presumably a subset of like this ethereum consensus that are aligned and will have like a different motive than necessarily the profit-seeking ldo holders which is helpful um so then I'll get to the next thing so proof of authority kind of like is like this like dirty word that like whenever I try to like say this the reaction is generally oh that's super centralized it's gonna be way less secure like this doesn't work um I'm gonna try to convince you by the end of this that I think like variation of this could be more secure and more decentralized than a proof of stake mechanism like very clearly um so proof of authority I think like I think that's a reasonable term when you're talking about like a truly like private permission type blockchain um potentially even like an rwa one where like Circle has like real control over this thing proof of governance uh I'm saying that like there's a clear incredible governance mechanism place to choose these delegates so it's like actually a bit reminiscent of the way that like Mustafa has described the difference between solvent ropes and smart contract ropes and maybe more of like a social distinction more than like a very Concrete technical one but I do think it is important so simple example will be like look at Roll-Ups like they'll presumably take into simple case like you have a smart contract bridge on ethereum that has like very powerful governance for this roll-up and for something like arbitrary to even see the initial form of this today where like you can force inclusion of a transaction through the L1 and they could forcibly remove the sequencer if they should so choose and so really they could just choose like hey here are the 10 delegates that we want to be our sequencer instead of the one so now I'll start to go through like concretely like what are the differences between all of them so one is permissionlessness so this is part of why like I'm targeting this specifically at Roll-Ups like I would say off the bat this is obviously not an ethereum uh like an ethereum type option it should be very obvious why like ethereum does not want to be like actively saying like hey here are the 30 people that like we trust to do this for us you want to let you know validator number one million join the validator set and like be non-openidated about that which I think is like very different from Roll-Ups um and that's the point here is like that sounds like a downside but I don't think that if Roll-Ups are optimizing for the same thing that their base layers are optimizing for like they're already paying the base layer for that decentralized consensus in the first place like and that is why they don't they're not going to even from an economic perspective it's not even going to make sense for them to have validate and remember willing one million and no one's going to want to do that and it doesn't add anything really like it's particularly for that kind of Doomsday scenario that they're already paying the L1 for um and in addition like kind of going back to like Patty's talk before it's actually like very helpful in many cases to have permissioning because like you want them to do things things like enforce certain transaction ordering um okay and governance this is very related to the point before like ethereum does not want like active opinionated governance that's like saying hey we're picking all these people I think the Practical reality is that like for most Roll-Ups though they're probably going to have this like you look at the ones today and the simple examples like Optimum is an orbitrum they have this giant Bridge you're required to have some form like legible on chain governance that will be presumably powerful powerful unless you think that they're optimizing for this like very immutable type contract and governance which I tend to think is like rather unlikely for most of these but it does make a difference if you do um so accountability this is like one of the things that everyone um kind of like Harps against here is like this is one of the big benefits of proof of stake it's like oh we could like slash the bad guys uh and like that is seen as one of the benefits um I like tend to disagree with that once you like actually play out what this looks like in the long run because the reality is the large majority if not all stake is going to be delegated like there's a natural economic incentive to separate capital from labor and we like see that play out very very clearly in every proof of stake system what I think is like the real advantage of proof of stake over work is like it's not necessarily the slashing aspect I think it's more so particularly once you play out the economics it's the very targeted removal of who the malicious attacker is where in proof of work you like you nuke the hashing algorithm and you restart from scratch and you're kind of screwed so in proof of stake it's not so much the slashing part of it that I think is like necessarily the most important important part of it it's that you can very targeted remove okay these are the bad guys these are people we want to get rid of and you still keep the same thing here if you have your governance just electing them um so this is why like I think like Economic Security just gets like a little overhyped sometimes when you like look at the simple incentives like you could have one billion dollars or 100 billion dollars if the guy who's like the operator who's doing that like it's literally not his money this is not like an incentive compatible thing it is just a reputation game that you were like assuming that they don't want to light your money on fire which is fine but like they also don't want to like screw their business and like lose out on all future profits it's the same thing like it's an understanding this is reputation game and not like a cryptographic like crypto economic incentive compatible design um so the so the other point is like so you realize okay so if it's not necessarily just as a punishment mechanism you realize but it is still important like okay if I'm gonna get slashed I'm going to pick my delegator wisely so it is an incentive mechanism for me to pick a delegate appropriately which does matter and so uh so moving on um so like this is uh from like a post that Nick Carter had a while back called it's the settlement insurance and stupid which is actually very good um so taking some pieces from it Ledger costliness you're talking about the amount paid to validators uh Slash transaction selectors per unit of time and like particularly in the proof of work context you can assume like reasonably closely like this reward paid is proportional to like very close to the amount of like energy and real cost that is spent to earn that um and a greater your salary to them means like a greater security because like it is more costly to reorg that chain if you're paying them more because that means it is a higher cost to do so um and then on the other side is uh like kind of badass quote from uh the prince that Josh sent me which is like kind of reminiscent of this like it reminds me of it a bit where if you're basically relying on Mercenaries like when the day comes when they're like not necessarily aligned with you like you might kind of be screwed so you probably want to have people who are like are aligned with you and not just always like explicitly dollar for dollar profit seeking in a situation equation like this so talking about settlement insurance is broadly systems ability to Grant recipients confidence a transaction will not be reversed so Economic Security when we talk about it we're talking about like what is the cost to reorg the chain here so proof of work as I mentioned like very simply you know you have to pay some money to like literally mine the blocks to do this proof of stake it's Costless to simulate blocks so like when we're generally talking about the economic security we're talking about the slashing but like as I kind of just described that slashing is like not necessarily deterrent if you're delegating all the capital to that person so it's like it's not like the actual same protection there um so delegation does remove that and you start to realize it is more of a reputation game so if we play out that scenario where you do have that separation of capital and labor which is like where the natural economic incentives lead to what is proof of stake at the end of the day it is back to that thing that I said in the beginning is like the fundamental thing it is a civil resistance mechanism and a mechanism for us to delegate who are the people who care about our system and like those are the people we're going to delegate to vote for us it is not necessarily like a way for us to actually penalize them because there is an incentive for it to not be their money and like have that separation again so then the question is okay if this is a mechanism for us primarily just to like actually pick people who are very aligned with us and like have the right distribution of the validator set is this the best mechanism for us to pick them and like this is where I've a rather strong opinion I do not think that it is because like it's a simple like tragedy of the commons if you take out like liquid staking protocols like I think dpos is like the worst with without them arguably because like it what does regular user you know like do in this scenario I go look for like who's the biggest validator the second biggest validator like I go delegate at the coinbase or wherever else like it's nice that you have a permissionless long tail but the Practical reality is the large majority of stake ends up going to like two or three people um versus proof of governance you're not like you're not putting like okay my dollars go to this person like I select that person we are voting as a collective for like what is the best distribution as a collective interest for all of us so we can go intentionally pick okay here are the 30 geographically distributed people that we like and we give them equal voting powder across them I think there's like significantly harder to corrupt and like potentially more decentralized and that's like actually what we see with like so like moving on here like this is the decentralization which like kind of follows on that um like what is decentralization it's like that it's that kind of that point that I was saying there of like is it validator number one million that makes you decentralized or is it like the composition of what do we care about like the top of the stake um and in particular like this is kind of like the like visual example of it like which of these is these centralization and particularly for a roll-up I would argue like the second one is actually the much more important one particularly because they're paying the L1 in this case like four is that doomsday type scenario of recoverability they are like very much optimizing for like what are the real-time short-term guarantees because like also their real cost is like being immediately reset once they like go back to the L1 so I think the second one is more important and the second one is actually like that is Lido's ethereum stake distribution like this is very intentionally what they do under the hood it is we pick these 29 delegates who are decentralized who are responsible and these are the people that we equally distribute votes to and like that is the kind of thing that you can basically just in-house to your protocol if you have the opinionated governance to do that so in terms of capital efficiency this should be intuitive tpos incredibly Capital inefficient like it's not good if you're you know your type of like roll-up economy or whatever it is LST is significantly better but you are adding on like the additional risk of like these uh Financial derivatives discrepancy between like different types of holders on bonding periods Etc uh I would say proof of governance is like absolutely optimal and like kind of all of these Dimensions everything stays in the native base asset everyone has like an equal value capture to like whatever it is you decide you want to burn it go ahead like you want to send money to your treasury to allocate it based on whatever your subjective governance process is go ahead and like you just have this explicit agreement like the validators get paid X slash year of sequencers um and so like this is what it comes down to is like the alignment that I was like kind of touching out with the Dual governance before so like this is a section taken out of like Danny uh Ryan his like very popular post on like the risks of LSD where he's talking about okay like lydo's doing this dual governance thing which is supposed to like okay that'll mitigate the principal agent problem but he's saying like Okay but Steve holders and Heath users like that's not the same thing it is still like a significantly lesser alignment um and then also had a post after that pointing out which I agree with is like this is not just like a Lido slash uh liquid taking thing this is just like an inherent problem with proof of stake like people who are staking in dpos they are also not the entire like superset of like roll up slash chain users slash those good census like there is a disparity there so what do you want to have do you want to have your roll-up token holders just like deciding by themselves like these are the people that we delegate to do you want to have an LST governance deciding it like completely for your chain so it's like maybe a little bit better because it like maybe it's more decentralized but it's also maybe worse because you're less aligned LST is able to go dual governance I would say is the best of those three because like you're letting a subjective governance process intentionally decentralized but like retaining power over it to like veto harmful actions and the last one is the cleanest one of just why don't you have your own chain designed um like again this doesn't make sense for something like ethereum because like they're not going to have that opinionated concrete governance process to be like selecting all these different validators but that is the exact opposite of what a lot of these Roll-Ups are doing and I don't think it's a coincidence it like happened to actually see it I think it was like a day or two ago optimism is to the first of my knowledge the first team to announce this in their governance post that they put out the other day that they intend to basically this is their plan at least initially for the sequencer it appears that their token house will be able to initially um choose like who are like the sequences that we want to whitelist and then their identity based citizens house would be able to veto those decisions like that is very different than just like a straight up token holder's alt vote um and so like that is kind of the point here is like we all know that like token voting is like not necessarily the best and like this lets you bring in that more subjective governance process that you may want to be creative with even if it is just straight take on holder governance I would argue that the majority token holder governance as a collective would make a better decision than everyone doing it individually but when you also introduce something like this where you allow identity based governance to be able to have additional rights like that is a very clear advantage over these other ones where you're entirely subject to like okay what are the token holders decide [Music] um so this was like kind of related to that like who's the monopolist in the scenario um there are like short-term monopolist powers of like whoever is the sequencer slash whoever is the validator in these protocols I would argue like the much more important Monopoly power on like any rational time span is like whoever chooses those people so whether that's the token holders the governance like whatever your mechanism is and this is like a similar quote again out of like Danny Ryan's post which is like yeah like Lido could become in that position like that's an important reason for dual governance um but that is like that is a power that you want that you don't want to be handing over and like I don't think that is the power that the sequencer reasonably has like yes they can do things on a very short time Horizon then you can immediately remove them and they lose all of their future Revenue like I think that latter person is the person who's actually in control there clearly um so that was a quick summary I mean like proof of mistake like it makes sense of protocols that are permissionless they don't want opinionated government it's like that makes sense for ethereum but like clearly lsts will rise and they do help decentralize meaningfully in my mind like Lido adds to the decentralization of ethereum like very clearly I'm like just just look at the operators and distribution of like versus if everyone just gave that state to coinbase like it's clearly significantly better so some form of dual government is also necessary in my mind proof of governance like I I think that too many Roll-Ups are just over indexing too like okay this is what ethereum did so we need to do the same thing but I think that they're just like they're fundamentally building for a different thing like ethereum is building four Roll-Ups Roll-Ups are building for users primarily and they're like optimizing for very different things because they're already paying their base layer for all of those types of assurances um so I do think that this is like very viable for them because they do have very different priorities and because sequences are fundamentally just like less powerful than like L1 validators in particular like as like they are getting this finality and like you immediately like that cost to reorg effectively goes back to zero when you're posting to the layer one like they are very short-term guarantees um this is like kind of the key I would say synthesis of the whole argument is like as a summary if we put things back together just like how does proof of stake end up playing out you do some form of simple dpos and okay Capital holders like they want some form of liquidity we want delegation of stake away liquid taking arises like that's very natural it's Capital efficient it's better but we have that principal agent problem so we introduce dual governance and what did we end up with at the end of the day is a total separation of capital and labor because that's where all the economic incentives are and we have a governance mechanism that is aligned with our chain that manages the delegate selection so the only questions at this point remaining are really do we want to let that delegation sit outside the protocol do we want to have this taking mechanism let you know Lido rocketpool whoever decide that and then we like try to rein them in with like some sort of veto right slash have a market there or do we just like in-house that because we have our own governance we don't need to let them decide slash we don't need to leak value out to some other protocol that's going to like take you know a chunk of all the revenues and then why add these Financial derivatives like like I came from like a financial derivatives background before this and like I like I'm rather opposed to just like layering on a bunch of financial derivatives on top of the consensus layer if they're unnecessary like they tend to introduce a lot of hidden risks that we like don't particularly understand and like I don't think it's a Pandora's Box that needs to be opened for Roll-Ups necessarily and in particular if we realize that it's primarily a voting mechanism it's not like an incentive compatible like deterrent so we don't necessarily need it and I think that is a risk that is like better to avoid um so it's not even that like proof of God governance is like this like perfect thing I think that this is inevitably where you end up if you just play out the economics I think this is like this is the rational Market outcome of letting these economics play out is this is where you end up it is the governance it is the changes that is in control in the best case so why not just like enshrine that and put it in the best way um this is the reason that like I'm kind of like skeptical about it like governance is really hard I like do not doubt that um it's really really hard to do this like just saying like oh yeah go replicate everything that Lido does um but in particular for like chains like optimism like Arboretum Etc that have an octave that have a very involved governance that is thoughtful and is able to decide like these are the delegates that are aligned for us I think that makes a lot of sense um this was PBS day and I didn't really talk about PBS um you could do PBS with all these and I think it like actually makes it easier because when you have a permission set um you've like the simplest example would be like you're kind of back to like the Mev gethi days uh more so where it's harder if you're trying to optimize for like boost like oh yeah we need validator number one million to be able to do this and like we can't trust them if you have like 10 people five people whatever it is that you can kind of trust them makes it a lot easier to like not have a lot of these censorship and sensorization problems like the sequencer can like add transactions in and you trust them kind of not to screw you um and that is all these are the slides thank you and I'm I have no idea where I am on time I'm assuming I'm over and that Tina is up next well in fact we're switching water a little bit but before we do that um one question from the audience anyone all right oh it's gonna be a tie hi um really enjoyed that thank you and it's in line with uh mostly aligned with most of that one question I do have is how do you think proof of governance affects liveness and the relationship between that and censorship resistance right because there does seem to be some use cases you know maybe it's a governance vote maybe it's uh defy liquidation maybe it's sort of a you know a game that's being built on an L3 that requires very strong liveness guarantees and it strikes me there are a lot of instances where leibness failures can actually be censorship resistance failures so I'd be interested to get your perspective on how whether or not proof of governance changes that and your thoughts in general yeah I mean it's definitely primarily like one of the largest reasons I think that you should at least decentralize the sequencer to some capacity even if you don't need to go to a meaningful extent it is the simple fact of like yeah servers go down like that that is not a good thing for any application whether it's high value or low value I would say the like absolute minimum that I would want is even if you have a default centralized sequencer as governant votes of okay we have these like five backup hot like backup sequencers that okay if x number of blocks are missed like we just go to the next one we go to the next one just like down the list and then open it up after that so I do think it is a critical even if you want like a default centralized sequencer because it is super efficient just like have one person giving you these guarantees but be ready to go like these are the governing selected people that we trust to fill in for us similarly for censorship um I think it is like again it is easier in my mind to like do the PBS stuff when you don't have to trust like validator number one million you could say like hey we have 20 of them and like the Builder becomes less of a choke point now because like okay they could see the block they can add in the rest of the transactions like it looks more like I've got which is helpful and then also just the simple composition of like the sequencer set themselves is I think it is much easier to get like a graph that looks like the Lido distribution graph versus if you just like let staking economics play out it's like what you really care about here for censorship resistance there is like it's not like what are what's the composition of the last like five percent of validators how many are in there it's how many do you need to get to one-third slash 51 slash two-thirds um and I think this is the clearest way to get like a very broad composition across that and then you could also add another mechanisms if you want like multiplicity Etc to help with that as well great question a great answer I'm really curious need of next question so I'm gonna let you ask away can you elaborate on why you think this is more appropriate for Roll-Ups rather than l1's I I remember on the slide you mentioned the permission list part of it which I I do agree with but can you elaborate more yeah so I I guess I would say oversimplifying there it's not necessarily just a layer one versus Layer Two like as kind of shown in like a lot of the screenshots there like one of the people who's been like starting to tweet about this lately is like a sunny and like I think this makes sense also for like plenty of Cosmos L ones where it's it's very similar to what I'm describing with the Roll-Ups of like okay we have a very clear tight-knit Community there's like a line on like what our values are we have an active governance process like we are able to manage this so it's more of a neutral slash permissionless base layer is like what you're going for um that like would not want this like it's just not an option so ethereum is a perfect example of like obviously they cannot do what I'm describing like it would make no sense um and that is reasonable in my mind because particularly for the bass lawyer like that is generally the area that you're looking for like okay we want you to become completely credibly neutral like no subjective process even if like the free market economics are like kind of concerning in the long run I think it's also the place where like you have a best shot of like winning that battle I would say quote unquote where if the economic incentives are to like okay you know centralize all this like there has to be like some kind of soft pressure against that and I think like ethereum is a type of place where even if there's like a slight incentive to centralize it more like there is a very strong community and like a very strong push for decentralization I think that's like a winnable battle to like very intentionally keep it decentralized subjectively um so they're they're different optimizations for different chains so it's not necessarily just an L1 versus an L2 I think that just generally speaking broad brush Strokes like l2s tend to fall in that latter category of like more opinionated more active governance and are optimizing more for real-time guarantees as opposed to like neutrality and long-term uh like nuclear war type resistance all right thank you John thank you for your 2x speed um speech next up we have a panel the end game how many of you here have read a blog post called endgame raise your hand okay is it by Rune from maker Dell or uh you raise your hand if it's from metallic all right we've got a informed audience shall we hello everyone um I think we'll be joined shortly by uh floating Avatar in the universe oh there we go okay great hand Tony yeah I hope you're having a good day Avatar sorry I haven't watched your second movie yet [Laughter] I I mean it is pretty good it is true that Anatoly does look like he could have been an extra on the Barbie movie but you know I'm not I don't know what else to say about that right now but nice nice this is my fame and cosplay for Oppenheimer yeah well you know uh as we learned today uh vitalik prefers Bob the Builder and uh maybe we'll we'll have Bob the Builder next time but um as as many of you know this panel is uh the the end game panel uh and I think uh you know part of part of this panel actually stems from last year at the last modular Summit which was sort of April 2022 so before Luna when we were all you know felt safer more comfortable less annoyed at people in the world I felt less safe before the Luna collapse that maybe that's also fair fair it's safer as in uh you know I think the debate was actually quite different at that time yeah at that time I think there was a lot more hype about monolithic architectures and modular architectures were sort of coming from behind and I'd say Obviously some of the stuff that happened the last year made people people Flip or you know things change the Luna stuff like it had lots of moral lessons for me but like totally nothing to do about monolithic versus modular so I'd love to hear that kiss yeah I think that's more like app chain messages yeah right but like okay I guess to me like Luna was not bad because all you know was monolithic versus modular or like on ethereum versus on bitcoin versus on um you know Cosmos versus Ursula or whatever right Luna was bad because it was a fundamentally bad design like the exact same design carbon copied onto ethereum would have been just as big a a collapsible failure for sure I I I'm more pointing out that at this time people were much more living in 2021 land okay this is true and and like that was when you know I think the psyche was broken right so I just wanted to say like give some context of like the last time we did this it was sort of modular was really the underdog it's like if you look through like a lot of arrows right like remember the scene where like Boromir just like it gets like shut down by a bunch of work arrows at the same time and it's like you know first you have Luna and then like you got the Celsius arrow and then yeah but um and then you got the the big FTX zero and then he is kind of dying and then there's just like one extra Arrow from like what was it I guess like dcg or whatever just like shoots in yeah so there's been a lot of arrows indeed more than three uh well all of our future arrows being beautiful diagrams there you go exactly commutative diagrams only uh you know we're all secretly category theorists I don't know I prefer non-commutative because like you know we want to have progress right like we don't want to just like go from the same place all right well click clearly clearly there's already even debate about whether anything has changed since last year so maybe maybe Anatoly and Mustafa let's start with you know in the last year what uh what in the monolithic first modular worlds has changed from your minds yeah so I think like um one of the biggest changes is a year ago there wasn't really um any kind of like frame roll-up Frameworks you know those like opposite the same arbitrary other kind of like optimistic Roll-Ups but there was no kind of Frameworks to to kind of create your own roll up now we have you know upstack we have arbitrim orbit roll kit as well and I think um kind of last year a lot of emphasis was the main reason why I needed Roll-Ups is scalability which is true but I think there's been a what I've realized over the past year is that um one of the most underappreciated aspects of Roll-Ups and modularity is that it gives developers more choice and freedom over the execution environments and that lets you do really cool things that just haven't fundamentally been possible before you know you can modify the evm and other DK op code so you don't have to you know use you have you can do more efficient SDK verification than just Squad 16 and that's really good for privacy or for example you know curio has modified the evm game engine to add their entire game as opcode on the on the app stack which can be thought proven on their mips photo printing system so I think it's kind of like this flexibility of execution environments um is really unappreciated and I think like might be as just as big or as as important um impacts of the space as as the scalability aspects Anatoly I think um it's been really cool to see the development of uh Roll-Ups and having them ship and actually seeing their performance numbers and from my perspective I've never thought of them as scalability Technologies because fundamentally you're still limited by the bandwidth of the layer one and uh if you can't exceed that you can't really scale beyond that we can do all sorts of other tricks but that's kind of like the bottleneck and when you start scaling that piece we haven't yet seen folks go beyond what a monolithic architecture that can provide um so I think that's coming I actually am pretty bullish on uh things like like clients giving pretty close to better than honest majority assumptions between shards and all these other things so I'm excited to see for that next iteration in like the actual base layer but uh so far from my perspective like actually the the main use case for Roll-Ups is that like giving new execution environments giving new ways for devs to to build you know a full game as a fraud approvable thing I think that that's a really really cool thing vitalik any and it's interesting because I think uh like pre-2019 vitalik was fully on board with the idea that Roll-Ups are not real scalability Technologies but then like that was when I moved pretty decisively away from that Paradigm like if you read my 20 pre-2019 stuff like I was talking about how like Roll-Ups aren't real scale because like they're not a uh like they're not a Big O notation improvements right like you know I talk about how regular blockchains are ofc like their capacity is like linear in the capacity of a computer but then like shorting is ofc squared right um but like Roll-Ups are o of c times like somewhere between 10 and 500 right and for a long time like the mathematical Purity side of myself got really hung up on that but then at some point I was like okay yeah yeah fine like a factor of 10 to 500 is still a big deal and like that was when well I guess and at the same time a kind of exhausted you know State channels and plasma and all of those things um that uh you know just to realize some of the fundamental limitations that they have in terms of health plasma requires every object have a logical owner and like the whole you know defragmentation problem that I mean I'm sure of Carl first was here you could tell even more about because they tried to even Implement like actually Implement that uh but uh the basically yeah like a gain of 10 to 500x is still a gain I think it is true that like in practice we've been slow on getting there one of the reasons why is because like close to half that gain comes from data compression and Roll-Ups have been pretty slow to actually Implement data compression and you know there's like all of these reasons of like oh well you know we don't want to have L2 nodes have to be archive nodes and like all of these things but these are they're issues that like can be engineered away and like like even evm parallelization it's like you know can be engineered and there's a difference between sort of solved in your head and like hard engineering so log solved and like that's been one of my own big or uh big warnings about the ecosystem um so I think like to me I still look at this from the perspective of like what is this going to look like like even three years from now right because we're definitely not nowhere close to the frontier of what even currently known approaches can provide right so so with that actually uh a great great thing to talk through you know there have been multiple end game blog posts all over the internet but all three of you I'm sure have very strong views on your views of what the end game should look like um so you know maybe in your own world words Define what you think the end game of the Technologies you're really interested in should look like what kind of things should they offer users what kinds of things should they offer sophisticated actors to to who maintain them what should they not offer them and um you know I think having a having an eye towards you know where where you really think the long far future is I think vitalik's talk today ended with a very good picture of what he thinks the future is at least in terms of you know the big proof proof thing yeah yeah I mean like my view on the future is definitely that like you know we have proofs out and I think like I've used the analogy that um you know zero like succinct zero knowledge proofs are to cryptography what Transformers are to machine learning like they're like there are to AI like they're this uh one single technology that is just so powerful all by itself they just like completely you know like sweeps across Decades of hard application specific work by thousands of talented people and just says like okay you know bye bye you're gone and uh replaces at what time with them vastly better alternative right and like that's just something that we have to adapt to right like anything that gets built today should be built with the assumption that like it's that like proofs exist as an ingredient and like that was not really part of the mindset a few years ago and like a lot of things change when that becomes part of the mindset right I mean obviously I mean like projects like you know were I think pretty early to that and uh you know had the evm been conceived even five years later it would have looked very different had I mean even the beacon chain been conceived even a few years later it would have uh I mean I worked we worked very different right like even when the beaker chain was built it wasn't really built with this uh Assumption of proofs in mind and so if we yeah half a world where we can just like assume that you know things can be proven and there's going to be a lot like everything that can be computed is going to have a light glance of it and all of those things like that in some sense like simplifies a lot of things and but um you know it still leaves open a pretty interesting design space of What kinds of things are going to exist and there's a lot of details that you can talk about yeah so typically to piggyback on that previous aspect and when I kind of like think about the end game I think about you know what is scalability and I Define scalability as three ports divided by the cost for an end user to verify the chain and so for the end game I think like how can we maximize throughput transaction 3 Port without without increasing the end cost for the user and that's only possible thanks to taking for you know proofs um you know data availability sampling fraud proofs Decay proofs um and and that should be the case even in the world where um the centralized block producers because we can still achieve the properties of a blockchain because you can still have you know censorship resistance and um verifiability even in the world where the centralized block producers um by using things like PBS and CR lists but to kind of go further I can to me the end game I see a world where the it will be easier in the future for developers to create the decentralized application by deploying a roll-up chain then deploying a smart contract simply because in a world where there's proofs there's simply there's no there isn't a good strong reason for um apps that are not to directly connect with each other to be to be sharing computational resources when the computation can happen on their own environment and simply have a proof that happened correctly all right I think the biggest exception to that is composability right like yeah yeah Anatoly with that I think yeah I think we're ready we're ready for for your end game yeah it's uh kind of interesting how different it is so I even going into the space you know five years ago I always thought that the biggest challenge was the available equal and fair availability of the data itself and this came from my experiences as kind of like amateur Trader through like interactive brokers and all these other systems whenever I had an algorithm that I thought had an edge my trades would always be a little slower and the data that I would need would always arrive a little later and I would always kind of lose and that's because I was playing in an unfair system um and the way that I designed Solana was with this idea that we have a single Global message bus and it tries to propagate all the information around the world simultaneously as fast as possible at the speed of light with this kind of like end State being that you know imagine some crazy trade event happens in Singapore that Newswire Solace to travel Speedo light through fiber to a Bloomberg terminal in New York but by the time that Trader looks at it a state transition propagating through Solana already adjusted for Price impact and the price information at naisy is exactly the same as in a market running in Solana because all that data is propagating at the same time so this is a system that I Envision you know back in the day and this is kind of still what we're building we're trying to reduce block times from 400 milliseconds to 200 milliseconds we're trying to make sure that there's multiple concur block producers so you can send your transaction to the most geographically closest one there's competition for math all of the stuff gets better and better and faster and in that world what's cool is that like I think Solana obviously needs to have a lot of Hardware to do that because you're sending a lot of data you're trying to keep it all together and Roll-Ups are not going to help you you know like you're not going to improve that system by splitting up State logically um it that those effectively create logical shards and you're not sending information globally to everyone you're sending information only to some of the folks which kind of breaks the whole point so but that system that we're building actually helps Roll-Ups like in my ideal world all of these settlement chains that have roll ups should be all atomically sequenced in the swan giant super optimized hyper fast synchronizing engine right that's one giant Global Atomic State machine but obviously we still need trustless computation we still need to make sure that users that can't afford the hardware have some guarantees that about like honest execution of these systems and like I think the research and like clients that have been done by the folks you know like the teams on the stage has been awesome and I think in the future like Solana for Solano to function has to have those capabilities as well but the fundamental problem that I want to solve is that Global State synchronization as close to the speed of light as possible as open as possible to everyone in the world yeah okay so let's suppose that we uh we end in a world where there's only really one settlement layer and you your chain of choice becomes an L2 of the other chain I only asked this question because anatoly's been writing a lot of tweets about putting uh you know making Solana uh making Ethan Alto Solana how how how does that I mean first of all antillo maybe you want to explain your tweets because I I I'm I personally was very confused when I read them but I I was trying to uh create a I guess a straw man to demonstrate that what an L2 is is there's a mechanical component to it which is a a trust a bridge with better than honest majority assumptions that functions because all the data that you need to prove that the smirkle root that's on your L1 is correct is also on the L1 so you can then run the fraud proofs you can basically or whatever a computer a ZK proof whatever whatever it is that you need to do you have all the information to validate this Merkel route which the root itself does not have anything else right it's just a just a hash um so that's kind of like you can do that with anything you can actually take ethereum L1 data right now dump it into Solana dump the state route that's computed from that ethereum data and then run an optimism style proof right to to check if fraud has occurred and then do the bisection and stuff like that does that make ethereum a Solano too mechanically yes socially no one reason why is because like you know there's a saying that like you know the Sovereign is the one that decides the exception and in blockchains the exception is bugs and 51 attacks and the question is always like look what happens if ethereum hard forks for example right like if ethereum hard Fork so there is a few possibilities right like one possibility is that the Solana bridge and if we assume that it's a you know perfect ZK bridge then according to the old ck rules the ethereum chain will just start being invalid and like that bridge will just basically create its own version of you know like basically its own ethereum classic 2.0 right um so that's like one but then the question is like well I'm going to do the assets like like what do the assets follow right and realistically in this case the assets would follow ethereum right um but you know if you get into a world where like the majority of assets are rooted on the Solana and then bridged onto ethereum then like that would that would look very different right or in other world in which right and in that case then like ethereum would not actually be capable of hard forking unless there is like some kind of Unchained governance right or a possible third world would be a world where the assets are all based on Solana but at the same time the Solana Community is willing to hard Fork whenever ethereum is willing to hard Fork right and in that case that's like a construction based off of I guess some kind of some sort of like more deeper version of on-chain governance and in that case like you could you know you would still be able to call ethereum and and L2 but it would be part of this ecosystem where sort of like things are basically yeah I mean like willing to be part uh be part of the governance of each other so I think it like yeah you basically just have to look at you know like what happens if one chain or the other chain gets 51 attacked and what happens it like what happens if one chain or they're taking 51 attacked and the community decides to do a yeah like a user activated soft Fork to kill the attackers right so not like an easy slashing hard Fork but like a censorship hard fork or the community responds by picking the minority chain and on the minority chain the uh you know the majority would have to either skip being on that chain or get slashed and if they skip being on that chance and they get leaked yeah and then like what happens in that case right so the thing is though that there's always going to be subset of users that are hardcore Cipher Funk censorship resistant maximalists that will always pick this the right hard Forks they will always Fork Solana and ethereum to towards the right state so the real L1 is inside of all of us you know this gets into like yet another theater of the debate we've been having since 2015 you know which chain is the real ethereum who's here thinks ethereum classic is the real ethereum Bitcoin cash is the real Bitcoin yeah I think this kind of like gets into the Beats of like how you define L2 or and so on and so forth versus it was a side chain but like that but there's definitions aside I still think it's an interesting composition or useful to um like have a validating the bridge between salon and ethereum would be validating like because most bridges between trust zones are not validating they just have a committee based assumption but like if if this is your ethereum at least verified um proof I think you could and then even if the d8 wasn't on ethereum and the da was in Selana and there's a community assumption I think that would I would at least be um as far as I can tell the same security properties as a validium or an optimistic chain which is like a kind of like a much better scenario for like a multi-chain ecosystem so one thing that did come up in in all of these answers to to whether it's possible for one settlement layer to usurp another one and make it an L2 is uh the role of governance in these Futures in the the modular or monolithic Futures and so you know I think we've we've seen a lot of different variants of what qualifies as governance you know I think choosing a hard Fork following certain people is a sort of weak form of governance we just heard John's talk about POG which you know I don't even I I haven't fully processed because it was spoken at high speed uh to be honest um but uh I I think like where do you view the role of governance in your preferred modality in towards the end game like how much you know how minimized is it how important is it where does it where is it necessary where is it only sufficient where is it non-necessary yeah I mean I feel I really feel like this upgrade thing Roll Up upgradability is the kind of like quote like the the core Nuance that has been a lot debate about like um you know like um you know it coming from from optimism is arguing that all roll ups are sovereign and there's kind of a very controversial statement and the reason why he argued that is because yagu is that well all Roll-Ups can just the community follow-up can just uh upgrade the role up ultimately what a roll-up is is what the community defines that roll up to be and not the bridge but I think there's some interesting Nuance questions about like um how do we have upgradable Roll-Ups while keeping the security properties of a roll up like the only kind of like way I know about that I I know of doing so is to have an upgrade delay and allow users to mass exit which is not clear if it's not clear how practical that would be in an actual um practical scenario yeah this is a tough choice right because I think like right now roll your two Roll-Ups are I guess there's like two camps there's sort of the more activist side and if you're on the more activist side then like I think the safe and responsible way is to like choose a delay number and like it could be somewhere between 30 and 365 days probably and uh if an upgrade happens and if you're not happy with the upgrade or if you know governance gets taken over by evil people in the upgrade involves stealing your money then like you just have to leave which is good enough for most users but it's not good enough for like really long-term applications that want to base themselves on that roll up right and then on the other side like like I know like scroll for example you know it really values the idea of like neutrality and like sticking to ethereum principles and kind of seat mirror like seeing itself as being a kind of an extender of uh ethereum land and uh like something like that would be what might be willing to like say like hey you know we're in an ad code level we're not going to be willing to to like deviate from anything but being a you know a copy of the protocol spec and like if they do that then that doesn't like it takes away that risk for applications but then it also opens up this interesting question of like if ethereum itself upgrades then like how would scroll end up copying that and then this gets into like protocol questions like I know this is one of those things that's why controversial within the ethereum research team even like there's some people that are in favor of uh in shrines Roll-Ups or like or Indian shrines like free like roll-up assisting pre-compile like basically imagine a pre-compile that just does evm validation and it just does whatever evm validation means during the specific block and like maybe you could let it like do either the current hard fork or the previous hard fork and then like in the back end clients would just Implement that by like waiting for whatever their preferred zke VM proof is for example right and like if you do something like that then like you can preserve that kind of like that tight coupling for the projects that want to do that and then if you don't do something like that then like layer twos would basically need to have governance for the like Unchained governance for the sole purpose of keeping at the very least for the sole purpose of keeping up with uh whatever layer one does right so that's uh like that's one of those trade-offs like and then obviously the uh you know the the other side of this is like this kind of underexplored class of like crazier ideas where like someone creates a uh layer one where that layer one is like intentionally willing to be more um you know like activist and uh or or and like basically yeah hard fork in such um in such a way that like even way or two like like assisting Layer Two is with uh you know like um hard-working along with those kinds of changes so yeah and I know there's like a big set of possibilities in off-chain governance there's a yeah obviously a big set of possibilities what's on chain governance as we see it and especially once you start like properly moving away from the coin voting stuff and uh and then there's like a a whole set of debates about use cases of governance like are you protecting against tax and that's it are you improving the protocol are you doing public goods funding right um and then if you do public goods funding then like do you do it um what kind of by enshrining an Unchained mechanism or do you do this kind of like retroactive off-chain thing the way that zcash does right it's like every four years they basically as far as I could tell so far they like decide you know who the public goods funders who the top level public goods finders are and then they get and then they do a hard Fork to give them the block reward and then that gets Revisited every four years which is like kind of cool in its own way right and Z cash has made the choice to be a more interventionist than ethereum and Bitcoin are but yeah I don't know it's a big design space but do you think do you think there's a way for to allow Roll-Ups to have upgrade mechanism but the same security properties as roll up but without coin voting and without enshrining that roll up into the L1 because that's one of the reasons why some people are interested in solving Roll-Ups right yeah right right I guess the challenge with Sovereign robs is like if you start using any assets that where those assets are not registered within that roll-up right then it's like well for those assets that you can't be Sovereign right unless the uh unless you have like hyper like more activist off-game governance yeah for sure but I think like even though L1 is really softened like you have you know usdc and usdt which is kind of like a you know a non-sovereign bridge between ethereum and circle or tether so it's definitely you know sovereignty is a spectrum yeah there's definitely a trade officer between solving Roll-Ups I'm not sovereign right that is true I mean you definitely could get every application to have um you know separate instances on all of the different uh Roll-Ups and so you don't like even cross roll up or kind of bridged assets don't exist anymore and then everyone can be Sovereign but uh well if you do that though like you would not be able to like eth would not be usable on Roll-Ups right because ethias uh like by definition home.otherium it needs I mean like the the major problem are zero days all these systems are too complex to not have some really fast path to upgrade and deal with this your day bug that's kind of like the end of the day like you have to I don't know how long it's going to take for us to construct something that is so simple that everyone agrees this this can be upgraded with a 30-day delay we're okay with with that um and if you have a fast path for zero days you're kind of introducing honest majority assumptions and I think that's mostly fine if that if that's what we're dealing with I think we then have to be very very careful about how we construct those majorities should they be like well-known security firms etc etc like kind of the the proof of governance talk I think went into a lot of those considerations but but like I think it's really really tough to to avoid those I think like a couple nuances on that like one is you technically don't need like you don't technically need a fast pass to upgrade you need a fast path to freeze and and arbitrarily solo path to finalize whether or not you're going to upgrade and then the other thing is uh like I definitely do not think that upgrade buttons should merely be a majority right if it's merely a majority then like whatever proof system you're doing technically has no votes right and you know you might uh it's uh like I think you need to have at least a 75 threshold so that says uh I mean the thing that I've been pushing for the stage one definition obviously um but like I do think that being greater than 50 greater than 50 is uh important because otherwise like it's mathematically true that the code itself has no votes um and then well the other thing is I guess one of the ways that the ethereum ecosystem is doing this as they are doing this kind of like inversion thing right like where like I know some of the Roll-Ups want to do this right they want to have multiple zke VM implementations and then the security Council only gets activated if at least uh what like one of them disagrees with the other or something like that which is I think an interesting path too as long as the implementations are being built independently enough yeah I I I think like at some level it seems like everyone thinks that there is some necessity of governance at the bare lease and bare minimum but it may be sort of to summarize like in some ways synchronizing multiple chains in the case of the modular world or in anatoly's view of the world kind of response measurement now maybe let's take a tiny tiny detour uh imagine you had to can come up with a compliment for the architecture that's the opposite of the one that you like like you had to find some something really fair like you know you were just your your your your your life depended on coming up with a really good compliment for the other architecture what would you what would you say to your to your fellow developer I mean speaking of Solana specifically I mean the way I see it is that uh totally Angela is trying to build the way I see it is um scalability ultimately has a has trade-offs between um scalability and composibility and um so like even you know at the ethereum Centric roadmap you have liquidity effect but some liquidity fragmentation let's say like optimism and orbitrim but the way I see it is like Solana is trying to trying to see as much how much throughput we can get as much as possible without any compressibility sacrifices whatsoever um you know that's why Anatoly doesn't see Roll-Ups as a scaling mechanism because it defeats the properties of the system he's trying to create which is like basically as if I understand the vision is like you know decentralized version of the New York Stock Exchange but so I do appreciate well I appreciate Barcelona is that you know they've made some great advancements in kind of execution environments you know the parallelized execution environment you know that's a massive um Improvement um and I do I appreciate that um like Solana is actually taking trust minimization a bit more seriously over the past year you know there's been some work and proposals over trying to create like clients and Implement fault proofs for Solana and you know even some proposals to to see how we can add data availability something to the Lana yeah I mean I appreciate that you know there's a strong Tactical Team and I appreciate the willingness to just like say here's uh some set of use cases that kind of we understand we're passionate about and you know we're going to like basically optimize and like we'll be willing to make the be willing to make trade-offs that do the best that we can for them and totally um well I think the data availability sampling and the whole fraud proof construction is like beautiful design it's awesome so and that actually is like I think came out of the research of both both of the the teams here so pretty cool and like uh the really cool thing is that like everything's open source as soon as those folks had really good ideas I was able to understand them and start thinking about how apply them to the Solana stock if we if we fast forward you know to kind of applications that you find interesting uh either within ecosystems that you're working in or uh sort of maybe even in the other ecosystems what are some applications you're you're interested in in 2023 and 2024 that will be used you know I think a lot of ECC this year at least from my perspective has been quite a bit of infrastructure seeing a lot of updates on you know how certain proving systems are working you know understanding how those developments have have moved on but we do at some point I have to have to find some other applications in them you know obviously you all probably have tons of examples of these that you're most interested in what are they yeah I mean I think um like in the short term there's kind of like being some really crazy progress in like gaming kind of Roll-Ups you know like hear your managed to kind of like run a real-time strategy game with a 0.5 second take engine using a modified evm that adds that part of the game as opcode and there's okay all of stuff like you know August and other teams are working on interesting game engines now I don't think you know gaming is the kind of like ultimate you know purpose or like the most you know real world case of crypto but I think historically what we've seen you know even in Computing a lot of advancements in Computing has compound gaming you know for example the concept of sharding actually originated from gaming so yeah I'm just kind of interested in following those developments there and I think in the long term they will have you know significant impacts on applications outside of outside of gaming as well um I kind of like want the OG application to come back like I want people to like pay for coffees with like if you know yeah like remember back in 2013 when like this was the whole the big thing and like I would I remember this was actually the very start of like my Bitcoin trip around the world um where we would uh have uh like I went to Boston and I went on a pilgrimage to a veggie Galaxy and Thelonious monkfish because those were the two restaurants that accepted Bitcoin and then you know we had the Bitcoin Keats over in Berlin and like York plot sort of got like 10 restaurants and a block to accept it like I want that culture to come back and I think a big part of the reason it died is obvious which is like these got too high but like you know the original pitch back then is like hey this is cheaper than PayPal but then it stops being cheaper than PayPal but with roll up so like it actually will be again which is amazing right and like I would love to see some of um you know those amazing OG things that we did back then come back now that you know the world does or the ecosystem is starting to be ready for them yeah I think I think that will definitely happen like we're seeing Banks already using usdc for settlement I think that will eventually be exposed to the end user um like it's being used kind of on the back end but it will eventually be exposed to the end user and then press none of these applications so far have had any Advanced cryptography so uh Anatolia the payments privacy preserving but okay Anatolian yeah I would say like simple things like payments and defy I guess defy can be very complicated but I think both of those really serve the two fundamental things that crypto provides and that self-custody and this idea of a global source of truth right for pricing or the ability to transact I think those are very transformative at scale if you have everyone in the world that now has cryptographic keys that they know can move value around everything else can be built on top of that you know like real world governance right like if you if everybody knows that like we can all communicate and coordinate with cryptography we can actually build very quick fast Global political movements that can take on action and solve real world problems I think but the foundation is that like cryptographic base of users that get self-custody get what they're doing they know like what this thing means so yeah the simple things I'm on vitalik's Camp here well I mean you know we are in France and uh Defy is the French word for challenge okay fine it's pronounced but like come on I don't like more generally also interested in experimentation around bells and kind of like form ways of organizing people on chain there's like this there's um a lot of different kind of proposals defy refi disco Dallas um a lot of interest I'm kind of like excited to see how that goes as well my last question which is a false trichotomy but you have to pick an answer anyway which is Barbie Oppenheimer or you think it's really bad that we're lionizing Oppenheimer via a movie I choose Bob the Builder sorry I forgot Bob the Builder I forgot Bob the Builder I want to see like the the crypto space come up with it's own like epic you know like you know like we've had songs right like uh you know remember there were Bitcoin songs Back Then There was um like that that uh um love you like like a Bitcoin parody that like continues to be one of my favorite songs to this day like it's actually good as a song despite being a parody there's uh I think I didn't like Simon De La review I write a novel at some point that like yeah like I'm like I would love to see just like us come up with a uh a movie that is like you know uses themes from these you know that we care about but it's like actually good as a movie at the same time I unfortunately saw that there was an online TV show about SBF so maybe that's not the right type of movie but uh it is it is that is coming out it's an animated short I see it it's an Oppenheimer for a different cause yeah exactly yeah the price is definitely you know Anatoly I mean you look like you're ready to be in the Barbie movie so like you gotta have some opinions here this is me cosplaying famine so definitely Oppenheimer all right well thanks everyone for joining us it's been a great day of talks we talked a lot about the public broadcasting system of the US I mean sorry proposer Builder separation and uh hope you have had a good week in Paris and uh enjoy [Applause] thanks everyone for staying for the entire morning plus an entire day that started at 2PM um just a few closing remarks they're supposed to be slides and if they don't appear I'll still say the same things so um basically the reason why we had um but not this PBS day journey is to seek out an answer that I wanted to know me as a community member take off my flashbots hat um what can I do to contribute to the PBS research that is critical to um fight against essentially the centralizing force of Meb and so this is something that I wanted to have as a call to action which is to build as a community a open r d map for the ecosystem on the topic on the problem space of PBS and so of course I stole a few slides from every speaker today this is one version of the end game thanks to vitalik and the whether you do believe in again game of approved Singularity or not the question really is where are we now and of course understanding that there are a lot of ecosystems different uh like participants and contributors sitting here so this may be just one of the many examples or one of the many road maps that you're familiar with the one on the right was I believe at the end of last year uh vitalik posted the um ethereum road map that is quite modular and so where was PBS back then it was right there with a couple components it looks like we're 25 there and today we got a zoomed in version of a heart-shaped roadmap from Mark neuter and there is still a lot of uncertainties to be figured out in terms of actually how do we actually um get rid of certain intermediaries that is currently not quite accounted for in the protocol as well as many other technical challenges so I started to ask myself okay as a non-ef non-core researcher non-core developer what can I do to actually understand how big what is a lay of the land and what can we do individually or as part of our project so I went on a rabbit hole of Mind mapping so of course we're um we have already on ethereum Boost ecosystem that's in operations that flashbacks many of my teammates are working on along with many of the EF and the community members contributing to it and it's up and running there's also a healthy ecosystem that's beyond just the map boost ecosystem that is doing a lot more of the r d work so after I actually interviewed around 10 to 20 researchers who are actually working in a space working on PBS I realized that I really can't recognize much on this mind map anymore because it has expanded so huge and I realize there's a lot more problems then I realized there was and ultimately these questions are very hard auction design problems very hard consensus design problems and there may not be a right answer and when I look through from the farther away research research problems zooming into the development and finally the operational problems I realized that the reason why I have a lot less branches there is because there's a lot more to be done by the community but yet we kind of just relied on hey the EF is going to take care of it not my problem but that shouldn't be the case there is so much we can do just in terms of figuring out in today's up and running out of protocol PBS um map boost ecosystem how do we keep relays um economically sustainable that's a research question how do we actually have data transparency such that we could um enable us to keep the ecosystem in check and how do we actually contribute to the prototyping the economic audits the security audits of all of the early research work that is going to production before they turn into an EIP those are just open-ended questions unaccounted for so it's a cause reaction and this doesn't just um applies to R1 today we heard I think for the for many uh of you here probably for the first time um for me probably but a second time because I interviewed every single speaker um what what PBS on L2 look like and this may be just a starting point so I'll end right here with essentially the theme of today that's term Zero Sum gaming deposit the sum let's keep crypto decentralized thank you [Applause] I'd also like to ask if we can all give Tina one more round of applause for actually curating the whole day as well thank you everybody happy hour begins see Back To Top