Which means taking storage off-chain right now this seems infeasible because of the cost of call data So Let's take an example layer 2 contract So the cost of call data is 68 gas per byte Which means 2,176 gas per word of 32 bytes Now let's take a side chain that can accommodate two million users Eats with a balance in two different token types. These are the rough numbers that we consider a minimum viable product at 0x This won't even take us like to a the whole world is tokenized scenario in which case we would need a million tokens and a billion users Anyway, this will already bring you to a balance tree that has 32 layers in it So a miracle proof in this balance tree is 30 true words, which means 70,000 gas of call data Verifying it is super cheap like it's a couple of char tree operations. You do a couple of call data loads It's only 2k gas to verify this proof But compare this to doing a storage update of a same single balance. That's only 5k gas so we're talking about a more than tenfold More expensive Solution to bring it off chain. This makes this entirely unfeasible right now. This makes us right now Use storage for balances instead of taking this off chain This problem actually gets worse once you look at more sophisticated solutions Starks right now are Limited by call data you can verify a stark in EVM fairly easily You don't even need a pre-compiled for that The problem is that Starks contain a lot of Merkel proofs and these Merkel proofs right now cost millions in gas It's hard to stay under the gas limit purely with the call data. So if you want Stark based layer 2 solutions call data needs to become significantly cheaper Another thing is fraud proofs. I know that the true bit people They have this mechanism where you can submit a fraud proof of incorrect execution And they had trouble keeping this fraud proof which contains a lot of Merkel roots to the memory that was used in WebAssembly They had trouble guaranteeing that this fraud proof would actually stay under the gas limit And if you have a system that depends on fraud proofs and you can't guarantee that the proof actually fits in a block Your system is up for disaster Like Someone can do something fraudulent and you would not be able to prove this on the main net So it's it's essentially uses a way another thing is Take for example the mini me token This is a token that uses a tremendous amount of storage because it keeps all the old balances around and the main purpose Of doing that is that you can do things like forking a token at old balances or implementing Foting mechanisms that uses balances at a certain point. There's a much more efficient solution for this Where you just use a Merkel proof of balance to an old block hash or to a particular block hash or state route snapshot That you store in the contract, but right now. This is also infeasible simply because of the cost of Merkel proofs so where does this number come from the 2176 gas per word and Vitalik, please interrupt me if they get this wrong But the way I understand it is that it started out with a particular maximum Call data block size of around a hundred and twenty kilobyte then divide this by the gas limit and This will give you the minimum amount of gas required to ensure that the call data is always under a particular Trash hold so basically it's starting from the what is the most adversarial scenario of call data Given the gas limit and the cash price of it and how do we need to set the gas price to prevent this from happening? I'm not exactly sure where this hundred and twenty gala kilobytes itself comes from this could be either Like chain growth as stuff where we don't want the chain to grow with more than a Maximum of a gigabyte per day or something like that It could be a bandwidth issue where a transaction propagation grinds to a halt if we go over this limit Or it could be a block propagation issue where blocks themselves don't move fast enough As soon as we increase it. I'm hoping that sack can come up with a decent answer here soon Of what actually breaks if we if we up this limit That being said in practice, we don't even get close to this Call data block site according to Eta scan the average block size is about 20 kilobytes I assume that this contains more than just the call data and also maybe transaction receipts But I don't know how Eta scan IO computes defines block size at any rate it's 20 kilobytes and it peaks under 40 kilobytes So we're nowhere near the limit So I also want to quickly reflect on what other users does call data currently have So the main use of card call data is to argue for a state chains It is basically prove like some signatures some meta information that the state should move from This state to the next state There's some auxiliary use cases that people have sporadically used as such as proof of knowledge You can submit a hash of a document to the blockchain it gets stored in the call data And then I can always claim in court that I had this document in my possession before a certain time Same as proof of publication some algorithms require data availability things Where you need to prove that you actually publish certain things you can store that in call data And the other is just simply use the ethereum blockchain as your own Like distributed file system I would argue that only the first is an appropriate use of call data and the rest should refer to logs and Storage instead so I would argue that we can ignore all the other All the other use cases Make it only for state transitions and therefore make it Security wise safe to prune as soon as a decent amount of consensus and finality exist on a state So given all that I proposed the following First of all remove the zero non-zero distinction. I didn't really get into this during this slide But basically this is a remnant of using a run length encoding in the wire format, which to me seems like an Over emphasis in the gas model on a particular implementation and as far as I understand this run length encoding isn't even used anymore And right now people are mining ethereum addresses that have the maximum number of zeros in them Scattered throughout the address, which doesn't even help for run length encoding. So yeah, I think this can go I would also argue that we should lower it to a hundred gas per word in order to make miracle proofs economically competitive with Chain storage Now this is the immediate consequence that the will that the maximum call data size of a block can increase so I would I Would say we can add an additional limit for a valid block So block is only valid if the combined call data size is less than x where I suggest as a starting point We make x twice what the current maximum is 256 kilobyte And then in order to make sure that chain growth the things are kept in check We aggressively prune call data under the assumption that it's only an argument for state chains that then doesn't have any further usage And that's my presentation already. I can give some more context about the zero non zero thing Basically the issue is that before we introduced that what happened is that people started Feeling the needs to kind of really optimize the hell out of their solidity functions and instead of a packing variables into 32-byte values They would spend a lot of time deciding whether it's an int 2 and int 4 and int 8 or I can int whatever and The goal of this is to basically just make writing contracts much simpler And so you can make everything be a 32-byte field, which is really much more convenient for contract programming and not have to worry about it Thank you. That's a good point That's also part of the reason why my proposal moves to a gas price per word instead of per byte Right, but the problem is that you could even still kind of get efficiencies by Packing multiple arguments into four Bite things in one word. Gotcha. Do you think that's still feasible if the gas price is a hundred gas per word? Because then the overhead of packing becomes more significant, right? Yeah, it'll definitely become like better, but a hundred gas per word is basically three gas per byte Which is in 20 x 20 x degree is significant And I'm also kind of scared of this kind of hybrid rate and limit problem issue because it changes the miners Optimization problem to this weird month multi-dimensional thing that requires more complex math to figure out But I Guess like the core of the proposal is probably just reducing the limit and and aggressively pruning call data, which seems like fine so if you've got 256 kilobytes per block that's about like half a terabyte of Blocks a year so I think that I Wanted to ask if you go back to previous slide when you were describing the users for cold data so interestingly here what you said that The other usages like for example distributed storage number four is this We were actually going on about the not using storage for like for as a Contract storage is basically like a really valuable resource It's probably more valuable than the cold data because it could be accessed from the smart contracts So I would rather say if you want to distribute storage you would should really use cold data instead of the storage Exactly exactly So I would say this is actually Very interesting in the context of a chain pruning So and in the state rent as well, so it sort of encompasses all of these things So what are the I think what we could get out of this is a recommendation for like how the storage should be used and what in which Cases cold data should be used instead or an issue case in which cases a log should be used So so yeah The main takeaway from this is that as much as we would love to use a state route in storage and basically Run 0x at a fixed storage size of only a couple of bytes right now. It's simply infeasible because of the cost of miracle proofs Yeah, I'm a little confused about this slide too because in order for something to in order to you know admit it a minute a log or Go into storage it has to come in through the call data in the first place Right now there is people who just send transactions that shove stuff into call data Just for the point of having the data be there, right? So, you know, it's like one random use case for this to give people context as let's say I want to have a Dapp that is just accessible from a like in one line of web 3 code Which would basically say load up the the get raw transaction of this then dehexify it and then execute that as javascript And like that would let you have dApps without having to have centralized UI or whatever I guess it's obviously a stupid workaround, but there's Reasons to do it. So if you want to do things like that post this change Then you would have to have the transaction But then you would also have to log the data and if you don't log the data then the transaction data just becomes like not Accessible easily after a couple of weeks That might happen anyway with logs and well the point is that the guarantees for law Like the basic think of it as kind of like a hierarchy where transactions are very ephemeral logs are kind of medium ephemeral and storages forever, but cost forever and Think we can also have a discussion to which extent we want ethereum to be used for bulk storage as opposed to solutions like file coin I Think there's a hierarchy here because like there's a difference between storing a few hundred bytes and storing a You know like a gigabyte of cat picture files So I mean I can actually just give one motivating use case of Extremely high value store use of the blockchain to store even like 50 bytes. So Let's say you want to have a some kind so some a brain wallet or something hidden behind a Basically a file encrypted with some password or something like that and instead of the pad instead of one password that you might forget You might want to have it say be a three or five of passwords or secure other things that you remember Now you can make a three or five with secret sharing But the problem with that is that with that big with secret sharing You can only choose your first three pieces of data and your other two are basically randomly generated stuff based on the first three So what you do instead is you choose all five pieces of data Then you use a razor coding to extend that to five out of seven and then the sixth and the seventh are random junk but you publish those to the blockchain and now you can recover data with Any three or five human memorable things plus two random things that are publicly viewable So there's a bunch of like really cool tiny things like that where like the value of storing data is Extremely high per single byte and so using the blockchain arguably is really optimal for it But but it's definitely not the same as I would also say one more comment Although it might have been designed that logs should be sort of cheaper to store than the cold data But the print practice The the growth of the log is already faster than the growth of the cold data So it's already like if you look at the archive note that I'm running The size of the older receipts is already a larger than the size of all the blocks which Answering your question it pretty much contains the cold data plus some addresses So yeah, I think it's like whatever the intention was the current log usage tells us that it's already like So I would start pruning the logs more aggressively than the blocks already because they actually grow in faster so then My guess is that actually use cases two three and four are really sporadic Yes, right now the logs don't really differentiate between the sporadic uses versus signaling that some token did some transfer and also that one of the big differences between sort of narrative of the Ethereum kind of sinking and Bitcoin does in a Bitcoin essentially There's only one way to sink the chains to do the from Genesis and because they don't have the state roots in the blocks So essentially the old the blockchain is one giant miracle tree in Ethereum However, you have a ability to sync from the snapshot Which means that it allows you to prune everything and still sort of have some kind of version of so basically theoretically even if the whole network removes the the first few blocks and It becomes unavailable. We can kind of still go on right we can still go and produce a new stink We just don't know what was in the beginning That and I think that mean that tells me that the storage in so that the space in the state Is more precious than the state in the blocks So and it has to be and what you're saying is that it's actually looking at the cold gas gas cost It's the other way around So it's actually easier to put stuff in the state rather than to put it in a cold cold data, which should be reversed Yeah, that's the main point When it comes to your point on log messages So if we were to do security critical information in log messages They will get mixed in with a lot of not security critical information that we would love to prune So then the argument would be to not use Not use log messages for points two and three but instead use storage directly because we do have security guarantees That storage will be maintained forward and then we can aggressively prune both call data and log messages Yeah, secondly. I wanted to yeah, thank you for running these numbers. This is super relevant But about the like a block size so I'd hesitate to introduce Block size limit unless we want to have not just a guess limit debate, but also a block size debate Isn't it gonna be fun? Right now we're nowhere near the current limit, but the assumption is that if we move to bulk off-chain storage We will get a significant increase in miracle proofs that are submitted to the chain so you can expect a significant uptick in the block size and Then right but if you then do this ten times gas increase you also have a Ten times block size increase so it already becomes 1.2 megabytes Which is something worth discussing in it in its own, right? I'm not sure it would be like that bad in practice to not have the limit because without it Like the block size without the limit goes up to 68,000 words Which is a bit more than two megabytes and from there like I mean first of all That's only a factor of eight more than this more than this limit And I think you can totally make reductions that are more modest into a hundred gas a word and like second this is one like Big blocks are one of those areas where if they're too big the your uncle rate goes super goes super high So there's also an unnatural distance that if they're not make very big ones but We'll have to discover what the uncle rate like what the yeah Uncle rate I'm looking forward to number to like seeing regressions on like what what the uncle rate contribution for blocks Block sizes as opposed to other things and those can be you know ameliorated with With optimizations on block propagation Just a minor comment that we've observed that uncles are smaller than regular blocks So block sizes not the impact that we think it is That's some reduction from the status quo is like good But the question is how big of a reduction because he still wants to kind of keep it balanced relative to other stuff And it seems like like if we want to if our goal is to make more goalproofs Be the cheaper way to build these kinds of applications then like we're actually attacking that problem from two angles one of them Is making the call data cheaper and the other one is making stores lots more expensive. I mean that is the goal It's the only option. Yeah doing both is Yeah Yeah, this is just to clarify this this limit on the Block size if we can do without that would be better for me, of course Okay, so I'm here about here to talk about uncle rates. So the previous conversation kind of flows nicely into this We've been looking at the data Historically of uncle rates and then just to give some context uncle rates are still blocks They get mine and included into the chain to get some reward, which is about Seven eighths depending on when it gets reference in the main chain and you also get a reward for including an uncle And so why is this important? It's it can help you see what the state of the network is higher uncle rates are theoretically related to lower block times and also To a larger size, but it's not necessarily the case as we've noticed in the last six months So we look at the uncle rates historically and then we find different points in time where you have Interesting changes. So you had some hikes in August 2016, which is the Dow or like another now another fork In November 2016 and so on and so on forward But for us what's been most interesting is this drop in the last six months of the uncle rates It just seems to have been going down Which is interesting because the number of transactions per block doesn't seem to be going down So there's not necessarily a relation between the transactions the size of the block and the uncle rates And so the idea of this is to make it a little bit more interactive for you to give us also some ideas of Why this might be happening and some of the implications of this So essentially this is just like a closer look in terms of the last six months and as you can see the transactions doesn't really match This slope that we see in the decrease of uncle rates And so we just thought about a number of different possible causes for why this could be happening So maybe the data size is more important than the transaction count. Maybe it's the number of miners or the number of nodes Protocol changes or the parity and get optimizations Or changes in the miners strategies maybe an increased connectivity between the miners or Since there's a migration of a lot of nodes and miners into Amazon, maybe that's also causing better connectivity and thus Resulting in lower uncle rates And so we started testing all of this hypothesis. We have collected data from Aletio It's eat their scan and eat their chain and we're gonna share all this data so that people can also start doing their analysis and Essentially, these are the variables that we've used so they're all number there And so we started checking the number of miners, which doesn't seem to have changed much in the last couple of months So if anything, there's a little bit more miners, so it doesn't seem to be related to the uncle rates We can also see that there's a lot of centralization. So if we look at the top 20 miners Historically it has decreased a lot now. You have like only five main pools that have most of the hashing power So that could explain also the increase in connectivity and the drop in uncle rates But it's not conclusive And this are the mining pools that have been doing the most mining of uncles in the last six months So we started theorizing what could cause this maybe some collusion or selfish mining but it seems very unlikely in terms of The results that we found We did find this curious increase on number of empty blocks in the network There's been an increase of about three percent. There were some articles They came out about a couple of months ago in October that were claiming there was spy mining happening in the network But we talked about this this morning with Vitalik and it seems that that wouldn't be possible But it does seem that there's an increase in terms of empty blocks that have been mining have been getting mine in the network so again, we tested this idea that Miners would stop working on blocks as they receive the header from other miners and they and Since they don't have complete information all they can do is post empty blocks But it doesn't seem to be the case We're also look we were also looking at these empty blocks and finding that the data is a bit inconclusive as you might have Higher block size than the uncle size or the inverse. So we're a bit puzzled by why this is happening And so like you can see here You can see the size of the uncles on the first column and then the size of the blocks on the second column And you just see variation sometimes the uncles are bigger. Sometimes the blocks are bigger And so we started doing some analysis in terms of this data and trying to see what could be causing this behavior. So Yeah, we also check the number of notes, but it doesn't seem It might have an effect in terms of less participants in the notes So they're more connected between themselves and then decreasing the uncle rates again Which seems to have been happening. There's a lot. Let's nose in the network Actually, I heard that it was about three thousand the real number of notes That's actually running at the network at this point. So very low We did conclude that some of the protocol changes the optimizations have definitely helped in terms of the uncle rates and Then we don't have any data on Amazon. So it's really hard to tell But this is some of the regression analysis that we started running So this is data from last year and looking at what impacts the most the uncle rates So definitely the number of transactions the hash rate the block size The number of accounts but correlation doesn't necessarily mean causation. So it doesn't really matter And also the rewards and the price of ether But if you look at it in the last six months, the number of transactions seems completely irrelevant It doesn't affect the uncle rate anymore. The hash rate is even more highly related And the block size has also decreased in terms of correlation between that So we just started doing some regression analysis with all of the variables This is all the results for all the regression analysis for simple linear regression with all the different variables and These are the ones that seem to be the most related So you have hash rate average block size difficulty mining return Oncomoning reward ether price gas limit and gas usage So essentially the idea is that with all this data that we've collected we can actually build a mathematical model and start playing around with the block gas limit and see how it impacts the uncle rates because Essentially if you have an increasing size of blocks But the uncle rates are still dropping then you could potentially increase the size of the blocks to a certain degree and so this is like a Building a model in the idea is that we're going to build a model with this with multivariate regression and trying to find what's most impactful and so from all of these hypotheses we concluded that Maybe the data size has something to do. It's not the number of miners Maybe the notes as well Definitely the protocol changes in the cat and parrot the optimizations have had an impact as well as some mining strategies that have been employed There's no selfish mining or no SPV mining as far as we can tell and There's definitely an increase of minor connectivity, which Yeah, it definitely impacts the uncle rates But that's it. I don't know if you all have any Ideas or anything that comes to mind. So can we 5x the gas limit or 10x? We'll see depends on what we run with the model and the simulations one of the things that I was Expecting after this. So you mentioned the gas and parity optimizations so one of the effects of those optimizations is that it actually breaks the relationship between The block gas limit and the uncle rates so it actually weakens it and this is because the block propagation now happens So the block propagation between the nodes the speed is basically doesn't doesn't depend on the How hard is to execute the block? It only does the proof of work at the moment So the only points where it the bigger blocks or more complex blocks slow it down is when the miners themselves Try to ingest the block. So I would say that It kind of makes sense to me and also it makes sense to me that it will be become harder and harder to use the uncle rate as the as a criteria for For network health. So we need to either if we still want to to monitor network health we need to find other criterias or Which may be stronger correlated to what we want to see. I Think you that's very interesting analysis good Who did we want to have next? Okay, yeah, hey guys, I want to talk about some testing criteria, right a lot of this is Some of this is gonna be a little redundant, but I just want to make sure that We're all on the same page and we have some clarification as to like what it is We're trying to do here and how we can most efficiently go about Achieving these these goals that we're setting for ourselves so I'm a proponent of obviously like doing this in a you know an accurate like deterministic manner So what we need to do is we need to like have a structure to the The way that we're we're testing and validating all of these hypotheses. So I Obviously first we want to formulate our hypothesis and we want to figure out which problems are valid like what's worth spending our time on right And this isn't any one about any one particular project or issue that's at hand It's just in general obviously time is of the essence for us and that's the whole point of this so we need to identify potential solutions and optimizations for these problems after we establish their validity and these these The certain optimizations may not be practical like we're we're presenting a lot of stuff and it's it's a great idea But we're kind of trying to come up with short-term solutions. So I think that we should target like you know low-hanging fruit obviously like Which optimizations are the best and which are the easiest to achieve an implement in a short period of time? And then just you know repeat this process going down the list, right? So we're gonna have these three criteria for evaluation essentially and it's nice to segment these and like Break them up into groups. So we have like environmental factors and that's gonna be you know more protocol related stuff like the state size and the hashing rate And another important thing is what can be controlled and what's uncontrollable in relation to these protocol related variables and then we have computational factors which are going to account for like the resources of a single node like the IO the knit capabilities all that stuff because we can't control the wide area network necessarily and we can't really control a lot of aspects of The protocol peering. There's a lot of things that are gonna be difficult And then there are also network factors, which would be like bandwidth and latency and packet loss the actual Conditions that we experience when these nodes are communicating with one another, you know within this within the network. So This is kind of like a brain dump and I'm really just presenting this so We can start initiating some sort of dialogue amongst ourselves So we can formulate a more structured way of going about testing and validating this product these things So like which environmental factors do we consider like how is the nodes available computational or network resources? How do they affect these for the performance? Like what's the relationship between pruning threshold and bandwidth like how often does a sink fail with? X bandwidth and Y pruning threshold if we account for state size within protocol to account for this and What parameters would result in the most effective optimization like which tweaking and tuning which parameters and So in regard to cache size, what's the minimum viable cache size? All of these are things that we should go about researching So we have some assumptions. These are just like my basic assumptions I came up with I wrote this last night just based on some conversations and dialogue that from yesterday So like processing the block.  I just want to let guys know share with you what I'm thinking so First we should establish our testing objectives like identify this assumptions and formulate the hypothesis like what's the bottom line and which criteria should we absolutely evaluate and which factors Have the most dramatic effects on the outputs so by identifying those factors We can understand a few key points like which optimizations should be prioritized Which are the most practical which are the most immediately achievable and I think that's one of the most important and formulating a test plan I Think that I created I wrote an example test plan for what we're doing Right Here so we can identify like the client like we want to test So I just kind of put this in and I haven't changed it me and Alexi We had the conversation and we need to identify like what is the criteria for a state size, you know How would you guys have find that? Because we can't really do it by the actual size that it occupies on a disc, right? Do you have any thoughts on that Alexi? Yes, because it is dependent on how the actual clients store it. So I suggested to just Number of accounts and the number of storage items and things like this. Yeah a total amount of code Okay, so I mean this isn't something that we're gonna decide right now Between the two of us, but before we move on and actually start testing these things We need to have those those variables need to be defined So we know what to look for right? So then our test cases that we're running we can write we write out a test series like this and We do that on white block Which I will run a demo of me just let me just Wrap up though. So using our emulation platform. We can acquire large data sets that are gonna be highly Accurate or reflective of real-world Data and then using those data sets. We can perform additional simulations Kind of similar to what Vanessa was talking about and the output of one test series can influence our hypothesis and like bring new issues light That's just the process. So But I think we should it's it's easier to just be practical And I think we should just demo white block right now So I'm gonna have Daniel come up and help me do it So I'm not like fumbling around and with keys and talking to everybody, but See, okay. Hello All right. Yeah, so We log on on the platform I Already have a chain built out. So we should just run the account info Or let's rebuild it While you're working on that. I had a question anyway. Yeah, so well, what are your priorities and where does the State size Emulation fit in among those priorities. I think they're gonna work with Andre Yeah, so we just started talking Initially initiating that dialogue today. So I mean, that's something that will work start working on when we get back to our lab I Have a few ideas, but I think it'd be more relevant to discuss in terms of like after we show What we're doing here So we're building out this blockchain with using the theorem on a theorem with the geth client We're just gonna indicate five nodes You can indicate the computational resources that are going to be assigned to each node and then you can identify the Define the parameters of the blockchain like gas limit or difficulty or whatever you would in a genesis file And then it's all dynamically created And then our platform like provisions all of those nodes sets them up with the appropriate client funds the accounts because we for so when we automate transactions and all that and assigns them each to assigns of Assigns of VLAN to each one of them. So they all have their own IP Now we can dynamically configure any of the links between those nodes with packet loss or bandwidth constraints Latency, whatever We can also add accounts or nodes After it's already been built. So right here. You can see like this was the initial balance. There's a transaction count and All these nodes are up and running so but right now there's if you run get Get info get or get stats all Yeah, so it's all zero right now because there's no blockchain that exists. So when we do minor start It's gonna just start all of the the mining process. So if we open a new tab we can Show the process of generating the DAG so So Joseph to answer your question. I think maybe Andre can do that. So can you tell us what do you think? Yeah, you can read the plan Yeah, so it's actually generating the DAG. We're well, we have to figure out how what time it takes to get to a reasonable storage size and I guess we're interested in testing two modes when we have a number of Like a limited number of smart contracts, which we inflate Or the other scenario is that we have actually just a number of dust accounts But a huge number of them and then we approach the size of the actual Ethereum a blockchain so depending on how fast we can get to that point and then keep inflating it We have we either have to or not have to make a number of of Modeling assumptions or like simplifications because on one one hand, we could use the real Geth and parity client and so on and be As close to the real thing as possible, but of course we'll have to reduce the difficulty, but but still if that proves to be computationally prohibitive expand Prohibitably expensive then we'll have more and more modeling assumptions because at the end of the day We are not interested in any security aspect of it or like even that it's Ethereum or whatnot. They are interested I given a certain sync protocol then What is the breaking point of that sync protocol? And then yeah, yeah So one of the issues is like how do we test effectively starting out because the state needs to be generated and before we start Actually testing so what my idea was is that we create a series of images with the state at size X And then we after those have been pre-generated. We can just import those states into our Framework and then start testing with those so we can automate transaction all activity if you want to show that and deploying smart contracts as well, so For this we do Transactions, yeah, so just show transactions So we're going to start a stream of transactions between accounts and you indicate the transactions per second And it's not like transactions per second that are going to be processed in terms. It's just How many transactions we're going to be sending in total within the network? Regardless of how many that's not the real TPS that everyone thinks it is but so we're sending a hundred transactions per second With a value of one ETH It just started so we can do get get stats past Get stats So we can look at the past ten blocks It's gonna take a second so we're watching that so you can just dynamically observe the how these how this how these This TPS is can change or whatever values or data points you want so one thing to note is we haven't applied any sort of latency or delay or Banned with constraints or packet loss between those nodes yet So we and in order to do that we also have a tool set for just standard network utilities like ping her IPer So we can run like ping between two nodes in the network like Yeah, so it's gonna ping between node zero and node one So you could see it's 0.05 milliseconds of latency and now we can apply a hundred milliseconds of latency to the links between those nodes And then we can observe the effects on TPS or whatever. I'm just using TPS as a basic metric that we're all familiar with So yeah, so we're applying a hundred milliseconds of delay And then if we run ping again should be Hundred milliseconds of delay between those nodes. We can also apply other Network configurations as well Then if you want to like run Hyper for whatever we can show you I better Yeah, I want to continue back to the question. Yeah, thanks for the demos. Okay. Do you guys understand the Does it make sense so far? Yeah, okay, so it's helpful. Yeah, so we want to test essentially the sinking Oh first thing and using this with this framework to test the Like a failure of the where does the failure of sinking happens and kind of get more objective picture about where you know What are the criteria that where is the breaking point and yes? Yeah? I'm clear about that. My question is about alignment because I'm I think I'm pretty clear that Yeah, Andre and Alexi's priorities, you know the Yeah, getting getting the data for the state size Yeah, increase impacts if as it keeps increasing But I want to get alignment on like where does that fit among your or white blocks priorities? You know, it's like number one for them I think that's pretty clear But if it's like number five on your priority, you know, that's something that we need to align on so That's what I'm trying to get at I Think that's like are you asking me what are my personal priorities and research? Yeah, I guess whether you or white block or Again, if it's like your if it's if it's number five on your interest list Yeah, it's number one and theirs then right it'll be hard for them to get well. We're gonna be working together So we're gonna be we're gonna be collaborating on on these initiatives. So In terms of my priorities That's something that's very interested interesting to me But I think my priority is finding out how we can be useful and contributing so if if if Alexi sees value in this then it's my highest priority that I'm that we're able to Provide value and help solve problems and create solutions. That's my priority is like Yes, I think we we kind of I think what we're hoping to do is that we we are get So basically Zach would provide access to this to this platform We have to decide about like the the cloud cloud compute bills like how we're gonna pay this bills and stuff like that but I think we can figure this out and You know, essentially to improve the documentation as we go because there might be some some lapses in documentation and Eventually like the reasons why I want to dedicate Andre for some time for that so that you know, I know that Zach Also works on other things, but this is why are we bringing Andre in in in this? Yes, so yeah, so I created this platform after because I was working on a theorem And I didn't have the tools that I needed to do a lot of the low level research that I wanted to do So this was made primarily for a theorem and I've been working and focusing on a theorem for some time But I think we should talk about that like offline because I don't want to like Shill I Wanted to add a comment on Testing syncing so you didn't include this but something you might want to think about an important factor in syncing is at least in warp sync is The Snapshot is now so large that just downloading it takes hours, right? And you can't expect a single client to be online for that long so in The vast majority like in 60 to 80 percent of cases the person you're downloading from will actually Disconnect you right halfway through and so you need to then go back into pairing and find another person like We now have it in place where you can actually restart a snapshot But they need to find a snapshot from the same block height This will be fixed in the next version of fast warp, but that's how it works right now So if you want to test how it works right now Pair disconnecting you as an important part of it. Yeah, so those are all features and functions that we have implemented Yeah, I think we're probably gonna start with the guess or at the beginning because it's probably And then move on to parody. Maybe by that time you've got already fast warp implemented So we can just do that right so just some things we need to I think like the most like the priority is just identifying how we can Effectively introduce the state within the environment. So it's not occupying a An exorbitant amount of time and generating that state initially from like Genesis. So but I don't think that's very Very difficult problem. I think that's probably something we can solve in a couple days of reading like R&D Which will get started on immediately So but does anybody else have any questions? I had one just just a quick one like how do you handle? different clients parody versus get versus well We have pre-compiled images that we store and then we just deploy them based on that client By indicating which client you want to deploy so what we're showing you here is like just like high level like obvious Like when we're testing we're not using these like build wizards that are prompting and doing all that stuff. We're actually Running just scripts that we define with based off of like a YAML file or something like that and then we automate all of the tests So after you define them in like a test file like I showed We could just like run all of those tests and one of them would be like client. We want a hundred nodes total We want 50 of them to have geth and 50 of them to have parody After you deploy those clients We have flags like we want to run these this many transactions or we want to do this or do that And that's what we want to do for this one test case. So we've done a lot of work with ETH research on exploring sharding and libP2P Using this framework and using those testing methodologies and it's been pretty cool experience So I would encourage you guys to like check out what we've worked on before because we don't really do any marketing like this is It's just us like hanging out and talking to people. So, um, you know But I think that these are valuable tools. They were useful to me So I think they would be of men's value to you guys as well and we want to work with you to build these tools make your lives easier and I want to open source all of this and That's that's a plan but right now I'm beholden to a board of directors But I don't want to say anything on the live stream But we could talk about my personal feelings and plans like afterwards. Well, you know, that's just live stream, right? Is it live streaming? Okay. Yeah. Yes, I love corporations And I'm very thankful for everything that the board of directors has done for me Okay, I'm their humble servant Thank you very much like I think we're really glad to have you on board Thank you. Are we good? Okay, thank you Then I think we have another are you guys ready to do one and more. Yeah, let's do another ebosom presentation testing home Okay So I was gonna talk about metering today, but instead I wanted to show you guys What web assembly looks like I should Zoom in somehow Yes. Yes metering tomorrow so that People know that there there is some beauty and some sophistication to web assembly It's not just sort of, you know, some bites of an EVM that hopefully there's no bugs in it This is some engineering, you know project and they have some proofs of some things Like most languages they have a syntax. Okay, so this is the paper That they put out when they were first announcing the language and They have this I guess syntax. I there's I'm sure people in this room know about these kinds of things There's standard ways to define languages and usually there's a syntax like we have a syntax in the English language There are grammar rules. Likewise. They have some sort of grammar rules or syntax to build these programs with and On top of this definition, so this is a definition of a syntax I don't know if they have all the rules or if things slightly changed since they publish this on top of this definition They define you don't have to know what this is by the way. Each of these is a rule And you have to you know that if you want to implement the spec or you have to follow these all these rules So these rules are for validity everything in a that can be checked statically. They wanted to write down and they Hopefully they wrote most of them down. I think there's some more later on about for some other things But anyway, we're there's some beauty that we're defining something called the grammar We're defining another thing on top of this grammar for each of these grammar rules We're defining these validity rules and once we define these valid validity rules. We can prove things Like that the absence of undefined befit behavior actually they have some undefined behavior that they identified but we we know about it and Source the point is we're standing on solid ground. We're not on an EVM. We're on a sort of solid foundation That we can you know build on Of course, there are some things like floating point that we have to be careful about and some things like growing memory That we have to be careful about and anyway after they define these validity rules and they designed it in a way that you can parse through the I guess e-wasm contract or the web assembly module And in one pass you can you can parse it Based on the grammar rules, then you can check the validity while you're parsing it And you can also compile it at the same time in one pass and also you can do it in parallel for each function So it's it's an engineered sort of It's engineered. It's a great engineering project. I think and They have a compact representation like 80% of native code size on average So portable any you know you can compile it to different Architectures and the ecosystem is growing. There are some growing pains, but it's growing So And there's some beauty in this these sort of definitions There's there's the execution semantics These rules you don't have to know what these are. This is too much. I know but each one of these is one step in in computation So there are computation steps It's sort of sophisticated there the computation is actually rewriting rules So you have some web assembly code and then it goes through these computation steps Where you rewrite where you copy and paste stuff and eventually you get to your final result and you're guaranteed They have some guarantees that you'll get to this final result and I think there's some beauty in in sort of defining things and having some sort of foundation and having some sort of solid proofs, you know these proofs are gonna you know just like Euclid proof things like 2,500 years ago about geometry, you know, and those proofs are still good today There's proofs about this stuff and they're gonna be true 2,500 years from now and you know, so there's no obsolescence to these proofs and I guess I just want to That's all I wanted to say that's it Questions one second. Andrea will give you the microphone. Yeah, just a you know a layman's question basically I talked to ask briefly KC and Guillaume that you are using web assemblies or web assembly gives you some mechanisms and facilities for virtual machines, but also LLVM can give you certain facilities as well and one kind of thing that LLVM doesn't run in browsers directly, but Like I guess it can be compiled into web assembly that gives you a means to run LLVM stuff in a browser. So like Have you compared using web assembly as your primary kind of tool set versus using LLVM as your primary tool set? Yeah, this was a question. I was not working on eWASM when this question was answered But yes, there's a there's an effort with Cardano that they want to use LLVM instead of instead of web assembly Or they're maybe using both. Yeah, it might be a reasonable alternative. I don't think they design there Are you talking about the LLVM intermediate representation? Yeah, sure. It's an alternative. I don't know if they have the same properties I don't know if it's designed to be you know past, you know For transportation doesn't it might not have the same properties that web assembly, but certainly Cardano was justified in Exploring it they change their intermediate representation every version of LLVM. So LLVM 8 or 7 You know, they're starting to work on 8. So the the Their IRs is constantly changing. So you have to keep up or you have to either, you know, move with them And there might they might introduce something strange Yeah, you're right that this is an alternative and yeah, there are other you know Dotnet CLI. There's there's a few other alternatives that people might suggest and I think it's an interesting discussion to have But certainly web assembly has some properties that might be hard to beat So I don't know if I answered your question. I'm just ma'am. I'm just mumbling. I might be able to Yeah, I might be able to answer part of that as well. And that's it's not an either or Distinction you can compile down to LLVM IR and then write a back-end for web assembly Web assembly is the actual virtual machine as opposed to this abstract intermediary, right? So it's actually I mean really any modern systems going to go through several of these layers before you get all the way down So we can absolutely do both. We can also use LLVM IR down to EVM as well There's nothing stopping us from doing that and we could actually get like You know, obviously it was almost designed from the ground up in a particular way, which is nice but we could get a lot of these properties moving forward at the EVM prior to you wasn't being implemented as well and Plug it that then into the LLVM IR As well right back in for that. So we could get a lot of these benefits in the meantime and I Agree, I think using LLVM is a good strategy So I had a subjective question a little bit They're about to clean up the food and drink go get it if you want it So basically ignoring some cost and all that stuff That you've already invested into would you choose it again today and be do you like it? Do you like was it nice? Yes guilty on all counts. Yes, I wanted to add more to the decision for using web assembly so LLVM is Designed around two assumptions. The first one is that this intermediate Representation is ephemeral. It only exists during the duration of compilation. You can throw it away and redo it The second is that you trust it web assembly is designed on the principles that you don't trust the bytecode that goes in it And this needs to be standardized and the reason is that web assembly is meant for the web So you don't trust the code that goes in it. So the whole security design of web assembly is way more Gear towards adversarial behavior than LLVM is LLVM will have a number of exploit It aren't discovered because no one is testing it in this field And I think this is actually the most compelling reason to go for web assembly Check check last chance for food anybody else And drinks as well. Are we done with programs?


The results of the study suggest that minimally invasive techniques such as laparoscopy, robotics, and pair technology can be used to treat hepatic echinococcus with good outcomes. An algorithm has been developed to help guide surgeons when selecting the best approach for treating this condition. This article was authored by K. M. Kurbanov, Z. A. Azizota, M. G. F. Kurbanov, and others.


Hi everyone and welcome to JSA TV, coming to you today from the Tech Capital's International Finance Forum in central London, and joining me is Phil Berchie, the founder of Structure Research. Hi Barb, thanks for having me. Yeah, it's so great. It's great to finally do an interview with you. We're good friends and partners, and it's nice to be here today and meeting up in London.  How's the day been going for you so far? It's been busy, and it's, you know, always good to, you know, just get the day going fast when you're trying to get over jet lag. So, but yeah, this is a wonderful venue for networking and for kind of getting a different perspective, obviously a look at different markets around the world. And yeah, it's a really productive event and certainly a nice change from, you know, not too long ago, we weren't doing these things and we were, you know, had the screen between us and the Zoom app, so. So true. It's so nice to be back in person again and nice to see you and, you know, we're fellow Canadians, I like to say.  So, tell us a little bit about Structure Research and, you know, where, what markets you cover and just some of what you offer to your clients. So, we like to think of ourselves as a focused research group, very targeted. We spend all our time in the internet infrastructure or digital infrastructure ecosystem. We have six analysts, we're distributed, core group in North America, but we have an analyst in the UK, an associate in Singapore.  But we definitely spend, you know, more specific to this geography. We spend a lot of time over the last, say, three or four years building out our European practice. And so, we've built out data sets and full coverage for core flat markets in Europe, and now we're moving to the Southern European region in that second tier. So, definitely a market of importance for us. And like I said, it kind of fits in with our global approach and mandate. I mean, I know that I can say, speak on behalf of JSA and our clients where there's always such tremendous value that you, you bring to our clients and we're always proud to be able to recommend you and our clients that do work with you or, you know, find great value in what you offer. And on that note, you open today's session with a bit of a, I know it was a whirlwind, it was 20 minutes. And I mean, I said to you earlier, we could have listened for at least an hour to that. But give us a bit of a high level what you went through today or any of the key trends that you would like to highlight from that. Yeah, definitely. 20 minutes, it's pretty quick. I've prepared 40 slides, so simple math that's two slides a minute. But no, we had to kind of pick and choose in terms of what we could focus on. But I think some core themes, especially for this audience, is what is happening since last year in terms of where the market has gone, what the temperature is, how is it tracking. And there has been some decelerations that started kind of coming out of the pandemic halfway through last year through to this. And so, you know, commented a bit about where that's going and how we're seeing the rest of 23 play out 2023. So, you know, I think the, in general, our conclusion, and I think a lot of the conversation here would support our thesis, which is that, you know, it's a slower environment, but the core fundamentals of this sector are in place. There doesn't seem to be any, you know, any, you know, there are headwinds, but these, the directional trends of the industry are moving in that direction inexorably. And they're not, there's not likely anything in the way. And so it's a, it's a waiting game in many ways. So, I think that's the core theme and term, a core message in terms of what our outlook is for the sector. Definitely feel, obviously, hyperscale is a big part of that story.  And of course, you know, always have to look at what's next and what are the main challenges. And, you know, I think I concluded with a bit of a look at the self-build market. And so we at Structure Research are starting to incorporate the self-build portion as a component of hyperscale data center research.  There's obviously more, if you want to contact us. But absolutely, I think hyperscale, where it's going, and of course, you know, where it's going in Europe and on a global basis.  But of course, people can connect with you to, to dig a bit deeper and to, you know, get a fuller look. I'm sure that you would be happy to speak to, to any of our audience here. But you also have an event coming up, I believe. So that's why we're here. The Tech Capital has, has been a partner of ours on the event side and on the, on the media side. So, you know, they've supported our event and we're here to support theirs. Our summit is held in Toronto, in Canada. This year, October 4th to 5th, we have a little fancy new venue this year, the Shangri-La Hotel. It's a two-day event, similar in approach and focus to, to this event. I would say we have a bit of a longer history, so it's, it's definitely come, come a long way with the two-year interaction, notwithstanding. But definitely a very good cross-section of operating companies, supporting vendors, and of course, finance, investment and real estate. And so we try to spread that across our audience evenly. And it's a, and the backdrop is our, our third-party independent research. And so our, I think our, the last thing I'd say, I think our event has developed a strong reputation for being global and having very solid content to support the event. And, and that's, again, something that we're gonna continue driving forward. Yeah, I would agree. It's a great event. I look forward to attending October 4th and 5th in Toronto. This, that's this year, 2023, October 4th and 5th. And winter doesn't start till a few weeks later. That's right. Still warm and beautiful in, in Ontario at that time of year. This kind of outfit will do just fine. So thank you. Thanks for joining. Thanks for having me. Always pleasure. Always a pleasure to catch up and see you in person. Thank you. Thank you for tuning or for joining us. And thank you viewers for tuning in to JSA TV coming to you today from Tech Capital's International Finance Forum in London. Until next time.


Digital financial services help customers to manage their financial lives. In many parts of the developed world, people take them for granted. The ability to organise finances online or via a mobile phone is very convenient. But for the world's poor, access to digital financial services goes beyond convenience. It can be transformational. Enabling people to save, to ensure and prepare themselves for everyday risks and unexpected shocks like droughts or pandemics. To better manage their finances and seize new opportunities to build financial health and resilience. Improving lives and contributing to development. To make a payment in cash, you must hand it to someone in notes and coins. For people in rural areas, this can mean travelling long distances with significant costs for transportation and lost time. There's also safety concerns like theft, but digital payment methods allow them to send money to someone without leaving their home or workplace. For a shopkeeper in Bangladesh, previously she might have travelled to town to pay her bills and suppliers, forfeiting that day's earnings, lost income, adding costs to an already heavy financial burden. But with the right digital tools, she can quickly send and receive payments without leaving her stall. She can also attract more customers who are able to pay digitally, broadening her customer base. It's more than smart business. Owning a digital account can enable the shopkeeper to more conveniently receive government payments and subsidies too, potentially receiving economic relief when needed, not days and weeks later, or to promptly pay her child's school fees. When people use digital financial services, the transactions tell a story and offer insights to financial services providers. This transactional data becomes the new collateral to access affordable credit. This is critical for those who traditionally do not have access to assets or collateral. Providers can also offer other financial products and services. In Nigeria, a small holder farmer routinely buys jerry cans of kerosene to power his family's home. Small quantities cost more, but his meager cash flow prevents anything else. Investing in a solar panel is also out of reach. Going digital enables a provider to offer a loan with affordable payments so the farmer can get the solar panel. After three months, instead of burning a dollar a day on kerosene, he repaid the loan. This gives the farmer an asset, his electricity bill is reduced and that money is channeled into savings. Insurance providers can also analyse repayment behaviour to offer products the farmer can understand and with premiums suited to his cash flow. With insurance, he can be protected against crop failure and feel more secure to invest in the business, allowing it to grow. Or, if there is an unexpected illness, the farmer won't have to redirect savings meant for the business. He won't have to sell two prized cows to pay a doctor and he won't have to deal with a loan shark. Key digital public goods have to be in place for digital financial services to truly help the poor. Along with a range of accessible and affordable products designed by the private sector that strengthen financial health and resilience and laws and regulations that allow innovation and do not make entry too difficult. The positive impact of digital financial services is so great that all over the world, where the public and private sector are working together, they can enable remarkable change and people are benefiting. 76% of adults now have an account, up from 51% in 2011. This is an incredible achievement that offers great hope to reach the remaining unserved. Through focus and partnership, country by country, we can continue to improve not only access and usage but quality and that can transform lives.


Yo what up beatbox fam, this is Kayo and today we're gonna be learning the Kenny Urban Siren If you enjoy this video subscribe and as always smash that like button baby Step one to learning the police siren.   All right. We're on our way to learning the police siren. All right Step two or three whatever step you're on. All right. So what we're gonna do is Test your falsetto. Okay. So you're gonna want to talk like this. You're gonna want to talk really high. You want to You want to activate your falsetto? You want to talk all up in this region up here? Okay guys That's where you want to be talking And so then once you do that, you're gonna want to you're gonna want to say no, you're gonna want to vocalize No, like I got a new and so you get that no No, now put your top teeth on your bottom lip Again top teeth on your bottom lip And now make that Sound and then you'll feel a vibration move your lip around on your teeth. I'm gonna give you a second to practice it So move your teeth Literally do this until you find a spot where it vibrates and trust me. You'll know when it vibrates Okay, so now I'm gonna show you You see you see I moved my teeth forward on my lip And there's nothing there. I don't have a vibration But then I move it back If you need any help guys, please ask me in the comments below I'll get right back to you guys on anything you need help with That's it for today guys. That's how that's it.  I'll catch you on the next video Like and subscribe


Alright everybody, what is going on? Welcome back to another video, today's video I'm really excited about man, I am. Look, this is what we got, look what we got.  So effectively if I play a video game, playing the game that I say I'm good at and I know a lot about then you know things should go pretty well. Let's see, I'm about to play my first ever online game. Now I must admit I have received this probably about two days ago. I've played about half an hour worth just to get my controls back. I have played number one, but this is number three. So you know I started playing this game back in like 2010. I've taken a break from PS4 or PS3 for years and so when I first started getting into football I decided to buy another PS4 and buy Madden and start playing again. And now I've finally got back in my hands rugby challenge and we're about to play. I'm about to play my first ever game online. I'm about to test myself because the reality is that I call myself a rugby player, don't know. I do, because I think I'm good. I think I know the game like the back of my hand and I think that effectively I should go pretty well in this. But this is my first game man, first game online.  Now where is this going to go? I wonder when they're going to bring out rugby challenge four. So alright then, let's go play online. I'm looking forward to this. How are we going to set up this camera? Why is the camera all funny? Alright, play online, quick match. Yeah, quick match, rugby 15s. Tell me someone's online to play me, please. There's definitely not going to be thousands online like there is on Madden. Alright, how am I going to go? I've got to go to New Zealand, right? I have to. I have to. Yeah, searching. I'm ready. Yep. Come on man, please. Ah, the cutout hole. To the left, to the right, through and scores. Okay, so punt is X, circle is ground rubber, and square is drop kick. Let's hit a dropy, eh? And straight through the middle. Sevens? Let's see if someone wants to play sevens. I'm not hopeful. Come on man.  Why is there no one here? Seriously man? I want to see the leaderboard. Let me see. Here we go.  Hogweed. 1800 and 18 wins. 39 losses. 102 draws.  So this just goes by wins. Is it? No. No points. On the right. Oh, here we go. Overall. Is it? That's rugby sevens. Okay. Right, I'm just going to have to wait. That seems. I'm going to try and message a subscriber. A few message me saying that they had the game. So I'm going to... Maybe I should accept some friends. 16. Still waiting. Ah, God.  Alright, it's not going to work. No one's playing. Literally no one is playing this online. And I'm not surprised. I've got to be honest. So, I guess... Oh, I guess I have to... I still don't know all the controls for this game, by the way, but we are going to go that... And we're going to exit out of that. We're going to have 15s. And you know what? We're going to go New Zealand versus USA. Match ceasings. We will go. Where are we going to go? We'll go Christchurch. Which used to be called AMI Stadium. But that's ANZ Stadium. Canterbury Stadium. There we go. Canterbury, Christchurch, New Zealand. Difficulty. Very easy. Easy. Normal. Hard. Pro. Well, if I'm going to go New Zealand, I'm going to go pro.  Let's do it. Straight into it. We're going to go... We're going to do a 20-minute match here, guys. We're going to go day. Conditions. Fine. Law variation. Normal. Maybe as well do 20 minutes.  Let's do it. Okay. Let's go, boys. I'll get anticipated. White Crockett. Kevin Lealamu. Owen Franks. Brodie Rotalec. Sam Whitelock. Liam Messon. Karen Reeve. Richie McCaw. Aaron Smith. Dan Carter. I want to... Something for you to tell. Ben Smith. Comrade Smith. Julian Savia. Further USA. Who have we got? I have no idea. Do you guys know these names? You might. All right. Let's get into it. Remember, it's on pro. I don't know what I'm doing. Oh, here we go. The Hucker and all. Do we watch an animated version of the Hucker? Why not? Not quite the same, really, is it? You can't skip it.  Challenge accepted. Let's do this. Get it, Nonu. So, you know, I'm probably going to have to explain a few rules to you. They've already turned it over. That's all right. Don't worry about it. So, when someone goes to the ground, they have to release it. It's up to their players to blow over the top and make sure they attain the balls. It's not a good decision to try and offload there.  Sal's the dummy. Get him. Johnson could run. And so, if your team gets more players to the breakdown or to the tackle before the other team, they're most likely going to retain the ball. And that's the way that this game works. And it looks as if you're saying to score. They just keep building pressure and the try just had to come in the end. Just a kick for goal now. He took the ball so very well. Straight to the upper. We're down 7-0. Five points for a try. The conversion kick that he just did is taken in line with wherever the try was scored. So, that's why you see players try and get the ball into the middle of the field underneath the sticks or the posts because that is where the kick will then be taken. Carter with a long kickoff. So, the wider the try is scored, the further back the person is going to have to take the kick to increase the angle and the likelihood of getting the kick. So, this is friction. It's going to be pretty hard, I imagine. Get there, Ben Smith. Get there. Go, Smith. Go, Smith. Oh, the pace. Get there, boys. See, I'm excited now because you've got a chance. Out the lead. Look at it again. And again, go, Smith. Get there, boys. Fuck, I lost it. See, USA, I was isolated. That's why when you break through, it's not always the best thing to like. It's always the best thing to run off on your own because once you get there, you need your players to be behind you to help retain the ball. Now, I'm going to take a scrum here. First scrum in the game. And the way to drive in the scrum is to stop those little lines as close to the middle as possible. And I did enough to retain it, and Huffback's going to take it. He's going to fire it out. Bikitao spies the gap. Bang off the right. Oh, my God. Get there, boys. Smith. And now they get there, man. Great run. Fast at the defense. Great work to keep the ball alive here. And so there's also a button to get your players out of the rock. And the reason you want to do that is if you blind them there, but you know you're going to lose the rock. You might as well get them out of there. Now, stop them out of there to defend in the line. Oh, God, what was that? The crowd are out of the seats. That is a try. That was brilliant work. Everything they did in the lead-up was very well executed. Absolutely exceptional try. They're looking good with the ball, though. Exception. It was looking focused as he lines the kick-up. The kick looks like it's hitting over. He's got it. They're keeping up the clock. It's 14-0 with 14 minutes go on. Get there, Nono. Smash him. Good defense. Good defense. Oh, no. Get there. See, and there's also an option of a quick bind. And a bind is when the players go in there and try to start the smoke. They need to do a quick bind, which gets them there faster, but there's not as much weight behind it. Or you can do a quick bind, which takes longer to do, but there's more weight behind it. So you've got a... You're forwards, who are the slowest guys, are the ones with the most strength, so you want them to be in the box, where it's the backs. All you really need them for is just another number there. They're not really going to provide much weight. So it's a matter of pressing both buttons. A mixture of quick and heavy binds.  Oh my god. No. They've got it. I don't know they don't.  Get there, boys. Jeez. Short-run through the support line. Good run, but an even better tackle. Back to the left. Big ball, yes. Go, Salvia. Go, Salvia. Truck him. Yes, get him. Right. Off to the blind zone to the left. Go, Nonu. Get off him. Over him, boys. Too isolated. My fault. Go, Smith. Good follow-up here from Puppertown.  Here we go. So here's my half-pack. Why a crocket with the gap? Right. Here we go. Now get over the place. See? Lost it. Found it into the ground. Davis feeds it off now. Gets away from the first defender. Here you go. Gets the ball to his support plate. And he goes inside. Abbott with a good pass. Nice work. Bring him down in the end. Puts the ball up. Moore is locked in now. This Moore's still going. Drive him back. Drive him back, please. Drive control of this as they look to do something with this Moore. He's not moving. Gives it short. He's got some good passes. Oh, give him a lot. Goes to ground quickly. Johnson gets in the way. Now the kick-and-chase. That's incredible. He chose the ball theory well. Now I think he might go upstairs here. He dropped it. There was certainly an opportunity there. Watch this. Oh, the dummy in the kick.  The graphics are shocking, but it's all right. I know what he's trying to do. So let me see. Did he drop it? Yeah. Isn't that a try? Right, 21-0. Imagine that happened in real life. Gets away. Davis snaps up the kick-off. It was a good catch under pressure. Got to be calm in those situations. And he did it well. Nice tackle. He's taken down hard. Looks like there's an injury here. That's a pretty nasty knock to the knee there, Nisbo. You don't like seeing that. You don't like seeing that. A scrum, no. Anything can happen in a scrum inside your own territory. Set. Brutal contest in the scrum. That'll knock the wind out of him. Loose ball, snap up. That pass goes inside. He's stopped in that one. He pushes it on. He's been hit hard. Inside pass. Barry gets through the attack. Thompson keeps it going. They think they've got space, but they don't. Big tackle there. There's no answer to that tackle. Another injury. Come on, guys. Looks in some pain, too.  Big Lewis is on. Set. Nice. There's some decent power going on in the scrums. Good pushing from both teams. Halfback takes the ball. The ball is out, collected by Thompson. Oh, no. Comrade Smith doesn't get to come off very often. There we go. Get in there. Absolutely smashed. No way through. Coleman has it now. Well contained. Chase pulls it out of the way. It's definitely hard, man. He pushes the pass through. Good tackle, boys. It is. See how they want to kick it? There you go. Not gone. That's right. Come on, let's get it scored for half-time. He'll be annoyed at that. I've already been getting tired. The USA boys are getting tired. If I win this, this will be the best comeback for the time. Go, Rick. Get over there.  Shitting me. Great turnover. Good turnover. Excellent start. Yep, that's right. He's shaken up by that one. And he's lost a bit. And it's an advantage. He just lost the ball ahead of him, really. It was good defense on him, though. That's really disappointing. 21 points to nil with the break-up front. Kickoff is made. Kickoff dragged it. Did well, though, didn't he? I'm not sure how to. Coleman gives it off to him. Humps the leg for the good kick. Get it, Smith. Oh, what a run. Johnson, he's got away from a couple of them. No stopping in there.  Come on, let's fire it out. Nice short ball. Inside, man. And down he goes in the tackle. Oh, man, that's the class in the court.  The only reason I retain... No, no, no, no. They come away with a loose ball. What am I doing? Explains it. Ashing run into the line. Lewis takes him in a nice tackle. Stewart delivers it to a runner. Trying to get a drive going here. Now it's under way. Edwards can see it in there. Barry keeps it going. I can figure something out here. He's nearly there. What a run. And he's over. The try scored in the corner. And with the way the game has been going, they'll certainly be happy with that. That is a superb try. The kick looks good. And the conversion is good. That's a really great kick. It was not an easy angle to work with. They're running away from that. Look at that margin. A comfortable lead now. Kickoff taken up. He looks for options. And he's shaken up by that one. Now the chaser is coming forward onto this. Julian Sarvia. Where you going, Sarvia? You don't need to get a ball out there. Sharpish. Blindside this space. Now it's been picked up and throws the defense. Why is Franks always out there? Get off the ball, Frank. I want you, man. Now he gets the ball away. That's a hard-running mess. Now we'll have a scrum. Very encouraging signs for the scrum. It looks completely solid. The Americans got a good shove on there. Furious-looking scrum down there. Then with the restart at the 22. That'll knock the wind out of him. Gilmore with a good burst of speed. He's tackled there but made good ground. Thompson gathers it out of the back. A little pass there. A tremendous tackle there. He pushes it on. He's chucked a beautiful pass inside. And it's a moor. Banks has it at the back of the moor. Shucked down with a brutal tackle. The head defeats. So this is a line-up. And it's regathered by Carter. Carter. That's it. Oh, intercept. It's so easy to drop the ball in a situation like that. And I gotta say, he never looked like dropping it. Yeah, spin it out wide. Here we go. And again. Oh, get over on there. You gotta lose it. The ball's being contested. He's broken the tackle apart. Paul with a good spin.  He's looking for support here. Go, Smith. Let's take a drop goal, eh? Take a drop goal. He spreads it. Oh, what a pass.  That was a pass of Carter right there. Takes it down. All right, Justin. There he goes it out the back. This is a move. Like a bunch of Sherman tanks going up the field there. And they've got it at the back there. Headwoods. Hands it back. That pass goes inside. Adams. Driven backwards. I'll take that. He really takes it out of the back. Oh, my god. He takes it nicely. Their performance in the line-up has been pretty solid so far. They continue the drive. They move it. Looking for some space. Paul gets the ball away. A good pass to his support player. Lovely tackle. Strong defeats. Abbott feeds it on.  Smash it, good tackle. Finally taken to ground now. Your blacks get the line-up feed. 10 out from halfway. Easily beats the defender. Barry stocks him with a nice tackle. He pushes the pass further. Can't bring him down. Lewis stopped in that tackle. Thompson keeps the ball moving. Taken down in a brutal tackle. Feeds it on. Sends it flat. Nonu is absolutely smashed. Real chance here. Chase scores in the corner. Good try. They are looking good on the scoreboard now. Edwards with the kick now, lining it up. This shows just how powerful he is to break. And he successfully converts it from out wide. That is good. Very good kick. They could end up with a cricket score here. A high long kickoff. Williams takes in the kickoff. Superb technique in that tackle. We are going to finish it off with a drop kick anyway. Just because I can. Let's go Carter. Let's go Carter. Not that way. This way. Bang it over. Tackling hard. It's a drop goal. Hardly got some. He's done well here. Just lines it up nicely and picks up the three points. I know how that came off his foot. They've only got a few minutes to make something. Kickoff. Drag down. Back to his feet quickly and wrestling for the board. Taking on Blake Whiteley. Thompson makes the tackle. Miolamu with a good finch. Good little step. Thompson, plenty of pace. They get him this time. Picks it up. Has a dart at the defence. Took a few attempts but they got him. So just a few minutes remaining here. I'm happy. He's a real force in this defence. Don't lose it. Okay. Big pass. Piccatoa looking for support as he runs. Release. Have to release the ball now. It's going on. It's going on. Let's go. He's got the pace. He's got the pace. Oh no. He's gone dead. He's gone dead. The restart of the 22. Smith there to field the kick. Strong leg drive. You're not going to keep that. This match just about over here. That's a shot. He's pounded. Just start doing just one off. Just like they do in the game. You know? And don't lose the ball. I said don't lose the ball. Don't lose the ball. Then he hear me. Get over there. Oh no. Big drive. He takes the ball himself and has a go. He takes it. Piccatoa looks at the penalty. But Anoni brought down now. The ball's being contested. Delivers it short. He kicks it deep into enemy territory. Thank God for that. Ben Smith. Force back in the tackle. Now they get there. He keeps the ball moving. Richie McCourt crunches his way up. Looking to make a little ground here. And it's their turn. Oh you're kidding me. They'll play advantage here. Oh it's a shame. This is first class rugby and no sort of mistakes. It's advantage USA. They call it a penalty. Then the game is over and they just throw it out. Yep. And there is the game. 35-3. What a match it's been. On pro. But regardless of... I made a hundred and twenty tackles to their 60.  But you know the stuff from here. So it looks as if no one plays this game anymore. Which I'm really... I'm really quite disappointed. But I'm going to try one more time. Just once more. Because God that would be so much more fun playing against New Zealand.  Yes! There's someone here. Yeah! New Zealand. No I don't want to go New Zealand. Do I want to go New Zealand? Do I? Yeah I want to go New Zealand. Yes!