Solana 上的無 Gas 交易：完整指南

Solana 上的無 Gas 交易允許贊助者為用戶支付網路費用。這並非免除費用、讓每筆交易都變成免費，或保證簽署贊助交易不會移動用戶資產。

最後更新：2025 年 1 月

Solana 上的無 Gas 交易是指終端用戶無需支付網路費用的區塊鏈交易，因為由稱為費用贊助者的指定第三方代為支付成本。「無 Gas」(Gasless) 一詞借用自以太坊的費用術語，其費用被稱為「Gas」。Solana 本身使用「交易費用」而非 Gas。但在口語上，無 Gas 在不同鏈上已演變為相同的含義：用戶無需支付任何費用，由他人買單。

Solana 預設並非無 Gas。網路上的每筆交易都需要以 SOL 支付費用。許多 dApp（去中心化應用程式）代您贊助這些費用，讓您在未持有任何 SOL 的情況下即可開始使用。您是否需要 SOL 取決於特定的 dApp：啟用了無 Gas 功能的 dApp 會為您支付費用，而其他 dApp 則需要您自行支付。本指南涵蓋了費用支付者架構、誰付費以及原因、現實世界案例、實現路徑、成本分析和安全考量。

目錄

1. 核心概念：Solana 的費用支付者架構如何運作
2. 無 Gas vs. 免費：澄清最常見的誤區
3. Solana vs. Ethereum：無 Gas 交易與帳戶抽象有何不同
4. 如何在 Solana 上實現無 Gas 交易
5. 現實世界案例：無 Gas 交易已在 Solana 哪些地方部署
6. 贊助交易的成本：無 Gas 實際上讓開發者花費多少？
7. 安全考量：開發者需要了解的轉發器風險
8. 選擇合適的方法：原生實現 vs. 託管服務
9. 關於 Solana 無 Gas 交易的常見問題
10. 總結：您需要了解的 Solana 無 Gas 交易重點

核心概念：Solana 的費用支付者架構如何運作

每一筆 Solana 交易都包含一個 feePayer 欄位，用來指定扣除哪個帳戶的 SOL 餘額以支付網路費用，且此帳戶不一定非得是交易發起人。

Solana 的交易費用模型

Solana 按簽名收取基礎費用，也可能收取優先費用。基礎費用參數及其以 SOL 計價的金額應參考最新文件；總交易成本會隨簽名、計算設定、優先費用和網路狀況而異。驗證者（處理和驗證交易的網路節點）收取這些費用，作為其計算工作的賠付。歷史證明（Proof of History）是與質押證明（Proof of Stake）和 Tower BFT 配合使用的計時組件。經常被引用的 65,000 TPS 數據是理論基準，而非保證的應用吞吐量。

如需完整的費用結構，請參閱 Solana 交易費用文件.

什麼是 Solana 上的費用支付者？

Solana 上的費用支付者（Fee Payer）是指定用於支付交易費用的帳戶。在標準交易中，費用支付者和交易簽署者是同一個帳戶（用戶錢包）。在無 Gas 交易中，它們被刻意設定為不同的帳戶。兩個帳戶都必須簽署交易，但只有費用支付者的 SOL 餘額會被扣除以支付網路費用。

這種分離透過 feePayer 欄位內建於 Solana 的基礎交易結構中。這不是一種變通方案、獨立的鏈上程式或應用層附加功能。任何 Solana 交易都可以透過設置此欄位來指定不同的費用支付者。有關技術規範，請參閱 Solana 費用支付者文件.

無 Gas 交易如何在網路中流轉的逐步說明：

1. 用戶在 dApp 中發起動作（鑄造 NFT、兌換代幣或任何其他鏈上動作）。
2. dApp 構建一個交易物件，並將 feePayer 欄位設置為獨立的贊助者帳戶，而非用戶錢包。
3. 用戶透過其錢包簽署交易，授權指令（該動作）。其簽署不會扣除其餘額。
4. 部分簽署的交易被發送到持有贊助者私鑰對的轉發器（Relayer）伺服器。
5. 轉發器驗證交易內容，確認其與預期的程式和指令數據相符。
6. 轉發器使用贊助者私鑰對添加費用支付者簽名。
7. 轉發器將完整簽署的交易提交至 Solana 網路，網路從費用支付者的餘額扣除費用，而非用戶的餘額。

這就像在餐廳掛帳一樣。用戶點餐（簽署指令），但由應用程式買單（支付費用）。

什麼是交易轉發器？

交易轉發器（Transaction Relayer）是使無 Gas 交易運作的後端服務。轉發器接收來自用戶的部分簽署交易（用戶已簽名授權指令但未支付費用），添加費用支付者的簽名，並將完整簽署的交易提交至 Solana 網路。存在兩種模式：自託管轉發器（dApp 開發者運行自己的伺服器）和託管轉發器服務（由 Helius 等第三方供應商處理基礎設施）。

您的錢包在無 Gas 交易中的角色

在標準交易中，您的錢包具備兩種功能：授權動作和支付費用。在無 Gas 交易中，您的錢包只負責第一項。當您使用啟用了無 Gas 功能的 dApp 時，您的 Phantom 錢包（或 Solflare、Backpack 或任何其他 Solana 錢包）會像往常一樣提示您簽署交易。您批准後，簽署即授權了指令：鑄造此 NFT、執行此兌換、更新此記錄。確認後您的錢包 SOL 餘額不會改變。費用由 dApp 的費用支付者帳戶支付，該帳戶由轉發器控制。相容的錢包不應洩露其私鑰，且由贊助者支付網路費用。然而，用戶簽署的指令仍可授權代幣轉移或其他狀態變更，因此必須審查完整的交易內容。

關於每種轉發器方法的完整技術實現，請參閱 實現指南。

關鍵術語

• 費用支付者 (Fee Payer)： 其 SOL 餘額用於支付交易費用的帳戶。在無 Gas 流程中，這由 dApp 控制，而非用戶。
• 交易轉發器 (Transaction Relayer)： 一種後端服務，接收部分簽署的交易，添加費用支付者簽名並將其提交至網路。
• 費用贊助者 (Fee Sponsor)： 資助費用支付者帳戶並承擔交易成本的實體（dApp 開發者、協議或託管服務）。

[DIAGRAM: Three-node flow diagram showing "用戶錢包簽署指令" with arrow labeled "部分簽署的交易" pointing to "中繼者 / 費用支付者簽署 + 支付費用" with arrow labeled "完全簽署的交易" pointing to "Solana 網路確認" and final arrow to "操作在用戶錢包中完成。" 設計團隊：節點從左到右，帶有標示的方向箭頭。]

無費 vs. 免費：釐清最常見的誤解

無費是費用贊助的簡稱：網路費用確實存在且始終由某方支付，但最終用戶並非支付者。

Solana 上存在三種費用情況，其中只有一種是真正意義上的無費：

• 標準交易： 用戶從自己的 SOL 餘額中支付費用。每筆簽名費用為 0.000005 SOL。
• 無費（贊助）交易： dApp、協議或託管的中繼者服務代表用戶支付費用。用戶的 SOL 餘額不會被動用。
• 低費交易： 用戶支付的費用非常小，幾乎感覺不到。這不是無費；用戶仍需要 SOL。

交易贊助是實現無費交易的面向業務術語。從產品角度來看，承擔交易費用是獲客成本，類似於提供免費試用或支付廣告曝光。

一個合理的問題隨之而來：如果我不支付，有什麼陷阱嗎？答案是透明的。在 Solana 的費用水平下，贊助商的成本微不足道。贊助 10 萬筆交易的基礎費用為 0.5 SOL。一個運行無費 NFT 鑄造的平台，可以透過市場費用、首次銷售收入或用戶留存率賺回數倍的成本。有些平台透過訂閱方案或協議代幣經濟學來收回成本。

費用始終會有人支付。它支付給 Solana 的驗證者。問題只在於誰來發送。

如需全面討論與費用贊助相關的風險，請參閱 安全注意事項 部分。

Solana 與 Ethereum：無費交易與帳戶抽象的差異

Ethereum 的礦工費模型是「無費」概念的起源，將 Solana 的原生費用支付者架構與 Ethereum 的 EIP-4337 帳戶抽象進行比較，就能看出兩者如何透過不同的技術手段實現相似的用戶體驗。

Ethereum 對計算收取「礦工費」。礦工費是可變的、市場驅動的，並以 ETH 支付（以 gwei 計價）。在網路擁塞高峰期，Ethereum 的交易費用歷史上曾達到每筆交易 50 美元或更高。這種波動性正是無費用戶體驗成為一個有意義的設計目標的原因。當將 Solana 費用與 Ethereum 礦工費進行比較時，基礎費用之間的差距解釋了為何費用贊助在 Solana 上經濟上微不足道，而在 Ethereum 上卻異常昂貴。Ethereum 的礦工費與 Solana 的交易費用相比，在典型成本上存在數個數量級的差異。

Ethereum 透過 EIP-4337 解決無費用戶體驗問題，這是一個應用層標準（而非協議層變更），引入了支付者（paymasters）。支付者是代表用戶贊助礦工費的智慧合約。部署支付者需要一個 UserOperation bundler、一個 EntryPoint 合約以及支付者合約本身。在任何用戶受益之前，這是一筆有意義的基礎設施投資。如需完整規格，請參閱 EIP-4337 規格.

在 EIP-4337 之前，Ethereum 使用了元交易（meta-transactions）（標準化為 ERC-2771）作為一種變通方法。用戶簽署一條表達意圖的訊息，然後由一個中繼者將該訊息包裝成一個完整的交易並支付礦工費。Solana 的方法在架構上更簡潔，因為費用支付者分離是一項第一類協議功能，而不是應用層的訊息包裝模式。

套用在 Solana 上的「無費」一詞是借用的術語。Solana 的文件使用「交易費用」，而不是「礦工費」。對「無費」的習慣性採用反映了 Ethereum 如何塑造了跨鏈此類用戶體驗模式的詞彙。

Ethereum 的 Layer 2 解決方案已降低了主網礦工費成本，此注意事項應包含在任何比較中。上表反映了 Ethereum 主網的歷史範圍。結構性差異依然存在：Solana 的費用支付者是一項協議功能，不需要額外的合約部署；而 EIP-4337 是一個應用層標準，需要部署支付者堆疊。

如何在 Solana 上實施無費交易

為 Solana 應用程式添加費用贊助存在三種實施方法。正確的選擇取決於交易量、開發資源、安全要求以及對第三方的依賴程度。這三種方法都使用 Solana 的原生 feePayer 欄位作為底層協議機制。

方法 1：在支援的 SDK 中設定費用支付者

原生方法是在交易物件上設定費用支付者欄位，並使用一個有安全託管的、已存入 SOL 的贊助帳戶。團隊應使用符合其核准工程環境的維護中繼 SDK，並根據當前的 Solana 交易規格驗證行為。

先決條件： 在核准的密鑰管理或簽署系統中託管的已存入資金的贊助帳戶、RPC 連線、交易驗證規則、監控和維護中的客戶端函式庫。

步驟：

1. 建立一個新的 Transaction 物件。
2. 加入相關指令（鑄造、交換、轉帳或其他程式呼叫）。
3. 設定 transaction.feePayer = sponsorKeypair.publicKey 以指定贊助帳戶。
4. 取得 recentBlockhash 並指派給交易。區塊雜湊約在 150 個槽位（約 60 到 90 秒）後過期；請盡快提交，或為有不可避免延遲的流程實施耐用 nonce。如需了解該模式，請參閱 Solana 耐用 nonce 文件
5. 讓用戶的錢包簽署交易指令。雖然贊助者支付網路費用，但指令仍可移動用戶資產或產生其他狀態變更。
6. 將部分簽署、序列化的交易發送到中繼者伺服器端點。
7. 中繼者驗證交易內容，加入贊助者金鑰對簽名，然後透過 RPC 提交完全簽署的交易。

確切的 SDK API 和交易類型會隨時間變化。實施應構造預期的指令，設定贊助者為費用支付者，獲取當前的區塊雜湊或支援的 nonce，在不更改簽署內容的情況下收集所需的簽名，在中繼者上驗證序列化的交易，並透過核准的 RPC 提供者提交。請根據當前的 SDK 和協議文件驗證每個步驟。

贊助者金鑰對必須始終保留在伺服器端。將其暴露於用戶端會讓任何使用者耗盡贊助者的 SOL 餘額。如需完整的風險分析，請參閱完整的安全討論。

如需權威欄位規格，請參閱 Solana 的費用支付者文件.

方法 2：使用受管中繼服務

受管中繼服務代表開發者處理費用支付者基礎設施，讓費用贊助可以透過 API 呼叫整合，而無需建置或維護中繼伺服器。

受管提供者提供的服務可能包含贊助交易或中繼功能。Helius、QuickNode 和 Alchemy 是原始文中提到的範例；目前的 Solana 支援與產品條款必須直接查閱。常見的整合模式如下：

1. 使用核准的密碼管理程序從選定的提供者取得認證。
2. 在用戶端建置交易，加入指示並將 transaction.feePayer 設定為提供者指定的公鑰。
3. 讓使用者錢包部分簽署交易。
4. 透過 HTTP POST 將交易序列化並傳送至提供者的無 gas 端點。
5. 提供者會驗證交易，並以費用支付者身分共同簽署，然後將交易提交至 Solana 網路。

受管服務可以減少直接的營運工作，但會引入供應商、認證、可用性、政策、隱私權和定價等依賴性。金鑰保管責任取決於提供者的架構和合約。提供者的文件是起點，不能取代安全性審查。

取捨的代價是對供應商的依賴。如果受管服務發生停機，贊助的交易就會失敗。使用者無法自行支付費用，除非有額外的前端邏輯來偵測中繼服務的可用性並改為建構標準交易。請評估這對您的產品容忍第三方可用性風險的影響。[選擇正確方法的原生實作 vs. 受管服務]此處的建置 vs. 購買架構涵蓋了此決策的全部內容。

QuickNode 和 Alchemy 都提供具備費用贊助或與中繼相關功能的 Solana 基礎設施。由於受管服務的產品不斷演進，請在每個提供者的文件中驗證目前的支援功能。

方法 3：建置自訂交易中繼服務

當應用程式需要自訂贊助資格邏輯、在大規模營運且有嚴格資料保留要求，或需要完全控制費用支付者金鑰對時，自訂交易中繼服務便適用。

自訂中繼服務的架構有五個元件：

1. API 端點： 透過 HTTP 接受來自 dApp 前端的半簽署序列化交易。
2. 驗證層： 反序列化交易，並針對允許清單檢查程式 ID、指示資料和帳戶清單。這是安全性最高的元件。中繼服務會簽署收到的任何內容；因此，它必須先驗證收到的內容，然後再簽署。
3. 費用支付者簽署： 使用儲存在環境變數或密碼管理器中的金鑰對。切勿將金鑰對儲存在原始碼中或提交到儲存庫。
4. RPC 提交： 透過 RPC 將完整簽署的交易傳送至 Solana，包含確認失敗的重試邏輯和處理速率限制回應。
5. 餘額監控： 贊助者錢包必須維持足夠的 SOL 以應對預期的交易量。實施自動化警報和儲值機制，以防止因餘額不足導致的中繼服務停機。

對於僅限 Python 的工程環境，請在確認支援所需的交易格式和簽署流程後，再使用維護中的 Python Solana 用戶端。自訂中繼服務仍然需要監控、速率限制處理、重試佇列、餘額控制、測試和事件回應。

實際應用案例：Solana 上已部署的無 Gas 交易

無 Gas 交易已在數種類型的 Solana dApps (去中心化應用程式) 中投入生產，每種類型都有獨特的商業理由來吸收使用者的交易費用。

NFT 的鑄造平台 是一種無 Gas 用途。當平台贊助網路費用時，相容的錢包可以在不支付 SOL 費用的情況下簽署鑄造交易。無 Gas 鑄造仍可能包含鑄造價格、優先費用政策、平台收費、權利金或後續的帳戶相關費用，因此使用者應檢查完整的交易和價格。

DeFi 的協議 面臨結構性的導入問題，而費用贊助直接解決了這個問題。抵達的使用者，如果持有 USDC 或其他非 SOL 代幣，在無法先取得 SOL 來支付交易費用之前，無法啟動任何兌換、質押或儲值。這會產生一個循環依賴：您需要 SOL 來與一個可以提供 SOL 的協議互動，但沒有 SOL 就無法互動。贊助新使用者的一到三次交易可以消除這個障礙。DEX、跨鏈橋導入流程和借貸平台都採用了這種模式。在贊助期結束後，透過兌換獲得 SOL 的使用者可以在後續交易中支付自己的費用。

Web3 遊戲 產生高頻率的交易，讓費用贊助對遊戲工作室來說在經濟上很有吸引力。每次觸及鏈上的遊戲內操作（例如物品購買、成就鑄造、排行榜更新）都會在沒有贊助的情況下顯示錢包提示和費用扣除。以 Solana 的基礎費用來說，贊助 1,000 次遊戲內交易約需 0.005 SOL。遊戲工作室會將此作為營運成本吸收，類似於伺服器基礎設施，結果是玩家體驗表現得像標準的 Web2 遊戲，而不是區塊鏈應用程式。

消費者 dApp 導入 將此模式擴展到任何應用程式。Solana dApp 可以贊助使用者首 N 次交易，以降低首次鏈上操作的門檻，然後在使用者取得 SOL 後轉為自行付費。Solana Pay (Solana 的開放支付協議) 為商家情境提供了類似的模式：商家可以充當費用支付者，讓客戶無需持有 SOL 支付費用即可發起付款。

我需要 SOL 才能使用這些應用程式嗎？ 不需要，只要平台積極贊助交易費用即可。無 Gas 是每個 dApp 的產品決策，而非網路保證。在假設費用由平台贊助之前，務必檢查平台的現行費用政策。贊助計畫可能有時間限制、數量上限，或僅限於特定操作。

無 Gas 行為主要是 dApp 和中繼服務的功能，但錢包相容性和交易格式支援仍需要測試。Phantom、Solflare 和 Backpack 是原始文中提到的範例，非推薦。使用者簽署交易指示，而贊助者授權支付費用。

贊助交易的成本：無 Gas 實際上要花費開發者多少錢？

原始文件使用 Solana 的交易費用文件，模擬了每次簽署 5,000 lamports 的基礎費用。這應視為需要驗證的輸入，而非永久報價。總贊助成本也取決於簽署次數、優先費用、重試、帳戶建立、提供者收費、基礎設施和 SOL 的價格。

下方的成本估算僅為說明性質，並基於公開可用的費用數據。本內容不構成財務建議。SOL 價格波動劇烈；實際的美元成本將有所不同。

1 SOL 等於 1,000,000,000 lamports。每次簽署 5,000 lamports 的基礎費用是網路最低限額。優先費用是可選的，由贊助者控制。

優先費用 (Priority fees) 是一項選用的 computeUnitPrice 指令，可在網路負載期間將交易移至隊列前端。增加優先費用會提高單筆交易成本並引入變動性。如果您的應用程式在擁塞期間贊助交易，請預留緩衝預算。

託管服務成本 在 Solana 網路費用之上增加了一個層級。使用 Helius 或其他託管轉發器 (Relayer) 時，開發者既要支付 Solana 基礎費用，也要支付提供商的 API 訂閱費用或單筆交易服務費。具體細節請諮詢各提供商的當前定價文件。

本表是使用來源假設的基礎費用和 SOL 價格進行的說明。實際成本取決於簽名、優先費用、失敗或重試的交易、帳戶建立、提供商定價、基礎設施以及幣價。團隊應基準測試自己的工作負載，而不是從表中推斷保證成本。

如需根據成本和營運因素在託管服務與自定義轉發器之間進行選擇，請參閱「正確方法」部分。

安全考量：開發者需要了解的轉發器風險

實施無 Gas 交易為開發者、基礎設施營運商和用戶帶來了安全責任。用戶簽名授權的是錢包呈現的交易指令；費用贊助並不會使有害或誤導性的指令變得安全。

用戶安全： 合法的費用贊助流程不應要求共享私鑰，但用戶仍需驗證域名、錢包提示、程式 ID (Program ID)、代幣批准、帳戶和金額。即使由另一個帳戶支付網路費用，惡意 dApp 仍可要求用戶簽署有害指令。

以下風險影響開發者和營運商，而交易簽名、釣魚、錢包和資產授權風險也會影響終端用戶。

風險 1：交易內容篡改。 惡意客戶端可以構建包含有害指令的交易並將其提交給轉發器，希望轉發器在不檢查內容的情況下進行簽名。緩解措施：轉發器在簽名前必須反序列化並驗證交易。根據預期值的允許清單檢查程式 ID、指令數據和帳戶列表。僅對符合應用程式預期結構的交易進行簽名。

風險 2：重放攻擊。 Solana 的 recentBlockhash 機制原生防止重放攻擊。區塊哈希 (Blockhash) 在大約 150 個 Slot (約 60 到 90 秒) 後過期，任何在其區塊哈希過期後提交的交易都會被網路拒絕。轉發器不應重新簽名具有已過期區塊哈希的交易。對於無法避免提交延遲的流程，請使用 Solana 的 nonceAccount 功能實施持久性 Nonce；參見 Solana 持久性 Nonce 文件.

風險 3：轉發器服務中斷 (DoS)。 如果第三方託管轉發器發生停機，即使用戶願意自己支付費用，也無法提交受贊助的交易。緩解措施：在前端實施備援路徑，當轉發器端點不可用時，構建標準 (用戶付費) 交易。這可以在停機期間保留功能。

風險 4：贊助商錢包耗盡。 如果沒有速率限制，攻擊者可以生成大量看起來有效的交易，以耗盡贊助商的 SOL 餘額。緩解措施：針對每個錢包地址、每個 IP 地址和每個時間窗口實施速率限制。設置每日支出上限。實施斷路器，當交易量超過閾值時自動暫停贊助。通過自動告警和充值觸發器監控贊助商錢包餘額。

風險 5：搶先交易與 MEV。 轉發器廣播交易並在鏈上確認前可見其內容。對於涉及兌換或套利下單的 DeFi 應用程式，敵對轉發器可能會搶先執行交易。緩解措施：對於處理敏感財務交易的 DeFi 應用程式，請使用自營轉發器。在將任何第三方提供商整合到 DeFi 產品之前，評估其聲譽和營運透明度。

關於監管背景：在某些司法管轄區，贊助用戶交易可能會對 dApp 的監管地位產生影響，特別是如果贊助的費用被定性為價值轉移。這不是法律建議；請諮詢法律顧問以進行針對特定司法管轄區的分析。

實施指南中的驗證層描述了在轉發器架構中應用這些緩解措施的位置。

轉發器實施安全清單

• 在簽名前驗證並反序列化交易內容
• 絕不重新簽名具有已過期區塊哈希的交易
• 為轉發器停機實施用戶付費備援機制
• 針對錢包、IP 和時間窗口實施速率限制，並設置每日支出上限
• 對於處理敏感交易的 DeFi 應用程式，使用自營或受信任的轉發器

選擇正確的方法：原生實施 vs. 託管服務

在原生 feePayer 實施、託管轉發器服務和自建轉發器之間進行選擇，取決於四個因素：開發週期、交易量、安全要求以及持續營運開銷的預算。

選擇託管服務沒有通用的交易量閾值。在選擇方法之前，請比較私鑰託管、驗證控制、可用性、隱私、合規、數據駐留、定價、可移植性和事件響應。

當您的應用程式需要自定義資格邏輯 (例如，僅贊助每個用戶的前五筆交易，或僅限於特定的指令類型)、當交易量和安全要求足以證明營運投入的合理性、或者當數據駐留要求排除使用第三方提供商時，請構建自定義轉發器。

不使用專用轉發器伺服器的原生 feePayer 方法適用於具有受信任後端且交易量可預測且較低的簡單應用程式。

使用託管服務的團隊應保持遷移到自營轉發器的能力，以防提供商更改定價或停止服務。記錄整合點，使遷移成為配置更改而非代碼重寫。

有關各個選項的成本模型，請參閱 成本分析部分。

關於 Solana 無 Gas 交易的常見問題

加密貨幣中的無 Gas 交易是什麼？

加密貨幣中的無 gas 交易是指終端使用者無需支付網絡費用的區塊鏈交易。第三方（如 dApp 開發者、協議或中繼器服務）會代表使用者支付費用。該術語起源於 Ethereum 生態系統（其中交易手續費被稱為「gas」），此後擴展到包括 Solana 在內的各條鏈，成為費用贊助型使用者體驗的通用術語。

Solana 會收取 gas 費嗎？

Solana 使用交易手續費而非「gas」一詞。來源指出每份簽名的基礎費用為 5,000 lamports，但應驗證目前的參數，且總成本可能包含多個簽名和選用的優先權費用。「無 gas (Gasless)」是指由另一個帳戶支付適用的網絡費用。

Solana 上的費用支付者 (fee payer) 如何運作？

Solana 上的費用支付者是指定支付交易手續費的帳戶。每筆交易的交易物件中都有一個 feePayer 欄位。在標準交易中，費用支付者和交易簽署者是同一個帳戶。在無 gas 交易中，它們是不同的帳戶：使用者的錢包簽名以授權指令，而另一個獨立的費用支付者帳戶（由 dApp 控制）簽名以授權並支付費用。僅會扣除費用支付者的 SOL 餘額。

誰為 Solana 上的無 gas 交易買單？

dApp 開發者、協議財庫或託管的中繼器 (relayer) 服務會支付 Solana 上的無 gas 交易費用。這些實體為費用支付者帳戶存入 SOL，並運行一個代表使用者共同簽署交易的中繼器。從商業角度來看，這是交易贊助：dApp 將費用視為使用者獲取成本。請參閱誤解部分中的「誰來支付」表格以獲取詳細明細。

是否可以在不支付費用的情況下發送 SOL？

在 Solana 上，如果不向驗證者支付費用，就不會發生任何交易。費用是協議的要求。可能的情況是由發送者以外的其他方支付費用。無 gas 交易仍然會產生費用；只是使用者並非支付費用的那個人。類比來說：餐廳可以招待你免費餐點，但食物本身仍然有成本。

什麼是交易手續費贊助 (transaction fee sponsorship)？

交易手續費贊助是指 dApp 開發者、協議或服務代表終端使用者支付區塊鏈網絡交易費用的行為，讓使用者無需持有用於支付費用的 SOL 即可與 Solana 互動。它是實現無 gas 使用者體驗的機制。從產品角度來看，費用贊助通常被視為使用者獲取成本，類似於免費增值 (freemium) 產品或免除入駐費用。

如何在 Solana 上構建無 gas dApp？

要在 Solana 上構建無 gas dApp：(1) 創建一個存放在伺服器端並存有 SOL 的費用支付者密鑰對；(2) 構建交易，並將 transaction.feePayer 設置為費用支付者的公鑰；(3) 讓使用者透過其錢包簽署交易；(4) 將部分簽署的交易發送到您的中繼伺服器；(5) 讓中繼器驗證交易內容，添加費用支付者簽名，並提交到網絡。請參閱實作指南以獲取所有三種實作方法的完整技術細節。

Solana 費用與 Ethereum gas 有什麼不同？

Ethereum 和 Solana 使用不同的費用和贊助架構。Solana 提供原生的費用支付者欄位，也可能使用優先權費用；Ethereum 則支持具有不同組件的帳戶抽象 (account-abstraction) 和元交易 (meta-transaction) 設計。應比較等效的工作量、確認政策、提供者成本和安全控制，而不是僅依賴單一的固定費用數據。

我可以在 Solana 上免費鑄造 NFT 嗎？

是的，許多 Solana NFT 平台會贊助鑄造交易費用，這意味著使用者無需支付網絡費用。然而，「免費鑄造 (free mint)」和「無 gas 鑄造 (gasless mint)」並不相同。免費鑄造意味著沒有交易手續費且沒有鑄造價格。無 gas 鑄造意味著交易手續費受到贊助，但可能仍需支付鑄造價格。無 gas 標籤特別指網絡費用的贊助，而非 NFT 本身是否有購買價格。

哪些錢包支持 Solana 上的無 gas 交易？

無 gas 行為主要由 dApp 和中繼器實作，但錢包的兼容性和交易格式支持仍需測試。贊助者可能會支付網絡費用，即使簽署的指令可能會移動使用者資產或產生其他成本。

Solana 上的無 gas 交易安全嗎？

它們可以安全地實作，但贊助並非安全保證。使用者必須驗證 dApp 和簽署的指令，而開發者則必須驗證交易、保護贊助者密鑰、限制濫用、監控中繼器並提供故障處理。合法的服務絕不應要求使用者的私鑰。

如果中繼器服務宕機了怎麼辦？

如果託管的中繼器服務宕機，則在服務恢復之前無法提交受贊助的交易。除非 dApp 實作了備援路徑，否則願意自行支付費用的使用者也無法操作。一個構建良好的無 gas dApp 會偵測中繼器的可用性，並在中繼器不可用時回退到構建由使用者支付費用的標準交易。這是使用託管中繼器服務而非自營服務的主要營運風險之一。

相關 Solana 網絡經濟指南

• Solana 如何產生收入
• Solana 穩定幣市場成長

在 Bybit 上探索 SOL

讀者可以查看 目前的 SOL 市場資訊 或 SOL/USDT 現貨市場.)。可用性並不代表對協議、穩定幣、中繼器、回購計畫或投資理論的認可。

總結：關於 Solana 無 gas 交易您需要了解的資訊

Solana 上的無 gas 交易透過將費用支付轉移到指定的費用支付者帳戶（這是 Solana 原生交易模型中的一等公民欄位），為終端使用者提供免手續費的體驗。

關鍵點：

• feePayer 欄位內建於 Solana 的基礎交易結構中。無需額外的程式或合約即可贊助費用。
• 費用始終存在且始終歸驗證者所有。無 gas 意味著使用者不是支付費用的那個人，並不代表沒有費用。
• 討論了三種實作路徑：使用經核准 SDK 的原生費用支付者流程、託管的中繼器服務，以及自定義構建的中繼器。每種方式在安全性、可用性、成本和控制權方面都有不同的權衡。
• 安全責任是共擔的：使用者審查他們簽署的內容，而開發者驗證交易內容、保護贊助者密鑰、限制濫用並監控中繼器的可用性。
• 來源的基礎費用說明表明贊助成本可能很低，但生產環境的經濟效益需要考量目前的費用、優先權設置、失敗率、提供者收費和等效工作量測試。

針對不同受眾的後續步驟：

針對使用者： 在假設您的 SOL 餘額不會被動用之前，請尋找 dApp 正在贊助費用的明確確認。當贊助處於活動狀態時，您可以在不先購買 SOL 的情況下參與，但請務必驗證每個平台目前的政策。

針對開發者： 比較原生費用支付者模型、多個託管提供商以及自營中繼器。在選擇實作方案之前，請驗證目前的文檔、安全假設、服務條款和成本。

針對產品策略師： 使用成本分析部分中的公式建模您的贊助成本，並使用正確方法部分中的決策表評估實作方法。

隨著 Solana 上面向消費者的 dApp 趨於成熟，費用贊助正成為標準的入駐模式。支持它的架構從第一天起就是 Solana 協議的一部分。