Skip to main content

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),签名则未注册,服务器关闭上游通道。