Tendex 在数字资产领域：交易基础设施、做市与 RPC 可靠性

范围：本文涵盖的是哪个 Tendex

tendex 一词出现在多个互不相关的语境中：天体物理学中的黑洞可视化概念、篮球效率公式、B2B 销售平台、可穿戴外骨骼品牌，以及一家瑞士数字资产交易公司。本文仅涵盖数字资产交易语境，其中 tendex 指的是一家总部位于瑞士的资产管理公司和做市商，为加密市场构建专有的订单与执行管理系统。

该公司的公开材料描述了三个产品领域：为特定合作伙伴提供做市和流动性供给、一只市场中性量化基金，以及定制策略实施。材料还描述了旨在跨多个交易场所和产品类型以最优可得价格完成交易的订单与执行管理系统。这些是关于该公司自身技术栈的已记录声明，而非你可以从外部验证的基准。

本文不复制专有业绩数据、基金回报或交易场所列表。相反，它解释此类技术栈所隐含的基础设施模式，并为你提供一套可复现的方法，用于衡量你可控的部分，尤其是 RPC 可靠性。

• 涵盖：作为数字资产交易与做市运营方的 tendex。
• 不涵盖：天体物理学中的 tendex 概念、篮球 Tendex 统计、B2B 销售平台或外骨骼品牌。
• 已记录的行为与建议以及你必须自行运行的测量是分开的。

前提条件与假设

以下流程假设你具备 HTTP API 的工作知识、拥有带 curl 的 shell，以及 Node.js 或 Python（用于较长的脚本）。你需要至少一个你有权查询的 RPC 端点，此处表示为 RPC_URL。如果你是在评估供应商而非单个端点，请收集多个候选 URL，并对每个 URL 运行相同流程。

你还应了解你的策略实际依赖哪条链以及哪些方法。一个仅从中心化交易场所读取价格的做市系统，与一个在链上结算、监控内存池或提交交易的系统，其 RPC 需求截然不同。在测量任何内容之前，请写下你调用的方法以及每个方法的延迟预算。

最后，假设任何单个端点都可能失败。该测量流程旨在暴露故障模式，而非证明某个端点完美无缺。

思维模型：RPC 在交易技术栈中的位置

数字资产交易技术栈通常有四层：市场数据摄取、策略与风险、订单与执行管理，以及结算或托管。RPC 节点位于策略层与链之间的边界。它们提供余额、nonce 和合约状态等读取服务，并中继已签名交易等写入操作。

对于做市商而言，关键路径通常是延迟敏感的读取和可靠的写入。过时的余额读取可能导致订单被拒绝；延迟的交易广播可能导致以非预期价格成交；nonce 不匹配可能使整个账户停滞。对于市场中性基金而言，关键路径通常是跨交易场所和工具的一致性，因此将链上状态与链下头寸对账的能力比原始吞吐量更重要。

实际含义是，RPC 可靠性不是一个单一数字。它是延迟、错误率、一致性以及在你的策略所使用的特定方法组合下的恢复行为的综合画像。

• 读取密集型策略关注延迟百分位数和缓存新鲜度。
• 写入密集型策略关注广播成功率、nonce 处理和替换行为。
• 跨交易场所策略关注链上状态与交易场所状态之间的一致性。

Tendex 已记录的能力与你自己的测量

关于 tendex 的公开描述强调专有的订单与执行管理系统、允许跨多种工具类型报价的集成，以及其投资产品内部使用的工具。这些是关于该公司内部技术栈的陈述。它们不会告诉你你将看到什么延迟、什么错误率可接受，或哪个 RPC 供应商将为你的策略提供服务。

将已记录的能力视为你可能构建的架构的背景，而非关于你自己环境的证据。真正重要的测量是你使用自己的方法组合和流量特征针对自己的端点运行的测量。

下表是一个模板。用你自己运行得到的值填充它；不要从任何文章（包括本文）复制数字。

• 已记录：专有 OEMS、多场所报价、市场中性基金、定制策略。
• 建议：按方法衡量延迟百分位数、错误率和一致性。
• 由你测量：结果表中的所有数值。

RPC 评估结果表模板

使用如下 Markdown 表格记录结果。在一天中的不同时段对每个方法至少运行数百次，并记录 p50、p95 和 p99 延迟、错误率以及任何一致性失败。在有真实数据之前，将单元格留空。

| 端点 | 方法 | 样本数 | p50 (ms) | p95 (ms) | p99 (ms) | 错误率 | 一致性失败 |

| --- | --- | --- | --- | --- | --- | --- | --- |

| RPC_URL_A | eth_getBalance | | | | | | |

| RPC_URL_A | eth_sendRawTransaction | | | | | | |

| RPC_URL_B | eth_getBalance | | | | | | |

| RPC_URL_B | eth_sendRawTransaction | | | | | | |

一致性列用于记录以下情况：在短时间窗口内对同一状态的两次读取返回不同结果，或交易被接受但在合理延迟后仍不可见。对于执行系统而言，这些失败比平均延迟更重要。

可运行诊断：使用 curl 测量延迟和错误率

从一个简单的循环开始，测量某个读取方法的往返时间和 HTTP 状态。这让你无需任何依赖即可获得延迟和错误率的一阶视图。

对每个候选端点运行它并保存输出。下面的脚本使用占位符 RPC_URL 和针对 eth_blockNumber 的 JSON-RPC 负载，该方法开销低且被广泛支持。

for i in $(seq 1 50); do
  start=$(date +%s%3N)
  status=$(curl -s -o /tmp/rpc_out.json -w "%{http_code}" \
    -X POST "$RPC_URL" \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}')
  end=$(date +%s%3N)
  echo "$i $status $((end-start))"
done

可运行诊断：使用 Python 计算百分位数和一致性

curl 循环为你提供原始样本。一个简短的 Python 脚本将它们转换为百分位数，并通过比较对同一区块的重复读取来检查一致性。这是你应该根据自己方法组合进行调整的流程。

下面的脚本仅使用标准库加上 requests。替换 RPC_URL 并调整方法列表以匹配你的策略。将输出记录到上面的结果表中。

import time, statistics, requests

RPC_URL = "RPC_URL"
METHODS = ["eth_blockNumber", "eth_getBalance"]
SAMPLES = 200

def call(method, params):
    payload = {"jsonrpc":"2.0","id":1,"method":method,"params":params}
    start = time.perf_counter()
    r = requests.post(RPC_URL, json=payload, timeout=5)
    elapsed = (time.perf_counter() - start) * 1000
    return r.status_code, elapsed, r.json()

for method in METHODS:
    params = [] if method == "eth_blockNumber" else ["0x0000000000000000000000000000000000000000", "latest"]
    latencies, errors = [], 0
    for _ in range(SAMPLES):
        try:
            status, ms, body = call(method, params)
            latencies.append(ms)
            if status != 200 or "error" in body:
                errors += 1
        except Exception:
            errors += 1
    latencies.sort()
    p50 = statistics.median(latencies)
    p95 = latencies[int(len(latencies) * 0.95) - 1]
    p99 = latencies[int(len(latencies) * 0.99) - 1]
    print(method, "p50", round(p50,1), "p95", round(p95,1), "p99", round(p99,1), "errors", errors)

预期验证结果

健康的端点应对每个样本返回 HTTP 200 和有效的 JSON-RPC 结果，且延迟百分位数应在多次运行间保持稳定。如果你看到 p99 延迟远高于 p50，或出现间歇性错误，则该端点在没有回退方案的情况下不适合执行关键路径。

对于一致性，对同一区块高度的重复读取应返回相同结果。如果不同，请记录差异并调查该端点是否在状态不同的节点之间进行了负载均衡。

不要将单次成功运行视为证明。在一天中的不同时段以及类似生产流量的负载下重复该流程。

排查常见故障模式

交易 RPC 使用中最常见的故障模式是 nonce 不匹配、过时读取、速率限制以及静默故障转移到滞后节点。每种在你的测量中都有不同的特征。

Nonce 不匹配通常表现为带有 nonce 错误的交易被拒绝。过时读取表现为余额或区块高度落后于其他端点。速率限制表现为负载下集中出现的 HTTP 429 响应。静默故障转移表现为一致性失败，即同一查询在短时间窗口内返回不同结果。

对于每种故障模式，判断你的策略能否容忍它。做市商如果有对账循环，可能接受偶尔的过时读取，但无法容忍使账户停滞的 nonce 不匹配。

• Nonce 错误：检查待处理交易处理和替换逻辑。
• 过时读取：在信任余额之前比较各端点的区块高度。
• 速率限制：在真实并发下衡量错误率，而非单个请求。
• 一致性失败：记录每次读取的区块高度和结果。

局限性与权衡

没有 RPC 端点是完美的。更高的可靠性通常成本更高，而专用基础设施以灵活性换取控制权。单个端点运营更简单但没有冗余；端点池增加了复杂性并需要一致性检查。

本文中的测量流程是起点，而非完整评估。它不涵盖内存池监控、交易替换或跨链行为。如果你的策略依赖这些，请扩展方法组合并重新运行该流程。

最后，任何交易公司（包括 tendex）技术栈的公开描述都不能替代你自己的架构审查。将它们作为背景，然后测量你自己的环境。

后续步骤：从测量到基础设施选择

一旦你有了结果表，下一步是决定你需要共享端点、专用节点还是混合方案。共享端点适合读取密集、延迟容忍型工作负载。当你需要可预测的性能和对节点软件的控制时，专用节点是合适的选择。

有关具体的端点与供应商建议，请使用 RPC Assistant 而非本文。有关节点托管和端点设计的背景，请参阅 Learn 指南中关于区块链节点托管和多链 RPC 端点的内容。

如果你正在专门评估 OnFinality，请查看 API 服务、RPC 定价、支持的网路和专用节点页面，然后对你正在考虑的端点运行测量流程。

• 从 RPC Assistant 开始选择端点与供应商。
• 使用 Learn 指南获取架构和测量背景。
• 在任何基础设施变更后重新运行该流程。