Scaling Avalanche with Subnets and Specialized VMs with Patrick O’Grady | a16z crypto research talks

Transcript

so welcome everyone to this week's uh a16c crypto research seminar very um lucky that today we have joining us Patrick O'Grady who's the head of engineering at Avalanche uh which is the sort of organization behind the Avalanche blockchain and uh Patrick's going to give us an update about uh you know kind of all the cool stuff that they're up to over over there so Patrick the floor is yours thanks Tim I appreciate the invitation to come and chat with you guys you know I watched a few of these conversations online though they were super well done so you know happy to participate you know uh today I'm going to talk to you about scaling Avalanche with subnets uh you know I saw it on our marketing my

comms team built this logo and I love the like neoni feel it's I use it everywhere now but uh the goal of this conversation is you know to talk about Avalanche like first of all Avalanche consensus what is it how does it work why is it a little different than how other people do stuff and then Avalanche is the network so how is Avalanche the network structured uh I think a lot of people may have heard about uh subnets subnets and how they compare to like zones pair chains l2s you know the elk like the full L1 scaling story and so talking about what they are and what you can build on them and then talking about where we're going with it so what the particular architecture allows us to do and and how we think that that really positions Avalanche well for the multitude world that I

think we feel strongly is is the next step here um the way I've structured this talk is you know I have tons of slides of random images pictures diagrams and everything like that feel free to interrupt me at any point to ask a clarifying question you know I think some of these topics are pretty nuanced but I think this room is fairly you know well researched on these things so uh please stop me if I say if you're confused by anything that I say um so yeah first off I'm Patrick O'Grady I'm the head of engineering here at Ava Labs I've gotten a lot of awesome experience about how people think about blockchain use blockchain develop on blockchain and so I think it's been a lot of fun I think a lot of it is definitely supported by some of the stuff you guys see with different uh

different people in your communities and stuff although I may write the tweets for a lot of the stuff we do I stand a very talented Team stand behind me you know I just want to give a shout out to them before we uh before we get going here um so yeah so first off we'll start off with what is Avalanche uh the consensus uh story so um the way you should think about Avalanche is it's kind of a it's it it describes two different things so one is the consensus protocol that came out in 2018 and then another one is the network that's actually built around the consensus which shares the same name um so I'm not going to go too deep into the other consensus uh kind of stories within our brief history of consensus

research I don't need to you know provide much context there I think for this group but I will dive deeply into the Avalanche side of it so you know as we think about our brief history of consensus research you know you have the Quorum based protocols that many projects use for bft you know a lot of stuff powering paxis and different sort of distributed systems research coming out of the 70s 80s 90s and you know I think that was very commonly used within permissions networks particularly for like crashful tolerance systems taxes is one of those and then you know never really used widely in a permissionless or like adversarial context um you know Nakamoto comes along 2009 longest chain idea brilliant Bitcoin awesome stuff um people start to revisit the original

voting based classical protocols uh as people move to this proof of stake transition um in 2018 a paper uh called Avalanche drops from a group called Team Rocket um and they propose a radically different approach to how consensus should be achieved instead of doing uh you know knowing your consensus Set uh doing like a deterministic process instead let's do repeated sub sampling of the network to achieve fast and scalable consensus um and so the way that this works or the big idea is that let's just say you know you have a I have a really cool like uh demo that I'll run showing this live

which will be I think kind of connect the dots after I explain a bit but as you know with in a consensus uh situation the whole goal is to basically propose is not to pick a particular color but just ensure all the honest notes pick the same color um so let's just say we have blue and orange um and so in avalanche the way that this works is let's say that you're the red node here you'll basically sub sample some set of K nodes by stake weight so in this in the main net this defaults to 20 or so people um if you get Alpha so that would be let's on the main nut that defaults to 15 of those 20 agree on a particular color

you then consider that pole or that round of the pull successful and then if you get you know beta and I'll I'll show this kind of in writing after this uh in a row polls then you accept and so the idea is very straightforward where it says okay we have this room let's say you have a thousand participants um I want to try and run Avalanche consensus so what I'm going to do is I'll pick 20 of random people in this in this huge room ask them what they think if they think you know a 15 of those or the majority of people or super majority of people it's all parameterizable based on who's running the consensus uh I'd say the same thing I can have some

notion that the network is starting to tip in a given Direction and then if I get so many in a row of that certain majority that I specify in my node I can be with very high probability say that the rest of the network will eventually agree on that and so the magic with Avalanche or the Breakthrough of the idea is that if you do this it actually works I guess it's the crazy idea with the repeated sub sampling um and so in some sense uh you may Wonder like okay you know you're doing all these samples you have to do 15 in a row that seems like a lot why isn't it really slow or like why uh you know why is it able to even perform as fast as it does typically finality on the main net

is between the order of 500 milliseconds to 1500 milliseconds across 1300 nodes well a few tricks uh first of all you can pipeline these votes together so you can like accrue confidence across multiple blocks for like a single chain of things second you can perform multiple queries at once so like you can let's say if you have 15 polls you can do like let's say four five six seven polls at once and then as long as you process them in order you're still guaranteed to have the same properties um and then lastly uh you know when there's no conflicting proposals for blocks or anything like that which is typically the case that usually only means you know like let's say 20 people you're asking 15 times is only like 300 round trips with no meter so compared to

like a traditional uh or other protocols that may be like an N squared sort of thing there's no hot path on a particular leader that collects votes there's no like uh fancy signature stuff that seemed to be done so you can have these really fast round trips that are basically just like HTTP requests uh going across uh already existing Channel between different nodes that's already like a mutually authenticated TLS connection um so that's just the overview of like kind of what uh the ideas and now I'll break out uh into kind of the steps that actually make up this protocol so you can understand I think a bit more of how we actually get to this this final step before I do that I'm happy to pause if there's any questions and if there's

anything that's clarifying there before I go into maybe more of the composition of the algorithm and then I'll show a demonstration of how this actually looks or like what the intuition is behind it cool um so the way that you should think about avalanches it's actually layers of simpler algorithms stacked up and what we call this is the snow family of consensus so the snow family of consensus is uh basically broken up into three constituent layers which is slush snowflake snowball and then Avalanche is built on top um so slush is the simplest one slush is just this crash fault tolerant algorithm

that says okay you know you're writing consensus you're going to default to the first color you hear about is your preference so you know someone gossips you a block and it's let's say the simple case with the coloring like blue um you know you'll pull uh the network for some Alpha uh so like for some uh parameter M time and then uh you know after M time no matter what you'll just stop and so you know basa if you get a priority uh Alpha k for One Direction you'll switch your color very simple so this is like the first step right we're like okay you know you could probably game this it's not uh it's not Byzantine fault tolerant resistant at all but if the network is

you know working together over some period of M time you can have some idea that great like eventually will probably align the same color based on the polling and based on what you hear about which is with random perturbations in the network especially if the network starts tilted uh to one side once you have slush the idea is okay well how can we change this notion of like counting or confidence of the node to give slightly more guarantees or maybe a few more guarantees and so then that comes with Snowflake and so uh before I continue I'll say that all of these are in the Avalanche consensus paper so if you are curious like you want to read it more long form uh you know I'll share that

link afterwards and you can take a look at it it's a pretty short paper so it's if you're curious to learn more um but the idea with snowflake is let's add a counter that captures the strength of our conviction basically so instead of just like saying okay if if I do another coal of alpha like Alpha divided by K and it changes my uh perspective um you know let's also keep track of how many consecutive pulls of alpha divided by K have yielded the same color and so that instead of after going for like M amount of time instead I say okay after I receive like beta or what we call beta consecutive then I'll stop so it adds this notion of instead of

time having some sort of accrued confidence based on the observation a node's observation of the network and so still we do the same thing though if the color changes so uh you know like if I do alpha K and I'm going orange orange orange and then it changes and I see a pull for blue um I'll reset my counter and start over so I'm still flopping all over the place but I have a little bit better idea of of what it means to actually accept the last week is what we call snowball snowball adds confidence to the preference change so instead of changing the color if you get another pull

um and a different color instead what you do is you only change your color based on your total accrued confidence so instead of saying okay you know I performed Alpha over K I saw a different color I'm going to change right away but what if I've already seen like 25 pulls in a row of orange should I be changing my preference to Blue uh no you should keep it as orange because it's likely that you know you got a small perturbation the network or you know it just so this confidence basically adds one more layer to this process and then upon that both Avalanche and then the linear chain mechanism for Avalanche called snowman are built so

now I'll pause for a second show you a really cool video and then I'll go over it again because I think you'll understand a little bit more of the intuition behind it so uh Avalanche very simply let's say you have this group this big grid of uh blue and orange every node running the same protocol here they all start querying each other and over time you know randomly the whole network will shift either orange or blue just based on the random polling uh of the network and so uh there's uh a demo that one of the co-founders of the company Ted Yin made which I stare at for hours uh a day sometimes when I'm

just doing these demonstrations because it's so fun um and so you can basically tune any of these parameters to see how the network changes as it pulls and this is all using snowball so the last basically most mature part of that consensus family so in this case the simple demonstration let's just say that we have 20 squared nodes and then we're doing this repeated so sampling with k um 10 and Alpha 8. so if I do a poll as a particular node and eight out of ten of those respond the same color I will continue I will basically say that's my color and then I'll count that as a successful poll if I get beta have those in a row with so let's say 15 then I'll

have very high confidence in basically finalize in this demonstration we don't actually ever finalize we just have continuously increasing confidence just to kind of show you how this works and so in this case I'll slow down the simulation a bit I think by default it runs really really fast so you can see all started off so on the bottom you'll see that this is the number of polls that are being performed and then in the diagram you can see that as the color gets darker it's the proportion of the Network that has a deep confidence about one of the colors so you can see at the beginning you know some people shift light blue and then they may have developed you know some sort of counter preference in in One

Direction but then eventually uh they demonstrate their color as uh the other as they see more consecutive pulls and generally more just successful pulls of the other color and eventually they come to uh you know one conclusion now you can really tweak this and see how it behaves on their very different circumstances like oh does it go faster if you have a larger K does uh like when you start to tweak like some of the different parameters like Alpha you start to change the safety parameters of the algorithm so let's just say for example right you had a you know let's say you were pulling 20 like let's say you had a your your poll is defined as 20 randomly 20 random people and then if you get you know 11

of them you say was successful well you may very quickly just buy random chance uh stumble upon a run uh that will give you uh you know maybe finality in the wrong direction um and so you have to think about uh you know how to tune these parameters in a way that's safe but also uh gets you the performance guarantees you need and so I was talking to Tim about this right before the presentation started was uh we had some research come out uh last week from the from Chris Chris Christian's group about a safety analysis of a lot of these protocols um they actually found a bug in the original Avalanche consensus paper which uh was a great find and you know appreciate their research and the

Avalanche protocol or as implemented uh was aware of this problem and also addressed in a different way but you know we've been sponsoring more research into this consensus algorithm for suggestions of how to improve its performance or just kind of more formal analysis of its safety guarantees because it's uh very different to analyze in some ways than some of the other protocols which are maybe more deterministic um but uh it's fun to at least visualize I can guarantee you that much Patrick a quick question so when the nodes are pulling each other do they only share their color do they also share their confidence they do not currently share their confidence they actually don't share

their color when asking someone else either so the way it will work is you basically say hey uh you know node a what is your preference given this uh chain and then it will respond back to you uh with its tip or like of that chain itself but we don't respond with confidence people have discussed that but you end up as you may imagine into a very interesting and weird Byzantine world where it's like all right like if I'm starting to tweak my confidence based on everyone else's confidence it's like a whole nother layer of uh what it means to actually be finalized

um would be maximally confident all the time when it responds yeah exactly or like or to some people it would say like try to keep them as close as possible like 50 50 and say like oh I'm not confident about anything and then a whole nother group it would try to convince on different sides in a different color like very interesting games I think that you could probably use it if you figured out a way to do it uh systematically to improve maybe the liveness characteristics of the network um but uh it raises very interesting questions around safety also um just like full notes immediately attached to it or like any node

uniformly agenda in the network gets involved so it's it's stake weighted so Avalanche itself is a very network network heavy protocol so it's a very uh I think compared to other networks that describe it as pretty fully connected most nodes are connected to other nodes and so they have uh basically your node ID or your node certificate is like in a way a hash of your TLS cert and so when you make when you make a connection to someone you can very quickly authenticate who they are um and then when you're doing the polling process based on uh basically the consensus set you just randomly sample based on Stick weight so let's say you have 1300 nodes you

know I'll sample with replacement the top 20 and every node will sample different groups just because they have different random seeds um but yeah it's uh you can keep resetting this and you know sometimes it'll go Blue sometimes it'll go orange sometimes it'll stay longer kind of in the middle and we see all these things on the network I think the thing to think about uh and kind of the thing I I don't have a slide here for which I wish I added is uh you know in the paper it talks about that the liveness uh in the worst case is reduced to square root n when there's square root n adversaries uh liveness starts to degrade

um and that only is really in the case where you have dualing proposals and so in many cases uh with the way that most of the chains on Avalanche work you very very rarely actually have blue and orange to vote on you typically just have blue in which case it looks more like a crash fault tolerant kind of performance mechanism for aliveness rather than uh Byzantine because the block itself encodes the basically the producer signature and there's like this kind of like allowed or soft producer list for some period of time um that makes it really quick I guess in a sense so I think originally a lot of the ideas were you know fully leaderless and then what we saw was that under

certain conditions a lot of like uh people tried to game the networking layer to uh for Mev or uh you know some sort of benefit on chain so when when we started to look at snowman plus plus which was the mechanism we used to reduce contention on the network that dramatically improved consensus performance as well across the network in terms of reducing finality and also reducing the number of rejected blocks so Patrick you alluded to this leader list versus not distinction so yeah maybe you could say a little bit more about that so uh and snowman plus plus so they're kind of like time slots and

like a designated black proposer like how does that work yeah so um that's fine too but yeah yeah so I'll do this I'll cover this now and then I'll get maybe more into some more of the network architecture uh and then we'll I'll make sure to leave some time at the end so that we can dive into all sorts of interesting nuances of both that and the consensus mechanism um and so um yeah so when Avalanche first came out um you know it's composed actually this is a great segue uh into uh explaining some of the different topologies of the network so when Avalanche first came out it's it's uh basically uh one network with three chains at least at the heart of it um one of those chains the X chain is a

dag um which has no leader so you know uh validators produce uh vertices those vertices can be improved by anyone and they're kind of confirmed independently you only have an issue if two vertices both rely on the same utxo um or someone is you know proposing a transaction that double spends uh you're never getting you're not going to guarantee that that's going to finalize but uh in the case of uh leaderless production that originally also applied fully to the teaching of the sea chain which are linear chains right and so early on uh when there was uh you know less traffic on the network it wasn't really an issue there was no mempool so

people just produce blocks uh when needed and then they were gossiped through the network work and voted on using the consensus mechanisms I talked about before but when the sea chain took off and there was a lot more activity so the c-tune is our evm based blockchain when that took off there was a lot of D5 activity and a lot of incentive to try and get your block or transaction before others people started to play games on the networking layer to take advantage of that and so as a result that caused the rejection rate of blocks to go up in many cases also increase the time to finality from like the 500 to 2 second range from to you know maybe like the 1.5 to 5 Second range and so the

solution both to make the network more efficient and to reduce the time to finality was to introduce a soft leadering mechanism the soft leadering mechanism is an expanding window at each height for who can who's allowed to basically propose a block and so the idea is uh it's actually not time-based it's just based on the height um and then the validator set at that time so if the network is going faster you don't actually have to wait for the next slot for the next proposer instead it's just based on the height so like let's say height 10 height 11 so like in our own testing you could run a virtual machine that like let's say you were just playing around with this want

to produce a block at every 100 millisecond you would have a preferred leader at every 100 millisecond slot or however faster virtual machine was running and so this I I really wish I had that slide basically reduce the rejection rate I think uh around the time it was activated from something like 30 to 5.0 three percent maybe so that was a lot less work for the network to do of course that was specifically the sea chain or so that applies to any uh linear chain so that was the P chain the C chain and then um as I'll explain with different subnets uh many of them also use the same proposer VM mechanism we call it um and so that uh it just comes out of

the box now if you really spin up a subnet so all the subnets run it most of the chains around it too so it's kind of like a soft version so if you think about a traditional longest chain whether it's like a single person who basically like say a proof of stake slot based one with a sort of one potentially one person to produce it you're saying there's a small set any of whom are eligible for that particular block height or yeah so it's a it's basically an expanding window um so if you start off at one let's say the preferred person has five seconds to produce something but if they produce it right away it immutely goes to the next slot for the next person to propose on top of um but then if that first person doesn't

produce within five seconds then it's open to that first person and then the second person and then if that doesn't work after 10 seconds then it's up into three people and then eventually it falls back to the all to all leader list so the thing with Avalanche is it doesn't actually produce blocks consistently it's quiescent so there are no transactions um to produce no blocks will be produced so if someone's not producing at a particular time it doesn't necessarily mean that they're adversarial or like they're trying to break the network or anything like that there may just be no blocks uh to produce so it has to be it's a little bit more interesting I think than uh well it's a little just a little different than I

think some of the traditional like slot-based things where you're assuming that if some of those are produced a block at a given time even if it's empty that means that they're offline or they should be you know slashed or something like that for not that participating in the protocol uh you're sitting here there's another explanation which is just that there was nothing to nothing to do that yeah yeah and so with some like other subnets especially some of the newer ones you know like let's just say you're starting off and you got a thousand people uh you know you may not be having like a huge overflow of transactions right away and so because the networking quies uh you end up saving a lot of resources blocks and everything like that just that are empty um and so uh it's an interesting property of the network because of the

way that this uh polling works and the rewards are actually uptime based rather than block uh based well I've been sorry one other question like I'm intrigued by you talking about sort of the network layer manipulations before you went to snowman plus plus so I'm wondering where I should should I think about like a node not gossiping transactions to prevent other people from proposing blocks and taking them for itself for what should I think about it yeah so there's a uh this is one thing I'll touch on a little bit later too which is uh because the way like um the typically the block production process works where a single node uh will produce a block and then send it out with its uh you

know let's just say the pre snowman plus plus case with no signature on it um and so it sends it out um and anyone can then start to basically vote on that block well if you get your block out to more nodes before other people do you probably would have a preference in the network for that block to be accepted because people would have started pulling it sooner they would have started to prefer it sooner and so you started to see people compete on the network layer to say oh yeah I can propagate my block faster than everyone else because there was no mental you just put your information in a block and then shared it and then that obviously there's an incentive to have that happen especially when there's like DVI or captive tvl but

then when you switch to the Snowman plus plus case or uh what also is known as the proposer VM um what happens is the it's bounded so like if you're producing within five seconds you're going to be able to get a block accepted so it was a pretty massive change the thing is it's it's not architected on the consensus layer it's actually architected as a virtual machine that sits on top of the same consensus so to actually release this like soft leadering approach we didn't actually change um anything within the consensus engine itself instead we just changed the block validity rules is something good how do you like exchange assets between the different chances is there like a built-in way to

do it or is it kind of standard bridging stuff no so I haven't touched on that part yet I'll uh let me get back to uh kind of providing the network architecture and then I'll answer uh I think probably those set of questions because I want to make sure I get to the more of the subnet related topics and how they relate to all of these other areas um I'll cover it at that time that's right cool um so now that we've covered uh at least Loosely some of the consensus some interesting questions around like some of the virtual machine design and how we think about uh proposers and consensus within a particular chain I want to also give a brief overview of avalanche itself and it's it's topology um so Avalanche uh

is uh think of it like a network of networks in a sense so there's a primary Network which has the staking set where everything happens like that and then you can create these sub networks on top of it which we call subnets now the way that it works is any validator has to always validate the primary Network and then they can opt in to validate subnets as well now subnets are running any sort of custom virtual machine that the subnet Creator wants to deploy in for most cases for Avalanche right now a lot of people deploy EVMS as the subnet virtual machine but it's a much more flexible interface I'll get into that is just a grpc shim for any language so you

know whether it's going rust you can write any type of virtual machine that actually actually runs as a subnet now up into this point uh you know people have wondered why we um you know uh like require or why the network requires uh that people also validate the primary Network when they're just trying to validate their subnet you know it'd be the equivalent of let's say Cosmos to validate your Zone you had to validate The Hub um and at this point you know without off subnet messaging which I'll talk about you know there isn't really a major reason for it outside of just kind of keeping uh the in the ecosystem cohesive but with cross subnet messaging that's this all changes um and so I'll talk about that a little

bit later um people visualize it in different ways so I always present multiple diagrams to help people understand um I think a little bit more about how the structure actually works so in this case uh you can see that there's like this root kind of this heart the primary network with the p with what are called the p x and C chain which I'll get into and from there you have this like loose proliferation of user-created subnets that may contain any number of validators the important distinction I think most people say is like oh you know does it borrow security for anywhere no they're actually Sovereign networks so the security is provided just by the validators that are part of it Avalanche itself the primary network does not provide any additional security

to the subnets by default you could add that mechanism if you wanted to but right now they're just Sovereign Networks So within the primary Network most people that have ever used Avalanche have used the C chain and that's the evm compatible chain that like most E5 happens on but there's actually two other chains in the primary Network as well um the other one that people tend to use is something called the P chain so that's the platform chain where it coordinates all the staking and the subnets within a single Network like this we have something called Atomic memory So within a subnet where you can think about it like putting arbitrary blobs into like this K value key value store between chains that can then be read on other chains and so the way that

communication happens between uh one single subnet because everyone is validating the same thing it's just to have this like think about like a bucket you could put stuff into and then take stuff out of so when you move assets between the C chain and the P chain for example which is oh I'm going to take my staking rewards and put them into Avec um what you'll do is you'll export a utxo from the keychain into this blob store and then on the C chain you'll try to read it in the consensus mechanism manages those dependencies to ensure that you know if you have a p-chain export then are imported at a later teaching block the network doesn't Halt and it you know it it establishes a an ordering over blocks that can then be

accepted so you can actually have multiple imports and exports in both p and C chain blocks um so the notion is that within a single subnet messaging and actually communication is pretty well defined because you have a shared validator set the difficulty comes when you're trying to communicate across subnets which have different value or sets and that's where the cross subnet messaging story comes in and so the joke I always say is like no one really knows what a subnet is I think in some sense uh because it's kind of used so broadly in some in some areas and um really it's just a collection of validators from the primary Network that just are also validating another chain

and so this this company uh I think two or three weeks ago came out with this really cool visualization tool that shows everyone on Avalanche and then what validators are also validating different subnets and chains um so you can see overwhelmingly so far still almost all validators are just part of the primary Network so they're just validating the x p and C chain but you're now starting to see some proliferation to uh different subnets I'll zoom in here so you can see a little bit more easily so the biggest one that people have seen on Avalanche so far is the dfk chain and so this is D5 kingdoms the other really big one is the swimmer Network which was Cordata and so they run some set of nodes

Community nodes right now those are both proof of authority networks so that's the original subnet mechanism um but when they're getting started it's important for them to you know make sure that everything makes sense you know they have control over the contracts so they want to ensure that there's some level of performance um and then they don't really do any staking or anything like that it's just fully managed by them but you know when this change happens so like as people have basically graduated from the C chain into the subnet World it has had major impacts on the primary Network so uh this was the gas price place on the C chain before and after crobata migrated to their own subnet and so over time what we've seen is that

projects will start on the C chain or on the primary Network and then when they get to some level of scale where their users are complaining that they want to use their own token or they want lower fees then they'll move into their own subnet and then run their own virtual machine that's compatible with their game so this has been really popular amongst different gaming companies that want to Target a level of throughput that they just know they're not going to get either on the primary Network or even on an evm they want to produce their own virtual machine um so I think most people as I said use the evm but the really the really important part about subnets is it's actually just a generic virtual

machine language and we've really written like a shim between the evm uh particularly Geth and into the consensus engine to allow it but the actual virtual machine interface is just a grpc uh layer so we give you arbitrary access to basically do anything within the engine or the networking layer that your virtual machine may want to do so uh the way that you should think about it is you know Avalanche consensus is this lower level engine you know it handles the networking the storage the consensus um and the API and then it will say hey like periodically I got this blob of bytes from the network like can you

parse it for me and then if you parse it you'll it'll hand it back to the engine and then the engine later on will say Hey you know now that you've parsed this blob can you verify it is this a good block great okay now accept it or rejected so you can abstract away a lot of the complexity of the consensus engine to actually build custom virtual machines that can do all sorts of random stuff um and so I created a demo uh which I call the spaces VM so uh if you go to this website I used to have a QR code up here but uh I decided not to do that for security reasons so if you go to this website called trispaces.xyz it's basically this generic name service site like think of it like about dot me which lets people

register names and then store stuff at those areas um and so this is built as a fully custom virtual machine um on top of a subnet and so I can like type in my name you know and I can view uh view the space of all the stuff I've stored there but this is a fully custom virtual machine running on the Avalanche uh basically VM interface um but I I basically added like eip712 type data abilities so you could still use metamask with it but it's a fully custom you know virtual machine and the way that I think about what that provides for Avalanche as the protocol is more to think about avalanches like this Hydra so you know

you have some set of virtual machines that are popular now but as different virtual machines become popular you know you just write a shim to this virtual machine interface and then all of a sudden now can run this entirely new experience and so it's a very future Forward Design mechanism I think for how we think about the growth of the network and uh has allowed us to continue to explore you know all sorts of new virtual machines stuff like the move VMS stuff like wasm stuff like you know file storage and things without having to like redesign the core of uh the Avalanche the Avalanche uh you know repository and the consensus engine um so I think uh we are going to release

some sdks and a few other languages pretty soon um but uh one of the things that people have uh you know really played around a lot with is some more of the networking stuff because you can send arbitrary um basically arbitrary gossip message back in back and forth between anyone in your subnet which is super useful for building like you know some cool like P2P messaging app with no blockchain at all or anything but the VM interface and everything gives you that flexibility to to Really create random things um and so I think the one thing with the cosmos SDK does particularly well is provide you know really nice wrappers around many of these low-level

Primitives um and that's been a huge part of I think their success and so we look to uh you know do something similar I think with wrapping some of these in higher level ideas that make it easier for uh you know virtual machine developers to get started excuse me but uh you know I think um to tie it up and then I'll start to loop back around to you know people that have different questions is really you know we have this you know Avalanches consensus we've um you know implemented these subnets you know the majority of them are proof of authority they can't talk to each other yet um and so you know what's coming so the the big thing um was something

called elastic subnets which just actually just activated on the Avalanche mainnet uh two days ago um so elastic subnets will people come to us and they're like hey you know um I want to launch a subnet but I don't want to control it like I don't want it to be a proof of authority mechanism where I have to like explicitly add validators well elastic subnets we agreed we're like you know I don't think I don't think the end goal of the subnets is also uh to be proof of authority um so we added this this notion called the last acceptance um and so elastic subnets allow you to uh oh subnet basically transition to subnet for being proof of authority and to prove stake um so you can define a custom token and then reward mechanism and so when people

uh stake to your submit they become validators if they are up time for you know some percentage of uptime uh they are then rewarded now the big benefit of this is that all of this logic actually happens externally to your virtual machine so you can enable staking for anything and not really have to worry about the actual sticking mechanism itself so the virtual machine may not even have blocks it may just be like a you know some sort of like PDP thing but you could still actually reward people for participating if they're up for some period of time um so that has been uh you know I think probably the one of the largest releases uh that we've had in avalanche outside of the Snowman plus plus kind of soft

proposer mechanism but that was really more reliability focused I think this is by far and away the the largest feature um that we've added and then I think the uh the other area that uh you know has people uh really been asking a lot of questions about um has been more of the Cross subnet messaging scheme um and so it's great to have uh Dan here because his work uh as many of you know is seminal in this uh in this area um but the idea very simply um I think uh is that uh the primary Network which everyone is a validator on this is why it's important that everyone's a validator uh when they

register to become a validator they store a BLS key plus a proof of possession uh on that Network well because the subnets are so closely connected to the primary Network and everyone runs the primary Network during the subnet block execution context you can actually just like look do a DB lookup or a memory lookup on your node to see really what the validator BLS Pub keys are at a particular time on any other subnet so the way that this works is if you're on subnet a and you're trying to do some sort of like interesting cross subnet messaging mechanism you can generate a multi-signature amongst all the validators on that subnet

send that message to any other subnet that message delivery and format is fully defined by the subnet so it's just an arbitrary signature the subnet B can then say okay I got this blob it says it has the signature you know I can look up right inside of the primary Network on my node uh you know what the keys should be at that time for the the validators from subnet a and then use that to just trivially authenticate that message so you don't actually need to pass any headers around or you know kind of keep different subnets up to date with each other's State context or values you can just query the primary Network to see pretty quickly whether or not a message should be valid or not and so a lot of

people have said you know subnets are interesting but until they can communicate with each other and until I can stake uh on them uh you know they're not as interesting to me and uh you know we've we've heard that uh you know resoundingly and we obviously feel uh similarly so a lot of our recent research has gone into making that possible and so I think this one is particularly exciting for us because we think it will unlock really a lot of subnet uh interest on that activity but uh I'll pause again now I think uh I think I may have prepared a few too many slides for the the slot for time sorry but a good question on the Montebello

signatures they have different thresholds and different subnets so yeah so this is this is I think one area of research we're super excited about so the subnet that receives a signature can decide how it wants to treat that so what we would expect to happen is the subnet B in this case would say oh you know I want to accept messages from subnet A and D but not C and for a my threshold on its uh you know State participation is 70 but on D I need 95 for it to be considered valid so it's wholly dependent on the receiver side whether or not it accepts a signature at all and if so like what state percentage uh the really convenient thing is the recipient subnet as I said has full visibility

into the staking set of any other subnet at any height so it can say oh you know like this message was a little old maybe six hours old I don't want to accept it I only want a message within the last three hours to minimize like kind of the churn assumptions and then from there you know some required State participation okay yeah yeah it's a it's more of a primitive I think than some of the other approaches to this problem um it's really just like a message create like a signature creation and a signature verification mechanism the message format the delivery the guarantees you get around reliability of that delivery are fully up to the subnet on how they want to handle that yes no thanks

I want to Circle back to snowmen plus plus is now a good time to do that or should we yeah totally I think um the last few things I have are kind of just more uh generic mechanisms so yeah let's I think it makes sense to go back to that I'll open it up now yeah fully for uh whatever questions you want to ask sweet I'm curious how so I I you you touched on this but I I didn't fully fully grok it I'm curious how snowman plus plus went from uh block Builders validators being able to sort of produce their own ordering and get blocks in and not get other people's transactions in to a state where uh you know all blocks were getting in yeah so um the way that we developed it actually is a virtual machine wrapper around an

inner virtual machine so think of it like you have this this virtual machine we Define called the proposer VM and its job is just to wrap arbitrary inner blob lights it doesn't really care what they are but you sign them as a validator yep and then you assign a basically a pitching height or time at which you did that um so when a when a validator gets a block at a particular height for a particular chain it knows who is supposed to basically what the preferred proposer list is and at what time those people are should be allowed to propose so let's just I'll make it very tangible um you know we're at height 10 we've accepted High 10 or whatever we have

high 10 verified and now uh we're going to height 11. let's say you're the second allowed proposer so you'd be allowed to propose anytime after five five seconds after that original block was created and I'm proposer a or like the first one I can produce at any time within that first five seconds when I gossip my block to everyone else they just run a simple validity check on the Block header and say oh you know I got the signature here of this node ID is it one that's supposed to be running right now yes great I'll start to actually verify the inner block no I'll drop it this is invalid right now yeah and so the cool part though is that because it's implemented as a virtual

machine you could feasibly create your own proposer mechanism based on something totally different um the architecture we always strive for is more the creation of Primitives that are Loosely stitched together and we look like to the community for like interesting adaptations of that like yeah proposer VM is a great start but oh you want to do something even fancier like you want to have strict Windows you could do that with timestamps if you wanted to like you could write a slot based a strictly slot-based proposer mechanism on top of the Snowman consensus which is totally open or like leaderless yeah um yeah so is the short version that to mitigate spamming you have like a

proposer selection mechanism which you didn't have before before you were just doing sort of gossip and then Collective signatures get over a certain threshold and accept it yes I mean it's uh the difference to the collect a certain number of signatures part there is no part of that in avalanche so like once a block is actually gossip people just vote on it there is a no signature passing people don't sign any headers which is a huge reason why it's so fast like I have bites and then people just basically vote on the hashes of those bites um but in terms of like what the big change was uh is yeah it's just the number of people allowed to produce a block or payload at a particular height starts off as one instead of starting off as everybody and proposer

selection is done uh sort of probabilistically based on stake weight exactly gotcha okay cool thank you yeah I mean uh like I said we uh I think you could do a really cool VM around it that's more like strictly slot days vrf stuff like yeah you know we would love to find more ways to have you know more creative approaches to it um I think at that time you're like we should really fix this and so we have the most reasonable safest option and then from there you know we really want to push people to develop uh interesting adaptations for their use cases and that was like November last year yeah I think it was it was right around

the time of avalanche Rush which I think was stocked I think it dropped in the middle of October okay very middle of the end of October yeah we have a whole write-up on it too if you want to read it and see like some of the diagrams and stuff cool oh yeah I'll check that out thank you yeah I think the only other thing uh you know potentially to touch on is um you know how we think about where uh the Avalanche go deployment is actually going um So within a subnet you can actually logically separate uh the chain Runners across physical hosts um and so within a subnet you could actually have multiple chains right on multiple hosts to scale out throughput scale out uh you know all sorts of State Management storage stuff um and then half Avalanche go act more

as like uh um almost like a network proxy that just decides like which hosts receive which traffic based on you know what what what uh chain they're actually validating um and so you know we uh I think now with the you know really the completion of the core Vision related to the elastic subnet component and the messaging um have really focused all of our attention back into uh you know hyper virtual machine optimization so people know us as like oh great like you can run eth like cool uh back to like now let's make a virtual machine that's hyper optimized and custom built for Avalanche consensus

so yeah I think that should be the gist of it but uh you know happiness Circle back anywhere I think there is a lot of obviously a lot of topics covered and uh happy to dive in either to the consensus design the virtual machine design the network design you know different trade-offs that you know I think the network makes in different ways um but uh yeah thank you for your time I think there's a question in Chad Patrick let's see if I can see that related to the vrf comment is there anyone thinking about using something analogous to Fiat uh Shamir heuristic to cut back on the heavy bandwidth requirements you

mentioned um so one thing we've talked about doing is now that we have this uh you know BLS Factory or tool at our disposal to do these periodic acceptance proofs where the values in the network kind of Gossip uh signatures I mean anyone that's looked at YouTube will say wow that sounds interesting I think it's an interesting idea for people that have the ability to produce uh you know BLS multi-signatures is to have something similar so that people that maybe aren't participating in consensus or don't want to do the polling can just wait and listen for validators to produce or some percentage of stake to participate in a single signature and use that instead as the

way to listen and accept for many like API nodes or uh even exchanges that's more than sufficient for their needs and it would mean that they'd dramatically reduce the amount of polling now the one thing I'll say is heavy bandwidth here is a relative term uh like the messages that are gossiped or like part of the poll is just 32 bytes so each pole per host is not like large we don't send the blocks back and forth you basically get a block and then you pull its hash so the network requirements are relative to others that maybe just listen to the signatures maybe higher because of the amount of pulls that have to be done but it's not like you know every block takes you know megabytes or gigabytes of traffic to

verify good question now okay oh the last thing I'll say well I fill time everyone has any questions is uh we're super interested in supporting different people working on uh zero knowledge virtual machines um and so people that are doing uh we think that our VM uh basically abstraction is really good just for hyper optimizing for zero knowledge uh proof verification and we'd love to work and are looking for different teams to support uh that are working on zero knowledge uh basically zero knowledge based virtual machines uh that would be a really good partner uh in that way because we can provide

or you know arbitrary uh implementations on the VM side and then uh super quick finality of those uh you know proof verification um which I think would go really well with like people doing these larger uh you know kind of zero knowledge scaling techniques uh so I just wanted to before I forgot throw that out as uh something that's super interesting to us right now yeah I'm curious if you guys have thought at all about sort of uh like flashbot style uh direct auction over transaction ordering at the I guess this is a c chain level I guess this isn't subnet level um but I remember sort of in the pre

snowman plus plus days I guess like September last year there was a ton of people offering sort of uh like a turbine style uh transaction spammers and then that sort of moved into direct uh large stake weighted uh validator connections I'm curious if like you've seen that expand at all I haven't looked into it in quite a while or if uh maybe there's sort of more of a democratized effort or anything of that nature yes I mean we um on the the topic of like transaction propagation eventpool uh we just our major concern is just the most efficient mechanism for transporting things so our mental just is amongst the people that are actually going to produce blocks I aka the validators

um it's much Sim it's like much more similar to Solana's approach where they like just like basically send transactions to the next producer uh like some set of producers instead of just gossiping it uniformly like in the Eastwood or something like that um so the med pool was a little it's not opaque per se but just like less widely disseminated because just to reduce network but networking overhead um we we have seen and have seen people play around with the idea on subnets and custom virtual machines in particular of changing the block proposer mechanism to be very different uh very different being like you know take into account all sorts of different factors or like on the transaction execution like have it natively swap

whatever token you want into something else or like make the transaction fee part of the application yeah so that you don't even have this like dual Market thing where you're paying whoever's producing and then you're paying the application like the application is the production of blocks um and so we have seen a lot of people babbling around like commit reveal sgx like all sorts of crazy things for clubs in particular these are subnets that are specific to like application specific clubs I think the the in the in the next few months you'll see a lot of subnets come out particularly virtual machines that are more application optimized so like have

a club that uh you know just the matching is on chain and then the order book is kind of you know gossiped around the node via like the VM interface Primitives um and then you can trivially paralyze the execution right like okay if you don't have like conflicting orders like if the transaction is verbose enough you don't actually need to do any like generic execution to know what state it's going to touch like let's say in a simple transaction I'm sending to you well I know the two database keys that are going to be touched or me and you right so any other transactions that don't touch that I can do at the same time so if you have multiple books or like they don't they don't trample on each other's orders in some interesting way uh you can do very interesting performance things outside of just

changes to the block production mechanism that maybe reward people in very different ways like oh you know big orders we prefer first even if they pay a lower fee well you could do very weird things if you have sufficient research uh I think the next one that's coming out is called dexilot uh they're working with layer zero um on uh kind of like the bridge component to connect to uh that subnet yeah awesome thank you yeah yeah for sure if you have any colleges for collabs also let me know I think uh I wanna we're working on creating more like reference examples I think of uh you know what people can do in this weird and new like totally custom vmworld and uh I think a

lot of people ask about nft minting they ask a lot about clubs they ask a lot about like super high throughput transfers um so yeah thanks so much for for the talk and and all the Q a yeah no appreciate you having me again I love the you know talking to the technical crowds about stuff I think uh what I'll say is there's always with Avalanche like there's a lot of lots of unpack in terms of like the consensus the network architecture and everything like that so it sometimes it takes some time to to really understand uh I think some of the depth of it and um you know I think over the next few months we're really excited to see uh what the community kind of uh puts out related to all these like interesting Primitives we're trying to unblock for them I think there's just so much cool

stuff happening right now and uh you know we're really excited to see to see where that goes so yeah thanks