Optimistic transaction propagation signal doc #20283
This commit is contained in:
parent
55d19e61da
commit
221b0f6841
|
@ -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
|
||||
|
||||
`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
|
||||
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
|
||||
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
|
Loading…
Reference in New Issue