 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 mean, this is redundant because everybody's been talking about it like that's today So I'm not really gonna go over that too much. 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?