Hashing It Out
Hashing It Out

Episode 84 · 2 years ago

Hashing It Out #84- Ava Labs Kevin Sekniqi and Stephen Buttolph

ABOUT THIS EPISODE

Kevin and Stephen of Ava Labs return to the show to give updates on the progress happening with Ava Labs. Join our Slack and continue the discussion about Ava Labs. 

Links For AVA Labs:

The Bitcoin Podcast Network

Now entering cast work. Welcome to hashing it out, a podcast where we talked to the tech innovators behind blocked in infrastructure and decentralized networks. We dive into the weeds to get at why and how people build this technology the problems they face along the way. Come listen and learn from the best in the business so you can join their ranks. Welcome back, everybody, to Hash it out. As always, I'm your host, Dr Corey Petty, and my cohost today is Dean Eigenman. Say, what's up, everybody, Dean, what's up, everybody, Dean. Dean ruined it. You've ruined it. We have to make a new thing now. Anyway. Yes, today, you've heard them before. You'll probably here again. We're talking with Alba labs and from them we have Stephen Bo Golf. Hey, say your last name, but half. Yeah, so, Stephen Battle. Yeah, it's like Rudolf, but with a butt in front of it. Yeah, Nice, you said that before. Oh Yeah, Oh, yeah, yeah, and Kevin Sech Niki. We start off by along you guys, introduce yourselves. Kevin, you start and we'll go a step and after that. Hey, yeah, so, yeah, I've been on this show before. It seems like I just can go away, but you also can't. You, you guys keep bringing me here, so it's your fault. To your audience listeners that are tired of me already, blame Corey, not me, inside man for so long. Again, blame cory the yeah, so very brief introduction on Kevin Technique. A background in on tech, initial in cryptography. Can't. was into crypto currencies way, way, way, pat back ago. Got In it basically a few months after the client came out, but was never really in the crypto twitter circles for a very long time. Got Involved in cryptography research, then went to my PhD to the Distributor Systems Research and then went on to work on the on the business side of things, with with Alva, and do mostly business side things nowadays. But obviously I have a technical background, so I get involved as much as I can on the technical things nowadays, but it's not much stephene by you. Yeah, so I'm steping bought off. So I got into crypto around in high school. I implemented like a little like margin trading, like trading bought on my polony x and like high school, and so that's great. How I got in like right around the time like eth was first to launch, and then then I went to Cornell University and took a couple of goons classes and kind of got more interested in both what he was doing and also kind of the space on a more technical side rather than financial, and so then I started doing research with Goon and then he put me on to implementing a go version of the avalanche protocol, which is turned into the the GECKO client for Ava, and so so that's basically where I've where I've been working for the past like two years and August, I guess. So, yeah, I'm how I feel like goons previous cops ie curriculum was a recruitment machine for Ava. I wrong there. I don't know. Like he did a lot of like he did a lot of system stuff which is like very related, but not specifically like blockchain related. But he did teach specifically a cryptocurrency blockchain like intro course, which I feel like he was definitely looking into a feel out the crowd and see both like the interest level in it and also like if there's like any people to do research. But you know you're wrong. I'm not. You're saying that's a negative thing. That's a perfect pool of people to be choosing from and trying to get people to work on t shop. If, if, if all all labs, is any any indication? I think we have quite a few ex cornel people. So you know we've definitely used goons. COON's outreach there. Yeah, for sure. Where you part of? I see three? Steven actually wasn't part of IC three. So I'd like sense like starting research with Goon. I've done like more ice three things, but actually was not part of IC three before working with the gone. Yeah, so I think it it's reasonable, before we start diving into any tacticles or changes or what's going on right now with Alva labs, to give a brief kind of chartical landscape of what lava is and how it differentiates itself...

...from the other open permission with block chains. Stephen, do you want to take that? Yeah, so I'll start and I'm sure that you'll have a bunch of play yeah, of course. So, so I'm a first differentiates yourself with its consensus protocol, which I know we talked about a lot before, at least previous episodes of this, but I'll give a very brief overview of essentially it's highly scaleable, both in throughput and also the latency and the number of participants that can participate in consensus. So the first kind of main idea that that started Alva was the consensus protocol. Now, since then we've also branched out into this idea of subnets or like heterogeneous or a heterogeneous network. So that allows us to kind of scale, not just like on like consensus speed sides, but also it allows people to kind of develop their own personalized network. So, for example, we we are able to port the EBM so easily because we can essentially just have a rapper around and existing evm implementation and then use avalanche consensus with that. And so we can poor things into Gecko in a relatively easy manner because of how we structured our subnets. And so that lets people not just, you know, have a very fast infrastructure but also a very flexible one, so someone could implement their own virtual machine that has kind of arbitrary business logic that's specific to them and so so yeah, so those are those are likes the to technical side and then I think Kevin can talk a lot more about like the business side and how we're kind of like pitching to to be unique in that aspect. But I think from the architecture side where we're kind of pushing towards, like you know, very a very flexible infrastructure, both on the consensus and on the engine side. For Kevin Cos, I want to I want to try and reiterate something that's I think is incredibly important about what I was doing, and that is it's a market distinction between consensus and the underlying data or macher like machine state or right most open networks. Right now, those two things are intrinsically married, like the consensus for livest state and the change of state, whereas consider like AVA and it's differentiation is consistence as his own thing, and then you can have other like a bunch of different machines rely on that. Consider engine. Yeah, exactly. Yeah, that's basically exactly right. It's programmability, not just of the application layer, which is what other smart contract platforms do allot to do already. It's also programmability at layers below that, at the network stack effect will, in the data stacks, which is which an important property. So it allows do some interesting things that are very difficult from for for others. I mean one of the most important things that we want to make sure is that we build a smart contract platform that capitalizes on the value of the applications built on top. This is something that a theory, for example, doesn't do. You know, I can if I issue a, let me let me call it a a low velocity, high longevity type of asset, something like, you know, real estate or land, tide or something like that that, on the theium, looks no different than, forgive my nominclacier here, but any regular shitcoin. It accumulates the same fees. It does not, it is not guaranteed to be different from any other. A coin that does maybe has no value whatsoever to it. And we're trying to capitalize on this problem in a way that provides, or that gives the issuers of assets and creators for smart contracts on our platform the ability to effectively divide the the guarantees a little bit more at a higher granularity or lower granularity. Rather, it's about, you know, giving somebody that is issuing these applications that or these masses that have, you know, very high longevity needs and high security needs. It gives them an ability to pay much, much larger fees to be stored for a very long period of time and be very secure, versus something that maybe is just, you know, not very high value and needs a maybe much higher speed and much lower fees. So this is something that we allow that a theorem doesn't quite allow. And and this actually goes down to the to the alvatoken design as well. So in a theorium, the problem is it does not, you know, if I issue a new token or if I build a really successful application on the theorium, if fees out are paid in Eith, which is great, but down to the miners and nobody else benefits from the fact that there is usage off of...

...these of this of this token on the system. It's actually, it's actually quite a big problem for a theorium. I mean you have so much value being built on a theium that bitcoin could never, could ever dream of right now and none of it is really being capitalized at the value that it should be capitalized by the by the underlying theorem token. You know, our design has been more of the the design that we've taken is more of the one that says, look, this is a cap supply token like bitcoin and whenever you do operations that require things like creating a new blockchains and paying for transaction fees and so on, they burn ava tokens and the burning of babba tokens ultimately creates scarcity in Ava, and so that capitalizes on the underlying on the underlying token of the of the system. So that's an in that's a different design from how a Theorem has done this, but I mean that's more of I would say peripheral property. The the first goal that we want to achieve is really in the ability to effectively low procamability at the at the network and data layer, which is very, very important because it allows a lot of flexibility on how you can design your economics for your smart contract. It's like effectively, you know, smart contract level charting, almost, if you want to think of it that way. Maybe that's not quite supercorrect, but it's the best knowledge that I can possibly come up with in one sentence. And and that's just not the case for any other platform that we've seen out there. Okay, so, Stephen, you mentioned these subnets that AVA has. Right. How do those compare? Are Would you compare those? Are those akin to pair chains or something like shards in east us. So with the stateless model that you mentioned, how does that compare to something like eath to, which also has the goal of being more stateless? Yeah, so, so I think the biggest difference between, you know, our model and something more similar to their model is that for us, our our subnets are heterogeneous, which means that they aren't necessarily running the same the same vm or the same same, I guess, Schema. If you're coming from Databas land, so eve to at least you know. Correct me if I'm wrong. But if to is planning on achieving scalability on the same kind of network with the same security guarantees in the same never guarantees across all of it shards. So what that means is that essentially they're trying to parallelize computation and increase their throughput by having nodes not need to validate the entire the entire state, and so that's that's very useful in some cases. However, it's typically pretty difficult when there's a lot of like cross shard communication, which on a block chain, it then becomes very important of how you're you're splitting things into shards, and so from from our point of view, you know you're going to have something like, you know, the die chain or the die, I guess Shard, where, you know, everyone wants to be on the Die Shard because there and wants to use die and so all of a sudden anyone that isn't on the Die Chard is going to have to be communicating with the Die Shard, which is relatively expensive in most chartage systems. However, with us, our viewpoint with subnets is that subnets are are heterogeneous and so they contain their own environment. So, for example, the EVM would live in its own subnet and would kind of or so for us, like atheriums is a subnet that we're playing on doing, which is a spoon of Etherorem state. So so that's so that's like the big difference really. So we have subnets based off of the functionality rather than, you know, just splitting the entire state. So that's like the main difference. Now to answer like your stateless kind of point. So stateless is kind of a different beast entirely. So it's very important when you're when you're building a blockchain system, that you have to understand that this thing's going to be alive for hopefully and extremely long period of time. So it's an ever growing database, you can think of that way. So you need to be able to kind of prune out things that are no longer vile or like needed. So bitcoin does this by using utxos, and so you only really need to care about the uts the current ut EXO set. As long as you can bootstrap in the current UTIXO set, then you're able to kind of process transactions and they progress. Now there are like client side security guarantees that, you know, may require you to bootstrap the entire chain, but we've seen that many people don't actually require that level of...

...security. Now it's, you know, still totally possible and everything we're doing, but I think for the happy path most people don't care. But there's other things that something like etherium does, which is account based rather than Utso based, and so that actually isn't proveable. So what that means is that whenever someone uses an account, that state actually can never get removed. Otherwise you would have a replay attack potential. So so there's like those kinds of decisions that go into m's to make it so that you can have an easy bootstrap in and an easy sink. But that's kind of almost orthogonal to two subnets in like the overall idea. So I guess subnets are probably more comparable to power chains in the polk adult model than to chards in the etherium model. From your summary, I don't know. I don't know a ton about POLKA DOT, so I'll be straight up of that. Yeah, I think it's so quick because some yeah, I think the quickest summary of power chains and Polka dot is that essentially it's just a heter generous blockchain that's connected over. It is layer above which is the POLKA DOT network. Not Quite so. First of all, the the POLKA DON network has a share security. We don't. Okay, that's first. Second of all, the the way to think of the subnet abstraction is that all the subnet is is a collection of validators. That's all of this is just a collection of validators. It's a set. So subnet can actually have multiple chains internally and each chain can have multiple different version machines. Really, what this abstraction provides you is is who gets to for the first layer abstraction, very very high layer, is a who gets to manage your data and then within that abstraction, you get to say how is my data managed? So the WHO gets to manage my data is the subnet component that defines this out of validators. And then once you answer that question, it can be permission or it can be fully permission, as you can say that this subnet is anybody can validate it, there is no requirements whatsoever for it, or you can say that only special types of entities can validate it. And then once you answer that question, you have to answer the question off. Okay, I am within this particular subnet. What is the mode or how are we managing the data? So we answer the WHO manage the data? Know, we have to answer how are we manage the data, and the how is answered via the any arbitrary collection of chains that can exist within the subnet which implement any arbitrary virtual machine. That's subtraction here. It's really there is effectively zero we like there is. There's nothing that's force down anybody's throat here. It's just you have full control over everything. You get to manage whatever, everything and in however way you want. So if I want to launch a new subnet that represents real estate holdings assets, then that's tribal to do, and that's not quite the same as, for example, just having a pair of chain, which is just a single Blockshin, I believe, just a single linear chain, and that's pair of chain. It happens to implement maybe different execution environment. So maybe evm versus something else, or maybe was some I'm not sure how many execution environments they they support, but that's the extent of the customizability of pair of chains. There's there's no more to it. So what binds these subnets together? Like what makes it a subnet different from just another avalanche network that someone created randomly? Are Are not able to communicate with each other? Or is it? Yes, yes, just fancy word for a new network. No, no, okay, I gotta go. Yeah, so they are able to communicate with each other, they're able to interoperate and that interoperation is not sort of works out of the box, regardless of the of the RSTUAL machine. There needs to be some wrappings done, but it should be pretty straightforward and the communication is the part here that that matters. So these subnets can communicate with each other, and I mean typically speaking, because a lot of them would share the same sort of set of addators, they probably would. The communication will be pretty trivial. But the thing here is that, you know, we're not trying to solve for share security model because we we think the share security model is is just not something that people just not something that makes sense. So so to us it's more of like gift freedom and responsibility of the of the subnet creators themselves to figure out who manages the this thing. And if they want the security of like a fully permissionless chain that's out there in public, then they can just launch on the on the default of a subnet. That one would be permission less and they can deploy on that one. But if they require more customizability and they can create their own correct...

...so you have to want to quick to get some type of make sure I'm right here. There are default subnets on Ava as it currently stands, and these are mandatory to be a part of. If you'd like to have a different step. That is that true? I think it used to be that way. It's still that way. And Yeah, subnets. Yeah, yeah, so it's just one default subnet is the main Alba default subnet is the permission lest one. So if you want to be part of the interoperability network, you you're going to have to be part of the of the main Alva subnet. But otherwise there is no other sort of enforcements being done here, so that this enforcement is really to just make sure that the fault of a sub thatt maintains a high degree of security guarantee in the permission. What do you do on the AUFICUS subnet? Like, what's the what's the purpose of it and how does it how does it give you that ability to have on your opportulity? The AVA subnet is the permissionless one. It's it's the one that it's about supposed to be the default one does most of the operations of that you would think of Bitcoin or etherium and so on. The the that default subnet also provides some atomic swop operations that are needed for for different other nondefault subnet so any other subnets that come in the future if they require, if they want to operate, if they want the interoperability, that interoperability comes by basically posting some transactions on the default of a subnet. It's effectively as a checkpointing mechanism, quick one. So that's where the default of a sudden it comes in. It's just a coordination ledger. Effectively. Yeah, just to jump in really quickly here. So in order for atomic swops to be reasonable, both of the subnets that are trying to perform the swap need to know like who the validators are at the other network, and so the platform chain that is running on the default subnet access kind of like a shared space for those subnets to interact. So so that's kind of how they how we enable automics oops across these two different subnets. Yeah, so the Java chain here is kind of akin to like the beacon chain and e's to it's it's a message passing system. Is that a correct statement? Out Say? They're very similar. But similar? Yes, but they don't have the the same functionality beacon chain has. It shuffles things around, it provides some randomness. This is not the case. So it's a reduced functionality be can chain. That would be a good way describer. And so if I want to do message passing, I just have to actually connect to the Abba subnet so that the ABA submet can delegate messages to these different subnets. Correct. Yes, okay, so it's yeah, so it's like the postal service essentially, effectively, and the Abas, the main Alva subnet, also has the the metadata chain, which is effectively a list of all the active subnets. It's just the registry of all its active right now. Who's all dating what? And Yeah, if you want to connect another subnet, you want to know who's the latest out of our dators, you basically just check with the mean Ava subnet. That's where the the reference point is. How is this metadata stored? Is it in the blocks or is it a in a smart contract? I think it's in the blocks, Stephen, and probably answer more on that. Yeahs basically in the Blox, like we it's a very thin vm like. It doesn't have like. It's not like a a very flexible vm like like etherium, with like solidity. It's it basically just allows for a couple different transaction formats, ones like, you know, add myself as a steak er, you know, add myself to the subnet, create a new subject, create a new block chain, as basically all the plotform chain does. So so that's that you're tracking on. That is basically just the current state of subnets and WHO's tracking them. Correct. Yeah, if you say state so many times there but it just comes out are there. Is there a limit to how many subnets that can exist, like with poke whin, there's a limit of pair chains, and then people like basically are vying for their ability to use the shared security model of the poem now at work. Is that it is a nice here? No, no, no, you can create as many as you I mean you can create any arbitray number of subnets and chains and so on, as long as you can pay for it. Pay For it. Yeah, like submit a transition. That's that. Has the fees require to make it happen, because creating a new submit is an expensive operation. And that's it. Because if it's is there. Yes,...

...how's the cost model work for that? Is a fixed price or does it get exponentially more expensive? Yeah, that mean that that can get very complicated. So we currently have a very dumb model of just fixed price. Eventually we're going to make it very, very sophisticated. So one thing at a time. There's only so many battles we can we can fight at the same time. Yeah, and yeah, come on, run it. Will probably want to have some sort of rent based model because maintaining that state is just going to keep growing. So we want to be able to remove it. So we'll probably want to go to send like rent based model for that. But right now it's just a straight fee. Pretty dumb. I mean not just retaining state, but you have the problem of like every subnet added will add pressure onto the ava submit, right, because every time across our transaction is done, that would have to happen through the AVA chain. So the more of these subnets you have, the more potential for pres transactions to this chain. What it would would grow. Sure, I mean like the atomic transactions will likely have fees as well, so that's not as big of a concern, but it's more just like the fact that the summit exists and is being tracked by the chain. So our would transactions into subnet be paid in a specific subnet token or USSO in a transactions inside of a subnet can have no fees. They can do basically whatever they want as long as the validators or that subnet are happy with it. Okay, yeah, it's so. Then, if anything, if a transaction then goes from subnet to another subnet and requires to have a fee paid on the of a chain to have that cross our transaction relayed. How would that work? And fees. So the actual atomic transaction requires fees. So something posted to the platform chain would require a feed. But if they had the same valid even if they have the same valuator Setsay, for instance, like a me and five buddies sides. We want to make two chains to I don't know why that I said that, but like just two different two different subjets that basically have, you know, maybe set for functionality. We have one for kind of smart contracts and the work for storage, and they are they're very much intertwined, but optimized for those two feet, two features. In that case, every time they talk to each other they have to go through the office subnet in order to do so, despite having babe like, the exact same minor set. So so this is actually very interesting. So currently the platform chain and the ex dange chain, or the pchain in the exchange is what we call it. They live in the same subnet. So we can actually perform operations in a slightly different way. So there are optimizations that you can use if you're two chains inside the same subnet. So, as Kevin mentioned, has the same set of validators. It's all subnet really is. So so there are like different operations that you can use that would potentially not involve of it at all. Now I will I will preface this, or I guess I will. Like just mentioned that, like not all this is currently implemented. So the the atomic swop side between subnets, that's currently not in the client, but Intra subnet has been implemented between the P and x chain. So we're working on it. But yeah, this is a yeah, it's the model. So technologically speaking, there's no reason to believe that that's not going to be the case. It's just hasn't been done yet based on available resources and priorities. Yeah, I mean we're working on it, like we've been. We've been pushing, like you know, sixteen hours and day, seven days a week for for a while. So we're pushing, we're working on it. But yeah, I just want to make sure that there was no confusion there. Where are we now? Like, what's what's the what's happened since we last talk and what do you currently like for advertising? So currently we're working on network stability stuff. So we we've been switching up our networking stack quite a bit previously. We had a so apologies because I'm going to talk mainly about the go client just because that's that's my area of focus. But we've been focusing on switching out the networking stack. We had a C plus plus networking stack for performance reasons, but the go garbage collector kind of interfered with that and was giving us a bunch of problems, so we ended up switching to a puergo networking stack. So that was a big change that we've done...

...recently. In addition, we're focusing on kind of bootstrapping improvements and just overall stability. So that's kind of our main focus right now. Yeah, is your new networking stack lip P to per or you guys writing something Rien? So for now it's just a very thin like. It's a dead simple basically just go native networking. It's like not complicated at all. It's basically just, you know, best efforts send a message to this peer if you're connected to it. I know that we've talked internally about looking at lip PDP just because I think that's kind of the Goto. But we were we were basically looking at getting something up and running as quickly as possible. So we just want to very thin networking stack for now. Yeah, what the requirement? What do you what do you need clients to do in terms of the nutworking layer that maybe is there any is there anything different in terms of what requirements you have? There? Would would like thinking comparing it to other block chain ecosystems and how they typically talk to each other. It appeared for network. So for the most part we just want to be able to connect to each other as well as possible and send messages because we're a a sync safe protocol. The messages don't really they don't need to be like guaranteed to be received or any thing like that. Of course, is impossible to do, but you know, some people tried it anyways. But but we basically just needed a dead simple communication tool. I know that some people have gone down the route of like using like UDP exclusively and attempts to like decrease message latencies. We haven't really seen any need for that. I think that's, for the most part, micro optimization. Unless you are extremely network bound, which are consensus protocol basically evenly distributes networking load, which is it's very similar to prove of work in that so for the most part network is not like a it's not a very band with heavy usage protocol compared to something like a classical consens protocol. So yeah, but it seems like because of the way avalanche works, there's usually multiple rounds. Are Multiple Times that have to query my peers for specific for their state. Right, yeah, that's correct. So would that not calls it to be band with heavy or would you only call that latency heavy? So so in in consensus you typically think about like what's the number of messages or what's number of bits? Awesome, how to amptotically that you would you have to send to peers. So for a single consensus decision in an avalanche, that's log in in the number of nodes in network. However, as more decisions like get added at the same time, we can pipeline that to be a constant time operation, whereas something like something like, you know, hot stuff or a tenderment, that requires a linear complexity. So at least on one of the nodes, Um. So. So for the most part the the bandwidth is is evenly distributed and is relatively relatively low. It was not that, I think the way I've always pictured this eternally in my head, and correct me if I'm wrong here, is that the way the network scales in terms of load is with the number of decision any given valid or has to make, because every single decision they have to make is based on a multiple rounds of random sampling of their network knowledge. So they they say, Hey, this group of people, what do you think about this? Now the round, a different group of people, what do you think about the same thing, et Cetera, until they come until they come to conclusion with a strong confidence interval. And that scales really, really well with the size of the network because the number of people that they're queering and their knowledge of the network is constant over time. It can differentiate because there's more people that they can sample from, but it's the same. It's based on what they want to do. Or, as most traditional like Byzantine considers, celgorrhythms scale with complexity because you need to have an answer from everyone. And so as the number of participates grows, that could the number of messages that pass across the network grows exponentially, and that's not the case with album. Yeah, know, that's that's a very good point. I often...

...times like to think about it is if anyone's taken like a interest statistates class, they always talk about you know sampling, a sampling a population to kind of get like like some expected value at some interval bounds, and so that's very much the same thing that avalanche does. So you don't need to sample the entire population to have be very confident in what the the population believes in a whole. So yeah, how much of the population do you need to sample? Roughly, like what how much of the population to have a validate or sample? So Kevin can talk a little bit about this because he knows a lot on the map side, for like exact bounds. But what was the question? The exact about how many nodes you need to sample? Yeah, I like how many? What percentage of the network to have a note sample? It's actually not based on percentage. So the if you can do something analysis on the hypogremetric distribution. Basically what it says is something kind of interesting, which is that the error bounce on a particular sample are really owned dependent on well, not really, but let me just say really, as far as you know, for all intents and purposes, you know, statistically significant really it's really only dependent on the sample size itself, not on it as a percentage of the network size or anything else. Is just a raw number. So it would really matters here is what the sample size is in raw terms. Is it five, hundred and ten, twenty, forty, whatever it may be? It's entirely independent. Again, that's not totally the true but really, like, believe me when I say it's mostly entirely independent of the network size. So the network can be a million or or ten billion or ten trillion, doesn't matter. You can ignore that for all intents and purposes and just focus on the the sample size itself. Well, that's five or ten or twenty, and for for for reasonable parameters and network, a sample size of about twenty is more than sufficient. If you go to forty, that's really, really sufficient and that's success. It's each each iteration that you're you're sampling changes, and so you're not sampling the same people every single time, right, correct? Yes, yes, and each iteration creates more and more. So like there's actually a tradeoff mathematically between latency and the sample size initially. So let me maybe make this clear for everybody listening. So let's sup pose off, I started by sampling everybody in the network, which is what typically most proof sticks systems work as. So that what is what I'll call a deterministic sample. I sample everybody and my error probability on what the true state of the network is is exactly zero because I have sampled everybody, I have full information. So in order for me to get probability zero of error, all I require, if I'm sampling everybody, is a single round. So the latency there is just one around. The way that it works with with avalanche is that you trade off those that latency of one round for are much smaller sample size. But the really nice thing, that's kind of like a he'll Mary from math, is that the sample size, while it can decrease drastically, the latency does not actually increase that much, which is a really Great Hall Mary. So you know, there is mathematically no difference between sampling let's say a hundred nodes versus sampling twozero notes. The guarantee there is really really close to each other, which means that I can just now save twenty rounds. So instead of you know, doing you know, rather one round off off, sorry, one round of two tho nodes. I can do one round of a hundred nodes, I get basically the same mathematical equivalent. If I've dropped down to let's say forty or twenty nodes, I get a little bit of error, but I can easily, you know, subsume that error and just completely squash it with just a few additional rounds. So the number of rounds grows very slowly. As far as the number of as far as the drop in in the sample sizes and how slowly drops is. Actually it's a complicated formula, but it's really, really small. It's like even it's like close log rhythm, even less than logarithmic. So it's really really slow growth. So which is which is a really nice properly so I fixed, you know, constant size sample of let's say twenty nodes per per iteration done over let's say ten consecutive trials would be sufficient for most intense and purposes to provide people with really high security guarantees, and this would be independent of the network size. This is where kind of AVA wins. So given these small numbers, now you can toss at it and no work of a thousand or of tenzero knows it doesn't really care. So so,...

...given that AVA or an abode, queries all these other other notes and it changes the set of nodes for every round that it queries. When I joined the network, how does that look? Do I, as a note, just try to gather as many nodes as possible in the beginning that I can change this set? Or, yeah, every round, try to find twenty new peers. What happens there? Yeah, so this is actually where we diverge pretty heavily from from other proof stake systems. So you know bitcoin. So there's the bootstrapping problem, which is different in proof of work systems from proof stake systems. Proof of work systems, they the bootstrapping pro problem can be solved as long as you connect to one correct node, a note that truly has the view of the network. And as far as that correct note, you know, comes back and says, Hey, here's the view of the network. The longest chain you can you can verify yourself and you should be good. But once you join the network, validational transactions still requires that the majority of the nodes you're connected to, or rather the hash power is, is correct. So boots trapping is nice in improve of work, but it ultimately doesn't really save you much. It's not like you're still getting consensus by only trusting a single other node. So it's kind of a it's kind of a party trick, it's kind of a moot point. It kind of falls flat on his feet, on its feet, whereas improve steake, other systems have, other projects have tried to desperately emulate this whole you know, one out of end. As long as I trust one single node, then maybe I can I can connect to the correct approve state network. And it's caused a rabbit hole off just insane proportions that we seem to not be able to get out of and people have lost their minds on all slashing and things like that, and it's gotten down a really crazy rabbit hole. there. Our bootstrapping mechanism is is pretty straightforward. Is We don't care about solving bootstrapping by just trusting a single node, because eventually you're going to have to trust some a jority number of nodes. So we assume that when you're trying to boots trapping the network, you're connecting to a majority, correct number of nodes and as long as that's the case, that assumption holds, which in reality it almost certainly will, then there's a very simple bootstrapping mechanism. All you effectively do is just download the state, get the the minimum intersection between these nodes that that have communities, to at least that half the the identities, and then you suddenly have the the list of peers that you can connect to and participate in the network, and then from that list of piers, this is what constitutes the latest active steaker set and that's where you sample from after you join. So that's that's really our boost, trapping and eventual operation of the network. Yeah, it was a really good answer, but I think dean was probably asking on a more like specific technical level, like does the node connect to all of the nodes at the same time or does it attempt to kind of discover nodes as as needed? Was that? was that what you were asking? Yeah, yeah, so, so the node just eagerly connects to is many noes as it can right now, as long as the network doesn't become so large that that actually causes issues. That's that's a totally reasonable path, and so that's that's kind of where we've taken now a node can connect easily to like ten thousand nodes, like thousands of nodes, with no issue. If we ever get to a point where we have like millions of validators, that that's probably going to have to get revisited because it'll probably no longer be sustainable. But as long as the network is like in a reasonable size right now, there should be no to with like running out of connection pile descriptors or anything like that. So that's that's what we currently use. So as this was as this conversation is going on, I've always had this mental model about of a works in terms of consensus, and it has occurred to me that it's the consensus version of the Central Limit Theorem. Are is everyone familiar with what that is? Yeah, that's exactly correct, and so, like, for those that don't know what that means, it's basically like, if you have an incredibly large population and you want us, you want to figure out what the mean is, you can do it and you can do it a few ways. which you can do is you can do the way in which Kevin just mentioned. You can sample every single person. But if you have it, you have a probability or a confidence of a one hundred percent exactly what that is, but that may be difficult depending...

...upon the size of the number of people we have the sample, and that's what we're seeing as kind of consistus AG rhythms. Try and grow with the number validators, or you can do it by sampling small amounts of people multiple times, and the central limit theorem states that as with as you iterate the number of times you sample those people, you converge to the to the actual mean of the entire distribution, very, very, very quickly and with a strong confidence. That's what you're doing. That's that's the general idea of what you're doing. Damn, you really, you really fucking killed me here. Oh sorry, I am suff a lot the curse. All your want, we don't care. Okay, okay, Jesus, really, yeah, you, you made this very God. We need to use you as our as our technicals folks person. Yeah, that was that was a perfect description. Basically. Okay, good, all that happen. There's so much confusion about what's going on, and that's that's not a difficult concept. Now it's really right off, and what's Nice about that is you have you can prematorize the system in terms of how many people. You need to sample with respect to like what latency traitar you have or like what how fast you get a confidence in all exactly. And here's the Nice thing. When you do trade the size for additional latency, you can still do cool you can still you do useful work in between each one of these rounds, and that's where the amortization with avalanche comes in. So it's not like, for example, exactly as you said, though, the the drop in the increasing in rounds is not like proportional to the decrease in the number of notes. Like if I go from, you know, one thousand nodes down to five hundred. It's not now like my my number of rounds goes from one to two. It actually kind of stays, still, still stays at one, almost at one. But even if I get to an additional number of rounds, I can still do useful work between each round, meaning that I can I can do a sample for one particular transaction and then the next round I can sort of pipeline the next transaction that references that previous one and say, okay, Corey pays dean, that's one transaction. Then Kevin Pays Stephen. That's not a transaction instead of doing multiple rounds for both of these in parallel. Instead I do Corey pays dean first and then I do Steven Pays Kevin, which points to the Corey Pay Steven Transaction Dean transaction, and now I can effectively create a linear chain of these guys, which looks like repeated sampling. So effectively everything, every single transaction, is only sampled once. So it's not even sampled multiple times in a row, it's just simple ones. So you end up reducing the amount of nose that you sampled per query down to just some constant number, very small constant number, and you effectively get a single round per transaction almost for free. So this is where where a lot of the magic happens. But you totally nailed it. It's actually once you kind of get this trade off, it's super simple. It's like and you're this straight off. Is exactly the reason why the basic primitive of snowflake effectively is a generalized method of describing basically every single quorum based system. It just happens to be one where you basically trade off determines to guarantees with probability guarantees in exactly the same way as if, instead of sampling everybody in the in the set and getting their mean, in which case I have a probability zero of error. I know exactly what they mean is, I can instead sort of trade off some of that guarantee with a little bit of error but still be pretty damn close to the mean and I still get a whole bunch of other benefits. So that's where a lot of the magic happens. But it's pretty simple that. The math is complicated, but it's the concept is very, very simple to explain. Yeah, I valanche. At least the consensus protocol family is really simple, which is one of the reasons why I like it, because it feels like something which anyone who's probably thought about probabilistic consensus or consensus in a tiny distributed system has probably thought of something like this. It's like a very simple method of just gossip in your state and taking a sample size. Yeah, exactly, and I mean this is the this is what the Qureum based systems already to do. Right, just happened to be with the entire system set. Yeah, so, yeah, it's Snow Flick is a generalized version of all consensus. In fact, if you do, if you make snowflake with their camp sample sizes, the network size, then you get one of the first well known consensus protocols, the the Ben or continsis protocol, a synchronous consiser protocol, from one thousand nine hundred and eighty three, before even pack thos very first. Which one? Which one's the first? Oh No, I think been or was was the first. Guy. I say, you almost get it. The only the only thing that it snow doesn't have is the random coin. They Oh, yeah, but yeah, yeah,...

...it doesn't care about that. So that I'm talking of just about the quorum, the coreum property. So, yeah, it looks very similar to to be no or. Actually it's a nineteen eighty three paper. It was the very first paper that solved consensus in an asynchronous system and it is from in one thousand nine hundred and eighty three, also a Cronellian guy. Actually. All right, what's next? All right, we're having size said to wrap this down. Like where you guys going? What are you? What are you looking forward to? How do people get involved, etc. Yeah, so we want people to to start looking and what we have as far as like what the properties it achieves, I think. I think it's a great time for for new systems to that. I that I've made a lot of noise. Hopefully like us to actually stick up to that noise and and deliver. I think we will. So the summer is going to be fun. We're going to be launching in something by test net the next week. We're going to be going towards Maine. That the summer and and it's really going to be the fund. That's when the fund really starts to think and we get to a in production, test this thing out, make sure that it gets some Lyndy lind the effects under its belt. It's it's robust and we're building lots of applications on top that really especially benefit from low latency, so and and low transaction fees. So it's it's you know, I get a lot of hater from the theorem crowd because it's like I'm going after a Theorem, but that's because it has issues like we're trying to solve those issues, like what you only to say. So it's it is where it is. So I'm excited myself at least, and I don't share this view with everybody else at Alba because I was. Is a pretty different set of people actually, and we all share different views, but I personally share the view of look, we have technology that can solve a lot of these issues and I want to see applications that that are writting fast and efficient and distributed way on on us. So and they're fully black was compatible with the theium in the EBM and so on. So that's going to be cool. I think that note cool. The technology works potentially, it has potential to change a lot of the problems or solve a lot of the problems that we faced in the currently implemented systems. Or value exists. How do you get people to move? Because it doesn't matter if people don't use it and put their value in it. How do you get that? Yeah, no, that's that's a great question. I mean, so to me there is there's a certain set of properties that are required to kind of make the secret sauce kind of work and really marinate a little bit. And first property is you need to make you need to propose the new system that really has incredibly low switching costs. If you don't have that already, let's Ley, let's forget about the other stuff. To begin with. So you need something that has compatibility to the theory. In virtual machine tooling works. The switching costs are super low. Validating the system has even even that part has super low costs. You just run on your machine. There is no slashing, none of that across the board. There is not a single piece of what we've built that. Frankly, I'm very proud of this that anybody can say, wow, this is so much work to get this going. It's going to be compiled olding go very soon. Is it actually already? Is it just basically go run a bunch of scripts? You're already running a note. Boom, there's no slashing on about the other sides of very low risk the you know, running applications on it. It's backward compabile the theory and so on. Okay, so that's the first that's the first ingredient of the secret sauce. And then the second thing is great, you provide it backwards compatibility system. You need to have a reason why people would want to switch. Ultimately, and and that reason is well number one, we have a very fast engine that we can actually back up our claims with, and and it's it gives rise to applications, or rather use cases. I would say that that currently can't really quite exist. On on on the Theorem, algre, for example, is is having masssive issues. They can't run certain kinds of trades because the the massive confirmation times with the theorium, the cost on a theorem are prohibitive. You know, it's just getting so expensive to run. You know, it's getting clogged down by by a random stuff that don't matter. So these are all problems. We need to get to that point where, you know, we have a hundred x better tech and then it's really a matter of you know, so we have backward compatibility, we have a one hundred x sort of better tech guarantee, whatever you want to call it. And then three, it's all about working with the right partners that accumulate sufficient network effects to be sort of self standing, and that includes not really working with the well established partners, initially an etherium, but with new upandcoming once and supporting those...

...guys that are building really cool new defy stuff really nurture that that community deeply like. We have absolutely no life and we don't plan to have a life for the next foreseeable few years until this thing just is self sufficient and is running and it's growing by itself, and that means just really supporting our deaths with with grants, with our attention, with nurturing them. We have lots of talented people internally that can that can help out teams. We don't have a whole lot of cash resources as other you know, maybe projects have raised the hundreds of millions of dollars, but I think, I think we are still competitive as far as the benefits that we provide. So you know, that's, I think, the the stuff in the secret sauce and also creating things that just simply don't exist anywhere else as far as applications go, and we have a bunch of those in the pipeline. And then the rest of the final ingredient in the secret sauce, I think is just a little bit of luck. So hopefully we we get that as well and and then we we got a good recipe going. Right. Do you get any more questions? I had one more, but I don't know if this is going to go on a tangent. You mentioned that you guys don't. So how do you? How do you do that? How do you handle CIBIL resistance. How do you assure that, like all these guarantee, that you have all these guarantees without slashing validators or Byzantine validators? Oh, I can get into hours for this. What? How much time do you have you? What are the guarantees that you want to provide that do you think you are providing with slashing? That's a good question. So the first one will be probably civil resistance. Right, we don't want. Why do you think civil resistance? I mean, B ift systems have been being have been built since the s precisely to not care about that small percentage of nose that are misbehaving. But those weren't Byzantine. Those aren't Byzantine systems in a permissionless environment. Right. So the problem is like, in a permissionless environment, when anyone, anyone, can spin up a note, where it's so easy, how do you ensure that not the majority is Byzantine? I mean, that does none be a stake, right? So do you have to accumulate that steak in order for you to be able to spin up a whole bunch of notes? You can spin up a lot of nose onnava. It just you won't have a lot of steak attached to them. So okay. So they're still thinking there's just no slashing of the steak. Correct. Yes, yes, yes, so what happens to a misbehaving note? You just kick it out of the system? No, you just ignore it. It just does it something. So I guess the easy way to say is probably that you don't need slashing because you have this steak and there's probably a high time for you to be able to transfer this steak to a new note for the to make sure that other people don't ignore you anymore. What do you mean by a high time? Like there's a there's an overhead on you having to exit your steak and then restaking it to get it to another note where you can start misbehaving again, to miss lead or to be a Byzantine node. I mean, even if you do that, even if there is almost zero switching cost to that, which that's not true. Even if that was the case, though, as long as you don't accumulate some large percentage of the steak, then doesn't really matter. You're basically entirely ignoring the system. That's the whole point of bft systems, so that that and that happens to the case. I think what slashing does is, you know, prevent those that you know maybe are thinking about doing misbehavior to not really do miss any misbehavior. But ultimately that's really not saving you anything because you already had to be aft protections in place. It's kind of like, I don't know, you put locks in your house and then inside the house you still have a gun. I mean, you know, it's maybe it's not a great analogy. That's not a great it's not a great one, but it's not. It's like you already have. You already have the protections in place. You're just creating additional drama and complexity internally with your with your slashing. So it's really not necessary. And here's the thing. Ultimately, if you end up breaking the threshold guarantees of the BFT system provides so the first layer of defense, which is the most important one, slashing does not prevent you. It does not save anything. If I accumulate majority stake in the system, I can actually make the minority stake look like the misbehaving ones and I can kick those guys out, which is crazy. So you, like I that's crazy. Like not only have you not misbehaved, you're totally good. I can make you lose all your money because I can make you look like the minority member in the system. So it's really says you nothing. Yeah, so I guess the protection in this scenario is that the minority just forks, the minority just works. Yeah, but by definition that's not really that's not really a protection, right, like you could be double spending like how long in a preproof stake system.

If that where to happen, you probably would have to have a whole bunch of social like skype calls to make sure what the hell just happened on do transactions, issues have already arrived is and then eventually you somehow fork, which is fine, and you undo ALD the issues. But I mean, this thing can happen in a system that is also not doing slashing in any case. If you if you end up going down to skype calls, then whatever problems you had in a in a non slashings, in a slashing system, you can also solve in a non slashing system. Yeah, so one of one of the people at Ava, Philip Blue, he says that proved stake is the cockroach of Civil Control, because you can always just fork out the person that's doing the attack and then force them to Rebuy, whereas in proople work he required you could just like switch to a new chain. So I like that street. I think it's a difference between internal and external resources being sticked. Yeah, it's correct. Yes, it's difference in proof of work and proof stake. What I'm interested is that I don't quite understand is in your right. This did gone a tangent, but it pepe my curiosity here. Like it say, we have some type of malicious note in the network with it, with with with some amount of steak. How much effect did they actually have on consensus? If the way rounds work is any individual node requests state from a random sample in the set and then does it over and over again with each with each of those random samplings changing with each iteration. Like it doesn't seem like it's very easily deterministic on how much an individual malicious node can control this, like the state something going one direction, because you have that kind of like avalanching. It's called avalage for a reason, right, because like that the random sampling guarantees that like once, once you have a chip and consensus in any given direction, it goes that direction very quickly with the number of iterations. Yes, yeah, so you would have to have a presignificant stake in order for you to to prevent that tipping over. And Yeah, it's not really in the number of nodes, it's really in the in the in the stake that you control. I mean the point of Alva is that eventually, once the steak is very highly distributed, it could potentially be in the in the hands of, you know, thousands of nodes than we're able to sustain that growth pretty easily. So it's future proof. That's that's at least. He's another big question which I've always wandered. Distribution. Yes, I always and cares about distribution of lava and the underlying assets in an ecosystem that's going to have a tremendous effect, especially because of the tour said on concern course. Yeah, yeah, no, absolutely. I mean distribution is huge, is critical. We Are we are going, we're trying to find every single possible source of distribution channels that week we can find where, even in considering interesting things like POW, actually, so we might allocate certain Alva Tokens to be mindable via POW and it's kind of like a fair opened thing we can. We're also looking at that work clock type of distribution methods. But the thing here is that basically we're start trying to piight, we're trying to serialize all of these one and after another. So it's not going to be everything all at once. There's going to be public sales, there's going to be, there has been some private sales, there's going to be developer grants, there's going to be which actually there already developer grants. There are sort of more nondeveloper grants that have happened. There is going to be distribution via these POW and work clock that mechanisms. We are very concerned about distribution ourself and we want to make sure that there is not a single person out there that can point it up and be like, Oh, this is a pretty mine thing and all that kind of stuff. They're going to do that. So get over that. They're get I know, I know that they're going to do that, but I would love to just be like yeah, you say that about all of like scept that the data eventually, you know, maybe three, four years from now, is going to say that it's even more distribute than bitcoin. So that's that's my dream. That's really what I want. I don't care about the money aspect of this thing. I want to be able to just be like, Holy Crab, this thing is more decentralized and more robust and bitcoin and put that hat on. I don't care about any other thing that comes with it. All right, do anything else for right before we go off on significantly more tangents, because we probably could. I mean, I'll definitely message either Kevin or Stephen. I've been in contact with them anyways, once I have a few more questions, but I feel like our listeners will probably no longer want to listen to all of those. For full disclosure, like hashing it out, like AVA is a sponsor of hashing it out as it currently stands. It did not influence any of the questions we have now or are particular interest in...

...it. I think just our interests in willingness to kind of dive into this and ask questions maybe sparked the ability to get sponsorship in the first place. But like, like, this is interesting, we care about it and it's new and so like. That's basically where we leave this before my are we sponsors. I'd even know it. Are we sponsor of you guys? Graduations? Of Jesus about this? I was also overs on here, you know, like interesting, interesting, I don't even know. I Frank I did not know. Well, otherwise, you, Maxi Onia. Okay. Well, next time, let's go more ethanax. They want. I want to handle a tart questions. You want to argue. I do want to learn you. Yes, let's let's bring some of the youthanxy. It's not I want inpen on five times. I'm sure we can bring it back on sometimes. So yeah, probably I need Anti Pross, whoever that guy is. I need that guy here. That's that's going to be fun session. Whoever that guy is a I need of here. That I'd be great. We'll work on trying to facilitate some panel where we moderate you versus sweet f Max he's kind of like that. Jesus, I'm all you with a nick episode can be. Can Be that, but more that. That was a fun episode. Then I want I want to just I want to go after actual, like full on Eth maxis and just have a beast shit, insane conversation. That's going to be fun. Honestly, Kevin, I'm kind of happy that you guys entered this space because or like became more serious with Ava, because all the eth maxis are no longer on my back. They're all on you guys now. My twitter experience has been so wholesome, so close. Oh my God, they're on me. Well, to be fair, they're not bothering me because they can bother me too much nowadays. I make I make noise against the etherium for real reason. They just can't see it's very objective noise, right. It's like look, well, high fees, all that kind of stuff, and there's nothing they can say. But I completely agree. Like I've been. I was commenting on a theium a lot because us. So I just think the east too, is practically going to work. And I got people are I got some Eth maxis dming me saying that I'm not doing good marketing for a theoreum and that's going to cause our bags to dump. Jesus. I was like that's great. Yeah, I don't get. This is why I brought the show. All right, guys, let's wrap this up. Thanks for comings on th add as much as we can that I remember to add to the show notes. And looking forward to seeing what you guys build and hearing you come on show with you later. Thank you. Thank you, guys. Thank you Deane, and thank cory and I'll thank you John. You've been quietly listening, but thank you for coming in. Thank you, guys. Thank you, guys. Are.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (118)