 So, but Nakamoto's protocol initially wanted to solve as kind of very concrete. So the initial motivation was implementing, well, the accounting of money transaction. So the initial problem was that Alice wants to transfer some money to Bob, but yes, somebody has to do the accounting, right? And if you don't want to trust a single entity, then you have to implement such a ledger, as it's called, well, in a distributed manner. And Nakamoto's protocol, as we have seen also in the previous talk, is one method to achieve this. So it's not surprising then that people started to think about what is actually the service that Bitcoin can export to applications to higher level protocols. And so actually what functionality does Bitcoin achieve? So if you want to specify this book here as a functionality, then what does it, how should it look like? So roughly, so what you can find in the literature is basically that, well, the basic structure of such a ledger functionality, it's a chain of blocks. And each block has some content. So as we have seen, simple transactions, so Alice transfers some money, well, in reality these are addresses, so it's not really Alice, it's Alice address, source and destination. But also one could think about to have complex contracts in there, so-called smart contracts, and everything is listed in these blocks, right? So what are the properties that you often hear about? Well, the content is, sorry, the content is provided by anyone that submits such a transactional contract with sufficient funds. So Alice can decide, well, I transfer this money to Bob, she can even say I have an entire contract that depends on the time and given that Bob does this, I do that. And well, the second property that one is interested is that anyone can read this state, so it's public. You can just say what's the state of this ledger and you can just see how much money a certain address has. And probably the most interesting property is that even an adversary cannot modify what's already in there. So it's immutable, it's written in stone, what's written in the ledger. And as a third, fourth property, one, such a ledger functionality is typically connected to a clock to reason about speeds or how much blocks show up over time. And this is typically found in the literature, such specification. So why do we want such functionality? Well, it's nice to assume it, such that you can design an application around it and then assume these ideal properties to conclude the security of your application. And it's also nice to have such functionality because you can work in a composable framework and get, kind of assume this as a hybrid functionality and use it. Well, let me just give one example, so I will quickly go into these two points. So for example, one application that is actually very nice, so briefly the idea for now. So imagine these people want to compute some MPC protocol. So now, what is the nice thing here? So instead of sending the messages directly to each other, well, they submit something to the ledger functionality. And what they submit this, in each round of this synchronous protocol, they submit their next protocol message. But we've attached with a fund. And this thing here, so this, as I told you before, you can submit the entire contract. This contract says, well, if you behave nicely now, you will get your money back in the next round. So if this protocol message of your current round is correct, and doesn't lead to an abort, for example, then you will receive your money back. Of course, this requires some form of public identifiability, for example, MPC with identifier abort. This has been, for example, worked out in KIA SEDAL in a recent work. And so this honest behavior is kind of punished, and honest behavior is encouraged. So even worse for Eve, if this protocol message that she submitted before led to an abort, she will be identified and not receive her money back. Even worse, for her and even better, for the honest guys, they will receive kind of her deposit, and this kind of favors honest behavior. So let me quickly go into the second point. So we would like to have a functionality to use, to follow this modular approach. So we quickly discussed before this number two here, namely that we assume a retro functionality can create an application, but we also need the first step. So how do we get the retro functionality? And they should rather be the same, so what we assumed here should be one that we can actually get. For example, from a random oracle, and a clock, and a network. And this is the problem which we address in this talk. So they should be the same, otherwise we have a mismatch and cannot really use it. So what are two strong properties that appeared? Well, an over-idealization of Bitcoin was, for example, that also made the transaction would make it to the next block. That's in the case of an almighty adversary, this cannot hold. So the lecture state extends in fixed time intervals. But the influence of an attack to this can also not really be. Third, that everyone sees the same state, as one would maybe intuitively think, can also not be guaranteed, maybe they see a similar state, but one sees maybe a prefix of the other, but not everyone sees the same state. And what we also have to consider is what is the influence of an adversary? We have to allow the adversary to influence the lecture and how it behaves. More than, for example, just that he can create own transactions or permute the list of transactions. So the roadmap for the rest of this talk is we would like to define a lecture functionality which is realizable by the Bitcoin backbone protocol. The questions we have to consider, so important questions, are, for example, so which transactions are part of the next block? Or when is the next block inserted into the state? Which part of the state, to honest part, is seen and what is the adversarial influence on the state itself? These are the questions we will answer in the following. So let's start now with the description of the lecture functionality that we define in the paper. So first of all, parties can input values, well, think of transactions, and they are, they run through a so-called validate predicate and are inserted into a buffer. Here, validate is a lecture specific validation check. Think of, does Alice have sufficient funds to transfer this money to ball? So validate gets as input, for example, the state of the lecture, the transaction, and decides, is this transaction valid? If yes, it goes into the buffer and stays there for a while. So let's jump to the more interesting setting, state updates. So as I said before, the lecture does not just proceed by itself. There has to be some influence that the adversary can have on this update. So how do we model that? So there is Eve. Well, she can propose the next block. So this sounds now a bit too much, right? So it's just a proposal. This proposal, this is not the next block that goes into the state. It will be run again for a lecture specific procedure, which we call extend policy. So what is extend policy? So this next block proposal is evaluated if it complies with the standards, with the policy that the lecture defines. So this is a lecture specific parameter, and at the same time it complies with forcing mechanism. So this blueprint, so to speak, what you see here is a very general class of lectures that you can now instantiate by giving concrete procedures, for example, policy and validate. For example, in Bitcoin, so let's discuss Bitcoin. So to recall, the input to extend policy is the next block. So the proposal of the adversary, debuffer, the time, for example, and it produces an x-block. The invariant of this extend policy procedure is that if the adversary complies with the standards or with the policy of the lecture, then its proposal is really the next block that goes into the state. And if it doesn't comply with the policy of the lecture, this extend policy will enforce the default block going to the next state. And this default block will, of course, be compliant with the policy. So in Bitcoin, this will remind you of the properties that have appeared in the literature. So the extend policy of Bitcoin can say, well, we enforce a minimal chain growth. So if the adversary says, well, don't extend the chain, then at some point, extend policy starts producing blocks on its own. We can enforce chain quality, for example, which means that not too many blocks can have as their owner a dishonest party, for example. And we can also enforce a weak transaction liveness, which means that all transactions that wait in the buffer for too long, they aren't forced to go into the next state block. And hence, we have some weak transaction liveness, which can be amplified, for example, by adding signatures to the paper. So let's continue to the third question. So what state, which part of the state to honest parties actually see? So when Alice wants to read the state of the ledger, I told you before that it's kind of too strong that she just gets the entire state to see. So what is the influence of the adversary there? The adversary can, when Alice wants to read the state, Eve can define a pointer into this state here, with the fact that Alice gets this prefix of the state. So this again seems a bit too strong, so there is a restriction on how this pointer here can be defined. The restriction is that this pointer cannot be too far away from the head of the state, and it can only move forward, that's all. So if Alice reads the state, she will get some prefix of the state, which is, she can be sure that it's not, the state is not much longer than what she can see, and she will only see increasing sequences. And let me mention a last point. So I also said that the ledger doesn't just proceed alone, but it's also important in a framework like UCS that a functionality has to receive activations to work. So there are special, in the ideal world, there are special, let's say dummy inputs, dummy commands, which we call maintain ledger, and whether the ledger proceeds in terms of time, so in terms of this clock functionality, also depends on the number of queries it can get. And if you get only a few queries, it proceeds lower than, it gets a lot of queries. And so the punchline here is that the ledger functionality itself, depending on the activations it gets, can influence the speed of this clock. So to sum up, this is the blueprint of the ledger functionality we put forward in our paper. We have modeled the influence of the adversary, and the parties, they can submit inputs, they can read the state, and they are assured that whatever they read, this points into a window that's too wide and starts at the head of the state. So this blue arrow means that Alice can read up to here, so on. And this window now slides, so as the state extends, through the extent mechanism I explained before, the parties move, kind of move with this window, and this gives kind of a sliding window view on this blockchain model. So that's kind of the summary of our ledger functionality. So how do we realize that? So the usual suspects here, we assume a couple of hybrid functionalities. A clock, of course, the random oracle, and the diffusion network. So it's not a broadcast network, it's kind of an ad hoc network where you can implement a multicast on top of it. And so what we then first did is to cast the backbone protocol as a synchronous UC protocol, following the synchrony model by Katz et al. And so in a nutshell, so the protocol proceeds in rounds. And each round we have to do this proof of work step, and you have to fetch the information so much the longest chain, what transactions came up, and so on. So we divided each round into two mini rounds to reflect this logical structure. So the mining protocol is roughly the protocol you saw in the previous talk. So in the first mini round, you fetch all the information from the network, new transactions, longest chain, and so on. In the second mini round, you try to extend your local longest chain. And if you found a longer chain, if you could extend it, you multicast this again over the network. At any time, remember that we want to realize such a ledger functionality, so the ledger state that the parties implement is defined to be the prefix of the longest local chain here. So then the main theorem, of course, again depends on some parameters we saw before. So we are in a setting with a fixed difficulty. You have the probability that you find the proof of work. You have the network delay. We have to quantify the honest mining power and the dishonest mining power. The honest mining power is quantified as a probability that at least one honest guy finds a proof of work in some round. And the dishonest mining power is quantified as the expected value of the number of proof of works that the adversary can find in one round. Then we can state the main theorem, so if this honest mining power and the dishonest mining power are apart, so which means the beta here is sufficiently bounded away from alpha and alpha is larger, according to this formula, then this mining protocol, the synchronous you see, ledger protocol with the concrete extent policy for Bitcoin, for the Bitcoin backbone, realizes this ledger functionality that we explained before, where you define the ledger state as the prefix of the longest local chain. So one nice thing in this proof is that the proof of work step could be distilled out as a modular sub-step. So the proof of work step, the first thing is to create a UC functionality that resembles a lottery. So what does this mean? So this lottery that the proof of work step implements, kind of very easy, each party can submit input and the lottery throws some coins and if it's accepted, then it's stored in the pool of accepted inputs. That's already it for this lottery functionality. And the nice observation is then that under these assumptions of the theorem, the honest parties have an advantage in winning this lottery over the dishonest parties. And this finally then leads to the consensus we already know about Bitcoin. So to sum up, we have seen that if you assume a ledger functionality for your application, you should not over-idealize what Bitcoin achieves. And what we now provided is an implementable ledger. So we specified it kind of a general class of ledgers and showed which concrete one the Bitcoin backpump protocol can realize. And this realizable ledger can now be used as the basis for proving applications. It can also be used as a basis for further analysis itself, for example, rational analysis. And this kind of extends what we already knew about Bitcoin. So we had property-based definitions and then proofs. Now we also know which functionality in a composable framework you can assume in a large application. So this concludes my talk and thank you for your attention.