ESP 作為 Espresso Network(ESP) 的原生功能代幣,將網路安全與服務付費統合於單一機制。驗證者與委託方透過 ESP 參與委託式權益證明(delegated Proof of Stake);接入鏈與應用根據協議支付費用,以取得 Finality、資料可用性(Data Availability,DA)等服務。理解質押與協議費的核心,在於角色分工、合約入口與激勵機制如何共同支撐網路共識。
多鏈場景下,排序確認通常仰賴共享基礎層。Espresso Network 以 HotShot 提供去中心化結算,ESP 則決定活躍驗證者集合的組成,以及服務的付費使用方式。質押路徑與費用路徑需分別核對,避免將「持有代幣」誤認為「已獲得網路服務」。
ESP 在網路安全中,擔任質押抵押與服務付費結構的功能載體。Ethereum 主網 ESP Token 地址為 0x031De51F3E8016514Bd0963d0B2AB825A591Db9A,官方說明用於 staking 與 protocol fees。驗證者需將 ESP 寫入 Stake Table,方可進入按質押量排序的活躍共識集合;委託方則將 ESP 委託給驗證者,間接強化網路安全。
ESP 不負責執行接入鏈交易,也不替代各鏈排序器。ESP 支撐的是網路端 PoS 安全預算:若要更改已確認結果,需破壞足夠高比例已質押 ESP 所對應的驗證者集合。此模型與 HotShot 共識與秒級 Finality 緊密相連——HotShot 達成 BFT 確認,ESP 質押決定確認背後的經濟權重。
| 組件 | 合約 / 入口(Ethereum) | 機制職能 |
|---|---|---|
| ESP Token | 0x031De51F3E8016514Bd0963d0B2AB825A591Db9A |
質押抵押與協議費用相關功能代幣 |
| Stake Table | 0xCeF474D372B5b09dEfe2aF187bf17338Dc704451 |
驗證者註冊、委託與質押表管理 |
| Fee Contract | 0x7f15ff3f783acd4d09c6a79d098ed5069a2bd39a |
存放用於支付 Espresso 網路費用的 ETH 存款 |
| Reward Claim | 0x67c966a0ecdd5c33608be7810414e5b54da878d8 |
驗證者與委託方可領取質押獎勵的入口 |
上表區分安全層與付費層:Stake Table 管理共識參與權,Fee Contract 管理服務預存與消耗,Reward Claim 負責獎勵領取。核對合約地址與職能,比僅記代幣名稱更貼近機制本質。
驗證者必須在 Ethereum 上於 Stake Table 註冊節點,並獲得足夠委託質押,才能進入每 epoch 按質押量排序的活躍集合。Mainnet 採用 permissionless delegated PoS:可自營驗證者,也可將 ESP 委託給已註冊驗證者。最低委託量公開為 1 ESP;活躍集合通常取質押量排名前 100 名的驗證者。
質押變更並非即時生效。質押表於 epoch 邊界更新;委託在 Ethereum 最終確認後,通常需再經兩個 epoch 才成為有效質押。解除委託有退出窗口,同一驗證者通常僅允許一筆進行中的 undelegation。驗證者可設定佣金,從節點獎勵中先行扣除,剩餘依委託比例分配。
未運行節點的持有者可透過 stake.espresso.network 等公開入口完成委託、解除委託與獎勵領取。入口僅為操作介面,實際約束則由 Stake Table、Reward Claim 等合約負責。選擇驗證者時,建議關注其是否位於活躍集合、佣金比例與節點可用性。
| 參與方式 | 執行者 | 機制結果 |
|---|---|---|
| 自營驗證者 | 註冊節點並吸引委託 | 進入活躍集合後參與 HotShot;收取佣金 |
| 委託 ESP | 持有者指定驗證者 | 增加該驗證者質押權重;分享扣除佣金後的獎勵 |
| 解除委託 | 委託方發起退出 | 經退出窗口取回資產;有效質押於 epoch 邊界調整 |
上表說明,共識參與權來自「註冊 + 有效質押權重」,而非錢包餘額本身。委託降低運維門檻,並將節點營運風險部分轉移到「選擇驗證者」上。

圖 1. ESP 質押與協議費雙路徑:持有者委託/質押 → 驗證者與 Stake Table → HotShot 安全;接入方經 Fee Contract 支付 Finality/DA 等服務。
接入方支付協議費用,係為結算、確認與可選 DA 等服務預存並消耗費用餘額。Fee Contract(0x7f15ff3f783acd4d09c6a79d098ed5069a2bd39a)存放用於支付 Espresso 費用的 ETH 存款;建構者或集成方可向指定地址存入 ETH 供扣費。ESP Token 官方描述同時涵蓋 staking 與 protocol fees,因此需明確區分「服務付費入口」與「代幣功能定位」,避免混為一體。
費用對應網路服務使用,而非「購買驗證者席位」。接入方依集成路徑消耗協議費取得 Finality 或 DA;驗證者則憑質押權重進入共識。兩路徑匯合於同一網路:一方為有激勵的驗證者集合,一方為付費使用服務的接入者。
此路徑亦區分 Espresso 與單鏈中心化排序器:後者確認常依賴單一營運方,前者將確認錨定於 PoS 集合,再由接入鏈付費使用。Espresso vs 中心化排序器與 Astria 對照的正是「付費使用共享確認層」與「信任單一排序器」的差異。協議費不改變各鏈是否自營排序器,只影響確認與 DA 的計量結算方式。
激勵設計旨在促使驗證者持續參與 HotShot 確認與相關驗證,使接入鏈區塊承諾能在去中心化集合上最終確認。獎勵經 Reward Claim 等路徑領取,根據鏈上可驗證紀錄向驗證者與委託方發放差額。激勵與「是否處於活躍集合並履職」直接掛鉤。
排序與 DA 分工明確:各鏈通常仍自營排序器;Espresso 提供區塊承諾的去中心化結算、快速 Finality 及可選 EspressoDA。Espresso 秒級確認全流程將交易、排序、HotShot 確認與可驗證結算串成鏈路。驗證者激勵涵蓋共享確認與 DA 驗證上的誠實參與,並不取代接入鏈執行。
佣金與活躍集合為兩道過濾:佣金分割驗證者與委託方獎勵;top 100 決定當期履職與獎勵資格。委託給未進集合的節點,官方說明可能暫時無獎勵。建議先確認節點是否在履職集合內,再談分配比例。
機制風險主要來自罰沒與行為約束。PoS 以獎勵鼓勵誠實行為,並以罰沒(slashing)等規則約束重大不當行為;具體條件以公開規則為準,「可能損失質押」屬機制內生風險。其次為智能合約風險:Stake Table、Fee Contract、Reward Claim 與 ESP Token 均部署於 Ethereum,漏洞、升級與權限變動都可能影響資金與狀態。
運營風險集中於驗證者端:節點離線、錯過職責或掉出活躍集合,將影響委託方實際分配。解除委託有時間窗口。費用端可能出現餘額不足、地址錯誤或扣費理解偏差。集成方須明確區分「已向 Fee Contract 存款」與「集成完成並獲得預期確認保證」。
常見誤解包括:僅將 ESP 視為可流通資產而忽略質押與費用功能;誤認委託等同自營驗證者,或認為任意委託均有獎勵資格;將協議費誤解為促銷發放。協議費對應 Finality/DA 服務使用,質押則關聯安全貢獻與激勵分配。
ESP 將安全預算與服務付費整合為一體:驗證者與委託方經 Stake Table 質押或委託 ESP,支撐 HotShot 活躍集合;接入方透過協議費用取得確認與 DA 等服務。激勵機制與排序確認、DA 驗證連動,並由佣金與活躍集合過濾分配對象。參與時需理解罰沒、合約、節點運營與退出窗口等風險,並分別核對質押與費用路徑。
ESP 作為 Espresso Network 的原生功能代幣,主要用於驗證者質押、委託式 PoS 參與,以及官方描述的協議費用相關功能。持有者可自行成為驗證者或將 ESP 委託給驗證者,以支撐 HotShot 共識安全;接入側則圍繞網路服務付費使用 Finality、DA 等能力。ESP 不負責執行各接入鏈內部交易。
成為驗證者需在 Ethereum 上的 Stake Table 註冊節點,配置共識密鑰與佣金等參數,並獲得足夠委託質押以進入按質押量排序的活躍集合。未運行節點的持有者可改為委託 ESP。公開交互入口包括 stake.espresso.network;註冊與委託的生效仍以鏈上合約與 epoch 規則為準。
Espresso Network 定位為面向多鏈生態的共享確認與結算基礎設施,透過 HotShot 共識為接入鏈與應用提供去中心化、快速最終確認的狀態錨定,並可配套資料可用性等服務。ESP 在該網路中承擔質押安全與協議費用相關功能,使驗證者集合與服務使用能在同一機制下運作。
HotShot 是 Espresso Network 的 BFT 共識協議,用於對接入鏈提交的區塊承諾達成去中心化最終確認,而不執行這些交易本身。其安全來自委託式 PoS 驗證者集合:要推翻已確認結果,需破壞足夠高比例的已質押 ESP 所對應權重。HotShot 因此將快速 Finality 與 PoS 經濟安全結合於同一確認層。
使用或參與 Espresso 須區分多重機制風險:PoS 罰沒與行為約束風險、Stake Table / Fee Contract / Reward Claim 等智能合約風險、驗證者離線或掉出活躍集合的運營風險,以及解除委託的時間窗口與費用存款操作風險。集成方亦應區分付費能力與完整集成結果。上述內容僅作機制說明。





