So, I'm going to talk about as I've done the last few years about using these backgrounding budgets that we kind of create here at NDSU and under some different scenarios for both steers and heifers across North Dakota based on current prices of both cattle and production costs and everything else that we're dealing with this time of year as we're trying to make these backgrounding decisions across the state. And so, initially I want to do a little bit of a defining of some terms and some boundaries on what we're considering here. And when I'm talking about, if I mentioned weaned calves just so we're all on the same page, I know everybody knows what weaned calves are, but typically 500 to 600 weight, maybe up to 650 pounds. And this is typically the thing to keep in mind here also, it's the largest price difference between heifers and steers. Okay, so in other words, the price per hundred weight, typically the lighter weight the calves are, the greater the differences between heifer and steer prices per hundred weight. Then, you know, backgrounded or heavier weight calves is going to be in the 750 sometimes 700 to 900 pound category. Often this price gap closes between heifers and steers per hundred weight from 15 to 20 bucks as much as 25 bucks ahead in the lighter weights down to about $5 per hundred weight. And so, that's when we're talking about closing that price slide between heifers and steers and often why backgrounding heifers as we'll see here in a bit is so beneficial is for this reason right here that this price slide closes. And then we have our finished cattle category. I'm pushing those animals up to 1350 pounds. And in this category, the price gap between them, the slide difference, it mostly disappears in this category because they're essentially finished. So this is what I and now when we're talking about lighter weight calves versus heavy weight calves. Okay, we're all aware that the lighter the weight, the higher value they have per per hundred weight typically. But overall the weight the overall values lower because you know what a 900 pound calf, it just weighs more 50, you know, 50% more than a 600 pound calf so per hundred weight it may be a little bit lower. But it overall value it tends to be higher so this is just how the price slide as a you know 2018 had had behaved essentially showing the price per hundred weight as the weight of the calves tends to tends to go up. Alright, so these next ones I want to talk about are concepts that Tim had hit on and it has to do with the price of corn. And these are a little bit dated but they come from Kansas State University and they illustrated pretty nicely on a few concepts of backgrounding that we deal with or even finishing out calves and that is that as the price of corn goes up. So we can use corn just in a sense as the price of feed. Okay, so in this case we're just using corn but the price of feed as well, which tends to get pulled up with corn often. And when you look the highest price corn $3.52 per bushel when this study was done. And what you notice is that line is flatter. So that's the one here with the blue diamonds here that's $3.52. So the price difference per hundred weight is the lowest when the price of feed is the highest. Okay, so why is that true? Well, because it costs quite a bit, it costs more to put weight on per pound. Okay, so it drives down the price of feeder calves, lighter weight or weaned calves and pulls up the price of 800 weight, 900 weight calves because it costs more to get the weight on. And feed lots and finishers are saying, okay, well, there's less risk now of feed prices being volatile or whatever because this is a heavier weight animal and I'm willing to pay more for it. So you get this relationship where it drives down the price of feeder cattle a little bit drives up the price of heavier weight calves and you get a flatter line. When corn prices are cheap, relatively, in this case, it was, you know, way, way low at $1.68 a bushel, but the relationship is the same. When feed prices are low, the price of lightweight calves goes up because there's a lot of money to be made with cheap feed in order to pack the pounds on these lighter weight calves. And then the relative price of heavier weight calves goes down. That doesn't mean all the heavier weight calf prices in total go down. It just means the relative price of feeder calves versus heavier weight calves. It moves that line this way. Okay, so it could be the case that all cattle prices go up. It's just that feeder cattle prices are lighter weight calf prices go up faster than the heavier weights when when feed prices are low. So that's that sort of inverse relationship. And Tim talks about that all the time with respect to corn prices and cattle prices. And then finally, and this one can be a bit confusing if you haven't seen it before. And this has to do with what fed cattle prices do on the on the relationship of the price spread. And what it essentially says is the higher that fed cattle prices are, the bigger the price gap is between lighter weight calves and heavier weight calves. And that's because the risk is is lessened. Okay, if I got high fed cattle prices. I want to as cheaply as I can pack the pounds on to make as much money as possible so I'm willing to pay a bit of a premium for lighter weight calves. And I'm not so worried about the cost of the feed as much. And so I'm not going to pay a premium for the heavier weight calves. And then vice versa, if the fed cattle prices are low, then that brings up the relative value not the overall value but the relative value of heavier weight calves, because there's there's there's less risk. The price is low but they're heavier so there's less risk I'll pay a little bit more for them which which kind of covers me if it takes a turn because perhaps the margins are a bit thinner. All right. So, in a nutshell that's that's that's how a lot of that works and then we look at some seasonality. That's going to goes on with this too. And that is US cattle prices by month and this is only showing three years and it's not so important to focus in on the price in any given year but so much that we tend to see that spring cattle prices. Okay, tend to be higher than than fall and that's for obvious reasons. Most most areas, especially in the plains northern plains they they have in the fall so you're going to have more animals hitting the market, but you know feeders need new cattle coming in at you know all the time so they may have to pay a bit of a premium to get them. And, and there's other reasons but but for the most part, we can see that those those spring calf prices tend to be a bit higher. And that's another way that you know backgrounded cattle can can can actually pay. So, moving into the scenarios. Good news this year. The feed prices are lower than they had been last year. I'm just showing this slide real quick to shoot use and show some of the assumptions. The biggest ones yardage in our budgets, it's 35 cents a day I crank that up to 45 just just due to some energy costs and some other factors. Interest is much higher than last year's we're using eight and a quarter but I've seen some operating node interest rates as high as nine so I may be a little bit too low on those, but these feed costs have have come down compared to a year ago. And here's our six scenarios that we're going to look at here, a low rate of gain steer scenario from 500 weight to 800 weight. The cost to gain on that was $3 per day per head per day. 2.8 pounds so a moderate ration here moving from 575 weight to 855 weight and those cost $1 32 a day. And then a finished steer scenario 3.6 pounds per day ration pretty aggressive going from 575 to 1375. And that cost per day is a buck eight. And then our heifer scenarios. So a lighter weight heifer scenario at 1.7 pounds. Okay, so in this one we're going from 450 to set almost 750 little over feed costs on that's a little under a buck a day 98 cents a day. A little bit heavier weight heifer same same rate of gain but a little bit heavier to start off and a little bit heavier. When we sell that feed cost $7. All right, and then 2.8 pounds so much more aggressive average daily gain 525 to 805 and the feed cost on that obviously is going to be higher because it's a more aggressive ration at $1 28 per day per head. So here's just the comparison between the two I apologize on my last scenario I had $1 7 it's actually a dollar eight like you see here in the corner not a big deal but makes about a dollar plus difference so it's not a huge deal but I just wanted to I didn't get it changed on the last slide but the dollar eight is correct. So last year's feed prices you can see the ones in red or last year's per head per day costs with the exact same scenarios this year quite a bit cheaper again because those feed costs this year. Corn prices meal prices silage all that stuff a lot cheaper this year than it was a year ago. So obviously that's going to that helps out a good bit. All right so we start with the steer scenarios and this is the prices I pulled and they're pretty pretty much the same as Tim's there. I averaged the prices for for instance for your 550 weights or your 500 weight animals and then I used the projected price around that 230 bucks for the for the sales price which is pretty close to exactly what Tim had had just mentioned. And again you know the market fluctuates when you got record high prices you got record high volatility so depending on the week that you view this could be off quite a bit could be a little low could be a little high just depends. And we'll talk about obviously the intent talked about the risk management tools that are available to avoid some of that. And then for live cattle prices I use the futures for finished cattle for that one finishing scenario and I have $170 per per hundred weight for finished cattle on average for summer of 24 which is when our finished scenario would end in this particular presentation. So scenario one 500 to 800 weight 1.7 pounds per day. Here's the ration grass and I thank Carl for for helping put these rations together and the cost big part of that obviously silage DDGs salt comes out to $1 three per day. And then so using our NDSU budgets or spreadsheet I do some modifications to it just for this presentation but you can see that scenario up here sets projected selling price $230 and this and this is real important to do so make sure you do this is when you bring the animal into your backgrounding operation make sure they're priced you know accordingly obviously to what you would have been able to get if you to take them to to the sale barn on you know around this time a year. In this case I've got it at 281 bucks per hundred weight for these for a for a 500 weight steer projected selling price of 800 pound animal $230.  So all that to say that we essentially break even in this scenario and this has been true for the years that I've been putting this together it's on a. A limited ration or a lower ration for steers it is really tough to come up with or arrive at a number that is much above break even the biggest reason is they're in the yard for 176 days to accomplish this and you got this yardage fee hanging out there 45 cents per day you know that's costing you plus plus interest obviously is adding up and the only way that this really works is if you're able to really get these feed costs down or your yardage fees are just substantially lower than this somehow or the market. Shoots up and essentially you're speculating on the market taking a turn but all things equal the low ration steer. Scenario rarely is above break even it's usually at break even and and the and often that's because you know steer prices for these 500 weight tends to be pretty high and that's $281. All right here's our second scenario bit more aggressive 2.8 pounds per day obviously that's going to cost more to accomplish so we're up to $132 per $132 a dollar 32 excuse me per head per day. And so this this ration changes a bit you're putting in some corn some DDGs grass legume hay etc. Now this one is obviously a much more profitable scenario more profitable than the lower 1.7 pound per day mainly because you're you're only in the yard 100 days instead of 176 so yardage isn't eating away at it. And in this case our return is about $57 per head and and really not not a whole lot of difference in there it is it does cost more per day obviously but it's the same yardage. The same interest rate but you'll notice the interest expenses lower because they're not in there you're not financing the cost of production for his long and that interest adds up. And as a result we wind up turning you know a 50 $57 per head profit on the steers and all we did was was increase the feed to him and try to try to put on about 2.8 pounds and it's the same essential prices $281 beginning value. And then coming out at 230 $230 per per 100 weight on that scenario. Then our final steer scenario in this case is our finished finished steer scenario 575 to a 1375 pound animal at 3.8 pounds per day. Again obviously that's going to be a lot more costly to put that much weight on that fast more pounds of feed going in to pull that off and so we wind up with a with a finished finished steer. And I'll go straight to the budget on this. Here's that projected selling price and this is based on the summer futures for for fed fed cattle 175 bucks beginning value on this a bit lower because it's a heavier weight cap coming in at $271 per 100 weight is our feed cost. And the finished year expected return is $127 and 28 cents per head and 57 cents per day profit I put those in there just so you know how much you're essentially putting on or gaining doing what doing what's being done. But with this scenario to keep in mind and I'll talk about this toward the end to I mean that's a long time 222 days as a long time for a lot of stuff to happen in the cattle markets. So if somebody was looking at taking something like this on putting together some kind of risk protection program LRP or what have you is really important from the standpoint of and I'm going to show a scenario at the end that if this if this 175 here because the 271 is locked in I mean once you bring the calf into your into your lot that price is paid. Okay. The feed costs and fluctuate some interest can fluctuate as well but it's probably not going down anytime soon but if I manipulate this projected selling price and move it downwards. Not even a lot 1015% this this turns really red really fast. And so 222 days is an awful long time to be be hanging out there hoping that that things don't take a turn and it's like Tim said you don't have to buy. The highest priced policy out there for you just got to figure out what your break even price is and then put a floor in so that at the very least, you know, eight nine months from now, we're not losing our shirt. All right to the half or feeding scenarios. All right. And here's the prices. I pulled them somewhat recently, you know, pretty much following tracking along with exactly what Tim quoted I'm using averages because again, depending on the day you check, could be off by 567 bucks 100 weight limit up or limit down in any given day. So this is more for planning purposes but but you got to know that when you take one calf into your backgrounding operation whatever the price is that's, you know, that's what it is that's what you got to jot down. So our first scenario, a low average daily gain 1.7 pounds a day and we're starting with a pretty lightweight heifer 450 pounds and taking her up to 756 and just under a buck per day to pull that off is what we're projecting based on the current feed prices 98 cents a day. That takes about 180 days to accomplish and look almost almost $90 ahead 49 and a half cents per day.  And this is for a 450 weight heifer so I mean if it was a lighter weight steer that'd be quite a bit higher than this if you're looking at a comparison when I was using 281 to bring the steers in at five five and a quarter. And then the projected sales price that if you just look at the if you just look at the cash markets how much that gap close this is what I was talking about before. And this is where we get some of these gains that and this isn't the as profitable of the most profitable scenario but even at a pretty modest rate of gain we're looking at almost $90 per head backgrounding these these lightweight heifers even on a on a moderate ration. Pulling in the the 1.7 pound per day heifers from 550 to 850 so we're starting with a larger a larger calf and and selling a larger calf that's going to that's going to cost more per day even though our average daily gain is a little bit lower. And it's fairly similar to the last scenario, essentially, whether you start with a 450 weight or a 550 weight if you feed out to 758 50 you're looking at 85 or so dollars per head in both of those scenarios. So, again, a lot of that coming from closing that price slide gap that projected sales price, you know dropped a little because I went from 800 a 50, but the beginning value I mean is quite a bit lower. If you'll recall steers at 550 were closer to 280 bucks. All right, so, you know, 40 $40 $40 drop for heifers coming into your operation at 550 versus steers and that a big reason for the explanation of this 80 $84 per day, despite 176 days on feet. Okay, so I just want to make that clear that's that's why that's happening. That's why you see it and and why, you know, backgrounding heifers in North Dakota has typically been a money making endeavor, especially when you, you know, use a lot of the tools that are available. And then our final scenario in this is 525 to 805 but we're putting trying to put on weight quite a bit faster going from 1.7 to 2.8. Again, that's going to cost more $1 28 per day to put that put weight on that fast and then obviously we're going to have to include some more in the ration to do it. But what that does is it drops the days on feed from, you know, 176 to 100, which is, you know, what you saw in the last scenario. Okay, projected selling price, the same beginning value coming in it's still a 525 or 550 waiter so the same. Okay, and what do we notice a really strong profit on this one almost $172 per head. If you if you go the aggressive more aggressive ration route or $1.72 per head per day. And in this case, the value of putting on the weight is adding up as well as the shorter term in the lot only 27 and a half bucks in interest. The lot costs aren't adding up as fast you're down to $45 because it's 45 cents over 100 days. And we've closed the price slide gap so this is sort of a all the benefits of backgrounding, especially with respect to heifers are all coming together in this in this particular scenario with a with a more aggressive ration. So shorter days in the lot, closing the price light gap, etc, etc. It's just this is this. I've been doing this now. Three or four years and every, every time that I do it whether it's a leaner year or a stronger year. This tends to be the most profitable scenario almost every single time and once there's something kind of strange going on with fed cattle. You know, live cattle prices or something like that, then sometimes finishing can be the can be the ticket as well. So here it is in summary all six of our scenarios and I just wanted to put this in there because as I go through that I'm going through spreadsheets and I'm going through the rations and everything and hear how you can compare it. The low rate of gain on steers from 500 to 800. It's pretty much a break even proposition. More aggressive ration 525 to 805. Yep, there's money to be made there, you know $57 ahead.  You might as well do it and go ahead and hopefully make around 50 60 bucks per head there. Finishing is profitable as well. We've got strong live cattle prices fed cattle prices. So you could be looking at making as much as $127 $130 ahead. The heifers are the ticket right now 90 $85 and even compared to our finished steer scenario. Right now that that aggressive heifer ration 2.8 pounds with these feed prices and these current cattle prices that one's that one's the highest overall profit loss per head of all the scenarios that I run by by a pretty wide margin. Again, it's because of that, you know, perfect storm of things coming together that's in favor of heifer backgrounding making that happen. So as I said before about putting in a floor, especially when it comes to the longer term decisions that are being made, I just want to use an example here. So if I take the 550 to 850 weight heifer scenario, which is the 1.7 pound per day. Okay. If I increase feed costs 20% over the projection. So I go from $1 8 per day to $1 30 per day. So let's say I totally with on my feed cost calculations. They're actually 20% higher, maybe even 30% higher. My profit drops from $84 per head to about $45 per head. Okay. So that's not great, but it's not the end of the world. I'm still making a profit. I'm still covering overhead. I'm still covering everything else and I'm actually actually making a profit in the end. On the flip side, if my 850 weight heifer projection declines from two, let's just say 10%. That's not a massive swing. Okay, 10% in that amount of time, 176 days or so from $216 to $194. I go from an $84 profit to a $92 loss that fast. So I can increase feed costs, my projected feed costs 10%, 20%, 30% and still have this remaining above zero, you know, or at least breaking even or whatever. What I cannot have with these, the price of these cash coming in, I cannot have them going down 10% or 20%. Especially at these prices, that would be an absolute disaster. That's a disaster. And that's why we're really emphasizing putting in a floor at these prices. It's not that we expect cattle prices to decline. The expectation is that they're going to continue to go up. It's just that the cost of them declining is so severe at these high prices. It's nice to put in a floor. And it's like Tim said, we hope we never use it. Our goal would be to put in, you know, a break even or if you want to maybe a slightly above break even and we never use the thing, right? That cattle prices, calf prices continue to go up this spring. And it just gets put into our budget as a cost of doing business. That's the ideal scenario. But if the worst case scenario happens and they do fall 10%, 20%, this at least makes sure that we don't absolutely lose our shirt doing something like this. And we're good to go the next year. So that's a lot of the reason that we're really pushing this risk protection tool is it's a way to ensure that we don't wind up in a scenario where the loss is just so severe that it puts us in a bind. That's the last thing we're after.


So, there's the agenda, testing and release updates, I will start on that. We, well my focus has been on B012. The last thing really in that, in the queue there is getting the upgraded BLS, including that draft 7 merged into the spec for the new test vectors. I'll be looking at that today. We're trying to get this out the next couple of days. I know it's a little late, but we've been the blocker. There's been a number of things going on, but getting this BLS is the last thing in there. Other than that, there are a number of networking updates and modifications that came out of that networking call. Thank you for everyone for the input and review. And also some increased testing is going to come out. There were some corner cases, especially around handling multiple different operations in blocks that could result in some corner cases with respect to modifying state in the middle of state transitions. So, might catch some new bugs on your end. Cool, so that is eminent. Any other updates on this? Cool. Let's run right into client updates. First we'll have techie. Sorry, Danny. Just thought I'd give you a big plus update if that's all right. Thanks, Heidi, please. It's been a little while. No, no worries. So we actually pushed a blog post last week that details all the stuff that we've been busy with. I'll just push it now on the chat before I forget. And yeah, it's been pretty good. We've made a lot of progress on the structural fuzzing. So we've implemented and derived the arbitrary trait on our two types. So we can now provide well-formed instances of custom types from raw byte buffers, so it's a huge improvement in our fuzzing coverage. So this has already allowed us to identify an integer underflow in an upstream dependency, the snappy crack that we use. So the maintainer confirmed the bug. We pushed the PR, but it's yet to be merged. Over the last few weeks, we've been working with Techu and Nimbus. It's been really great working with these guys. We've raised a bunch of issues. Some of them could have been exploited off the wire. Others are more hardening opportunities. I guess the main ones, there was an infinite loop in Techu when SSZ decoding bit lists without an end of list marker. And on Nimbus, there was a seg fault due to stack overflowing with the process final updates function if I recall correctly. We've updated the trophies list of big and fuzz. We're now up to 18 unique bugs, which is pretty cool. Made some good progress with the goal and integration. So just a quick reminder for everyone. We've been experiencing a lot of issues integrating both serenity and prism. And we actually lined up a call with prism in a few hours to see how we can better collaborate on this one and move forward. Yeah, if you go through the blog post, we're proposing a new architecture for big and fuzz. So it's all outlined in the blog post. Please feel free to give us feedback. Super keen to hear from everyone on this. Basically, we're going to move away from C++ and we implement the AFI bindings in Rust. Don't necessarily want to go into details here, but we're breaking down big and fuzz into three separate tools. Each two fuzz, which will be coverage guided fuzzing, leveraging the structural fuzzing that we've been working on to generate interesting samples. Each two diff that will allow us to replay samples, those samples across all the implementations using the nice utilities that you guys have been building. So PCLI, LCLI, CCLI, and so on. And finally, the AFI bindings. That's the core differential fuzzing part. So that's beacon fuzz V2. There's a nice diagram at the bottom of the blog post if you're interested. Yeah, so please check it out. Super keen to get some feedback from everyone. We'll also be pushing Docker images so that the community can help find bugs. I think it's a lot of people asking how they can contribute to E2. And that might be an interesting experiment. Kudos to Justin Drake for the suggestion. We should be wrapping this up next week. And I guess finally, we've been starting playing with Lodestar. I think we caught a few type errors on the SSZ package, but we're not really asked for the experts. So I might reach out to Cayman next week to discuss this further. Because I guess most likely these are probably caught by the calling packages. And yeah, that's pretty much it. Awesome. Thanks, Maddie. Any questions for Maddie? Yes. There was a discussion three weeks ago about some beacon states that shouldn't be trusted. So it involves everyone. But apparently, well, last time I looked, it was actually states that couldn't happen if we were in an actual functioning client. So what's the latest news on that? Was it been first modified? Yes, so that's the reason why we're splitting things up so that we can avoid this confusion. You probably saw an issue or a PR from Danny. I don't think it ended up being merged to the specs repo. But we're probably going to have to sync off beacon states at some point. So in my opinion, the whole concept of beacon states being trusted inputs, we might not rely on this assumption for too long. In fact, we've found a couple of overflows on Lighthouse when dealing with invalid beacon states, per se. So the spec has actually been clarified, right? I think last week or two weeks ago. Now, if you overflow in a state transition, it's clear that the state transition is invalid, which is good to see. But yes, we've been so the structural fuzzing help us mutate the beacon states better so that we can actually not only have valid SSZ containers, valid beacon state SSZ containers, but also valid beacon states as per the spec. So yeah, it's one of the reasons why we split up the tool set that we have in three separate tools. And yeah, those conversations were super interesting in my opinions. So it raised a lot of interesting thoughts. And yeah, thanks everyone for being involved. And I guess one of the issues that we had as well is hitting the utilities and CLI, for example, was hitting directly the state transition and bypassing all the potential checks that are performed at the networking layer. So we've now considered that and won't be raising such issues if they arise in the future. Hopefully that makes sense. Right, and I guess to clarify, in the syncing, there's probably two ways to sync a network safely once the networks run for more than say three weeks. One is to have a checkpoint for a given epoch and block sync from Genesis and then make sure that the checkpoint you reach is that checkpoint route that you had. That wouldn't involve having to get an untrusted state from somewhere. But if you instead, there's a much better UX around actually just starting from a state. If you have this checkpoint that you want, you wanna actually just start from that state. So at that point, you're actually inputting a state and there's an avenue to input a state into your system. Generally you've got this from say a trusted source, but there's a small likelihood that you've gotten from a various trusted source and you have some sort of like tainted state that you're inputting into your system. And so I think that's the nuance there. Obviously you don't have to necessarily get it from the PTP network like I had in that PR, but the idea of getting a state from somewhere and putting it into your system is certainly a flow that I think we're gonna all want because block sync from Genesis is not, it's not gonna be the best UX once we get a few months into this thing. Yep, it's fine. Cool, any follow up on that or other questions from Eddie? Cool, thank you. Glad to see all the progress there and the trophies on that on your README, very exciting. Okay, other testing items? Let's discuss, let's not separate. Yeah, we're gonna do client updates and then we'll go straight into test nets. Great, so let's get started with Techu. Perfect, this is Jim from Techu. So in the past couple of weeks, we added snappy compression over gossip and RPC. We also added support for ping and get metadata. Now we're randomly subscribing to persistent subnets. We majorly reduced our memory usage while syncing. And lastly, we now have built-in support for syncing Schlesi, that's it. Cool, what's that memory usage look like on, say, Schlesi? Do you know? I think it's now averaging around like 900 megabytes, so not 100% sure that it's been a while since that. Yeah, okay, cool, thanks. Let's start. Hey, so in the past few weeks, we're finally starting to be able to sync. As of today, we're syncing kind of stably on Schlesi. Haven't yet reached the head, but we've synced a few thousand epochs, worked through different gossip subbugs and syncing bugs and what have you. Still not really stable, but hopefully the next few weeks we'll kind of nail down some of that node level stability. It still looks like our DSP5 isn't running. So we are stuck with our bootstrap peers and it's not really sustainable. So different things like that we're still working through. Got it, thanks, Kamen. Nimbus, hi. So like Lordstar, we had multiple sync fixes in the past three weeks, in particular Snappy, which had the compatibility issue with Lighthouses. We now have a single make Schlesi target to connect to Schlesi. Sync is working slowly but steadily, let's say. And right now the main focus for Schlesi and Sync is working on performance in particular on Windows. Besides that, we have worked a lot on multiple memory leaks that were preventing our testnet to last for a week. Somewhere coming from the P2P, some from our block caching system and we added several memory tracking tools. And also since we are entering like, we are focusing on bug fixing, we have now tools to debug on discovery, to debug LEP2P topics and message received. Got it, thanks. And this probably goes without being said, but once we have fast state transitions, it seems like the next big culprit is memory usage. I know everyone's kind of been attacking this from different angles, but be sure not going to each other's doors. I know there's a lot of pretty solid strategies to go off of now, so you don't have to deal with this alone. Trinity. Everyone, not a huge update this week. Mainly we've been continuing our port to the TRIO-ASync framework. We have updates to the latest Speaking Node and Validator APIs, which is good to get into place. We've also made some progress on bringing more full-time contributors to the project, which should just generally help out with everything we have going on. Cool. Thank you, Alex. Another mind. Just minor updates in the last week, so we've updated a bit of the open app specification that they tested synchronizations but had some problems with the Mothra networking. Not really much happening in the last two weeks. Got it. Thank you. Prism. Hey guys, Terrence here. So over the last few weeks, we've been working on just Topaz maintenance. We're fixing UX bugs and then users' feedback as they get reported in the Topaz testnet. Also, fixing network bugs as they get reported in the Multi-Crime Testnet. So nothing really is substantive from that regards, just typical bug fixes. We are also fully aligned to SPAC version 11.2 and working into aligning into version 012 right now. And later has been doing great work on optimizing initial syncing. So this latest experiment resulted in 100 blocks per second during initial syncing. And this is without attestation signature verification. So we still need to optimize signature verification for initial syncing. Basically what the Lighthouse is doing. I've been in shape in doing great work on slashing detection. So Eric Hunter reported to us that one of his validator was earning more money than the rest. It turns out his validator has included a slashing object in the block. So that means that our backhand slashing service is working. That means that PubSub Slashing Network is working. So it's pretty exciting. Let's see, we've been running client production readiness tests in particular stress tests and then the in-activity penalty test. So we updated a few internal matrix to better super monitoring. We're running 16,000 validators one section and then $20 and then no issue on that. So we're starting the in-activity penalty test. We're waiting a few days to see the outcome of that. So yeah, we'll continue to work stress on it. And yeah, that's it. Nice. Are you all running on short slot times on the stress tests? Yeah, yeah, yeah. We are doing one second right now. Oh, nice. Do you know if you're seeing any degree of forking more than, say, on a normal 12-second slot time? Not necessarily, but we do see about 85% participation versus 99% participation. And that's just due to timeout. Timeout from which angle? Sorry. The RPC angle test, then we have about 2,000 validators on one vision node still does some RPC requests within a second. Gotcha. Interesting. Okay, cool. Glad that you all are pushing on those. Thanks, Terence. Lighthouse. That'll be me again. So Paul's been busy implementing hierarchical key derivation for BLS. So we're ensuring interoperability with ETHDO by Jim McDee that's being used by Prism. So he's implemented the key derivation generation, the BLS key store and the BLS wallet. Quad excited to announce that we're kicking off the first external security review with 12 bits on Monday. So we've wrapped up the slashing protection, spent a lot of time handling concurrency and to me city guarantees for database transactions. And we've also changed directory structure to better suit audits in the future. We've been running several 16K validator test nets over the last couple of weeks. We've seen two panics, one from an upstream package or one from our code, both have been fixed. You were asking about memory usage, Danny. We've seen some great improvements there. So we're looking at 300 megabytes of RAM for a node running a big node and a validator client with two K validators, which is quite cool. We've been working to fix some consensus bugs as well that have been identified by Justin Drake. So we've removed almost all parallelization from our state transition code. It's not really needed anymore since we can do batch BLS verification now. We finished implementing full gossip self verification logic, caused a bunch of issues with our tests harnesses. So really looking forward to seeing how it runs on Schlessee. Talking about Schlessee, we've defaulted our Lighthouse to run on the Schlessee testnet by default. So the spec and the Genesis state are now backed into our binary. I guess other missed updates. We moved our disk v5 implementation into standalone Sigma Prime repo and we've been upgrading to stable futures, the entire code base, bumping all the Lighthouse dependencies to the latest versions. And yeah, so we're really almost done with this massive upgrade that age ravine has been busy with and we're hoping that Trail of Fits can tackle Lighthouse with these incorporated. And yeah, we've just been working on the RPC error handling as well and it's been integrated into our reputation system. Cool. Thank you. And the 300 megabytes, that's a 16 K testnet? Correct. Cool. Very good. Thank you. Thank you, thank you. I believe that was all. Let's move on to testnets. We can start with Afri. Yeah, sure. Thank you. I can talk a little bit about multi-client testnets. A lot of stuff happened the last three weeks since our last call. I did multiple attempts to create a multi-client testnet that unfortunately failed, mainly due to network fragmentations, but also due to big nodes disconnecting and rejecting other peers, each other for rate limiting and other reasons. Then we revealed the problem with the kind of edge case that these two timestamp can be less than minimum genesis time. So we had different genesis times calculated in the prison and Lighthouse. However, our client teams are super responsive and I want to emphasize that I really appreciate it. Apparently we managed to launch a multi-client testnet two weeks ago. We talked about it. It's called Schlesi that launched initially with two Lighthouse validators at genesis and two prison validators. In the beginning, the finality was horrible because some clients kept crashing and my validator knows I had a hard time to keep them updated and alive. But then again, as I said, client teams are super helpful and responsive and we're doing an amazing job in fixing bugs. And eventually now Schlesi has a almost perfect finality and liveliness for more than a week after fixing the most important bugs. And I think everyone is surprised how stable this network is running. After a couple of days, Tico joined the testnet since they managed to successfully connect and sync the network first. But now I also know they run validators on Schlesi. So we have three full clients on Schlesi right now. I know that the Nimbus Beacon Chain client is also synchronizing. I still personally experience networking and sync issues but I know the team is very close to fixing it. I didn't manage to get to the chainhead yet but I know it synchronizes and connects. But maybe Protro has more detail because he mentioned earlier today that he managed to do a full sync on Schlesi. I also know that loads are managed to connect and synchronize at least some epochs on Schlesi but I didn't test that out yet. So I'm aware of five clients right now at least was partial, some was full support for Schlesi Testnet. I would be interested in learning more about where Trinity and the Cortex client are regarding interoperability or multi-client testnet efforts. And given the current stability of the Schlesi Testnet I would start working on outlining a coordinated multi-client testnet soon. Something that's based on the main aspect ideally on targeting the version O.12 of the specification with 16K Genesis validators and maybe we can figure out a way to launch the testnet with three different clients at Genesis. So it would be amazing, but that's all up for discussion and also I had the idea maybe if we do a more coordinated and more official multi-client testnet maybe we can also do a dry run test of a deposit contract ceremony on the testnet but that's all to be discussed and I would carefully target maybe a June 2020 launch date but I'm still not very certain about how long it takes to implement the version O.12 of the ESTool spec in all clients but I'm open for discussion here but I think we can start talking about this now. That's it from my side. Yeah, thank you Proto, do you have anything to fill in? All right, so I've been trying and experimenting with Loadstar and Nimbus. There are clients that are relatively new to the special testnet. Loadstar has made some great progress in sustainability and they've been thinking many epochs, like a thousand or so, it's about 10% of the special testnet I think. So stability is getting there and then Nimbus is very close to the head of the chain, about 100 blocks distance. This is where the sync mode changes and I think there's some stability issues if this special sync mode for the last few blocks but it's working and I've implemented support for them to show up on EVE stats. So everyone can follow the testnet work. Cool, thank you. Yeah, I'll put a diff up of what is going into B012 and outline those items so we can get a better estimate on how long it's gonna take. I think the, sorry, someone just messaged me. I think the, there are a number of networking changes. Most of these are very minor. I think the big thing is gonna be the support for BLS. I know that we just got it on Harumi and I'm not sure the state of the Java implementation and the Malacra implementation. Does anybody, anybody looked into those yet? Yeah, we're good. We're pretty much ready. Cux just pushed the latest changes so we should be 0.12 compliant in terms of BLS already. Great. Yeah, planning to update the Java implementation this weekend. I spent too much time messing around with Slacy this week but should be lessing. Awesome. And I know Python is also updated and we will have those test vectors output. So I think a like coordinated start in June is certainly, right at the beginning of June is like for some sort of larger coordinated start will make a lot of sense. And I think we'll even be able to do some smaller test runs in the weeks before but we'll, I guess that'll be more on the client end to digest how much this P012 is gonna take. Cool. Other conversation on test nets, questions, comments, thoughts moving into research updates who wants to get us started? If nobody else will enters. Great. I could go from the E-wasn't perspective. Yes, please. Yeah, we have quite a bit to report because we haven't been reporting this frequently on these calls last, I believe, it was a few months ago. So a week ago we have released E1x64 the first variant of it. It's a write up on E-research but we also have a repo under the E-wasn't org on GitHub which has a much longer spec as well as it has examples written in solidity. Both of these are linked in the write up. So this first variant uses receipts which are generated on the sending shard and need to be submitted on the receiving shard. And the simple examples we have regarding this are tokens, two kinds of tokens. One of them is rep tokens. And with that example, it is possible to accomplish having dye, for example, on all the different shards. Now on the next steps, we are looking into new variants and it's not entirely clear which we're gonna do next but we have two ideas on the plate. One is to look more into yanking and there have been different similar proposals regarding yanking as well as by writing the variant one. If you look closely at the specification in one of the appendices, there is something called rich transactions and we also use that to devise yet another version of yanking and we only realize it retrospectively that it is kind of yanking. So anyway, I think we're gonna either look into yanking next or something based on the eat transfer objects which I believe was mentioned by Casey as part of some phase two ideas earlier on. At this point, I also want to emphasize one of the main reasons for this Ephone X64 was not to move phase two into EVM but rather to have a much smaller scale to experiment with these kinds of designs as well as to engage current DAP developers and give them some kind of a and understanding what sharding could look like and that's why we have those solidity examples and we really want to get feedback from those DAP developers to guide us which design is something which could be useful to them. But eventually we do expect that the more useful designs would mean much larger changes in the EVM where it may not make sense anymore to keep EVM because at least historically, the E1 community has been really reluctant to accept a radical EVM changes and if you would do radical EVM changes, then you already lose the benefit of the access to EVM tooling so you may as well just switch to a different engine such as Wazem and then now maybe just switching over to some updates on the benchmarking work we have been doing. So the benchmarking work we do, I guess this is something we always mention and I think a lot of people just think the Wazem team is working on benchmarking but it's more like an on and off effort and in the past few months, we have been looking at some new engines which seem to be performing, one of them especially, Wazem 3 is performing much better than any of the other engines but it seems to be a bit more complicated than the other interpreters and we have found some edge cases where metering could be challenging on this engine. Also we have looked at another E was incompatible, Wazem engine called SSVM but it doesn't really bring any speed benefits over Revit which was our main engine so far. And I also mentioned FISI a few months ago, probably in February, which is an interpreter written by the Wazem team and I'm happy to report that just today we managed to release the 01, the first version of it which passes a lot of the official tests but it doesn't implement floating points and the reason for this release is because next week or the week after we plan to release 0.2 which has optimizations and we just wanted this first to have like a baseline against the optimizations. And sorry for taking so long but it's just a lot of stuff which happened and now coming into maybe a really interesting part. So as part of the benchmarking we have been looking at all the different, well basically all the different pre-compiles which exist on EVM or on E1 currently because if we would propose like it was in the system we wouldn't wanna keep the pre-compiles. And we have reported this previously that the elliptic curve pre-compiles we got quite good results. So that was with the BN128 or BN254. We got quite a good results with those including pairings but it's required what we call big integer host functions. So those are, you could see those are kind of similar to pre-compiles but those are much more primitive operations than the pre-compiles which exist on E1. So as an example it would be 256 bit addition because wasn't, doesn't have it but we also proposed Montgomery multiplication on 256 bit numbers in this big integer API. And with those we were able to achieve really good speeds on BN128 and in the past month we have been looking into BLS12. And again, we managed to reach speeds very closely to the native speeds. So first we have looked at, and all of this is on interpreters. So first we have looked at just a basic BLS128 implementation in Rust which didn't really produce the speeds we expected or at least we hoped. So just some random numbers here. The, this Rust code combined natively was taking roughly five milliseconds for a two point pattern. And the same compare to WASM was roughly 500 milliseconds. And then we reached out to WASM snark, Jordy and the team behind WASM snark because that has been the optimized WASM implementation we have been using for BN128. And they managed to implement support for BLS12. And with that code, with some more optimizations on the big integer APIs, we have been able to move the speed down from 500 milliseconds to close to 14. And I think with one set of optimizations we were able to get close to eight milliseconds. So that's less than, less than half the, but more than half the speed of native. So I would say this is really good news that even on BLS we could get to use BLS video pre-compiles in WASM. And the last part now is that we were also interested to check if we can replicate these findings on EVM. So in the past, I think three weeks we have been working on a small project called EVM 384 which we hope to release for tomorrow's all core devs. And under tests we have added three upcodes to the EVM which are modular addition, modular subtraction and Montgomery multiplication. All these working on 384 bit numbers. And we have implemented just one building block of the pairing operation and made a more like a synthetic benchmark out of that to approximate the actual implementation because obviously into two, three weeks time we don't have the capability to implement BLS 12 on EVM. But with this synthetic implementation we got pretty close to the WASM numbers. So in the end what that means we may be able to even get rid of the the BLS 12 pre-compiles for each one. Potentially it seems to be possible to replicate that with just three primitives. I think that's all and sorry it took so long but hope you found it interesting. Yeah, good, thank you. And if you're interested in some of the stuff and you haven't read the X64 or the recent X64 posts check it out. Any follow up or questions for AXIC? Other research updates? I know I got a handful of people that might want to talk. Vitalik? Looking into homomorphic encryption things more. One thing that we discovered is that there's a use case for it in private information retrieval so we'll probably ask around more things about that producer. And I'm also a published A.I. post this morning basically kind of open calling cryptographers to see if they can solve our polynomial commitment problems. Not too much else in terms of researchy things. I guess spec side also looking into some phase one simplifications. On the proof of custody side. Oh, right. If you have been following proof of custody stuff check out, Donkert has a new post on A3search that proposes removing the bit from the actual signature which is pretty cool. Yeah, and I have a kind of mean thing that I haven't posted but the follow up which basically has kind of reduced the frequency of key revealing so you don't have to worry about kind of keeping track of reveal lateness and it's just like if you don't reveal in time then it's invalid. Yeah, so like between those two things it seems like we can cut with the complexity of the proof of custody by more than half maybe two, three quarters. Yeah, which is awesome. Yeah, the thing where it turns out that we got a bit unlucky is we went down the summer rabbit hole of trying to get a self verifying proof of custody based on the key commitments and it's, I mean, there's kind of, there's efficiency and uncertainty is it would also bind us to using key commitments for block verification. So there's challenges in going down that path that don't exist if we just go down this kind of 0.01 bit approach. Yeah, cool. Yeah, check out that post. It's pretty interesting, very simple but might reduce complexity by a lot. Okay, other research updates? Do one for TXRX. Great. For ETH1, ETH2 merge research, Mikhail has just released an ETH research post about that I think just shortly after the call last time. Oh no, actually probably about a week ago he released it and he started working on a draft ETH1, ETH2 communication protocol to, and he's kind of like working on a POC for phase one as well. For the network monitor, we found that a lighthouse was sending unsolicited UDP packets and so we opened a PR for that regarding fork choice tests. We kind of, we've been generating tests. Alex has built this kind of transpiler for the tests and we found a bug already in Techoo for the proto array implementation. And around the fork choice tests made improvements to Onatoll which is the PySpec transpiler. So now it can translate phase one spec and found three bugs or three, we go in three PRs regarding a PySpec for phase one based on the results from that. And then implemented Gossip 1.1 on JVM Limp V2P.  Thank you. Other research updates? Gio, many success in making an RPC consensus engine for Geth? Yeah, I mean, there's a PR in the works. We're still kind of discussing the documentation, sorry, the list of RPC calls with Peter. We had the meeting this morning. And I think we just shared with you the document. So I was going to ask for your input after this call. But overall, yeah, I would say the skeleton is already there but we still need to, yeah, I don't know, a couple of details. Great, great. Cool, thank you, that's exciting. Other items, other research items, anything before we move on? Cool, next up is networking. We did have a call about eight days ago. It's a really good conversation and items came out of that. And we've also, this has kind of been ongoing, debugging and interfacing with networking. But are there any other updates? Anything on your mind, Felix, or otherwise? Hey, sorry, I couldn't really unmute in time. So sorry for not participating in the networking call last time. So on my side, I'm still working on the new, on the sort of like spec updates to the DSP5 spec which will improve the current performance a little bit and also resolve this one error message that I guess if you've been running it on a testnet, you're also seeing it basically sometimes you can get packets which are seemingly, which have seemingly wrong encoding, but actually it's just a spec bug. So I'm still working on it and I will publish that very soon. I'm actually not sure how to, basically I'll have something for feedback next couple of days. And then so would be kind of nice to get into a bit of a conversation with like all of the implementation teams to figure out like what is gonna be the path of least resistance to upgrading because the discovery upgrading can be kind of complicated. So we have to figure out if we actually wanted to try to do some soft update or just basically live with like half broken discovery for a couple of weeks until everyone has the right version or if we're right. So complicated with respect to live nets. Yeah, so if the network is live, it can be complicated because they will basically be, if there's a mismatch in the versions and the versions are fundamentally incompatible then basically there's no way to do a clean upgrade because basically just means nodes won't find each other. So due to the V012 spec update with the BLS updates coming, it might just be best to wrap this in the same update so that, because we're gonna have to restart the nets anyway. Okay, that sounds very good. So I mean, depends on like, I mean you were talking about like tentative, like June timeline for the next testnet. So maybe we can just make it so the updates go in then and then we just launch a new testnet with a new version or something like that would be great. I mean, how long do you expect these changes to need to be able to go back and forth and make it into the spec? So I guess it's gonna take approximately like, I don't know, one or more week at least to like kind of get the actual spec done and then I can assist people with the implementation.  It's gonna be all minor changes. Cool. So what I would say is, reach out early to implementers to get feedback and input so we can just kind of streamline this. But if we can get it down on that timeline then I think we can avoid the headache of upgrading these nets in life. Yeah, okay. Cool. Thank you. Any questions for Felix? Great. Other networking items? Okay. General spec discussion. I have seen those phase one PRs with the bugs. I certainly, the testing on phase one is minimal, we're currently. So I really appreciate those bugs, but I've been prioritizing to be zero 12, but I'll get to those soon. Other spec items, I imagine this one's been pretty quiet for the past six months, the spec item discussion, but as we move into phase one implementations, I'm sure it'll get a little more lively. I have a question regarding the fork choice tests. Will we have them in 0.12 or 0.5, 0.1? Right. So Joseph, what is the state of the fork choice tests that you all have been working on? Are these generated off of the PI spec or are these generated off of the old harmony implementation? And what's the format that they're outputting in? And given that format, is it something that we can integrate into the canonical vectors for the next release? All right. Alex, who's likely on the call to speak to it, but essentially what it does is it reads the PI spec and then transpiles it to generate the tests. But Alex, are you on? I don't think he is. I'll knock on y'all's door and see if these tests can appropriately just be shoved into the next release because if they're already working for you, they can work for others. Definitely. I think that was his goal though, was generally being able to just automated test generation for all the different clients. Cool. Okay, I'm gonna knock on his door. Thanks, Mawin. Thanks, Joseph. Okay, any other items here? Hi. So about the BOS shop before this call, I just made a PR to fix the phase one, phase one, the zero signature issue I posed here and I hope that people who are interested can take a look like in 24 hours so we can generate the BOS test soon. Thank you. Yeah, I will certainly take a look and others can as well. Thank you. Okay, open discussion, anything on anyone's mind. Awesome work. There's like a ton of moving parts right now and it's super, super exciting. Thank you everyone and I will talk to you all soon. Thank you. Thanks, Lyle. Thanks, Lyle. Bye. Thanks everyone, bye. Thanks everyone. Thank you. Thank you.


The Blue & U and this very special behind the scenes tour of Denver's new crime lab is brought to you by the Denver Police Foundation. For more information on the foundation visit their website at www.demberpolicefoundation.org. 75 foot double lane pistol rifle range at this point. Right now in the lab that we have we can't fire rifles. The range is only 25 feet long and high-powered rifles won't work in here. This will handle anything up to 50 caliber BMG. And when a gun fires you're going to get this great big huge cloud of lead that's going to surround you and the weapon you're shooting. Well, lead's not good for you. It's not part of your diet. It's not on your food tree and that's supposed to be ingesting lead. So what we're doing right now is we've got this air system and it's not on yet. You can hear it going a little bit but it's really not on. When we do turn it on it's going to send a large volume of air downrange. It's going to blow all of that lead cloud away from the shooter.  So it's a good system. It's a safe system. The last thing we really want to do is have the shooter, you know, ingesting a lot of lead. All of our folks have lead tests every six months. We want to keep it safe. Keep it safe. Well, how do you go in there and find your bullet? We don't. The range is strictly for checking functionality of a weapon. Does it work? When we go to the courtroom, the first question my firearms examiner is going to be asked is, does the weapon work? We have to fire the gun. In the old lab we had a vertical tank. The vertical tank allowed us to recover bullets from handguns. We could not fire a long gun into our vertical tank. Not a safe thing to do. This tank has been designed to be able to handle a long gun. We fired a 7mm mag into it. Handled it beautifully. The company that manufactured it, test fired it before they ever sent it out to us for the .50 caliber BMG round. The engineering on there is phenomenal. It actually creates waves inside of the tank. You've got your pumps down at the end to actually send the wave pattern toward the shooter. So you shoot against the wave and it takes the velocity out of the bullet almost instantaneously. Phenomenal piece of engineering. Small space, but we're able now to fire not only long guns, but handguns. This is a vehicle inspection bay. This used to be the Sally Port for the city jail. It used to do a lot of prisoner drop off here. But we've gutted that out. We've got new floors, new walls, new innards. And what we're doing here is we have a multiple space vehicle inspection bay. I talked to you about superglue. I've got a tent. At this point, this is a superglue tent. I can put an entire vehicle in there and actually superglue the inside and outside of that vehicle. The tent's collapsible. I can bring it together. It creates probably a three foot wide frame that I can move out of the way if I have to. So I've got room in here for two vehicles. On the far side of the bay, I've got room for a large profile type vehicle. I have pneumatics. I've got electricity. I've got light on either side of the bays. All three bays. I've got work centers for the crime scene investigators. I've got work rooms. One for fluorescence or luminol. We're checking for presence of blood or semen that has been trying to be washed away. We can find trace elements of it. I have another room on the far side that is another superglue chamber. But it's the room itself as a chamber. I can put a door in it. I can put a car fender, a bumper, whatever I want in that chamber. It's big enough to handle it. So this chamber's for a car. The other one's for large items. The one's up in latent prints or for smaller items. This is basically our man cave. This is a place for people to come down and really look at a vehicle under a controlled situation. Again, we come a long way. Thanks for joining us for this very special edition of The Blue and Yew. The City and County of Denver now has one of the finest crime labs in the world. I'd also like to say thank you to those Denver residents who supported this bond project so that we could build this incredible new facility. That's our show for this month. And remember, the key to crime prevention is The Blue and Yew.


When you write a paper for a graduate class, you'll quickly realize that the expectations for your writing are much different than they were in undergrad. One of the areas in which this is particularly obvious is a thesis statement. This video will show you how to discern the major components of an effective thesis statement. So what's the big difference between a thesis for an undergrad paper and a thesis for a grad paper? To put it simply, thesis statements for graduate papers are sophisticated. They should be arguable, specific, and able to be supported by relevant theory. Let's start by looking at what it means for a thesis to be arguable. Here are two examples. Which one is arguable, and which one is a statement of fact? Pause the video while you read over them. When you're ready, hit play to find out if you've chosen correctly. This thesis statement is arguable. It states a claim, and offers a reason for this claim. People may disagree with either the reason for the claim, or have a different reason to accept the claim. The bottom example is simply a statement of fact, offering something that really can't be argued or disagreed with. In fact, it would probably be difficult to write a paper supporting this thesis. You'd probably run out of things to say. Now let's take a look at the second characteristic. A thesis should be specific. Take a look at these two examples, pause the videos you did before, and decide which one is specific and which one is too vague. When you're ready, hit play to find out if you're correct. You might have been able to tell by the differences in length, but this example is more specific. While more words doesn't necessarily mean that a thesis is specific enough, this example goes into sufficient detail, in addition to offering an arguable claim. This example, however, is really vague. What kind of limitations is it talking about? Why is it a useful framework? This statement needs to be developed more before it can be effective. Remember that graduate level work is more rigorous than what you did in undergrad. The expectations for specificity are likely to be higher. Finally, let's take a look at the last element. An effective thesis statement can be supported by relevant theory, particularly when you're writing a case study. Take a look at these two examples, pause the video, and decide which one can be supported by relevant theory. In this case, the number of words doesn't really tell you anything. This example makes an arguable claim, which we know is important, and that claim can be backed up by theory relevant to the issue. The other example basically summarizes the organization, but doesn't offer anything that can be argued or supported by relevant theory. You don't have to come up with a perfect thesis before you can start researching or writing your paper. Oftentimes, writers start with the so-so thesis and modify it as they conduct research and think more about their topic. In the first example we looked at, the statement of fact could be turned into the more effective claim. Rather than starting out with a perfect thesis, it's important to know approximately what you want to say in your thesis and modify it until you have something that's effective. Remember that a paper is a chance for you to engage deeply with the topic, develop your own stance on an issue, and share that with your reader. A great thesis statement helps your reader get a grasp of your position before they dive into the body of your paper, where they'll find the support you provided for your thesis. For help constructing an effective thesis statement, ask your professor for help or make an appointment with a writing center.


Fort Bragg, Fort Hood, the Washington Navy Yard, and USS Mahon. What do they all have in common? All these bases have endured the tragedy caused by an active shooter. Lives were changed in an instant, and in the aftermath of these shootings, victims were mourned and survivors started the recovery process. To help prepare against such senseless actions, the Navy regularly conducts active shooter drills. These exercises assess the readiness of security personnel on naval installations. To ensure safety, Navy Security Forces assists sailors in preparing for such incidents. The training you receive during these drills can mean the difference between life and death. Do your part and understand the importance of knowing what to do during an active shooter situation. Talk to your command training department or visit Navy Knowledge Online for more information so you know what to do if another tragedy strikes.