# Eth 1.x research call #3 ## January 14, 2020 Recording starts ~5 minutes in to call... Before the transcript, two things were discussed: * In person meeting Scheduled March 7-8 in Paris. The venue is limited to 40 people, so please respond to the survey in the telegram chat if you're coming. * "Stateless Ethereum" is a good unified term for the direction of research, so in public channels we'll be trying to use it instead of "Eth 1.x research into stateless clients" -- Alexey, talking about EIP 2464: https://github.com/ethereum/EIPs/pull/2464 ... which is normally the square root of you take the total number of peers, and then you add one.... Anyways, there was this strange formula in this EIP and I saw it in the code, and I was like, why is this the case? In the EIP it says something about logarithmic numbers... [square roots vs logarithmic] Is there any sort of model which sort of shows us why this is actually a good strategy... I could never get to the bottom of where this comes from and who invented it. Yes about both block and transaction propogation. I did notice that the transactions are propogated. I noticed that transactions go to every single peer, but the full blocks are propogated to a random square root of peers... but announced to every peer. And i was trying to find out where it comes from, because it's not very obvious to me why this formula is used. ?: Isn't it geth-specific? A: No, it's in the parity code, too. And I think there were two implementations of it so I submitted a PR to harmonize them slightly. It's not geth-specific and it's not obvious to me why this particular formula is used. I think it'd be interesting, in this context, if Peter knows about it, for him to explain why, because it's not obvious to me. ?: Yeah I think it's interesting, but it's not tied to a network protocol. A: No, it's not just academic interest, it's tied directly to the context of this EIP Piper: I think the parallels here are simply that we have a nice push pull model for blocks and it would be nice to have for transactions as well. Jason: You were asking about subtleties and if I remember correctly someone was looking in Bitcoin at this kind of model one as a way to map out the topoology of the network... A: Yeah they called it a "cargo cult", you see it in other places and you don't know why they do it but it works. (haha) J: yeah so they would say "here's a transaction, and you know they would provide it to only one peer , and then they could like check to see where it propogated to other peers as a way of like mapping out which peers were connected to which other peers." So yeah, that may be important in Eth2 when validators are trying harder to stay anonymous... but maybe that's a subtlety worth pointing out Essentially, Jason, if I understand correctly, was that this model that we already do with blocks can be used to map the topology of the network, and whether that's good or bad is its own thing, but we can figure out who's connected to who with some probability. Piper: so I think this is a pretty straightforward win. It's mostly orthogonal to what we're working on but besides the fact that it's just a good band of savings, so unless there's more to add, I suggest we move on to the next topic: witness research. Couple of topics here. Binary trie, there has been some progress on that. Alexey, do you want to elaborate? Igor has a blogpost https://medium.com/@mandrigin/stateless-ethereum-binary-tries-experiment-b2c035497768 Igor: Conclusion was that theoretically the size savings were 4x, and/but in practice, when I ran the test on mainnet, over 2.5million blocks (from the middle and recently), the actual savings was only about half. What's important here is that by 'witness', we mean all the information that you need to reconstruct the trie. So it means if we have and account with huge code/storage, that whole storage needs to be included with the witness. I later did a little follow-up on twitter, did some research on binary tries reducing the number of hashes in the witness. so when I looked at the hashes specifically, and removed all other components, I saw on average 3x improvements with the hashes alone. So that kind of matches the theory. so it's a good improvement I think. Alexey: I actually wanted to make a correction: this is true for the code, we have to include all of that, but we only include part of the storage which was touched inside the transaction. The problem with the code is that it's hashed as one single entity, which is what we were discussing today in the chat. Igor: Yes, that's correct. Because we treat them the same way, so we know which parts of the storage we touched Piper: Do we have any like, hard numbers on percentage distribution on how how much of a witness is hashes and how much is code? Igor: yeah we have CSVs V: there are some 2-line numbers on the EthMagicians post as well. https://ethereum-magicians.org/t/protocol-changes-to-bound-witness-size/3885 Piper: do you have any high-level numbers handy? V: Sure sizes for contract code witnesses for blocks range from 200-700 kilobytes, and the witnesses for like Merkle trie stuff ranges with hexary tries ranges from 600 kilobytes to 2.7 Mb P: so Witness sizes range from 800kb to 3.4Mb with something like 30% of that being code, and 70% hashes and the merkle proof? Alexey: Yes that's right. On average about 1/3 of the witness is code. P: Okay, so it sounds like we have a good estimate of the savings we can expect from the binary trie switch... Two thirds of the witness will be 3x smaller? Is that about right? I: one sec... Median savings: 47% 95th percentile: at least 39% 99th percentile: at least 34% V: Yeah that's sounding to me like things other than hashes are a significant part of the witness... what things would that be? I: yeah... we're talking about the full witness, hashes, keys, code, and storage. V: K. so that seems consistent with 2/3rds dropping by 2/3rds P: Ok, so we would expect the witness portion of that to drop to something like 300 kb to 1.4mB, right? V: sounds right. P: So then it sounds like we have good numbers. Alexey or Igor is there more that you'd like to look into? A: I think that the variations, even if we start changing the witness format, the variations won't be actually that different. Because the part that encodes the structure of the witness is very small. So regardless of how you pack them together, the conclusion will not change. P: So the remaining part then is how we pack the code. In answering "How small can we make the witness" A: Well, I would like to answer 2 remaining questions: Can we make the witnesses smaller by manipulating how we hash the code. So that's number one. Second, is can we replace the hashes entirely by something like a stark proof. And this is something we can pursue, and of course if we can do something with the code, then these hashes could also be removed. So those are related to each other, but they can be treated separately for the moment. P: K. So we have one more definite improvement, which is merklizing the code, and then possibly two more improvements using ZK techniques to get rid of all the intermediate hashes. Okay, so catching up with the chat... Sina, you posted some data on merklizing the contract codes? Sina: Yes, that is what it was doing: Simulating running mainnet blocks, merklizing the code into chunks and a trie, and comparing how much is the total amount of code you need in that block, comparing that total size to how many chunks you need to send, as well as all the hashes for the proof. And this a ballpark figure, but I found that maybe you can have 40-60% reduction in code size. But again this is early and I'd like to run more tests. P: No that's fine, we're just getting early numbers Rick Dudley: Silly question: can those hashes be used across addresses? Like if you have the same code with two different addresses can you reuse that hash? V: In a witness I don't see why not. P: Yeah I think all the overlapping intermediate hashes are deduplicated and merged together into just one big single witness. Sina: So with my approach each account, similar to having a storage trie, it would have a different trie for the code. But I think Martin was asking if there could be a global trie P: Oh, that's interesting. So you could take all the code chunks and put into one global code trie. V: one challenge with de-coupling code storage from accounts is that if we ever decided to do rent in the future then that would complicate things further because there would be conflicts with objects and confusion over those shared contract code instances. P: Yeah, so something to look into maybe... A: Yeah I'd also say that before we get excited with the dedublication we actually have to figure out whether its really beneficial or not. P: So looking at the numbers with those first two optimizations: Merklizing the code, and switching to binary tries, it gets proof sizes down to something like 400kb to 1.7mB. Based on rough numbers, but a starting point. So the other question out there is what are our bounds on this? What do we think the network can handle? Is that something being looked into? V: Just today starkware released a post where they basically repeated the same experiment that led to Istanbul, which was basically spamming the chain with a bunch of big call division data transactions, and because the gas costs are cheaper they went up to blocks of something like 1.4mB, along the same size as witnesses we are talking about, and uncle-rate-wise we saw basically nothing with the network. Which was actually kind of suprising, and it might suggest that we might want to not just look at uncle rates but also how non-mining clients download these things. MHS: Fun fact about that, is that me and Peter are also looking in to why 6 of 8 root nodes crashed on sunday, and we finally got an answer to that. But yeah, with these ballpark figures we have, it would be interesting to know what the ratio is between block versus witness, so that we can have an estimate. I'm curious about the ratio. V: So calldata does not have witness data, so the blocks that starkware produced, witness sizes would be basically zero on top of the block itself. P: But those tests are really just testing what happens when there is a big block, right? P: Ok, so next question, are we at a point when we want to talk about format? V: Ooooh, I would like to get a sense of how people feel about the progressive transition strategy that I was proposing, vs possible alternatives for moving from hexary to binary. P: I remember Alexey, your model was reliant on a flat database layout and a hard cutover A: Yeah, actually after talking to Vitalik I added this item (in the chat) to the research list https://ledgerwatch.github.io/Ethereum_1_Research_topics.html#Migration-from-hexary-to-binary-tries So basically what Vitalik is suggesting is that you could try to virtualize binary tries in the hexary tries, so that the transition would be less painful. There are two questions here. Whether we actually do migrate from the hex to binary, and the second question is how do we migrate. Do we migrate everything at once? Or do we have to do it incrimentally. And I thought about this...so we would basically recompute the entire state gradually over a period of lets say a couple of months, and then we switch when everybody is ready or we stop the chain for like an hour, to recompute it, or we do it gradually. And there are pros and cons for each of these strategies.... Like a big pro for incrimental is that you don't have to stop anything, but a con is that you have to keep the code for binary and hexary tries forever, maybe to validate old blocks. P: My inclination is towards the progressive strategy... mostly it just seems like the safest strategy. One it doesn't depend on a database layout.. which is important because it doesn't impose on clients... A: By progressive strategy, what do you mean? P: Vitalik's proposal. A: He was suggesting how you switch to binary tries without a flat structure. And I'm fine with that because it doesn't matter; I can implement it flat, others can do it without the structure. V: Well yeah, there were two ideas in there. One idea was doing a trie that's binary from a hash point of view on top of something that's hexary from a database point of view. And the other idea was basically you change the trie from hexary to binary one node at a time, and you move accounts from one to the other as each account is touched by VM execution. A: Yeah the first is something that's an implementation change/detail, which is good to have because then you know that everyone can switch. And the second is a change to the protocol. Which needs to be decided upon. Whether we want that mixture or not, or that gradual transition which will basically never complete.... V: We can do what we did with the Shanghai attacks... A: No you can't because part of the trie is untouchable V: Oh you mean contract internal storage, okay that's true P: Interesting... so we would need a way to solve that if we wanted to do the touching model... V: Realistically we could just add a "POKE" opcode.... P: So if we need to do the incrimental way we need a way to poke all the code of the state A: And something I don't like about that is that it's more complex, because you essentially have even more complex hashing rules in the state, because you have to account that part of the state is hexary, part is binary, and all that needs to be handled. R: Why can't the poke be done client side? P: The poking changes the state root, so it needs consensus on what was and wasn't poked. R: Doesn't that make going backwards a deal-breaker right? Isn't that what we're talking about? A: No we're doing two possible strategies: First: from block x, in say, 6 months time, we are switching to binary tries, and you need to be ready with a new binary state root ready for the swap in the hardfork Second: We start marking every account in each new account that has changed, and piece by piece change over as it's executed EVM RD: Can't it be precomputed? A: It's a moving target though. So you can't pre-compute in advance because it'll get out of date so fast. P: It doesn't sound like there is a way to do this all at once. Whatever we do it needs to be slow and gradual so that each client can do it on their own. So I think where we're at is we need to look at this problem more. We have two solutions that are sort of broken in some ways. The hard cut-over dictates database layout to some extent. A: Rather, the flat database layout can do it, but the naive db layout cannot do it. If you imagine this precomputation strategy, where in 6 months you need to have a binary trie, if you think not on a computer science level, but on a logistics level, people will upgrade at different times, and may only start computing one month or one week in advance. So it'll be really difficult to coordinate a precomputation. P: So essentially, there is a minimum amount of time that it'll take to precompute the new state... and thus any client that joins the network in less than that amount of time before the hardfork, will not be able to participate in the hardfork. ?: There's another way you could do it... you could start to compute the new trie as well as the old one, and gradually start to agree on the precomputation, and then at some point can switch. J.H: Just a note on the coordination side... what we've seen so far with hardforks is that exchanges like to update about an hour before, and miners like to update *right at the moment* RD: But if I'm not mistaken we're updating the state data, which has never been done before right? A: correct it's got a unique set of challenges M: If the majority clients can do a quick switchover, but for example other clients take 3 days to switchover... maybe that's ok A: Do you think it'd be possible to stop the chain for an amount of time and recompute in like an hour? J: I don't know if this works on a technical standpoint, but what if you had a hardfork that was 3 days before, that everyone needed to join... and then that would commit to a second hardfork... so you could get that exclusion zone, and make sure everyone's on the train before it departs the station. (mumbled agreement) M: We will be able to test this in practice, so I'll look into this and give you an exact number of how long it takes to generate the hexary trie from a snapshot. A: They do this with Cosmos, actually. So what they do is do the state snapshot, then they stop the chain for an hour or two, and then they all recompute, and then they start again. So it works for them apparently. RD: So they have some problems with rollback, but more importantly they have a social convention around that which we don't have (in Ethereum). P: So I'm going to try to pull this together, because it sounds like we just have an unanswered question, and need to think about this more and flesh out some more solid numbers. So that means what does it take to recompute the state, as well as how we can do an incremental update to the trie and what does that look like for clients. P: Let's talk about chunking accounts. Lots of discussion in the last couple days, so does anyone have something they want to jump in. A: Perhaps we can summarize: Started with Sina presenting data from a prototype, where he mentioned that he analyzes mainnet blocks... he takes the code, figures out where the jump destination points are (where they have a special instruction JUMPDEST), which marks valid jump destinations. If someone tries to jump to a not marked point it's basically failure. So he splits up the code using these jump points, and then makes them a bit larger, and uses a chunk size up to 128 bytes, then he merklizes them. So we discussed if that chunk size is optimal, you could use 32 bytes, or configurable, so we can play with this. Then I had the question if it makes more sense to use fixed size chunks instead of jump points. Apparently the issue here is that you can pretend that an incorrect execution was executed correctly.... because you have to know where the jumpdests are. So Martin proposed a solution to this using fixed-size chunks which adds some metadata to the chunk, which specifies where the correct jump destinations are within the chunk. This means we can always figure out if the jumpdest is correct or not. So yeah, you need a little bit of metadata, and you can have fixed metadata added to each chunk, and chunks of fixed size, and you can pack all that up. And I like this model because it makes the model less 'leaky', in terms of 'abstraction leaks', and I think we should try not to concentrate optimizations in a single layer. Then Christian suggested a slightly more complicated way of hashing, which is related to code execution, which is interesting. In this model the size of the proof will be propotional to the number of static jumps. And we also uncovered disallowing dynamic jumps actually might help in terms of optimizing the proof sizes, which is something I didn't think of before. So that' my summary P: I agree with you -- I was originally in the jumpdest camp -- but I like the idea of having fixed jump sizes and being explicit about embedding metadata. I don't fully understand Christian's proposal A: I can explain it briefly P: sure A: Ok so imagine that we have static jumps -- IDK how we predict them somehow -- we figure out all the points where the static jumps may exist (some are conditional), and then you make each of those jumps you create a node in your merkle trie/forest -- and that node includes the hash of the the point you are jumping to, and the code that is remaining... so whenever you jump, you create the witness on the fly, and you know which jumps were taken and which were not taken. So for the taken jumps, you add the hash of the code that was not taken after the jump. And so essentially the depth of your hash chain will be equal to the jumps taken. So with 5 jumps, you have 5 things in the hash chain. But if you take a dynamic jump, you have to prove it in a simlar way as before. So essentially you have two parallel hashings of the same code -- The full one will be only used for dynamic jumps or code copies. But you still need to determine which jumps are static and which are not -- but it's very interesting. V: I forget. I know we've explicitly defined a push followed by a jump is a static jump and other jumps are dynamic jumps, but I don't remember. Sina: It's possible to determine though V: The idea would be we'd just consider push jumps static A: But you could actually do symbolic execution and consider some jumps static even if they are not preceded by the push data V: But we're not going to shove a symbolic execution engine into the consensus layer :) A: haha, no. P: Ok so it sounds like we've got a good start here. Which is to simply merklize the code in some way, plus metadata, -- and some ideas for how we can make this all smaller, but those potentially require EVM improvements like restricting dynamic jumps. This has been suggested before as an EVM improvement. If someone is willing to make the case for this and say why it's worth it, and prove that we'll get the savings we expect, we can go that route, but I would suggest we default towards the simple solution just so that we don't have another major EVM change to put in there. Sina: Yes just to quickly add, among the simpler solutions martin suggested that with the chunking, we have a default chunking method, but we make it flexible on the client side... letting users specify chunking at deploy time. P: Another discussion worth having is any changes to gas scheduling that might need to account for the bytes actually used, which then I guess cascades into the ungas proposal. ?: I'm not convinced there needs to be changes. We don't need to change the gas costs for the operations, we just need to pay for the witness size. A: Who will pay for the witness size? The problem is that the witness is per block, and transactions are paid per transaction, so how are we going to split it up? ?: Don't charge for the overlap. charge for what ever part witness is generated. That's nice savings but no one collects it. V: The problem then is that you don't know what the witness is that a particular transaction demands until you run it P: Isn't that the case anyways? A: Yeah I think it's ok, you just specify the max gas you're willing to spend, and if that's not enough for the witness it doesn't get included. P: So let me clarify cuz I have a question: The idea is that the schedule of gas for a CALL opcode stays the same, but then the EVM semantics change so that as more code is loaded, more gas is spent from the available gas? And this would be a breaking change... A: it won't be a breaking change... I need to think about it a bit more but actually I quite like it. Because it means we will not need significant changes in the gas costs. If we do it as Brian and Martin suggested, by figuring out for each transaction what part of the state it has touched, including accounts and storage and code parts, and then we just charge for that, proportional to how much it would inflate the witness on its own, and then charge every transaction like this -- and then any overlap between transactions is extra for the miner. V: Wait, so this is basically saying that it's like a gas refund, except negative instead of positive? A: yes, I think so. M: Yeah, I like this. V: One challenge is that the current gas model is that you have the ability to make sub-calls and you only trust the sub calls with a portion of the total gas you commit, but if you allow transactions to go around randomly dynamically accessing stuff and costing arbitrary amounts of gas at the end, then we kind of lose that security model. P: Don't we already have that right now with dynamic SSTORE and SLOAD costs? A: as Josef was saying in the chat UNGAS fixes this. V: Yes, that's true. But basically we have to explicitly agree that we are ok with this breaking change to the security model... P: Ok so there's two things on the table here: UNGAS, which says that you can't do this inspection of gas. It's kind of its own proposal, and makes these other changes (that would be breaking) easier to do. V: quick question, sorry, if we UNGAS, then philosophically speaking, there's no difference between deducting gas up front or at the end A: Yes, exactly. That's exactly the point. It makes it much more flexible. V: So basically a negative refund and charging up front are the same... except in the case of refunds covering gas A: I think UNGAS will make a lot of the computation things much simpler, and will allow for some optimizations as well. V: Yeah that makes sense. ?: So question, you said that this would make charging at the beginning or end, but currently if you run out of gas, but have a refund pending, you'll revert... but in this case you would be able to get that transaction through... V: That's what I mentioned. And I also just realized one other difference, which is the 63/64 rule A: I think Wei commented specifically on that, but I don't remember what he said about it. P: Ok, I think I can circle this back together. So we have UNGAS, which is not essential for stateless ethereum, but it is an idea for how to make future breaking changes to gas schedules easier. There are open questions about implementation complexity -- I know that Alexey has expressed interested in a more formal EVM specification, to see if we can make a change like UNGAS -- this fits into that same category as the transaction propogation stuff discussed before, as in that it's not an explicit requirement for stateless ethereum but it is something that can make everything better. So the question we need an answer to is: Does UNGAS actually make this stuff easier? And to answer that we need to look at what it looks like without UNGAS, compared to what it looks like with it. So what we want to be doing is charging gas based on how much code you actually use. How big of a breaking change is that, and how much does it change EVM execution to do that? So that's stuff we need experiments for. Running these things with the code merklized, and running it with the gas rules applied and seeing how that would actually change the cost and execution in the EVM. So... anything else on meklizing contract code that people want to toss in? we are coming up on 20 minutes 'til the end of the call... A: So I think theres one more interesting thing in the chat. I think someone (Sina?) suggested that in the future the compilers might be able to optimize the bytecode layout so that it'd produce smaller witnesses. I think that these optimizations can be done for both jumpdest and fixed-size chunking. For this reason I think we should leave both chunking methods on the table. Sina: On this point I asked Christian about compiler optimizations, and he said he was hesitant to promise anything about these optimizations. So that remains to be seen. P: Ok I have one more topic to toss out there: Will, in the stuff that you posted on the pull model, there was mention of the kind of DHT routing and state providers. One of the problems I see coming with a network with the stateful core and stateless/semistatess edges... in theory all the nodes are participating in the Eth protocol, but they are not going to have things like historical chain data, or some of the recent state data... So this brings up the topic of chain pruning old blocks, transactions, receipts, accounts etc. Most of this is in some sense orthogonal to stateless Ethereum, but I think it's important, because we need a way for clients to signal what data they have. So one angle is that the clients need to easily signal what data they have in the network. So I think we need to pursue the chain pruning EIPs to allow clients to forget about this data -- which also allows for a stateless client that joins the network to just broadcast up front that they are not going to have that data. So that's problem #1, which is something that we can do right now. It's not a protocol-level change -- well, it's a networking protocol change but not a consensus change. It would allow clients to start forgetting that stuff as well as allowing clients to start broadcasting what data they actually have. The second side of this problem is that once we make changes to the Eth protocol that makes it so that not all clients are expected to have this historical data, we ideally want a place where clients can get this. And the best idea I have to fix this right now is to make that part of a distributed storage network... that's specific for the Eth data. I'm curious, does anyone know of anyone who has worked on this, or thought about it... like are there specs written, that sort of thing.. V: I remember seeing on twitter when I was talking to nethermind people... and I suggested for history storage that dumb approach where everyone just picks a random span of half a million blocks and store those... and they suggested that they have something in the works but I didn't follow up... Nethermind: Yeah I'm on the call. I know we were discussing some combination of contract and serving nodes for the distributed data... just for the data itself we can use the marketplace approach of what we have, but not necessarily all the security assumptions we would need for this particular topic. I can send some details on ethresearch and we can discuss. A: I have a comment: there are a couple of things that Peter from geth asked me to put on the research list which I did, which is storing state outside of the ethereum network. So I'm just going to post that into the chat. https://ledgerwatch.github.io/Ethereum_1_Research_topics.html#Storing-state-outside-of-Ethereum-network And another thing I put in there related to chain pruning is this.... another topic on research. So on the first thing, Peter told me in Osaka I think, is they did an experiment... basically if you split the current state into big enough chunks, you can actually store the state in cloudfare or something in such a way that you don't actually have to replace chunks that often -- I don't know what size he was using -- but it's possible to store them in such a way that someone can retrieve a fairly recent state out of there. And that goes back to something, Piper you might remember we discussed at the swarm summit back in Madrid, where the idea first was to store the state in swarm, where each node in the trie is the chunk in swarm. And originally I said it was too granular, and I think Peter was experimenting with was splitting the state into less granular chunks. Another thing I wanted to say was about chain pruning. I thought about it a little bit more. So you have two strategies here. You start embedding the information about what part of the state/chain you have already, and you either base your discovery on this information -- which I think is a bit brittle, you would have to surround yourself by the peers that actually have this information, and place yourself in the network there. And I don't like this approach because it is one of those cases of leaking abstraction... so you have to make the network look like the data -- another way is what swarm is doing, which is a data routing network. Which is that if you don't have the data, you route it further to someone else that does, and just return the result. So this is an experiment we've tried in turbogeth, where we want to support something like getNodeData... it's a primitive that we cannot serve ourselves, but we might be able to proxy it through, and act as a data delivery network so that if we can't serve the requested data, we can route it from somebody else, and smoothly integrate with the network M: If I can elaborate on what Alexey said... the geth experiment was with something called state tiling... so we chopped up the state trie into large enough tiles, which were 2-4 kilobytes each, I think... and in the experiments we did, we notice there are about 200 tiles that change with each block. The big idea behind this is that we could have one geth node serve an unlimited amount of LES nodes.... there would be not on-demand work done by the central node -- everything gets pushed out to a caching layer which only requests -- so the http layer basically can cache by hash for the tiles. https://gist.github.com/holiman/280f6b9a67230c2c93e17ab63b2a33fc Sam (quilt): This is really interesting. We're looking at some similar stuff for Eth2, specifically for getting state from a DHT or something similar. If you could send me anything you've written up I would love to take a look. M: Yeah it's not in a blogpost or anything, but I can send you implementations to do it, and also a consumer that reads from it and acts on it... I can send you the PRs... P: I've been tossing the idea of a secondary distributed storage network around in my head, and it certainly has some complexity that makes me nervous, but it also has a really nice property that I like, which is that it makes it so that all those lightweight nodes around the network have a job that they can do that they are well suited for, which would be just storing some data in memory, and listening to and responding to requests that come in for their part of the data/network. This is an un-fleshed-out idea, but the general problem still needs to be solved: we don't want nodes jocking for position in the network based on what kind of data they want to get... we want them to be able to just join the network wherever and be able to retrieve the data they need with some level of reliability. So I think that's a problem we keep looking at and trying to solve so that as we progress towards this new network that looks different from the current one we can still have a readily supported case where if you turn on a full node you don't have some crazy luck thing on whether or not you actually get the connections you need to sync the full state. Any additional things to toss in before we call it quits? J: Do we want an unofficial gathering at Stanford Blockchain week or ETHDenver? P: Yeah I think we can just organize ad-hoc J: If there are anyone going to the Stanford thing I can make that happen. So if you're going please reach out to James H. P: Ideally we'll get the next meeting earlier now, planning on one month out, so that we can get one more call mid-way between now and EthCC in march. So yeah. Unless anyone else has things to discuss, we'll call this meeting to a close, thanks!