10 个稳定版本

2.0.3 2020年3月16日
2.0.2 2019年10月24日
2.0.1 2019年9月11日
2.0.0 2019年3月28日
1.9.0 2018年1月30日

#2956 in 魔法豆

Download history 61/week @ 2024-03-11 56/week @ 2024-03-18 10/week @ 2024-03-25 92/week @ 2024-04-01 71/week @ 2024-04-08 50/week @ 2024-04-15 59/week @ 2024-04-22 12/week @ 2024-04-29 28/week @ 2024-05-06 29/week @ 2024-05-13 22/week @ 2024-05-20 49/week @ 2024-05-27 27/week @ 2024-06-03 14/week @ 2024-06-10 41/week @ 2024-06-17 14/week @ 2024-06-24

100 每月下载量
用于 25 个crate(直接使用2个)

MIT/Apache

75KB
1.5K SLoC

Continuous integration

parity-common

Parity Technologies 项目中使用的crate集合


lib.rs:

通用交易池

Ethereum交易池的一个可扩展且高效的实现。池根据某些可插拔的 Scoring 实现存储已排序、验证的交易。池还允许你根据某些 Readiness(可插拔)的概念构造一组 pending 交易。

池对交易是通用的,不应对其做出任何假设。我们能依赖的只有定义

  • 单个发送者交易排序的 Scoring
  • 与不同发送者交易相比,交易的优先级

注意:单个发送者的交易不是按优先级排序的,但在构建pending集合时,我们仍然需要保持排序(即 txs[1] 总是需要在 txs[0] 之后包含,即使它的优先级更高)

设计细节

性能假设

  • 处理数万笔交易的可能性
  • 快速插入和替换 O(per-sender + log(senders))
  • 合理快速的停滞交易移除 O(per-sender)
  • 合理快速的挂起集合构建 O(txs * (log(senders) + log(per-sender))

通过牺牲一些内存来提高移除性能。目前使用 SmallVec 存储发送者的交易,而我们可以使用 VecDeque 并有效地 pop_front 最佳交易。

可以通过引入一个名为 nonce 的概念来降低挂起集合构建和插入的复杂度——一个交易的绝对、数值排序。我们不这么做,因为 EIP208 可能会有影响,其中 nonce 可能不可用。

  1. 池将特定发送者的交易分组在一起,并按组内的 Scoring 排序存储,即 HashMap<Sender, Vec<Transaction>>
  2. 此外,我们还维护每个发送者的最佳和最差交易(通过 Scoring 而不是 priority)并按 priority 排序。这意味着我们可以轻松地识别整个池中的最佳交易和最差交易。
  3. 每当新交易插入队列时
    • 首先检查所有限制(总体、内存、每个发送者)
    • 检索所有来自发送者的交易
    • 二分搜索插入交易的位置
    • 决定是否替换现有交易(3种结果:删除、替换、插入)
    • 如果受影响,则更新该发送者的最佳和最差交易
  4. 挂起列表构建
    • 将所有发送者的最佳交易(按优先级)添加到列表中
    • 用该发送者的下一个交易(按顺序)替换交易(如果有)
    • 重复

依赖关系

~215KB