I'm Peter Gagi, I'm a research fellow at IOHK and we are now at Cambridge, Massachusetts and I'm going to give a talk on Uroboros and Uroboros PROWS, which are two proof-of-stake protocols that underlie the Cardano project. Uroboros is unique in being the first proof-of-stake protocol with provable security guarantees being published in a peer-reviewed conference crypto 2017. Provable security is an approach that is being adopted by cryptographers in academia for decades already and it's a way to design protocols where as opposed to trying to just design them in a best effort way you instead aim for a clear security guarantees that can be mathematically proven in a rigorous computational model. Approvable security treatment of the protocol consists of defining the model in which we look at the protocol, describing the protocol and defining the required goals that we want to achieve with this protocol and then giving a mathematical proof that this protocol actually achieves these goals in this model against an arbitrary adversarial behavior that the model allows. Thank you very much Amy for the kind introduction. So yes I will be talking today about Uroboros and Uroboros PROWS, the two proof-of-stake algorithms that one of them is underlying Cardano already now and the second one is potentially might replace him at some point. And first let me mention that the whole line of work on Uroboros blockchain is joint work with Agelos Kias, Alex Russell, Bernardo David and Roman Olinikov and actually these gentlemen are the authors of the first Uroboros paper and I joined the team when we started working on PROWS. I will be talking about both of these protocols and also I would like to acknowledge Alex for creating an older version of these slides that will be used throughout the talk. So the roadmap for today, so I will be first very briefly talking about Bitcoin and proof-of-work although we all have an overview of how this roughly works, is just to make sure we are on the same page and to be able to draw comparisons later. Then what follows out from this first part is that this is not the end of the story and this motivates why we want to look at the proof-of-stake instead.  I will describe you the model in which we look at how Uroboros works and in which we prove the security guarantees. I will describe how the protocol works and I will try to show you some details from the security proof of the protocol. So this will be more of a theoretical look at Uroboros. And then I will also talk about prowess briefly by describing the differences from Uroboros and how this helps us make Uroboros better, namely secure in a semi-synchronous setting and with adaptive corruptions. I will talk in detail about what this means. So let's start with Bitcoin and proof-of-work. We all know this part so Bitcoin as we all know is a cryptocurrency that appeared in 2008, at least the proposal. And what was novel about Bitcoin is the idea of a decentralized ledger mechanism that is being maintained in a permissionless setting. So anyone can enter the setting, participate in the protocol. And this was possible due to a novel security assumption, namely the majority of adversarial computing power, sorry, the assumption that majority of the computing power is controlled by honest parties. This is the crucial security assumption that Bitcoin is relying on. Of course, it inspired a huge amount of follow-up work and there is a huge amount of cryptocurrencies that came to exist after Bitcoin. Some try to aim for richer transactions, which are often called smart contracts. Some aim for better privacy and some aim for different consensus mechanisms. And actually a different consensus mechanism is what I will be talking about mostly. But from a theoretician's perspective, the first question you should ask and needs to be asked when you look at Bitcoin is what problem does Bitcoin solve? And this question wasn't rigorously asked for quite some time and later this was formalized, mostly in the GKL work. And it turns out that the question is how a distributed collection of parties can agree on a dynamic evolving sequence of transactions, which we will call ledger, in such a way that it maintains two properties. The first one is called persistence. And it means that any transactions that already entered the ledger will be immutable. And the second one is called liveness and means that if I want to include a transaction into the ledger, eventually this will happen. This is an informal description of a property that can be captured formally. And of course, it's parametrized somehow to give some concrete meaning to this eventually. But this is the intuition. And this all should be happening in a setting where parties can join and leave the execution of the protocol. And we have to account for some parties that might behave adversarily and try to disrupt the protocol. And the way Bitcoin goes about this, of course, is by storing this ledger in a data structure called a blockchain, which consists of a genesis block that is agreed upon at the beginning. We assume that everyone agrees upon how this genesis block looks. And then a sequence of blocks where each of them contains some transactions and also a hash of the previous block. So this particular block commits to the entire history of transactions in Bitcoin. And of course, the major challenge in Bitcoin and in cryptocurrencies in general is how to achieve consensus on changes on extending this blockchain. And the interesting point here from a theoretical perspective is that this is outside of classical distributed computing models because it no longer makes sense to speak about majority of players. This is due to the CBL attack, which we all know, right? If it costs you nothing to enter the space and there are no identities, then you can just create as many players as you want if you try to disrupt the system. And the solution that Bitcoin uses to overcome this problem is a combination of two things. So the first one is proof of work. So as you all know, a block in Bitcoin looks like this and it contains a work nonce, which is a proof that whoever created the block invested a particular amount of work. And this certifies that the work was invested. And the second part of the solution is the longest chain rule, which means that if I'm a party looking at the potential candidates for the state of the ledger, I will simply choose the one chain that I see that is the longest I have seen so far, or at least contains most work. So in a very simplified cartoon version, Bitcoin works like this. If you are a node, what you do is you just simply repeat the following. You collect all the pending transactions, you collect any chains that you have seen on the network, you adopt the longest one out of those as your current state. I mean, of course, it has to be valid in terms of the transactions that it contains and other things. And then you simply try to mine a new block on top of this chain by trying to solve this proof of work. And if you succeed, you add it to the blockchain and you broadcast it so that everyone can adopt it as well. And what this whole procedure achieves is called eventual consensus. Because if we have an adversary that tries to compromise the persistence, for example, he might try to remove a particular transaction that is in one of the blue blocks from the ledger. He would have to create an alternative blockchain or an alternative fork from the blockchain that would have to be longer than the major one. And of course, this is highly unlikely if he only controls a minority of the computing power. This is the carton version of the main security argument of Bitcoin.  But another way how to see this is that this actually yields as an implicit mechanism for a ledger election. So you can see all these people that are doing the mining, doing trying to complete these proofs of work as competing in a ledger election process where the probability of succeeding, which means being able to extend the chain, is proportional to the computing power. What is nice about Bitcoin is that, first of all, it is simple. The protocol is much simpler than previous protocols trying to achieve consensus in permissioned settings, for example. And it neatly solves this challenge, how to achieve this consensus in a fluid population of participants. But also, and also with previous impossibility results, which told us that something like this should not be possible, our sidestep, thanks to this ingenious new assumption of the majority of computational power. And actually, it's amenable to formal analysis, which already happened to some extent in academic literature. So there is Gara Edal in 2015, gave analysis of Bitcoin in the synchronous setting. Then Pas et al in the semi-synchronous setting. And Badejo Edal at crypto 2017 gave a UC-based characterization of what Bitcoin achieves. So that's all good and nice, but we wouldn't be here if this was the fine answer. And so Bitcoin also has some disadvantages. And the main one is the computational raise that is necessarily happening to maintain this proof of work. Because this assumption of honest computational power, honest majority of computational power, that's essential for Bitcoin security. And so as Bitcoin grows, the need for computational power being wasted in the process of maintaining the ledger also increases. And this can actually to some extent be quantified. It's hard to get precise numbers, but the estimates are on the order of single units of gigawatts being needed for maintaining the Bitcoin network, which roughly corresponds to powering a million U.S. homes or an entire country, as you can see in the news. But what is, at least for me, more worrying about this is that these estimates are growing due to the growing popularity of Bitcoin. So for example, it almost tripled over the last six months as the price has soared. And this doesn't seem to be sustainable in the long term. And remember that security of Bitcoin crucially relies on this. So clearly from a theoretical but also from a practical perspective, a very important challenge is to try to replace proof of work with some other mechanism. And if we try to aim for a similar mechanism, which we also can see as a lottery or a leader election mechanism, what we would like to do is to do this election based on different resources than computational power. There are actually several proposals trying to do this. There were proposals looking at disk space as being the resource to be used, maybe useful computation as opposed to the useless computation that is being used in Bitcoin, maybe useful storage of useful data. But I would say that the most appealing approach is to, instead of all these real life resources, try to use an abstract resource. And clearly, the choice of the abstract resource would be to use the coin itself, the owning of the coin itself. And this is exactly the line of thought that leads to proof of stake, the topic I will be talking about. So basically proof of stake is this approach of shifting this election process to a setting where your probability of winning is proportional to the fraction of the currency that you own. This has several advantages because, as you know, the ledger already contains the information about how the currency is distributed among the participants. So basically the first idea how we could do this is simply in steps, always elect the smallest unit of the coin and just try to look who owns it and let this guy be the leader. This would lead to participants being elected leaders proportionally to the stake that they own. This was actually proposed in the context of Bitcoin as well and that's why originally it was called follow the Satoshi by the smallest unit of account in Bitcoin. And from a high-level perspective, it looks awesome because we just got rid of the need of the physical resources that would underlie the election process, but otherwise nothing needs to change, right? Except that it's not so easy. So the main challenge when you want to design the, I mean there are several challenges, but the main challenge when you want to design a proof of stake protocol is that for this election that I just described, you need some randomness to elect, for example, this coin and what I described. And this randomness, this randomness needs to be unbiased, unbiased by the parties involved, potentially malicious parties. And this is really crucial because as soon as the adversary can bias the randomness, he can bias the election process and he can try to hijack the whole chain and bad things happen. So the first challenge is how to produce this randomness. The first strawman proposal that was actually even implemented in several existing cryptocurrencies and that comes to our mind, if you try to think about it, is that, okay, the blockchain already contains some effectively randomly looking data, which are the hashes of the blocks. So one thing you could do is just try to hash the blockchain as far as you see it for now, then this will identify a particular coin and then this will somehow identify its owner and this owner is allowed to create the next block. That sounds good, it just doesn't work. And the reason for this is well known, it's called rejection sampling. What the adversary can do if he gets into a position of creating a block, he can try to locally test whether if he creates a particular block, what would be the outcome of this process and if it turns out that the next elected leader would be someone else, he just discards this block and tries again and he does this locally until he is lucky and until the outcome of this process is that he would be the leader of the next block again and then he can do this on and on and basically hijack the chain. So this is obviously unacceptable. This is called a grinding attack, it's one form of it, it's a simplified one, one can see many variants of this and this is mostly to illustrate that it's not as easy to make this idea work as it would look at first sight and there are actually a lot of subtle challenges in it. I don't know, at least some of the constructions that deal with this problem and give some rigorous guarantees in terms of security of the proof of stake protocol. Uroboros is the protocol that I will talk about and now I'll just sketch how these protocols deal with this particular challenge of getting randomness. So what Uroboros does, it implements a secure multi-party computation to generate the randomness. I will go into the details later and this actually gives us clean randomness unbiased by the adversary as long as some assumptions that I will detail later are satisfied. A different class of protocols, snow-wide and Uroboros prowls, they choose a slightly different approach. They do use hashing which is what I described before but in a much more careful way and they do give a rigorous analysis that this grinding attack actually can be contained and the randomness can be used for staking without jeopardizing the security properties of the blockchain. So it's hashing is used and then by careful analysis we can show that this doesn't do any harm and in this place I also have to mention Algorand which actually predates all the proposals above but uses a different approach so I will not have a chance to go into details of that in the talk. The approach is that contrary to the above constructions which aim for an eventual consensus just like I showed you aiming for the longest chain rule and accepting the longest chain, Algorand simply tries to get a complete consensus for every block. But why I mention it here is because it still needs randomness for its running so it has to address similar problems and it does it in a similar way to the constructions in the second ball and namely it does use some hashing and it does an analysis that shows that grinding the effects of grinding are can be contained and limited. There were also several solutions of proof of stake in the wild so I will just list them here the NXT cryptocurrency peer coined DPOS that seems to be underlying BitShares team and DOS. There is discussion about Casper at Ethereum and so on. So let me now move to the main part of the talk where I will try to give you some insight into how Uroboros works, in what model we analyze it and how we try to prove it secure. So from a really top-level view Uroboros is a protocol that assumes synchronous time and communication so we look at it in a synchronous network model. This is something that an assumption that will be relieved in proud but for Uroboros this is how we analyze it and it does provide persistence and liveness. The two properties that I told you about that we care about it provably achieves persistence and liveness under the following assumptions. We assume that the adversary controls a minority of the stake throughout the whole execution of the protocol. We assume that corruptions from the adversary are not immediate so the adversary might corrupt parties but there is some delay in this corruption. This is also an assumption that can be alleviated in proud and we do it in proud and stake shifts are happening at a bounded rate so this seems like a practically reasonable assumption. We are assuming for example that not all the stake will transfer from one account to another one within a single transaction and there is a bounded rate of how the stake shifts. So let me detail a bit about the communication model. I said it's a synchronous model. We assume that participants have synchronized watches and we split all the time into slots for example in the Cardano implementation of Uroboros one slot is 20 seconds just so that you can imagine a particular number there and we assume that all messages that are being sent by players by honest players are received by all the other honest players in the same slot so within this 20 seconds this is the synchronicity assumption of the model. A property of the protocol is that all the parties only communicate by broadcast which in practice is implemented by peer-to-peer gossiping but we give the adversarial parties so any parties corrupted by the adversary we give them the power to send arbitrary messages to arbitrary subsets of the players and arriving at arbitrary times. So this is the communication model. So let's now take a look at how the protocol works from a top level view. It's divided into epochs. Each epoch is a sequence of R slots so it's a particular time interval. This would be the colored boxes down there the big ones as you can see each of them consists of several blocks that were produced in this epoch and within each of these epochs we need something that is called a stake taking distribution. This will be the distribution that will be used to sample the winners of the election process and the way we obtain this stake distribution for a particular so for example for the yellow epoch we obtain the stake distribution by simply taking a snapshot of how the assets are distributed in a particular moment in the previous epoch so in this case it would be in the blue epoch and except for the stake distribution we also need randomness and the randomness is produced in the previous epoch by a multi-party computation so during the blue epoch there is an NPC running which leads to an unbiased probably unbiased randomness that is then used in the yellow epoch to to sample the winners of the election. These are called slot leaders in Uroboros so this for every slot as I told you about these slots for every slot we elect a unique player that is allowed to create a block in that slot and the sequence of these players these slot leaders is called a leader schedule and that is sampled using the stake distribution and the randomness that I described to you and that come from the previous epoch so this circle of epochs that each of the epochs relies for its stake distribution and randomness on the previous epoch this is how Uroboros looks from a very top level perspective and if we want to analyze the security of Uroboros then well if I want to tell you something about it I will go and I will approach it in the same way that we do in that it is done in the paper which is doing it in two steps first looking at one single epoch assuming that the stake is static because it's there is a just a fixed stake distribution that is being used for sampling the slot leaders and the randomness is clean and given at the beginning this is called a static static setting for example and then I will tell you how to bootstrap to analyze the whole protocol and the sequence of these epochs so first let's take a look at the static case we assume that there is a genesis block that that contains the public keys of the players together with their stake with the proportional stakes these are given at the beginning and shared by all the players and we also assume that there is a sufficiently long clean random string for the leader election and now we are going to look at one particular epoch of length R and try to show that during this particular epoch persistence and liveness is achieved so as I said in this static case the leader selection is simple there is just a public publicly known function L that takes the randomness of that is to be used for this epoch and generates all all the leaders the generates the whole sequence of the whole leader schedule in such a way that each leader is selected independently from the other leaders and proportionally to its stake this is what one would expect and since the function L is public and the randomness is public the whole leader's leader schedule is public as well so everyone knows the leader schedule in advance then we can talk about when is a blockchain considered valid it has to start with the with the genesis block that is agreed upon everyone knows it it has to contain a sequence of blocks of course that are associated with increasing slot numbers and each contains a hedge of the previous one and they contain non conflicting transactions but what is important is that there doesn't have to be a block for each of the slots because maybe the the unique slot leader that was chosen for that particular slot did not produce a block maybe he was malicious maybe he he was offline for whatever reason so we consider the chain valid if even if there are slots without blocks but each of the blocks has to be signed by the leader of the slot to which this this block claims to belong this is important and that's why the structure of the blocks in uroboros is as follows it contains of course the transaction the hedge of the previous block and the slot number but on top of it it also contains a signature that comes from the from the secret key that corresponds to the public key that is present in the stake distribution right so the stake distribution is simply a distribution of stake over public keys and then this can be used to to verify that the block was actually signed by the proper proper slot leader for that particular slot so the protocol in the static case looks as follows again the the the party collects all the transaction that sees on the network and the collects all broadcasted blockchains it adopts the longest one as its current state and then if the party figures out that it that she's the leader of for for the particular slot currently happening it just creates an additional block signs it and broadcasts it to broadcasts it to everyone and this block is of course created on top of the longest chain that the party has seen so far so you can see that deliberately and by design this protocol is very similar to what is happening in bitcoin although we get rid of the of the proof of work aspect and the the election looks different in particular it's important to to observe that it's also a longest chain rule protocol so we do have this longest chain rule that governs which which chain is to be considered the current state however the analysis is is different in many or in several crucial aspects from bitcoin namely in our setting the the adversary in contrast to the bitcoin adversary has several additional powers at its disposal first of all it he knows the entire sequence of leaders ahead of time because as I said it is public and and second of all he can generate multiple blocks per multiple blocks per every slot where he is the slow leader because this is this is basically for free it only costs you one signature to generate a block so this this extends the powers of the adversary that's not the case in proof of work where you have to work hard to to create every every block and so an obvious question is how much does this increase the power of of the adversary and can we prove that it doesn't allow him to disrupt the security of the of the blockchain what what the paper does is it introduces a framework to describe the combinatorial behavior that is happening when when we are extending this this chain in this in this manner that I described to you with some slots belonging to honest parties and some slots being controlled by the adversary so to talk about this we will we will use the notion of a characteristic string which is basically just a binary string a string of zeros and ones that that describe how the slots are distributed among honest parties and the adversary so it's a string of our bits and the zero always means that the slot leader for the particular slot and that at that position is an honest party and one means that it's a it's an adversarial party so you can you can notice that this string in the execution of the protocol is just binomially distributed with the parameter 1 minus epsilon over 2 where where this is the the the relative stake of the adversary that that we assume in the in the in the in the distribution of in the stake distribution and the hope would be that as the adversary controls the minority of the stake it will also control a minority of the slots so less than one half of the bits in this bit string will be will be one and the hope is that this is sufficient to observe that that the dynamics of the protocol as it will be happening will will lead to persist will achieve persistence and liveness so let's see let's see how to go about that how to how to actually show this so as I said the goal is to to show persistence and liveness but it is well known that in blockchain based protocols one can actually show three more basic properties common prefix chain quality and chain growth and these three properties together imply both persistence and liveness this this is from the gkl 15 work where common prefix simply means that any two chains possessed by any two honest parties potentially at different time moments have the property that if you cut k the final k blocks from one of the chains it will become a prefix of the other one this is common prefix chain quality is a property that shows that that says that any chain possessed by an honest party has the property that at least one of the blocks within the last k blocks was honestly generated by an honest party and chain grown growth simply means that there is a lower bound to the to the growth of the chain at every at every sequence of say k slots actually it turns out that the most difficult property to to prove for roboros but also I think in general is common prefix and so I will talk a bit about how this is achieved and then very quickly glows over the other two properties so but to get some intuition let's let's take a look at an example of how the dynamics of the protocol works so let's imagine that we have this epoch with what nine slots and we have a we have an agreed upon genesis block and we have a characteristic string down here I remember that zeros mean that this is an honest honest slot so the slot leader for that slot is honest and one means that that the slot leader is adversarial so what can be happening so the first slot leader is honest so he follows the protocol and he simply creates a block that extends the longest chain which is just the genesis block that's easy then it's adversaries then is the turn of the adversary and of course he can he can just create a block that does not extend the longest chain but creates an alternative chain then it's an honest player's turn again and as we know the protocol says that the honest party should extend the longest chain available the longest chain it has seen so far but in case there are several chains of the same length to be on the safe side we we we let the adversary decide which which of the chains will be extended by by this honest party to be yes to be to be on the safe side in the analysis so for example let's say in this case the adversary makes the the honest party extends this upper chain then it's adversaries turn again he can do something like this for example then it's an honest party's turn but what and maybe the honest party extends this one because both of the chains were of the same length but then what the what the adversary can do is only at this point creates additional blocks that belong to its to its slots and then use these blocks to convince the the next honest party to extend this new third middle chain right then it's adversaries turn again maybe maybe he doesn't use his slot and in the next one he does produce a block as you can see in the in the slides and finally makes the the last honest party extend this this longest middle chain so what we can see from this toy example is that the dynamics is already far from trivial even in this simple static setting and what different paths in this in this tree that you can see correspond are basically different histories of transactions so and even here with with minority of adversarial slots the adversary was able to create three of them even though they are of different lengths and so we would like to to show that it can never happen that the adversary manages to create two alternative histories that have forked sufficiently far in the in the past and and are of equal length because then basically the the honest party doesn't know which of these histories to believe and and persistence is clearly violated right and to be able to show this formally there is a there is a forks calculus introduced in the paper where we formalize this where this notion is is formalized we talk about a fork which is which is just a name for for such a such a tree as you can see up there and which is an abstraction of what were the chains that were being sent around by by parties so it's a graph that indicates these these chains nodes of course correspond to blocks edges correspond to this predecessor relation we have a genesis block there we we this this double circle nodes correspond to honest blocks and single circle one correspond to adversarial blocks all nodes are labeled with their slot number with the number of the slot that they belong to and each node has a unique edge of course to a previous previous node with a smaller label what is important to to notice is that according to the protocol all play and to the according to the model all players hear all honest broadcasts and honest players speak at most ones in any slot and what these two observations mean for the for the graph is that any honest slot is associated with exactly one honest node and the depth of any honest block exceeds the depths of all previous honest blocks because if an honest party broadcasted the block then any later honest party will not be willing to exceed to extend a chain that will be shorter than the one that this honest party already broadcasted this is due to the synchronicity assumption of of the broadcast so formally a fork is a for a particular characteristic string w is a labeled rooted tree where each node is labeled by by an element from from zero to n and it satisfies the four conditions that the the root is labeled with zero edges are directed away from from the root labels increase along each of the paths honest slots so the slots that belong to that have a zero in this characteristic string they label unique vertex and the depth of the honest vertices increase and any any tree that satisfies this for condition is called a fork for the particular string so if we fix a string there is a large set of forks that can potentially occur as the dynamics of the of the protocol evolves and we want to argue about all of these forks and so the idea when we want to prove common prefix property for the for the protocol our goal is to show that if we start by choosing this characteristic string from this binomial distribution that I told you about then the probability that common prefix will be violated is is small is negligible but the way we want to go about it is to actually show that if common prefix would be violated for this particular string it would mean that a very very obscure fork has has occurred so the graph has some very unexpected properties namely namely there are two widely diverging paths so there are two long parts that have diverged from each other a long time ago this this would be necessary for for a violation of common prefix and so we can try to just show in a combinatorial way that over the probability of sampling this characteristic string with overwhelming probability we end up with a string that doesn't allow a fork that would have this this undesirable property so none of the forks that are admissible for this particular bit string would have this this undesirable property and this is the way we want to go about it to just show that this is not this this is far from straightforward okay so first the first definition we call a string such a bit string we call it forkable if it has this property that there exists a fork there exists this graph this this tree that has two two paths that are of maximum length within this fork and they they diverge at the beginning so they have no no overlap except for the genesis block and here is a particular example in an interesting one where we have nine nine slots three three honest one then three adversarial one and then three honest ones again so the adversary only controls one third of the of the slots but what it can do is okay let the let the honest guys do their job then create an alternative part of length three let the let the final honest guys create the extent his upper chain and then exposed create an additional three three blocks in the lower chain and this basically creates two paths that are both of length six and they they the only intersect the only block in the intersection of these paths is the genesis block so this shows that this string this particular string of length nine is forkable even though it only contains one third of adversarial slots so this is this is this is a bit worrying when it means that the analysis will be will be quite involved and what actually what one can observe quite easily is that no string of density less than one third is forkable so this is like a corner case the adversary needs at least one third of of ones in the string to be able to to to create such a fork so if we were aiming for one third security would be basically done quite easily but but what we what we what uroboros is aiming for is a security up to up to adversaries that contain any honest any any arbitrary large minority of of the stake and this this turned out to be much more involved so of course one can observe that if the adversary controls more than one half of the of the slots the string is clearly forkable because the adversary can just ignore whatever the honest guys do and do his own stuff and make it as long as he at least as long as the honest parties but what is interesting is this space between one third and one half and to be able to say something about it we need to to argue probabilistically so we have to to count in the distribution of these forkable strings this binomial distribution that I told you about and ask the question what is the probability that the particular string that is sampled from this distribution will be forkable in this sense of this definition and this is a this is a question that is answered already in the uroboros paper but the a stronger bound is achieved by rassel adal in a particular write-up that you can find on eprint in the way in the sense of this theorem which says that if we draw this speed string from a binomial distribution with this parameter one minus epsilon over two which corresponds to the to the to the relative stake of the adversary then the probability that the string is forkable decreases exponentially with the length of the string and this together with the reduction theorem that basically says that if a bit string permits common prefix violation then there must be a forkable strict substring of a particular length somewhere in the in the bit string this together with the theorem and via union bound of course gives us the desired result that the common prefix violation can also be upper bounded by a similar exponential bound so I will briefly I will briefly talk about how this theorem is is proven it's via a martingale argument and the relevant feature that we that needs to be looked at is two-dimensional quantity that tries to capture some properties of the longest chain so far so it's a quantity that evolves as the as we are processing the bit string and it captures the the some properties of the longest chain in so far in this in this tree and the second longest chain these are the it turns out it's sufficient to look at these two of course they they may change throughout the the running of the experiment but it's such a two-dimensional quantity I will now try to show you what this quantity is so let's introduce some hopefully intuitive terms for that so if we look at the at the fork like this one in the picture below and we look at the particular part in it let's let's look at the part denoted by T that's the the one the the upper one then the gap of T is simply the difference in the length of this part from the length from the longest part that is present in the fork so for example the gap of T is four the reserve of this part is the number of adversarial slots that follow after the end of this path T so in this case it's three because the adversary has three slots at his disposal after the end of this of this path why is this important because if the adversary decides that he wants to do so he can extend T by at most three blocks just whenever he wants because he has control over these slots right and and the reach of T is simply the difference between the reserve and the gap and and the intuition is that the reach of a particular path tells us how much can the adversary extend this path if he wants to with respect or relative to the longest part in the in the in the fork right so in this case the reach is minus one which means if that if the adversary wants to make the path it tries to make the path as long as possible it would he could extend it to to be one block shorter than the longest part in the in the fork and we can go one level higher and look at the particular fork and say that the reach of the whole fork so remember the fork is just this this tree is the maximum of all reach values for all the paths in the fork and the margin of the fork is the second best disjoint reach so so the the reach of the second longest completely disjoint path in in this tree and then even one level higher we can talk about a particular string characteristic string and we say we define these two quantities rho and mu where rho is the maximum reach over all forks that are compatible with this string so if you have a string you have a set of all forks that that belong to to this to this bit string to this characteristic string and rho is the maximum reach of all of them and mu is the maximum margin of all of them and then not so difficult to see fact is that that the characteristic string is forkable if and only if the the mu quantity turns out to be non-negative for the for the whole bit string this is intuitively this is because it means that if the there exists a fork for the particular string in which if the adversary wants he can extend the second longest disjoint chain to the length of the longest disjoint chain which means he can produce two histories that are of the same length and they fork at the beginning which means he can puzzle all the honest parties and violate persistence and so what we want to achieve is to show that with this distribution of the of the characteristic string the probability that mu is non-negative is is negligible and the idea that is that is followed in the paper is to analyze this powers random variables well for this distribution of of w and with some work one can show that actually these two quantities inductively follow a particular recursive expansion that I show you here how how these two quantities evolve if you add a zero or a one to the end of the to the end of the string and you can actually define a related martingale to to these random variables lambda and mu okay it should be actually row and mu and then you can apply as my inequality to this martingale and this will give you the the result I will know not go into into that but I hope this at least gives you the intuition of how the proof goes and this concludes the proof of common prefix thanks to the reduction that that I already mentioned to you okay so so this was about common prefix chain growth and chain quality and I will just mention that of course persistence and liveness follow from these three properties in a quite standard way okay so this establishes that the static the static part of the protocol which only describes one epoch does achieve persistence and liveness as we wanted in and this can be formally established but now we we need to somehow bootstrap and get to the to the dynamic protocol where where one epochs follow one epoch follows another and for this as I said we need we need randomness we need updated randomness for the new for the new epoch to be to be used for sampling the slot leader slot leader schedule and what uroboros does is it uses a secure multi-party computation as protocol to generate this randomness with using the blockchain itself during this epoch as the communication medium and the randomness that is then generated is guaranteed to be clean as long as the majority of the stakeholders or the slot leaders for that particular epoch are honest and the tool that we use for this protocol is publicly verifiable secret sharing where which is a protocol where with the dealer and the family of players where the dealer can choose a value and share it to produce shares for each of the each of the players and then players can both check whether the broadcasted shares are valid in the sense that together they they really reflect the consistent value and also if it is valid then majority of the players can reconstruct this value but the minority of the players can learn nothing about the value and this is very useful for the goal that we have because we can simply make the parties use pvss to share a random string that they generate and after all the and also what we do for efficiency reasons is that the parties also commit to this string and after all these commitments are put into the blockchain the players simply open the commitments and explore the values to get the new randomness but if someone fails to open his commitment then the pvss shares can be used to reconstruct his value and and in this way achieve the clean randomness for the next epoch when it comes to practicality of uroboros it was actually implemented by iohk as as the consensus algorithm are underlying cardano there are several ways how one can look at the performance one that is also presented in the paper is that one can compare how much time one needs in minutes to to achieve 99.9 percent assurance against an adversary that is trying to make a double spending attack where in the case of uroboros we can model this attack we can do actually the optimal attack that the adversary can do for a double spending this follows from the four calculus that i showed you in the case of bitcoin we only do the double spending attack that you would expect the the simple one so potentially there are better attacks against against bitcoin but this already this attack is sufficient to show that actually this comparison turns out significantly in favor of uroboros so you can see several you can see how this this turns out for various values of the adversarial either stake ratio or computational power ratio and there are two columns for uroboros one is the general one which is assuming an arbitrary adversary that's what we have done so far but the other one which I think is is relevant for practice as well or maybe even more is assuming a covered adversary which is a weaker adversary that doesn't want to give away that he behaves adversarial is for example he's not willing to sign two blocks that would belong into the same slot because that would clearly identify him as being malicious and there might be some out of band ways to to punish him or this is not specified in the protocol but but there might it might be undesirable for the adversary to give away that he doesn't follow the protocol and if he decides to operate in such a covered way the guarantees are of course even stronger okay so that much for uroboros and let me now describe how prowess differs from uroboros and what are the goals that we had in mind when trying to design prowess and how do we achieve these goals so in a nutshell prowess is an improved version of uroboros that achieve security in a semi synchronous communication model and despite full fully adversarial adaptive corruption so these are two goals that uroboros achieves and the tools that are used to to achieve these goals are local and private leader selection forward secure signatures and using hashing to obtain randomness and i will now go into into the details of both of these these goals that we achieve and all the three met tools that we used to achieve them and hopefully give you in a limited time a brief overview of how prowess differs from from uroboros so you can see these two goals that that we have listed up here as basically strengthening of the adversarial powers in the model that we are analyzing uroboros in so the first strengthening is that we assume semi synchronous communication so the black text on the slide is simply the slide that was describing the communication model for uroboros in the original paper and the red text highlights the differences in the model in which we look at prowess so now we still have slots but the honest players are only guaranteed that the messages from them are delivered to other honest players within at most delta slots so with some delay and this delay is fully controlled by the adversary individually for each message and each recipient the adversary can decide how this message will be delayed and this bound delta is unknown to the product to the protocol so the parties cannot cannot exploit the knowledge of delta and what we show is that the security of prowess probably degrades gracefully with increasing delta of course you with increasing with worse and worse network you cannot maintain the same security and performance but it degrades gracefully which is not this did not follow from the analysis of uroboros because the that analysis only assume synchronous communication and the second strengthening that we that we make strengthening of the adversary is that it can make immediate corruptions so it can just at any point in the execution of the protocol it can corrupt any party and immediately obtain all of its all of its memory including its secret keys and act on behalf of that party this is was also something that not only was not captured by the by the model of the original uroboros paper but also would be disastrous for the protocol because because once the once the slot leader schedule is public the adversary could just corrupt the slot leaders and he could he could hijack the chain so the only restrictions that the adversary still needs to to obey is that it still only can corrupt minority of the state throughout the the experiment and we still assume that the state shifts are happening at the bounded rate so this is the second strengthening that that we apply to the model and the three tools that we are using to be able to prove persistence and liveness also in this doubly strengthened model is so the first tool is that we use local private leader selection remember in uroboros we chose the the leader schedule publicly here we don't do it we use a tool called verifiable random functions which is a cryptographic primitive that basically consists of two procedures one is called evaluate it so vrfs are like a public public key cousins of prf of pseudo random functions and so the first the first procedure called evaluate needs the secret key of the and using the secret key it and it takes an input and produces the corresponding output which is unique for this input and this key it looks pseudo random to anyone who doesn't know the secret key and the function also produces a proof so that the party owning the secret key can convince anyone else that this is indeed the output for that corresponding input and the secret key and then of course there is a second verify procedure that allows you if you only control the public key it allows you to check that for a particular input the corresponding output and proof are correct so this is a vrf and you can use it in a natural way to to get a leader selection lottery for for deciding slot leaders in a in a local and private way so every stakeholder simply has a his own secret key for a for a vrf and he just plugs into this vrf the randomness for that epoch and the the slot number and looks at the output and if the output is smaller than some threshold that that is derived from his particular stake ratio if it is smaller than than he's just a he's a leader for that slot an interesting point here is that this function phi that that creates the threshold from your from your stake needs to be sub linear with respect to the stake as opposed to the case in world boroughs where the where the the slot leader attribution was public because if if it is public you can you can actually make it linearly proportional to your stake but that's not the case in the in the private leader selection case if you want to maintain in what we call independent aggregation which means that if you have a particular pile of stake it doesn't help you to split the stake into several piles and pretend that you are several players to increase your chances of becoming a leader if we want to maintain this property then the function actually needs to be sub linear so we have such a function in browse a similar construction was also used previously in the nxt cryptocurrency and also in algorand for for doing private leader selection it's actually not enough to use an arbitrary vanilla vrf a generic one because we need some security also in case when the keys of the vrf are adversarially generated because every player will be generating the keys for himself so we don't want corrupted players to be able to win to cheat the leader selection lottery by improperly generating the vrf keys but in the paper we give a use a functionality of a vrf that is sufficient for this for this task and we also give an efficient realization of it assuming random oracles and computational diffie helman assumption and what is interesting about this local and private leader election is that it produces empty slots and multi leader slots because now the the leader selection cannot be like synchronized throughout the all the parties so if every party decides locally whether he or she is a slot leader it means that there will be slots that contain no leaders and there will be slots that contain several leaders and to analyze this and show that persistence and liveness is still maintained we need to make an extension of the fork of the strings analysis I will not go into how we do it but we do it in the browse paper and interestingly now the ratio of empty slots basically how many slots turn out to have no slot leader is a protocol parameter that's and it will be hidden in this in this phi function and this actually turns out to be useful because such short leader loss periods help us in the analysis in the semi synchronous setting because they kind of allow parties to synchronize when over the short periods of silence and it's important also to to mention that this doesn't a great performance because now we can aim for much shorter slots because our assumption is not that messages will be delivered within the slot as it was the case for uroboros and the second tool that we use in prowess is our key evolving signatures these are digital signature schemes with a special property where the public keys are fixed but the secret keys can be evolved in such a way that you can update it in every step in our case that would be every slot and even if you get hold of someone's secret key for a particular slot you are not able to forge signatures for previous slots so if any party if a party deletes its its its older secret keys as it is prescribed by the protocol before broadcasting any messages even when when it acts as a slot leader in a particular slot then even if the party gets immediately corrupted by the adversary the adversary can no longer create blocks in in the in the name of this party for past slots and for this slot because the keys are already delayed deleted or evolved and this helps us to to manage to achieve adaptive security to manage with the adversary that is allowed to do immediate corruptions so such a key such a key evolving signature scheme is used for signing blocks in prowess and we also give a uc functionality for for key evolving signatures that is sufficient for this role and and we give a realization of it and the final tool that I want to mention is that prowess also moves away from the mpc to to for generating the randomness for for the next epoch for slot leader selection what it does instead is again turning to hashing because it's much more efficient but recall that there was this basic complaint against hashing which is that the adversary can do rejection sampling and to prevent this what we do is that into every block we include an additional vrf value from the leader so if you turn out to be a leader producing a block you also include a particular vrf value using your secret key for the vrf and these values are hashed together from from the whole past epoch to create the randomness for the next epoch at one at one shot and this means that if with with clean randomness the the next epoch thanks to the static analysis there would be there would be only a negligible probability of violating say common prefix or any other of the desired properties then an adversary who is able to do rejection sampling polynomially many times cannot increase this probability sufficiently to make it non-negligible the actual bound in the paper is much more nuanced but but even this argument is sufficient on the asymptotic level okay right so these are the three three main differences of of prowess compared to Uroboros and the two the two goals that we achieve by by these three changes I will not go into further details and I will if you are interested in any additional details just either look into the papers that are all an imprint or ask me and with this I will finish the talk so thank you for your attention


It's been 18 years since we last saw a cinematic installment to the Matrix. Yes, we've had something close to it in the Matrix online, but never a proper follow-up to the original trilogy. Not that we expected one either, because apparently everything that has a beginning has an end. But now that we've received our first look into the Matrix resurrections, how can it possibly live up to the phenomenon that was the Matrix, more than two decades after the first movie was released? I'm Matt Rogers and join me today as I explain why I unfortunately think it can't. But before we get to that, if you want videos on the latest movies and TV shows delivered straight to your subscription feed, be sure to spank that subscribe button and ring that bell to not miss a single thing. Now don't get me wrong, I do not intend for this video to become a hit piece on the Matrix series, far from it. I have my reasons for loving every movie so far, but as excited as I am for the series to be continuing, we have to remember some important points as to why we, or at least I, initially fell in love with the Matrix. To start with, the Matrix came out in 1999. It was the late 90s, the turn of the millennium, technology in the internet was still a mystery to most. The concept Samsung mobile phones in the original movie were absolutely revolutionary at the time, in a weird way they still are. The fantasy technology and more importantly the special effects used in these movies were cutting edge, with the introduction of things like bullet time and making proper use of slow motion, which for child me it was like watching my dreams play out on screen. Fast forward to 2021 and internet, CGI and far-fetched movie concepts are a lot more commonplace. Nothing quite like the Matrix of course, but I can't imagine what it would take for the Matrix 4 to have that same effect on me. For the action and fight sequences, let's use a very fitting example, the John Wick movies. The fight choreography there is top-notch and although John Wick doesn't have gravity-defying characters going head-to-head, there are limits to what the Matrix can show us that we haven't already seen in the original trilogy or elsewhere. Now I am a huge defender of the Matrix Reloaded. I remember having a VHS of that movie at just 10 years old and watched the burly brawl, the shadow fight and the car chase scene so much that those parts of the VHS burnt out. I really haven't enjoyed an action sequence as much as those in all the years past and sadly I don't expect to again. But maybe my imagination just isn't as big as the Wachowski sisters and returning to what I was saying before I do not have a problem with being wrong on the points I'm making. Come December I will happily eat my words if my now adult mind is blown. On the topic of story, they really need to go nuts here for it to be taken seriously. If they do what I'm scared they're going to do, a neo-amnesia thing where he has to remind himself who he is from scratch, the whole movie is already dead in the water if you ask me. My prediction and probably the most obvious plot goes as follows. These people we see in the trailer come to fetch Neo as they need his help for something. He's been taking the blue pills to forget about the events of the first movies but the call of the matrix is too strong. We see him pass through the liquid mirror once again then after reintroducing himself and remembering he is the one he realises he needs Trinity for insert plot point here and he initiates her like she did to him in the first movie. I don't know it's not a bad concept and I may be entirely off base but main characters with amnesia is becoming a meme at this point and it's not a mind bending enough concept for my liking. But on the other hand since the story wrapped up in revolutions it kind of gives the writers a blank page especially since it's been established that characters that were very dead in revolutions are now back. The animatrix did a great job at filling in blanks that we didn't realise were there, maybe this movie will assist in doing the same. It's been confirmed that Lawrence Fishburne unfortunately won't be returning for this film and reportedly wasn't even invited to. But if the matrix online is considered canon Morpheus is killed by a masked gunman whilst placing a bomb in the matrix to get back in the machines. But who we see here in the trailer very well could be a young Morpheus and who knows maybe a cameo by Fishburne is being kept under wraps it is called the matrix resurrections after all. With so many potential plots and story threads I guess it's worth hearing what Keanu Reeves himself had to say about the movie. Director Lana Wachowski had this to say. Quote we showed the film to Keanu and he was really blown away by it and he said something that was typically Keanu where it's incredibly insightful and he's just sort of sitting there and you don't expect some incredible revelation to come out of him at that moment but he like casual brilliance just rolls off of Keanu and he was just sitting there and he goes 20 years ago you told a story in which you described the coming 20 years and the problems of the nature of digital virtual life and how it was going to impact us and how we think about it and gave us a frame to be able to think about it and talk about it and you took the same character and the same stories and the same stuff and somehow you made it about the next 20 years and he was like how do you do that? Keanu Reeves wise as always and let's hope he's right but let's change gears I want to talk about the style choices that we've seen so far. The trailer isn't much to go off but that's really all we have so far. Is anyone else disappointed that Neo looks exactly like John Wick? We all know Keanu Reeves found his look with his long hair and stubble which obviously suits him but that's just not Neo to me. It's literally the exact same look as John Wick and it's almost like this movie in John Wick 4 will be hard to differentiate for more reasons than one. I'm sure he wouldn't look as good as he did with short hair and a close shave and maybe I'm just holding on to the past but that was my initial reaction. For the iconic Matrix costumes the trailer again doesn't give much away but I'm begging to see those trench coats again. The wardrobe of the cast became such a big part of the original trilogy and it would be a shame to not at least have a call back to that. Give us the sunglasses at least. I'm also hoping for some standout new characters too. Remember characters like the twins? They were such a great concept with the interesting ghost mechanics which added so much to the car chase sequence in Reloaded. Give us more stuff like that. We are getting aggravated. Yes we are. Another iconic aspect of the Matrix is its music. Who could forget the rage against the machine ending to the first movie or the electronic and orchestral score by Don Davis and features by Juno Reactor? Part of the appeal of Reloaded for me was the music and I don't think anything quite like it has been done for any other movies since. Scoring the Matrix is a tough gig and unfortunately they don't have Don Davis returning to the composer's chair this time and apparently he wasn't invited back either which is a bit of a concern. I would have loved to have had just one more soundtrack from him and Juno Reactor. Confirmation of the role of composer has not 100% been confirmed but it is said to be Johnny Klamek who worked with the Wachowskis briefly in Revolutions but more so in their TV series Sense 8. I'm not too familiar with his work but looking through his discography I did enjoy one hour photo which is another one of the best movies of the early 2000s. But will he be up to the task of scoring something as complex as the Matrix? I guess we'll have to see. All this to say I know I'm being a pessimist here as there is a lot that could drag this movie down but I really hope I'm wrong. What I would give for this movie to become a classic in its own right. But what are your thoughts? Do you share my pessimism or have you got a whole other outlook on it? I'd love to hear what you think so let me know. I'll be down there in the comments. But be sure to subscribe for weekly videos covering your favorite movies and TV shows. If you subscribe during this video then walk on the board and if you had a good time hanging out then spank that like button. This is Matt Rogers and that is all.


CircuitPython is code plus community. And one of the best ways we have of celebrating that is with the Python on microcontrollers newsletter. So this is a weekly newsletter. You can subscribe to it by going to AdafruitDaily.com. Just put in your email address. Request the newsletters you'd like to get in your inbox. And you can also go and check them out here on the web page itself. Right on the home page is a link to this. And this is this week's episode or edition of the Python on Hardware Newsletter. And I'll just point out a couple of things that I thought were notable from this week's edition. First of all, there are now 100 CircuitPython Blinka compatible single board computers. So this is things like Raspberry Pis and Onion Pis and Rootabaga Pis and Asparagus Pis. I don't know all the different ones. But if you're like me and don't know all of them, that's OK, because this newsletter has you covered. You can go and click on the link here and check out all of the Beagle. There's another one, all of the different boards that are now compatible with Blinka. Let's see. Also, we have, let me check my notes over here. This out of the way. Oh, there was an advent of code calendar. This looks interesting. These are some small programming puzzles that you can open up one little nuggety, bite-sized, little delicious puzzle every day as an advent calendar. So there's a link there that'll take you to that. Speaking of holidays, check out this, you guessed it, Hanukkah light saber. So this is great. This is a Circuit Playground blue fruit and a strip of 30 NeoPixels doing a persistence of vision method where you can use long exposure photography and draw some different Hanukkah-based things in the air and take cool, long exposure photos of them. There is a menorah and some dreidels, and there's a nice little explanation of it in here, and this was found on Instagram. And by the way, if you find things that you think belong in any of our newsletters, there's a link at the bottom that will tell you how to go and submit those changes or submit those news items. This is also another nice one. This is a three-printed Plex server using a Raspberry Pi, but it also uses Circuit Python, I believe, for all of the display stuff to give you systems, statistics, and other information IP address, temperature, and other readouts there. So really cool-looking Plex server or media server. And here's another really nice one. This is our own Todd Bot, everyone's Todd Bot. He's not just our own, he's the world's Todd Bot. And Todd Bot created a really cool Pico Touch synthesizer, another in his ever-growing series of small PCB-based synthesizer things. This one has an octave keyboard of capacitive touch, and also has reverse-mount neopixels pointing up, and he's got some tests up there. This was a link on Mastodon, you can go there and check it out, or just enjoy this gif of touching it, because it's a touch synthesizer. And let's see, another one actually is somewhat related was this one, which is Bobricius, if I'm getting that name right, created this Armachat Touch computer, and it also uses TouchIO to create this full QWERTY keyboard with backlighting, and it's a PCB with a underglow type of technique where the solder mask has been told not to go, and it's a really cool looking project, you can go check that out on Instagram and then find other links for more information. And the last one I thought was really cute clippy there, and then the last one that I was gonna call out, but of course you can see there's lots and lots of stuff here I'm skimming over, so you should go check it out yourself, was, where'd it go? It was the Pine 64 Pico-sized single board computer, I think I blew past it, didn't it? Where'd you go? Where'd you go, Pine? Nope, nope, I'll keep going, keep going. That was a little macro pad, there it is. So this is a, I don't know much about this, and I must admit I haven't followed the link yet, but that is a Pi Pico form factor single board computer. So if you wanna learn more about that and all of these other interesting things, I'll just tease, there's another little new board right down there, the M0 Sense, risk-based computer, or a micro controller, these are all in the Python on microcontrollers newsletter, so go check that out. All right, let me jump back here.


ঠিকলং দ conte��ώςদা� Beispiel নানangers�া লоде�আ ডিকব অক�을 মাকইНА ��িতকাযিhea�য� contrad ওিনড নাকairs Disc Other মানyszॸ দানপি ততরই গাট� NHিক� Winston তক� billi tell install such a journey, মাকলানগা �aggi� испыт�তা�aczy�চো� Museum తత్ వి పంధేరో మాపనార్న 번 cooling కైస్ అలనఝనా costs reserved 161 estim per day బన్ మిడి న్ ఇఆవెపఠ Ching 2020 న్ పనిమాకూ అంALI �teilఒ న్ nevertheless, the people around thus reached Royston franklin on their new year cancellation from Christmas. The envelop said atal tunnel built their rebellious look which is why they reached New Year and sent their Christmas greetings for each快Sems. This Way they reached Royston franklin on Christmas night.


Hello everybody and welcome to the Jenkins Pipeline Authoring SIG. Today is Friday April 3rd. This is our weekly meeting. Welcome to everybody. I do see we have a few new people on the call. If you would like to introduce yourself, you're more than welcome. If not, that is okay. I'll give you a moment and if you'd like to introduce yourself. Hello everybody. My name is Jason. Well, I'm just starting to work with Jenkins. I'm pretty interested in knowing more about what this group is. Thank you very much, Jason. And welcome. We're awesome to have you. Super awesome. So thank you very, very much. With that, I am going to share my screen. I'm going to hope I do this right. Before we get started, I would like to let everybody know that this meeting is governed by the Jenkins Code of Conduct, which basically amounts to be nice to one another. Let's see. We'll go ahead and get started on the open items. So last week we did not meet because there was all kinds of things happening with myself and other people were busy.  I would like to start off with covering the roadmap. And I have sharing it on my screen. This is kind of what I came up with and I started doing some of the initial initiatives. These are not hard initiatives. These dates are not hard dates. I just wanted to get something started and really open it up to the rest of the community to start to help set the sort of the roadmap for this particular SIG. I would also like to mention that the idea for creating this roadmap is to roll up into the JEP roadmap that was approved by Oleg and PRD. I don't have a link to that PR right off the top of my handy dandy interweb, but I think everybody may have a chance to have seen it. Is there any questions, any comments, any concerns? I think this is a fine start and we can always add things as we go. Right. I just wanted to get the format sort of up there, put sort of what the ideas would be. I put the GDSL on because I really do want to see that come to fruition from a sort of upkeep and maintain maintenance standpoint. But again, these are nothing that are hard. I know we've worked on the personas, the roadmaps and the documentation. So, again, this is just to get us started and feedback is welcome. What I do believe this document is open to everybody to comment. It is open edit ability to you, Liam. And the reason for that is just general safety. We don't want to have people come in and start messing around with things. Yeah, not to, not to be the gatekeepers. It's certainly not that. So with that, this is the roadmap. We can change it. We can add to it. We can take away. I just wanted to get something started there. I would like to, I don't want to set an artificial timeline on getting this completed, but I would like to put something out there to say, we'd like that we'd like to have this completed by X. What are your thoughts on that. I, this is Liam. I prefer that we actually sort of follow the lead from the overall roadmap, I think, which is, which doesn't have target dates. And the reason for that is I don't want to, for people to feel like this is that we are not succeeding if some specific date isn't hit. This is a volunteer organization. Things happen and like that means I think that it both sets an expectation that that may not be met and then also sort of it just might make make anyone doing the work feel less good about it if it doesn't get done on some schedule. I agree with that. I agree with that. So then maybe what we could do is is I can maybe I need to just take out these this whole timeline as far as I mean what we have is two main things right now three, three, four right then we're we're working our way through them. So I mean this is this is fine. I suspect that we're going to pull into the the overall roadmap or otherwise we can emulate it and or you know make it make a subversion of it. That would be great. You know what I think I can I can take that action item to sort of plagiarize it and then we can tailor it the way we need for for our SIG that probably will be a good good thing to do. I will take that action item. Okay, thank you. So there'll be another document coming before next meeting. Okay. So that takes care.  I apologize. The Jenkins roadmap is live on Jenkins.io. It's admittedly still in draft, but the pull request was accepted. It's visible and being refined. I like the conversation we had in discussing the roadmap that maps of roads do not in general have dates on them. So my full support that maps of roads do not have dates. They don't need them. Right. Yeah. A map of a road talks about destinations and and possibly steps along the way to the destination but it doesn't really need or benefit particularly in a community project from having dates associated. So my full support to delete the dates across the top. Cool. Awesome. Okay. Thank you so much for taking care of that. Does anybody else have any input in regards to road maps getting rid of the dates, which I do fully support. It's artificial, but sometimes in my head I think like in the business side so I'm thinking we've got to we're working in a sprint and we've got to have dates and burn downs but I have to sometimes remember that's not the case for when we're dealing with open source. So I just sent to the docs mailing list and invitation for people to suggest Docs roadmap items as well and my intent there I propose to use a actually condorsed style voting technique, gather the ideas and then ask people to vote. You know, this, this feels like a great, a great effort as well and let's, let's encourage people the crucial thing for me as contributors are deeply profoundly highly valued. Overall, this is an amazing step forward for the community as a whole, because it's showing that we're, we're, we're all coming together and trying to drive us down a road. I like, I see where the motif is now, we're all trying to do that. And I think the beauty of all of that is everybody has a seat in the car to drive down that road or on your bike or you see why I'm going right so I'm trying to package that all up. Alrighty, so that takes care of road maps. Next on the list, we had there was I added these items in. I do not see. They may be here. No, I don't think so. Craig here so it. No, so for Craig, if you are watching the video, we are talking about the items that you wanted to be on the agenda. I would like to add something, which is an echo to what Oleg has stated that these, these type of bugs don't really fall under this sig. I do think that these are items that we can help maybe get looked at but I don't think they fall under this sig. I'm going to step back from that and let you, anyone else add anything that they may like to in regards to this. I'm, I'm, I have some to say but I'm waiting to see if anybody else has anything to point out here because I tend to talk so I'm. I also agree with Oleg so I that's I also don't have a lot to say. I will try and advocate for a perspective that I'm not sure that the perspective that I don't agree with which is these are pipeline bugs. And so I can see how it's how it's reasonable to want, want them at worked on, and to want to gain them greater visibility and to say well, this would be one place to get that kind of traction, right. But I don't, but as you said, I don't, I don't think that this is the venue since this is more would say that this, this group is more aspirational about where we're going and how we can help a larger community not work on individual specific technical bugs. There are already people doing that and the fact that their time is limited and that some bugs are not getting as much traction as anyone would like really there's no there's always more to be done and there's resources is not it's it's unfortunate but there it is right. Yeah. So, I think that well this may be I'm trying to how do I say this. Well, this may be a place that I, I think it would be good for this type of an issue, or issues in general that are related to a particular Jira would be better served in the getter channel. Through asynchronous communication, as opposed to this meeting because I agree this meeting is more of a larger, like how are we driving this initiative of pipeline authoring forward. Having said, if a, if a particular issue or person concerned about an issue feels that they're not getting the needed exposure to the to the issue, then maybe this could be a place that they bring that up to voice that concern. I don't necessarily think we are structured currently in such a way that we could help be a sounding board for that or get the help acting for a particular issue. I think I'm rambling and I apologize, but I mean, we're a group of experts so and members of the community so we can, we can help out direct people but that doesn't necessarily mean that, you know, the, the, one of them is more of a technical side the other one is actually maybe more in our, our wheelhouse, which is talking about adding a, adding a, improving the usability of pipeline by adding a link that will lint a pipeline, run the linter on a declarative pipeline to the web UI, for example. That is a very, very good suggestion. Yeah. So, yeah, I commented a little while ago on it's 52939. It's sort of a squash together issue that has like, we also, it was filed by Craig, actually, and so he said I want this and I also want to do a reload for this other larger technical issue which has been around for a long time is harder to do. So, that, so, but just getting a link, the link side of this is actually probably a reasonable thing that can, that we can do. I don't agree now for now, and anybody please jump in if you think wrong, but I think we can at least agree for now that a this is not this meeting is not the venue to address certain things like that. So, those things addressed, we can maybe say, you know, use the getter channel, and I think I also just to add to that I put in a PR, yesterday that PR was merged to update sort of the structure of our Jenkins.io for the pipeline offering to kind of state, hey, you got to use the getter channel for these things and make sure you've done your, you know, due diligence and research before coming, you know, there. And it really wasn't a change from what was already there it was more just a rewording. So, I think if it does anybody else have anything they'd like to add to this. I don't know what I did with my editing type mode. Much better. Okay, if nobody else has anything to add to this we will go ahead and move on. Okay, and the next item up is. Let me just, let me just, I'll just. Craig, if you're watching this later or if you're on the getter channel. We're happy to, you know, discuss this again just come back around just like it's one of those things where. It's like, well, you wanted to bring it up, we brought it up. We'd love, we'd love to have your, your view on it rather than any talk about it amongst ourselves. So, anyways, thanks. Thank you very much for that. Okay, moving on to the next thing we are going to talk about Jenkins Docsig seeking roadmap items. Mark you had brought that up. And I think that is awesome. I have some suggestions. So I think for anybody else that may not have been here when we were discussing that we're talking about, we're overall all there was a larger organizational roadmap put forward. And now each SIG is trying to do their roadmap to sort of roll up into that large organizational roll up. The Docsig is also doing the same thing. And they have, they're open for suggestions and contributions and items like that. Now I know we have talked a lot about previous meetings about the Docs and and how we'd like to see pipeline stuff sort of structured for that. So this is a great opportunity to be able to for anybody watching or anybody here. This is a great opportunity to be able to influence or have the ability to speak and add your value to other SIGs as well. So this is a link to the Docsig meeting notes in our meeting notes. Mark, would you like to add to anything about that. Just encourage people to freely be involved. I'm trying an experiment with this particular request. I'm going to gather suggestions for about a week and after about a week I'm going to put up a condorsed poll that will ask people to prioritize which things they want and then will. Those will take the top two or three and put those on the roadmap. We've had suggestions for Jenkins and Kubernetes for, hey, give me dramatic improvements to how Java 8 is described or the tuning of this or that. All sorts of interesting topics and areas. None of those things should be considered any way blocking or an impediment to the pipeline authoring SIG. You can create and contribute and add anywhere. I would definitely interested in the Jenkins and Kubernetes one. There's a lot more. A lot more coming up on that topic soon. So pay attention to that guaranteed you will see more about that. Does anybody else have any questions or comments concerns regarding the Jenkins Docsig seeking roadmap items. So where do we submit them. I'm looking. So right inside you could either send me email. You could propose some comments into that meetings into those meeting notes. Any of those is fine. You can send me a tweet. Okay, any of those is just great. Cool. Just checking. I've also brought up on my screen to share. Yeah, so scroll down. It's about it's item seven in that list. There you go. There we go roadmap ideas and you look just comment there. And my intent is to collect the ideas. Several of them have backing either email messages or Jira tickets that support and describe hey what is being requested. So that you can think about a little deeper than just the text that's there. Okay, that is awesome. I will do as soon as we're done with this meeting I'm going to go right to this link and add some stuff. Great. Thanks. Okay, so that takes it care of new items. We do have my action item that I will migrate and adapt to Jenkins IO roadmap for our SIG, I will have that ready by the next meeting. And so now we can go into open Q&A or open mic, whatever you want to call it. Does anybody have anything they wanted to discuss. Jason, just just checking in. If you guys had anything in order to bring up. No, actually, I just come here to learn some things. Okay. Great. I'd like to say one thing in regards to the new people joining that really warms the deepest parts of my heart to thank you for joining. Call a friend, bring a friend. I think it's awesome that community we're very inviting and this is the opportunity to not only get to learn, but also to be able to help affect some of the organizational changes that are happening. Thank you so, so much for joining. Please tell a friend and bring one. I was going to make some offbeat statement, but I'm not. It's cool. If nobody has anything else, we will go ahead and conclude this meeting. All right. I thank you everybody. Have a great Friday, great weekend. Be safe out there. Yeah, or in there. Yeah, in there. And if you're out there, six feet, you know, Yeah, all right. All right. Have a great weekend, everybody.


about a third of all our food goes to waste. And by goes to waste, I mean goes unsold or uneaten. Some of that, you know, in the U.S. about 3% of it gets donated. Other portion goes to animal feed or to composting, but the vast majority is still going to landfills or incineration or down the road.


Brandon Schuyler-Umbdahl, specialist, 645th, ICTC, 88 Hotel. Right now we're qualifying on the 50, 50 cal. We just got done with zeroing and did our first table. Now we're getting ready to go hot on the range for the pop-up targets. Practice, practice, practice, you know, because a lot of these skills, when you go on the range, when you're shooting any kind of weapon system or even your MLS, you know, you need to practice it in order to get efficient with it and have it to be second nature. It's a perishable skill when you're shooting, so you've got to consistently go through drive runs at all times. Captain Dave Irvin with Team 1, 3, 3, 40th, 181 MFTB. I'm a 12 alpha combat engineer. Today we're qualifying 645th on the M2A1 50 cal machine gun, shooting 10 meters, zero and transition qualification tables. What they learn here while they're at Fort McCoy pre-deployment, take all that, internalize it, make sure that you remember it when you go down range and you encounter a real situation, apply what you learned here, train hard here so it's easier in the forward fight.


What's good YouTube? This is your boy Chihuahua back to y'all again with another art tutorial man If you're new to the channel go ahead and hit that like button come in subscribe Make sure you click post notifications so you will be notified every time you go drop some heat in today's video I will be showing you guys how to draw fire inside of adobe illustrator. So without further ado Let's jump right into this thing. Okay. The first thing you want to do you want to come over here to your pencil tool Then you just want to Pick any color that you that you want to start with Lot is bottom color And make sure this color is sitting on top. Okay now with our pencil tool. We just gonna draw Out the shape of how fire would look so it's just like It's like wow Freeform you know and it's kind of like Unpredictable at the same time. So Pretty much how fire would be Then you also got you little pieces. That's flying up now that we drew that What you want to do? You want to highlight what we just drew you want to come over here object Expand you want to click merge your pathfinder Now you want to come back to your your swatches You want to find Your gradient any gradient to start out with let's go through the gradient library Okay, we'll start with that It can be any color gradient. Then we're gonna come over here To the gradient so we can tweak the colors Let's uh Let's get rid of one. So we only have two or two transition Now what you want to do you want to find you like a Orange to a yellow of these colors Orange going into a yellow now What you want to do you want to select this and press down on your arrow until you get the orange at the top You know I'm saying so the yellow at the bottom And the orange at the top And we're gonna pull this in some sort of fade Say now that we got that and click off of it. Let's create us a new layer right above it And we can start with any color just so you'll be able to see The difference so I just select it like a pink Inside of a little fire using our pencil tool and all this flow together You see we got our fire The bottom layer lock. So we're gonna grab this pink layer Don't select everything on the pink layer We're gonna go to object Expand and also we're gonna go back to our gradient and just select the gradient to start with now we're gonna make the transition go from White to yellow Let's get rid of that one in the middle all you need is to gradient To switch So you got to delete the third if you got one a little white right here To the angle at the top another thing you can do Create you another layer put it at the very bottom So let the color red affects It's gonna blur get out your brush tool for your blur and that's how you make fire inside Adobe Illustrator man, make sure you stay tuned Moji coming soon And I'm out this thing These are my prices for the cartoon heads man If you was ever wondering how you can get a cartoon head and be featured on my YouTube channel All you have to do is go subscribe to my I mean go follow me on Instagram DM me on there You know I'm saying Place your order and I will get to you I got a lot of people that's in my inbox So it's if it take me some time to get to you just keep that in mind It's a lot of people that's in my inbox trying to place a order. So It's on my price list man. Y'all go ahead check it out You know I'm saying make sure you stay tuned Moji coming soon and I'm out


from Seattle, Washington. Extracting the signal from the noise, it's theCUBE on the ground at LinuxCon North America 2015. Now, here's your host, John Furrier. Hello everyone, this is John Furrier with SiliconANGLE, theCUBE, we are on the ground here in Seattle for LinuxCon, and I'm here at Amjad Afada, who's the founder of DCHQ, startup in San Francisco. Welcome to the on the ground segment of theCUBE. Thank you very much, thanks for having me. So you guys had raised a little bit of cash, a little angel round from Accelerator. You're here at the Container Conference, Linux Conference, all the action under the hood, as we say. Tell us about what you guys are working on, because this is where all the action is. I mean, Docker started here in Solomon's up on stage. You never know, you guys will be the next breakout, the next unicorn. You guys gazing out into the landscape there. Hopefully, yeah, yeah, we're very excited to be here. We're building a platform for managing the deployments and lifecycle management of container-based apps. And yeah, we're very excited. We basically launched the hosted platform at this conference and the second version of our on-premise product.  How many people on your team? We're four. We're four people in DCHQ, and yeah, we're small and nimble, but we develop very fast, yeah. You guys full-stack developers? We, yep. We have full-stack. Of course, you're Linux Conference. Gonna say, of course you are. Of course, yes, exactly. So this is the phenomenon that's going on out now. It's the 10x developer, Mark Andrews, I think coined that term, or someone kicked it around, but it really shows that with the cloud and now with open source, you can have one developer do the role of what you used to take 10. That's essentially what you're living that world right now. So what's it like? You're certainly nimble. You're under-capitalized at this point. You haven't gotten revenue yet. What's the mindset? I mean, before we started this company, I was at VMware and we were working with a lot of large enterprises and we definitely saw a gap as far as Docker container management and that was around governance in general and enterprises were just fearful of this technology because they were afraid of how developers were using it in the downstream environments. And so that's how the idea came about and we quickly built like a governance platform for these enterprises and then we went back to our area of strength, which is application modeling and lifecycle management and now that's what we provide. So downstream, you mean they've just been using a lot of Docker containers. I mean, it's getting out of control. It's like a wildfire, right? That's correct. Docker Hub has been huge in terms of promoting and pushing this technology forward, but at the same time, enterprises were just afraid of what developers were using out of Docker Hub and they wanted a bit more control into how they create the images, who gets access to what template and into what compute resource they can deploy this to. How do customers make sense of all this Docker container management? And that seems to be the land grab everyone's going for here. You got Kubernetes out there, you got all kinds of orchestration, legacy stuff out in open source.  It's a huge opportunity. It's definitely in our belief that's going to be the sort of the next wave of virtualization, but at the same time, it doesn't have to be a complete shift from the way developers are developing applications today. And this is something we're bringing to the table. Today, if enterprises wanted to adopt Docker, there's a bit of a learning curve in terms of learning the Docker file syntax and all that stuff. And so we provide the sort of the automated build feature and if you wanna go with that approach, you can do that. But at the same time, we've been able to allow enterprises to containerize their enterprise IT applications very, very quickly with minimal effort. And that's through by invoking batch script plugins that can customize containers at request time and post provisioning. And almost every enterprise has expertise in shell scripting. So they don't have to learn a new syntax and a new yet a new scripting language. They can just use it. Yeah, we saw the same thing in the Hadoop ecosystem. SQL on Hadoop seems to be the dominant trend now when everyone was kinda poo-pooing that. So that's the common language. So same thing going on in your world, right? That's exactly right. Exactly right. And we just made it a flexible way of modeling very, very complex applications. You can invoke these plugins. You can do the environment variable bindings. We've modeled like a MongoDB shorted cluster with two replica sets, mainly because of our very sophisticated app model. So the trend that you guys are attacking now, if I get this right is, is that the operational aspect of automation and complexity management is what you guys are attacking. In other words, you're providing some abstraction to the management of operationalizing Docker. Is that correct? That's exactly right. We help operationalize Docker as exactly like you said in terms of doing the monitoring, managing the life cycle, doing the backups, the updating of containers, the running containers that is. But at the same time, we're also unlocking a new way of modeling these Docker-based applications for the actual developers themselves. Okay, so how do you get paid? I mean, everyone needs to get paid. You've got to do funding. You guys are going to stop shipping the products and start shipping. What's going on? Give us the update. Right, so on-premise product is now undergoing evaluation at some really big companies right now. So it's in the evaluation mode if you want. And the hosted platform is where we're hopefully going to accelerate the adoption of the startup users. And it's a different value proposition from all the governance and the granular access controls I've been talking about. The startups basically want a cheaper alternative to something like Heroku, where they're paying thousands of dollars a month. They want to be able to use credits they already have on public clouds, like Amazon and Azure and RackSpace.  Is that correct? I mean, does that work? We have two versions. So the hosted platform, you sign up with us, you register your own cloud endpoints, and we just orchestrate the Docker-based application deployments on your own clouds.  So what's next for the company? What's your goals? This conference has been tremendously helpful for us to just listen to the customers, what they want, and we already have a prioritized list of enhancements that we need to make. And we're just looking to continue to improve and grow our business. Are you going to start selling the product? Oh yeah, so it's definitely on sale. So you get some cash in the door, right? Revenue. Absolutely. Yeah, I urge everybody to sign up on dchq.io. We have a three-months free trial, but after that you can see the pricing sort of section in our site, and hopefully you can start paying us. All right, check it out. What's the final question I want to ask you? What's the vibe of the show out here? What's it like here at Linux Condition? What's the big theme? What's the vibe? What's going on? Yeah, I mean, as you said, container is the next big thing. Obviously, that's the main theme of the conference, even for the hardcore Linux professionals in this conference that don't necessarily care about this container technology. They seem to now sort of understand what we're trying to provide and how this can be revolutionary. All right, we're here on the ground at LinuxCon in Seattle. This is the cubes on the ground program. Look for us. It's looking at angle.tv. Thanks for watching.