 Joachim Neu from Stanford University and they will be discussing the availability, accountability dilemma and its resolution via accountability gadgets. Thank you, Jonathan. Welcome everyone. My name is Joachim Neu and I'm presenting joint work with my colleague, Nozred Tash and with our advisor David Che. I hope you all see the slides. If you're curious, we have a preprint on archive, the link is down here. You can go check out the paper and let's get started. So in this talk, we will have three key takeaways. The first one is a dilemma, which is that no single ledger protocol can be available and accountable. The second point is a proposed resolution of this dilemma, which is to instead of having a single ledger protocol, how about we have two nested ledgers, one of which is available and the other one accountable. And then as a third point, I'm going to show a black box construction of such a checkpointing mechanism from any accountable consensus protocol. And this is what we call accountability gadgets. So let's backtrack a little bit and look at one of our favorite protocols, the longest chain protocol. Roughly here's how it works. So there's a bunch of participants in the network and they try to build a blockchain together, which you see here on the left. And okay, it's pretty straightforward someone puts out a block right and the blockchain grows and eventually we're going to confirm some of these blocks and that's what makes up our ledger. The blockchain protocol is interesting. It has the following interesting property, which is if somebody forces a bunch of the participants in the network offline, then the remaining participants can still keep growing this longest chain. So we call this this protocol is available under dynamic participation. So this is if these nodes are not really forced offline, but instead they just, you know, decided to leave and kind of do their own thing. Then they might be building a parallel chain. And that eventually leads to a safety violation, right there is a inconsistency here to ledgers. And you might ask, okay, who's to blame now right. The way I framed this is well, you know, they, they weren't forced offline they left. So they would be to blame, but how can a third party looking at the protocol from outside determine this. There's another class of protocols, which are very dear to us, which are proposed and both protocols. They're very differently. Somebody puts out a proposal. People take a vote. If two thirds endorse the block, then this block gets a special status for simplicity. Let's just say it's confirmed. So it doesn't matter the remaining one third boats. Now if we have a safety violation to have a safety violation in such a protocol right we need two blocks. And then both of them need to get two thirds signatures. And just by counting right there aren't enough signatures to really do that. So the only way this can happen is if there are a bunch of adversarial nodes who essentially double sign on blocks. And in this case, we can do something interesting which is we inspect these sets of signatures. And we can point out who must have violated the protocol because it's a protocol violation to vote to vote more than once. And we can hold this accountable safety because if there is a safety violation, then we can hold participants accountable, meaning we can point out who who's who's at fault. And we can, for example, slash their steak, or, you know, that might be other external means to the protocol to hold them accountable. So the point with this is that these protocols are not available right if somebody again forces part of the network offline, then we do not get enough signatures to move the protocol ahead. And so the protocol stalls. So this is not available. The question is, is this dichotomy particular to the longest chain and propose and both protocols, or is there anything more fundamental here. In particular, can any protocol achieve availability and accountability simultaneously. And the content of the availability accountability dilemmas know, and the argument works as follows. Suppose we had a protocol that was both available and accountable. So look at the following execution. We have a bunch of honest notes on the left and we have a bunch of adversarial notes on the right. Each of these nodes, each of these groups talk among each other, the honest guys since they're honest right they're also trying to talk to the adversary, but the adversary really never talks back to them. If you have two clients, Alice and Bob, then Alice will hear a set of messages from the honest guys. And they will basically tell Alice, hey, we didn't hear from these other nodes, probably their censored forced offline, you should decide a. So on the other hand, the, the other set of notes might tell Bob hey we didn't we also didn't hear from the others. They did but they can still pretend they didn't. They're probably censored you should decide be. Now we have assumed that this protocol is both available and accountable right so by availability. Alice eventually reaches the conclusion that a was decided and Bob reaches the conclusion that be was decided. There is a safety violation. And since we assume that this protocol was accountable. We would like to hold somebody accountable now. So, suppose there is an accountability mechanism, which Alice and Bob then use in order to determine somebody who must have violated the protocol. And suppose this accountability mechanism points out one of these adversarial notes. And here's the problem. This scenario is really indistinguishable from the scenario in which we switch the roles of honest and adversarial notes. Right. So, since the two scenarios are indistinguishable. The accountability mechanism in this case would have pointed to an honest note, which is of course innocent. And that is not allowed right we only want to hold. We want our accountability mechanism to be such that it only points to adversarial notes. So since we cannot have a single ledger that is always accountability safe and live under dynamic participation. We're proposing to resolve this dilemma in the following way. Rather than having a single ledger. How about we decompose the single ledger into two nested ledgers and available for ledger and an accountable prefix ledger. The accountable full ledger is always safe and live under dynamic participation, and the accountable full ledger. Sorry, the accountable prefix ledger is always accountability safe. And it is life if enough notes are participating. And then it's really up to the clients to choose which of the two ledgers they consider they want to consider. If they ask whether a certain transaction is confirmed so if this is a high value transaction, that should really roll back then you might want to wait for it to enter the accountable prefix. If it's a low value transaction where speed is more important, then perhaps it's enough. If this transaction has entered the available full part of the ledger. So this concludes the second part. Now on to the third part, which is the construction of accountability gadgets. The accountability gadgets. This is an connects to an idea that has been circulating in various forms in the literature before it roughly works as follows. We start out with a longest chain protocol where transactions enter and they're being ordered in the usual way of a long as chain protocol. This forms the available ledger. The longest chains are then periodically fed into the accountability gadget. That means somebody, some leader within the accountability gadget, proposes their longest chain for tech pointing. And then there's a vote on whether or not to agree on this checkpoint, and the votes are tallied in a ledger that is maintained by any accountable consensus protocol. So this can be hot stuff this can be whatever your favorite protocol here. Then after now this way we agree on which votes to count. And then we after these votes are interpreted a checkpointing decision is reached. And this forms the accountable, the accountable checkpoint ledger, and the checkpoint decisions are also fed back into the longest chain protocol, so that the longest chain can respect the life pointing decisions and practice. Here is what this looks like so in the middle you see the participants of the protocol on the left, you see the available longest chain view the view on the available longest chain protocol and on the right you see the view on the accountable vote tally. So nodes build blocks in the longest chain protocol, right, the usual way at some point. So this is what what forms the available ledger right the longest chain at some point. So the node proposes a new checkpoint says how about we check point this block TX five because this is my longest chain. And then other participants check yeah this is also my longest chain I agree with this. And they vote except for this block. And then, if enough votes come together. There is a checkpointing decision to checkpoint the block TX five. And that then leads to the new checkpoint. And this is how the, that fragment of the available ledger transitions into the accountable prefix. Now if an adversary wants to build a longer chain off of the, like on the side chain, which does not respect the latest checkpoint, then honest notes are just going to ignore this so honest notes will from now on only builds on top of the previous checkpoint. And so new blocks come in and this grows the available ledger. And this gives us the availability of that available ledger of the two ledger protocol. And eventually somebody is again going to propose their longest chain for checkpointing. There's going to be a vote again. It's going to be a new checkpointing decision. This block transitions from the available into the accountable ledger. This protocol is accountable, because the vote tally is accountable. So if you wanted to change the checkpointing decision decisions you would have to change the vote tally, but the vote tally is maintained by an accountable consensus protocol. And so, if you change the vote tally, then I can point, you know, observers can point out who changed the vote tally and who's to blame for the safety violation. This protocol has another positive property, which we call predictable validity. It means the following. It means that if a participant proposes a block in the protocol, then they know at the time of producing the block, what will be the prefix in the ledger of the transactions that they propose to add to the ledger. And the advantage of this is, or this is an important ingredient, an important prerequisite for very common light client and sharding techniques. Because this way we can make sure that no invalid transactions ever enter into the ledger and we do not have to later do some ledger sanitization, which is more tricky for sharding or light client nodes to follow. We implemented this construction in kind of a prototype where we just picked some permissioned longest chain protocol. We picked some hot stuff implementation. And with the implementation of Antonio, who was talking yesterday, we took the P2P gossip some network. And we ran. So we ran this. And one of our interests for for for this work is comparing it to gas for which is kind of a simplified version of the Ethereum. And here you can change protocol. And here you see a plot of the average required bandwidth versus the accountable ledger latency for our protocol and for Gasper, and you can see that we can support roughly the same bandwidth and the same latency for twice as many I want to close with a comparison to related work I already mentioned earlier that similar ideas you've probably already seen. It's been widely discussed both in an academic as well as kind of a blockchain practitioner setting. So we're comparing here accountability gadgets to Ethereum to to finality gadgets to snap and chat protocols and to the checkpoint at longest chain. In terms of protocols, a nice property of accountability gadgets is that we can use any accountable consensus protocol for tech pointing. And this is in contrast to Ethereum to for example which uses to quite particular protocols, LMD ghost as underlay and Casper FFG as the finality gadget finality gadgets support some underlay and they usually put some handcrafted finality gadget on top, which requires us to design new protocols to process them again rather than relying on existing protocols. And the check funded longest chain uses Nakamoto's longest chain as underlay and then uses Algorand BA on top. And again, this is, it's not straightforward to swap out Algorand in that construction with some other protocol. In terms of accountability, as the name says accountability gadgets provide accountability finality gadgets, the situations of it makes it's a very diverse set of protocols, some of them do, some of them do not. In general, it's not their design goal. The check funded longest chain does not support accountability because Algorand BA is not accountable. In terms of security. We prove that accountability gadgets are secure. This is in contrast to Ethereum to which is not secure as it's specified in gas for and finality gadgets. Again, it's quite diverse set of protocols. Some from the more academic camp have rigorous security proofs, some that come more from blockchain projects do not. In terms of predictable validity accountability gadgets do satisfy this snap and chat protocols do not. And that's a major drawback in terms of the application. If you want to know more about this work, check out the preprint on archive, you'll find more information about the prototype, the prototype that we developed with hot stuff as accountable protocol about the formalization of the dilemma and about the construction and the security analysis of the accountability gadgets. Thank you.