跳至内容
0%

零费用,无限复杂度:大规模构建 gasless transactions

Alchemy headshot

作者 Alchemy

发布于 2026年3月4日2 分钟阅读

无 Gas 交易基础设施,从用户体验中移除 Gas 费用

区块链基础设施提供即时结算、全球触达能力,以及比传统金融体系低几个数量级的成本结构。稳定币在现代 L2 上结算耗时不到一秒,费用低于一美分。这些基础设施已经存在,但想利用这一代新型资金流转方式的公司面临一个重大挑战。

阻碍采用的瓶颈不是速度、成本或安全性——而是 gas。每一笔区块链交易都要求发送方持有该链的原生代币来支付手续费。一个持有 10 万美元 USDC 的用户,如果没有先在交易所购入 ETH,就无法发送哪怕一美元。gas 价格波动不可预测。不同的链需要不同的原生代币。

对金融机构而言,这是完全行不通的。银行不愿在资产负债表上持有波动性原生代币。支付处理商无法要求终端用户管理 gas 余额。消费级应用也无法在需要像 Venmo 一样丝滑的流程中引入多代币的复杂性。

无 gas 交易通过让应用代表用户支付 gas 来解决这个问题。用户从不持有、获取或思考原生代币。开发者以美元付费。基础设施提供方处理中间的所有环节。

无 gas 交易的工作原理

无 gas 交易将 gas 的支付方从终端用户转移到应用开发者,由基础设施提供方管理链上机制和账单结算。

流程如下:

  1. 开发者创建 gas 策略——通过 API 或控制面板配置消费规则(单用户上限、单策略上限)、允许名单/屏蔽名单、基于自定义 webhook 的资格规则,以及 ERC-20 代币支付选项。
  2. 用户发起交易——应用将交易转发给 Alchemy 的 Transaction API。
  3. Alchemy 根据策略进行校验——实时检查消费限额、资格规则和自定义条件。
  4. Alchemy 签署 paymaster 负载——Sponsorship Service 通过 AWS KMS 生成加密签名,授权链上 paymaster 合约支付 gas。
  5. 交易上链——paymaster 智能合约验证签名并垫付原生代币形式的 gas。
  6. 开发者收到美元账单——Alchemy 跟踪已确认的交易,将 gas 成本换算为美元,计入月度账单。

一次 API 调用。几分钟即可完成集成。底层基础设施负责处理策略执行、加密签名、多链 gas 估算、链上确认跟踪,以及账单核对。

背后的基础设施

Alchemy 的无 gas 基础设施由三个核心服务组成:

Sponsorship Service——实时决策引擎。根据开发者的策略配置校验每一笔赞助请求,检查近实时汇总的消费统计数据,并通过 AWS KMS 签署 paymaster 负载,提供硬件级别的安全保障。

Paymaster Admin Service——用于创建和管理 gas 策略的 CRUD API。支持消费规则、允许名单/屏蔽名单、基于自定义 webhook 的资格判定、ERC-20 代币支付配置,以及策略有效期控制。

Bundler——聚合已赞助的 UserOperations(交易),将其打包为批量交易提交上链,优化确认速度和吞吐量。处理各支持网络上的提交策略,监控链上纳入情况,并将确认数据反馈给下游的账单和策略执行系统。

这些服务共同处理每秒数千次跨所有支持链的赞助请求,支撑数据量已超过 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 还是其他任何支持的链上,开发者体验都是一致的。

简单的美元计费

开发者不应该为了赞助 gas 而需要持有 ETH、SOL 或任何原生代币。Alchemy 在每条链上以原生代币垫付 gas,并在月末提供单一的美元账单。

这需要管理数十条链上的 gas 资金池、实时向美元的成本换算,以及能够准确核对数百万笔赞助交易的账单管道。自动消费上限可在拥堵事件导致 gas 价格飙升时提供保护,确保开发者的账单不会出现意外。最终效果是,为这种本质上波动且多币种的事物,提供了类似 SaaS 的计费体验。

协议演进

EVM 上无 gas 交易的标准已经历显著演进。ERC-2771(元交易)需要修改智能合约。ERC-4337 引入了账户抽象(Account Abstraction),并标准化了 Bundler 和 Paymaster。EIP-7702 允许现有的 EOA 在无需迁移地址的情况下获得智能钱包能力。

Alchemy 经历了这每一次转变,并将其 Transaction API 设计为一个能力层,而非协议封装层。该 API 表达的是开发者想要做的事情——赞助 gas、批量调用、接受 ERC-20 gas 支付——并处理底层的协议复杂性。当更新的标准出现或协议发生变化时,我们负责采纳或适配,开发者的集成方式则无需改变。

开发者体验的简洁性

面向开发者的集成只需一次 API 调用:

typescript
Copied
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、Turnkey)集成,无需进行架构上的重写。

市场背景

无 gas 交易基础设施正在两个正在融合的市场中成为一项必需品:

进入加密领域的金融机构。 银行、金融科技公司和支付公司无法在资产负债表上持有原生代币。摩根大通每天处理超过 100 亿美元的 JPMD 存款代币流转。中国银行(香港)正在为稳定币的铸造/销毁操作部署无 gas 基础设施。这些机构需要具备合规控制、审计追踪和 SLA 保障的生产级 gas 赞助方案。

要求区块链隐形的消费级应用。 Slash 已通过完全无 gas 的流程处理超过 10 亿美元的稳定币商业支付。World 每周通过 Alchemy 的 bundler 和 paymaster 基础设施运行超过 1200 万笔交易。用户体验的标准是即时、免费,且与传统金融科技应用无法区分。

Alchemy 目前在所有 EVM 链和 Solana 的无 gas 交易市场中占据约 85% 的市场份额,过去两年累计处理金额超过 10 亿美元。

基于无 gas 基础设施构建

管理 paymaster 基础设施、KMS 签名、多链 gas 估算和协议迁移,并不能让产品形成差异化。用户从不知道也不关心自己的 gas 是如何被赞助的——他们只知道转账既快速、便宜又简单。

Alchemy 承担基础设施的复杂性,让团队能够专注于真正推动业务发展的事情:交付功能、增长用户,以及创造收入。最好的无 gas 交易体验,就是没有人会注意到的那种。

探索无 gas 基础设施,开始构建,或联系我们获取定制定价、集成问题解答等更多信息。我们随时为你提供帮助!

常见问题

什么是无 gas 交易?

无 gas 交易允许应用代表用户赞助 gas 费用,使终端用户无需持有、获取或考虑像 ETH 这样的原生代币即可完成区块链交易。

无 gas 交易是如何运作的?

开发者创建 gas 策略,用户通过应用发起交易,Alchemy 根据策略进行校验,签署 paymaster 负载,随后 paymaster 智能合约在链上支付 gas,开发者则收到一份美元账单。

无 gas 交易中的 paymaster 是什么?

paymaster 是一种智能合约,用于验证加密签名,并为被赞助的交易垫付原生代币形式的 gas,从而让应用而非终端用户来承担 gas 成本。

我需要持有 ETH 或原生代币来为用户赞助 gas 吗?

不需要,Alchemy 会在所有支持的链上以原生代币垫付 gas,并在月末提供单一的美元账单,因此开发者无需持有波动性的原生代币。

什么是 ERC-4337,它与无 gas 交易有什么关系?

ERC-4337 引入了账户抽象(Account Abstraction),并标准化了 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 估算、签名和账单核对。

Background gradient

构建区块链应用

Alchemy 将最强大的 Web3 开发者产品和工具与资源、社区及专业支持结合在一起。