I'm Lars, I'm Director of Education for IOHK, so I do Haskell courses, just did one for two months on Barbados, but I also feel it's important not to just do education but also do some, get your hands dirty. So I'm also leading the incentives work stream in Cardano and I'm in Hamburg today at the Blockchain Mania meet-up and want to explain our ideas for the incentives at Cardano and I hear that the audience is very technical, so that's quite exciting, so I hope that I can go into quite some depth and explain how it really works, why it's important, what we hope the outcome will be and how we hope to achieve that. In general, the point of incentives is to incentivize the participants in a blockchain system to do the right thing and in our concrete case of Cardano that means we want a certain distribution of stake, so we want that basically there are stake pools, not too many, not too few and that most of the stake is somehow concentrated in one of these stake pools and the idea is that those stake pools actively participate in the protocol and are online when they are supposed to be online and do the things that the protocol demands of them and the point of incentives is now what we have been busy with over the last months to set up incentives in such a way that if everybody follows his own rational financial interest then the outcome will be this nice distribution of stake that we would like to have. Okay, thank you very much for having me here tonight and I want to talk about incentives in Cardano, explain in general what incentives are good for and how we plan to do them in Cardano. So first a couple of words about myself. So I'm actually a mathematician, I have a PhD in pure mathematics from Regensburg University here in Germany and I did one year as a postdoc at Cambridge University in the UK, then worked 10 years in normal software development doing stuff like .NET, C-Sharp, even JavaScript I'm ashamed to say and but during my time in Cambridge I first got into contact with Haskell so I've been an enthusiastic Haskell hobbyist for more than 15 years and then when the frustration got too big in this normal software development then I joined IHK in November 2016 first part time so full time I'm now almost exactly a year and I'm the director of education so that means for example that I spent a lot of time doing Haskell courses, I just spent January and February in on Barbados doing a Haskell course there and last year two months in Athens and we also do things like internal and external trainings on other topics as well not just Haskell but I feel that somehow it's not good to just do education you must also really get your hands dirty so in addition to that I am also leading the incentives work streaming Cardano and that's why I'm here tonight and what I want to talk about tonight so I'm leading it so that means I don't actually do the work so the the team that mostly works on incentives is our chief scientist that IHK was also professor at Edinburgh University professor Kialias Agalos he is also the main inventor of the Robos protocol that Philip introduced then Elias he's a professor at Oxford University game theorist and also senior research fellow at IHK and then Katarina also at Edinburgh University who is Agalos student so as an introduction to incentives so what are incentives well in the most general sense at least in the context of cryptocurrencies it's just the way to encourage people to do what they should do to follow the protocol and participate in it and follow it faithfully and for example for Bitcoin that means mining blocks and including transactions into the blocks to make Bitcoin work and in Cardano as Philip explained it means being online because remember there's this election process we have these slots and each slot gets elected a leader and when it's your time when this slot comes up then you are supposed to be online and actually create the block and you are also Philip explained this thing with people sitting around the table throwing dice and then they have to reveal their number at a certain time so for this process people are also supposed to be online and participate in this protocol so somehow we want to incentivize people to do these things and even though as Philip also explained participating in Cardano is far less expensive than participating in Bitcoin you don't need server farms you just need a normal laptop nevertheless I mean you have some investment and you have to spend time and so on so it's just fair that you also get reimbursed somehow for your trouble and when I talk about incentives then in this talk I mostly will talk about monetary incentives so you get some ADA for your trouble and so I mean monetary in this context of course doesn't mean euro or dollars it means you get ADA our cryptocurrency but that being said one should not forget that there are other types of incentives as well like being idealistic or moral and just the general desire to do the right thing and that should not be underestimated as an example in Bitcoin there's this story from Coin Desk from 2014 there was a big mining pool that accumulated 42% of total mining power and as we know the close-eyed gets to 50% that's the more dangerous it becomes and then what happened was that people members of this mining pool voluntarily left and in a matter of two days it dropped from 42% to 38% and they didn't do that because it was financially good for them on the contrary rather they just did it because they believed in Bitcoin and believed in decentralization and just wanted to do the right thing and ideally of course these two things would align so it should what is in your own best selfish interests financially speaking should also perfectly align ideally with moral with doing the right thing and as we have seen in this example with the mining pool in Bitcoin that's not the case I mean people had to choose between making more money and doing the right thing and our goal in Cardano is to align these two things so that when you maximize your profit you automatically do exactly the right thing and just right and I say we strive for that so I'm not claiming that we achieve that but at least we want to somehow get there and get closer than Bitcoin does right so what exactly is it that we want to incentivize in Cardano so we want to incentivize stakeholders to be online and they have to participate in the protocol for example when they have been elected slot leader for a certain slot then they should be online at that slot to create the block and on the other hand I mean there may be people that are just not interested in doing that or don't have the technical know how to to set up the software in the way that makes it possible or maybe they don't have the time or whatever and it will also be possible for those people to delegate the stake to a stake pool same as in similar to mining pools in Bitcoin there will be so-called stake pools in Cardano and I'll explain more about delegation later right and this is describing what exactly we want so we have these people that own ADA and they can somehow join in pools and actually what we would like ideally would be that about 80% of all the stake all the ADA should be delegated to a number of K stake pools where K should be probably something around 100 so we would like that 80% of all ADA is organized into stake into about 100 stake pools and those stake pools then should be power users that are online when needed and they should also provide additional network infrastructure so-called relay nodes that we need to to make the network traffic more efficient and the it's okay if the remaining 20% that probably will belong to small stakeholders they can if there's a wish also participate in the protocol on their own or they also can just ignore it and don't do anything so that should be fine but this is the configuration we aim for and somehow we want to set up our incentives in a way that achieve that so if everybody does what is in his own best financial interest personal interest then the outcome should be this right so I mentioned delegation so let's talk about this and that's another team we see Agalos again as I said he's chief scientist in at IHK so he does a lot of things so he's involved in coming up with the delegation scheme then one of his students Dimitris was also at Annenberg University and researcher at IOHK and then Mario who is originally from Brazil I believe and who is at a lecturer or professor at Tokyo Institute of Technology and also research fellow at IOHK and so steak in because as Philip explained Cardano is a proof of steak system so holding steak means more than it means for Bitcoin to hold Bitcoin so I mean on the one hand Cardano is a normal cryptocurrency so of course by owning ADA you can just use it as any other cryptocurrency you can use it to spend it to buy something to buy stuff but in addition to that I mean you don't only have this buying power the payment power but in addition to that holding ADA as Philip explains also means that it comes with the right and obligation to participate in the protocol and to create blocks and these two uses of ADA can be separated by the delegation mechanism so somebody that owns ADA can keep the spending power so it's still his money but he can delegate the power to to participate in the protocol to somebody else the idea is exactly for people that maybe technically not very versed or whatever don't have time don't want to worry about it just want to use it to as money and are not interested in the protocol that they then can give their rights away to a power user to a pool that can do the technical things and as I said before but let me just stress that so delegation does not mean that you lose control over the money you can still spend it at any time it just means that the right to participate in the protocol is delegated not the right to spend the money and this is now a bit technical but it's only a couple of slides so this is how the delegation mechanism actually works so there will be three different types of addresses basically accounts types of accounts and each is associated with a key or key pair in the cryptographic sense one for payments one for staking and as far as payments is concerned all these three types of accounts are exactly identical the differences in the staking so there's this base address where both key the staking key is directly linked to it and there's a so-called pointer address where it's more indirect so the address points to a point in the blockchain and at that point in the blockchain there's some meta data that defines the staking key and then finally enterprise addresses where that can stake and this letter type is meant for exchanges because there we have the situation that an exchange from the point of view of the blockchain is extremely rich because all the money that people store at the exchange from the point of the blockchain belongs to the exchange but we but legally the money of course doesn't belong to the exchange but to to the people that deposited it there so for exchanges we don't want them to use basically their clients money to participate in the protocol so the idea is that they have special enterprise addresses where they can just transfer funds but can't do staking can't create blocks and so on I mentioned here for the pointer addresses I mentioned a pointer to a delegation certificate so what's that it's a piece of I mean a signed cryptographically signed piece of meta data in the blockchain not necessarily in the blockchain I come to that that transfers staking rights from one staking key to another and we can probably see where this is going this is then used to delegate if you want to delegate to a mining pool and it can be published in the blockchain in that case it's called a heavyweight certificate and pointer addresses that I mentioned on the previous slide can reference it and and the way that technically happens is there will be a transaction which ends up on the blockchain and this transaction can have meet meta data and part of this meta data will be this delegation certificate and that in particular sorry come to that so right I just wanted to say this first so you also automatically then have to pay for for these delegation certificates the heavyweight ones because in order to get this transaction transaction into the blockchain you have to pay the normal transaction fees so it comes with a small cost to to do these delegation certificates right and then this middle sentence is about conflicting I mean you could of course delegate your money to somebody and then to somebody else so you could have two delegation certificates and there must be some rule to break the tie and the rule is simply the later one wins so whatever is later in the blockchain over rules everything that's before it then there are also lightweight certificates so they are not published on the blockchain and not part of the meta data of of a transaction they only become public as part of a block so those are included in the headers of blocks by the creator of the block to prove that he actually has the staking rights for the address that was elected slot leader and then there's another ingredient so for these staking pools they will have to formally register so it's it's written in the lecture on the blockchain registration certificate also embedded in a special transaction so basically you have to pay a fee to create a pool one of these staking pools and in this transfer so you pay the system basically this fee and you embed your certificate and the certificate contains the staking key of the pool leader so people that want to join this pool will then create a delegation certificate where they transfer their staking rights to that staking right a staking key of the pool leader and right and they do that in the form of a heavyweight certificate and this is all quite complicated but for good reason so if you think about it there are these pointers and there can also be chains so I can point to to some staking key and then there can be another delegation certificate that transfers that staking key to yet another one and so on so there can be several hops so it can be quite complicated but that means that lots of scenarios are some are modeled with this so you can have regular user wallets offline user wallets with cold staking enhanced privacy staking pool wallets exchange wallets and and that's why it's so relatively complicated to to cover all these use cases so I don't want to go into more detail but it's quite interesting how how depending what you want how much security you want how much privacy you want you can set use these different types of addresses to get quite interesting scenarios right so this is how delegation works and now I want to explain the incentive mechanism itself so first of all I want to say where the money actually comes from I mean we want to incentivize people but the money to do that or the ADA to do that must come from somewhere and there are two sources same or very similar to Bitcoin actually first is transaction fees so let me briefly talk about transaction fees I mean the second reason is topic of this talk to fund incentives for the stakeholders and the stake pools and so on there's another reason the prevention of distributed distributed denial of service attacks so that is an attack by an attacker tries to create hundreds or thousands or millions of transactions and flood the blockchain with it and overload the system and the idea is if if you can't do that for free if you have to pay even a small amount of money for each transaction and it becomes prohibitively expensive to to create all these flooding transactions so that's the other reason why you need transaction fees and how it works is when similar to other cryptocurrencies there's a rule what actually in Cardano we have specific rules so it's not just convention so it's hard coded for each transaction what the minimal fees are and then in each transaction you have to include at least the minimal fees so the inputs to your transaction have to are larger than the outputs of the transaction and the difference must be at least as large as the minimal fees it can be larger if you feel generous and it's a very simple formula that we use at the moment to calculate these minimal fees so it's just a linear function so some constant term a plus b times the size of the transaction where the size is not the size in ADA but the size in bytes and yeah there are the values of these constants right now so you always pay at least this 0.15 ADA that's the constant term and then for each byte you pay this 0.00043946 ADA and as an example if you have a typical transaction of size 200 bytes then you would add this constant term a plus the b times 200 and you get something like 0.16 ADA and the justification for that form is so we have the a for this distributed denial of service attack prevention so the idea is no matter how small and trivial your transaction is you always have to at least pay this a so you no matter how small it is there's always this cost a and that a should be high enough so that it makes it too expensive for you to create thousands of transactions or millions and the b is basically for fairness so the idea is I mean you should pay for the strain you put on the system and if you have a large transaction then people that run the Cardano protocol they have to save store your data on their computers so they have to basically buy memory so somehow it makes sense that the bigger the transaction is the more expensive it should be we might later add other terms to that for example one idea was the the number of UTXOs you have so so if your wallet gets more and more complicated that that also makes it more expensive for people actually to store your data so there could be a term for that another idea that we had was to also add a term for the actual size in ADA so that if you transfer large amounts of ADA not necessarily large in bytes but in ADAs that it should maybe also depend on that like yeah but right now this is the formula we use so that's the one source of income or for incentives and right so so this a and b is as I said hard-coded but we anticipate that probably at some point that might have to be adjusted I mean yeah depending on the course of ADA and also on the use statistics of the of the system right and the second source of incentives as in Bitcoin will be monetary expansion so what does that mean the total supply of ADA today is circa 31 billion ADA it's a bit more but less than 32 and the maximal supply is 45 billion ADA so there's still this gap of almost 14 billion ADA available and the ideas to use those for incentives as well obviously even though it's a large amount it's a it's a finite amount so the idea is to do something similar to what Bitcoin does to to have an exponential in decrease over time so it slowly gets less and less the percentage that's used of that for incentives so and the reason for that is that the hope of course is that Cardano will be hugely successful and more and more people will use it and so the transaction fees will go up and then there's less and less need for for this extra monetary expansion money and just as an example how that what it could look like but this is purely arbitrary so this 5% is just really an example no idea how high that will be but for example if we start with this 14 billion and each year spend 5% of the still available money on incentives then the first year we would have 5% of 14 billion which is 700 million and then of course the available money goes down and so slowly over the years it becomes less and less but it's quite a graceful decay so but of course maybe 5% is too high maybe will be useless so it's just an example what that would look like right so these are the two sources where the incentives come from now how are they actually distributed amongst people and as Philip mentioned in Cardano we have this strict division of time into so-called epochs and slots so slot last 20 seconds and for each slot one coin is randomly chosen and the owner has the right to create this block in that slot and then epoch contains 21,600 slots and if you multiply that you see that's exactly five days and epoch this is when this election and randomization process happens so every five days the people roll their dice and generate a new random number seed and the slot leaders for the next epoch for the next 21,600 slots are elected at that point so each epoch right and the plan is to distribute incentives not as in Bitcoin on a block by block base but on an epoch by epoch base so all in some all transaction fees of all the blocks of an epoch plus the monetary expansion will be put into one reward pool for the whole epoch and then this whole pool will be distributed amongst the people that were active or important in this epoch which I explain on the next slides and so the basic the basic idea is it's okay and I explained that in two steps first I explain how this rewards pool is distributed amongst pools and then afterwards I will explain how one pool then further splits it between the members of the pool so now we're just talking about how the whole reward pool is split amongst pools and the basic idea is to do it proportional to stake so the your split of the reward pool is proportional to your stake and there are two ways to actually realize that you just look at the stake and do the calculation or you could also look at the number of slots in that epoch that the pool was elected slot leader and not the number of blocks it actually created but the number it was elected pool leader and this of course looks different at first but if you remember I mean as Philip explained the proper the probability of being elected slot leader is proportional to a stake so if you do some basic probability theory 101 you see that these two methods would lead to the same expected outcome so that's the basic idea so the more stake you have in the system you bigger your part in the rewards pool is and then there are two refinements to that first refinement I mentioned that we have this number K of desired number of pools which should be around a hundred so we want around a hundred pools if you think about it normally it would make if we just had this proportional rule then it would make sense for pools to become bigger and bigger because they would still get the same reward but they would have lower costs because over it somehow I mean if bigger pool has not much more over it than a small pool so there would be a tendency to big big blocks and in order to prevent that we will just cap the the maximum part of the rewards pool you can get at 1 over K so in the example of K 100 we want 100 pools that means no matter how high your stake is you can never get more than 1% of the rewards pool for the epoch so in this in example if you have two state pools and B one has 0.3 percent of stake and one is 1.2 percent of stake then a will get 0.3 percent of the rewards pool according to his stake but B will not get 1.2 percent but only 1% nobody will get more than one and the hope is of course that this will have the effect that pools won't grow too large because then there some other part they get from the reward pool decreases and doesn't increase it doesn't decrease but it doesn't increase any longer right and the second refinement is I mean so far this was all only dependent on the stake the stake pools have but not on the work they actually do so there somehow there must be a mechanism that checks whether they actually create the blocks when they were elected and so there will be some sort of predicate that checks that so it looks at for which slots in a given epoch the pool was elected leader and checks which of these slots the pool actually did its work and did actually create blocks and depending on these two inputs it will decide whether you are entitled to get your rewards or not and just as a remark this predicate I mean you can think something like okay I must do I must create at least 90% of the blocks I was elected to create in order to get my reward it can't be quite that simple because if you think about it say you have been elected for 100 slots in epoch and you already created 90 blocks then you could just switch off your computer and ignore the last 10 because you already reached this threshold of 90% and if everybody did that then that would mean that at the end of an epoch everybody would switch off their computers which wouldn't be good for obvious reasons so it must be a bit more complicated than that some randomization maybe or maybe just looking exactly at the number of created blocks divided by the number of elected blocks and and use that number directly or something like that but this is the general idea so you only get your rewards if you actually did the work okay and yes this is the example I just explained why it can't be that simple right and if you think about it so there are two reasons why you get could get less than your stake one if you have in this example of k equals 100 if you have more than 1% of stake you won't get this the amount that's over 1% or if you don't do your work you also don't get the rewards so that means not not the whole reward pool is actually distributed and it's it's important that the rest does not get distributed amongst people so that's just not distributed at all but that's actually not a bug but a feature because as Philip also mentioned we have this treasury thing and the treasury of course also needs funds so we will just put this unused rewards into the treasury so it's not lost to humanity it's just lost to these pools right and an important consequence of this is that there's no competition between pools so nothing one pool does can somehow have an impact on how much reward another pool gets so it's not as if everything I gain somebody else's loo else loses there's this strict fencing in of right so it means that there's no incentive for any pool to sabotage another pool it's not as if if I sabotage you and you can't create your blocks I get your rewards as I explained on the previous slide the rewards then just go to treasury I don't get them so that means the polls are completely independent in this epoch and no matter what they do they can only influence their own rewards but not somebody else's rewards and that means that classical attacks on Bitcoin like selfish mining for example a block withholding just cannot work because these the pools are fenced off in this sense from each other this it's not that my gain is your loss it's completely independent so this is a very important property of the scheme right finally I want to say now we have determined each pool gets on so much of the rewards pool what then happens to the pool members which means the people that have delegated their staking rights to this pool and that will depend on will follow two guidelines first that the pool leader itself the one that runs the pool the one that registered the pool filled in this registration certificate published it on the blockchain and paid the fees and she also has the I mean she has the hardware and she must be online and so on so she should get more than the others and the second rule is that the pool members that are not the leaders should be rewarded proportional to the stake that delegates simply proportional and last slide isn't just an example to what that would could look like so but I must stress the fact this is completely arbitrary so it's not reflecting actual incentives it's just an example to explain the rules so we have three people Alice Bob and Charlie Alice has 0.2 percent of stake and she runs a pool with Bob and Charlie as members Bob has 0.1 and Charlie is 0.2 and let's say that in this epoch in the rewards pool there are five million ADA and that Alice's pool beautifully did all the greater blocks so she doesn't I mean she fulfills this predicate and she gets the full share of her reward and if you see the whole pool has 0.2 percent plus 0.1 plus 0.2 is 0.5 which is less than 1% so she also doesn't get kept off so she gets full the whole pool gets full 0.5 percent of the stake which if you do the calculation is 25,000 ADA so that's what the pool gets and now with these two guidelines the Bob has open 1% of stake and Charlie has 0.2 so Bob will get half of what Charlie gets but Charlie and Alice have the same stake but Alice has the overhead of running the pool so Alice will get more than Charlie and Bob will get half of what Charlie gets and let's just assume that this additional compensation for running the pool in this case will be 5000 ADA so Alice upfront takes 5000 of the 25,000 and 20,000 are left and now those 20,000 are exactly distributed according to the stake so Alice to Bob to Charlie is like 2 to 1 to 2 and if you do the calculation that gives 8,000, 4,000, 8,000 so Alice gets these 8,000 plus her special 5,000, 13,000 and Bob and Charlie get 4,000 and 8,000 so that's the idea so important to just sum up important thing that for a whole epoch the incentives are pooled it's not like in Bitcoin where it's on a block by block base it gets pooled then it gets distributed according to the stake of the pools but kept at a certain number to prevent big pools and also you can lose your rights to part of the reward if you don't do your job and money can not be distributed it then goes to the Treasury which means there's no competition amongst pools and then finally once you have determined how much one pool gets it gets distributed amongst pool leaders according to their stake with the exception that the pool leader herself gets a pool members everybody according to stake but the pool leader herself gets a bit more and the details are still being worked out but this is the general idea so that was right and as I said before this is purely fictional so please now don't start making calculations how much you can earn buying Ada right and yes so that's all I wanted to say thank you very much I just wanted to encourage you to subscribe to the IOHK YouTube channel where for example the talks from tonight will also be put online soon I hope and to also follow us on Twitter that's input output HK thank you very much


Well, I think it's 1205, we've got 12 people in the room, so we want to say welcome to everyone. I'm Janice Robinson, I'm the moderator, I'm from BYU, and these two gals are from the University of Utah, who is our neighbor, sometimes are foe, but mostly we love them, right? Anyway, so this is a follow-up on some video stuff, just a reminder to everyone to keep your video and microphone off until the point where we are asking questions. This is also a 20-minute session, so we need to speed along and leave a little few minutes at the end for questions, and you can also enter questions in the Q&A, and then the presenters can see those, so take it away. Alright, thank you, welcome everyone to our presentation, please put your questions in the Q&A, and we'll answer those at the end. I want to thank everyone for coming, my name is Tally, and I'm the liaison to our video game program, and Anne is in charge of our institutional repository, which includes the student theses and dissertations, next slide. Before we get started, I'd like to acknowledge that the University of Utah is the traditional and ancestral homelands of the Shoshone, Paiute, Ghoshu, and Yut tribes, and is a crossroads for indigenous peoples. Next. Founded over a decade ago, the Entertainment Arts and Engineering Program, or EAE, has offered multiple degree options for students. According to US News, EAE is currently ranked number one among public institutions for game designs. EAE has really set itself apart from other programs, the students don't only learn about game design, but they create video games which are available for download, usually for free. The students create many games throughout their coursework, and it cumulates in a thesis game. The question quickly became, how does the library collect, preserve, and disseminate these complex theses? Next. Video games are especially appealing for this question because of their inherent duality as both an object and an activity, how and should we preserve both? We thought video games would also be a case study to explore preservation and dissemination strategies for emerging forms of complex digital scholarship. Next. A major challenge associated with this type, this question of preserving and disseminating complex digital scholarship is the ever-changing software and hardware. There is a lot of literature about emulators and similar concepts, but Ann and I were more interested in practical steps that we could take immediately. So we applied for an institute, a museum, and library services grant to explore this. Next. After receiving an IMLS grant, we spent a year researching and talking with EAE. We published a white paper about our findings. It's finally named the EDS report or emerging digital scholarship. Since then, we've applied our recommendations and are actively collecting, preserving, and disseminating EAE's video game theses. In this presentation, we'll highlight a few of our recommendations and what this has looked like moving forward. Next. Here are key recommendations, which we'll explore a bit more. I'll cover the first two and Ann will take the last two. The image on this slide shows a handful of EAE's published student games. Next. Students decide everything in this process. EAE was very clear that as intellectual property owners of the games, the students as a team decide if and what the library collects, preserves, and disseminates. We created a tiered system of increasingly collecting more content for the game record. The hope is to collect the entire RAP kit, which includes everything the student authors submit for their theses. The students use an archival agreement form, which is an ungraded assignment, and also posted on the EAE research guide to indicate these preferences. An educational course was created to support student decision making. The students also use this form to communicate their copyright ownership and any permissions and the level of access that others have will have to the game. This latter section includes an embargo option and limited access in the special collections reading room. Next. The second recommendation is to let student authors provide metadata for their game. Part of the archival agreement form is this author provided metadata section. This gives students voice to how their games are described. The images on the slide show the various metadata fields. Drawing from previous literature, especially Dr. Lee's from the University of Washington, this list is pretty lengthy, but it gives multiple access points for a variety of gamers. Practically, the author provided metadata provides the library a starting point to accurately describe the game. This is especially important because metadata practitioners may not have the necessary equipment or expertise to play the game and then describe it. This section offers the students a chance to reflect on their work and help streamline library processes. Next slide. Excuse me. As a result, all the game theses have an expanded record based off the student-provided metadata. About a year after the game is released, Ann will go search Google and add any news, awards or reviews of the video game and add that content to the metadata record. There are several games which have received Steam Community Greenlight Game recognition plus other awards and recognitions too. For example, Best Police Training Simulator, the image on the left, won the first place citizen award at the Microsoft Imagine Cup. I'll now turn the time over to Ann. Thank you, Tally. Here's the EAE archive. This is where we collected all of the student-contributed metadata and also went out and curated a broader footprint for both the current games and the games that have been produced over the history of the program. Currently, there are 125 games over the 11-year history. Because students are required as part of the coursework to publish their game, we found that they particularly like using Steam these days. Steam is a community of gamers. It supports search and discovery and it's been used by many of the students as the publishing platform. Awards that Steam offer like the Greenlight Awards are community-selected awards that are very coveted. Because of this, there's a lot of incentive for the student to provide really detailed metadata about their game. We will come here and curate information here and augment the record that we have for it in our archive. Another site that's very useful is YouTube. YouTube is a publishing platform for trailers to games and demos to games. YouTube very helpfully has an algorithm that will recognize when a new game has been uploaded and also when YouTube community members have created videos of them playing that game. This is an opportunity to explore what the impact is of these games after they've been published. Something that is really difficult to do with other types of media. But this games lend themselves well to this sort of impact. There are other platforms that students have used. Recently, itch.io and Moby games are used as well as Google Play or Apple. Many years ago, a few students used DeSura for their game. You can see here that DeSura has had sort of an up and down history since its introduction a little over 10 years ago. This is a good reminder to us of just the volatility of curating inside a gaming environment. It's subject to the movement of the market. It's something to keep in mind. Moving on to our preservation plan. We're folding it into the existing preservation plan for our digital library. What we will do is accept the original game files in a zip file format and we will deposit that in the Rosetta digital preservation system. We will also have fixity checks run on the file by the preservation archivist. That will serve as our back-end. Our front-end will be a collection in our IR that's data repository. There will be cross-references between the data repository and Rosetta and the EAE archive. How did the students respond to what Tally and I came up with? Well, since we started collecting analytics in 2019, there was really low rates of interest in doing any archival or preservation measures and very disappointingly, there were many games published but not that many forms filled out. We did become aware of a flaw in the permissions form which we were able to correct, which sort of implied the library would be willing to provide dark storage. So now we require some form of embargo or some level of restricted access, but it has to be accessible. This year we're seeing more engagement in terms of the number of games published. We're seeing a few more people participate and also there's more interest in taking us up on what we can do to preserve our game. Our plan in the future is to support the circulation of the wrap kits that we're storing in Rosetta. Once they're able to circulate, we want to have a repository of user manuals and technical specifications for the hardware software tools that were used to develop the game because this will be a way to support their replication and reproduction and emulation in the future. And thank you so much for your time and attention. We've got links to our white paper and website. We'd be happy to start taking your questions. There are two questions. One, do you have a size limit for preservation zip packages? No, we currently do not have a size limit. Great. And the other question is, are games submitted in lieu of a thesis or to supplement a thesis? The thesis is the video game itself. Okay. So there's no paper thesis about the game that they submit to the thesis office. So that's kind of why we're having to work directly with EAE in terms of getting those because for their programs, nothing is getting routed to the thesis office and then eventually back to the library. That's why that collaboration has been so essential. Oh, great. One other question.  There's an echo here.  The zip packages? I can see if I can find one up. I can pull one up. I didn't even think to look or inquire. Give me a second. I will answer that and if we can move on, that would probably be best. And I'll look for an answer. Here's another question. Two questions. Are there similar programs like this at other institutions? This was very unique to a lot of us and another person said, do you have a policy on accessibility or how do you handle that issue if it comes up? Okay, so accessibility is something that the students are in charge of and so it's very important that they understand what they're providing access to and that they get to make that decision of what level of access. We can limit it to campus. We can limit it to the library. We can limit it to the program itself. But it's an important decision for them to make. They do make a decision about their copyright which indicates whether or not any files that they created can be modified or if they can be copied and with attribution. So Tally's work with increasing the copyright education over the past year has, I believe, resulted in more participation because the students have a better understanding of what they're doing. And I'm sorry, there was a question about policy. I forgot what that... They just wanted to know if there were other programs like this at other institutions. We have not found one. That is not to say there isn't one, but we did look at game development programs and there doesn't seem to be a connection between the program and the academic library. There are academic libraries preserving video games. Some are exploring emulation, some are collecting legacy games. And I know that there is some of that collection building going on at my library, even though I'm not directly involved in that aspect of it. Yeah, I guess I read that question differently. Similar programs, game design programs, that's how I read it. And that's yes. I don't know which meaning of similar programs that you want us to answer, Emily. But there are some other great game design programs as well. And to our knowledge, we haven't come across many libraries that are kind of actively collecting those theses. You know, I think this is fascinating technology because all of us theses and dissertations, you know, we've transitioned from paper to digital, but they're mostly PDFs. But I'm assuming that if some student wanted to have a lot of, you know, interviews or YouTube or something, then this same technology or processes could be used. So we have a lot to learn from your work over the last four years. Thank you very much. We think that there is an application here for other forms of scholarship and video games are a really good test case to begin to explore how are we going to support born digital complex scholarship in our institutional repositories and libraries. And I think there are exciting opportunities to work really closely with developers in the development process to record that process and that is going to even further enrich those records. There's one more question. Someone said she wasn't aware of ex-libris Rosetta. Is this the only option you found for preservation of these packets? It's just the in-house solution. We were focused on doing something locally sustainable because this is not beyond the grant. We have not received funding. And so we're using existing systems to fold in an archival and preservation plan for the video games. Just piggybacking them on top of existing systems. Well I definitely appreciate all your research and hard work and it's going to take a lot of thinking outside the box to accommodate students who are doing things differently than what we're all used to. Does anybody else have any questions? I see something in the chat. People are just saying thank you for presenting and hearing about these examples of video games. You're breaking new ground here so you got to stay around for a while so we can all learn from you. We will try. Okay it's great. Thank you. It's been a pleasure. This PowerPoint is available in the replay section right? It's what I'm told. It should be. Anyway great. So thank you so much. Thank you very much. Have a good conference everyone. You too. It's great to see you up north on my screen.


Cardiovascular diseases are more common in both men and women, but there are differences in clinical symptoms, pathophysiology, and response to treatment. Women tend to have a lower perception of the risk and are often underdiagnosed due to delayed recognition of symptoms. Estrogen provides protection against heart disease during reproductive phase, but after menopause, the risk increases. The presented work highlights the importance of monitoring women's health in their middle age and implementing early intervention strategies to reduce the risk of CVD. This article was authored by Kamila Rixkowska, Veronica Adak, Kamil Janikowski, and others.


Good morning. Good afternoon and good evening to all of you in which part of the world you are today. We will be diving into the world of service mesh and how it help in enhancing and meeting the security and compliance need. But before we do that, a quick round of introduction. My name is Nenath Desai. I'm working at InfraCloud as a staff engineer in DevOps and SIS space. At InfraCloud, I mainly work to help our clients to handle their need around DevOps, SIS and platform engineering. Mainly around infrastructure design modernization using cloud native technologies like Kubernetes and all the tech stack that revolves around Kubernetes. As part of my regular consulting work, I happen to work on an implementation of service mesh for a few customers to aid their security and compliance need. And that's how I thought whatever I have learned can share with you all. Okay, so agenda wise we will discuss a range of topics that are central to the service mesh. We will explore how microservices emerge as a transformative architectural pattern and the factors that fuel their rise. Then we will dwell into the critical aspect of security challenges in microservice architecture. We will discuss complexities that come with a decentralized system and how to address them. Then we'll turn our attention to the evolution of service mesh. I will take you through the historical context of why and how the service mesh came into the existence and their role in overall modern microservice ecosystem. Then we'll explore the role of service mesh in enhancing security and then moving on we'll discuss how service mesh aids in compliance effort as well. And then we'll highlight with some of the examples as well how it meets your regulatory requirements. And that eventually making compliance more manageable. And later we'll explain how service mesh platform improves in observability as well as making it easy to identify troubleshoot issues. Zero trust networking is a hot topic. And I will discuss how service mesh alliance with the principles of zero trust and finally we will explore service mesh deployment consideration and best practices. I will share insights on how to make the most of service mesh while avoiding the common fit faults. And then we will see the small demo of service mesh capabilities in terms of how they help with the authentication and authorization. So rise of microservice so before the microservice architecture pattern actually gained the popularity the predominant software architecture pattern was a monolithic architecture. And it was characterized by its single code base where your entire application was built like a single cohesive unit which means all the components module functionalities were bundled together and tightly coupled as a single code. Obviously with the time spent iterating on the same thing you normally learn a better and efficient way of solving problem. And so over past few years to bypass the challenges posed by monolithic microservice pattern came into emergence and it has gained prominence in recent years due to several compelling reasons. Some of them highlighted here like first is of course scalability. So it allows individual services to be scaled independent of other services. For example, let's say you have an e-commerce application which has a different microservices like product catalog which handles product information or pricing etc. You let's have another user authentication service which normally is responsible for user login registration and order management service kind of service as well which can help with the process of creating and tracking customer orders. So now let's consider a scenario where and your e-commerce platform experience increase in a traffic due to holiday sale event. During such event different part of your application may experience different level of workload. For example product catalog service due to high user demand product this service can experience a significant search in the request from users browser and thus it can cause a load on this service. But thanks to the microservice nature you can scale this service horizontally by adding more instances or containers. For user authentication service while it is important from user authentication perspective but on a sales event you may not experience that much of surge in traffic. So you can scale it to a minimal level without overprovisioning any resources. And for order management service because people will put lots of order this service also might experience a surge in traffic and so you can scale this as well horizontally as and when needed. So I hope this example demonstrate how each microservice can be scaled independently based on its specific loads or requirement. And this scalability allows you to optimize your resources quite well and maintain an efficient performance during the traffic variation and making sure that your application remains responsible at the same time cost effective as well. And this flexibility also extend to the technology choices as well. Now your team can select most suitable programming languages and framework for each of the service. For example for user authentication service maybe Node.js or Ruby can be used for quick development and ease of handling user related operations. For product catalog maybe Python or Java for their efficient data processing. These small code bases of microservices has also led to the faster development and deployment cycles. And in terms of resilience as well microservices help to contain failures if one service encounters issues it doesn't necessarily disrupt your entire application. And it also helps from the collaboration perspective as well among all the small teams that are working on the individual microservices. Continuing on the same your testing and maintenance has also become more manageable with microservices due to the smaller code bases. And this microservices pattern has also helped for the adoption of containers and Kubernetes and overall cloud native development. And microservices are kind of naturally fit for automated CI CD pipeline which has resulted into the rapid and frequent releases. I'm sure we know this famous line from Spiderman movie where Uncle Ben convinced Peter that great powers with the great powers comes great responsibility. Similarly in a microservice world with pun intended I would say it comes with some greater security challenges as well. Why I will explain now. So what we have seen over the years is due to the microservice architecture pattern the attack surface has increased. Microservices open does expose multiple endpoints and API. So it increased the potential attack surface attacker can target a specific service going back again to the same e-commerce application. If they know that payment services are one which is processing all the payments they can specifically targeted service to service communication has also become a challenge in microservice architecture. If we do not encrypt these services to service communication. It can cause a damage to confidentiality integrity and authenticity of the data that has been exchanged between the microservice. And without encryption network traffic between these microservices normally happens in a plain text and that makes it more susceptible for use dropping attackers can gain access to the network and intercept and inspect the data that is being exchanged between the services. We normally call it as a passive attack. It can also lead to the man in the middle attack where an attacker intercept the communication between these microservices by the impersonating one or both the parties. Authentication and authorization as well across these multiple microservices can become complex. We have seen already in past I think many banking scams in regards to this from data security perspective as well. We as part of cloud native development we prefer our data being distributed across multiple microservices like take an example of your cloud storage service where your user files are stored across microservices. So making sure that this data at rest and in transit should be secured is quite highly important in today's world. Identity and access management as well like managing user identities and access controls across these diverse set of microservices can become challenging. And so it's a need of our to have I am solution which is much robust in a way code vulnerability as well. So smaller code base in microservice can sometimes lead to the overlooked security vulnerabilities. We have seen couple of time people pushing sensitive data sometime as part of a hard coding and runtime security as well like monitoring your microservices at runtime is also vital. And due to the if the more number of microservices are there chances are that you may miss out on that part as well to continue on the same your API security as well. So APIs are the most critical part of the microservices. So properly ensuring and securing those APIs in like input validation or rate limiting these are the essential part to prevent SQL injection or abuse kind of attack. So now the more number of microservice are there it is important that you have a registry which contain list and information about all these microservices. But at the same time, if someone gets access to these registry mechanism, then the attackers can redirect all the request to some malicious services. Securing the service registry and discovery mechanism is also important from microservices security challenge perspective. Logging and monitoring as well like centralized logging and monitoring did are important for detecting the suspicious activities. For example, let's say these many hundred or 200 microservices. If you do not have a centralized logging mechanism, it's become really hard to gain the insights about how your microservices are behaving. Container security as well, like if you are using container based microservices, then one need to ensure there are properly configured and isolated mechanisms to prevent container escapes or privilege escalation attacks. And as now it is already happening, most of us are using the Kubernetes kind of orchestration platform. So maintaining a security of these kind of platform is also important as it host your entire application. API gateways as well if I have to say is I have seen it has been quite widely used option. So protecting incoming and outgoing traffic on these services are also important. And we have also seen that many microservices rely on third party libraries and component. So securing them is also a big task. So how does service mesh happen? Well, the world was in a need of someone to come ahead and help us with some super mesh power to handle securely and regulate this microservice world. So jokes aside, the emergence of service mesh can be traced back to the evolution of application architecture. Like initially three tier web app DB kind of application practice was been practiced. However, as application grew in complexity, the challenges arose and companies found themselves writing custom libraries. So client libraries, which helps you with the request load balancing circuit breaking retries and from the instrumentation perspective as well. So these libraries were challenges when it comes to making some updates in them because it then require you to restart all your services as well. So to address this challenge proxies came into the scene proxies offered a solution that bypass many of the limitation of the client libraries. And unlike client libraries proxies can be upgraded without the need of recompilation and redeployment of your application. And this brought the flexibility and ease of maintenance for your microservice. And as then later cloud native practices gained prominence, officially a mesh of proxies emerged and it introduced the concept of deploying and managing proxies separately from your application lifecycle. So by creating a distributed mesh of these proxies, one was able to standardize the runtime operation. And it also provided a centralized API and then become a crucial component of microservices. And that's how service mesh has emerged over the years. Okay, so how does service mesh help basically in security and that too, especially in the world of Kubernetes. Well, from authentication and authorization perspective, service mesh enables strong authentication and authorization mechanism. For example, it allows only authorized services to access the sensitive data from a sensitive microservices. The encryption mtls feature basically of service mesh helps you to protect your data in transit or at rest as well. So you can use any service mesh tool of your choice like linkerd or Istio. And this has helped to avoid eavesdropping or manual middle attack basically from traffic control and routing perspective. There are popular service mesh mechanism which provides you a way to control the way traffic is flowing between the services and the way load balancing is happening. So their access control and circuit circuit breaking abilities has also provided us a way to prevent security vulnerabilities getting in. Okay, and from observatory and monitoring perspective as well. So service mesh does emit metrics that can be captured and monitored by various monitoring tools like Prometheus and so on. So service mesh platform is basically designed to provide the extensive observatory and monitoring capabilities. So for example, service mesh like NY proxy in Istio or you can say linkerd proxies, they generate a wide range of metrics that you can use. And based on those metrics, you can get the information about request rate, latencies, error rate, success rates and all the other relevant data. And solutions make sure that to provide this information either via HTTP endpoint or GRPC interface or side gas. And you can set alert and visualization as well on them. And from distributed security policies perspective, it provide a centralized policy management and enforcement tool across all your microservices. So it allows you to define security policies such as access control or authentication rule, all in one place, considered like a single plane of the glass. And it provides you a framework for real time policy update and changes without a risk of misconfiguration and basically overall improving the security posture for your microservices environment. From a service identity and authentication perspective with service mesh, you can implement mechanisms like MTLS and JWT tokens that ensures that only authenticated service can communicate with each others. And thus it standards the overall security of microservices by preventing unauthorized and unrequired accesses. From runtime security perspective as well, it helps to detect the anomalies by continuously observing the network traffic. And from API security point of view as well, it can help by doing the validation of inputs or incoming requests and help us to detect attack like as I mentioned SQL injection. And from security upgrade and patching perspective as well. So with the sidecar proxies approach, one can independently upgrade their microservices. So even when you're upgrading proxies, it will not recompile or redeploy your entire application itself. So that's how service mesh does help you from the security perspective.  Yes, I am talking about the term compliance. So let's see how service mesh helps with compliance based on the different industries regulations. So thanks to the enforcement of fine-grained policies by service mesh, it helps you to the meet requirement like those of GDPR to ensure data protection and privacy. The access control mechanisms provided by service mesh helps to comply the standards like HIPAA or PCI DSS. So service mesh makes sure that only authorized entities can interact with the sensitive data. Apart from that, it does provide you a centralized auditing and logging capabilities to accurately gather report and brings the traceability. And when it comes to data protection regulation like GDPR HIPAA, the data encryption with MTLS feature that I mentioned prior is crucial as it maintain the confidentiality of data during the communication between different services. To continue on the same, to comply with standard like ISO 27001, service mesh does offer governance and traceability features. Thus allowing organization to monitor and control all the service interaction. And by identifying services and controlling traffic accordingly, it helps to ensure that data flows aligned with the regulations like GDPR's data residency restriction kind of. And lastly, service mesh does support RBAC that aids compliance with the security standard like NIS SP853 by allowing organization to define and enforce the rollback access control policies. So well, that's how the service mesh does helps with the compliance angle as well. And I mentioned prior that the way service mesh helps with the access control is by fine grained access policies. The service mesh platform like STO LinkerD does allow organization to define precise rules, policies you can say, using which you can control and provide a secure access to only those who are needed for those services. The RBAC feature is also powerful for example in STO in particular. It enables you to define the roles and permission for services. It is kind of similar to the traditional access control mechanism but tailored to the microservices. For example, for the payment service, you can specifically define a particular role. And the NY proxy kind of feature does help you for the dynamic authorization as well. Does it basically allows to make a decision at a real time based on various factors like user identity, request context or even the state of the system. Apart from that, from identity and trust verification perspective as well, these are important factors and that's where your MTA list kind of features does help you. Okay, so that's how service mesh announces the access control and how does service mesh helps basically from observatory and monitoring perspective is as I mentioned or talk prior that it helps with the imitation of the matrix that you can collect from monitoring perspective. And you can readily integrate it with any monitoring platform of your choice. Platform like STO and Linkardy are already offering a centralized logging aggregating of all the logs from microservices. And it helps when it comes to the troubleshooting and mentoring compliance as it is a need of different audit requirement as well. And this distributed application does require us to understand end to end flows like from the moment someone tries to access our application, how different, how the client is flowing from one service to other service. So service mesh out of the box does provide capabilities to integrate with different distributed tracing tools like Jaeger or Zipkin. So that allows you to see microservice, how it is handling overall request and it can help you to identify the bottlenecks as well. And of course, you can integrate these monitoring platforms with the tools like Grafana and so on. And thus, it can help you to the visualization part of all your microservices current state as well. So for example, this is very small Grafana dashboard template that can give you the insights about how service mesh capabilities are able to fetch you the insights. So zero trust security model is a kind of paradigm shift in network security that always emphasizes on never trust always verify approach. With service mesh, all communication between the microservices is subject to strict verification and validation. And regardless of whether it occurs within the same cluster across the cluster or across the different cloud providers. Every interaction is getting evaluated against the defined policies and security rules and ensure that only authenticated and authorizes authorized services only can communicate with each other. So this approach significantly reduce the attack surface and limit the lateral movement within the microservice ecosystem and thus it does enhance security at the same time minimize the potential impact of the bridge. Okay, so I'm sure when we want to adopt some new tool we always want to understand some of the best practices that can help us with adopting that technology well. So these are some of them that I have listed. Needless to say always do plan ahead the deployment of service mesh, take into the account, the size of your application and the complexity and available resources. Secondly, evaluate different solutions, there are multiple micro service mesh available in the markets. First start understanding your specific use case and requirement and then at the end of the day see every service mesh platforms has their own features at the same time trade off. So choose the one that aligns with your needs specifically. Third, I would say is always do start small like whenever I was working on our clients requirement, we always started with one micro service, try to move it into the service mesh, try to gain that confidence and then move to move other services as well on a service mesh. And the capabilities like circuit breaking and retry policies of service mesh do help you to handle the failures gracefully. So do make sure to use them as it helps to prevent cascading failures and improve the service reliability. And needless to say, always focus on observatory and monitoring, always follow the shift left approach when it comes to security. The traffic management feature of service mesh is very powerful and do make use of it to do the traffic splitting as well as load balancing and for the can read deployments as well as that can help you to do the zero downtime kind of deployment server. Okay, from namespace and resource isolation perspective as well do configure a specific compute for every namespace that your development teams are going to use. Yeah, so this is crucial from the documentation and training perspective, always make sure that your development as well as operational team are very familiar with handling service mesh, then only decide to move any micro service on the service mesh. And from disaster recovery and high ability perspective as well, always plan for these kind of scenarios and do make sure to implement redundancy wherever necessary. There are tools like Valero and all that can help you with those aspect from performance testing point of view as well. Make sure you do the end to end performance testing for the microservices been moved on to the service mesh and try to ensure that there is no significant latency or bottleneck is been introduced in your microservice architecture. If you are using a commercial service mesh product, be aware of potential vendor lock in and consider open source alternative if portability is your concern. Backup and restore strategy as well, do make sure to have it in place already. And those will save your time when it comes to the typical disaster scenarios. And from so service mesh policies as well, do make sure to enforce strict policies when it comes to the traffic routing or security or access control. So see, service mesh deployment can be complex. But by following the best practices, certainly you will be able to successfully implement and manage service mesh for your microservice architecture and helps to improve the reliability, security and observability of your services. Okay. Well, now it's a demo time. I will give you a small demo of service mesh capabilities around authentication and authorization using Istio as a service mesh here. See, these capabilities are available in all the service mesh tools, but in the end I had to choose one. And so I decided maybe to use the Istio itself. So we will have one sample app and see how MTLS work for internal secure communication among microservices as well as how it helps with JWT tokens to authenticate end users as well. So to save time what I have done is I have recorded both the parts of it will play them one by one and explain. But prior that let's understand it with some visual diagrams. So for example, we'll have two namespaces called foo and bar with two microservices. One is HTTP bin and another is sleep. And both will run the NY proxy basically they both are kind of onboarded on a service mesh. And we'll use another instance as well of HTTP bin and sleep microservice, which is running without sidecar that means without service mesh in a namespace called as a legacy. So what we'll do is we will try to send a traffic from each sleep and HTTP bin pod of each namespace to other pods in the other namespace. So what we will ideally see is by default Istio does tracks the server workload which are migrated to Istio proxies and it does configure the client proxies to send a mutual TLS traffic between those workloads. And for the non service mesh service it use the plain text traffic. So basically we will use MTLS for communication between services from foo and bar namespace. But when it comes to communicating with the services from the legacy namespace, it will use the plain text format. So let me play the video of it. So as you could see here, we have three names to assess foo bar and legacy foo and bar are enabled with Istio sidecar proxies, whether as legacy is without any sidecar proxies. That's the reason here if you will see they have only one container which is of those microservices. But the containers or pods from the bar and foo namespace are having two containers, which indicates that the sidecar proxies has been enabled. We can verify the same by describing the pod from either foo or bar namespace and that's what we are going to do. We are going to describe now and see in HTTP bin service from the bar namespace. So you can see here that Istio sidecar proxy has been injected in that, which will make sure that any communication that is happening with this microservice will be via this sidecar only. And now what we will do is basically from each microservice of each namespace here using this simple curl request. We are trying to connect to other services right now no Istio policies has been enabled. That's the reason it will allow communication between the services which have sidecar enabled to the services which even do not have sidecar or service mesh been enabled. So basically it will allow communication in the empty list for those which are having sidecar. But at the same time for the one like legacy one, it will use the plain text communication and how we can be very much sure of that is if you will see now. Whenever you enable a sidecar Istio proxy, what it does is that it add this ex forwarded client cert header in the curl request that originally comes from our microservices. So here what we are doing is from the pods from our foo namespace. We are trying to send the curl request to the pod from the foo namespace. And ideally, basically these two namespaces are now enabled with service mesh. That's the reason it should use the ex forwarded client cert, which will validate that the communication is happening in a empty list by using the empty list feature. So to repeat again, the ex forwarded client cert header gets automatically added when service to service intercommunication is happening using the mutual TLS. So this proves us that it is using empty list for the secure communication. And now let's try to again send a similar request, but this time the curl request is to the microservice HTTP bin from the legacy namespace. And since now the request is going from sidecar enabled microservice to non service mesh or non sidecar enabled, ideally this header will not be present. That means the traffic flowing is happening in a plain text format, which is risky in a way. Yeah, so if you could see it was not able to gather anything. And now since we want to make sure that all our microservices are communicating with each other in a secure way alone, we will enable a peer authentication policy of the studio. So what this policy does help is for inter service communication with empty list mode as a strict. It makes sure that unless and until empty list is enabled for the microservices, any traffic that is going to and fro from this microservices with service mesh will be rejected. Okay. So now we have created this policy and now we will again try to run the same curl request. Now what should happen this time is that any communication that is going to happen with legacy namespace based microservices should be rejected. So our services with is to enabled will not be able to communicate with legacy namespace based services, because that communication was a plain text one, which is risky. As I can as I mentioned it can lead to use dropping or minor middle attack. So if you see here for communication from food namespace to bar namespace, it is generating 200 response, but for sleep microservice from legacy namespace when it is trying to connect to our HTTP bin service from the food name says which has basically is to sidecar proxy enabled it generated the exit code 56 that means it was not able to gather any data. So what happened here is the peer authentication policy observed that okay someone trying to send a plain text request to the parts or containers inside my particular namespace. Let me reject it. And that's how it is giving the exit code 56. Okay, it will happen the same for even if your service tried to communicate with the other microservice from the bar namespace as well. It will also get exited with error code 56. So I hope you are able to understand how service mesh does helps you with this empty list feature to avoid any unsecured connection to your microservices and does it helps that all this intercommunication inside the cluster is also secured in a way. Okay, and now we will move to the next demo, which is about how an end user will be authenticated when he will try to connect to your microservices which are covered by your studio service mesh. So for any authentication purpose, if you could see here, what we will try to demo here is if someone want to connect to HTTP bin microservice, then that external end user request should connect it on port 80. And it should get routed to HTTP bin service via Istio gateway called so here we are given name called HTTP bin gateway service. Okay, and we have also configured virtual service as well. So request will go from HTTP bin gateway to your virtual service. So if you describe the gateway here, gateway service here, you will be able to see that it is trying to show that any request end user request that comes should come on port 80. And if it is coming with HTTP protocol, then route that request to the Istio ingress gateway. That's what the purpose of this gateway policy, gateway resource, sorry. And then we have also created this virtual service. What this virtual service basically is doing is that it is telling that when a request come in at the Istio gateway, that request should come to me on a virtual service. And then I will route that request on port 8002 service HTTP bin. That's what it is trying to denote here. Okay, and we have also created a request authentication mechanism here. If you will do as you can see here, the request authentication policy called the JWT example. So the way we had a peer authentication policy in Istio to secure the service to service communication. If you want end user traffic coming to your service mesh based microservice, then you need to define a resource called as a request authentication. This request authentication policy in Istio service mesh helps you to validate that the request that is coming is coming with the JWT token, which is been issued by a particular predefined user. Here in this case, we are saying testing address secure.io and it is also making sure that to check if that request is been validated with the public key, which is already, which is something that Istio is already aware of. Okay. So, but here could be the case that this request policy authentication policy can detect whether the request is coming with the right valid JWT tokens or not. Only if the some value for token is assigned but in case let's say no value or no token is passed. Unfortunately, it does pass the request inside. And so for the very same purpose, we have created another authorization policy as you could see here on screen. What this policy basically does is it is telling Istio that if any end user request comes without any JWT token, you basically need to deny that request. So, we'll do a demo. We'll again try to send a curl request here if you see we are not passing any header, any JWT valid token. So it will give you 403. Thanks to that authorization policy that we defined. And now thanks to the request authentication policy that we have defined, let's say I'm randomly passing some JWT tokens like dead beef or something. So what it should happen is it should reject that request and that's the reason you are able to see it has given 401 error. What for this demo purpose I have done is I have stored or picked up the token which is available here on Istio sample examples. So I have stored that inside a token variable and now that token is basically this one, which is a valid token. So any end user request that is coming with this token should be allowed by our Istio and that's what you will see now. So here I will again run the same curl request now here this time if you see I am passing it the JWT token which has been rightly issued and now as you could see it is giving 200 response. So that's how Istio service mesh basically helps you with the end user authentication and authorization. Again, to repeat Istio was just one example. These features are pretty common in any service mesh that you use. And that does helps you with the security and compliance perspective as well. So that's very much from this webinar. And I hope you find it insightful and took away something new from this webinar. And you can reach out to me at any time on LinkedIn or Twitter for any query around service mesh. And thank you so much again for watching this. Thanks.