Jakub Čech - Tackling Fragmented UI/UX in the Web3 Sector: The Power of Unification

Transcript

[Applause] awesome thank you thank you so much uh thanks for joining I usually like do a bit of a survey in the beginning uh the data set is going to be a little bit smaller now than usual but thanks for joining regardless uh how many of you guys are aare or have heard about ail all right that's uh that's an answer perfect thank you and how how many of you are aware of like the data availability problem as a whole in the space cool awesome thank you so much yeah uh this talk uh will be about a product that we've been building uh for the past three and a half years we started uh as part of polygon uh as a team inside of

polygon uh I think it's three and a half years uh but yeah I don't remember things very well so that's where we are uh we then uh changed the structure or you know uh exited polygon in a way uh now we're a separate entity uh building separately because uh that's what made the most sense and I'll go through the challenges uh of the current space I'll go through like you know the problem statement itself high level View and then I'll go through some uh technical bits of the products that we built uh I'll mainly focus on the most immediate product that we're launching uh this half uh 2024 on Main net but it's been

running on test net for quite a while now cool so the problem statement right now there's been a lot of rollups popping up uh uh in the space in the past year more than a year but you know it's been something that's been ramping up quite a bit so uh they've been used as a way to scale uh blockchains and uh one of the things that they need is data availability uh so they need somewhere to post or publish data and then uh there needs to be some kind of a verification that the data has indeed been published uh one of the issues that I'll go into uh with this approach is that uh if you have a lot of rollups uh

you end up uh with a lot of fragmentation in the space because uh by default there's no composability between the rollups so you end up with the same problem as if you had a you know hundreds thousands of chains and then if you're someone who needs to build an application that for example communicates with a bunch of rollups uh you end up with a bit of an issue uh if there's no composability uh you end up having to you know look for a solution that pretty much ends up being something like a couple Bridges linking all the rollups uh so there's some sense of unification that is required uh usually nowadays if you look around most of the rollups are ethereum based uh or have taken sort of like the

most attention at least uh that is rollups in a way are the main way of having uh offchain computation uh and you know the growth of rollups uh you know created a lot of demand for ethereum uh for data availability or on ethereum for data availability but if you look at the road map of ethereum uh like full DK charting is still uh long time of uh by looks of it and that's why uh we started building a solution uh that'll be talking about today uh it's called aalda it's powered by uh zero knowledge proofs and kg kzg polom commitments for

validity validity proofs and uh the end goal is to improve the user experience across the whole Space uh so right now if you look at the space uh there's hundreds of general purpose uh and specific rollups uh that are popping up it's probably thousands uh or even more uh perhaps uh and like I said this is leading to some sense of fragmentation across the space and we in general across web3 we haven't been very good at like building something that uh allows for the creation of a good user experience uh if you look at the past uh you know uh 10 years of this space so we always have to you know we create

something we create a solution for something and uh only after that we start thinking about the actual like you know uh what does the ux look like uh how how is this things uh easy to use or not easy to use and so on and so forth so uh in a way to address this uh fragmentations or fragmentation rollups should be able to interoperate in a trust minimized way ideally and that's where uh our product that I'll be talking about very briefly uh comes in a Nexus uh which uh will be unifying the rollups across web 3 uh with uh proof aggregation and data availability sampling I'll go into that in a bit uh but at the same time if you create a

solution for something that usually needs a solution for that as well in a way so uh creating that kind of coordination uh of value across blockchains also requires some shared Economic Security in the unification layer or for the unification layer and that's uh where the third product that I'll be talking about comes in and that's a fusion security uh so it's we have three things uh that we're building LDA Nexus and LL Fusion I will spend the most time on LDA so LD uh a DA uh like I mentioned something we've been building for three and a half years now uh it's a validity proof based uh data availability layer

layer so it's something that uh allows you to utilize uh data availability block space and post uh data uh via light client and utilize something that we call uh data availability sampling if you're a roll up and we've built it in a way that allows for easy verifiability using kcg polinomial commitments uh so that's uh kind of how we've built it to make it uh as easy as possible for anyone to not have to run a note but instead run a very lightweight light client that allows you to actually

verify that the data has uh been published uh I'll go into that in a second uh LDA uh is a modular Bas layer uh that provides uh unopinionated uh block space two modular chains what it does is sequences packages and publishes data it uh also segregates the transaction data based on something that we call app IDs so you post data for your application for your rollup and then you also uh retrieve data for your application and your rollup you don't have to care about the other data that's uh being posted or that's being

stored uh yeah uh it's a uh L LDA in a way uh is built on a uh substrate SDK or right now you can also call it pa. szk I guess uh it has it has a robust validator set that will sign up of on the published blocks and like I said it's completely obvious oblivious to the transaction data contained in the blocks and yeah and then each uh rollup that uses uh Avail data availability then can Define the way that it actually uh does the computation so it can be an evm uh bite code it can be something

very specific doesn't have to be a VM at all as well all right I'll go very briefly through the no network uh it's probably more detail uh than needed uh so like I mentioned we've built it on substrat uh and this gave us the flexibility uh to develop this further do things like you know have uh block size that we can work with in the future uh have a very proven solution uh for example used by a lot of chains like padot kusama and so on and so forth so built on that SDK uh uh so that we don't have to like reinvent the wheel uh because right now

that's uh not something that's uh really worth doing uh we use babe and Grandpa for Block offering and finality uh these have also been things uh that have been like ble proven in the space quite a bit uh we have pretty fast finality uh fast test across the da Solutions and uh you know like I mentioned substrate being pretty resilient even if uh you know there's a large Network partition and so on and so forth so we really just wanted to make sure that the base layer is as robust as possible so that we can focus on the actual uh Solutions on top all right some of the substrate changes that we've made uh we made a 20

second block time instead of a sixc block time uh which is standard substrate SDK we did that to uh give enough time for the light client network uh uh to be able to actually process uh what's in the block and uh put it into a distributed hash table they'll go into in a bit as well uh I mentioned uh there's an concept of application ID uh which segregates the data based on the poster and the application as a whole uh and then that's kind of what it looks like you post data you have a signature uh for the app ID and that's how you like recognize that it's your data and what you're going to patch uh afterwards when you need it we also extended the

substrate header uh so we have uh modifi the system and executive pellets uh and we added an extension to the blocks so it contains all the information that is required to support the data availability that we're using uh substrate for there's a header and an extension to it all right I'll go through the whole flow uh so applications uh send some uh data blobs to ail using a an arbitrary uh application ID let's say it's an application one in here application two application three uh or application one actually but it's a post number three and then uh what we actually do is order

the data chunk it and then pad it if there's uh still some room left uh what we then do uh we take that data uh we generate commitments for the data uh and then we do eraser coding on those commitments or with those commitments and we create something that we call Extended commitments that we then uh pass into the extended header uh for each block and we create like a metrix that is uh dynamic in size uh and then uh yeah that allows us to make sure that we you know uh save on computation uh uh we

don't extend the header unnecessarily and so on and so forth and all it contains basically is a data route Matrix size application index and the commitments uh yeah then we post that data or propagate the data to the network the block is then propagated to the network and yeah we also made some changes to the import export or the import mechanism uh and the uh comparison of the imported header with the uh generated header so that they're actually the same uh and we've extended substrate with some uh rpcs that are created just for this application to uh

allow for the uh data availability uh scenarios and uh other light client scenarios uh to be supported so you can uh do sampling uh they integrate other custom features that we need for light client and they can be queried by like clients or by anyone else and they're cached so uh I'll go through data availability sampling and how that works in a little bit and now I'll focus more on the light client network uh which uh technically if you look at LDA it's like two networks on top one is the base layer network with the substrate noes and there's the light c network that is separate all right so how do it actually

work it's something that you built using rust uh with uh things like rust L peer-to-peer uh it's an overlay peer-to-peer Network on the Bas layer like I mentioned uh it's uh the main uh sort of way to uh you know query the network and verify data availability and things like that for finalized blocks uh and uh it performs also data availability sampling for each block uh they do not need to download the block content uh that is due to the way that we create the commitments and then do eraser coding uh you only need to sample parts of the block uh and they maintain a uh cademia based uh distributed

hashtable uh so that creates another Network so they're eventually they're not dependent as much on the nodes they're just dependent on one another to be able to uh verify that data has been published all right and you only need a couple samples or several samples to give you uh guarantees close to 100% of that something's been published all right uh I'll go through the actual uh data availability sampling process uh here uh briefly so you have validators you have a network that publishes uh uh two blocks uh let's say light client one uh queries uh uh the Val Network or the node Network for uh

the data and the extended uh header uh with the commitments uh it gets what it wants and then it populates uh a block replica uh on the DHD on the distributed hash table so uh let's say it has some coverage of like 25% or something like that uh then another light client uh does the same for different kind of data for example has a different application ID or something like that and it populates the DHT with more data and then another light client comes in uh it's like yeah I'm not going to query the node Network for this I'm just going to see if it's already on the DHD and it finds out it's not so it falls back to

actually querying the nodes and it gets all that it needs uh for the scenario that it's trying to accomplish and it populates the rest of the DHD and now in the DHD we actually have uh all the blocks on the network covered uh so all the upcoming light clients they don't really need to query uh the nodes let's say in a simplistic way they just go directly through the DHD all right and yeah just very briefly uh we spend most of the time actually optimizing the peer-to-peer network uh because uh the way uh Li peer to-peer right now works uh it's very dependent on the scenarios that you're

doing um uh and there's other Concepts like fat clients that actually uh sample more parts of the block but uh it's not uh that uh relevant as there's only going to be a couple of them usually uh but they have a more of a coverage and they can like uh provide uh more data to others and so on and so forth uh and when we simplify Li blocks if you get a header but a node has invalid data uh the Samplers won't match the commitments uh because we yeah we uh we actually sample just the finalized blocks so then it gets like frown away all right uh what's next I'll just very brief briefly go through the last

two bits of a Nexus and a fusion uh and these kind of extend the base solution that I just talked about uh that provides the base data availability sampling and like I mentioned in the beginning if you have a lot of rollups uh and you want to work with a couple rollups for your application or something like that uh or let's say you want to have some composability between all of the rollups you end up with a solution uh that would resemble for example something like thousands of bridges uh you know if you wanted to connect all the rollups in some meaningful way and then work with uh whatever they produce uh which is not really sustainable if you look at the

way web3 works right now uh bridges are usually the weakest link uh in the solutions so you kind of want to avoid having uh Bridge bridges for everything uh that's when something that can uh act as a middleware comes in uh and we're developing something that we call uh Nexus that acts as a unification layer and yeah uh it acts as like a verification Hub uh that unifies the UPS uh using aalda uh as the root of the trust the base layer and that way we want to enable like unified experiences so that you can add you can then

actually use uh what comes of comes out of the Nexus and uh use that to achieve uh composability between all the rollups that are using that solution so you don't need to understand or know anything about the state transition function uh of the other rollups uh you only verify that the transition functions were completed uh correctly and DL Nexus uh does a proof composition uh and you only have to verify single proof and that allows you to uh verify the validity of all executions uh on all the rollups that have happened before so

it pretty much takes uh it pretty much takes uh proofs from the different rollups uh that are either posted um directly to the Nexus layer or to the data availability layer and then it creates One Singular proof for all of them in a way uh yeah and another thing that it does uh is a transaction uh sequencing uh inclusion uh so it's a uh or at least a coordination via a d centralized uh sequencer selection mechanism uh will be also done by uh avail Nexus all right and then uh a fusion uh like I mentioned uh you create a solution for something that needs

another solution uh so once you have something like a unified layer like this you also need something like a unified security for all of that uh so you need to make sure that if you have a unified layer uh like this you also need to make sure that it's uh extremely secure uh to make sure all the cryptoeconomic guarantees are there and so on and so forth uh and with a fusion uh this is actually something we're targeting 2025 for uh or with uh you can actually add cryptoeconomic security to the base layer uh by actually adding or staking uh other different assets like you know BTC ethereum different tokens for uh

coming from different rollups and so on and so forth and all of that together combined RS like a increased joint security uh structure so uh and it like contributes to the consensus alongside you know uh alongside all the other uh tokens that are represented on the shared layer cool that is pretty much it uh not sure if there are any questions or anything like that but uh thanks for being here [Applause]