Alchemy 用量:提升透明度与简洁性

背景

我们的定价基于"计算单元"（compute units）的概念——这是衡量你的应用在 Alchemy 上使用的总计算资源的指标。你可以将其类比为向 Amazon 支付 AWS 使用费用的方式。有些查询很轻量、运行很快（例如 eth_blockNumber），而有些查询则计算量较大（例如大型 eth_getLogs 查询）。为了给你最低的成本，我们没有按查询数量收费，而是只按实际使用的计算量收费。

挑战

当每个请求都要测量计算量时，计算单元（以及由此产生的月度用量）可能难以预测。有些方法的强度差异很大（例如 eth_call），它们消耗的计算单元数量可能相差多达 100 倍。这使得优化用量或预测月度成本变得比本应有的更复杂。

我们希望让所有客户都能简单、直观地测量和预测在 Alchemy 上的用量。因此，为了打造对开发者最友好的平台，我们决定更新计算单元的衡量方式。

计算单元的更新

在新的计算单元模型中，每个方法都会被分配一个固定的计算单元数，该数值来自其平均强度。这意味着你在发起某个调用之前，就能确切知道它会消耗多少计算单元，大幅提升了可预测性和透明度。

举一个说明这次更新如何改善开发者体验的例子：假设某用户发起 10,000 次 trace 请求。

在旧的计算单元模式下，用户发起 10,000 次 trace_call 请求，要到请求全部完成之后才知道消耗了多少计算单元。根据区块、合约以及调用发生的时间不同，用户最终可能消耗了 750,000 个计算单元，也可能是 1,000,000 个。即便如此，下一次再发起 10,000 次 trace_call 请求时，结果也可能不同。

而在新的计算单元模型下，如果有人发起 10,000 次 trace_call 请求，每次调用为 75 CU，那么总消耗将是 10,000×75 = 750,000 CU，每次都是如此。

不再需要猜测，也不再有波动——只有公平且确定的用量衡量方式！

关于各方法对应的完整 CU 分配列表（基于多年的基准用量测试得出），请参阅我们的文档。

更优的速率限制

目前，我们使用每秒查询数（QPS）作为主要的速率限制指标。虽然这是 API 相当常见的限速方式，但它是一种相对粗糙的工具。这意味着我们常常不得不出于谨慎，把速率限制设得比实际需要更严格。

有了新的计算单元定义，我们得以用一个更优的指标来替代 QPS：每秒计算单元数，即 CUPS。

CUPS 速率限制实际上是 QPS 的加权版本，其中每个方法的权重就是它的计算强度。由于考虑到了请求的差异性和所调用方法的类型，这一限制最终会更加准确。这使我们能够为所有客户提供更可靠的整体服务，同时限制也更为宽松（在很多情况下甚至比以前更宽松！）。

总结

总的来说，我们认为这次变更会给客户带来巨大的改善。我们始终认真对待你的反馈，并致力于让开发者体验做到最好，这样我们才能都专注于打造最出色的产品。

如有任何问题或需要澄清的地方，欢迎随时联系我们，我们很乐意提供帮助。