Skip to content

Fix probable grammar error in Gulf stream media post #983

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
GCrispino wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Fix probable grammar error in Gulf stream media post #983

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
2 changes: 1 addition & 1 deletion ...nt/posts/gulf-stream--solana-s-mempool-less-transaction-forwarding-protocol.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -83,7 +83,7 @@ When the benchmark client starts generating 100,000 transactions per second, the

Our solution to this problem on the Solana network is to push transaction caching and forwarding to the edge of the network. We call it **Gulf Stream.** Since every validator knows the order of upcoming leaders, clients and validators forward transactions to the expected leader ahead of time. This allows validators to execute transactions ahead of time, reduce confirmation times, switch leaders faster, and reduce the memory pressure on validators from the unconfirmed transaction pool. This solution is not possible in networks that have a non-deterministic leader

So how does it work? Clients, such as wallets, sign transactions that reference a specific block-hash. Clients select a fairly recent block-hash that has been fully confirmed by the network. Blocks are proposed roughly every 800ms, and require an exponentially increasing timeout to unroll with every additional block. Using our default timeout curve, a fully confirmed block-hashes are, in the worst case, 32 blocks old. The transaction is valid only in the children of the referenced block, and is only valid for X blocks. While X is not yet finalized, we expect that a block-hash has a TTL (time to live) of about 32 blocks. Assuming block times of 800 ms, that equates to 24 seconds.
So how does it work? Clients, such as wallets, sign transactions that reference a specific block-hash. Clients select a fairly recent block-hash that has been fully confirmed by the network. Blocks are proposed roughly every 800ms, and require an exponentially increasing timeout to unroll with every additional block. Using our default timeout curve, fully confirmed block-hashes are, in the worst case, 32 blocks old. The transaction is valid only in the children of the referenced block, and is only valid for X blocks. While X is not yet finalized, we expect that a block-hash has a TTL (time to live) of about 32 blocks. Assuming block times of 800 ms, that equates to 24 seconds.

Once a transaction is forwarded to any validator, the validator forwards it to one of the upcoming leaders. Clients can subscribe to transaction confirmations from validators. Clients know that a block-hash expires in a finite period of time, or the transaction is confirmed by the network. This allows clients to sign transactions that are guaranteed to execute or fail. Once the network moves past the rollback point such that the blockhash the transaction reference has expired, clients have a guarantee that the transaction is now invalid and will never be executed on chain.

Expand Down