 Perfect. Thank you very much. I'm very excited to be here at CCS. It's my pleasure to present exciting research with the Tyler Oberos Genesis, Composable Proof of Stake Blockchains with Dynamic Availability, which is joined effort with Peter Gashi, Agilos Kjajas, Alexander Russell, and Vasylistikas. Let me first recall quickly what the original goal of blockchain protocol was and still is. So we can succinctly summarize that as it should implement an immutable transaction legend. So what is that? Well, it's kind of an object where everybody can look up how much money everyone has. It's a recording transaction of who transferred how many coins to whom, and it should be immutable in the sense that if you see a transaction in there, it shouldn't be changed afterwards. So it's kind of written in stone. We also know how to formulate this more formally in a cryptographic setting, namely as a transaction ledger functionality that we introduced in crypto last year. So this functionality, you can really imagine that it reflects all nice blockchain properties what we would have. So it exports a certain state that everybody can read. It ensures chain growth. So the state really extends over time and it also ensures chain quality, which is basically that there are a lot of well-formed blocks that contain a lot of recent transactions. It also captures such functionality, also captures the influence that an adversary could potentially have. This influence is, of course, limited, but it's very important to formulate that. Why? Because such functionality in a universal composable interpretation, it allows you to clearly define what applications can expect from a blockchain protocol, such as Bitcoin, for example. So if you want to use Bitcoin as a service, implement a poker application or something like this, you would want to know what exactly can you rely on if you just invoke the black box interface that a blockchain protocol should give you. So, well, we actually understand quite well what should be achieved. The problem that makes it really hard to implement are the real-world constraints that one imposes on blockchain protocols. So one should, at all times, avoid the central trust identity. One should allow for dynamic participation. People can come and go at will. And one should be permissionless and accessible to everyone. The nice thing also in the crypto paper last year, we proved that Bitcoin achieves the ledger functionality, fulfilling all of these properties on an honest majority assumption of computing power. And also in the dynamic availability setting. What do I mean with that? Well, the real world looks actually more or less like this. It's a multi-party computation. People connect over a network. We have an adversary that always tries to temper with what the honest guys want to do. And in blockchain settings, so dynamic availability refers to the fact that people can just decide to join, they can decide to leave again as they want. And still, to be fully kind of dynamic, we also have to consider the fact that even if somebody connects to the network, he might temporarily be stalled, just offline or sleepy. So even though he's supposed to act, he might be temporarily unavailable. Usually, we need more assumptions of the real world than just the network. When we want to reach something that this consensus likes, so in Bitcoin, for example, the assumption is pretty natural. So we have usually a reference of time also available, random oracle. As we saw this morning, a diffusion network with some bounded delay probably. And what the parties also have is they need to agree on a Genesis block to be assured that they work in the same context, right? So these are quite natural guarantees. So if you imagine protocols, open F timestamps, unpredictability for random oracles are a way to model hash functions. And well for communication, we need multicast mechanisms or other mechanisms that might be needed. So actually, why aren't we done? So we know that there is a protocol that achieves the lecture. Well, maybe we don't want a protocol that requires electrical power as much as the country of Ireland or Denmark or whatever. So sustainability is a big issue. Maybe achieve the same, just less resource intensive. And here's exactly the proof of stay comes into play. And in this work, we show that we implement the lecture functionality with exactly the same setup, so the natural setup you just saw. And with the same features, so dynamic availability, no trusted entity. We can give universally composable guarantees, which means the guarantees we give hold in every context. And we're sustainable, so we built this on top of proof of stake. In particular based on Oroboros, on Oroboros-Prowse. And this is what I'm going to explain next. Okay, so on the following slides, I will show you Oroboros-Prowse. This was introduced this year's Euro Crypt by Davide Dahl. And I'm going to show you how it works, because later I will show you how we modified to get everything what we need. And I will also motivate on the following slides, why what you see here is actually a hard problem and was even thought to be impossible to solve. So let's start. So on the slide, you see here a timeline, so this is time. Basic interval of time, we call it a slot. And several slots grouped together is an epoch, just for kind of how I refer to those time units in the following. So in very broad terms, in Oroboros-Prowse, and Prowse for short, in each slot we have a leader election process going. This is a private election, so everybody does it on its own. It's proportional to its stake, so if somebody has a lot of stake, he's more likely to be elected as the leader. And also the leader election is fed with fresh randomness directly from the chain to ensure freshness of these elections. And the task of a slot leader is just to create a block for this slot and to extend a chain that he knows, make it longer. Let's be a bit more precise. So assume here we have a chain that we are in the current epoch, so to your right. And so now what's happening now? Well, first parties have to agree on the stake distribution, according to which the leaders should be sampled. And this is taken from the last block in epoch minus 2. The fact that we have an epoch in between is actually very crucial and very nice because like this we can assure that every party in the current epoch, every honest party agrees on the stake distribution. Okay, so this means now we have these three guys that have money according to this block. So in the current epoch, the leader election process will go on among these three people. Okay, and to be even a bit more precise, so recall that every party is identified by a private and public key. So it samples really according to a very viable random function. This just means it evaluates a random function and can prove later to everyone that it did. So the party did evaluate it reliably with its private key. And the input to this random function are the slot number and some randomness. And if the outcome of this function call is smaller than a certain threshold that depends on the stake, then this part is considered to be the slot leader. With this process, just as a side remark, we can get empty slots. That's fine. We can have multiple leaders similar to Bitcoin, so that's also fine. And one important thing, so to ensure that each epoch is somewhat independent, so the lottery is really fresh, so this leader election takes into account randomness that is put into blocks also in the last epoch to ensure that parties also agree on that. But also to ensure that so one takes enough randomness values into account to also ensure that there is recent randomness from an honest party. Okay, so a very core function of every blockchain protocol, as you might remember, is the way one should select chains. So over time, Alice will be having a certain state. But she will also receive new chains that might be longer, for example this one. And a crucial thing is now, shall Alice adopt this new chain? And if she becomes slot leader, extend this chain or the other. So which chain is preferable? In Bitcoin, the answer is very simple, take the longest. Proof of stake, this is basically, it would also be nice. But those of you who are more familiar with that, so the situation here should look already a bit dangerous to you. So what is that? It's the second alternative is a very long chain, so pretty good. One might think. But it also rewrites kind of, it forks way in the past, as we can see. It rewrites the entire history that Alice knows, and this is pretty dangerous. Why? Because of the famous long range attacks. Long range attacks is actually a family of attacks. I just give you a rough overview of what they want to achieve or what the adversary wants to achieve. So the adversary emulates in his head possible, execute possible chains that might emerge from the slot leader election process. And the goal of long range attacks is that he devises strategies which makes him very rich on this private chain in his mind. And if he achieves that, this chain in his mind will over time grow pretty fast. Because he's the only one, the adversary will always be elected in this process. So it can grow very fast, especially if in the real world that the participation is probably not that high. There are very subtle attacks also, so it's not just you corrupt like everybody that sold all the stake. You can also pack the transactions that you like the most. This was presented by Gauchy et al. this year, so stake bleeding attacks. So this is really dangerous. That's why the chain rule of Oroboros Prow says adopt a new chain that is valid if it is longer, but does not fork by more than K blocks in the past. So it should not fork by too much. K is a parameter of the protocol intuitively Alice thinks, I mean K is also the common prefix parameter. So Alice thinks if I chop up off K blocks from my current chain, then this is the state that every honest party should eventually also have. So she doesn't revert her history if it's by too much. So this has undesirable implications. Well, why imagine an execution where nobody wants to give up the entire history, how do new parties actually join the execution? So honest, if I want to join, I need some advice. Where are the honest parties currently, I need a trusted checkpoint. Otherwise, I'm completely lost and would never be able to join. And this of course is undesirable because it would require some trusted entity that would serve me such a checkpoint. So we should avoid this. Just for completeness, the second approach to kind of defeat long range attacks is of course to require some fixed participation level, which is of course also undesirable if you want to be in a dynamic participation setting. So we cannot just wait for parties if you want to go on. So yeah, both implications seem like pretty hard to avoid those of the existence of these attacks and then at the same time unfortunate to have. And this is the main result of this paper here at the CCS. So we do not require this. And how do we achieve that? Well, we replace the chain selection rule in Oroboros-Praos by a new one, which I will explain next. And that's what we do. So to give you a bit of a technical roadmap of results, we do. So we first have to check that Oroboros-Praos, as we just saw it, is actually a good thing to build our new solution on. So we analyze the protocol in a dynamic participation setting. So we analyze a bit the simpler setting at first, where nobody new joins, but parties might still fall asleep and not respond. In the second step, we introduce the new chain selection rule that is supposed then to deal with new registrations, with new joining parties. And finally, if time permits, I would also like to give you some overview of the arguments to make you kind of to convince you that the new chain selection rule is really useful. Okay, so the security of Oroboros-Praos is built up in a powerful combinatorial model or formalism characteristic strings and forks. I will not go into much detail, just to say that forks are kind of the abstract model of all possible chains induced by the real-world leader election process. So everything all induced chains, the structure of those, this is what is modeled by forks. And if you look at this picture, of course what is undesirable, if you now again think of the common prefix property, what is undesirable if you have long chains that diverge pretty heavily. So they have no large common prefix, so we have here two chains that Alice could choose from and well, they diverge pretty far in the past. This is undesirable and luckily we can prove that the substantial divergence, as it's called, occurs only with negligible probability under the condition that the active stake that is present in the system outperforms the adversarial active stake in the system at any time. We then go on and prove common prefix chain quality, so we prove common prefix, of course, and the chain quality and chain growth and we also prove universal composable security. Good, so now let's tackle the new chain selection rule. Consider again the situation, we have Alice, she knows her green chain, she's served with a blue chain and which one is better. Well before in the prowess rule, blue chain would have no chance and now with our new rule, the blue chain, it receives a second chance. Alice examines both chains, looks what is the last common block they have in common, there is a time where they diverge and then she examines a time interval of certain size that is carefully chosen by the protocol after this fork and in this time interval after the fork she will then choose or think that the chain is preferable which has more blocks on this time interval. So in this time interval the chain is preferable that has higher block density. This is the rule, so we keep the first one from prowess, of course if it's not like if it doesn't fork by much, we take the longest and otherwise we examine this particular interval and prefer the one. So if it does fork by more than k blocks we prefer the chain that has higher density on this special interval. And now in the last couple of minutes I would quickly try to show you some selective security arguments, you might think okay why does this help. So we basically have two important claims in the paper so we will find all the details there. So claim number one is consider a simpler setting where everybody is always up to date, so everybody is there from the beginning, might be sleeping but we don't care. Then it's actually still nobody would ever adopt a chain that forks by too much. So we actually nobody would ever invoke the new condition if everybody is up to date. And then more importantly the second claim if a new party now joins the execution this new party can just observe the network being served with a couple of chains and the party that joins will automatically after a certain time pick the chain that is very good. So that shares a large common prefix with honest parties, that's what we wanted to achieve. So let me quickly argue about the first one and then see how much time we have for the second one. So first assume Alice would now for the first time actually she's always there, she's very up to date and she will be served now with a chain that has higher block density in this special interval. So we choose the interval very carefully such that it's small enough that we can guarantee that the leader election process is actually identical up to twice the size of the interval, so up to the second purple line, sorry the third purple line. However the interval is large enough that we can guarantee some substantial growth and it's also large enough that we can expect an honest kind of a really honest slot in right after the interval. Good but what is this situation now? Well now we have found that the large divergence had to occur in the past which we ruled out just by the analysis we did before. So this situation apparently does not occur. It's as hard to convince and always up to date Alice to rewrite her history as it is to find a large divergence which only happens with negligible probability so everything is good. So now quickly for the I'm running out of time so quickly for the second claim consider now Alice for the first time joins an execution. So what do we do? We conduct a fourth experiment. We say ah maybe there is a spy spying on the protocol from the beginning and now what we prove in the paper is that if this spy or this angel Alice decides to adopt the good chain and remember this angel Alice is very up to date. She observes everything from the beginning and we prove that if angel Alice decides to adopt the good chain and so does the real Alice. So we are fine perfect and I think I will skip now kind of the argument essentially it's very similar to the case before. If real Alice would indeed never prefer a chain that angel Alice accepts this can only happen if she knows an entire different history which is not possible by the previous argument again divergences substantial divergences do not occur and very good. So let me summarize. So we saw that the dynamic participation and decentralization is of course very important in blockchain protocols and Oroboros Genesis achieves this and we prove you see security in a fully dynamic setting. Parties can bootstrap from the Genesis block only so they don't need any other advice then of course what is the Genesis block and we prove that it's enough to have the honest majority condition of stake. Well and small outlook so of course we also this research is not is not done yet there is a lot to be done like privacy issues or building blockchains that have a very high throughput and so with this I really have to conclude now so thanks for your attention here are the references that I have during the talk and yeah thanks.