Skip to content

docs(notar,tower): polish #8626

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lidatong wants to merge 1 commit into
base: main
Choose a base branch
from
+144 −178
Open

docs(notar,tower): polish #8626

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
28 changes: 22 additions & 6 deletions src/choreo/notar/fd_notar.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,12 +15,28 @@
further ahead slots can be cluster confirmed before they are
replayed.

On the similarities and differences between fd_ghost vs fd_notar:

The reason both fd_ghost and fd_notar exist even though they do
seemingly similar things (tracking vote stake on blocks) is because
Solana implements the rules quite differently.

On the similarities and differences between fd_ghost / fd_tower vs.
fd_notar:

The reason both fd_ghost / fd_tower and fd_notar exist even though
they do seemingly similar things (tracking vote stake on blocks) is
because Solana implements the rules quite differently.

At a high-level, fd_ghost / fd_tower is based on vote accounts vs.
fd_notar which is based on vote _transactions_. Everything in
fd_ghost / fd_tower is dependent on the vote account's state after
the vote txns have been replayed. So we only have stake information
in fd_ghost / fd_tower for a block, if that block has been replayed.

On the other hand, fd_notar processes vote transactions as they come
in from gossip and TPU, so it does not have this same requirement
that the block has been replayed. This is important, because block
transmission is unreliable, and notar provides a fallback mechanism
for detecting votes for blocks we don't have. fd_notar still ingests
replay votes as well, so it is guaranteed to be a superset of the
votes tracked by fd_ghost / fd_tower.
Comment on lines +36 to +37
Copy link

Copilot AI Mar 2, 2026

Choose a reason for hiding this comment

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

The comment says fd_notar is "guaranteed to be a superset" of votes tracked by fd_ghost/fd_tower. However, the current vote-txn ingestion path filters to TowerSync(Switch) only, so legacy/other vote instructions that still update the vote account could be reflected in fd_ghost/fd_tower but ignored by fd_notar. Consider softening this claim (e.g., "intended to be" / "for TowerSync votes"), or explicitly stating the assumption that only TowerSync(Switch) votes are supported/tracked here.

Suggested change
replay votes as well, so it is guaranteed to be a superset of the
votes tracked by fd_ghost / fd_tower.
replay votes as well, so it is intended to be a superset of the
TowerSync(Switch) votes tracked by fd_ghost / fd_tower, assuming only
TowerSync(Switch) vote instructions are supported/tracked here.

Copilot uses AI. Check for mistakes.

There are also differences in how votes are counted between the two.
In fd_ghost, we use the GHOST rule to recursively sum the stake of
the subtree (a slot and all its descendants). The LMD rule counts a
validator's stake to at most one fork. When the validator switches
Expand Down
Loading
Loading