Skip to content
This repository was archived by the owner on Jan 22, 2025. It is now read-only.
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
109 changes: 109 additions & 0 deletions docs/src/proposals/optimistic-transaction-propagation-signal.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,109 @@
---
title: Optimistic Transaction Propagation Signal
Copy link
Copy Markdown
Contributor

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.

Copy link
Copy Markdown
Contributor Author

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.

---

## 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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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 ClusterNodes and ClusterNodesCache, so that I can make this change. I can tidy that out and send that as a pull-request.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#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.


`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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The 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
Copy link
Copy Markdown
Contributor

@carllin carllin Sep 28, 2021

Choose a reason for hiding this comment

The 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 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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The 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 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?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The 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

  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)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The 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