-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Optimistic transaction propagation signal doc #20283
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,109 @@ | ||
| --- | ||
| title: Optimistic Transaction Propagation Signal | ||
| --- | ||
|
|
||
| ## Current Retransmit behavior | ||
|
|
||
| The retransmission tree currently considers: | ||
| 1. epoch staked nodes | ||
| 2. tvu peers (filtered by contact info and shred version) | ||
| 3. current validator | ||
|
|
||
| concatenating (1), (2), and (3) | ||
| deduplicating this list of entries by pubkey favoring entries with contact info | ||
| filtering this list by entries with contact info | ||
|
|
||
| This list is then is randomly shuffled by stake weight. | ||
|
|
||
| Shreds are then retransmitted to up to FANOUT neighbors and up to FANOUT | ||
| children. | ||
|
|
||
| ## Deterministic retransmission tree | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I do already have some draft code related to this part. That was actually the motivation of adding
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Cool, if you already have changes which would separate the retransmission into a deterministic set from the epoch staked nodes that sounds great.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. #20480 |
||
|
|
||
| `weighted_shuffle` will use a deterministic seed when | ||
| `enable_deterministic_seed` has been enabled based on the triple (shred slot, | ||
| shred index, leader pubkey): | ||
|
|
||
| ``` | ||
| if enable_deterministic_seed(self.slot(), root_bank) { | ||
| hashv(&[ | ||
| &self.slot().to_le_bytes(), | ||
| &self.index().to_le_bytes(), | ||
| &leader_pubkey.to_bytes(), | ||
| ]) | ||
| ``` | ||
|
|
||
| First, only epoch staked nodes will be considered regardless of presence of | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This change will need to be coordinated with some of the RPC providers so that their nodes aren't cut off.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
| contact info (and possibly including the validator node itself). | ||
|
|
||
| A deterministic ordering of the epoch staked nodes will be created based on the | ||
| derministic shred seed using weighted_shuffle. | ||
|
|
||
| Let `neighbor_set` be selected from up to FANOUT neighbors of the current node. | ||
| Let `child_set` be selected from up to FANOUT children of the current node. | ||
|
|
||
| Filter `neighbor_set` by contact info. | ||
| Filter `child_set` by contact info. | ||
|
|
||
| Let `epoch_set` be the union of `neighbor_set` and `child_set`. | ||
|
|
||
| Let `remaining_set` be all other nodes with contact info not contained in | ||
| `epoch_set`. | ||
|
|
||
| If `epoch_set.len < 2*FANOUT` then we may randomly select up to | ||
| `2*FANOUT - epoch_set.len` nodes to to retransmit to from `remaining_set`. | ||
|
|
||
| ## Receiving retransmitted shred | ||
|
|
||
| If the current validator node is not in the set of epoch staked nodes for the | ||
| shred epoch then no early retransmission information can be obtained. | ||
|
|
||
| Compute the deterministic shred seed. | ||
|
|
||
| Run the deterministic epoch_stakes shuffle. | ||
|
|
||
| Find position of self in the neighbor or child sets. | ||
|
|
||
| Calculate the sum of the stakes of all nodes in the current and prior | ||
| distribution levels. | ||
|
|
||
| ### Stake summation considerations: | ||
|
|
||
| - Stake sum could include stakes of nodes which had been skipped in prior | ||
| distribution levels because of lack of contact info. | ||
| - Current node was part of original epoch staked shuffle from retransmitter | ||
| but was filtered out because of missing contact info. Current node subsequently | ||
| receives retransmisison of shred and assumes that the retransmit was a result | ||
| of the deterministic tree calculation and not from subsequent random selection. | ||
| This should be benign because the current node will underestimate prior stake | ||
| weight in the retransmission tree. | ||
|
|
||
| ### General considerations: | ||
|
|
||
| attack by leader (level 0): | ||
| - transmits shred for distribution through the tree as normal | ||
| - additionally transmits shred (or fake shred) directly to node(s) at level >=2 | ||
| leading the node(s) to believe a greater percentage of the tree retransmission | ||
| tree had been processed | ||
|
|
||
| attack by node at level n: | ||
| - retransmits shred to node(s) at level >=n+2 leading the node(s) to believe a | ||
| greater percentage of the tree retransmission tree had been processed | ||
|
|
||
| ### Questions | ||
|
|
||
| - Should receiving nodes attempt to verify that the origin of the shred was | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 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?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we can add signatures on hops sometime later. I think initially I am fine with
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
| retransmitted from the expected node? If so, consideration of spoofing? | ||
| - How is this information consumed? | ||
|
|
||
| ## Notes | ||
|
|
||
| Practically, signals should fall into the following buckets: | ||
| 1. current leader (can signal layer 1 when broadcast is sent) | ||
| 2. layer 1 | ||
| 1.1. can signal layer 1 when shred is received | ||
| 1.2. can signal layer 1 + subset of layer 2 when retransmit is sent | ||
| 3. layer 2 | ||
| 3.1. can signal layer 2 when shred is received | ||
| 3.2. can signal layer 2 + subset of layer 3 when retrnasmit is sent | ||
| 4. current node not a member of epoch staked nodes, no signal can be sent | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intention is to expose some new commitment level like confirmed/processed to indicate some level of distribution across staked nodes.