## Eth 1x call \#2

17 December 2019

-- Call will be recorded but not posted publicly -- ask Piper if you'd like a copy

Piper - welcome, this call and group is primarily focused on stateless client research, but if other topics are relevant, they are welcome to be discussed in these channels (ethresear.ch, telegram, etc)

### Agenda

* "shades of statefulness"
* Rough roadmap
* More detailed discussion around witnesses, and more technical things

Piper: In the last call, I requested that teams put forth some dedicated resources for these efforts, so if you need help with those efforts reach out to me and I can help.

We're also looking to organize an in-person meetup after EthCC in Paris March (through the 5th), tentatively on the 6th-8th -- Consensys has offered office space

Guilherme -- France is currently on strike... we might want a backup plan since it's looking like it's going to last a long time.

### Statefullness

It is okay to have expectations on service providers, who are also compensating them.

Defining what we're working on.

The ideal case is moving toward a 'fully stateless' protocol, with clients and even miners are stateless

Alexey: I would object that miners should be stateless... this isn't what I would suggest or endorse

Piper: This is where we need to get to in the Eth2.0 context

Alexey: I think this is something that will derail our efforts because it'll distract everyone. We shouldn't even touch Eth2.0 until much latA er

Piper: I agree. That's a long way off, and

Alexey: Yes, the danger is that we become yet another Eth2.0 research group, and stateless miners is too close to that. We created this group to distinguish from those efforts. But that's my personal opinion.

Piper: So what's the goal in your perspective?

Alexey: To create a pretty long runway for Eth1.x -- and I think sustainability is a good word here. We want to keep people like miners engaged around.

Piper: So re-phrasing there are players in the network that need to have expensive hardware and profit motives, and these are a subset that can still maintain a full state and are intrisicly motivated to keep that. But for the rest of the entire network, state is optional.

Danny: Yeah that seems like the right direction, we want to tightly couple incentives for things like witnesses and validators

In the context of eth2 it's not worth targeting that full stateless ideal right now.

Rick: I'm in favor of this being a seperate protocol for some time because I'm concerned with applications and app developers. We should be able to have apps track the state that they want to track, and not just gossip full blocks.

Piper: I think this lines up, with everyone having a choice about where on the stateless spectrum you fall. There's just one state, and people should be able to just track the parts of state that we want.

We'll distil this down after the call for tangible notse

Joseph Delong: We want the throughput of the network to remain the same with these changes, too.

Alexey: the main benefit of stateless ethereum is that it doesn't change the paradigm for smart contract developers.

So it might change prices for users, but it won't change things for developers.

Piper: Question: under what we're talking about, if we still expect miners to be stateful, it seems like there's some merit to the idea that witness sizes won't affect block propogation

Danny: They don't affect the block propogation, but it does affect the network performance

Piper:

Rick: We want sort of a different subscription model for witnesses than we do for blocks.

Piper: since the choice of how stateless you are is a choice, it feels like we have a good degree of freedom here. We don't have to come out of the gate with a bullet-proff solution for witnesses. We can get something out sooner that doesn't necessarily solve the problems with larger witnesses. It may be that the more stateless you go, the harder it is to sync, or there might be errors.

Alexy: When we started to talk about incentives... why would a miner provide witnesses? I proposed that we change the propogation rules for blocks. The current rule is that the node checks proof of work and passes the block on without running it. But this removes the incentives for the miners to include the witness. So when we bring this back, we need to change that rule back to getting the block, veryifying the witness, and then you pass it on. The crux here is that you stop propogating blocks without witnesses, and this closes the incentive loop. So it remains to be seen

Marting Holst: Witnesses need to be included in the blocks then, or alongside, but doesn't that create the same problem?

Alexey:

Ratan: Are the miners then not incentivised to keep the most stateful clients as their connected nodes?
Piper: the witness sizes get larger the further out into the stateless edges you get, while you have full stateful nodes in the center

Alexey: Yeah, the ideal network would organize out into a stateless periphery, and we hope that those nodes out there would be able to swarm the witnesses better.

Rick: If you are a full stateless client and you want the full state, you might get n-6 or n-12

Ratan: This might also help with the uncle rate...

Alexey: IDK, I haven't thought about uncle rate too much.

John: So more statelessness means greater latency.

Alexy/Rick: Yeah, it's a weak assumption but that's the idea.

Piper: Yeah, the closer to the state center, the more up-to-date you'd get. Which is not necessarily a problem, I don't think...

Piper: so this helps us thing about our target. In these early stages, we don't need to target a fully stateless network at the edge. It's ok to deliver something in the near future that works toward that.

Alexey: One suggestion I have: Our plan is to introduce redqueen/firehose, and I really want to make sure that the format is the same format that stateless ethereum uses for witnesses. So if you're syncing, you do 2 protocols at the same time: you get your witnesses from peers, and secondly, you get chunks of state. So none of the data ends up stale, because it's packaged up with the witnesses. So this is my idea that we can sort of fuze these two together.

Piper: So the idea here is that the delivery format for witness data follows the same format as redqueen/firehose

Alexey: yeah, because the witness data specifies a forest of tries, and what red queen asks for is the subtrie of state, so the format is the same.

Ratan: Why would any node connect with any less stateful node? isn't this going to result in some sort of a tragedy of the commons?

Alexy: No miners can't connect to the whole network

Piper: So everyone wants to connect to a more stateful node, and less stateful nodes are less preferential

Alexey: I think this only matters if you really need a low latency

Piper: I think while people will prefer fully stateful nodes, they won't have the option to connect to only stateful nodes, because if you can't pass your blocks on to (less stateful nodes), your blocks are not going to propogate and won't be profitable.

Rick: We're in a weird situation in which we're discussing 'why do miners broadcast witnesses'? And I think that they won't, it's just that whomever is on the other side of that witness gap will have to pay the price.

brian: ... spoke very fast and connection cut out..
The rational thing to do re transaction prop, for instance, is to not forward the transactions you hear about, as a miner, and that way only you will be able to mine them. But, that doesn't happen! The network is already largely altruistic, so it seems like as long as building witnesses isn't unduely expensive it might not need any incentivization.

Alexey: the reason we have to change the rules for propogation is that miners care just about block propogation, and if people propogate without miner's incentive, they won't include witnesses. For non-mining nodes, it's just beneficial to them to have witnesses, so that they don't have to go fishing for state, and that's enough of an incentive for them. You don't need to keep a ton of state in memory. A lot of nodes would benefit from witnesses.

Piper: ok let's put some bounds on this conversation cuz we've hit some good observations and I think now it's important to start documenting this and compiling a more distiled roadmap, and we can start breaking this down into milestones.

Should we create something like an ETH2 specs repo so that we can write this down and discuss in a public central place in the future.

Alexey: I think it's a bit too early for specs at this point. But my team is planning to work on just a block witness specification. I just don't want to be distracted by this other stuff while we're working on this.

Piper: ok, so shades of statefulness, witness propogation. What can we deliver on the 3-6 months timeline? One thing we've talked about is changing regular Eth protocol to change tx propogation protocol to do just hashes instead. Is there anything else

Vitalik: What's the status of other clients adopting beam sync?

Pegasus/Besu has something prototyped but not ready yet

Tomasz: Do we have updated specs for metawitness propogation?

Piper: it's in a working branch but we don't have anything written down at the moment.

Jason: Yeah, nothing written down

Tomasz: yeah, so this is a small thing that would really speed up the dev process: a common test spec for witnesses and beam sync.

** people agree **

Piper: are there any other clients on the call that have questions or want to comment?

Alexy: it's not impementable for turbo-geth

Piper: The stuff with meta witnesses will make it workable

MArtin: geth does not have a plan to implement beam-sync -- however, hive now supports different kinds of test cases. Hive can spin up geth and another client and verify if it works... so I think that would be valuable for testing beam-sync with multiple clients

Piper: Great, yes, that's on our radar. Trinity is focusing on march shipment for everything in beam sync fully working. And we're working on a spec for a sub-protocol. We should start having real witness data propogating around by end of Q2

Alexey: as I said beam sync is un-implementable, but we want to have a witness structure implemented by next year. We can't do beamsync using `getNodeData` in turbo-geth, but we could do it with redqueen

So eventually, redqueen will be fused with beam sync, and it'll essentially be the same thing.

But importantly we want to change the witness format so that we can formally define the semantics of the witness, and this would be enough to collapse the firehose spec into a much shorter document, because there is just one thing, rather than like 4-5 different things.

Piper: and there is a huge benefit to getting alternative methods to fetching state.

Question: at what point does it makes sense to start testing cross-client?

Piper: are there more topics that people want to bring up

Alexey: There are two roadmaps that I think about: research, and implementation. The research ends when we've thought about witness formation, incentives, gas costs, etc. However, this doesn't resolve the problems of gas costs and such. That's where I go into the implementation roadmap, which is much less certain, and from my perspective is much harder. My conviction at the moment is that we have to go the road of 'ungas' (This make gas unobservable to the smart contract.)

Binary trie would allow us to halve the size of the full witness, but that's a whole other issue because if we change that basically every client will need to become like turbo-geth

Wei: I don't think ungas is actually a really big change. There are only a handful of opcodes that need to change. The specification is actually really simple, and I'll post it -- but I'm trying to say this isn't a complicated change. It'll just have effects like changing the solidity compiler and other things.

Alexey: Yeah, I'm looking at it in the broader scope, but it's coupled to so many things that make it complex, and it's going to be harder than just

Wei: account versioning, subcodes, and ungas -- these are just the 3 changes, it's not too complicated.

Piper: So my takaway is that looking at these ungas changes should be looked into sooner than later. So that's actionable: we need to validate assumptions and look more at this ungas research.

floor's open...

Paul: is anyone working on mempool tricks? Helping to propogate witnesses ahead of time, or optimize witness propogation...

Piper: the idea is that we do on-demand state-fetching based on what's in the mempool, and can warm up the needed state. Is that the idea?

Paul: Yeah, and rectification of witnesses. Wondering if there are any breakthroughs there.

Piper: So, next call will be tentatively the first or second week of January. Similarly, we'll get a thread started on our in-person meeting, and figuring out location.

Also if anyone wants to come to ETHDenver, I'll be around -- this isn't a formal meeting but I encourage you to consider coming. Also the Stanford blockchain week is the following week.

Also we are trying to boost the marketing a bit, so please let me know or speak up if you could present some of these ideas to the wider ethereum community..

Update Community