Alchemy 用量:提升透明度與簡易性

背景

我們的定價是基於「compute units」（計算單位）的概念——衡量你的應用程式在 Alchemy 上使用的總運算資源。你可以把這想成你付費給 Amazon 使用 AWS 的方式。有些查詢很輕量、執行速度快（例如 eth_blockNumber），有些則較為密集（例如大型的 eth_getLogs 查詢）。我們希望盡可能給你最低的成本，因此我們不按查詢數量收費，而是只針對實際使用的運算量收費。

挑戰

當每個請求都要計算運算量時，compute units（以及因此而來的每月用量）會難以預測。有些方法的強度變化很大（例如 eth_call），它們所消耗的 compute units 可能相差多達 100 倍。這使得優化用量或預測每月成本變得比應有的還要複雜混亂。

我們希望讓 Alchemy 上的用量衡量與預測，對所有客戶來說都簡單易懂。因此，為了打造對開發者最友善的平台，我們決定更新 compute units 的衡量方式。

compute units 的更新

在我們新的 compute unit 模型中，每個方法都會被分配一個固定的 compute units 數值，該數值是根據其平均強度所推算出來的。這代表你在發出特定呼叫之前，就能確切知道它會消耗多少 compute units，大幅提升可預測性與透明度。

舉例來說，這項更新如何改善開發者體驗：假設一位使用者發出 10,000 次 trace 請求。

在舊的 compute units 制度下，使用者發出 10,000 次 trace_call 請求，直到請求全部完成後才知道總共用掉了多少 compute units。依照區塊、合約及呼叫時機的不同，使用者最終可能總共使用了 750,000 或 1,000,000 個 compute units。即便如此，下次他們再發出 10,000 次 trace_call 請求時，結果也可能不一樣。

使用新的 compute units 模型，若有人發出 10,000 次 trace_call 請求，每次呼叫為 75 CU，那麼每一次都會消耗總共 10,000 × 75 = 750,000 CUs。

沒有猜測，也沒有變動——只有公平且確定的用量衡量方式！

關於各方法所對應的 CU 數值完整列表（根據多年的效能測試用量所制定），請參閱我們的文件。

更好的速率限制

目前，我們使用每秒查詢數（queries per second，QPS）作為主要的速率限制方式。雖然這是 API 相當典型的速率限制方式，但它是相對粗略的工具。這意味著我們經常被迫採取保守做法，在速率限制上比實際需要更嚴格。

透過更新後的 compute units 定義，我們得以用更有利的衡量方式取代 QPS：每秒 compute units（compute units per second，CUPS）。

CUPS 速率限制實際上是 QPS 的加權版本，每個方法的權重就是它的運算強度。這項限制能更準確地反映請求的變異性以及所呼叫方法的類型。這讓我們能為所有客戶提供更可靠的整體服務，並提供同樣寬鬆（在許多情況下甚至更寬鬆！）的限制。

總結

整體而言，我們認為這項變更對客戶來說是一大進步。我們一向重視你的意見回饋，並努力讓開發者體驗盡善盡美，好讓我們都能專注於打造最好的產品。

如有任何問題或需要進一步說明，歡迎隨時與我們聯繫，我們很樂意協助。