Hello hello hello ladies and gentlemen, welcome back I'm Philip Magnus and recently I read this little beauty Artificial Condition, the second book in the Murderbot Diaries, which is very very very fun. More fun than I had with the first one, but I talked to myself, since I haven't actually spoken about the first one, I might as well do something weird. A review of my review of All Systems Red, the first novella in the Murderbot Diaries. Let's get into it shall we? This review is from February 24th 2020 and was posted originally for Booknest EU. The copy I read I had also borrowed from the library, just like this one. You can figure it out by this here little thingy. Yes it says Oroman Engelska, which is probably how you would not pronounce it if you were actually Swedish. Let's move on shall we? While browsing through the rows of books in English in the Swedish library I frequent, I came across Matt Wells' All Systems Red, and the fellow who's cover I dimly recall seeing years before on tour.com. Very true, I had seen it before. I looked through my two read list and surprised this one was nowhere near it, as if that would stop me. I grabbed it stole away, had a poem that is too lightening as well, by the way that's a great novel, you should go check it out, in case someone topped this tin-vella to conspicuous. Long live sci-fi. Indeed, it has lived long. It can be phased back as far away as Edgar Allan Poe, if you believe the critics. By the end of the night I had read through the first of these titles with barely any effort. I had. These are very easy to read. For example this one, it might say that it's 158 pages, but actually when the pages are printed like this, it really is. Probably less. All Systems Red offers a fun story from the point of view of an anxiety-riddled robot, with several biological components in a touch of misanthropy. I like the imaginary people on the entertainment feed way more than I liked real ones, but you can't have one without the other. I understand that, Murderbot. This sec unit, short for Security Unit, calls itself Murderbot and seeks to avoid all direct interactions with its human wards, interested only in watching the TV, music and game programs on entertainment channels. If this isn't enough to make the Murderbot relatable, I don't know what it will. And for the record it is. It totally is. My empathy for Murderbot is far greater than my empathy for my common man outside these four walls of my prison. Stuck on a planet with a band of scientists performing geological studies, our protagonist hopes to avoid any sort of excitement. Unfortunately for him, this is a sci-fi novella intent on putting Murderbot on the spot and testing its metal. A few action scenes are only to be expected, and they were well handled and entertaining. I think that's a bit vague. I think it's got some buzzwords. I would like to think that my language has become more precise since. You know, I would probably get into the nitty-gritty of those actions, if only I remembered them. Probably a lot of… I think there was something about sec units going against one another, ripping limbs off of one another, shooting at each other with energy weapons. Anyway, of artificial condition is anything to judge by. The prose is serviceable. Not quite excellent, but it doesn't need to be. There's plenty of great interactions. The dialogue never tends towards the heavily expositional, and the personalities of all the scientists led by Team Leader Mensa shine true. Are in the humour? Golden. Yes, talk to Murderbot about its feelings. The idea was so painful. I dropped to 97% efficiency. I'd rather climb back into Hostile One's mouth. I have to say, not so bad at choosing quotes. I enjoyed that one. Yeah, it's good. It's good. In terms of antagonists, the architects behind our protagonists' woes don't make fronting especially memorable. They don't. I really don't remember anything about them other than being part of an evil corporation. Let's see what I've said. They are rather archetypal presenting the depths to which human greed tends to go when a group of people goes off the very deep end. It works well and keeps our second unit and his group of scientists on their toes and pushing themselves as hard as they can to survive. Right, yeah, that's fair enough description of what went on. Once embroiled in a crisis, Murderbot is willing to put its life on the line. For the band of humans it has been tasked with protecting, despite it hacking its governance module. The same module that allows anyone who signed a deal with the company, like the scientists, to command Murderbot. By working to save Mensa and the rest of her team from a shadowy enemy, then Murderbot is exercising its free will. And this is at the heart of what's examined in Wells' novel. The question is one of freedom and compassion and the examination of the self. And the text goes a long way in showing how Murderbot exercises all three. Right in the money here, I would probably have brought up something a little bit more literary now. I'd probably be talking about something like Dona Harroway's cyborgs and simians. It's a really interesting take on subjectivity in post-modernism. And it would be at home with the Murderbot diaries, I suspect. Maybe I will write about it a little bit once I have actually read. Oh, six, I think. Six entries into the series. And I finish the review up with MyScore for All Systems. Red is a four out of five. This is a legitimately enjoyable adventure in a science fiction setting with plenty of good zingers, a socially awkward Robocop. What's not to love? I'm looking forward to reading more about Murderbot in the future. I'll definitely be picking up his story when I'm next in my local library. I like the reference to Robocop. It's a very obvious one. Probably lots of people have made it. And it's not really all that correct. But it made me laugh. Smile. I probably laughed while I was writing it. I tend to giggle to myself uncontrollably. That's my Murderbot cell systems red review. Did you enjoy me reviewing my review? I think it wasn't too bad. I would give it either seven out of five or seven out of ten, whichever makes me look better. I'm not sure which one that would be. Am I humble or am I great? Well beyond what you would expect. I don't know, but you tell me in the comments down below. I hope to see you very soon for the actual non-spoof review of Artificial Condition. And I am looking forward to reading the next books in the series, the next novellas. And there is in fact an actual novel, which is about 350 pages long and numbers five in the series. So I have it's a ways off yet. Smash that like button, press that subscribe button and all the other button relevant things that you might enjoy or not. See you again next time. Bye.


The president's budget proposal eliminates public media funding. Learn how you can help at lptv.org slash action. The future of a Bemidji veterans home was heavily discussed during the Beltrami County Board of Commissioners meeting today. Board members expressed concern that a proposed $10 million for the home through a state bonding bill would be pushed to next year. While last year's bonding bill could come up at any time on the senate floor, the veterans home funding was not included in that version. The board members hoped that area representatives would push for the funds to be included in a house version of the bill to be approved this year. I've been lobbying real hard and I've got assurances from the leaders that it'll be it'll be included but that and a buck will get you a cup of coffee McDonald's. I plan on staying on top of it. During the meeting, Beltrami County Administrator K Mack expressed concern over the status of two tax bills in the House and Senate. Mack said that there was a possibility that corporations such as Enbridge may have been overtaxed due to appraisals conducted by the State Department. If Enbridge were to take that matter to tax court, the county would be required to pay the money back. That will devastate Clearwater County but I'll tell you what it will not be I don't know what Beltrami County would do if we had to pay back. Ours would be about a quarter of a million dollars. The bills would require instead the the state to pay the property tax money back to the taxpayer. So far the two bills have had little movement and have only been referred to other committees. If you've enjoyed this segment of Lakeland News, please consider making a tax deductible contribution to Lakeland Public Television.


So this is a presentation I did earlier to the developers, so it's an internal presentation to the programmers within IWHK. Some from other teams that are not part of the Cardano, but mostly the Cardano team. So it's a tech talk about a particular technique for specifying and testing and this is part of my goal to improve the quality of our software over time. We built the initial system quite quickly and over time, in previous talks I've talked about high assurance and all this stuff, but there's a lot of more short term, less sophisticated things that we can do and this talk is about one of those. So it's about how do we think about specifying new components of our software or if we're rewriting bits of the software to improve its quality, where do we start from, we need to start from the specifications, how do we think about those specifications, what's a good general purpose technique for doing so. In previous talks I've talked a lot about mathematics and whatever. And so this is a sort of, it is a mathematical technique, but it's very practical, so this is why I was explaining this one to everybody. So it's all about abstraction and so I start off with the theory with this box and some people point out, oh it's a category diagram, it doesn't matter. So we start with the theory, which is a straightforward bit of mathematical theory, but it's very simple and then I go on to explain how do you apply that theory to real world examples, particularly examples from our system. For example at the moment, as I mentioned during the talk, colleagues of ours are rewriting a new wallet backend and they're applying this technique as part of that backend. There's many parts of our software that we can apply this technique, it's quite a general approach. Front-end users are not going to really notice this kind of stuff, this is about software quality on the inside. I mean what do you notice, do you notice the absence of things going wrong? What do we want? We want reliable software as well. We want all the features, we want things to be pretty, but we also want things to work. And working in the backend turns into building our software with clear, clear specifications and then being able to test them easily against those specifications. It's how do we build components that are simpler, easier to understand, reducing the accidental complexity. By starting with these kinds of thinking about these things is mathematical abstract specifications makes it much easier to start at the beginning with what is the simplest possible thing I could do and then you fiddle with it until it becomes as simple as you can make it and then you go and build it and then you test it against that specification and that gives you a lot easier way. The simplest specification leads to a simpler implementation but it leads to an implementation that can be tested easily and it can be tested quite comprehensively. There's a traditional way of, or a way that people often build software is they build a thing and then they write lots and lots and lots of tests or it's kind of a slapdash kind of approach and that's a lot of effort and it takes a lot of, it takes a lot of those different tests to get coverage of everything and you don't really know that you've really covered everything and you often end up with accidentally complicated designs. If you start from let's try as hard as we can to make a simple abstract description of what we're trying to achieve then that leads through to a simple way of testing against that abstract specification and you then have a much stronger, much greater confidence that the thing we've built works, meets its specification and we can understand what that specification is. It's simpler whereas sometimes you build things and you keep tweaking all the way through and by the end you're like well I've got this thing but it's quite complicated and it's quite hard to understand and maybe only two people understand it and that's not good. You want everything to be as simple as you can make it. Simplicity leads to quality and what does that mean for the end user? Yeah, it means the absence of failures but in a way that's not really very sexy. What's flashy is user interfaces and cool new features but because there's money at stake quality is important. The absence of failure is an important quality. Yeah, so I want to talk about specification because before we contest anything we need to have a specification and so here I'm not talking about fancy things, I'm talking about the ordinary components that we write all the time.  I'm not talking about that stuff, that's much more sophisticated, I'm talking about just much more everyday, the kind of testing that we should be doing on new components that we're writing that we're working on at the moment and so the key thing is how do we capture specifications or techniques for capturing specifications. So I want to do two, I'll talk about the theory a little bit and then talk about two case studies. One case I'll talk about which is the wallet rewrite that's happening right now, Edward and Edsko are not here, they are solidly working all week, peace and quiet for them and they're working on, so I'll describe the wallet rewrite as a case study of what I'm describing here and then I want us to do a much simpler instance of the same thing in groups and we all work on it in groups of three around a laptop for 20 minutes and then we reconvene and discuss as a group, raise points about what we've done to try and try this as an exercise basically because actually I've been setting this, the one that we'll do as an exercise together, I've been setting this as an interview question and so I think it's probably a good idea if we look at it ourselves and make sure that we can pass our own tests, exactly, it's good to dog food, things like that, so yeah, okay so let's start off with, we're talking about specifications and I've got this unlabeled diagram over here which will become labeled as we go along, so there's different kinds of specifications and the kind I want to talk about, you know and I mean specifications in a sort of programming mathematically kind of way, not like big wordy documents, right, so how do we write what kind of specifications do we have, we've got, sometimes you have a specification that says do something and achieve a result that looks like this or achieve a result that has this property, that's a style of specification where you can say the end result should have this property, should look like this but it doesn't say anything about how you get there, it's a sort of non-constructive specification, achieve this end result, right, and those kinds of specifications are nice but it's not always easy to, there's lots of things which are hard to specify in that sort of style. A very common style of specification that we can use and the one that we'll talk about is the style of specification where you've got either a reference implementation or a very simple executable simplified version of what you're trying to do for real and that's what we'll, the approach that we'll concentrate on. So in the idea of, I mean if you have a reference implementation that's, it's a simple instance of this idea where, you know, for some reason you've got, you know, a version which is simpler, it might be low performance and the idea is that's, either someone else wrote it and it's obviously correct or you wrote it yourself and it's so simple that it's obviously correct and then you use that to compare with your complicated high performance whatever version. So that, that sometimes works, right, but it often, often that's a hard one to do as well because your reference implementation is just as complicated as your real one, you know, or maybe performance is not the problem so, you know, writing the reference implementation doesn't, you can still make errors in your reference implementation so, sometimes that doesn't really help you. So the technique I want to talk about is very similar to the idea of having a reference implementation but it's having a much, much simpler reference implementation, much simpler than the real one but still enough to give us interesting specifications and specifications that we can test in an executable way, you know, in using QuickCheck and all that kind of thing. So we will come towards this diagram then. So start labeling things. So at the bottom here, this blue one, this is the real implementation of something and it takes some input and it produces some result and this might be, I mean, you know, this looks like it's just a sort of pure function, input, the implementation here but this could be something that's much more complicated like it could be the entire node, it could be the wallet and the input here is the entire sequence of the blockchain and the output is the state at any particular point or something. So this is, you know, some kind of implementation that given a whole bunch of stuff over a period of time has some state or produces some results, whatever. The details don't matter too much. We can apply the same technique even if it's not a simple pure function. And then at the top we have our reference implementation. And so, okay, so these things represent, you know, the type of data that we have on the input and the type of data that we have as the output. Like, for example, with the wallet we will have, let's say, the state of the wallet at a particular point in time and the input was a whole bunch of blocks, let's say. So that's not a pure function, right? The wallet is this stateful, mutable thing.  And so what is this thing then? So this is the reference or the specification reference. And it is also a function or a thing like a function that takes some input and produces some output. But it doesn't produce the same types as this one. This one takes, you know, the actual blocks as defined in the current code and this takes something else. So the idea is that this is supposed to be something that is analogous to that, but is radically simpler, much, much simpler. And then, okay, and it produces some output. And then let's talk about what these things are. So, oops. And the direction of these arrows is important. So the relevance is that this is a, kind of what we call that one. This one is always called abs for abstraction. And this one is for making things more concrete. I can't remember. What's the standard, is there a standard name for this one? Reify. And then what would the other one be? Abstraction and reification. Okay. Doesn't really matter what we call it. So, okay, what's the whole story then? The point is that we want to start with a radically simpler or, if you like, more abstract version of the real input. So if this is, so the first example we're going to look at is going to be the wallet and blocks. So let's say that this implementation is the wallet and this is the data types that we actually use to represent blocks. And this is not necessarily the binary encoding, but the internal representation of blocks. So then this is the much simpler form of, that represents some of the information in here, the sort of important bits of information in here. So then we have a function that goes from the much simpler version into the real one, which we can then push through the implementation and get some output or some state at some point after pushing all the blocks through, let's say. And then we have another function that goes the other direction, the abstraction function, that takes only the, that forgets some of the information, transforms it in some way to take us back to a simpler corresponding output. And then the whole point is we say that to go from here to here should be the same as going from here to here. So the composition of, I mean, if you do it to do this in a, if these were pure functions, then you would be saying that abs composed with the implementation composed with reify equals the spec. That's the, that's the formally the property that this diagram represents. But yeah, what you're doing is you're starting off with some, some inputs that you generate over here. And you can use quick check generators to generate some input here.   And then, so that, that tells you that your real implementation computes the same thing as what your specification computes. So does that make sense to start with? So then the question is, what should this be like? And what should these things be like? How much simpler should they be? What are we trying to capture? So, okay, so then let's, we can, if we then move on to the case study in a second. Let's see, so what are the other, okay, let's just label the other important points in the diagram. Because this will be like, we'll keep this one as the theory one, then we'll flip this one over as we go along. So over here, we're going to be, like, using quick check to generators, to, to generate our, our abstract input. We have to implement a reify function to go from the abstract to the concrete. We have our real implementation, which we will have to discuss how we run this in this, in this setting. And then we have our abstraction function and gets us back to the, the abstract output. Was it other things I was going to label here? Oh, yeah, and then obviously what we're doing here is we're checking that these two things are equal. So the final, the final test property is that they come out the same, the same result. And this can be the implementation or a simulation. So this might be some way of running the real implementation in a simulated way, in a simulated environment, if, if we can do that. And you might need to do that so that we can run it, you know, hundreds of times in a quick check style test suite. So it may, so this, this kind of approach will then lead on to it being rather important to be able to run our implementations in a simulated way. And there are techniques for that, which I won't go into right now. But hundreds might maybe in his talk Thursday. Maybe there are some connections. Yeah. Oh, tomorrow. Okay, good, good. All right, so let's let's look at the first case study then. So I've mentioned the wallet. And the wallet is a really nice example that fits this pattern very well. So we're currently, as you know, rewriting the, the wallet code. And particularly it's, it's not the bit of the wallet that that's problematic is nothing to do with like HD derivation trees and all that. It's about the, the state that it maintains. So what, what is it that a wallet does? I mean, okay, it sends transactions. But the other major, the other major thing that it does is maintain information about the state of the blockchain that corresponds to your, your wallet, to your addresses that make up your wallet. So the, the major thing that that's doing is it's so it's the first step of this is to say, okay, well, what is, what is the specification of the wallet? And let's try and simplify as much as we can. What are the critical things of what it does? So there's, and the way that we've looked at it is to say, well, it breaks down into sort of two major parts. There's information that's derived from the blockchain. And then there's sending transactions. So let's, and let's focus on the first bit. Okay, the information that's derived from the blockchain. Now, so if you look at that, you know, the shape of the blockchain and the way that it grows, should tell you straight away that, you know, it's a list. It's a list of blocks or a list of transactions abstractly, right? That's the first step of abstraction to say, well, okay, yes, obviously it has all these details of pointers and hashes and blah, blah, blah, but fundamentally, it's a list of blocks or even it's a list of transactions. If you forget the boundaries between blocks, it's a list of transactions. And then what is it that we're computing? What is it the wallet maintains? It maintains, you have to be able to ask questions like, what's the balance? Or what's, but one of the major things that the wallet maintains is the UTXO, the UTXO of the, of your account or your accounts in your wallet. So that tells us that, yeah, one of the major things that the, the wallet is doing is it's, it's got this, this list. And it's, and at any particular point, you've got the, the summary of this is the UTXO. That's not the only thing it computes, but it's one of the major ones. And indeed, everything else that the wallet computes has to be computed in this style as well. Either directly from the chain or from the chain and based on other things that are computed from the chain or just based on things computed from the chain. Like you could compute the balance, I think, correct me if I'm wrong, anyone, but I think you can compute the balance just by looking at the UTXO. There's, there's details to do with pending transactions as well, but so you could compute the balance by looking at the UTXO, but the UTXO has to be computed by having, in principle, having looked at the entire history of the chain. And obviously we know that because you do that every 20 seconds, we need to do this by incrementally updating that the, the, the the UTXO is a summary of everything that's, everything of interest that has ever happened. But it's a summary that we have to maintain incrementally because, you know, the chain grows every 20 seconds and we can't, it's madness to, to go and scan backwards through the chain. So what does this suggest to us? We're computing a, everything that we compute is computed in this style of step-by-step incremental updates to a running accumulator. Somebody shout out, what's, anybody, come on. What, what, what's the first, what's the first thing that comes to mind? State? Like state monad? Yep. That's, that's a good one. Go on, Neil. It's a fold. What kind of fold? What kind of fold? How many kinds of folds are there? Say again? So is it, okay, there are left folds and are right folds. Which one is this? Yes, it's a left fold. So, you had the 50-50 chance there. No, no, no. You knew the right answer, you knew the right answer. So, so the UTXO function here is a function from, okay, well, I didn't say what this chain was, but let's say, let's say that it, we're ignoring blocks and we're just interested in transactions. So we'll say that it's a, the blockchain is a list of transactions to the type UTXO, which is, we've not specified it, but it's some kind of map or whatever. And we're saying that it necessarily is computable as a fold L of something and something. Details to be decided. But the point is it must be computable in that style for us to be able to do anything, for us to be able to do this. It must be a fold L. So this already, this, this is now, if we can fill in these details here, which is, it's not, not too hard to do, this can become our reference implementation, our specification of what does it mean to correctly compute the UTXO from the blockchain, right? And the, and this embodies all the things that we've got here. So let's see how this map, maps up, matches up. So this, this UTXO function is this function and the input here is this chain, the, the list of, list of transactions. And as you can see, that is radically simpler than, you know, the real chain, because the real chain has blocks and it has merkle trees and it has pointers and hashes and it's in a database and blah, blah, blah, blah, blah, you know, this is, this is complicated for good reasons. So this is the much, much simpler one, just a list of transactions, although of course it has to be, as a chain, it has to be valid, right? So this, this isn't just for any old list of transactions, it has to be, you know, there's a validity condition of what, what makes a valid blockchain, but it's not a detail we need to go over right now. Then this, this type obviously is the, the output type here, which represents this blob. Okay, so that gives us this function and this thing can be quite short. I mean, if we were to go through it, we're not going to go through it right now, this function would fit on the rest of this piece of paper, right? But yeah, right, thank you George. Yeah, so this is, this is, this can be very simple, whereas in the real implementation, there's lots of stuff going on, right? And there's lots of concurrency and state management and blah, blah, blah, blah, blah. Go on George. Even in this example, we should define what is transaction because based on this, we can have like invalid set of transactions and then it's not you took so, but maybe you took so something like that. Yeah, no, you're right. We need, we need to know what is a transaction, what is our representation of transactions and what is the validity condition. That's, that's absolutely right. So the approach that we're taking, the Edsgoen, Edward are taking right now, is that they don't have to start from scratch here because we already have a mathematical formalization of a very simplified form of UTXO accounting, because Bruno was given the task a few weeks ago of writing down a simple mathematical description of UTXO style accounting and Ethereum style accounting and trying to match the two up. And so he's, you know, he's gone and read a couple of papers and he's done a few, you know, a simple sort of mathematical description of what is UTXO style accounting and how does it relate to Ethereum. But we can just grab the, that bit, you know, the UTXO style account. It's like three pages of a LaTec document that Bruno's written down. And so he's already come up with a nice description of what our transactions precisely, what do they consist of, and what does it mean for a chain to be valid. And so we can, we can just take that and use that exactly as our, so like last week Edsgo took Bruno's paper and took the first three pages and translated it into Haskell. And that becomes the transaction type, the chain and the function for computing the UTXO and the balance from UTXO. And that stuff's all very small. And we already know that's a sensible definition because he's already gone through and written some lemmas about how these things relate to other things and anyway. So it means that we're starting off with a sensible, very, very simplified form of transactions in UTXO style accounting. I think it was mentioning here that for wallet we actually want to go from UTXO representation to accounting representation. And Bruno was effectively proving, if we talk about the same thing, he was effectively proving the equivalence between account based and UTXO. Yeah, yeah. And Bruno is looking at the relationship between Ethereum style accounting and UTXO style accounting because we want to be able to move value from one to the other for all this side chain and stuff. So that's why he was looking at it. But then it became a very useful bonus because Edsgo didn't have to like, you know, go and work this out himself. He could just go and steal it from Bruno's work already. Okay. Now, so what does this throw out? This throws out blocks. It throws out signatures. So all the cryptography stuff is gone. It just has the essential thing about transactions, inputs and outputs, and what is the UTXO and how is it computed? So this, right, so this gives us, you know, we could write, we could finish writing this down and we could all agree that this is a correct description of computing the UTXO from a chain. And so then that gives us our reference implementation. So now we're in a good point. We've got this thing. So then the next task to flesh this out with the wallet, and this is what Edsgo was started on last week, is writing this function to go from this representation into the real blocks. And so, and this is where it's actually very useful in just a side point in the wallet code. It's very useful to have pure functions for constructing these blocks. One of the things that he found was that there are pure functions, but they're buried kind of deep inside. All the, all the things are exported or all in terms of effects that then also push things into the database or, and he wants just pure functions for just constructing these blocks so that he can implement this reify function. So that's a useful thing to bear in mind. For these kind of testing things, it's very useful to be able to have pure functions that construct the, these, these data types. Yeah, I have a short comment on this. So basically, how do blocks you write or is it known? All right, so I have a short comment on this. We already have the blockchain writer, as everybody knows. Yes, that's right, but it doesn't help us. It uses a functionality from the core, and the problem is we cannot, like, it doesn't make any sense to, to write in a pure functions construction blocks because it is, or cumbersome, it's a lot of code. And it will be, it will be duplication basically. What we did is we abstracted a lot of, a lot of core components instead for the blockchain writer. You can use pure database with it, but it's like, it can be effectively pure except for maybe some, some, some things with logging. So I have to respectfully disagree. The, the block generator is useful, that, that code that, that is there, but the fact that it isn't pure means that we can't really use it here because we, we need to generate those blocks without pushing them into the, into the chain or into the database or into the system. We need to just have them in memory and then do something with them. Whereas the, the current block generator, you can only, you, you start from some, some input about what you want to do and then it, it generates the blocks and it pushes it into the, into the stateful part of the system and pushes it out through the B list and error on all the rest of it. And we need to be able to do just make me a block that's valid without doing anything else. Yeah, sure. So yeah, so that, that's, that's what the first, so when, when EDSCO started on this last week, the first thing that he decided that needs to be done was, well, yeah, finding this stuff, you know, constructing this function or at least constructing the, finding the types for these things from, from the paper and then started on writing this function. And because that was the, that was the first thing that he thought of is like, okay, well, we talked about what the specification ought to be and his first thought is, okay, now how are we going to be able to test it? So before we've really written, before they'd really written any part of the new code, it's, how are we going to be able to construct this kind of, this kind of test? And so yeah, started on that. Um, this, the function in the other direction, um, well, what's it going to be in this context? It's going to be a function that goes from the, uh, let's see, what's the type? The abstraction function. I mean basically it goes from the, uh, the real implementations UTXO, uh, to the, the sort of specification style UTXO. So it's just a conversion of representations. Um, and of course that loses a lot of information. I mean the real UTXO has, you know, the real, uh, transaction IDs and, you know, there's more, more detail in there.  Um, going, going back to the, the much simpler style of UTXO that came from the, um, from the specification. So then how do we put that all together? Um, so in the wallet code that they're looking at, they want to be able to test, they want to be able to do a unit test of the wallet without having any part of the core. They want to be able to test the wallet completely on its own. And so, um, the, the, the first thing to do there was to identify what is the boundary? What is the interface between, uh, the, the core code and the wallet? And it turns out there is actually a very nice, simple, uh, boundary, which is this B-listener interface if any of you've looked at it. But it, and it's basically just, here's a block or here's a block that's being rolled back. Uh, it's a sort of notification interface, uh, to say that we're moving from here to here or we're rolling back, we're moving from here to here. Um, so that, that gives a nice, a nice narrow interface between the wallet and the, and the core code. Um, the core code informs the wallet that a block has been added or the core code informs the wallet that a, a block has been rolled back. Uh, and that actually, so that, that's, no, maybe I won't go into that diversion. Um, yeah, okay. Um, and then let's see, uh, where was my train of thought going on this? Um, yeah. So you've got this narrow interface and then the point is that we can, um, use that interface, uh, as part of this kind of style testing without having the core code in there at all, without having, sorry, without having the node in there. So any of the state of the blockchain, right? Or obviously the, the wallet code makes use of function calls from the core, but it, it's not going to have the blockchain in there. So what we do, or what we are going to do is that we generate all these blocks, uh, and then we just push them straight into the B-list interface. So we don't, we have the wallet code, which has its, you know, B-list and our API that it responds to. Here, here's a block, here's a block, here's a block. And we just do that. We just push in a block into the wallet code and say, here is a whole sequence of a thousand blocks or whatever. And here's one that got rolled back. Um, without having the, without it being running in the context of the node.  Push it through the abstraction function and check that it's equal to the UTXO that we're expecting. Um, and that way we're able to get, you know, a unit test of the wallet or of, you know, the UTXO computation of the wallet and all the other similar things that are computed from the chain. Um, without having to test it in the context of the entire rest of the node. Because if you do it in the context of the node, you've got to, it's hard to do rollbacks, right? Um, you've got to, I mean the real chain doesn't rollback very often. I mean it, so far it never has, right? So, of course, we will also do integration tests, but, you know, you want to be able to do them as small as possible first, so you test the logic there and then you do the integration. So, but we can do, we can do the same pattern of tests, uh, for the integration as well. Uh, it'll be, we won't get, we won't get rollbacks in that case. Um, or at least, it'll be a bit harder to, to achieve them. Um, but in that case, we just, we just change what our implementation or simulation is here. Um, and we, instead of pushing them straight into the B-listener interface of the wallet, we will push them into the, the, you know, the node and it will apply it to its database and it will inform the wallet that something happened. Or we could go even one step back and say, instead of pushing blocks in, we will push transactions in one by one. Uh, and again, check that the UTXO comes out right at the end. Um, so we can do that same, this same style of tests at just at the wallet or at the wallet and node or at the, um, further out, you know, all the way to pushing transactions in from, fully from the outside. Does that make sense? Any questions on that, on that case study? Um, where's, where's the, uh, the mic? Sorry, where? Run around, Jerry Gay. Yeah, thanks. Right, so, is it on? Okay. I have a question regarding the reification stage. Uh, namely, if, since we're converting from a simpler representation to a more complicated one, it's possible that we are mapping to a large number of possible values in the more complicated section. Well, maybe even in some circumstances, no values. So for instance, if the simpler representation allows some things that the more complicated one forbids for some reasons. Right. So how do you deal with that? Are you, would you test, uh, several different things? Would you do that non-deterministically or how would you? Okay, so the, the, the choice of this representation should be such that everything that exists here should be mappable into something over here. Um, so we shouldn't be generating, we shouldn't have a representation here that allows things that don't make sense over here. I'm, I'm not sure if, I, I see situations where it would make sense to have a simpler representation where things don't map into the more complicated ones. Well, then it, well then it makes it very hard to do a real-life function. Um, Well, yes, but that was my question. Yeah. How would you approach that? Well, the answer is, you don't do that. The answer is that you, you get to choose what this representation is. And you, you choose it as an abstraction of this thing. Okay. And so, uh, everything that can be represented here can be mapped down to this thing by forgetting the bits that you don't care about. And everything that exists over here can be mapped back into. And so there's a, there's a property that if you combine the reify and abstraction or, or if you, well, these are in different types here, but, uh, you could go in the opposite direction and you should get back to the same thing. Maybe to say specifically what I was thinking of to make it more clear, I was thinking of in the context of smart contracts. You might, for instance, encounter a situation that, uh, the abstract notation doesn't deal with, uh, computation limits. So what in the theorem would be gas limits and so on? Generating random programs is always very tricky. Doing this kind of stuff with programs, smart contracts is, is, is, is hard. Okay. I mean, that's a whole topic in itself is how do you generate valid, simple programs? So maybe, maybe you could then still answer, how would you deal with mapping to multiple, uh, possible values? So for instance, in this situation, you have, uh, that you, in the abstract representation, have a list of transactions and then in the concrete one, you have blocks. Yeah. So there are multiple ways to distribute that, obviously. How would you deal with that? Yeah, uh, that's a very good point. There is extra detail here and you have to make a decision about that.  So, uh, we would just add enough extra arguments to a reify that says, um, that would, that would control how they end up in blocks. Uh, so that we can, as part of the quick check test say, well, let's, let's try it and make sure that we get cover cases where there's empty blocks as well as non-empty as well as to get, to get a reasonable coverage of the, of the, of the space of possibilities. Um, Okay. So it's not a, it's not a pure function from the abstract. Well, it may be a pure function that has additional arguments. Okay. And we make use of those additional arguments to, to cover the, the, the space of, um, of possibilities in the, in the ritual type down here. Okay. Thank you. Uh, what's the, what's the time now? How are we doing for time? Okay. All right. So now the, what, what I want everyone to do now is, uh, in like groups of two or three, uh, we want to look at the next case study, which is much simpler. This one is, you know, is like several weeks of work. Uh, I want to do one that's like 20 minutes. Um, and so the, the, the task is, we want to specify, but we're not going to actually implement and test, but at least specify, uh, the voting system that we have in Cardano, or at least a simplification of the voting system that we have in Cardano. We can, if you, if you have time, you can do the next step. So, uh, the question is, and this is, this is the question I use in interviews is, um, how would you, uh, test and, well, the interview questions, how you test it, which is this thing as well. Um, but how would you specify, um, in this kind of style, right? You know, a simple function that captures the essential details. Um, a reference implementation. How would you specify the voting system? So, what are the, what is, how does the voting system work in Cardano? Or at least a simplified version. George will jump on me if I get the details wrong, but it's, the point is, we're trying to show you. Yeah, but yeah, so we're, we're, we will add a second detail later. Um, but if we take a simplified form, we say that at some point, someone proposes a, an update. Um, uh, and they, okay, there's a detail that they had to have had a certain number of signatures, blah, blah, blah. We'll ignore that. We'll say, someone, someone's allowed to propose an update. And then, uh, everybody votes. Um, and after a deadline, at the deadline, we make the decision. Um, as to whether the vote succeeded or, or failed. And at the moment, and we do that on a simple majority of the people who voted. Right. Now, there is a detail that we won't cover initially, unless, unless you do it and we can, we can add the extra complexity later, which is, the, the vote can actually end early. But for the, for the simple one, let's start with, let's specify it that, uh, at, at the deadline, we make the decision about, did the vote pass or fail? Okay. So, what I want you to do is to, in groups of two or three, think about that problem. I've under-specified it, deliberately under-specified it. Right. So there are things that you will have to go, well, okay, what information do you actually need to work this out? You know, there'll be things that, the, the concrete, when you start to write this down concretely, you have to be precise. And you realize, oh, we need this information, we need that information. So discuss that amongst yourselves. And, uh, we, let's reconvene in 15 minutes. And, um, I'll ask a couple groups to, uh, raise, raise points that they've noticed, and we can, we can discuss. Is that, is that okay? Is the problem clear? Any, any questions? Apart from my deliberate under-specification, I can repeat the specification if you like. Okay. Specification is, the vote, the vote starts when someone proposes an update. Everybody gets to vote. That's vague. That's the idea. Everybody gets to vote. At the deadline, and there's a specified deadline, let's just say that it's, you know, some, some number of slots or some number of, some period of time. At the deadline, um, the vote passes or fails based on a simple majority of the people who voted. Or of the, of the stake that voted. So the details about stake and blah blah blah timing, that, that's for you to flesh out. And then try and, try and do a simplified, uh, um, clarification. Yes? Oh, okay. We can do, yes, for now, let's just do one proposal at a time. Someone, someone volunteer, otherwise I will start volunteering people. All right. Do you want to, uh, grab the mic? So remember the, the, the point was, I asked you to implement this spec, or reference implementation. You don't have to worry, and which means you've got to choose what these types are, but you don't have to think about the rest of it. All right, go ahead. Okay. So our, um, our specification was pretty simple. Um, we def, we, we defined a vote as consisting of an amount of stake and a, and a four, four or against. Okay. Um, then the specification says we take an, an unordered set of votes. Okay. And produce a result. Okay. Um, and the, basically if the, if we, if we add up all the, all the stake for the things which are four, and subtract all the stake for the things that are against, if the result is greater than or equal to zero, um, it passes otherwise it fails. And we allow our set of votes to be empty. Okay. In which case it fails. Okay. So what was, so let's review the details. So the, the representation here was a set of votes. Set? Yes. Uh, and the vote was the, a pair of stake. Stake and four or against. Yeah. Okay. Um, okay. Uh, does anyone want to comment on that? Uh, so first of all any comments on, on this style or approach and then, and then we'll go around and do other, other people's approaches. Does anyone want to comment on? So stake is actually already, uh, like an enhancement of, uh, it's, it's already more complex, not, not the most simplified model. So if you need to consider stakes, it's okay. But if there is no such requirement, you can consider that, uh, every person has just one stakes or you, it just have number of people vote positively or negatively. Okay. So this is the first point was that my, my specification is ambiguous. Right. I didn't, I didn't mention a stake, but this is a, you know, when, when you come to, I mean, yeah, we, ultimately, we have to consider a stake. Right.  Um, so I think, I think considering stake is, I mean, this is a choice about what, what is the exercise. But if you think about what would we be doing for the real specification of the system, obviously we must, we must consider a stake. Yeah. So if you've not considered a stake, that's okay. Uh, but if you have them, yeah, that is, that is a detail of the system that we need to, need to include. So absolutely, the, uh, uh, yeah, so the, the, the outcome of the vote, so we need to know, as part of the input, what, what stakeholders, stakes are. So one, one thing I spot about your approach, uh, one thing that makes me wonder is what about, uh, can I, can I vote more than once? Um, what is, what is your state, your set representation do with that? So, sorry, lots of running around with mics. So we've, we've, we've abstracted away from all the questions of how we authenticate votes. Mm hmm. Uh, uh, we, we've got rid of the order as well. Uh, we've, we've got away from the order. So, so, so the specification is we have a set of votes. We didn't say how we got them. Yeah. Um, and the voting system returns the result when you're specifying what the result should be. Okay. So we're, and we're not capturing the detail of can I vote? Can I vote? Can I vote? Both ways, more than once, et cetera. Okay. So that, you simply said that's out of scope. We're saying that. We're taking, we're taking that as out of scope. Okay. All right. That, that is a legitimate decision. Okay. Any other volunteers to, George? Just one comment also. It's question, should we consider, like, are we, is it out of our scope that some votes could go after deadline? Or is it so, so if you have some vote after deadline, we should ignore it or we should cancel whole voting or we say that, like all those that are passing into our function as they are just, they haven't all for deadline and we don't, don't need to consider this particular deadline. Well, let's think about what we would do. If we're doing this for real, what would we do? We would say, well, of course, we can't control when people's votes end up in, unless we probably can't control when they end up in the chain. And so we say, if they can exist past the deadline, but they will be ignored. So our, our specification would have to allow for, as input, votes that take place, votes that are after the deadline, but the specification would say that they obviously contribute nothing towards the, the result. Yeah. And also, it makes even more sense in extended versions that you converse that in, in which you can have majority of votes hit before deadline. And if you consider this version, you certainly need to engage. That's right. Yeah. Yeah. So it's, it's worth noting that in the real system that the voting rules are slightly more complicated where we allow the votes to end early. If, and what's the rule exactly, George? If an absolute majority of all stakeholders, not just those voting, but absolute majority of, of stake has voted one way or the other, then the vote ends early. Yes. Yes. Yes. So for, for doing this for real, we would have to incorporate that, that detail. Yeah, because that line is, it is in such a way that in average case, we will have vote, vote, like we will have voting process to end up as fast as possible as soon as we have majority. Yeah, this table. Okay. Next, volunteer over this table. So we considered a couple of other things. Yeah. Okay. One was the notion of the majority versus the total set of stake, the vote that people actually voted not vote. Mm hmm. And one of our questions back to the management would be what's your policy for people who don't vote? Right. Because that's a question about the majority, notion of majority. Yep. Secondly is that we have notion of sequence that somebody would propose. Mm hmm. And then people would receive proposals. And then they would vote on proposals. We didn't consider, we must admit we didn't consider double voting. Okay. But we did consider the notion that there was a deadline which was part of the proposal at the beginning. And then we were starting to refine down to the level of what were the transitions that would be seen mm hmm. By either, by the actor performing the action, or the ones that are just watching the blockchain. Mm hmm. How the sequences of things would start to occur. Okay. Do you want to say something more, did you? Or... Oh, I wanted to say something else here. Yeah, okay. And then I wanted to volunteer from over here somewhere. So, so the, the, so I think our assertion is that, is that everything, everything that everybody else has just said already represent, represents a ratification of this spec. A ratification. Right. In the, in the sense that if you start thinking about Oh, would you end the voting early or we're, you know, the question of whether someone voted before the deadline or not, we're saying, but that's all taken care of by, with this, this is the set of people whose votes count. Yeah, because your, your version is more abstract for most other people. More abstract. So, which means that you, but that means that you can't capture the details of people voting twice. Absolutely. So, so, so... Because the representation doesn't allow for... So you could, so, so, so, I mean, you can extend this approach to, to, to, to, to stack more on top. Yeah. That's right.  That's a good point. That's a good point. Yeah. Someone, someone from this table. I'm volunteering you. All right, sure. So, we, we considered the idea of having a proposal with a start time and an end time. Okay. And so... So the proposal itself says what it starts now or starts with some, at some slot number and ends at some other slot number. Yeah. Okay. Yeah. And then this notion of having ballots where each ballot has an associated amount of stake and whether it's in favor or against. Okay. So each, each vote is a, just a pair of the stake, of the, the, like the percentage stake of the stakeholder or the absolute stake of the stakeholder. And yes or no, whether they're voting for against. Yeah. Okay. And also time we... There's like the slot number or something. Yep. Okay. And then we had this notion of just making sure that we're looking at a set of ballots that fall within the time range specified by their given proposal. Mm-hmm. And then from there just tallying up the total number of... The total amount of stake in favor versus against if there was a majority in favor then it's considered ratified. Okay. That sounds, that sounds eminently defensible. So this, the summary there is that you've got a list of events, things of interest which is ballot being started which tells you what slot it ends in and the list also contains the votes and then your specification is a function from that list of events, votes, proposals, etc., to a yes or no and what time slot the yes or no occurs. Something like that. Yeah. George, do you want to comment on that or? Yeah, I want to comment. Also interesting is that when we've been testing it we were actually having like a sequence of events which are like one block applied or one block rollbacks, something like that and actually you can have like one block in place with new votes but then you can have this block disappear and these votes to rollback and actually voting result might already be in place but then you go back and need to consider new votes and delete old votes so this kind of thing also comes to place when you revile all this stuff. No, that's actually a very interesting point. Yeah, it's very interesting that when you're dealing with a blockchain of course you know the the last block is not stable and so we shouldn't tally up the votes during the slot in which the vote ends we should actually tally the votes cave slots after the vote ends because that's the first time at which we know absolutely for sure that it will never ever change. Yes, that's how it's implemented but to test it you probably would like to like try like okay it probably assumes on this table slot but what if we like try to do it like to try to induce some instability like would survive is actually implement so. So the point here is that there's an iterative sort of refinement of the specification that you start off by thinking like the the most abstract one and then you add you add complexity into your specification by considering these issues one by one like the oh we can vote more than once we need to know slot times we need to know and then you make the valid point that with a blockchain things can be rolled back so so when do we know it's stable and we can I'm I'm confident that we can capture of that notion is part of the specification as well it's still in this very simple style and indeed we could do the next step which is ending voting early as soon as yeah I I just have one note not about the spec as much but like if you and as soon as there is 50% of stake and let's say you add the you know the case just to be sure that you capture the rollbacks it's also for in terms of like practicality a bit weird because you could have an updated middle of the night or something it's not predictable right but this this has you know maybe you can capture this in the spec or not but it has the you know the PR effect and so on so if you announce the update is going to be rolled you know rolled out on Sunday and Sunday it's on Friday that my you know that's a very important operational issue which is slightly hard to capture in these kinds of specifications yeah it might have different effects but maybe maybe you should include in your spec that the validity condition of a proposal is that it can't end on a Sunday night you could you could totally do that if you want to there's a question of how much detail you want to capture does any other table anyone over here want to go on Alex I don't think we've actually added anything new everything that we've done has already been mentioned it was we chose to use a list of events yeah making a proposal the proposal is very simple it's just an ID there's nothing to it and then the the votes just a voter ID and a proposal ID and then of course so your your representation allows for more than one vote to be ongoing at once yes yes okay because you've got different identifiers for different proposals that's right and when you vote you say which proposal you're voting on okay yeah and we neglect to do include any stake probably should have but so I guess to all right so you incorporate one improvement or one more a bit of realism in that direction but not that not the stake one yeah I suppose to do the ratification function for this we would just choose a constant stake maybe one stake yeah and then to verify it it's similar to what we see on the whiteboard there it's like a fold you keep some some map of proposal IDs to current proposal state after you update the time after one has been after the deadlines been reached you to change your past you've got an assumption that your events are in order yes the assumption is there and are tagged with their slot number yeah well we just yeah slot number yeah it could have been a slot number time time slot number whatever yeah mm-hmm how we produce we produce a list of output events in a way so incrementally so at at the time when a proposal has been handled we say we say now that proposal is now finished right because because your specification captures any number of so we could have an infinite list of input events and we would incrementally produce an infinite list of output events and is your executable specification small enough to be you know fit on kind of one slide and everyone would agree that it was correct no well yeah 57 lines of code including including type definitions yeah okay that's that's still you know considerably smaller than the real implementation so okay is there anything else anyone else wants to add about about this whole thing otherwise we can just wrap up and go and get some lunch so let's see what would what would I summarize from this this is a this is a quite a general approach to testing lots of different kinds of components I think I think you can see that it's relatively realistic that you can test you can test things like you know the wallets that are complicated and stateful you have a lot of choice in how you choose your your abstraction your representations of these things and yeah so I think it's a very useful technique to have in mind when you're starting or you're rewriting a new writing or rewriting some some component and and start by thinking well what is it what is its specification can I and how will I test against that specification and yeah this is not the only approach to to this kind of you know quick check style simulating blah blah blah approach but it's a it's a fairly general one that works even for even for stateful components but it's particularly good where you've got stateful components if you can run your implementation in simulation so that you can do things like faster than real time right so we don't have to wait 20 seconds through every right so this leads on to techniques of how do we write you know how do we write stateful code where we can abstract in such a way that we can actually run it in simulation I mean you know in our code we've got lots and lots of abstractions over it over effects but not always in such a way that it's easy for us to run them in simulation faster than real time and being able to do that is really useful to be able to do this kind of quick check style you know to do this kind of setup so that that's a useful thing to also keep in mind when you're starting a new development of a new component can I run this thing in simulation and and for real any other questions anyone wants to raise about about this okay all right thank you very much


Open a PowerPoint and choose New, Blank Presentation. Then select the Design tab on top and find Slide Size. Choose Custom Slide Size and make your width 30 inches and your height 40 inches, making sure Portrait is selected as well. Click OK and PowerPoint will ask you if you want to maximize or ensure fit. We recommend choosing Ensure Fit so that you can see the whole thing at once. Then on your Home tab, select the Layout drop-down menu and choose Blank. Now go ahead and do a Save As using the File tab and name your poster project and choose a place to save it too.


Barbara asks, is there a way to create a report with all open approval requests in it for several users? We have set up an approval flow via Power Automate to approve documents and SharePoint. The approvers are approving via Teams. We need reports for each user to check which approval requests are still open. At those TPS reports? No. I'm assuming so. Use the new approvals apps into the approvals app in Teams. See if I can say that three times fast. So in Teams in the left-hand navigation, click the little dot dot dot right there on the left-hand side and look for approvals. If you haven't already added it, add it to your Teams application. It will show you approvals across your entire organization for you. And if you've submitted an approval, you can see all the outstanding ones for everything that's waiting. Yeah, and if you go in the back door to Power Platform that you'll have at the approvals there, which things are still running too. You can see what's still running and hopefully identify some of the things that may be hung up or who you're waiting on, right? That's always like, who's hanging up the show here? Mr. Blame. That's right. It's long, cold in the tent, yeah. Yeah, you can see where it's at. You can see what's going on. You can see, like Sherry said, who you're waiting for. Super cool. Yeah. That's what we were just... The third-party app scenario. Again, there's so many third-party apps that help on those sorts of things too. This one's actually a Microsoft app. It's not even a third-party app. That's right. Yeah. But there are, yeah, there are definitely third-party apps that can make it even more intuitive. Yeah. Depends on how far they need to go with it. Yeah, that's just kind of a side thing here. I know that Barb is not asking about it, but like if you're gonna do a migration, if you're reorg or restructuring as well, to know what's running, to know what's out there as well, so that what are you gonna break? What processes are still running? What flows are midway through before you attempt to do a migration? It's important to have access to those reports as well. Definitely.


I'm represent positive money and we're a organisation in NGO trying to do research in campaigns to reform the money and banking system so it's fairer, more democratic and sustainable. We actually own polled a lot of our supporters, we represent thousands of supporters across the country and over a thousand came back and they actually said that 22% of them said that climate change that climate change is the most pressing issue for the Bank of England right now, 35% setting inequality, 19% said risk of financial crash, 13% high private debt, 9% high house prices, 1% inflation etc etc. It shows you what a good job we're doing on inflation. Anyway the point is I think a lot of people feel that the Bank of England isn't doing enough about climate change Mynd i chi'n gweld y PPC yw hwn i wedi ceisio y fan hyn yn 12 ymgyrchu, ac yn y gallwch chi'n bryd o'r dysglosio, ac mae'n ddifeniau'n fydd yn mynd i edrych. Mae'r Bank of England yn ei gweithio i fynd i ddechrau'r maith. mae'n bwysig ei'r cyffredinol ar dweudio cyhoeddion 10 miliwn ffordd neu'r ddweudio'r ddeunydd, yn ffosgol ffordd i gael, a chyfodd yr ysgolwch ei wedi cael ei wneud ar y swyddiadau gwahanol. Mae'n ddweud i gydag y byddiol, oherwydd mae'n gweithio'n ddweudio'r ffordd i'n ddweudio'r ddweudio'r ffordd. Rydyn ni'n gydig i'r sgwp ffordd yn siaradol. o ffordd, i'w ffinansiol, yw ydych chi'n meddwl ymweld hwnnw yn ffordd o ffodol. Yn ymdweud yw... Yn ymdweud yw... Prydych chi rydyn ni? Yn ymdweud. Prydych chi'n meddwl ymdweud? Rydyn ni'n defnyddio chi'n meddwl i'r ysgol. Rydyn ni'n meddwl i'r ysgol a'i meddwl i'n meddwl i'r hyn o gyflynyddoedd yn gorffydd. Yn ymdweud yma, ond yw'n meddwl i'w fathogwch nesaf. Mae gyn gallwch, ffagafol, o hytrif, Ac mae gynnodd, os y gydig iawn, oedd ymweld ysgrif wedi'i Fedor Cymru. Felly mae'n gydig i ddoriadau yn gwyllwn yn ei wneud hynny.  So we have very specific responsibilities that are given to us by governments, and our responsibilities are the thing that your poll is least worried about, monetary stability, inflation being low stable predictable, and the health of the financial system. So what we have said with respect to climate is that we can see a future risk, in some cases an insurance for example, that it has present implications, but for banks and others it's a future risk that the system has to get ready for, and I think it's fair to say that we have led amongst central banks in this thinking, but it's certainly amongst the leaders if not the leader in thinking about how the system has to get ready for the risk. Now the second thing is that, and we have catalyzed a lot of changes internationally, that $100 trillion figure is a significant, that is more, that's 20% more than global GDP. Again to put a number around it just in terms of the scale of interest in which companies are taking these risks seriously, which companies aren't, which have opportunities, which are part of the problem, which are part of the solution, that's what that means. Now disclosure is disclosure about what your risks are, where your opportunities are, how much greenhouse gases you emit, how much you plan to emit in the future, those types of issues. Disclosure is not making those decisions for companies, it's either you're there or it's providing the information for the market to then make a decision. With respect to, and last point, with respect to the purchases that the bank makes, if the bank ever makes purchases of securities, whether they're gilts of government bonds issued by Her Majesty's Government, or in the case that you referenced corporate bonds issued by companies, we are very conscious to make those purchases in a way that doesn't distort the market, because if we distort the market we are making, unelected officials are making a political decision. If somebody wants to change the tax system, if somebody wants to accelerate our climate policies, if somebody wants to build more schools or hospitals or fewer, for that matter, those decisions are taken by elected officials through Parliament. If somebody is concerned about keeping inflation low, stable, predictable, a financial system being secure, and adjusting the future of the financial system in a way that's consistent with those, that responsibility is devolved in a very specific way to the Bank of England. We can affect those, and climate comes into that in the sense of what the future of the system might be. Do you mind if I add very quickly that mark, which is just to say remember that that decision on that aspect of QE was by a committee of people, a monetary policy committee that is directly accountable to Parliament, and that committee on which the Government and I have said, and they thought, you know, considered that very carefully, and it was very clear that everyone on that committee, including the four external members, who have no business but to account to Parliament on all these questions, that is their only reporting line. They don't work for the Bank of England. We're very clear that it was very important that we should step back and buy what the market was rather than skewing decisions this way and that. And that is their primary responsibility. Hang on. It is monetary policy. Is their responsibility, their responsibility is to hear the inflation target, nothing else. And I think it's quite important that people fulfil the responsibilities they're asked to fulfil on more other thickness, which is what I'm talking about.


Tana Hill under some pressure fires Fitzpatrick What a throw what a catch for the rookie fourth-round pick just activated from the practice squad last week


Awesome. Well, my name is Ishaan, and I'll be talking about a product that we're building here in CryptoEconLab called Atlas.storage. And Atlas is we're building a decentralized geospatial data platform. So the agenda for today will be, we'll talk a little bit about the vision, the roadmap, and why we think this is an important product to build. And then I will go into the market opportunity, and specifically into the Filecoin economics and the geospatial market. So I think my slides might be out of date here, so we'll see if I had a missing slide or not. So the vision for Atlas is to build a platform that stores all of humanity's geospatial information on the Filecoin network and make it available via APIs and SDKs, and integrates and shares other organizations' geospatial data to the broader community. And so the second part to Atlas's vision is to build a community that advances geospatial data sets and Web3 native software and technologies. So what does that actually mean, right? So I think there's like a unique opportunity here to make geospatial data more accessible and usable to researchers, scientists, engineers, and entrepreneurs. So right now geospatial data sets are really highly segmented in different parts. If you want geospatial data from the U.S. government, you can find a couple on data.gov, but they're all over the place and not easy to use. The APIs are not easy to use, and we want to provide an end-to-end service that supports storage and computation with smart contracts to unlock use cases that didn't exist before. So what that really means is you can think of an example of where you're like a homeowner and the home gets destroyed by a hurricane or natural disaster, right? And an example of where somebody could use Atlas as a property insurance company that has a policy on that home, you can get geospatial data such as satellite imagery or natural disaster data, or it may be run some computation on it, so in this case it could be like a machine learning model, and then tied that, the output of that computation to a smart contract, and then like fulfill a transaction based on the output, so then like in seconds you could say, well, it looks like three quarters of your house is destroyed, and so we're going to pay like X amount of the claim, right? And this is like a use case that could be done in seconds or minutes right after the data is available on that property in this example, where in like most of these use cases where people are using geospatial data to make a lot of like real life decisions, generally these decisions happen in like weeks or months and not in like minutes or days, right? And these kinds of examples, especially with natural disasters, like days is what homeowners or people who have been like kicked out of their house because of a natural disaster really need. The second part to like our vision is like a community driven approach where the community is passionate about finding useful geospatial data sets, uploading them on Falkoi Network and making it accessible, so like we don't want to be the only people, like our team doesn't want to be the only group of people who are storing geospatial data on the Falkoi Network and doing all the work we want. The community get involved, community members helping other community members, and you know that gets just like a better flywheel for like getting more data onto the Falkoi Network and then the community can decide what they think is useful as opposed to like us as a team deciding what we think is useful. So this is actually a picture of Landsat 9, which is a satellite that's in space right now by the US government, by NASA and USGS. So Landsat is a program that was started in 1972 and has been capturing pictures of the Earth for the last 50 years and started at Landsat 1. We're at Landsat 9 now and the Landsat program in aggregate has collected about 5 to 7 petabytes of imagery and metadata. So like this is a great use case to get this large of a geospatial data set onto the Falkoi Network and so we're going to start with storing satellite imagery and making those images and scenes that are available in Landsat available through retrieval APIs. And then after that we're going to go to other satellite imagery, low flying aircraft imagery, et cetera, and then also other types of geospatial data. We can imagine like climate, water temperature, land temperature, land classification. These are all different types of geospatial data sets that exist that are really useful to different types of people depending on what the use case is. So like an example is land classification is really important for like the agriculture industry and insurance and agriculture and like figuring out like where what crops grow where well. And then finally we want to partner with existing geospatial data companies to integrate their data into Atlas. So like an example of this there are a lot of companies that are already buying these, you know, buying or downloading these geospatial data sets and then creating proprietary data on top of it. So an example of this could be there are firms that are like building analysis of properties all throughout the US or Western Europe and working with them where they might be like a Web 2 company but want to get into Web 3 business model or have a distribution channel that didn't exist before of their B2B company and get them onto the Atlas platform so that those, that data can be accessible to like, you know, the growing Web 3 community that wants to build really cool technology or apps. And then finally one goal that we have is like we're big, you know, obviously being part of our call labs. We are big on open source and open standard so like all of this is going to be done in an open source way. We're going to be following open standards such as stack or cloud optimized geo tips if anyone here is a geospatial nerd and knows what those words mean. So why do we think that like Atlas is a good idea and we want to store geospatial data on the decentralized Web? So one is that geospatial data is kind of core to what we do. There's lots of use cases and insurance, property, construction, lending, agriculture where this kind of data is used every single day. And because of that there's like hundreds of petabytes of geospatial data that, you know, that exists out there and bringing that kind of data to the Falkland network has a lot of like powerful network effects. Second, there's like a lot of like physical and virtual worlds that I've been integrating recently so you can think about like metaverses or like play to earn games and even, you know, other games where something might happen in the physical world and then there's like something happens in the virtual world based on that action happening in the physical world or vice versa. And so we're able to kind of support those kinds of, you know, products that people build. And really like Atlas's mission really aligns well with like Filecoin's mission. So like if we, you know, we've seen, a lot of people probably seen this side a couple times by now, but the mission of Filecoin is to create a decentralized, efficient and robust foundation for humanities information. And for us we want to, we are very aligned with that because for us it's kind of the same thing, but for geospatial data and then making that geospatial data accessible to everyone. Finally, the economics of the Filecoin network really make it a lot better to store geospatial data as opposed to like storing it on centralized cloud computing platforms. And I'll get into that later, but like the Filecoin economics is like a huge boon to geospatial datasets. So I'm going to talk a little bit about like the market opportunity here and you know why Filecoin is great for geospatial datasets and overall the geospatial market. So like the market size for satellite and aerial imagery is estimated to be $30 billion by 2030 and that's just image capture. So like when I say image capture I mean like actual satellites or aircrafts or drones in the air taking images and people reselling those images. That doesn't include the analytics that people do on top of that and that market size is estimated to be $110 billion by 2026. So you can tell that like imagery looks like over the next decade or two is going to become a commodity and the real value will be in like the analytics that people can get from imagery and also like structured non-image data. Also like at current prices commercial satellite imagery can cost $20 a square kilometer on centralized cloud computing platforms and for you know in context just the US land area would cost $180 million USD per year to store and the world land area would cost $3 billion. So with Filecoin you can drop these cost by orders of magnitude and that drives real value because if you think about like storing data right, if someone has a really high cost of storing data they need to like monetize that data and if they have to monetize that data that means that they have to charge some price or they can like let's just say if you want to break even on storage you're not even trying to make a profit on this. If you are able to you know drop the cost by orders of magnitude you're able to decrease the price significantly to your users or your customers of that data which means that a lot more people can now access that data and that this is where like Filecoin, the Filecoin network really shines for really big data sets because right now like really big data sets cost a lot of money to store those on you know AWS or GCP or you know whatever. So like a quick recap on this right, I think like Filecoin is great because it has all this capacity right we have as of May 22 which is about five months four months ago we had 17 exabytes of storage capacity and there's like hundreds if not you know exabytes of geospatial data that is available to store and like the combination of storage, computation and smart contracts is where like we're going to be driving the real value over time because like you know storage is, Filecoin is great, storage is a commodity but like as Juan said yesterday's computation and smart contracts is going to be where the real value is generated. So we need a lot of help building this so if you're interested in Atlas at all if you're a researcher, entrepreneur or engineer who's interested in using our products you know please contact us the URL or Twitter and if you're in Filecoin Slack the hashtag Atlas Slack channel please contact us there if you're a storage provider who wants to store geospatial data you know this could be a great use case for large storage and retrievals or if you're you know someone who's super passionate about geospatial data and wants to join the team and help us build you know this future that we're envisioning that please reach out we definitely need all the help that we can get. Cool, thank you and if you have time I can answer some questions. Yeah, a brief question. Have you thought about the go-to market for this so how are you thinking about attracting people that have data to store to your product like what is going to be kind of the public facing you know function at your... Yeah yeah great question so our first goal is to like prove that you know this works and we can do retrievals from APIs like relatively fast with satellite imagery so there is Landsat which is U.S. you know NASA and USGS and then there's European Space Agency which has satellites that have been flying since 2014 or something like that and once we prove that our goal is to build a community that people can then you know either vote on in some mechanism and decide what geospatial data sets they want to store on Atlas and so that that's like one path of our go-to-market strategy and the other path is to work with like current geospatial providers who are like in the Web 2 business and they might want like a new there's like a new distribution channel for customers get them on to Atlas platform and like kind of connect to their APIs directly without having them to store data on IPFS or Filecoin and get people using that using those products. Did I answer your question? Do you plan to have a governance token like Ocean Protocol does? Great question. We don't know. So before we get into stuff like how the organization of the data will be and the organization of the entity we're going to be focused on like more use cases and see and let the use cases drive whether we're going to you know we would use a token or we would you know maybe go through it you know maybe use Filecoin or completely non-token method. Also is this data also given or like served to oracles to get it on chain? Sorry, serve to what? Oracles. So I don't think we'll probably store the data on chain but I do think that we will end up integrating with other oracles if they want to get data for their use case outside of Atlas. Because you mentioned about like Metaverse projects or gaming projects which like react to certain like real-world geospatial data. I think you said that a few moments ago. Yeah, yeah. So if that game is particularly on chain so you would require that data like whatever you have in Atlas.storage to get it like on chain and then it kind of like react to a smart contract and like the NFT if you have a land based NFT it is like changing its maybe its appearance like in accordance with a real-world data. So for that purpose like I asked the question. You know it's a good question it's just that we're so early that it's like hard to know what like the use case will be right. So like that is a possible use case in the future but for us for now we're at more simpler use cases with like more simpler applications. So I'm trying to think like the function underneath the hood if you've got the I'm just wondering about the cold storage versus like caching and ready to rock files is the idea that you've got like the whole surface of the earth or the whole surface of the US and then like you're storing that and like oh everybody's asking for New York City and everybody's asking for this new construction neighborhood outside of Chicago and so we're going to cash those but the actual you know economies and cost savings that you're getting are for the cold storage part right. Is that how it's working in Filecoin? The cold storage part is where you're getting the cost savings and then you would still the tools are still kind of conventional Web 2 tools for the caching and serving of stuff. Yeah exactly so like that's exactly how we're thinking about it but also in like let's say non-critical business applications like they're able to like run these big processes or jobs that like they'll leave the computer on for like six hours later and they'll have it run so like being able to pull from cold storage is actually at the beginning an okay use case. So like we always think about when we think about like applications we always think about like retrieval times and like milliseconds or sub one second right but there are a lot of applications where there's a lot of analysis happening where you don't need sub one second and so like that would be one great application of this but also like we do plan on like having like using as you know caching layer to make the satellite images or the geospatial data that is being queried the most available through that for really fast retrievals. Nice. Yeah. Well first thanks for the presentation. I think it's a very useful product. It's definitely one that we need and I know that because I've been on the terms of integrating when we are transforming the data because a common use case is you have to hand data. Sometimes you actually have more than one hundred set you have for example four and you want to compute a new one for like for example for doing future extrapolations you need to apply operate operations on each bit that you have. So not only you consume a lot of data but you generate a lot of data and it's usually I mean the closer you can get to the edge to compute and generate that usually the better. How do we I mean do we have any thoughts about that? Like maybe Atlas could be integrated with FVM or some kind of compute solution. Did we have any thoughts about that? Yeah so I don't think we're going to decide like right now what like compute solution we're going to use but like we you know just in terms of like compute teams that like working are working in protocol labs right like having integrations with FVM and some you know like compute over a data team such as Bakiow is definitely on the roadmap because and this is a good point because the like the compute jobs are actually more valuable than the actual data itself like and mostly because like geospatial imagery is going to is a commodity or will be a commodity very quickly and so like for us at least in my opinion it's really key that we do build out these integrations and I don't think that it's just going to be like one compute platform and I'm hoping that they'll be integrating with multiple compute platforms for you know because a lot of these compute platforms have their own use cases that are like you know depending on what they want to achieve in terms of performance or security or whatever it may be are very different from each other. And second question, it's very useful to let's say the data sets that have the most valid add are actually post-processed data sets like as I said before you take five hand data sets and you compute a new variable of interest like one common for example is about climate analysis where you look at the past, you run the model to the past and you generate this synthetic data. Is it the scope of the project that for example we are able also to include those synthetic data sets or those value-added data sets beyond for example RAM data sets? Sorry I didn't understand your question. Like suppose that I'm a user, I've extracted data sets I have computed that and I did generate a new data set with the same granularity that has way more value because of that, because of the computation that's embedded. Is the platform going to make it easy for me as a Mito user to for example publish these data sets that others can use? Yes, so that is definitely on the roadmap and that's a technical challenge that we're going to have to solve because so say like you've done some computation and added more data or created more data on top of the data set that's already existing. I don't know as of right now how trivial it would be to get that data onto like an IPFS node or the Faqoi network without you running a node yourself which I don't expect anyone to really do. We kind of want to abstract that away. So that's definitely on the roadmap but that's like a very future far-looking thing that we're going to eventually get to.


Hello, my name is Taiwakanyemi. I'm the director of Afrolabs. Afrolabs is a Pan-African network of tech innovation hubs, and we create platforms to help tech hubs network and collaborate. I've been supporting the Young Innovators Competition here at the ITU World 2014. And my primary takeaway is that it's very important to create platforms to support young innovators. This competition has created opportunities for these young people to network and to collaborate and to learn from one another. And in as much as young people are very enthusiastic and they have a lot of energy, they do need support, they need funding, they need institutional support, they need mentorship, and I think the competition creates a fantastic platform to support them.


We finally made it, after what feels like an eternity. We got 17 comic book movies to phase two.   I first want to point out that I didn't cover every single comic book movie ever made. It's inconceivable for a one-man show such as this. I'd like to pour one out for the punishers out there and the dreads and the electros and the tank girls of the world. That I just didn't have the opportunity to talk about, because I didn't want to. Not because they're bad, because I'm lazy. Let's make sure that's very clear. Without any further ado, I'm gonna announce Movie Feud's fashion, the 17 winners. I'm glad I stumbled leading into this. Really makes for good TV watching. Let's go! I've already talked about all these movies. There is no need to regurgitate nonsense or beat a dead homeless man. Instead, I'm just gonna gloss over the winners and we're gonna move past this. It's time. Doctor Strange was a fun, albeit familiar Marvel movie, full of spectacle and snappy dialogue. It won with 63% of the votes, with V for Fendetta taking second at 26. Batman Returns is a fantastic stylized picture with one of my favorite Batman's to date, Michael Keaton. You voted him in with 53% of the votes over Superman 2 at 18.  It was a no-brainer that Deadpool would win, but I didn't make it easy. Having it go up against Kingsman, Kick Ass, and Scott Pilgrim made the choice tough. Deadpool still managed to get 51% from the viewers, which is impressive.   Granted, its competition was just as bad, but I thought at least Batman forever would win out the day. And I was wrong, as I often am. The Dark Knight easily trounced the other Nolan films, getting an overwhelming 83% of the votes. I don't think anyone should be surprised by that. 2005's Fantastic Four isn't a great film by any stretch. Thank you, subscribe. But it's easily the best of the Fox properties so far. 59% agreed with me. Captain America's Civil War gets an easy win with 76%. Ant-Man came in second with only 14, proof that a little Spider-Man goes a long way. And speaking of Spider-Man, what was I looking at over there? The Tobey Maguire sequel holds up remarkably well and easily trounced the other sequel flicks with 63%. Teenage Mutant Ninja Turtles 2 out of the shadows had some fun moments, but it wasn't enough to catapult it to the top spot. The original 1990 picture got 41% and the victory. Iron Man gets an easy win from the origin story line-ups at 74%. Captain America came up second with only 10. When I feuded the X-Men films, it was a pretty sure bet that either X2 or Days of Future Past would take the crown. Because they're both terrific pictures. But that's not what happened, is it, asshole? Future Evil Me, you're back. Wearing the same clothes as I am because no budget. We both know I never left. I just waited in the shadows with bated breath to tell you what I already predicted all along.   This changes nothing. Dark Knight is in the lineup. Nothing beats Dark Knight. Yeah, sure. In your timeline, maybe. But there's a storm coming at him. I hope you're on the right side. I'm gonna get the broom. I'll show myself out. I hope you're proud of yourselves. Over 1,300 votes made X-Men Origins Wolverine a reality as a winner. So we have this to look forward to now. The last four films to make the Phase 2 bracket our Man of Steel with 32%. Sorry, BVS fans, game over. Spider-Man 1, Superman Returns, and Jim Carrey's The Mask conclude the list. Now's where we really speed things up. This is me speeding things up. There are 17 movies. I'm holding up eight fingers. There are 17 movies in this bracket list. Only two of them are moving on for the final head-to-head. So choose wisely, Grasshopper. Because it's time to move on to greener pastures and then I can do other things on this channel. You know, like other movies I could talk about besides superhero films. Thanks for joining me on this long journey and let's make sure the proper champs make it to the final phase. Comment, vote, share my channel around with your friends, and remember this is more than just reviews. This is more than just going to win this tournament. Mark my words. It's the Donald Trump of superhero films. People don't think it could happen until it does. Oh, you'll see. Come on. Get out of here.


and I have a team of four, and the members are Srinath, Sandhya and Srinath. What we are trying to do is a concept regarding notifications. Notify it as a concept which is trying to ensure a schedule and easy life for people. What we are trying to do is we will notify everyone with whatever activities or which are necessary activities which anyone needs to do at very correct time of the day. Many of us will find ourselves in such kind of situations. We are just wondering that what works. I am just missing something. I needed to do something right now. But I can't remember what I was supposed to do. Or even if it is to get a number, so I have experienced someone's birthday. But I just don't remember whose birthday it is. Or even certain things can go unnoticed. Like I am stable, or I have a meeting, but things go unnoticed. We just can't call that out. So we are just trying to provide a solution to this. Back to a very handy solution which can either, for example, a Sony smart phone or even a mobile. So two kinds of APIs we are trying to use in this. One is notification, other is sensor. With notification we are trying to cover the major aspects of it. The notifications what we are trying to cover is portrait, personal and a few other things. In portrait what we are targeting is, like there can be meeting schedules. We can integrate outdoor meeting schedules. Also we can bring in a concept of software as a service. Which is not yet there and not in portrait. Means we can provide customized solutions to various smartphones. Like various corporate requirements like approvals are required. For recognition needs. For various approval side intermediate levels. And other services. So far those purposes also we can provide customized products to various corporate. And to ensure them that their flow is just on a click-off watch. You can get a notification that approver is in. Just click and do the purchase. Because I am going to go to the system and follow the process. Such kind of things also. For self-criticism we can integrate that kind of information. For day modifications this can be. These information we can integrate with the FTA. It is all that secret as well. Also the utility character is like mobile phones, smart phones. Easy to capture. What is the time associated with these bills. What type of money. So when it doesn't that I decide what model people do. That I think they have near the end date. These bills. So we can paste the dates of these bills. And at that time we can prompt them. With the prompting that it is a time you have to pay that bill. Please check if you have paid or not. Such kind of prompts we can provide. So these prompts. Especially the pros and cons. We can use sensors for this. Like if you are currently busy. I would just leave it unnoticed. I won't notice the bill. It will snooze off. So with the help of sensors what we can do. Is try to write a pattern. Like if we are using a smartwatch. Write a pattern. With which we can ensure that he is in an ideal state. Associated. In a very good position. Take action on that communication. Which we are counting on. Like for example. If we are starting a movie. A lot of that things is missing. So we might not pay attention to this organization. While it is completely added. I mean it might be a sleep or something. So we will try to write a pattern. In which we can identify that person. That person has it. I don't see that. So at that moment of day. We will coordinate the notifications. Related to the sensors. As per their priority. We can also plan to indicate. To indicate subside. Especially subside. For 4 meters. We can do GPS tracking system. But if I am running for 2 meters. Then it is very difficult. To do both the tasks simultaneously. So we can provide this facility in smartwatch itself. We are just notifying where to take right. Where to take left. While you need to just take a watch. And the thing is then. Also the traffic. Traffic information and everything. We may also use 4 systems. So for the movement. So we are just. We are not implementing the complete logic. We are. Incorporated a part of it. That is sensitive. Ok guys. Any questions? Thank you. Next we have.