34 lines
2.3 KiB
Markdown
34 lines
2.3 KiB
Markdown
# RiP Curl：低延迟，面向事务的RPC
|
||
|
||
## 面临的问题
|
||
|
||
创建Solana的初始RPC实现是为了让用户确认最近刚发送到集群的交易。 在设计时就考虑到了它的内存使用情况，因此任何验证节点都应该能够支持API，而不必担心DoS攻击。
|
||
|
||
后来，使用相同的API来支持Solana浏览器变得很必要。 原始设计仅支持几分钟的历史记录，因此我们将其更改为改为将事务状态存储在本地RocksDB实例中，并提供长达几天的历史记录。 然后，我们通过BigTable将其扩展到六个月。
|
||
|
||
每次修改都让API变得更适合于提供静态内容的应用程序，并且对交易处理的吸引力降低了。 客户轮询交易状态而不是被通知，会给人一种错误的印象，即确认时间更长。 此外，客户可以轮询的内容是有限的，这会阻止他们做出合理的实时决策，例如，一旦特定的、受信任的验证者对其进行投票，便确认了交易。
|
||
|
||
## 拟定的解决方案
|
||
|
||
基于验证者的ReplayStage，构建一个网络友好、面向事务的流式API。
|
||
|
||
改善客户体验：
|
||
|
||
* 直接从WebAssembly应用程序支持连接。
|
||
* 可以实时向客户通知确认进度，包括投票和投票者质押权重。
|
||
* 当占比最重的分叉发生变化，如果它会影响交易确认计数，则会通知客户。
|
||
|
||
对验证节点的支持更加简单：
|
||
|
||
* 每个验证节点支持一定数量的并发连接，否则没有明显的资源限制。
|
||
* 交易状态永远不会存储在内存中，因此无法进行轮询。
|
||
* 签名仅存储在内存中，直到所需的承诺级别或直到区块哈希过期为止（以较晚的日期为准）。
|
||
|
||
工作原理：
|
||
|
||
1. 客户端使用可靠的通信通道（例如Web socket）连接到验证节点。
|
||
2. 验证节点使用ReplayStage注册签名。
|
||
3. 验证程序将交易发送到Gulf Stream，并重试所有已知的派生，直到区块哈希过期(直到仅在最长的分叉上接受交易为止)。 如果区块哈希过期，则签名未注册，通知客户端，并关闭连接。
|
||
4. 当ReplayStage检测到影响交易状态的事件时，它将实时通知客户端。
|
||
5. 确认交易已植根后 (`CommitmentLevel::Max`)，签名则未注册，服务器关闭上游通道。
|