 I started looking at Proof of Stake actually a number of years ago. It was somehow realisation that I mean at the time I was in Greece and I was thinking like is it possible to deploy this system like a blockchain type of system for use by anyone in Greece and I mean you would ideally like that the actors of that system actually do not have to utilise heavy equipment. I mean ideally like you would like to have a user base that is using cell phones and basically simple computing devices without having to rely on very sophisticated systems that are expensive or energy-hungry and clearly Proof of Stake at that time seemed like yeah this is an alternative like Proof of Work based blockchains that are very energy intensive. So you wouldn't actually hope that they could be supported actually by a user base that is not sophisticated in terms of computing equipment. I'm talking about the minor side actually not the user side of course. So Proof of Stake seemed natural and my main inclination at the time was that I can just pick one of those systems there and try to understand it but it clearly became apparent that this is quite an interesting problem it's not going to be like an easy way to do it. So it took some time to come back to the problem so the last few months like the intensified sort of ideas that I collected from working on Proof of Work based systems like Bitcoin trying to understand the security and brought a lot of this understanding to Proof of Stake so last few months like we work quite intensively and we have like this new system now that we are finalizing. Alright thank you very much, thank you very much for the introduction it's a pleasure to be here today at the ATI. So the time of the work is Secure Decentralized Blockchains without Proof of Work and that's joint work with Johannes Costantino, Alexander Russell, Bernardo Devin and Roman Olunukov. So I'm going to start with just one very introductory motivation slide. You know Bitcoin as you might be hearing like a lot these days is a remarkable solution but what problem? Now this question is still looming so what I want to tell you first a little bit about is work towards the science of blockchain systems and I would like to put this a little bit into perspective focusing of course on my approach which comes from computer science and cryptography. So it is very important to distinguish between protocol solutions like the Bitcoin protocol and the objectives that they tried to reach. We have to make sure that we understand those as different and it is important to isolate the objectives and understand them on their own right and then judge the protocol solutions with respect to those objectives. So if we do that we are then able to reevaluate these objectives and the hypotheses that we made in order to attain them. So then once we've done that it is then possible to ask for alternative ways to reach the same objectives exploring a wider protocol design space and then we can also reevaluate the basic assumptions and ask is it possible to attain the same objectives under different more agreeable assumptions or assumptions that fit the particular application scenario we're interested in. So this is the grand plan for understanding this from a science point of view. So in 2014 jointly with Juan Garay and Nicos Leonardo's we worked in what we call the analysis of the Bitcoin backbone which was a moniker we used to describe an abstraction of the Bitcoin client that was simple enough to describe fully in pseudocode in a couple of pages. The idea was that in this way by isolating suitably in a way that is familiar to someone that understand the analysis of algorithms what Bitcoin does we will be able to state precise theorems about what the protocol really achieves. So jointly with that it is important to understand also what is the problem that this core algorithm tries to solve. So in the same way that if you are let's say a starting computer science student you can look at the sorting algorithm and you can say okay here is sorting algorithm you have to first to in order to understand how good it is you have to first appreciate the problem how difficult it is to take an array with numbers which are not in order and try to put them in order. So you have to appreciate the complexity of this problem in order to understand how good a solution is. So here it's a similar process so the problem that we isolated and we analyzed the Bitcoin backbone the core protocol of Bitcoin that tries to solve is what we call the robust transaction ledger which is essentially a database of transaction that has two properties which I'll briefly describe in a moment. Now given this we provided formal arguments that this protocol can provide the properties of a robust transaction ledger. So this naturally gives rise to questions like so now given that specific target precisely defined is that protocol the best way to do it? And given that it does it under a certain set of assumptions are these assumptions the ones that we feel comfortable with in an actual deployment? So the assumptions can be also very cleanly described these are related to proof of work and a certain idealized model of computations that cryptographers call the random oracle model I'll not be going into the details about how this works but I just want you just to have a moment and appreciate the fact that there are clean mathematical formulations that are hiding behind these terms that you see on the slide and you can find them actually in our write-up which is publicly available in the IPRID archive in the link I give there. So I'll be centering today to the main question on the lower right which is are these assumption and hypothesis the ones that are most relevant and can we substitute them with others that perhaps are more agreeable for certain application scenarios? So in particular from a protocol design perspective you can ask with respect to the question is this the best solution under the same assumptions there is a realization that Bitcoin is slow and slow basically means that if you compare it let's say with other transaction processing networks like Visa, PayPal, Bitcoin is much slower and this is something that has been widely cited and we community now collectively understands as an important issue this scalability question if you want. Furthermore the proof of work that is employed in Bitcoin has very significant energy consumption is that reasonable? Is it possible to substitute this for something else? So right now this is a current estimate of 350 megawatt and it's expected to grow we've seen it growing over the years quite rapidly. So turning the focus now for a moment away from the solution and just focusing on the problem so the problem of a robust transaction ledger is essentially a database of transactions that should satisfy two properties persistence and liveness. In some sense these properties are classical in the sense that they have been studied or variants of them have been studied by the distributed systems community for many many years so we understand these questions as fundamental questions of distributed systems theory and they are with us since the 70s. So persistence says that if a transaction is confirmed by a node, in other words node here would be an entity that you're allowed to query about the status of a certain transaction and mind you there could be one, two or many such nodes that you might want to query about a transaction then any other node that reports it if it reports it will agree with its position in this sequence of transactions that we're going to call the ledger. So basically transactions persist if you hear that a transaction is reported and confirmed then you will never hear otherwise even if you query a different node or you are in a different place and so forth. So that's not enough and this is critical this thing like persistence can actually be satisfied even by a system that actually processes no transactions whatsoever because it says, observe the property has conditional it says if one node reports, confirms a transaction reports it, let's say, as stable then the others will basically not disagree. So we want something to say that actually the system does progress and liveness captures that that if you broadcast a transaction to the network and there should be some mechanism for you to do that that's a fundamental sort of communication mode that should be facilitated by the system then this transaction, if it is transmitted perhaps for a sufficient amount of time or in a sufficient way, let's say, broadcast it widely then it will result to its confirmation by the nodes now if you join these two properties in a bundle you have a working database that actually maintains the order of transactions and adopts new transactions as they come this may not be the only properties you want from such a database but they appear to be necessary for the database to be useful and that's exactly the point so when we worked in isolating these properties an important concern was that these properties should be stated in an appropriate way that we can then formally argue that the Bitcoin Core Protocol what we call the Bitcoin Backbone Protocol should actually implement, realize these properties and this is what we did in a specific adversarial model which means basically assuming that an adversary is poised to make these properties fail this is a classical way of analyzing distributed systems and cryptographic systems so there are many interesting follow-up works to this analysis and we still have a long way to go until we completely understand the full-blown Bitcoin Protocol its properties and its characteristics so I should say this is not the end but rather a first step of what I also consider a very important question from a theoretical point of view it's actually very interesting that the fundamental question that is raised by Bitcoin is a question that has escaped the distributed systems theory community and this is very interesting you had a very active community in computer science research that he was focusing exactly on that problem and its variants, essentially consensus actually missing that question to put it in very plain words how does consensus as a problem behaves and can actually be defined when you consider it in a setting where you have not a pre-existing identity infrastructure because that's the actual question if you want to cast it as a consensus type of question there were a few papers it should be said but it's clear from the publication record that these few papers were just in the margins way, way outside what was mainstream distributed systems research and that's interesting because you can argue that perhaps one of the most fundamental radical results in this area in distributed computer systems actually came from completely outside this normal academic study of the discipline of distributed systems so let's have a look at implementing a robust transaction ledger so you can think like and this is a very high level description of how you might place protocols in a two-dimensional domain where you think about how decentralized they are and you compare that to how good are in terms of performance and energy efficiency so that is clear that we need performance and energy efficiency there's no way to argue against that and furthermore you can make sound arguments that decentralizing a protocol is a good thing there are many things that could go wrong when you have centralized components single points of failure is it possible to eliminate them or remove them to the best degree we can so if you want to place what we know right now it's something like that on the upper left of the domain we have like basically a centralized database which we know and it works we know how to implement and then you have slightly lower on the right based on the agreement protocols so there is a vast literature of protocols that basically say there is a fixed set of servers that are going to provide you a unified view of transactions the key point in this protocol which is a very big class of protocols is that the servers are identified maintained and static these are the servers the system is distributed but it still remains static with respect to these nodes and there are standard protocols that may be used in this domain they have been studied very very extensively in the distributed systems theory literature and we have a relatively good understanding of the problem from an engineering point of view so here is another space that is interesting and it's possible to place Bitcoin further to the right of these protocols so the level of centralization that is required by Bitcoin still is present but definitely is at a different domain compared to these other protocols of course, observe that this also comes at a cost and the cost is what places Bitcoin to the lower right of that picture exactly because its performance and energy efficient is not good so many questions here with one important one from the protocol design point of view is that is there anything that we can put in this space so this is a motivation for what I'm going to be presenting to you for the remaining of the talk which is a motivation for proof of stake so in order to understand what proof of stake is it's good to go back to Bitcoin and what you know about it and think that generating the next block in Bitcoin is like an election you have a set of miners that are all participating and they participate by opting in which means they download that client and they run it on their system and now one of them is elected to produce the next block what is key here is that the election of that entity is proportional to its hashing power which if you want in some sense is proportional to the investment that the actor has done when the actor opted in the system by downloading the client and running it it actually provides some energy and takes the cost that is associated with running the client so this way of running the protocol or this way of running this election system produces collisions which as the understanding is they can be resolved by a certain mechanism that is implemented inside the Bitcoin system which tells miners to go with the longest chain or be more precise a chain that has the highest amount of difficulty in case there are multiple chains floating in the network so the idea of a proof of stake system is something that is present in the Bitcoin community for many years and the idea basically is that instead of actually hashing power we could use stake the actual stake that is present is reported in the ledger so in this case in such a protocol the set of miners will be the set of all stakeholders so it will be essentially no miners the entities that are going to be identified as actors running the protocol will be the ones that are identified by the ledger itself and then a randomized process will take the current stake into account and then elect the next miner that is eligible to produce the block of course observe that there is no other actor here to implement this randomized election process and the entities themselves, the stakeholders should be the ones that are running this election protocol so in some sense if you take proof of stake and try to put it here you should observe that is definitely more decentralized what is a business agreement type of protocol where you have a static set of servers running the system that's because even though you're going to start with an initial stakeholder distribution the protocol itself may enable this stake to shift to new entities that are entering the system and then those entities will organically assume the effort and the trust that is needed to run the system furthermore there is no proof of work barrier here there is no proof of work involved whatsoever so it is possible to run this protocol extremely fast furthermore if it is a true blockchain protocol it doesn't have to run a complicated agreement step every time a block is produced instead it can immediately produce a block which is going to be broadcasted and thus optimistically build the ledger as fast as the network allows so for this reason placing proof of stake is an advantageous position in this design space of protocols and recognizing this a lot of people in the Bitcoin community enthusiastically went ahead and created many proof of stake based cryptocurrencies just a few of those being presented in this slide unfortunately the problem is a bit harder than you might think even if you use the Bitcoin itself as an example of how you might design this like very fast the community realized that it's fundamentally more difficult to design what they were calling it as a pure proof of stake solution and you can think about it a little bit like there are like all these issues of randomization you have the same stakeholders that are actually participating and having an incentive to participate to run this election protocol how can you argue that this randomized election process cannot be biased by some of them and observe that in the case of Bitcoin things are slightly better they're not perfect but they're better because at least the randomized election process itself is controlled or if you won't hinder it in some sense by this proof of work perspective which we assume it's not possible to be subverted no one can spit it up in some obvious way this biasing problem is not the only one even worse exactly because of the absence of proof of work you have this class of attacks that sometimes the community calls them nothing at stake attacks which basically says that a malicious majority of stakeholders can essentially take any point in time in that system and replay the whole ledger from that point on without actually spending any effort so in some sense this goes against the point that we were making in the beginning that actually proof of stake can actually be more decentralized than a classical Byzantine agreement protocol because the only way seemingly that you can have to prevent a nothing at stake attack is have exactly the same actors being responsible all the time which was basically collapsed this back to a Byzantine agreement system so how can these problems be resolved so I'll tell you a little bit about our work which we've recently released and you can find online as well which provides a new formalization and design strategy for proof of stake protocols and furthermore provides a new proof of stake based robust transaction ledger that addresses all these attacks under a set of cleanly stated assumptions I'll tell you a little bit about the way that the protocol works and then I'll spend like a few minutes just giving you technical details what you have at the core of the protocol is a blockchain like the one that you would expect to see in Bitcoin nevertheless every block is going to be associated with a certain time interval that we call a slot in other words time is divided in slots and blocks can only be produced within a slot by a certain identified member of the current set of stakeholders so you can think of these elected stakeholders which are being marked here underneath as the entities that have been currently elected to run and introduce blocks to the system each one of them is like a kink in its own slot if you are in your slot you are the only one identified entity that can produce a block and you can do that and once you do that it will be immediately accepted by anyone else in the system because that slot belongs to you and this designation is part of the core genesis of this whole blockchain the only way that the block might be missing is that the respective stakeholder is not present at that specific moment and that's why you can have misses here so this blockchain is going to grow and it's going to grow proportional to the number of stakeholders you have online otherwise everything else is supposed to operate exactly as in Bitcoin assuming of course that you have this elected stakeholder in every slot so now let's come to how this election is being done because that's the critical point of that system so there is a procedure which is called follow the Satoshi which basically says I'm going to elect a stakeholder proportional to the stake that a stakeholder has in the system at a certain moment of course in order for this to work you have to provide randomness to that and you could expect that producing that randomness that you have to agree on it's exactly where the weak spot is and this is exactly where we're going to spend all our time to make sure that this can be done securely now you can imagine that the system can actually run for a little bit of time utilizing an initial random seed which could be built in the system in the same way that the Genesis block of Bitcoin was something random that was produced by Satoshi Nakamoto and hard-coded into the Bitcoin client so this initial Genesis block and an initial stakeholder distribution is going to be present here at the Genesis block and is going to define this initial committee which is going to be assigned the slots that are available in the system so the follow the Satoshi process which I just mentioned basically does this uniform distribution according to the stakeholder level of stake before we see how we can take that system forever let's imagine it a little bit for just an initial set of stakeholders like a more classical Byzantine agreement protocol where basically stake does not shift even then it's possible to attack that system and here I'm giving you one example in what we call a forkable string so think of a string which is just a sequence of zeros and ones and assign that position a zero when let's say an honest stakeholder is assigned that slot and then assign to that position a one when a potentially malicious stakeholder is active it's very interesting actually to understand the structure of those strings that enable a fork to exist this is actually one of the core elements of our mathematical analysis so here is an example of a string which I'll just read it 00110010 that string is a string which is advantageous for the adversary and here is an example of a fork that the adversary might produce against a set of stakeholders that are following Bitcoin's longest chain rule in order for this system to work we have to first show that the density of those strings is actually small and most strings in other words should be not forkable this is actually what we proved and this analysis is in our technical report what we show is in two levels first we argue that if the dense if the hamming weight, in other words the number of ones of those strings is small then it's not possible to create those forkable strings and then you can actually go up to 50% close to 50% of number of ones in a string and you'll still get an exponentially declining probability measure interestingly the moment you hit 50% everything is gone and all strings are forkable from this point on aligning with the way that you would do security with Bitcoin and other classical Byzantine systems here is a diagram also that shows you the behavior of these strings with respect to the power of the adversary and the power of the adversary on the x-axis and the percentage of forkable strings you can see how this is pulled on the lower right okay, so now I'll tell you the next step which is how does the protocol go into multiple epochs because so far this will only work for a static set of stakeholders you fix them at the beginning you do the election with very high probability you're not going to have a forkable string and then they can actually build that chain but then of course your security isn't going to be only as good as these initial set of stakeholders are honest honest majority should be present among the initial stakeholders so basically this says that steak cannot move or even if it moves your trust assumption is with the initial set of stakeholders so what we're going to do now is bootstrapping so now we're going to say that was just one epoch what we're going to do now is a new epoch that is going to be building on the previous one so in order to do that randomness should be refreshed and that's a tricky part how is it possible to create pure randomness in this adversarial process so here is where cryptography results can come to the rescue so since you assume honest majority anyway at the initial set of stakeholders what you can have them do is simulate using what is known in the cryptography literature as secure multi-party computation a pure random source essentially a beacon of randomness we know we can do that we know we can do that from the cryptography literature and even though in the 80s and 90s when these techniques were developed and analyzed were still very theoretical in the last 10 years there is a lot of effort in actually implementing them and it's actually possible to design a secure multi-party computation that emulates trusted randomness so here is how you bootstrap here's the first epoch that is going to do exactly that this blockchain you trust your initial stakeholders for doing that but then when you want to bootstrap there is a specific pre-agreed point of time that you will have to have new randomness so during this process during this initial sequence what's going to happen is that this initial set of stakeholders are going to run this coin tossing protocol which is finally nicknamed as god coin tossing because the term is guaranteed output delivery coin tossing this is the term used in the cryptography literature that is going to seed the next election of the committee and now this is all the only thing you need this fresh randomness is going to produce string which is not going to be forkable with high probability and the protocol now can bootstrap and move forever at least until there's a basic security assumptions you have about cryptography collapse so here is the main idea of the protocol I might tell you a little bit or at least like I have a slide about that which I'm going to skip in the interest of time that's how you can actually implement that coin tossing protocol but what is nice about this what I found particularly cute about the design is that this protocol that bootstraps the blockchain in its initial stage it just uses the blockchain itself as the communication medium and it can do that because at least for a short period of time this initial epoch the analysis guarantees correctness for you so once this is done you have fresh randomness to elect a new committee and this is some details about the building blocks which are most interest to those that do cryptography and computer security and less of interest to a wider audience presentation so I'm not going to be giving you any details but be happy to be discussing with them during the break if some of you are so inclined perhaps something to point at this moment which I don't have a slide for is that once this process is done during the first epoch the trust assumption you have is that this initial set of stakeholders is honest and should remain honest for that period of the epoch and then you do the other election that reflects the stake as it has been determined in that epoch now that means that basically the system even though it leaves stake to move, to shift from block to block its trust assumption it doesn't shift in the same swift way it just waits a little bit and it follows from behind using this secure multi-party computation-based election protocol so this is observation is key for the security analysis that we perform and actually bounding the stake shifts that are happening is important to provide the final security argument to put it differently if the stake is radically changed in the system there is no way that that system would guarantee you any security and even though there is no formal argument for that I would say that this is really a barrier in designing such a protocol so something interesting which is a feature of that protocol is the following you don't really have to use the actual stakeholders as the actors that are elected in the committee you can actually use the blockchain itself as a delegation mechanism to say if you have stake you can vote for someone to be your representative in the committee election thus in this way the system can naturally allow the stakeholders to produce representatives and then those representatives themselves are going to be the ones that are running the protocol so what is interesting furthermore is that you can apply to these various principles that we have about delegative democracy like for example you can have a threshold bound about how many votes of stake you should have in order to be in a committee and furthermore you can also have mechanisms like instant revocation which are reminiscent of what some people in voting literature would call liquid democracy where basically you can delegate and have someone represent you in the system and then immediately if you believe that revoke that delegation so this being said I'll come to the end I'll leave maybe a few minutes for questions there are many open questions in this work and in this line of work so synchronicity was a very important assumption in how the system was actually argued to be secure and that is something that we would really like to see how much we can relax actually this is an ongoing effort in understanding the reliance on synchrony that these protocols have and of course initial results and basic understanding is that it's limited we have to be highly synchronous for this to work and this it might be an important barrier in many settings and it's definitely something that we have to understand better furthermore the type of analysis which I presented to you was in this classical setting of good guys versus bad guys so it is very important to understand the incentive structure that you can build around that system and we do have a novel incentive structure which I didn't have the time to explain which has the objective to prevent selfish mining because as it turns out that system that I presented to you in its vanilla version if you implement it with basic rewards as in bitcoin would be susceptible to selfish mining in the same way that selfish mining is nevertheless a good thing about it is that the reward mechanism of bitcoin is just one example of a very simple incentive mechanism that you can build in the system and in fact you can try very different ways to incentivize participation that can be more incentive compatible and we do have a suggestion for that which is currently under active development a prototype furthermore an actual system implementing it that is currently underway and I do hope that in the next few months we're going to have something available which is going to be released as an open source project so thank you very much for your attention I'll be happy to discuss any questions that you may have