---
title: "零手續費，無限複雜度：打造可規模化的 gasless transactions"
description: "消費型應用需要讓區塊鏈的體驗跟其他支付方式一樣自然。最大的障礙是一層大多數使用者永遠不會理解的手續費機制。以下是我們如何將它徹底移除的做法。"
---

# 零手續費，無限複雜度：打造可規模化的 gasless transactions

<ImageBlock
  src="https://media.alchemy.com/1772629973-technical-guide-blog.png"
  alt="無 Gas 交易基礎設施，讓使用者體驗不受 Gas 費影響"
  width={1920}
  height={900}
  priority
/>

區塊鏈基礎設施提供即時結算、全球觸及範圍，以及在成本結構上以數量級勝過傳統金融的優勢。[穩定幣](https://www.alchemy.com/dapps/top/stablecoins)在現代 L2 上的結算時間不到一秒，成本低於一美分。這些軌道已經存在，但想利用這一代新型資金移動方式的公司，面臨一個主要挑戰。

採用的瓶頸不是速度、成本或安全性——而是 gas。每一筆區塊鏈交易都要求發送方持有該鏈的原生代幣來支付手續費。一個持有 10 萬美元 USDC 的使用者，若沒有先在交易所取得 ETH，就無法發送一美元。Gas 價格波動難以預測。不同的鏈需要不同的原生代幣。

對[金融機構](/fintech)而言，這是一個無法接受的條件。銀行不想在資產負債表上持有波動性高的原生代幣。支付處理商不能要求終端使用者自行管理 gas 餘額。消費性應用程式不能在需要像 Venmo 一樣簡單的流程中引入多代幣的複雜性。

[無 gas 交易](/gasless-transactions)透過讓應用程式代替使用者贊助 gas 來解決這個問題。使用者永遠不需要持有、取得或考慮原生代幣。開發者以美元付款。基礎設施提供商負責處理中間的一切。

## 無 gas 交易的運作方式

無 gas 交易將 gas 費用的支付方，從終端使用者轉移到應用程式開發者身上，由基礎設施提供商負責處理鏈上機制與計費。

流程如下：

1. **開發者建立 gas 政策**——透過 API 或儀表板設定支出規則（每位使用者上限、每項政策上限）、允許清單／封鎖清單、以自訂 webhook 為基礎的資格規則，以及 ERC-20 代幣付款選項。
1. **使用者發起交易**——應用程式將交易轉發給 Alchemy 的 Transaction API。
1. **Alchemy 依政策進行驗證**——即時檢查支出限額、資格規則與自訂條件。
1. **Alchemy 簽署 paymaster 負載**——Sponsorship Service 透過 AWS KMS 產生密碼學簽章，授權鏈上 paymaster 合約支付 gas。
1. **交易上鏈**——paymaster 智能合約驗證簽章並以原生代幣墊付 gas。
1. **開發者收到美元帳單**——Alchemy 追蹤已確認的交易，將 gas 成本換算成美元，並加入月結帳單。

一次 API 呼叫，數分鐘內完成整合。底層基礎設施負責處理政策執行、密碼學簽署、多鏈 gas 估算、鏈上確認追蹤，以及帳單核對。

## 底層基礎設施

Alchemy 的無 gas 基礎設施由三項核心服務組成：

**Sponsorship Service**——即時決策引擎。針對開發者的政策設定驗證每一筆贊助請求，檢查近乎即時的彙總支出統計數據，並透過 AWS KMS 簽署 paymaster 負載，具備硬體等級的安全保證。

**[Paymaster](/overviews/what-is-a-paymaster) Admin Service**——用於建立與管理 gas 政策的 CRUD API。支援支出規則、允許清單／封鎖清單、以自訂 webhook 為基礎的資格判斷、ERC-20 代幣付款設定，以及政策期限控制。

[**Bundler**](/overviews/what-is-a-bundler)——彙整已贊助的 [UserOperations](/overviews/user-operations)（交易），並以打包交易的形式提交上鏈，以優化更快的確認時間與更高的吞吐量。負責處理各支援網路的提交策略、監控鏈上納入情況，並將確認資料回饋給下游的計費與政策執行系統。

這些服務加總起來，每秒可在所有支援的鏈上處理數千筆贊助請求，背後支撐的是超過 6 億筆且持續增長的記錄，寫入吞吐量為每秒 800 筆且持續增長。開發者只需要進行一次 API 呼叫。

## 讓 gas 隱形所需付出的代價

每個基礎設施團隊都要面對自建或採購的抉擇。我們的標準很簡單：如果它無法讓你的產品產生差異化，你就不應該自己建置它。沒有人會因為某個支付應用程式贊助 gas 的方式而選擇它，而建置無 gas 基礎設施所需投入的資源與時間相當可觀。以下是我們所解決的一些問題，讓客戶不必自己處理。

### 資料管線問題

每一筆贊助請求都會產生一筆記錄，必須寫入、追蹤至鏈上確認，並與帳單核對。在規模擴大後，這會變成一個高吞吐量的資料管線挑戰。

World 每天發送 350 萬筆贊助請求。以 3 個月的保留期計算，光是這一位客戶就會產生數億筆記錄。Alchemy 的 paymaster 資料庫每秒處理 800 次寫入，累計超過 6 億筆記錄，其基礎設施設計目標是擴展至數十億筆——採用分層保留策略、以串流為基礎的鏈上監控，以及服務層的水平擴展。

### 即時政策執行

當開發者設定一項政策，將贊助限制在每位使用者每月 100 美元時，這個限制必須在每條鏈、每一筆交易上都維持有效，且每秒要處理數千筆請求。確認支出的真實來源存在於鏈上，需要數分鐘才能最終確認，這要求持續運作的彙總管線，將鏈下政策決策與鏈上最終性進行近乎即時的核對。

Alchemy 持續運作這些管線，因此當使用者達到其設定的上限時，贊助就會停止——即使在多條鏈上同時進行交易也是如此。

### 高吞吐量下的密碼學簽署

每一筆已贊助的交易都需要一份密碼學簽章，證明鏈上 paymaster 合約應該支付 gas。Alchemy 透過 AWS KMS 產生這些簽章，具備硬體等級的安全性——與銀行及政府機構所採用的標準相同。

要在高吞吐量下維持這樣的安全標準，需要水平化的金鑰管理策略、低延遲的簽署管線，以及確保沒有單點故障會阻擋交易的備援機制。

### 多鏈 gas 抽象化

不同鏈的 gas 機制差異很大。Ethereum L1 的 gas 價格會隨需求波動。L2 有不同的定序器經濟模型。Solana 採用完全不同的模型——贊助對象是交易手續費與關聯代幣帳戶的租金，而不是智能帳戶 paymaster。

Alchemy 將這一切抽象化為單一的 API 介面。開發者只需以政策 ID 呼叫 `prepareCalls`，系統便會處理特定鏈的 gas 估算、贊助驗證與鏈上驗證。在 Ethereum、Arbitrum、Base、Solana 以及其他所有支援的鏈上，開發者體驗完全一致。

### 簡單的美元計費

開發者不應該需要持有 ETH、SOL 或任何原生代幣才能贊助 gas。Alchemy 在每條鏈上以原生代幣墊付 gas，並在月底提供單一的美元帳單。

這需要管理數十條鏈上的 gas 資金儲備、即時的美元成本換算，以及能準確核對數百萬筆已贊助交易的計費管線。自動支出上限可在壅塞事件導致 gas 價格飆升時提供保護，確保開發者的帳單不會出現意外。最終成果是為這種本質上波動且涉及多種幣別的事物，提供類似 SaaS 的計費體驗。

### 協議演進

EVM 上無 gas 交易的標準已經歷重大演進。**ERC-2771**（元交易）需要修改智能合約。[**ERC-4337**](/overviews/what-is-account-abstraction) 引入了帳戶抽象化，並提供標準化的 Bundler 與 Paymaster。[**EIP-7702**](/overviews/eip-7702-ethereum-pectra-hardfork) 讓現有的 EOA 無需遷移地址即可獲得[智能錢包](https://www.alchemy.com/smart-wallets)功能。

Alchemy 已經歷過這每一次轉變，並將其 Transaction API 設計為能力層，而非協議包裝層。這個 API 表達的是開發者想要達成的目標——贊助 gas、批次呼叫、接受 ERC-20 gas 付款——並負責處理底層的協議複雜度。若有更新的標準出現，或協議發生變化，我們會採納或調整。開發者的整合方式不需要改變。

### 開發者的簡便性

面向開發者的整合只需一次 API 呼叫：

<CodeSnippet
  language="typescript"
  code={`const { id } = await client.sendCalls({
  from: await signer.getAddress(),
  capabilities: {
    paymasterService: {
      policyId: config.policyId,
    },
  },
  calls: [{ to: "0x0000000000000000000000000000000000000000",value: "0x00", data: "0x" }]
});`}
/>
在這背後：政策驗證、即時支出執行、特定鏈的 gas
估算、7702 委派偵測、KMS 簽署、UserOperation 建構、
bundler 提交、鏈上確認監控，以及帳單核對。

同樣的準備—簽署—發送模式適用於任何語言，並可與現有的託管方案（HSM、MPC、[Privy](https://www.alchemy.com/dapps/privy)、[Turnkey](https://www.alchemy.com/dapps/turnkey)）整合，無需重新設計架構。

## 市場現況

無 gas 交易基礎設施正在兩個相互匯聚的市場中，逐漸成為必要條件：

**進入加密貨幣領域的金融機構。** 銀行、金融科技公司與支付公司無法在資產負債表上持有原生代幣。摩根大通每日處理超過 100 億美元的 JPMD 存款代幣流動。中國銀行（香港）正在部署無 gas 基礎設施，用於穩定幣的鑄造與銷毀操作。這些機構需要具備合規控制、稽核軌跡與 SLA 保證的正式生產級 gas 贊助方案。

**要求區塊鏈隱形化的消費性應用程式。** [Slash](/case-studies/slash-stablecoin-banking) 已透過完全無 gas 的流程處理超過 10 億美元的穩定幣商業支付。World 透過 Alchemy 的 bundler 與 paymaster 基礎設施，每週執行超過 1200 萬筆交易。使用者體驗的標準是：即時、免手續費，且與傳統金融科技無法區分。

Alchemy 目前在所有 EVM 鏈與 Solana 的無 gas 交易市場中，佔有約 85% 的市場份額，過去兩年累計處理金額超過 10 億美元。

## 建構於無 gas 基礎設施之上

管理 paymaster 基礎設施、KMS 簽署、多鏈 gas 估算與協議遷移，並不能為產品帶來差異化。使用者永遠不會知道也不在意他們的 gas 是如何被贊助的——他們只知道匯款既快速、便宜又簡單。

Alchemy 負責處理基礎設施的複雜性，讓團隊能專注於真正推動業務發展的事：發布功能、增加使用者，以及創造營收。最好的無 gas 交易體驗，就是沒有人會注意到的那一種。

深入了解[無 gas 基礎設施](/gasless-transactions)、[開始建構](https://dashboard.alchemy.com/)，若有客製化定價、整合問題或其他需求，歡迎[聯絡我們](/contact-sales)。我們樂於提供協助！

## 常見問題

### 什麼是無 gas 交易？

無 gas 交易讓應用程式能代替使用者贊助 gas 費用，如此一來終端使用者就永遠不需要持有、取得或考慮 ETH 等原生代幣，即可完成區塊鏈交易。

### 無 gas 交易是如何運作的？

開發者建立一項 gas 政策，使用者透過應用程式發起交易，Alchemy 依政策進行驗證、簽署 paymaster 負載，接著 paymaster 智能合約在鏈上支付 gas，而開發者則會收到一份美元帳單。

### 在無 gas 交易中，什麼是 paymaster？

Paymaster 是一種智能合約，用於驗證密碼學簽章，並以原生代幣為已贊助的交易墊付 gas，讓應用程式而非終端使用者來負擔 gas 成本。

### 我需要持有 ETH 或原生代幣才能為使用者贊助 gas 嗎？

不需要，Alchemy 會在所有支援的鏈上以原生代幣墊付 gas，並在月底提供單一的美元帳單，因此開發者永遠不需要持有波動性高的原生代幣。

### 什麼是 ERC-4337，它與無 gas 交易有什麼關係？

ERC-4337 引入了帳戶抽象化，並提供標準化的 Bundler 與 Paymaster，透過 UserOperations 讓 gas 費用的支付方由使用者轉移至應用程式開發者，藉此實現無 gas 交易。

### Alchemy 如何處理不同區塊鏈上的無 gas 交易？

Alchemy 將特定鏈的 gas 機制抽象化為單一 API 介面，負責處理 Ethereum、Arbitrum、Base、Solana 及其他支援鏈上的 gas 估算、贊助驗證與鏈上驗證。

### 我可以為無 gas 交易設定支出限額嗎？

可以，開發者可以設定 gas 政策，包括每位使用者上限、每項政策上限、允許清單／封鎖清單，以及以自訂 webhook 為基礎的資格規則，這些規則會在所有鏈上即時執行。

### 我需要多久才能將無 gas 交易整合到我的應用程式中？

使用 Alchemy 的 Transaction API，只需一次 API 呼叫，數分鐘內即可完成整合，該 API 會處理所有底層基礎設施，包括政策驗證、gas 估算、簽署與帳單核對。