Scaling Real-World Assets, Not Blockspace | Justin Kilpatrick - Althea and Gravity Bridge

[Music] hey everyone I'm Justin and uh do you have the display there we go okay really right up here okay cool okay good afternoon everybody I'm Justin co-founder of Alia and today I have a talk that's about Alia L1 but really the design decisions behind it so for that we're going to need to start with some context um so Alia is a uh Alia is a dpen project decentralized physical infrastructure although we really predate that definition by several years um and I'm not really here to talk about althia the application so much as the L1 that we have built to support it and and this is because I think it's a really interesting alternative inter um alternative interpretation of the scaling problems that uh sort of dominate blockchain design discussions and what I found really interesting as we went over and went through this process of designing an L1 for ala is that what we the choices that we made and the options that we selected were completely different from the normal uh more focused uh blockchain design discussions and decisions so this led me to want to sort of present all of these differences and really talk about uh what does dpin need in a scaling platform as a sort of contrarian or I guess not really contrarian but an alternative to the uh sort of l2s l3s ZK discussions around uh defi scaling now I should get out of the way some context so Alia is a protocol that allows devices to buy and sell bandwidth from each other so for the you know super short elevator pitch on that um just imagine that your cell phone could buy bandwidth from any cell tower not just one of the three main providers but anyone anyone with any cell tower anyone set up um as a metaphorical equivalent of just kind of handing them a quarter as you walk by uh in order to buy some data um and so yeah this is a microtransactions application it's really about creating a market for bandwidth and uh we have been working on this for uh six or seven years now depending on how you count and we are we are selling uh well we are an ISP to thousands of homes in 15 states and several countries um and we have real customers buying bandwidth using this system from a uh for example a fire station uh to just regular people who regular people who are not familiar with crypto at all using this as an application um so now we're starting to think of well not starting now we're implementing uh what does it take to do this at scale to have a bandwidth market like this running for everyone in America or everyone in the world and how do we make sure that uh you know it scales and everything works out so without further Ado let's get started started and sort of jump right into the technical decisions um so first of all uh how much block space do you really need anyways and I think this is this is one of the things that is um this is one of the discussions that's sort of dominated by more block space better uh arguments and that may be reasonably true in the case of Defi and sort of financial applications uh more block space creates induced demand so the lower your gas cost the more transactions you're going to get to Arbitrage all the pools and to Arbitrage between different protocols and it just goes on forever really um but that's not true when you are buying and selling what is um I like to think of bandwidth as a physical good because it's transmitted through the air it's really not so different than a candy bar once you have downloaded some data uh the sender cannot take it back and uh they still want to get paid for it and uh the interesting thing about microtransactions applications uh in this sort of context is that you think well okay you want to send transactions as often as possible right that's not really the case in fact the frequency with which you want to send transactions is bounded by the latency of the system that is accepting the transactions so finality speed um and that's that's an unintuitive answer until you start thinking about trying to write the code that actually does this stuff and start trying to think about writing it in a way that is uh reliable enough that your phone is not constantly ringing um and to do that uh you really need to worry about what transactions are in Flight what is final what is not final what could be reverted what could be changed uh what if somebody unplugs the device what if somebody reboots the device what if somebody reboots the receiving device what if the receiving device has corrupt memory because it doesn't have ECC all of these things are things you really need to worry about um so being sure that you have sent your payment that it has been finalized on the blockchain and that the receiving node uh understands that it has been paid uh are really your constraining factors um um so what this means is that you don't want to settle every you know one second five seconds you really want to settle every couple of cents maybe 1 cent 5 Cent anything more than that and uh your tracking logic starts to go wonky because even so let's say you have a centralized shared sequencer that gives you an inclusion proof this is the fastest you can possibly know that your transaction has been accepted how fast is it how fast is it really in the worst case and and uh the answer to that is probably about 1 to two seconds so that's not actually that much better than the finality time you can get uh with so we ended up selecting tender consensus uh on a cosmos base and finality time sit around you know somewhere between four and 8 seconds so a a single centralized sequencer acts as a single point of failure in the sense that well point of failure point of liveness failure I should say there's safety failures as well but you're not getting a big benefit from it you can have a decentralized validator set and ultimately your biggest constraint about how many transactions you want to send doesn't change um this is a really interesting and unintuitive conclusion and it's kind of the sort of thing that this whole talk is about is what we've learned building Alia and running a dpin application and how that influences what you actually want to build um yeah so anyways the ultimate conclusion for this is that you don't really need uh an enormous amount of block space in terms of block space everybody's going to be settling uh let's say everybody was streaming uh 4K video continuously they were all paying some absurd price for B you know just to generate more transactions um you still you're talking about maybe tens of thousands um you know tens of thousands per minute uh to a couple thousand per second to settle all the bandwidth in the United States and that's if everybody's watching 4K Super Bowl same time etc etc um so you don't need to start to get into really crazy scaling Solutions or uh ZK proofs or lots of multiple shards you can reasonably do this with a simple validator set and well optimized code um even more interesting than that and on the same subject is that uh scaling for defi is actually a much harder problem which you may have already guessed listening to just the first couple of minutes of this presentation um when you're doing transactions for real world value you can parallelize them really easily you're not talking about reducing the composability of a programming environment like the evm that is fundamentally about well so the value of the evm evm is fundamentally about composability that composability fundamentally requires that you seriously serially execute each transaction and means that you're means that you can't really take advantage of parallel processing on an individual validator very easily whereas if you're processing a bunch of uh whereas if you're processing a bunch of just straight up hardcoded a sends money to B transactions these can all settle at the end of the block and be processed in parallel and then you wrap up the block and do the signing and one thread at the end so this means that for althia L1 we've gone with a hybrid platform where we have both a base layer that allows us to send just bandwidth transactions as a special type that we can process vastly more efficiently and then evm and then an integrated evm that is useful for defi applications that want to be close to the to the actual bandwidth sales uh but at a really high price because we're not really optimizing uh well really high price is relative but um we're not really optimizing for enormous evm throughput we're optimizing for enormous bandwidth transaction throughput um and once again I think that this is interesting from the perspective of how much what you we're trying to do constrains your scaling concerns um and this brings us to the last point that while while figuring out a form of parallelism and increasing the speed of serialized execution is the hardest problem for evm chains the hardest problem for a chain that hopes to be a settlement layer for Real World Exchange whether that be candy bars um bandwidth um um you know pretty much anything physical that has to change hands uh you need two things more than anything else uh you need some form of instant finality to get more uh to actually get the transaction throughput there and to simplify your applications and you also need a way to handle the uh the RPC problem which is actually really really hard because when you are dealing with uh defi it's relatively reasonable to have a very high full node or I I should put it this way RPC node to user ratio because users are not transacting all the time and do not need to be observing the blockchain state constantly they you know there is there's no there are Arbitrage Bots and such but they can pay for their own infrastructure you don't have a router that needs to know when it's been paid a point of salale terminal that needs to be always on and watching for payments you don't have um essenti an enormous query load that is the real bottleneck when dealing with uh realtime payments because they have to remain real time so obviously no matter how many queries you run uh the validators are going to keep producing blocks at about the same rate you're not going to knock them down um but if the users cannot query and know that their transactions are finalized we're back to the first point we don't have uh fast enough finality so uh this is why think the like client Space is really underappreciated and uh that that the current I think the current Concepts behind client diversity in ethereum and in other blockchains are insufficiently Advanced uh why do we have only one type of client that's a full client and an archive note and it does only those two things um because we really need more effective like clients that start to eliminate these RPC problems start to run in a web browser and give us query capability that is really efficient uh and useful now unfortunately ethereum has designed itself into a corner here with its own uh um with its non-final sorry I'll put it this way uh the delayed finality in eth2 consensus fundamentally makes it extremely difficult to make a lightweight light client like this because the proofs that are needed to do that don't really exist in a practical way this is useful for ethereum because it provides additional resiliency uh in that it's not final uh but because there is no finality you have a data availability problem uh and the data availability problem cannot be solved with a rapid with a quick proof so that is a bundle of words in there but long story short for our application for dpin applications uh we need to be able to bootstrap a light client that can effectively query other nodes for blocks in a you know couple hundred megabytes of ram at most so the uh okay sorry I'm not going to go on a detour about uh home Wi-Fi router hardware and how much RAM they have but that's a that's an entirely different lecture uh and is something that has been a really fun problem interesting to work with but anyways uh a uh compared to a home Wi-Fi router a Chrome tab is practically roomy in terms of resources um so yeah particularly we chose Tinder as our base Tinder provides uh sacrifices um liveness for instant finality which we needed before and we also need now to make effective light clients and these effective light clients are critically important to maintain the query load when you have let's say uh 300 million households two three devices each all of them are looking at the chain pretty much continuously um you know that's that's not practical to do any other way you need an efficient like client or everybody's going to be having the same terrible experience that blockchain natives have when you're trying to use a chain and the rpcs are heavily overloaded or not responding or when you have to pay out the nose to infura to get yourself something stable and sort of avoid that problem now this brings us to the last one and that is that data availability um I think this problem is sort of interesting uh mainly because the way that it's being approached right now is as as a financialization problem and I don't really think it's a financialization problem at all uh and in order to in that's because I'm coming at it from a hardware first perspective and as somebody who spends a lot of time dealing with physical Hardware that's kind of where my mind is uh but in terms of storage the storage is dirt cheap you can buy enough storage for a eth full node considered to be like a really heavy blockchain for uh $64 and uh you know the immediate response from anybody who has has ever tried to run an ethereum full node will tell me that that storage isn't fast enough and uh that's a problem with the program not a problem with the fundamental requirements of what you need to do so you know the amount of data you need to store is the same uh the fact that you need really fast storage is an artifact of once again the expectation that there's only one type of uh chain client a combined archive full node um and I think that needs to change with more intelligent like clients and ethereum is like I said it has some problems with that you um you're not going to fit an e two like client in a browser but you can definitely fit an e two like client in a lot smaller footprint than you have right now if you came at it from that sort of low low processing envelope perspective but right now the focus on client diversity is just having diverse clients that all do the same thing and not a Ultra lightweight client that is prepared to store only part of the blockchain at a time uh so anyway way for our purposes um for Alia L1 purposes uh if we're talking about many millions of uh home Wi-Fi routers point of sale terminals uh people's phones interacting as sort of mediumweight light clients where you have a few hundred megabytes of RAM and maybe a gig or two of storage data availability becomes a logistics problem you just have to have each node store a random distributed sampling of all the blocks and respond to queries for them and if you have a sufficient number of nodes then data availability ceases to be a problem the issue of course is having a sufficient number of nodes which ties back to why we need lighter clients so that running nodes is far cheaper and there are far more of them um it would also help if they didn't require such enormous amounts of Maintenance but that's part of the design requirements of building a lighter weight client okay so hopefully I have not just all confused you all silly and there are some intelligent questions to be had well either way there is uh we have some merch over at table A5 um and uh yeah that includes free t-shirts although I don't think for long um and uh yeah I'll be happy to answer questions and talk about this after since it looks like I'm going to run out of time in a minute anyways thank you everybody