solana/docs/src/proposals/rip-curl.md

RiP Curl: low-latency, transaction-oriented RPC

Problem

Solana's initial RPC implementation was created for the purpose of allowing users to confirm transactions that had just recently been sent to the cluster. It was designed with memory usage in mind such that any validator should be able to support the API without concern of DoS attacks.

Later down the line, it became desirable to use that same API to support the Solana explorer. The original design only supported minutes of history, so we changed it to instead store transaction statuses in a local RocksDB instance and offer days of history. We then extended that to 6 months via BigTable.

With each modification, the API became more suitable for applications serving static content and less appealing for transaction processing. The clients poll for transaction status instead of being notified, giving the false impression of higher confirmation times. Furthermore, what clients can poll for is limited, preventing them from making reasonable real-time decisions, such as recognizing a transaction is confirmed as soon as particular, trusted validators vote on it.

Proposed Solution

A web-friendly, transaction-oriented, streaming API built around the validator's ReplayStage.

Improved client experience:

• Support connections directly from WebAssembly apps.
• Clients can be notified of confirmation progress in real-time, including votes and voter stake weight.
• Clients can be notified when the heaviest fork changes, if it affects the transactions confirmation count.

Easier for validators to support:

• Each validator supports some number of concurrent connections and otherwise has no significant resource constraints.
• Transaction status is never stored in memory and cannot be polled for.
• Signatures are only stored in memory until the desired commitment level or until the blockhash expires, which ever is later.

How it works:

1. The client connects to a validator using a reliable communication channel, such as a web socket.
2. The validator registers the signature with ReplayStage.
3. The validator sends the transaction into the Gulf Stream and retries all known forks until the blockhash expires (not until the transaction is accepted on only the heaviest fork). If the blockhash expires, the signature is unregistered, the client is notified, and connection is closed.
4. As ReplayStage detects events affecting the transaction's status, it notifies the client in real-time.
5. After confirmation that the transaction is rooted (CommitmentLevel::Max), the signature is unregistered and the server closes the upstream channel.