ep 11 – Proof-of-Stake Blockchains: Designs, Consensus, Attacks

Transcript

welcome to web 3 with Asics and z a show about building the next generation of the internet from the team at Asics and Z crypto that includes me your host sonal this show is for anyone whether computer scientists researcher developers and creators Community or company leader or others seeking to understand and go deeper on all things crypto and web 3 towards a decentralized community governed internet so in this week's episode we do an overview of proof of stake blockchains from quick background on how blockchains work a difference between group estate and proof of work and approaches to improving both to digging deeper into civil attacks and civil resistance and much more on the design of proof estate blockchains we also go into therefore

different consensus approaches for proof of stake touching briefly on the question debate of centralization versus decentralization in practice and we also cover Costless simulation and long-range attacks and then briefly discuss topics on like slashing and more we don't go into too much detail on ethereum or the merge since we cover that in an upcoming episode be sure to also check out our YouTube channel for several introductory and deep dive videos in particular you can find videos on the exact topics discussed in this episode including proof of stake blockchains and long range attacks just search Asics and see crypto and then finally if you'd also like a more high level survey of research in web 3 and a quick tour through Tech topics like vdfs Roll-Ups

and more be sure to check out episode 8 in this feed which was a hallway style jam with the research team and this episode is also quite literally a hallway style or actually rather casual meeting room chat featuring Asics and Z crypto research partner Valeria or Lara nicolenko who was previously on Novi at meta formerly Facebook where she was a research scientist and cryptographer for the DM blockchain she specializes in modern cryptography post Quantum cryptography and proof of stake blockchain design also joining this hallway and co-hosting with me is A6 and Z crypto how to research Tim refgarden who is also a computer science professor at Columbia and before that at Stanford among many other things he also has a YouTube channel with several lectures on

foundations of blockchains and more as a reminder none of the following is investment business legal or tax advice please see asicsundu.com disclosures for more important information including a link to a list of our investments one thing before we go on we should really quickly talk about like a very high level overview just like what is the difference between proof of stake and proof of work and just how it works so what the blockchain is is just a block of transactions that are totally ordered so a blockchain is one chain starting from a Genesis that appends blocks one by one so the miners help this blockchain grow they take the transactions of users that they have heard from and they Park those

transactions in a blog and they're trying to append next block each Miner is trying to append their own blog to the chain so to open the block The Miner needs to solve a computational puzzle and that puzzle is usually pretty expensive to solve you need to spend some electricity and if you want to be faster than other Miners and be the first to append the blockchain you will probably need some mining Hardware that's specialized for solving this exact computational puzzles and different proof of work blockchain have different computational puzzles so when it gets its puzzle solved it broadcasts the block to the whole network together with the solution so the puzzles take very long to solve but yet they are

super easy and fast to verify so the other miners who are hearing about this blocks from different other miners are trying to decide which ones to pick and there is a certain rules that miners Supply to select one block to append and then to start building on top of with mining you are solving expensive computational puzzles as a result as a side effect if you're taking wealth and coins out of the protocol moving into the real world to pay your electricity bills or to order your money Hardware in order to do pretty Diamond computation right solving sort of useless in fact computational puzzles but that help solve the simple resistance problem essentially great so that's proof of work and proof of stake so their whole

idea of proof of stake is instead of allowing this money to leave the product onto the physical world why don't we ask the miners to lock these coins inside the protocol directly and just reward the miners for participating in building the blockchain proportional to the amount of coins that they locked because otherwise they would spend the same coins on the infrastructure and they still will get rewards proportional to the money that they spend on the infrastructure so we can just circumvent this step altogether and not require miners have any special mining Hardware so with proof of work and proof of stake there also comes a change in terminology and proof of work we call the nodes who help grow the blockchain miners and an improve of stake we call them validators

just to reflect the fact that they're not doing so much work they're only validating it executing transactions and then they're also sending them over and listening on their networks to receive transactions but they're not solving any mining puzzles so this component is missing so that's why there's this change in terminology in proof of stake we call the notes who help grow the blockchain validators and proof-of-work miners that's fantastic and just a reminder like what we're really talking about is people who are contributing computational resources to verify the transactions on a network you know do the work and one analogy we always talk about is how blockchains are like user Community owned and operated service networks and essentially these validators are service providers who are

taking on the expensive computational work to make these systems work so just a very high level okay this is great so far we cover the miners versus validators we covered solving mining puzzles versus validating transactions we alluded to the stake one thing I don't think like kind of bottom line it for me on the energy side so the proof of stake blockchain since their values are not solving this expensive computational puzzles they're not spending electricity to be solving them the only thing they're doing is kind of a subset of the proof of work miners work which is just validating and executing transactions and that's typically much much cheaper and so the electricity consumption would be several

orders of magnitude less for proof of stake blockchains versus proof of work we should also acknowledge that there is some debate over exactly how negative is the energy consumption of Bitcoin and ethereum some people like to sort of drill down into okay how much of that electricity actually would have been used for other positive purposes other people like to argue maybe this is actually a modest amount of electricity or energy given the kind of uniqueness of the system that it supports so I think it's worth noting that there is a pretty interesting debate people can dig into if they want to whatever your thoughts on that debate I think it's pretty clear that environmental concerns are likely to make it more difficult to for example launch new proof of report blockchains improve State blockchains and indeed that's very much been the

trend we've seen in recent years I also get to that that apparently still the energy consumption of ethereum and Bitcoin combined less than the mining gold industry so in that sense combined they're not as bad yeah it's also worth mentioning I remember in the early days when Bitcoin and you know people used to talk about energy use like a lot of the miners that are doing proof of work located in areas where there's latent capacity but there's also renewable energy sources like hydropower so sometimes excess demand goes into the mining and so there's a lot of like moves as well to think about one way or the other yeah but there are other interesting approaches to kind of trying to make the proof of work better one of the popular one is try to increase the block size and that what Bitcoin was trying to do for example but

by the nature of proof of work increasing the block size will delay block propagation through the network and as a result the chain can start forking more and becoming less reliable but people study these approach as increasing the block size they're also figuring out if maybe the frequency of the blocks can be increased also there are interesting approaches around moving transactions of chain all together with lightning networks that will definitely kind of offload the chain a little bit make it more efficient and there also approaches trying to change the proof of work puzzle to make miners actually be doing some useful work so proof of useful work that can actually be helpful for example protein folding transportation problems stuff like that interesting Direction in that regard as

well so I would not totally dismiss the line of work that's trying to improve proof of work altogether some nice ideas there okay let's just talk about an overview of proof of stake blockchains kind of a survey from both theoretical and practical considerations Tim maybe you can kick us off in like sort of the history and evolution of consensus and where we are today sure happy too soon all maybe the good place to start this just to set the stage and compare and contrast modern blockchain protocols you know layer ones versus the classical consensus protocols from the 1980s so the original generation of consensus protocols obviously that was a long time ago well before anyone was thinking about blockchains the motivation was very different the motivation would often be

like a government or a big company replicating a database or some other system and those were so-called permissioned systems meaning that you do want to keep a bunch of machines in sync just like you do with a blockchain but really you just wanted to keep like seven or maybe 22 machines in sync and moreover you knew with that set of machines was in advance and it was never going to change I mean everybody knew who was running the protocol so that's a big difference between public blockchains like say Bitcoin and ethereum where really anybody can run the protocol an immediate issue that comes up when you pass to the permissionless settings the prospect of sybils which will then lead us into why you might need some kind of civilization distance mechanism like proof of stake or one of the alternatives

indeed the Civil problem pops up when you start making your system more permissionless and when you want to grow the set of validators to potentially being super super large you need to figure out who are the real humans or otherwise there can be Robots coming into your system Bots that will inflate the validator set without doing any real work or replicating each other's work and you can quickly have an adversary dominate the validator set and then you have different kinds of consensus problems breaking persistency or safety guarantees and just to be super basic layer like we are talking about trying to achieve consensus without centralized classic parties kind of deciding you're

on this server and this is what you're doing here and this is where you're doing X and so the risk of not knowing who is doing what in this kind of decentralized system is much higher obviously especially the problem of bots being in the system right exactly you don't want this kind of empty entities that replicate themselves indefinitely and then constitute the majority over the real entities and taking over the system and just one fun fact if you're wondering why are they called sybils why is it called civil proof when I first heard about the whole category of civil attacks I'm like it can't be a coincidence that they're calling it Sybil because I do remember that there was a movie that was based on a book called Sybil and it was about a woman who had a type of multiple personality

disorder extremely fragmented the idea being that you don't know if there's one Identity or multiple identities is that what you're thinking of talking about Tim yeah that's perfect civil attack is actually a pretty simple thing you don't want the set of entities that you rely on to be inflated by Bots that are not represented by any real and it is a humans so you would want to make sure that the set of validators who are participating in building your blockchain or consensus protocol the legitimate parties who have real stake in the system who have real incentives to keep the system somewhat functioning and functioning well civil resistance is essentially just production against machines that adversarial yet they're not sacrificing any resources to

participate in the protocol so it's essentially free for them to attack the system and it's free for them to grow in numbers right if you don't have civil protection but if you check that there is some physical entity behind the machine that you're interacting with or they have some stake locked they make the stake subject to slashing or put their stake at risk if you don't have any of that then you open your system free to participate for everyone then you will have this bad entities without any incentives to keep the system honest you keep them coming and kind of dominating the real party so you have to make sure that the entities that you let into the protocol they can

be defined by the protocol so they will not be a centralized entity who decides who is in and who is out but you need to make sure that the entities that you let in have good incentives to participate honestly in proof of stake blockchain designs you would ask them to lock the stake and make it subject to slashing and they will not get the stake back unless they behave honestly and if they behave honestly and participate actively in the consensus you return them the stake and you also give them the reward so they're very well incentivized to participate in the consensus and keep the blockchain healthy so what are the approaches to civil resistance so there are I guess two approaches to simple resistance or two main ones Bitcoin chose to do civil resistance

with proof of work essentially so nodes will do some expensive computation that will require certain specialized Hardware oftentimes or at least some electricity consumption and based on that you would decide whether the node is a real human being or whether there's some physical entity behind it or not and the other approach to civil resistance is stake based so you would show that you have real coins in the system coins in the blockchain for example this is somewhat harder to do if you're in a pure consensus world and don't have any economic incentives but it certainly becomes easier when you're in a blockchain setting and we have each holder having some stake in this blockchain they can sort of prove that they own stake to show that there are

some real entities and of course there are approaches based on identity checking and kyc that you can take for civil protection but that's still be made to work in the centralized and more permissionless settings so why even bother with proof of stake people could argue like we've had Bitcoin the original instantiation from the original 2009 white paper like the idea proposed in there implemented in the form of proof of work but Beyond like the obvious energy Etc why do we care about proof of stake what else is there to say here yeah going back to the electricity consumption that's the main selling point for proof of stake blockchain so far but definitely not the only one there are a bunch of other properties

that we gained when we move to proof of stake the biggest one you get is from probabilistic finality you get to deterministic finality so what that means is that right now in proof of work blockchains when you submit a transaction you need to wait several blocks to be built on top of it to make sure that it's deep enough into the chain that it won't be forked so it will be just there forever and the more blocks you wait the higher is your assurance that the transaction will stay there so sometimes you would want to wait for more blocks for larger transfers and for fewer blocks for just small payments but that's a very annoying property right to have to wait and then even if you wait long enough a pretty long time you will still not have

a deterministic guarantee that your transaction will stay there so what the proof of stake approaches give us is deterministic finality when you learn that your transaction is finalized you may still need to wait quite a long time but when you know your transaction is finalized you can be sure it will not be reverted and so you can act on that one thing I'd add or just to say it in a different way we're actually pointing out that different approaches to civil resistance sort of play nicely with different types of approaches to consensus and so proof of work as we see it in Bitcoin and ethereum and so on it's always coupled with something like a longest chain rule for deciding which blocks are valid which transactions have

been confirmed but a fundamental issue with longest chain rules is that if for some reason an adversary got lucky and wound up having control over a whole bunch of new blocks in a row you could actually switch what the longest chain is and that probably may be very small like you said probabilistic finality meaning that very high probability the transactions aren't going to get rolled back at least if you wait long enough for confirmation but there is always still some probability that some adversaries going to be able to grow a longer chain proof of work just seems to couple very naturally with those kinds of longest chain rules whereas proof of stake there is this separate category of consensus protocols based on the protocols from the 1980s which seems to play much more nicely with proof of

stake civil resistance but just like you said a proof of stake you usually locks in money in escrow in a suitable smart contract which then means it's almost like you've reduced it back to the permission setting of the 1980s where you know who are going to be the nodes running your protocol you don't know the nodes you just know they're public keys or something like that but you do have a known set of validators if you force people to lock stake up in a smart contract and so in a different way I would say it is the different approach civil resistance actually unlock different approaches to consensus and so that can help you achieve properties like deterministic finality where it's not clear how to achieve those I'm using a different simple resistance using proof of work yeah for deterministic finality definitely if you mimic the

proof of work directly as a proof of stake protocol by just replacing the leader selection basically who gets to mine a new block you are not selecting that proportional to the computational power but proportional kind of the stake that they has locked then you kind of just inheriting the probabilistic finality of proof of work but if you build some finality gadgets that help you finalize the transactions just as you were saying based on the fact that you know who other parties that are participating you can get this additional guarantee of the domestic finality on top of your model deterministic finality lower layer so just to pick back up and Probe on the details of this what are other quick benefits to proof of stake Beyond this so not only you can get deterministic

finality sometimes you can just make your blockchain more performant you can make time to finality be shorter so you have faster finality and you can have also larger throughput so your blockchain will be processing more transactions per second but usually approaches to speeding up the blockchain involve limiting the active valid reset so obviously the fewer nodes you have the faster you can run the protocol between them but to keep it fair and to keep it really permissionless in the spirit you will have to do some sub-sampling of committees so usually those blockchains who are trying to increase performance they do SUB sampling of a smaller committees and those committees then work for a certain period of time until they're replaced with the new

sub-sampled committees so if you are participating in those protocols long enough as a validator eventually your rewards will be averaged proportional to the stake that you looked but you know if you're participating not so long enough you might be unlucky to not be selected to participate in those committees but anyway just the general theme of kind of increasing the finality and throughput it seems to be just making the set of values smaller okay we've talked a little bit about why you might want an alternative to proof of work why proof of stake might give you some advantages we talked a little bit about different approaches to civil resistance you know the two most dominant ones at the moment proof of work proof of stake so let's go ahead and drill down into the landscape of proof of Stig blockchains because they don't all resemble each other there's

been very different types of designs that have been explored by different projects so how should we think about sort of categorizing different proof of stick blockchains so there's definitely a theme in proof of stake blockchains and there are two most popular approaches that the projects are taking one of them is generally widely known as long as chain consensus protocol that essentially mimics the proof of work Nakamoto consensus where we just replace the reward function instead of rewarding miners proportional to their computational power where rewarding miners proportional to the stake that they locked in the protocol but then preserving the other properties like probability finality for example so the way those protocols work is usually the

values indicate their willingness to participate in the consensus by locking stake and then at some point they start validating and from the validators who have locked staked and who indicated their willingness to run consensus you pick each one validator per slot and the slot is a deterministic time interval so the time is divided into slots you pick one leader from the validator set per slot and you ask this leader to propose a block and the way that leader selected with probability proportional to the stake that it has locked if the leader was good and honest and proposed a good blog that everybody accepted then he will be getting a reward for that block so there's really an incentive to be a

good leader and there are also Fork selection rules that are happening same yss and proof of work blockchains were to figure out on top of which chain to build your block on you select one of the chains according to a 4 Choice rule that's determined by the protocol and it's actually interesting that fork Choice rules although they referred to as long as chain rules there became more and more complicated over time and some of them are really elaborate so they're not always as simple as pick the longest chain so that's one design choice is just mimic the proof of work nakamotic consensus with proof of stake and by the way Larry before you transition into the other what would you call that category of approaches that you just described where it's sort of similar to the proof of work work choice I think the most

correct term is proof of stake with a fork Choice rule although you will see different other names some call it Nakamoto style consensus some call it longest chain consensus so yeah there's definitely a variety of names before use so no you didn't expect that there would be a key term in web 3 where everybody agreed on what it should be called did you no you're right I don't think we've ever seen that so you're about to go into the other category of approaches to designing proof of State blockchains yeah right the other type of approaches are based on this long literature of building Byzantine resilience systems for permissioned settings as team was mentioning where you definitely know the set of values that you're running with you can just ask them to run a Byzantine

resilient consensus protocol between themselves and agree through consensus on which blocks to append and so when the block gets abandoned typically you know exactly when this blog is finalized typically the model is that when the block is appended there there will be a certificate from the validators saying that this block is final and to make sure your transaction really goes in the blockchain you just need to wait to see a transaction in a blog that has a certificate from the validators what do we call the second category bft consensus like Byzantine fault tolerant consensus is there any other names for that category of approaches no that's consensus Protocols are pretty old from the 80s 90s and so people have enough time to kind

of figure them out and so they're mostly referred as bft consensus protocols let me be one of the less technical name instead of this is a standard but you could call it committee based because the idea is that and this connects to the deterministic finality properties that Lara mentioned earlier the way it's done is through having lots of nodes vote on whether a block should be added to the blockchain or not and so rather than just having one node making a unilateral decision like you do in the longest chain style protocols you actually have more of a collaborative effort among all the nodes running the protocol to decide which blocks should be the ones that actually wind up confirmed so I had to pick a theme I would say committees and voting but again like I completely agree with EFT style consensus is what you'd usually

hear okay great so what are some of the kind of differences in the properties between these two approaches to proof of stake blockchains the bft style and Nakamoto style consensus yeah fantastic there is a major difference which is in case of a network partition which properties does The blockchain Preserve and which it loses because if you get major set of nodes separated from others you will have to either diverge on your blockchain and have half of the notes built in one chain half of the nodes built in another chain that's the case for Nakamoto style consensus that's called preserving liveness but you're losing safety because now you Fork the blockchains there is a potential to

double spend on those two forks so Nakamoto style consensus in case of a network partition they preserve liveness but they lose safety and bft style consensus they favor safety over lioness so if there is a partition between the notes then the blockchain will simply Halt and stop finalizing transactions and you will have to wait till the network restores to see progress again do we have any concrete examples we can mention so one of the earliest examples of this part of the design space where you're doing proof of stake simple resistance where you have some kind of bft style consensus would be the cosmos ecosystem they introduced the consensus protocol known as tender mint which is pretty directly inspired by the the sort of

classic consensus protocols from the 80s and 90s and they recognized how using proof of stake civil resistance you can kind of harness the ideas from the permission setting and sort of bring them into the permissionless world and where does ethereum fit in this taxonomy so ethereum right now is a proof of work a blockchain though they run the consensus layer that will soon become the main chain after the merge their consensus layer is actually a very nice hybrid of this longest chain consensus and bft so what they do is they essentially run the longest chain consensus and then BFD as a finality Gadget so you get the best of both worlds this way you get your transactions finalized deterministically and at the same time you're keeping the

satellite validators really large which is easier to do with longest chain approaches are there any other differences or things we should talk about here so proof of work civil resistance approved stake civil resistance they both have their Advocates and one of the things those different Advocates like to debate is which one is is either more centralized or tends more towards centralization and that's actually like a really hard question to reason about for a few reasons one is just ask 10 people about what decentralization means you're gonna get 11 different answers and then even if you fix a particular notion of decentralization whether it's like Nakamoto coefficient or like the biggest validator slash minor whatever definition we want to use it's actually pretty hard to measure that definition

for example because of the Civil problem maybe it looks like all of your validators don't have much stake but maybe lots of those validators are actually controlled by the same entity and so they would then appear to be decentralized according to one definition even though in reality it's not and then the other thing really worth distinguishing is you could take two given protocols and ask which one is sort of more decentralized now and again with the two caveats they'll get to Define what that means and then you have to actually measure that quantity but even there I think a lot of what people debate about is kind of very long term like do you expect greater concentration of be it hash rate or be at stake versus not and I don't know that we even have observed enough data I don't know that we've actually had enough time to go by

to have any empirical evidence one way or the other I mean you can sit in your chair and tell anecdotes about why one might favorite centralization more than the other but I find it very hard to have much confidence either way until we see this play out at least a little bit yeah absolutely which blockchain is more permissionless whether it's proof of work or proof of stake this will be a never-ending debate I bet in the meanwhile people are trying to design incentive schemes that will encourage the system to be more decentralized in one way or another maybe you would want your validity Assad to be large at least appear to be larger of course you can have same entities behind multiple validators but it definitely seems like a good thing to incentivize people to run more validator nodes and participate in

building the blockchain at the same time you still want to preserve safety so you would want to slash your violators for misbehaving although not all the blockchains are doing that and there's also a debate there whether you need to slash or just give rewards out but with slashing you need to be careful to not make it so severe that no validators will want to run on your blockchain so there's a very delicate balance there of how you keep the valid yourself sufficiently large and of course there is a total separate question of how do you make sure that it's Diversified enough and it's not the whole value reset is run by the same entity and under the hood all right I'm not very clear on the status or state of on where we actually are when it comes to progress of proof of

stake blockchains in practice and I wonder if there's a way to kind of give a quick answer on that without having to go into specifics of which project is doing what I actually don't know where we are in the development of proof of stake blockchains relative to proof of work like what's the status or scorecard on that maybe we can segue from this to what are the unique challenges of Designing these cryptocurrencies are dominated still by proof of works that occupies about 57 percent of the market cup and then the rest is actually mostly proof of stake blockchain projects so that's a substantial fraction already and with ethereum moving to proof of stake it will be the second major cryptocurrency that will start being proof of stake and if you zoom in on the layer ones that launched in the last say

four years it's overwhelmingly proof of stake and some of those Protocols are now doing very well all right so we've talked about how the design space is sort of pretty rich and complex for blockchains in general and even previously take blockchains specifically maybe it's worth just drilling down getting a little more Technical and talking about some of the challenges that come up when you're designing a proof of stake blockchain because it's not as simple as just like swapping out the old proof of work module and swapping in a new proof of stake one there's actually a lot of other things you have to worry about as well one issue is just the challenges of implementing what's in effect the sort of random selection of either one node or a committee of nodes to make further progress in the blockchain random

sampling is fundamentally more challenging and proof stake than in proof of work so so why is that so in proof of stake blockchain you have this unique challenge of selecting a leader in a fair and random way so that it gets a chance to get the block reward or extend the chain with probability proportional to the proof of stake and you don't want to mess up with this process you don't want this to be biasable or predictable say more about that Lara so why you don't want it to be biasable is because the current leaders can potentially influence the randomness used to select the Future Leaders in order to make them more likely to become leaders again so ideally you would love your process to be unbiasable for that

you also don't want this process to be predictable because ideally you would want the adversary to not know who will be the Future Leaders so they cannot be ddosed especially in permissionless settings when you don't know very well your validity values may not have very strong deals protections you don't want the attacker to be taking leaders one by one and stopping the blockchain from making progress so this properties if you want to achieve both of them simultaneously it makes the problem really challenging and there are different approaches the simplest one would be just deterministically the election when you go in round robin fashion kind of PQ leaders the other approach will be run down mechanisms where the previous leaders are committing Randomness so that the next

leaders can be selected based on the this Randomness it's challenging to make this unbiasable you will still have a little bit of bias in the systems and there are some better approaches based on random beacons which are more generic and will work not just for leader election but also for enabling Randomness API for smart contracts if you want to run a lottery for example inside a smart contract you would need to get some Randomness to figure out who the winner is so this approach is good for that as well not just fully election So when you say random Beacon is that the same as a vrf or verifiable random function or is it a little bit different yeah it's a little bit different there are constructions based on verifiable random functions but there are also other approaches to building that you

can build random beacons with the verifiable secret sharing where a set of current validators they just keep regenerating the secret key together in a threshold fashion and derive Randomness from threshold cryptography there also approaches based on vdfs verifiable delay functions so it's a very large design space and I would say that this is very much the work in progress and people are actively research and exploring different solutions then of course there are solutions that are already implemented and running maybe there are more than 10 papers worth looking at to see all these different approaches that people are taking and more papers are appearing like every couple months it's very much a topic of very intense research right now because so many blockchains just

need this primitive of very strong leader election to prove that they're safe in life so Randomness is harder than a proof of State context because you have to really generate it sort of in the protocol itself as opposed to just having it donated in effect by nature and the randomness involved in people solving proof of word puzzles okay another challenge of proof State context is Costless simulation so what would be an example of a problem that arises due to Costless simulation and also what's Costless simulation in this context so of course the simulation essentially means that you're not required to solve any heavy computational puzzles to extend the chain and if you took control over the chain somehow by maybe compromising all

of the validators that then you can really cheaply extend an alternative change from that point so basically forking the main blockchain you can extend it indefinitely and essentially you can try to make it as long as the true chain making it really difficult for the user to differentiate between the two and pick the correct one in proof of work this is not a problem because miners will be required to solve computational puzzles that are super expensive to create a really long fork and as an adversary you will have to be solving more puzzles and real chain solving and for that you will have to just replicate of the mining infrastructure to be working on your adversarial Fork this will be really problematic just because the proof of

work blockchains are supported by so much miners they're consuming so much electricity like duplicating that it's pretty much impossible right so with ghostly simulation there are all different kind of other attacks that follow from this problem and the largest one that worries blockchain projects is a long range attack the idea there is an attacker can compromise historical consensus keys and try to create an adversarial Fork to deceive the users and make them believe that their Fork is a correct one if you think about it the validators who were valuing in The Chain in the past they may not continue to be in the system they may withdraw all of their stake from the system and have no incentives to maintain their past

consensus Keys secure because maybe there will be just fine with the students blockchain being attacked or they can get additional profit from selling this past consensus keys to the adversary so incentives are not helping here to keep the historical Keys safe so this idea that old consensus Keys might get stolen the adversary could Fork a blockchain from like long ago and kind of take everything over there's a bunch of really major proof of stake blockchains out there in the world how are they addressing the threat of these long-range attacks right now yeah great question so of course the simplest way to address that is to introduce checkpoints but that solution is not great because it's kind of centralized it will require the checkpoint inside

your code base on GitHub some may argue though that this is a good solution right now maybe because some of the blockchains are more centralized in case of a devastating attack you would want to checkpoint your historical blog to invalidate this attack when some people think about it is if you sort of trusted the folks who wrote Whatever client that you're using if you trusted the sort of website you downloaded it from you trust the implementation is it that big a step to then also just trust from the same source of Declaration of some recent block that should be included in the blockchain that's right but at the same time you would want your system to be a diverse and decentralized so you would want ideally to have more clients and then there's a challenge of embedding the same checkpoints in all of these

clients it's sort of you're back to this consensus problem again of making them agree and what checkpoint to include so that's one approach you can also checkpoints your proof of stake blockchain into the proof of work blockchain just periodically publish some checkpoints there at least it might help coordinate mitigation to the attack if it happens at least in a social layer kind of make people look at historically what has been checkpointing on the proof of work blockchain to make sure you as a community is picking the Right Fork if you got really confused about which Fork is the correct one so you do something like even if you're a very small project maybe you could once a day or once a week to is published to bitcoin let's say a summary of the most recent state

of your blockchain and then if there's an attack you would just basically the trust would be the same as the Trust In Bitcoin at that point to do recovery right yeah exactly although you need to be careful about how exactly you trust that I would better just leave it to the social layer to later figure out like whether you trust the checkpoint and the proof of work blockchain because that also could be created adversarially potentially if there was a silent attack going on but still checkboarding solution is more centralized it will require you to put some trust in checkpointing mechanism so this sort of checkpointing idea one way to think about this is It's almost like the protocol kicking the can to the social layer of the users and maintainers of the protocol so I almost wonder if

there's an analogy with how people often think about you know 51 attacks right so for example in Bitcoin if somebody was able to Corral 51 of the overall mining power there's a sense in which they could quote unquote take over the chain and control black production on the other hand people do worry about 51 attacks but then they don't worry that much and probably one of the reasons is they think it's too costly to do it but I think another reason is that there's always this sort of backup emergency option to kind of escalate if you like to the social layer and say oh no no no this is clearly a 51 attack we should roll black some blocks or we should change the proof work puzzle or do some kind of hard Fork so I wonder should we think about this sort of check pointing

at the social layer is kind of analogous to like a hard Fork recovery from a 51 attack I think that's a Perfect Analogy in fact that's how hard Forks are done is that you have to in Bank in a checkpoint in your protocol to make sure you're synchronized into the correct chain after the hard Fork if you have a long range attack in addition to coordinating of which Fork to choose you also have to figure out why that happened and then you need to fix that because typically if one long range attack was possible and you're saying a rosarial fork it means something is wrong with the system and it might lead to more attacks like that so this attack will need to make developers urgently figure out the problem and fix it and that's also another decision you will

have the community to agree on of how do you fix the protocol in case it is susceptible to long-range attacks to tie this back into checkpointing and basically protocols hunting on things and escalating them to the social layer I wonder if some of these other approaches to long range attacks we can almost think about the sort of more sophisticated approaches that try to push some of that responsibility back from the social layer back into the protocol itself and again looping this back to 51 attacks I mean one interesting feature about ethereum post merge the approve of stake implementation as you mentioned slashing is definitely part of that design I think one way to think about slashing it's almost like a in protocol defense against something like a 51 attack right so there's actually maybe maybe there's

no need to escalate to the social layer because the protocol will just itself automatically drain the funds of people who deviate from honest consensus behave behavior and so it seems like a really interesting tension to me a certain sort of recovery properties you might want you know where they best handled in protocol kind of programmatically or sort of extra protocol at the social layer I think that's definitely something we're still figuring out and it might be useful to think of these different approaches to long-range attacks as sort of different choices on where you are on that Continuum that's fantastic one such a fantastic point and so relevant to many discussions that are actually happening right now Lara your running down approaches to checkpointing did you have anything more to say there there are other Solutions involving key

evolving cryptography where you would trust your owner's violators to rotate the keys frequently and kind of discard the old Keys completely delete destroy them so that darker cannot later find the historical consensus keys but the problem with that is that it's also kind of incentive incompatible if the validator knows ahead of time that it would want to be malicious in the future it will just keep his historical consensus Keys hidden and then maybe sell them to the other city I mean how do you prove to anybody that you deleted or discarded something right that's just exactly that's a pretty much unsolved problem although you can use trusted Hardware to do the deletion but then you'll have to trust your trusted Hardware assumptions and just sometimes people prefer cryptography to trusted

hardware and there are also other approaches one of them will develop when we're working at the DM blockchain with Sarah Azu and George danesas we published a paper called Winkle and the idea there is you would have an additional layer of user-based consensus on top of your database consensus that is going to be progressing slower but it will involve the whole user base to kind of voting with their transactions of what they think is the latest block that they are aware of so essentially you will need to change your transaction format to include some of their blogs that you are aware of in blockchain in this way users transacting with their stake in the blockchain they will be

also casting votes on what they think the state of the blockchain is what was the greatest blog or the latest ebook and this will also help because if the adversary Forks some historical log of the blockchain starts creating his own work he will definitely not be able to impersonate real users he will not be able to forge their signatures so in his work pretty much the only thing it will be able to do is censor transactions of honest users and maybe add transactions from the accounts that it has compromised so this chain in terms of user voting power will be more poor than the correct chain just because there are less honest users transacting and voting for fresh blocks on that forking chain

so anyway just the whole idea of Twinkle is build a user-based consensus on top of the consensus that you already have such that you alleviate your assumption from trusting the values to now trusting the whole user base to not break the protocol and make it safe and philosophically it feels like the right approach to also make the users work on helping you maintain the security of the blockchain you had several years of experience at Novi Labs working on the DM blockchain I wish I could have been a fly on the wall on some of those discussions about oh should we do proof of work proof of stake proof of authority proof of authority meaning just do a permission to kind of blockchain protocol and then also the other parts of the design space

that you outlined you know longest chain bft type anything you could say about the decisions that were made and like what were the biggest factors that led to those decisions so for the DM blockchain we planned on the first version being more permissioned where you would have a pre-selected set of Auditors or have busy notes to run the blockchain and who are okay with it and you know who they are so it seems like a safe first thing to start with and then if when you battle the SEO protocol then move to more permissionless regime where you would allow mobile dators to join and make the protocol decide who can join and who can leave and actually a lot of profostic blockchain projects are taking sort of this route where they know the top of their validators and

they're expanding the validity base more and more as they're becoming more and more confident that the protocol is running correctly as intended and on the side of the consensus protocol that we were choosing of course deterministic finality was really attractive so that's why we kind of decided to use the bft style consensus protocol also in bft style consensus when you don't have too many validators you can keep the set bounded then you can build really performant blockchain with really fast finality and really large throughput that definitely was a requirement for the VM blockchain that we were building because we were anticipating the user base to grow to a large size really quickly so we had to make sure that the

blockchain can be performant enough to support large user base the moment I like heard about what they're trying to build I was completely sold on the idea to open the blockchain world to kind of ordinary users the promise of this blockchain was focusing on enabling a cross-border transfers and that's definitely a pain right now to send money to other countries that's just taking too long and oftentimes just too complicated and they're in almost fees involved so that would if this blockchain was to go live that would make it really really simple Let's cross border transfers is there a place where people can find out more about all this snowy work that you just mentioned the

whole project is open source it's actually a very nice code base you can download it play with it you can read the specifications and different descriptions that we also made open source to better understand how it works the Novi team had also a very big research group that consists of cryptographers formal verification people people doing distributed systems programming languages a lot of nice work has come out of this group as well in form of academic papers advancing the field so I'd recommend checking out them as well that's great all right so having talked about some of the solutions that have been proposed thus far maybe it's obvious to The Listener that this is still largely an unsolved problem people

love to say kind of it's still early in web 3 usually talking about investment or about adoption but this is a great example of how early it is even on just the sort of Science and Engineering side you know we've been hearing about proof of stake for I don't know eight years if not more and still people building new blockchain Protocols are really struggling with the way to do it right overall I'd say speaking in 2022 I think it's clear that proof of stakes civil resistance is going to be a really relevant concept an important part of the design space for quite a while but again as we said before we're still converging on the best way or ways to do it the smart people are thinking about the problem and accordingly we're seeing progress at a healthy rate I do think when we look back in 2030 we may

sheepishly sort of look at the ways our approaches to proof of stake that we had available in 2022 I expect a lot more progress and more best practices to cohere on proof of stake blockchain design as this decade unfolds yeah definitely I definitely hope that more academic work will be analyzing this blockchain protocols concretely but it's just such a complex thing usually when you're trying to reason about the protocol with all the blouse and whistles that it has so it's really exciting to see engineering teams innovating designers innovating on how to improve this blockchain protocols and their guarantees as well as people from Academia analyzing those blockchains for more theoretical perspectives and

proving the guarantees that they provide there's a lot of innovation happening in the proof of stake blockchain design I think there's a lot to learn from Individual projects and their approaches as well as each other well that's a great note to end on thank you so much for joining this week's episode of web3 with Asics and Z sort of a hallway style chat with our head of research Tim ruffgarden and Valeria nicolenko research partner at Asics and Z crypto thank you so much you guys for joining this week thank you so thanks Sono thank you for listening to web3 with A6 and Z you can find show notes with links to resources books or papers discussed transcripts and more at asicsncccrypto.com this episode was

produced and edited by sonotoxy that's me the episode was technically edited by our audio editor Justin golden with seven Morris credit also to moonshot design for the art and all thanks to support from Asics and Z crypto to follow more of our work and get updates resources from us and from others be sure to subscribe to our web 3 Weekly Newsletter you can find it on our website at asicsnzcrypto.com thank you for listening and for subscribing let's go [Music]