Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Ava Labs x CBER Ep 10: Deep-dive on the Avalanche Blockchain
69 Plays1 month ago
Stephen Buttolph (Chief Protocol Architect at Ava Labs) discusses how Avalanche's blockchain can be used for tokenization of real-world assets. The podcast also explains the Avalanche consensus protocol and how this protocol is an important differentiator between Avalanche and other blockchains.
Learn more: https://www.avax.network/
Recommended
Transcript
Introduction to 'Crafting the Crypto Economy'
00:00:06
Speaker
Hello and welcome to Crafting the Crypto Economy. I am Silvia Sanchez, Project Manager at OWL Explains by Avallabs, and today we bring you a transformative podcast series in partnership with the Crypto and Blockchain Economic Research Forum. This series features leading faculty from renowned global universities exploring various elements in the blockchain ecosystem. These episodes are a bit longer than our usual hootenannies, since we will be getting very deep.
00:00:33
Speaker
And also, each episode will have its accompanying paper posted on our website for further reading. And with that, I will hand it over to our moderators Fahad Saleh and Andreas Park.
Focus on Avalanche Protocol
00:00:45
Speaker
Hello everyone to another edition of the Siva Abu Lab's podcast series on Crafting the Crypto Economy. I'm Andreas Park from the University of Toronto and I'm your co-host together with Fahad Saleh from the University of Florida.
00:00:59
Speaker
So um what we're trying to do in this podcast series is bring to you the audience interesting insights of cutting edge research in the field of blockchain, decentralized finance and other other related topics.
00:01:15
Speaker
um Now, Fahad and I have obviously have this podcast series that's been made possible only by the support of Avalops. And Fahad and I had a conversation about it that we don't really feature the Avalanche Protocol, um which has been developed by Avalops prominently in this in this podcast series. And so we thought we were going to change that. um So what we want to do in today's podcast is bring to you a big picture overview of how the Avalanche protocol works and and what it what it really does, why it exists and what we can learn from it.
Interview with Steven Batov on Avalanche Protocol
00:01:50
Speaker
And we have the perfect guest really for this ah for this podcast series. I'm very happy that we're joined by Steven Batov, who is the chief architect of the protocol in Avalanche.
00:02:06
Speaker
um So Steven, welcome to and we're very happy to have you in this podcast series. Thanks for joining us. Awesome. Thanks for having me. I know super super looking forward to the conversation. I'm really excited to to dive deep. Yeah. Yeah, so I'm actually looking
Teaching Blockchain Concepts
00:02:20
Speaker
forward to this too. I'm always happy to learn something new about ah protocols and the like that I've not learned very much about although um A little bit came to fame here from my side as I was co-hosting or co-organizing a research seminar series um at the University of Toronto's Fields Institute, that's that's the math department, with other people from engineering and the like. And we had a we had a series which ran in 2019 and at the time we actually had Emim as a guest to explain what the Avalanche Protocol was there for and at the time
00:02:52
Speaker
um you know Realistically, the protocol was not really operational, so it was really pretty cool. In case anybody wants to know, we also had Silvio Michaeli from Algorand there before the protocol world went went live and we also had Vitalik, so it was actually a pretty high-profile series in hindsight.
00:03:10
Speaker
um not Fahad and I are both business professors and we do research on blockchain which puts us in a very interesting position because on the one hand we're interested in the economic mechanisms of these networks but we also need to understand the institutions really well and then on the other hand we we teach to business students at all levels starting from undergrads to and MBAs to sometimes also executives And we're trying to explain to them the merits of of these protocols and actually just really how they how they work. So it kind of puts us in a curious spot. um Now what I'm trying to do in this podcast today is I've tried to play the role of of somebody who is really a student, like an undergrad student, who knows nothing about this and who is not technically inclined.
00:03:54
Speaker
And I'd like to understand from you, Stephen, how the protocol really works.
Avalanche's Mission and Subnets
00:03:58
Speaker
um And with that, let's maybe just start with but why why does Avalanche exist? What what problem do you actually try and solve? Yeah, for sure. So I think the the mission statement of like The AVALABs and and like the Avalanche Network is trying to digitize the the world's like you know finances. right So basically, like bringing in like real world assets into this kind of like digital ah kind of economy, ecosystem.
00:04:28
Speaker
um So I think that that's the the high level kind of mission statement um for for Avalanche. And I think that that mission statement probably doesn't really differentiate like that much across like many blockchains, to be perfectly honest. like I think that Ethereum is trying to bring like finances into the you know real world assets, into this ah economic um kind of environment but um actually wait if if I can interject there um that's a very interesting answer exactly I would not have thought that ah somebody at the Ethereum Foundation would give the same answer meaning that um yes they they want I think every let's say lab or foundation attached to ah an L1 wants to have activity on their chain
00:05:17
Speaker
ah But when you and you say real world assets, I think of more than financial assets. And that's a very specific direction. Or let me, from a technical perspective, it introduces a very specific direction, right? Because it poses unique challenges relative to saying, hey, I just want to be able to do asset swaps based on assets that settle already on my L1 system, already on my chain. So maybe if, as a start, could you give some context on the sort of how that mission affects the design of the Avalanche
Real-world Applications: California DMV Case Study
00:05:53
Speaker
blockchain? Absolutely. um So a good example of this I think is actually so recently I think California DMV digitized a lot of our number of car records onto an Avalanche subnet. um So this is very much kind of the the push that you know we've been going on and trying to digitize these kind of like real world assets and trying to like
00:06:16
Speaker
improve efficiency on various mechanisms. So subnets are very much structured and designed specifically for these environments where there's is different regulatory concerns. So a great kind of like example, say, is some some company that wants some properties of blockchains, but not all properties of blockchains. So all properties of blockchains might be you know like a Bitcoin mainnet, Ethereum mainnet. You have a public verifiable ledger that is kind of censorship resistant, that there's no like um global entity that owns it, and it's just kind of this kind of unstoppable force that keeps moving forward. um Some companies, for regulatory reasons,
00:07:07
Speaker
explicitly need to be able to like censor transactions, say like their OFAC regulated stuff and they're a US company, like they just can't touch some some things. so Actually, wait so you know subnets I think are a very interesting topic, but I think this might be like not quite the 101 and something I want to get to in depth ah maybe a bit later in the podcast. At at a high level though, just for the framing for the audience, I think what you're saying is that this this point about subnets, which doesn't exist in the Ethereum ecosystem, at least not that literal say for that literal term,
00:07:42
Speaker
um it allows for a certain amount of customization, right is is I think what you are getting at. Is that fair? Yes. Subnets let you pick and choose kind of what Parts of oh, sorry. Go ahead.
Avalanche's Multi-chain Architecture
00:07:56
Speaker
and I'm sorry guys I have to I have to interrupt you there because you already lost me as the audience and and your undergrad student So can we can we just actually take a huge step back and just talk about what our lunch Actually is before we go into subnets and all these details. So let me let's just take a starting point, right? Ethereum which is what most people
00:08:17
Speaker
you know Most of the audience, even if they are not really in the weeds of blockchain, may have heard about. right so it's A blockchain is a data structure where you create transactions of some form or operations that are put into blocks that sort of fit together in in sequence. right And then there is a process around this ah where these blocks get produced and then the blocks get put onto the chain and they're considered to be valid and then you move on one one block at a time.
00:08:45
Speaker
So like if I may, you know, I mean, just for the maybe for the sake of the argument ah for the audience, if you think of Ethereum, you know, now runs on the system called proof of stake. Really what that means is that there is for each block, there is a proposal.
00:09:00
Speaker
and then there is a committee of validators and the proposer proposes a block which is a set of transactions and then the validators vote whether or not this is valid and if it is then it goes on to the slot that is provided for it on the blockchain and then on you move to the next block.
00:09:18
Speaker
And there's also a process of finality, where the entire group of validators votes for some blocks, some specific blocks. And once these are voted, then some block in the past would be considered valid and final and cannot be changed anymore. So this is a very big picture overview of how something like Ethereum works. Now, can you, Stephen, explain to us what exactly the difference to this kind of process is and where Avalanche as a specific protocol comes into place?
00:09:47
Speaker
So I think you just gave a ah good kind of like summary of general blockchains, right? I think at the the core, they are a database, which basically means that you can like store data on it, read data from it, write, update things very arbitrarily. um And the kind of like writes and sometimes even reads to that can be you know authenticated based on the rules of the blockchain, right? So how the database changes ends up being kind of whatever the rules of your blockchain are. That is a kind of like single blockchain, right? So Bitcoin is a single blockchain. um Ethereum is a single blockchain. Avalanche, the Avalanche network
00:10:39
Speaker
ah Is not necessarily comprised of a single blockchain there's actually multiple blockchains, right? um So multiple blockchains already exist right there is Bitcoin there is aetherium and there's no real like Interaction between them at least like within their protocols um The avalanche design um feels for a number of reasons that there are going to be multiple blockchains um with different rules and potentially even different validators and the validators are like people that kind of
00:11:19
Speaker
agree and actually like change the database. but Can I can interrupt you there so just to to understand this better? i mean In principle, Ethereum is just ah a mechanism, a protocol. right and then you know Ultimately, and just like Bitcoin, where they agreed on a particular chain as it is.
00:11:37
Speaker
Nothing prevents say Bitcoin from running another one, like another Bitcoin blockchain, which effectively is what Dogecoin is. right it's It's basically just a copy of it and runs in parallel to it, and it has nothing to do with Bitcoin. and You can do the same thing for Ethereum. You could also run a new Ethereum network using exactly the same rules, um starting at something completely new point, and it can do the same thing. right so and Sometimes it's fought towards forks, right? is Is that what you're talking about? or you So you have the ability to you just give people a technology that they can deploy? Or are these multiple chains that you refer to somehow connected? Not quite. So if you were to take the Ethereum protocol, um so I would say, you know, Ethereum mainnet is a database, right?
00:12:24
Speaker
Utherium testnet I'm you know, say Sephoya or what I mean, you know don't fact-check me on the naming Is another? Utherium rules database rights, you know, but they're at the end of the day they have different actual data in them, right? So there's two different instances of the same kind of Database rules set but they're two different databases, right? um So that um I would say that they are two different blockchains at that point because they have different data. um So kind of regardless of the rules and how they modify it, like that's how I think of blockchains is like whatever the data is and the protocol is a blockchain. For Avalanche, um the blockchains kind of the the key thing, the key difference between blockchains just out in the world and Avalanche
00:13:20
Speaker
like layer ones or subnets or blockchains, um is that they all register their validators in this same global blockchain that we call the P chain or the platform chain. So basically, there's this small level of hierarchy um in Avalanche blockchains where you have the platform chain that has a registry of all of the validators or the people that are like running these chains. And then you have all of the other blockchains. And the reason that that coordination layer exists
00:13:57
Speaker
is to provide interactions between blockchains. So um you know there's the like things such as, say, like a Ethereum
Avalanche Chain Structure and Validators
00:14:07
Speaker
to Solana Bridge. right Those exist, and those are interactions. But those end up being these kind of like trust points, where you aren't actually getting the security of Ethereum, you aren't getting the security of Solana, you aren't even getting the security of like like whichever is weaker you're actually getting the security of the bridge if you use the bridge right and so that is really something that um ends up being a major choke point between interactions between these chains. Can I just inter interject briefly so can we take a step back and go okay so let's start at the let's go back to before there's any activity on the chain okay can we go back to sort of like the equivalent of the genesis block and talk about
00:14:54
Speaker
ah what that looks like. In other words, what I'm saying is i I appreciate and understand that there can be complexity arising in the system. And for instance, if we're thinking in an Ethereum context, I think of things like, you know, rollups can exist, but you can still talk coherently about Ethereum without talking about those things. Right. And so could you, like you mentioned, teaching, right. And then you clarified it's a platform chain. So at the Genesis, what exactly exists?
00:15:23
Speaker
And what is the meaning of block production in that context? right So Andrea sort of sketched out but what that means in the Ethereum context. But if we assume, for instance for instance for instance, nobody is deploying anything on this chain, and it's just deployed like by the developers, right but nobody's actually adding activity to it. What does the block production process look like in that world?
00:15:45
Speaker
So that's actually interesting. So most blockchains will produce empty blocks based on some block production mechanism. Avalanche actually does not. um So avalanche will quiesce. If there's nothing to do, it will not do anything. um So this is very different in if you look at, say, Bitcoin. Bitcoin is always producing blocks. Doesn't matter if users are submitting transactions. So um In the Avalanche network, the answer would be nothing would happen. but Okay, so let let's let's say let's let's say let's say they're payment transactions only, right? So like it's me and Andrea sending Avax back and forth to each other every whatever, ah five seconds. What happens then? Sure. So the so I guess the the question is is, what is the kind of Avalanche block production mechanism? Yeah, exactly. So how's the second block produced, right? So that's the question. You have an Innocence block, so now Todd and I actually exchange
00:16:42
Speaker
A token, a native token, right? So what's happening? Yeah, so the full, so I guess, do you want to start at a a high level of block production or you would just want to run through the full slow? Start high and then go deep. with We ask you if more if we want to know more. um Okay, sounds good. So um the validator will have transactions somehow um and we'll say, okay, um you know, we have transactions that are pending. So, you know, the network is willing to produce a block.
00:17:11
Speaker
um So essentially there is a um random selection um where the ah Based off of the current validator set um and based off of slots for block production, um a validator will get randomly selected um to say, okay, this is your slot that you can produce this in. um If the block producer chooses to produce that slot, then the block is produced. And at that point, the consensus mechanism will start.
00:17:45
Speaker
um And so the consensus mechanism will work to finalize that block. um If the block isn't produced, then the slot will pass with nothing happening and the next slot will start. And then that the block proposer of that slot can choose to produce um a block.
00:18:02
Speaker
Okay, so so but just to clarify, because we have some some jargon from earlier that I want to make sure everybody understands. So now you're talking about a linear chain, right? So is this the P chain? Is this the platform chain that we're talking about? Or is this some like, what do we call it? in What's the term of jargon for this? This is every blockchain in the Avalanche network will be independently performing this process.
00:18:26
Speaker
But that that genesis there's another at the genesis, not many chains, right? So at Mainnet Avalanche Genesis, there are three chains that were included in the Genesis. One of them is the platform chain. um The other one is the smart contract enabled contracts chain, just the C chain. That's actually the chain that most people use on a kind of day to day basis because it's it is in EVM um I don't want to say EVM compatible because there are some slight differences, but it is like a solidity compatible blockchain.
00:19:01
Speaker
um And then there is the X chain, which was um kind of the simple payments um exchange chain is kind of how that was set up. So ah at Mainnet Genesis, there were three of these such chains. But so if Andreas and I are just sending Avax back and forth,
00:19:21
Speaker
I would have guessed based on what you just said that these are happening only on the X chain, but what you said earlier suggests that somehow they're happening simultaneously across all three chains. yeah where we know ah Where would our transaction go actually? that Do we pick or? you can You could submit a transaction to any of these chains. they have They're different blockchains with different rules, um so the types of transactions that you can do on them are different. right so On a evm chain you can just do simple transfers if you wanted to i could just send funds to this you know i can ask one very basic question so because you said a genesis. I just just to be clear that each of these chains have a have a separate genesis block or do they all start at the same genesis block.
00:20:05
Speaker
So because i'm asking the for I'm asking for a foreign reason. So somehow some people have to own these this tokens, I assume, right so that you can make some form of gas payment. um And so there has to be a stripe maybe in the genesis block. So do they are there separate allocations? or this's all the same suppose the word What was the word you specifically said? There has to be a what in the genesis block?
00:20:26
Speaker
an allocation so people need to have tokens and so it has to be some allocation made to somebody so that the whole thing can start right so somebody can spend tokens right is i mean are you asber first of all very quickly do you have a similar concept as ethereum where you have to pay for gas or you have to pay gas sorry there are transaction fees yes yeah okay all right good so so you i i think i think for any permissionless network transaction fees are a requirement um just for DOS resilience reasons. So DOS is basically a denial of service attack. um So if you didn't have transaction fees, then someone could just- Okay, I just wanted to clarify. No, I understand. I mean, Bitcoin doesn't have them per se, right? But I get it, right? um But coming back to Andreas's question, is there is there a common genesis block? So the full mainnet initialization is the p-chain has a genesis block.
00:21:25
Speaker
inside of the platform chain's genesis block specifies the creation of two chains, the C chain and the X chain. And so at the ah origin point of the network, those three um chains are created. Each of them have their own genesis block. But in the P chain's genesis block, it specifies to create the X chain and the
Staking and Token Movement in Avalanche
00:21:53
Speaker
C chain. Wait, OK.
00:21:55
Speaker
can i Can I think about each of these as each of the chains as being its own state machine? So is there always a state for each of them? Yes. And so what you're really saying is that the P chain has sort of the genesis genesis block, like the the king of all genesis blocks. yeah And it tells the C chain and the X chain what their what their genesis state is going to be in some sense. Correct. I see.
00:22:23
Speaker
But now, OK, so part of what I felt like when you were framing it is a bit like, OK, so the exchange is kind of like Bitcoin, but with a different consensus protocol, which let's leave consensus protocols aside for a moment, because you said like simple payments. And that's, I think, how a lot of people conceptualize Bitcoin. Right. So it's just things like me and Andrea sending Gavax tokens back to back and forth to each other. Nothing crazy sophisticated.
00:22:43
Speaker
And then ah there is, was it the C chain is this is the contract chain, the smart contract chain, which is a bit more like Ethereum, where it could be Andreas and me sending Avax back and forth to each other, but it's kind of not the point of the chain. The chain allows for richer things like the smart contracts that we hear about on Ethereum. And that leads me to ask the following question, which is, so what is the P chain doing now? Is it like coordinating somehow across the C and the X? like what it what Why do we need another chain?
00:23:12
Speaker
Yeah, so we've talked um about blockchains a little bit, um and we very briefly kind of mentioned validators. um So in the Avalanche network, there are blockchains, and then there are groups of validators that we call um subnets. So at mainnet Genesis, there is one subnet,
00:23:36
Speaker
um And that subnet includes the three blockchains, the X chain, the P chain and the C chain colloquially termed the primary network, the Avalanche kind of like a primary network. So the subnet being kind of like the owner of the validator sets determines who is actually going to be um performing consensus and determining like block validity of these chains. So the X chain, the P chain and the C chain all actually have the same validator set. Um, and that validator set is managed on the P chain. So if you wanted to stake on the avalanche primary network, you would need to move your, um, avalanche tokens, a box for Avax, depending on, um, you know, pronunciation, um, to the P chain to stake
00:24:35
Speaker
for the primary network. um And that would then mean that you are eligible to produce blocks for the P-chain, X-chain, and C-chain. So as far as just the primary network,
00:24:48
Speaker
That's the rules for the P chain. Okay, so is this in some form similar to the beacon chain in in Ethereum where there's sort of like people's stake on the beacon chain, I think it is, right? And then then they get selected based on their stake that they lock up there. Is is is that to think about it? And now maybe ah I'm just revealing that and I'm pretty clueless. Again, can I just reframe the question? So ah so the way I was thinking about, I think I had a parallel thought to Andreas, but maybe slightly different a framing of it, which is When I think about Ethereum, if I want to stake natively, not through some intermediary, I actually send my Ether to a particular smart contract.
00:25:30
Speaker
um and so it's kind of like It's almost like on your C chain, it would be like, hey, look, I want to stake. It sounds like what you have is you're saying, like no no, look, this is not like some This is not the same thing as like arbitrary smart contracts. This is like special. and so Why don't we just actually catalog this in a different place? so For instance, if I try to think about the activities on the Ethereum blockchain as sort of separated across these three chains that we're talking about, to try to get a sense of like what should ideally is really happening on these chains.
00:25:59
Speaker
ah Based on what we're saying, I would say like okay so payments should go on the i think it was X chain, we said. um the the The smart contract stuff, let's say deployments of decentralized exchanges, all of the Uniswap activity, for instance, should go on the C chain. but For instance, when i want a stak when I want to deposit my ETH into that staking contract, the equivalent of that is happening on your P chain. I take it. Is that correct?
00:26:26
Speaker
Yes. So any staking operations is ah are occurring on the platform chain. um Yes. So if you have a box on, say, the C chain, you would need to move it to the P chain and then stake it. Right. Okay. So that's already interesting. So um in the sense of like, so these chains have to be sort of They have their own states, but they have to have a sort of compatibility across them. For instance, you so so the Avox token, um if I own it and I want to send it, it must be the case somehow that this is sort of ah consistently understood across the chains. Now, you briefly alluded to this idea that I kind of like send the the balance from one chain to another, right? I move it from the C chain to the P chain.
00:27:17
Speaker
Is this materially different than thinking about something like me moving my ether from layer one to um a roll up? is this sort of And part of the reason I'm asking about that conceptualization is that in some sense, like the the mechanics of those processes, as best I understand it, is really that I'm essentially creating a new token on the other chain. um And I'm sort of like freezing the ability to access it on the first chain.
00:27:44
Speaker
Or potentially burning it entirely and so like at the mechanical level. It's really just as simple as yeah burn this create that um But then we interpret it as well It's the same token because of somehow of how that like bridging step works Is that is that how I would is that the same sort of mechanics or similar mechanics that moving across chains? That is not quite how I would describe it. So in the ethereum roll-up world ethereum like the layer one does not know about rollups at all right they just have smart contracts and so as far as the ethereum l1 is concerned this thing is just a smart contract right so you deposit the eth into the smart contract the smart contract is going to own that eth and then the smart contract will decide to send that eth somewhere else on the l1 when they when someone tries to withdraw it right
00:28:37
Speaker
And there's, of course, a bunch of validity rules within the smart contract. But as far as like the L1 is concerned, the ETH is never leaving the L1. It's within that um smart contract or you know being moved around. um So the L2, in that case, will have kind of this kind of mocked version of the ethos as you had commented um But and then you know when it pushes it back down into the smart contract It'll move it for avalanche the of ox is actually moved from chain to chain So when you decrease the balance on one chain? There is no reference to that balance any anymore on that chain and it will then get moved over to this other chain the reason that that is possible um is because
00:29:27
Speaker
these are all core, like, ah these are all validated by the same set of validators. So there is a kind of meta protocol for um transfers within the same validator set um for the primary network that allows this transfer to happen. So then the question that I have is, is the state of the So one way I think to think about consensus is we're going to have consensus on the state of a system. but You can even abstract from blocks and say, like we're just going to agree at whatever at index 55 that this is the state of the system. And the index, you can actually that kind of maps back to blocks, but whatever. like The point is we're coming to agreement on the state of a system in some like notion of time, which is, let's say, the integers can correspond to blocks or slots or something like that. right
00:30:21
Speaker
um in your context, meaning in an avalanches context, is the state that these validators are coming to agreement on sort of joint across the three chains? Or can they like separately come to consensus on a new block on the X chain without interrupting, without having to weigh in on whether it's say the C and the P chain have been updated or something like that? Because if you're talking about like, ah we have consensus on, let's say, the the the three states of each of the chains simultaneously, sort of the Cartesian product of them, then then it very much like makes sense what you were describing a moment ago, which is like, okay, this balance is drawn down, that balance is drawn up, we're anyway coming to consensus across all of these things. So this is like totally coherent to think about. um
00:31:08
Speaker
So is it that or is it they so they are actually coming to consensus on each of the individual chains separately at each point in time? So each chain is performing consensus independently. um That is important because otherwise you're not really running like a chain anymore. You're really more running like a DAG kind of thing and it gets quite complicated. um However, the block validity rules um for these kind of cross chain swaps require ah prior finalization of these things. So the way that the swap actually works, if you're trying to move a box from one chain to the other in the primary network, is there is an export transaction on the but origin chain.
00:32:05
Speaker
And that is accepted just seamlessly, right? Cause you know, you have your, your, a box so they can verify that that, you know, is getting exported. Okay, fine. Like I don't really care about it. Then after that block is accepted, you will have an import transaction on your destination chain. And as part of the validity rules of that transaction,
00:32:30
Speaker
that node operator will verify that the ah that actual export was finalized on the origin chain, which works because they have the same validator set.
00:32:45
Speaker
Right. But okay, so kind of coming back to maybe the the Ethereum contrast. So as as as is we were saying, the Ethereum chain doesn't depend on any of its roll ups. Like it cannot have validity rules that condition directly on something that's happening on Optimism Arbiter. There may be ways to kind of internalize that information but it's it can't really condition dr it sounds like that's a difference here where if i understood use correctly you're saying yeah like okay i want to move from i don't know c chain to p chain and the way it's gonna work is actually in sequence first i'll say i want to export from the c chain.
00:33:22
Speaker
That gets finalized. And so now everybody's like, oh, look, the state of the C-chain has been updated. And this has been whatever my balance has been deducted by whatever amount or something like that. And so now it can be imported on the P-chain. But that means the P-chain is actually conditioning on activity on the C-chain, which which does't isn't, is let's say, a difference, yeah I guess, in some sense to to the Ethereum framework. Is that fair?
00:33:48
Speaker
It's certainly a difference. ah The X chain is not a roll up of the P chain or or anything like that. All of the blockchains in a subnet, um like they all kind of have the same security assumption of their validator set.
00:34:03
Speaker
Um, so like the difference is in ethereum, right? Like you have the l1 that's secured by you know thousands of validators that We can argue on the number if we want to but anyways, um, and then you have a roll-up that is, you know secured by maybe a few people right, um, so you wouldn't want to have the um, like any anything those few people say be a bearing on the validity rules of your
Avalanche's Consensus Protocol: Snow
00:34:33
Speaker
L1. Now they have like very kind of strict like timing rules so that you know they have basically a only one trust assumption rather than a majority trust assumption or things like consensus and we could talk more about that if we want to.
00:34:48
Speaker
But essentially, that's why in Ethereum, it would not be safe to condition on something that a small group of people say. um And that's not what's happening. In the in the Avalanche network, um the the validator sets are the same. So if you trust yourself, you can trust you know kind of yourself right because they're the same. but But in Ethereum, it's not even coherent to condition on things that are on the L2. You can feed it in, right but you can't ah the the system Into the system. yeah Yeah, yeah the status is so basically what I'm saying is so for instance even this is Not something we should probably dig into right now because it's a bit further um But just for like for the sake of clarity if I'm writing a smart contract on the C chain Can I condition on things within the state of the X or the P chain? No Because the the reason I was asking that is because it sounded like this import which I I'm not that's not writing a smart contract but still this import and
00:35:45
Speaker
was conditioning the validity of it depended on the state of a different chain. But I guess that that concept doesn't extend to, for instance, the so not like, yeah, when I'm writing in any system, when I'm writing ah logic, it has to the conditions I'm specifying have to be coherent to according to the system. Right. And so in the theorem, I think it's a very simple concept, like the Ethereum L1 chain has a state.
00:36:11
Speaker
And I can condition on things inside that state to write my you know logic. This is this is a very is a very important point. um When you are writing a smart contract on Ethereum, you are a user of Ethereum. right You are not defining the verification rules of the Ethereum blockchain. You are defining what to do in the context of those rules.
00:36:36
Speaker
right so um In the defining of the actual rules of the C-chain, X-chain, and P-chain blockchains, we can specify safe behavior to transfer a box or generally other native assets, but the this is not related, so we can skip that. um But a box between the chains, you can define that as kind of a primitive um to be used and that is a safe primitive to use but that is not necessarily like the user does not have the ability to define those primitives um if that makes sense yes you're you're saying at the protocol level sometimes you are using information from one chain
00:37:26
Speaker
to think about validity of something happening on another chain. But that doesn't mean you extend that to the universe of, you know, this is a permissionless setting. You're not saying like anybody can now condition across chains. Yeah, i mean it would be like, you know, in Ethereum, you know, the blockchain rules are determined based off of the op codes of the EVM. yeah Right. So the EVM have instruction set that you can use.
00:37:50
Speaker
You know, people, the you know, the the Ethereum network upgrades from time to time to add new op codes, right? So like, you know, the the big EOF kind of push that they've been trying to do recently is introducing a whole new set of op codes.
00:38:04
Speaker
um That is something that the protocol can do and change the validity rules kind of as time goes on and you know perform network upgrades. But that's not something that you as a user could do. You couldn't as a user submit something that changes the validity rules of the the chain. Now there are some chains that actually that is not necessarily true paul ah along like the governance style chains like um I think Polkadot and Tezos do some interesting things here, but i don't want to that that right but yeah but but I think this goes back to the point that like your so so some of the stuff that we were talking about in the context of Ethereum, like moving tokens across chains, is just sort of through the smart contract functionality of the chain. um Whereas I think in the avalanche context, it's more baked into the protocol. Actually, but then at least a question of like, OK, so what if I create my own token?
00:39:02
Speaker
um is the is that the Is the export import stuff materially different for that relative to the Avox token? So in practice, the only token that makes sense to move around within the primary network is Avox.
00:39:23
Speaker
um because Because that's really the only thing that you're going to be moving to the P chain for staking or like things like that. So actually so its so so you said make sense, but the question is, is it feasible? So if I create my own token, so I guess the place where I create my token is is the C chain, the contract chain. That's the only place where it makes sense, I guess, right?
00:39:42
Speaker
Oh no, maybe I'll get on. OK, but let's just just for the sake of argument, I can create my own token on the C chain. Is that fair? ERC20 tokens. Yeah, sure. Yeah, yeah sure. um Are you saying I cannot move it to say the X chain or that I wouldn't want to move it? So the Ethereum virtual machine does not treat ERC20 tokens as anything special. There's just data within a contract. um So that data is not possible to transfer to something like the P chain. The X chain, you can create custom assets that are movable um to say the P chain um that are not a box. um But that is not
00:40:34
Speaker
um like an ERC20 would not fit that. That is technically ah something that could be extended. And that has been a conversation about whether or not people would want to um introduce kind of like these ERC20 tokens and moved them to the P-chain. um And so that was actually, and this is maybe took touching a little bit ah too far at this point. This was something that we had,
00:41:03
Speaker
considered as an option for um launching additional subnets, additional proof of stake subnets. um But we actually went with a different, more general design. um So I don't know if we want to talk about that. I think they were probably skipping a lot of steps. We started talking about launching new subnets and things like that.
00:41:28
Speaker
So can I interject for one second? um So this is all very well and it's all very interesting of where the funds can move and everything, but I kind of want to understand where where does this avalanche protocol come in? as ah So the avalanche, the snowflakes and the snow and everything, can you can you kind of bring that out? um So which part of that is actually what is happening there and why is this something new and cool?
00:41:53
Speaker
ah Yeah, so we've been kind of deep in the the the bowels of nitty-gritty stuff. So let's go at the very very highest of level um, so Snow, um or avalanche, uh is a kind of family of consensus protocols so consensus, uh works to basically take you know a group of validators or members of the consensus protocol and agree on a value. So what we've been talking to about this whole time is you know we have say some validator set and we are um somehow producing blocks and then we are agreeing on what the next block is from potentially multiple options. um So the consensus protocol is the thing that actually decides okay this is the next block in our blockchain
00:42:45
Speaker
And this is going to be the new state you know based off of the the execution of that block. So that's what consensus is at a high level. The key kind of things for consensus protocols, I would say, are how quickly does this process happen? So if I'm given a new block, how quickly can I say this is the block?
00:43:09
Speaker
We are not going to change it. We finalize this block. And of course, you want that to be very fast so that you know you submit a transaction and boom, it is immediately confirmed by the network. right So that this latency ends up having a very direct end user impact. So you want to minimize that as much as possible.
00:43:26
Speaker
The other thing is kind of how many participants does your consensus protocol allow? um So most consensus protocols require um some form of communication between one node and all other nodes. So most consensus protocols have this, you know, say,
00:43:49
Speaker
All to all broadcast where I take in a you know, so maybe I see the first block I broadcast everyone. Hey, I saw this block. I want to you know, accept this block and then everyone sees that and then they broadcast. OK, yeah, we're going to accept that block or you know something like that so.
00:44:06
Speaker
That kind of all to all communication, as the number of participants grows, becomes more and more expensive. So most consensus protocols are essentially limited on like the number of participants that they can have because of this this mechanism.
00:44:26
Speaker
So the SNO protocol is very different in that it does not necessarily increase in what is called message complexity as the number of nodes grows. um And the way that SNO actually does this is basically high school statistics, um to be perfectly honest,
00:44:48
Speaker
um So you know a great example is ah you polling for, say, like an election. right So you know we have an election coming up. um who Who is the you know the leading contender for like you know favorability or whatever? you know I have personally never been asked by CNN or you know whatever news agency on my opinion of you know the president or potential president or whatever But yet these news agencies say, oh, here is like, you know, the public favors this person at, you know, 52 percent or you know whatever. um And the way that they do that is by performing statistical analysis and sampling. So you have, you know, your network of and people for the election case would be you the anyone in the United States.
00:45:37
Speaker
um And they would basically take that take that set and sample randomly some people, um hopefully without any sampling bias. um It's harder in the election case, but for us, it is very easy to sample without any bias because it's a much more closed kind of system. And we can basically perform statistical analysis on who is preferring or what percentage of the network is preferring a block without actually communicating to everyone.
00:46:08
Speaker
um And by repeatedly performing that we can actually get very strong statistical guarantees that the network is all preferring some block and that allows us to finalize. So essentially rather than explicitly having every node talk to every other node, every node is performing a statistical analysis on the network to then determine if something has been finalized, and which means the message complexity is you know theoretically much smaller.
00:46:44
Speaker
Now, there's a lot of nuances into how you actually pick that like value that you are going to decide on, um because I've basically just been kind of talking in the statistical sense of like detecting that something has finalized, not necessarily how you make it get selected. um But that is at the at the high level kind of the idea behind Snow Consensus and how it can scale to significantly larger um networks than traditional consensus protocols.
Mechanics of Avalanche Consensus Process
00:47:17
Speaker
Okay, so let me let me just try to really read, we jig this, um just just so that I get a sense for for maybe how this generally works. So let's say, for the sake of the argument, we have 100 nodes, right? um And well, it could be 1000 for how sorry, but let's say we start with 100, right? So I can understand this, right? And so, essentially, so and, and, um
00:47:42
Speaker
we receive ah We receive a block, right? and Each node receives information. Somebody broadcasts the block and says, this is the new block. And now I go out as a node and I go ask 10 buddies of mine and whatever. you know I mean, not buddies, but randomly selected out of 100 and say, what do you think? And every 100 node, all of the 100 nodes do that, right? So they ask 10 buddies whether or not the block is valid.
00:48:06
Speaker
And then based on that vote, we decide, we we make an internal decision whether or not it is valid. Is that correct? And then that essentially then leads to me updating my my my chain, right? And say, okay, so I've decided this block is valid or not, and I add it or not.
00:48:24
Speaker
Is that fair to say? And so is this then a ballistic settlement thing? Or how do we think about this? um So a couple very nitpicky things, just because some people might nitpick. Validation of a block.
00:48:40
Speaker
um Is not act like consensus and I think I actually misspoke on this earlier as well consensus does not necessarily Validate a block on like whether or not it is a valid block that is able to be performed independently and prior to the consensus step so consensus is only performed over blocks that follow the rules of you know the the blockchain mechanism. what' the so suicide can united say So basically we're deciding only on on adding the block or not. Is that what it is? We are deciding which block to add. So of of potentially many blocks, potentially a single block, we need to pick one of them.
00:49:25
Speaker
So these are all valid blocks, because we've already filtered out invalid blocks at this point. We're just deciding, OK, of the set of valid blocks that I have, which of these should we accept? Stephen, if I can just interrupt and interject, because i think you're making ah ah I think you're making a simple point. So just to just see if I understand it correctly. So I think you're saying stuff like, for instance, double spending.
00:49:49
Speaker
Right. We don't need consensus to figure out whether you're whether I'm trying to double spend or not. Right. And so you're saying like any any block that is formed that includes a transaction that is spending funds that the the spender doesn't even have is automatically thrown out. It is a quote invalid block and it is not even going to enter into the consensus process. But it's possible that we could have two blocks that fully consist of valid transactions that are fully valid, where none of them where they're not sort of violating these fundamental rules, right? And then we still have to decide which one do we go with, right? And and that's the consensus process. like do we Which one do we pick? Ultimately, if we're going to have a chain, we have to pick one in each in each slot, let's say. Exactly. Yes. Yeah.
00:50:36
Speaker
so yeah so Of these potentially valid um out these blocks, um essentially the node will at first adopt the first one ACs. So originally you have no valid blocks for the the next slot, right? Because it hasn't been produced yet. And then you you end up seeing the first block. So you say, all right, well, that's the best thing I have right now. So I will initially prefer that.
00:51:06
Speaker
And then you will start the sampling process. So now I have something that is unfinalized that I want to finalize, so I will start sampling. And when the sampling process starts, that block is still going to be probably getting propagated throughout the network. um But if there is no conflict, so this is the only block that is you know possible for this slot, everyone is going to immediately adopt this block. I will see that everyone has adopted that block, and I can quickly finalize. right So the happy case is very, very simple. In the less happy case, where you have multiple blocks,
00:51:45
Speaker
You may have people that you know originally prefer block A, some people prefer block B, and there is not enough of the network that is like decided on any block that you can confirm based off of your statistical sampling. So in addition to the statistical sampling, you will always switch your preference to whatever value you think the ma majority of the network is um preferring. So to simplify this case, assume that there's at most two options. um So essentially, there's always going to be some majority value. after i produce After I perform some samples, I say, well, you know what, the network is kind of split, like say 55, 45. But I can see that you you know A has 55% of the network.
00:52:40
Speaker
B has 45% of the network, I'm going to change my vote from B to A. So I switch to the majority. And so what ends up happening is as you perform this process repeatedly, by people always trying to push towards the majority value, the network ends up becoming uniformly colored. And then you can detect that and finalize. Where are these? Where are these preliminary ballots being recorded? So for instance, let's say you were picking. Sorry, go ahead. None of this is in the block. This is not a consensus mechanism. Right, right. but But my point was that so for instance, ah maybe in the first accounting of it, half the network says up and the other half of the network says down. How do we even know this has happened?
00:53:29
Speaker
but like How do I know that you think up is the consensus and I think down is the consensus? right Because you talked about sort of revising as the iterative process, it sounds like you were describing, but how does the iteration happen? like where How do I find out that we don't all agree that it's down the way I think it is after my statistical sampling?
00:53:47
Speaker
so The statistical analysis um for like finalization says like at the probability of a hash collision, which is basically the same level of guarantees any cryptography is giving, um I know that everyone is going to be in the future in agreement with red.
00:54:11
Speaker
So we would never finalize um if the network were like a 50-50 split because your your statistical analysis is just not going to give you... Sure. No, no, no. I get that. Okay. So maybe I'm missing something else in in the mechanics of what's happening here because what I thought I understood from what you were saying was something like we're each going to try to figure out what the consensus is essentially by sampling.
00:54:38
Speaker
initially, right? So each each node each validator node is going to engage in a sampling process. Is that is that correct? Each will separately do it. that I think this is actually not, you don't need to post this, but you what do you think it is? Fahad, I think you just basically resample many times, right? But how do I know I need to resample is my question. Yeah, so and how do you know when to stop actually is the question. Yeah, okay, sure. And I think that's the same. So yeah, so you continue sampling forever until you have detected that, okay, a sufficient amount of the network
00:55:14
Speaker
is in agreement with this value. So once my p-value of the sample is sufficiently narrow, then I say, oh, OK, yes, I can finalize, and then I can stop. So prior to that, though, I just keep sampling, and I am always updating my preference to be whatever I think the majority preference is in the net. So I have an absolute threshold of the probability that we do all agree on whatever up Conditional on how much I've sampled and I keep going until I meet that threshold I actually don't pay any attention to what anybody else happens to think at any point in time Meaning I don't care about there. I don't care about their process their process of sampling I'm not concerned about I'm just looking at my process and setting it at like an insanely high threshold so that When I'm done, I'm basically confident that everybody else is gonna end up in the same place anyway
00:56:08
Speaker
Yeah, i mean you do have to condition on the process that everyone is trying to switch to the majority or the the virtuous nodes are switching to the majority because otherwise, you know, you could have it. But I don't have to know that I don't have to know what their current estimates are. Correct.
00:56:27
Speaker
Okay, ah exactly. yeah and So and so okay called just in terms of the process, so at some point, so is there a common value that everybody picks? A probability 99.9% or is this is this individually determined? ah I don't understand. Well, what do you expect? I mean, you have a probability of you know consensus, but is that is that is that common? but this So basically, this is the safety value. So like the epsilon of failure.
00:56:56
Speaker
um
00:56:59
Speaker
Technically, the nodes could change that. And that wouldn't necessarily mean that things break. But for all intents and purposes, this is a chosen parameter of the system. um so And then so when I'm done, when I believe I've reached that threshold, is there another Is that do you just say I'm done or and and and include the blog or is this just something where there's another broadcast message where you say I'm done? ah you're You're just done.
00:57:31
Speaker
um we yeah like so This is kind of the the interesting part. So within Avalanche, these blockchains can't have custom rules. um And so ah you can certainly launch a blockchain inside of the Avalanche network with a custom rule that says, and after I have noticed that this is the block that we agree on, we do some additional process um over this finalized value. um And of course, that process is now a lot easier because you don't have to agree on things. You know that everyone either currently does or eventually will agree that that is the block. So
00:58:12
Speaker
these kind of blockchains can define these kind of custom operations and people do. um But that is not necessarily like a core part of the Avalanche protocol. Okay, so and now I'm going to get a little bit nerdy here. um So if I think about this process and compare it to say, what happens in Ethereum,
00:58:39
Speaker
What really is is the main difference here? So as I recall it in Ethereum, there' is there's really a set of rules of where you have to append append the block. right It's like something to do with the heaviest wage. right um And so that's kind of a protocol rule. And if you pen try to append it to something else, then you get possibly penalized or something. Right. And so is this something you avoid that part and you just basically go, hey, this is, you know, it's a free country. You can you can pick you know something else. Or what what is this really? I would say that this is an alternative to that.
00:59:15
Speaker
which proceeds significantly faster so in ethereum blocks get produced every i believe twelve seconds or so. um I think it's like twelve and a half maybe or whatever.
00:59:28
Speaker
um It's about 12. So you know blocks get produced every 12 seconds. And then it takes, you know I think, what, a couple epochs, where I think there's, what, 32 blocks and epochs or something. At the end of the day, like I think finalization comes out to being around 12 minutes or so to like finalize the block. So everyone has kind of like participated in this this mechanism. um So they get benefits out of doing this. But the finalization time is 12 minutes.
00:59:58
Speaker
right um Block inclusion time is probably going to, on average, be, say, like six seconds or so, but um you know it goes up to 12 minutes. um In Avalanche, the block finalization time is typically around 1.2 seconds. um So you know the the the speed that this iterative process can go at is significantly faster than just kind of performing this LMD ghost, which is, I think, is like the like
01:00:29
Speaker
whatever heaviest chain basically um ah following protocol that they use. um ah Yeah, so it is just a latency game, I would say. It's just a latency. So I mean, one of the things with the with Ethereum you know process is is because you need the votes of the validators of finalization, right? um And so you kind of, so what you're saying is you do this How do I put this? I think you almost do this in sequence, but because your protocol, but but the person process is very fast, it goes fast. ah Because you don't really need to collect the vote, right? So it's sort of like a decentralized approach to the voting. Is that maybe one way to think about it? Yeah, I mean, the the reason why, you know, Ethereum's block finalization time is 12 minutes is because
01:01:18
Speaker
It requires that you know enough people have all put their signatures into blocks and those blocks are distributed to everyone in the network. So basically everyone is seeing all of these signatures and it but you know and that is you know essentially growing out. It's becoming more and more complex the number of like participants required. right um For Avalanche, in order to finalize the size of these samples, they're relatively small and you can perform these very quickly. And so that gives you very strong statistical guarantees. Whereas in Ethereum, you will have this kind of like, ah longer signature verifying process, um which will eventually perform, you know, basically, ah just give you a cryptographic verification saying this block is finalized. So and in in a sense, what what you have is essentially if ah if I'm i mean maybe maybe I'm paraphrasing this, but can I think about it as
01:02:17
Speaker
your blocks are essentially finalized the moment they enter the chain? Yeah, I mean, that it kind of depends on how you view things. So, like, you know, you could envision in Ethereum, like, I only consider a block in the chain if it has been finalized, right?
01:02:34
Speaker
you could think of it that way. um in In Avalanche, that's how typically everything is kind of considered at the user level um because it gives like you know the the acceptance time is 1.5 seconds, 1.2 seconds, so that's reasonable to like just only tell users finalized data.
01:02:55
Speaker
um So As far as a user is concerned, that is true. like as ah But in practice, there are you know a processing tree of blocks that are unfinalized that clients will be handling, very similar to other blockchains. So I have two two strands of questions. One's a simpler one, just a detailed one. So um yeah maybe I may ask that first. um When I'm doing, let's say i'm ah I'm a validating node, and I'm doing a statistical sampling thing.
01:03:24
Speaker
Let's say I reach out to you know, Andrea says another note saying like, hey, what do you think up or down, right? Is his answer dependent on ah where he like what he's seeing around him? And part of what I'm so what what I'm asking here is really about like, are the votes static or or are the Uh, yeah, I guess maybe this is not the right terminology, but are the votes static or dynamic in the sense that like, if he ends up, if he says it's up right now, and in the meantime, he's doing his sampling and he's seeing everybody saying down. If I were to ask him later, is it possible he would have said down instead of up, even if he's honest? Yes. Okay. But so, so that seems like.
01:04:00
Speaker
one difference right in the sense that like in ethereum if i'm in a tester and i didn't see the block and so i vote that the head was the previous thing um i never in fact if i try to vote again because oh no i just saw it just now now i'm gonna get slashed right but that's so that's that's only true within the same kind of like epoch or like epoch might even not be the right term but you can and you can you can attest to a chain and then later a different chain gets more weight And you know that thing gets finalized and then you switch. No, that that's that's that's that's true. But that's different, I think. right So the point is, first of all, the testers only vote once once in every epoch anyway. But even what I was really alluding to was slot by slot. So every slot, they're voting on a few different things, one of which is the head of the chain. When you were talking about LMD Ghost, that's what you were talking about. If I vote twice,
01:04:52
Speaker
if i'm a vote If I'm an eligible voter and I vote twice, I'll get slashed. It doesn't matter. So if it doesn't matter whether I was sort of correct the second time, um you're just not supposed to do that. like The idea is there is some value in effect from seeing it now posted on a block. Like, OK, great, you were on the wrong side of this thing. Tough. But if if we keep it static, there's some stability. OK, so I guess the I guess can you provide any context on the on the on the sort of point about um Given that it's possible because like, you know, there's there's a very sort of very simple law of large numbers intuition about if it really is sort of static if you know if Andreas is always going to say up and you're always going to say down or whatever and I and I and I randomly draw um a Population that I'll I guess in that case I would get eventually sort of the proportion of people who are on one side or the other ah but it seems like some of that intuition would be a little bit complicated by the fact that
01:05:50
Speaker
essentially what I'm querying people about is not something they have as a static value. It's that they themselves are um trying to figure it out. I guess it's good rule this The statistical analysis has to you know understand you know we have some potential number of Byzantine nodes.
01:06:08
Speaker
of the virtuous nodes, here is how they will be updating their preference. They're going to be following this majority. and But forget about Byzantine nodes, right? So Mike, my concern is more on the dimension of, like he's, and let's say Andreas is ah is an honest node, but he is going to, he might change his mind, honestly. And so can you talk a little bit about, about how that ah plays into the into the outcome. So yeah, essentially you can ah imagine this again in the two color example, um because all of this can be broken down into what is called binary consensus zero or one. um If you are at like um some, ah okay, let me step back.
01:06:52
Speaker
Basically, you have a percentage in which if the network is truly colored that way, so if 60% of the network is reporting red, 40% of the network is reporting blue, truly.
01:07:05
Speaker
um and you perform this sampling, you're guaranteed, based off of that, you know with your sampling parameters, that after some number of rounds, everyone's going to prefer red. right So you're so sufficiently far off that after just performing some rounds of sampling, at that level, you're guaranteed everyone performs red. just You can just basically perform but statistical analysis.
01:07:29
Speaker
But it just just to clarify, that sounds like the mental model you're thinking of is like a discrete time game, where like, okay, so we have some initial value, we each do our so our sampling, and then we sort of come up with our potentially new value, and then we repeat the process, right? and and like But but but you know one of the things that always comes up, obviously in the blockchain context is like, there's no real sense of time. And so it's usually an abstraction when we think of anything in like precise, discrete time.
01:07:57
Speaker
um But just is that the mental model that you that you were putting? across Because that I very much could see. like If you were to just do this in discrete time, then i I imagine this thing is going to converge pretty easily. i mean even Even continuously, right like if people are sampling the the majority and they're just trying to follow the majority value, whatever they think the majority is,
01:08:16
Speaker
like as people are just independently performing this, they are going to all
Avalanche vs Ethereum: Consensus and Throughput
01:08:21
Speaker
tip. like it be like It would be bizarre for them to stay the 50-50 split right because that means that like you know people are basically randomly selecting red and blue and you're never able to like bias the network far enough to like get out into this. Well, I guess the question is if they're like in different rounds. like i you know i mean This may not be like a very practical outcome, but the point is like if they get too staggered, it could always be like,
01:08:46
Speaker
you know, everybody was converging on blue and now but I'm sort of on the next round. And so yeah, I mean, at at the end of the day, because this is all random, like, it's possible for something like that to happen, right? Like, but the the probabilities decay. um And so like,
01:09:02
Speaker
I think the the analysis is something like the network is guaranteed to be like colored within a logarithmic number of rounds, tolerating the square root Byzantine adversary that is like an all-knowing adversary. right so like this there Are there any latency assumptions? Are there any latency assumptions in in the argument? This is getting very specific. um But that's actually, so just be clear, that's the concern about like different rounds.
01:09:30
Speaker
There are latency assumptions. um the i don't think like it It is not assuming that everyone is discreetly transitioning from round to round. so Can I ask another question for now? so Just to maybe bring this to a ah ah back to the higher level. um so One of the things I think that Avalanche advertises is that it has a much higher throughput compared to Ethereum. right so I think Ethereum can probably do now, what, 50 transactions a second? And you can do 5,000.
01:10:03
Speaker
Where's that number coming from? but why Why can you do more? For now, just if I may say, So you say basically you can produce or finalize a block in one and a half seconds, right? So I presume this also means that the block production time is say one and a half seconds. If you eyeball this, um if your blocks would be have the same capacity, then that just means that you can do, you know, 10 times the capacity of Ethereum and not essentially 100 times it. So what what gives? So throughput is a very interesting topic. So there is, um,
01:10:43
Speaker
various mechanisms for scaling throughput so on different subnets right so different subnets can execute stuff essentially concurrently right so these blockchains are executing stuff concurrently um So at some level, the Avalanche network is kind of processing you know kind of the the union of all these things. But it's not really like fair, right because you know you have different validator sets, and so you have different security assumptions. It's not like a one-to-one comparison. um So the actual like throughput of the holistic Avalanche network
01:11:19
Speaker
you know is kind of like maybe not a good question. um As far as the performance of a singular chain,
01:11:30
Speaker
What ends up being um very kind of performance critical and basically the the reason why um Ethereum is not ah incredibly performant, which to be clear, is the same on our C chain, right? So the C chain for us is not some high throughput chain, our contracts chain, because it's an EVM compatible chain.
01:11:54
Speaker
um So what actually really matters for throughput on an individual chain is much more the actual rules of that chain rather than the consensus mechanism. So the consensus mechanism is important because if your consensus mechanism is doing a lot of work such that it is like kind of like swamping your available resources, you can get bottlenecked there. um But once you have a sufficiently fast consensus mechanism, um the throughput bottlenecks are much more at the kind of blockchain rules
01:12:33
Speaker
portion So um what ends up being very important is optimizing things like um data dissemination, disk IO, signature verification, things like this. um Even within Ethereum, what is a transaction is not a fair comparison um because you could have a single transaction that takes up the entire gas of a block.
01:13:00
Speaker
or you could have you know a bunch of just simple payment transfers and you know as far as you theorem is concerned it takes up the same gas it's doing approximately the same amount of work but the the tps is very different um so i would say you know i could it's basically in summary it's not incredibly consensus related unless you have a not good consensus mechanism, basically. um But the the actual kind of like, and so what we call them as virtual machines for the the rules of a blockchain, um that design is actually much more important for throughput. So um the key thing that Ethereum, in my opinion, does poorly for throughput
01:13:47
Speaker
is the contracts have the ability to basically perform arbitrary and random disk reads. um And the result of those disk reads are blocking. So what ends up happening is I like perform some Sload, which is an opcode in Ethereum, load this from disk. And the EVM will you know check if it's in cache. But if it's not, it'll go read it from disk, load it, and then use that value to continue the execution.
01:14:16
Speaker
And that is incredibly slow. So basically, if you run a profile, oftentimes, especially in the malicious case, you see just you're just stuck on like discrete waiting, discrete waiting, discrete waiting. um So a big performance improvement that, you know, something like Solana has been doing um something like what we've been doing with kind of our virtual machine framework is pre-specifying state keys that you're going to be accessing. um So this pushes some complexity up to the user, which is not ideal. um But it means that you can do two things very easily. One, you can pre-fetch all of the data that you need concurrently from disk. So you're not hitting this like fetching from disk waiting, moving, fetching from disk waiting. You can just fetch everything from disk and then execute with everything.
01:15:10
Speaker
The second thing is that you can actually just naturally paralyze things based off of the state that they require. So you can execute these operations concurrently if they don't touch the same state. um So that is a those are kind of like the big kind of say CPU and like disk improvements. The bandwidth improvement um ends up becoming pretty important after you kind of have alleviated some of these things. So this is something that Solana has spent a lot of time optimizing, say, the networking stack. um I personally feel like they should actually optimize the um network model rather than their like stack. This is something that some of the newer networks are doing with SUI and Aptos, where they will basically have
01:16:00
Speaker
um People that disseminate information and then the block producer rather than taking all that information and pushing it out, will just kind of reference that already disseminated information, which basically removes the um the block producer as a bandwidth choke point. So if I can interrupt you there for one second because that was... um Very interesting and a little techy, so I'm just trying to think of if I would be trying to explain this to executives what really the difference is. as is I mean, it seems like you have a ah clever ah engineering solution which probably yeah originates from a lot of the work that Emin was doing when she was still in head of IC3, right? But if I could ask you,
01:16:43
Speaker
If you would be giving the biggest criticism of the way how you handle this from an engineering perspective, and we we hear this with Solana often, right? Because Solana notes need to be up, and and you know they can collude, not collude, they can collide in their in their ability to create consensus and all. um but What would be a criticism that people would love against the particular version and particular choices that you make in your engineering solution?
01:17:11
Speaker
and you um I mean, I don't know, I'm putting you on the spot to put a criticism against your own work, but I just like to understand it better there. But what are the trade offs that you're making, maybe? So I would say um this is a very interesting question on the kind of, say, consensus side. There are definitely trade offs going like on the throughput side.
01:17:37
Speaker
Not every blockchain should do these optimizations. um And I would actually maybe um say that most blockchains should probably do these optimizations, but blockchain should not do those optimizations and then run at like, you know, 50k TPS or something like that. um And the reason for that is because this is not necessarily sustainable for a you know fully decentralized network, right? Like, I would say from a software like engineering perspective, your code should be able to like
01:18:12
Speaker
Grow based off of the the, sorry, the performance should be able to utilize the resources that you provide it. So if if I am giving you access to more bandwidth, more disk IO, more CPU, your engineering solution should be able to take advantage of that.
01:18:31
Speaker
um I'm not saying that every blockchain should then say, okay, because of that, we're going to require every validator to run a supercomputer and like do all that. like I don't think that that is true. I do think that there should be you know high performance blockchains and like you know medium performance blockchains and that like those both have a use case for like decentralization purposes.
01:18:54
Speaker
um As far as the specific drawbacks to some of the throughput things that I mentioned, specifying state keys upfront is pretty annoying from a user perspective. It's very similar to when you submit a Uniswap transaction and it reverts because of, like say, slippage changed, um but it's actually much more restrictive than even that because now it's actually just Oh hey, the execution of my logic changed what data I needed to read to verify it, which means revert. So having like state keys get specified is a significant user facing drawback. um There are alternatives to that, um so there are people like I think Monad is probably the current example.
01:19:45
Speaker
Um, where rather than specifying state keys, they will basically like perform optimistic concurrency control. Um, and I, I would, I would say that there are drawbacks to that from a kind of theoretical Byzantine level. But wait, wait, can I just, can I just clarify here? So just contrasting C chain versus Ethereum.
01:20:06
Speaker
So they're both EVM, right? Is that? They are very similar. Right. Okay. The CG does not have these improvements. Right. Okay, exactly. Okay. So that's where I wanted to go. Because I guess um if I'm thinking about, for instance, doing all the stuff that is that that that's on Ethereum, except in the avalanche context,
01:20:28
Speaker
wouldn't that end up living on the C-chain? And so what would the relative performance be in that case? so It sounds like the X-chain doesn't sound like it's capable of handling anything like that, right? And it doesn't sound like the P-chain is the right place for it either. So yeah, I guess if I if i were doing all the same applications, and I suppose since it's c EVM, in some sense I could just like deploy exactly the same applications, and there are similarities, like Uniswap does exist and so on. Avalanche, what is the performance difference of me essentially spinning up the Ethereum chain as the C-chain?
01:20:57
Speaker
Like, what meaning the activity that's on there? the the the only The only real difference is the consensus mechanism. So the at the end of the day, the latencies will be lower for finalization on something like the C-chain. So what's the order of magnitude we're talking about there, then? Well, the Ethereum mainnet finalizes in 12 minutes. C-chain finalizes in 1.2 seconds. So that's the... that's the but so the one point So the thing is, the 1.2 still OK, so then then I'm missing something about like when you were when you I thought you were saying that ah somehow the the the choke point, the critical factor for getting the speed was not so much the consensus mechanism, but rather
01:21:41
Speaker
ah the the smart contract logic like associated with a virtual machine. there's two There's two measurements. One is latency, the other is throughput. so Basically, how quickly can I submit a transaction versus how many transactions can I submit? Consensus is very important for how quickly I can submit a transaction. Throughput is much more depending on your virtual machine, which is yeah know how many transactions can this can this you know blockchain support per second.
01:22:09
Speaker
um so So from a consensus perspective, it is very critical for latency. It is less critical on the throughput side. The the virtual machine is very critical on throughput side. It is less critical on the latency side. They both do still impact the other, but they are kind of separated. Okay. So so i'm I'm kind of missing something. So because you're saying like, okay, we can send a lot more transactions. We can more quickly send transactions into the Avalanche network, but it may not result in materially higher throughput. And is so, yeah, um but I'm trying to understand the the the two pieces you're saying. right because if i understand If I'm literally sort of restating what you said, I think, just now, you're saying, I can send transactions faster. Yeah, the stereotypical example here is a highway. right So a highway travels at some speed. So if you increase the speed limit, your your latency is getting better. right So you want it as high of a speed limit as possible. And then the number of lanes in the highway is your throughput.
01:23:08
Speaker
right so like Basically, like the the consensus mechanism makes the speed limit higher. But the in order to like make the the road wider, you actually have to like make improvements on the virtual machine level. So the C-chain, because it's running the Ethereum virtual machine, it is not really scaling out throughput.
01:23:27
Speaker
it's just making the speed limit higher. So like that that's the the the typical kind of example. um I'm not exactly following, because i is what you're you're an a so but so so when we talk about throughput in the context of the blockchain, you're talking about some some normalized measure of TPS, right? Because to your point, like transactions are not all the same, but we can sort of normalize ah is some level of gas, whatever. um But that's throughput, right? So you're saying that the C chain will have similar throughput as ethereum because they're both EVM, right? So the part that I'm struggling with is. If I yeah, OK, so then then your analogy to speed limit. So what is the speed limit then in the in this context? Like if I submit a transaction to the C chain, so I've been talking about finalization time, you it's probably going to take like ah you know some mempool time, whatever couple seconds to get accepted onto the C chain finalized. It will not revert, right?
01:24:26
Speaker
um on ethereum it's going to take a couple of seconds to get included into a block but that block can still get forked out so so's there's a related good question but which i will leave to the side for a moment but um okay i think i think the notion of finalization we're talking about the theorem is actually not that helpful right now but partially because you know it's i mean they for instance could have 30 slots in a in an epoch instead of 32 or you know i mean it's like the even in practice i'm not necessarily sure people Will wait you know to epochs in something where they care about time right so like the point that that that's in some sense exactly the point of like lmd ghost right which is that even if you killed a finality gadget lately you know as you know like bitcoin has probabilistic finality which is essentially what lmd ghost does right so i'm not sure the twelve minute i take your point about it like.
01:25:15
Speaker
But in some sense, it's not really, I think, the comparative number we should be using. um Like, for instance, that number for Bitcoin is effectively infinity um because you never have that that notion that that level of finalization. right um So maybe let's put that to the side. But I'm still trying to understand then. So I think I get your point about like the time from which I send the transaction to the network to which it shows up on a block. Is that sort of how I can think about Well, okay, because then then then I guess on Ethereum, that's not that's still going to be longer. It's so it's going to take longer than than a second and a half.
01:25:50
Speaker
like kind of i kind of use the This is totally a centralized, not a fair measurement at all, but it's just you know something that is actually pretty reasonable, I think, is like the the number the amount of time it takes to deposit into Coinbase or whatever exchange. right could can can we stick with I think the part that I'm struggling with is like the actual concrete detail. right so like If we could put the analogies aside, it sounds like you were you were talking about the time from which I formed the transaction to the point it actually ends up on a block.
01:26:22
Speaker
Is that, am I misunderstanding like the one and a half seconds on the Avalanche site? Is that what we're talking about there? or So the 1.2 seconds metric that I was talking about is the time that it takes from a block being produced to a block being finalized. That is separate Of course, from the time that it takes from a user submitting a transaction to that being included in a block, um that depends on a number of things. It can depend on, you know are they paying a sufficient fee, so on and so forth. um It is typically on the order of a maybe second, couple of seconds, um just for like basically going from the user to, say, some node in the network to some validator
01:27:10
Speaker
gossiped around. So theres there's operations that happen there prior to getting included into a block. um Once the block is produced, that is not necessarily guaranteed that it is final. You then have to go through consensus. um So the full end-to-end time for a user transaction from users signing it and submitting it to the network and finalization is probably a few seconds.
01:27:36
Speaker
um No, they like the mempool time is not going to be substantially different than um like getting into the mempool is not going to be substantially different than Ethereum. The time to get included into a block is going to primarily just be based off of block time. So the C chain is two second block time. Ethereum is 12 seconds. So that is, you know.
01:28:02
Speaker
ah Yeah, but again, like, these are like, I think, actually I think you did actually in a finance sense, I think the the final part is, is not unimportant, right? So, I mean, you know, if a heart and I, if I have to buy coffee at a coffee shop, right, um you know, it's just low stakes. And, you know, the final, the finality is not a problem, let's say, right, give or take.
01:28:26
Speaker
But if i have a if I want to run, let's say, a ah trading platform for government bonds right where each transaction is worth $7 million dollars and you know having finality and having finality fast, and it's a fast throughput, try of you know it requires a reasonably quick ah reaction time and all that, then I think this would make a difference. right I think we can say that probably. right Or if we think of bank transfers, we have to run a bank transfer of some form. You know you don't want to sit there and wait for 12, 15 minutes until something is finalized. right So is that that's kind of, I think, maybe the the case where this really matters? I think this is why I brought up Coinbase. When is my transfer into Coinbase accepted by Coinbase? And I can actually use the fund. right
01:29:17
Speaker
So now I'm gonna go back take my executive head on right and say okay so you just told me something which is really off putting which is it's really hard on the user right so it's like you know I run something I want to run an application maybe I use your blockchain and I have to be something that's hard on the user that's that's really something I don't want to have at any cost.
01:29:36
Speaker
Right. So I want my users to be, you know, I want the user experience to be great. I want to have it on their phone. I want them to be able to do stuff with their phone. What are you talking about here? What what does that really mean when you say the user it's it's puts pressure on them? So this is a very good question.
01:29:54
Speaker
Blockchains have many types of users.
Developers and Blockchain Applications
01:29:57
Speaker
So there is the user of a blockchain for me is actually typically the developer of a decentralized application. That's actually the user of a blockchain, like from like the blockchain's perspective. Then you have the users of that decentralized application, right?
01:30:16
Speaker
that are accessing it on their phone and sending stuff around. right So each of these different software stacks, depending on how deep down technically you get, your users are actually just
Solana vs Ethereum Development Complexity
01:30:28
Speaker
still developers. right um So Solana has this state key you know specification mechanism as well. right So this is not necessarily you know something that is new throughout the the ecosystem.
01:30:43
Speaker
um And i would I would say that it is not as easy to develop a application on Solana as it is to develop an application on Ethereum, both from a tooling perspective, but also just like literally the virtual machines are more complex or the virtual machine is maybe more restrictive in the Solana case than Ethereum's virtual machine.
Development Trade-offs: Language and Tools
01:31:05
Speaker
um So.
01:31:09
Speaker
it It does not necessarily impact the final end user, um but it changes the um blockchain developer experience. So if you want something that is like you know super easy and flexible to use, um you know you might not be able to get the the best performance um possible. right And this is this is kind of a trade off that most developers are probably pretty used to. right like um If I wanted to like write a super quick project, like I might do it in you know Python and just you know whip something up.
Avalanche Mainnet and Snow Protocols
01:31:48
Speaker
But if I wanted to actually like optimize something to a very like performant level, I probably wouldn't be like implementing this in in Python. Python might not be a great example because a lot of Python libraries are actually implemented in C++ plus plus under the hood. So you know for like machine learning things, it is still very performant. But you know if I'm building something from scratch in Python, it's going to be slow. If I'm building something from scratch in like Rust or C or C++, plus plus I have the ability to make it fast, right? So these are very different kind of UX things, and you know it becomes a very complex trade-off space, I would say. But at the end user, you could still like have no idea, oh, I'm talking to a Python or a like C++ plus plus server on the backend, similarly to your blockchains.
01:32:38
Speaker
it just depends on how you have to develop those
Avalanche's Unique Blockchain Components
01:32:41
Speaker
applications. So it it becomes a very complex trade-off space. Okay, so now I think, I mean, unless Fahad wants to chime in one more time, I think i think i we have a very good sense now of of how the mainnet works on Avalanche and and and you know what the but the advantage is, how the consensus plays in, and particularly how the snow and Avalanche has come in, right? So I hope that we can get this right for the audience. i think if i i mean let me Let me do this. Let me try to recap it. right so In many ways, there is there is a lot of similarities to other blockchains. You have, very you have let's say, different versions of it, and I'm paraphrasing. I'm sorry, if I get this wrong, you have different versions. Some of them are ah really quite quick. right so For simple payments and you have others that are, this is the C-chain, which is does smart contracts, which is just what it
Subnets in Avalanche vs Ethereum's L2 Solutions
01:33:30
Speaker
is. It takes some more time to ah to run through because you need to understand
01:33:34
Speaker
You need a lot of data for the state to get the transactions properly or to get the process properly. And then you have a process which reaches finality quite quickly, which is a clever process in terms of how you communicate blocks throughout the ecosystem right or through the system of validators, if you want. So I'm i'm paraphrasing, um but i'm I'm just trying to get a good sense of for the for the audience of of what really is the key components of of Avalanche here.
01:34:03
Speaker
Now, the one thing i will I want to ask is, ah so we've we've talked a lot about subnets at some early stage where I actually rudely interrupted everybody. um So can we maybe just...
01:34:15
Speaker
briefly come back to that and and maybe keep it at a level which is sufficiently digestible for you know the the less informed audience. So so let's put it like this. In Ethereum, there's a lot of talk about their scaling solutions, which are layer two solutions. right You basically have a sequencer that runs a roll-up. And then depending on the on the type of roll-up, they post data at regular intervals so that you know the roll-up, the mainnet basically can check um what is happening in the roll-up that people who use the roll-up have certainty about execution and and validity of what they do. um But that essentially is the scaling solution that you can come compress activities ah from a roll-up into you know single transactions if you want. So can I think of your subnets as something that is similar to that or is there something deeper to it that is that that I have not yet understood?
01:35:12
Speaker
there are um some notable differences. So, yeah Ethereum's goal with layer twos is to scale out the kind of execution capacity of the Ethereum network without um taking on any significant security assumptions,
Communication and Operations of Subnets
01:35:33
Speaker
right? So, the layer twos should is inherit the security of the layer one, is what they they want, right?
01:35:39
Speaker
um That is generally true of you know these smart contract enabled chains. So someone could launch a layer two of the C chain if they so wanted to. That is you know something that is totally possible. um So like you know you could implement the same smart contract that you have on you know Ethereum to set up a layer two and and do things like that. um So basically, I think of Layer 2 as a mechanism of trying to scale out a single blockchain, specifically the execution capacity of a single blockchain. um Subnets are different in that they are not trying to inherit the security of a another chain. They are, um for all intents and purposes, their own chain.
01:36:31
Speaker
um But they are tied together with communication like some messaging protocol. And that messaging protocol is set up to enable easy messages you know notifications from one chain to another. So for instance, I think I tried to um you know talk about, like say, Ethereum to Solana Bridge.
01:36:56
Speaker
um That bridge does not you know have any relation to the security of Ethereum and Solana that is you know dependent on whoever the people custody of those tokens are. right In Avalanche, the way that you would implement a bridge is not with a third party, but with validator sets attesting to events that happened and sending those attestations to other chains. Now,
01:37:26
Speaker
The reason why that is possible is because that other chain can know the validator set because the validator set is registered. Can I maybe bring this instead of thinking about it as different chains, can I bring this to my world of finance? um So can I think of I mean maybe this is not entirely the best analogy But just think about it as you have two different banks They can run a subnet of some form or use a subnet of some form where they keep accounts Let's say right for for the customers and then if you want to do transfers between the between the two rights we can so so sort of like the the that the avalanche protocol
Bridging and Security in Avalanche
01:38:08
Speaker
would be a
01:38:09
Speaker
the party or would we be able to do the transfer seamlessly between the two? Yeah, so rather than having like, you know, you have say, Ethereum, you deposit into some bridge contract, and then that bridge ah person will then sign some message on Solana saying, hey, this person deposited on Ethereum, trust me, bro, um, which is basically how like these, these bridges typically work. Um, you would actually have, you know, basically a deposit into a smart contract on say this avalanche C chain. And then the avalanche C chain will be willing to sign what is called a warp message, but whatever. It's a cross chain message to basically attest to say, Hey, this event happened.
Financial Sector's View on Public Blockchains
01:38:54
Speaker
And then you can pass that message to this other subnet and they are able to then verify, oh, yes, this did occur according to this validator set. And so then they credit you know this this deposit on their chain without introducing an intermediate. I mean, this is kind of really quite exciting in a way, but because if you take the perspective again of the financial sector, right?
01:39:20
Speaker
So there is a certain resistance to using a blockchain to begin to begin with, right? So something like a public blockchain, um ah like Ethereum for for various reasons, so there's the slowness component and all that. But I think, you know, when you have and and also in particular in the CBDC space, right, where there's there's long discussions of how you could optimally introduce a CBDC, you know, essentially, I think the the consensus is that central banks themselves will not want to run the network itself.
01:39:48
Speaker
But you can imagine a world in which you use a CBDC, you know, sort of like an architecture, underlying architecture, which is maintained in via multiple subnets, which would be, you know, again, you know, in some form or another, I think, of course, of banks that they're, you know, this is not the perfect analogy, but we can maybe think about something along those lines there.
Customizable Subnets for Regulated Environments
01:40:11
Speaker
And but we need to still cross applications and and things that are being done.
01:40:16
Speaker
on on on sort of like confined spaces right and and that's something which you can accomplish with subnets is that a fair depiction yeah absolutely so a big um thing that people are really excited to use subnets for is places that have like specific regulatory restrictions. right so Say, hey, I um yeah i think I used the example of like you know whatever, OFAC restrictions. right like If a bank is trying to perform operations and put them on chain, like if someone gets added to the OFAC list, they need to be able to halt like any operations that happen there. so If this company is running the subnet,
01:40:59
Speaker
Then they can basically encode the rules of their blockchain. They can encode whatever rules they want. And so they could essentially say, hey, this person is not allowed to issue transactions. you know So you could basically put up a blockchain that is explicitly allowing some like centralized entity to censor like operations. right That could be encoded into this blockchain's rules.
01:41:22
Speaker
And then that blockchain can still then send messages out to this wider ecosystem. So people can say, Hey, you know what, this, um, you know, random, I don't know, big bank, whatever but Wells Fargo, I don't know, um, sends out this like random message that says, Hey, like this person, you know, deposited into here and whatever. And, you know, say some other subnet could pick that up and say, Oh, okay, because of that, I'm going to do some other operation. So,
01:41:51
Speaker
it It allows this kind of custom rules that wouldn't be possible generally in a fully kind of permissionless ecosystem.
Subnets' Flexibility in Crypto and Regulatory Environments
01:42:01
Speaker
But these fully permissionless ecosystems, the reason why they I think they haven't gained a lot of traction um with companies is because they're too permissionless. like They don't fit within the regulatory bounds that these companies have to live in on a day-to-day basis.
01:42:16
Speaker
um And also oftentimes you have this situation where, you know, even if the regulatory concern isn't founded, you know, the the company will say, listen, we don't actually know.
01:42:27
Speaker
And this is an exploratory endeavor. And we don't want to get heat like legal heat for this exploratory endeavor. So we're just not even going to consider it. right So even if the argument is, oh, well, no, this permissionless chain, this isn't actually like against the regulatory like you know whatever, like that can be enough just to spook people off, whether it's well-founded or not. um And so these these subnets kind of are are really trying to like set up this kind of space where people can really define these like custom rules that you know traditional blockchain people might not think are like good rules, but in reality, these are the rules that people have to
Subnets in the Gaming Industry
01:43:06
Speaker
follow. It seems to me that subnets, they also have some value for people who you know do come from the typical crypto community who aren't necessarily in those things that you were describing. And so let me let me see if this makes sense.
01:43:18
Speaker
um So, for instance, there's a, as economists, we refer to this positive externality associated with the fact that, you know, sometimes my application benefits from somebody other, some other applications being on the same blockchain.
01:43:29
Speaker
But there's also a negative externality from the perspective that we're all competing for the same block space. And so if all the applications are on exactly the same chain, I get some value out of the stuff being there. But I also potentially lose a lot of value from the fact that I got to have all my, in fact, my users have to compete for essentially activity on that space. And one way to solve for this is, yeah, they're on like different chains, but then interoperability becomes an issue, right? Like,
01:43:55
Speaker
theres There's some complication associated with bridging across different actual blockchains. But your P-chain, I i guess, is kind of solving for this in part. right like You're you' making the interoperability across chains much more seamless because there is sort of a coordination. There there is something that sort of is across all these things. right um Does that also kind of comport with your with your vision of subnets? Because it seems to me that even if I were like completely in the in the depths of the crypto community and wasn't interested in you know in in in smoothing edges for regulators and so on, I could still see a lot of value of the potentially essentially having my own chain where I don't have to compete for block space and then using this interoperability whenever I need to to sort of interact with other applications.
01:44:40
Speaker
Yeah, this is the big um this is why a lot of like say gaming like blockchain gaming um people are very interested in launching on Avalanche is because of that kind of blocks
Scaling Solutions: L2s and Subnets
01:44:51
Speaker
-based separation. you know So ah there are, of course, trade-offs that come to this. right So like if you are launching your own blockchain, like you're not going to necessarily be inheriting the security of the Avalanche primary network. right But for a lot of games, that's kind of fine. What they probably want is more like verifiability and like um things like that, observability more than like like security of them running it. Because at the end of the day, a lot of these games are centralized. right They define the rules of like, hey, now we have this new like expansion pack, or now we have this new thing. And they kind of just change the the rules of the game on a whim. right
01:45:30
Speaker
um So a lot of games are very interested for those kind of scalability of reasons for sure. Oh yeah, the the last the last thing I wanted to touch on is the composability thing. And ah and then and maybe we can wrap up, but you kind of touched on it. is ah So there's basically atomic composability, which is basically, you know, I have a single transaction and it is like touching all these different things and then it can like you know basically perform operations based on the state of other things. That is kind of the the main reason that you want to like have things boxed within a chain. So that's something that, you know, Ethereum L1 does like very well. You have this atomic composability across things.
01:46:09
Speaker
um As soon as you start like trying to do any of these kind of scaling mechanisms, whether it be L2s or subnets, um the interaction pattern ends up getting more more complex and typically is not necessarily atomic. um so For us with warp messaging, you could have a single transaction that says, hey sign this transaction on subnet A that is going to issue you know some transaction on subnet B that will then send another transaction to subnet C. And those are all happening on hops rather than atomically.
01:46:43
Speaker
um So there there are like some subtle like
Challenges of Atomic Composability
01:46:47
Speaker
differences there. um It's kind of similar to like if you deposit first on the L1 and then you get your tokens on the L2 to then like perform some operation. um So there there are a lot of similarities, but you kind of do lose that atomic composability that people do really like. Interesting. It's time to try to break the laws of physics in a way though, right?
01:47:07
Speaker
You can be only at one location at the same time, right? Because that's kind of what you need for atomic stuff. Stuff has to happen really at the same time at at various different locations if you want, aka subnets, right? So that's tricky part.
01:47:19
Speaker
You have to either like have some like kind of global consensus mechanism or some like ah some like freezing of like things and it introduces a lot of complexity.
Conclusion and Gratitude
01:47:30
Speaker
so yeah but Sounds very exciting. um ah so i'm I'm very grateful for for the time that you spent with us. I actually learned a lot more about about Avalanche here that I knew before. Shame on me, but it is just what it is. um so and I hope our listeners also benefited greatly from from this really deep dive and sometimes this very nerdy discussion about some aspects of the protocol, but I hope it was useful for most people.
01:47:53
Speaker
It's a little bit more than you know i like a five-minute YouTube video probably. right um but you know For anybody who waited here for this long, so thank you for your time and thanks for listening to us. Steven, thanks so much again for for for sitting down with us and explaining this in so much detail to us. I really appreciate it. Thank you. All right. Okay. Thanks listeners and ah see you next time.
01:48:18
Speaker
We hope you enjoyed this podcast. Thank you for listening. As a reminder, you can find additional materials on OWLExplains.com and can stay updated by following us on social media. That's all for today.