Optimistic transaction propagation signal doc

[jbiseda]

Problem

See #17439

Summary of Changes

Fixes #

[carllin]

This change will need to be coordinated with some of the RPC providers so that their nodes aren't cut off.

[jbiseda]

I don't think this would substantially change the shred distribution to non-staked nodes. It would mostly change the behavior to staked nodes before the next epoch. I'm proposing that we still distribute shreds to other nodes, they just fall outside of the first pass of the calculation which would become deterministic.

[carllin]

Ah, this is only necessary once a a validator needs to infer from receiving the shred some confidence in the path it went through? Without that need, it doesn't seem like a validator in turbine really cares about where it got the shred from, they just need to decide from the shred seed whether to retransmit the shred.

Could you add a section describing what sort of guarantees we're trying to infer from receiving shreds over turbine? I.e. if we receive X shreds via turbine, what can we deduce about the % confidence that the rest of the network will also get this block, and what is the justification (some quick maths/probability calculation) about why this is the case?

[jbiseda]

Yeah, checking the packet source address would be more of a sanity check as it wouldn't prevent spoofing. It's not required for expected operation of the retransmission.

Any signal that would be generated would be advisory. This would indicate the following: if the network is following the above retransmission algorithm then when the current shred was received by this node it should also have been attempted to have been sent to nodes covering X stake.

I think a stronger statement would require additional inter-node communication (like some random sampling of nodes that are also expected to have received the shred for confirmation). @aeyakovenko what level of confidence did you have in mind?

[aeyakovenko]

we can add signatures on hops sometime later. I think initially I am fine with

1. assuming UDP spoofing isn't an issue
2. adding private p2p ports between any two nodes on the network, which would make it hard to do 1
3. aggregated signatures on hops with BLS (but that will take a while to ship)

[jbiseda]

Something else we could consider would be to perform the stake distribution calculation on the client side. The validator transmission is made deterministic and the validator simply exposes whether it has received a shred. The client can then perform the stake distribution calculation using validator responses from one or more nodes depending on the client confidence requirements. This would let the client select how much sampling is required for its use case and would offload calculation overhead to the client.

[behzadnouri]

I do already have some draft code related to this part. That was actually the motivation of adding ClusterNodes and ClusterNodesCache, so that I can make this change. I can tidy that out and send that as a pull-request.

[jbiseda]

Cool, if you already have changes which would separate the retransmission into a deterministic set from the epoch staked nodes that sounds great.

[behzadnouri]

#20480
the goal was to reduce reliance on gossip, and impact of unstaked nodes joining and leaving cluster.
but it also makes turbine peers deterministic given the set of staked nodes.

[behzadnouri]

I think the document could expand with more detail on how (after retransmit stage) we will infer "Optimistic Execution" for shreds, and what would happen then.

[jbiseda]

The intention is to expose some new commitment level like confirmed/processed to indicate some level of distribution across staked nodes.

[aeyakovenko]

I think it's fairly close to the right thing. it will take some iteration on the implementation to figure out though