Next.js 服务端动作在 DApp 中的应用：交易构建、签名中继与安全边界

Next.js 服务端动作在 DApp 中的应用：交易构建、签名中继与安全边界

一、Server Actions 为什么是 DApp 前端的范式转移

传统的 DApp 前端架构遵循"链上一切"原则：用户在浏览器中签名，交易通过 MetaMask 注入的 provider 直接广播到节点。这套模式简单直接，但也暴露了明显的问题——私钥管理分散在客户端，签名逻辑暴露在浏览器环境中，复杂的交易构建（如多步 DeFi 操作）在前端完成导致代码臃肿且难以调试。

Next.js 的 Server Actions 为 DApp 带来了一个新的选项：将交易构建、Gas 估算、签名中继等逻辑移到服务端。服务端持有应用级私钥（或通过 MPC/TSS 管理），前端只负责用户意图的收集和 EIP-712 签名授权的获取。这种架构转变不是要替代用户签名，而是重新划分客户端与服务端的职责边界。

二、服务端交易中继的架构设计

sequenceDiagram participant Browser as 浏览器端 participant SA as Server Action participant Bundler as 交易打包服务 participant SC as 智能合约 participant AAWallet as AA 钱包/中继器 Browser->>SA: 1. 提交交易意图 + EIP-712 授权签名 SA->>SA: 2. 验证签名来源与权限 SA->>SA: 3. 构建交易 calldata + Gas 估算 SA->>Bundler: 4. 提交 UserOperation Bundler->>SC: 5. handleOps 批量执行 SC-->>Bundler: 6. 执行结果 Bundler-->>SA: 7. UserOpReceipt SA-->>Browser: 8. 交易哈希 + 回执

Server Action 在 DApp 中的核心价值在于三个环节：

交易构建的复杂度隔离。一个涉及 AMM 套利的交易需要先查询多个池子的储备量，计算最优路径，构造多跳 swap 的 calldata。这些逻辑放在前端，不仅增加 bundle 体积，还需要暴露 RPC endpoint。迁移到 Server Action 后，计算在服务端完成，前端只需传入用户的 swap 意图。

Gas 策略的集中管理。服务端可以监控各链的 Gas 价格，按区块空间需求自动选择最优的 Gas 参数（maxFeePerGas、maxPriorityFeePerGas）。结合 EIP-1559 的 baseFee 预测，可以显著降低用户在 Gas 高峰期的额外支出。

签名的责任分离。用户的 EOA 签名只用于授权意图（EIP-712 typed data），实际的交易由服务端的中继器账户提交。这种分离意味着用户的钱包不需要持有 Gas Token，可以由中继器代为支付后从交易中结算。

三、实现：安全的服务端交易中继器

以下实现展示如何在 Next.js Server Action 中构建一个生产级交易中继，包含签名验证、nonce 管理和 Gas 估算。

// app/actions/relayTransaction.ts 'use server'; import { ethers } from 'ethers'; import { createPublicClient, http, parseEther } from 'viem'; import { base } from 'viem/chains'; import { z } from 'zod'; // 多链 Provider 映射 const chainProviders: Record<number, ethers.JsonRpcProvider> = { 8453: new ethers.JsonRpcProvider(process.env.BASE_RPC_URL), 1: new ethers.JsonRpcProvider(process.env.ETHEREUM_RPC_URL), 42161: new ethers.JsonRpcProvider(process.env.ARBITRUM_RPC_URL), }; /** * 中继器钱包 * 设计决策：使用环境变量管理私钥，生产环境应迁移到 KMS/HSM 或 MPC 方案 * 中继器钱包需要持有各链 Gas Token，余额监控由独立定时任务负责 */ const relayWallet = new ethers.Wallet( process.env.RELAYER_PRIVATE_KEY!, chainProviders[8453] ); // 输入验证 Schema const RelayRequestSchema = z.object({ chainId: z.number().int().positive(), to: z.string().regex(/^0x[a-fA-F0-9]{40}$/), data: z.string().regex(/^0x[a-fA-F0-9]*$/), value: z.string().regex(/^\d+$/).default('0'), userAddress: z.string().regex(/^0x[a-fA-F0-9]{40}$/), // 用户对交易意图的 EIP-712 签名 userSignature: z.string().regex(/^0x[a-fA-F0-9]+$/), deadline: z.number().int().positive(), }); // EIP-712 域定义 const DOMAIN = { name: 'DAppRelayer', version: '1', chainId: 8453, verifyingContract: process.env.NEXT_PUBLIC_ENTRYPOINT_ADDRESS! as `0x${string}`, }; const RELAY_TYPES = { RelayRequest: [ { name: 'chainId', type: 'uint256' }, { name: 'to', type: 'address' }, { name: 'data', type: 'bytes' }, { name: 'value', type: 'uint256' }, { name: 'userAddress', type: 'address' }, { name: 'deadline', type: 'uint256' }, ], } as const; // Nonce 管理器 const pendingNonces = new Map<string, number>(); export async function relayTransaction(formData: FormData) { const raw = Object.fromEntries(formData.entries()); // 严格校验输入，防止注入攻击 const parsed = RelayRequestSchema.safeParse({ chainId: Number(raw.chainId), to: raw.to, data: raw.data, value: raw.value || '0', userAddress: raw.userAddress, userSignature: raw.userSignature, deadline: Number(raw.deadline), }); if (!parsed.success) { return { error: 'Invalid input', details: parsed.error.flatten() }; } const { chainId, to, data, value, userAddress, userSignature, deadline } = parsed.data; // 检查 deadline 是否已过期 if (Date.now() / 1000 > deadline) { return { error: 'Request expired' }; } // 验证 EIP-712 签名 const recoveredAddress = ethers.verifyTypedData( DOMAIN, RELAY_TYPES, { chainId, to, data, value, userAddress, deadline }, userSignature ); if (recoveredAddress.toLowerCase() !== userAddress.toLowerCase()) { return { error: 'Invalid signature' }; } // Nonce 管理 const provider = chainProviders[chainId]; if (!provider) { return { error: `Unsupported chain: ${chainId}` }; } const relayAddr = relayWallet.address; const currentNonce = pendingNonces.get(relayAddr) ?? await provider.getTransactionCount(relayAddr); try { // Gas 估算 const gasLimit = await provider.estimateGas({ from: relayAddr, to, data, value: parseEther(value), }); const feeData = await provider.getFeeData(); // 发送中继交易 const tx = await relayWallet.sendTransaction({ to, data, value: parseEther(value), nonce: currentNonce, gasLimit: (gasLimit * 120n) / 100n, // 20% buffer maxFeePerGas: feeData.maxFeePerGas ?? undefined, maxPriorityFeePerGas: feeData.maxPriorityFeePerGas ?? undefined, chainId, }); pendingNonces.set(relayAddr, currentNonce + 1); return { success: true, txHash: tx.hash, }; } catch (err) { const message = err instanceof Error ? err.message : 'Unknown error'; // 如果 nonce 冲突，清除缓存让下次请求重新查询 if (message.includes('nonce')) { pendingNonces.delete(relayAddr); } return { error: message }; } }

前端调用 Server Action 的方式：

// components/RelayForm.tsx 'use client'; import { relayTransaction } from '@/app/actions/relayTransaction'; import { useAccount, useSignTypedData } from 'wagmi'; import { DOMAIN, RELAY_TYPES } from '@/lib/constants'; export function SwapRelayForm({ to, data, value }: { to: string; data: string; value: string; }) { const { address } = useAccount(); const { signTypedDataAsync } = useSignTypedData(); const handleRelay = async () => { if (!address) return; const deadline = Math.floor(Date.now() / 1000) + 300; // 5 分钟有效期 // 用户对交易意图进行 EIP-712 签名 const signature = await signTypedDataAsync({ domain: DOMAIN, types: RELAY_TYPES, primaryType: 'RelayRequest', message: { chainId: 8453, to: to as `0x${string}`, data: data as `0x${string}`, value, userAddress: address, deadline, }, }); // 通过 Server Action 中继 const formData = new FormData(); formData.append('chainId', '8453'); formData.append('to', to); formData.append('data', data); formData.append('value', value); formData.append('userAddress', address); formData.append('userSignature', signature); formData.append('deadline', String(deadline)); const result = await relayTransaction(formData); if ('error' in result) { console.error('Relay failed:', result.error); } else { console.log('Tx submitted:', result.txHash); } }; return ( <button onClick={handleRelay} disabled={!address}> 确认并中继交易 </button> ); }

四、安全边界分析

服务端私钥的单点风险。中继器钱包的私钥存储在服务端环境变量中，一旦泄露，攻击者可以提交任意交易。生产环境必须升级：使用 AWS KMS 或 Google Cloud HSM 管理私钥，通过 signature service 签名，应用层不接触原始私钥材料。更进一步的方案是采用 ERC-4337 的 Bundler 架构，将签名中继外包给去中心化的打包者网络。

签名重放的防护层次。代码中通过 deadline + nonce 双重防护：deadline 限制签名的有效时间窗口（5 分钟），nonce 确保每笔请求只被处理一次。但服务端 nonce 缓存是内存级的，进程重启后会丢失。持久化方案需要用 Redis 维护 nonce 状态，或者在链上通过 EntryPoint 合约的 nonce 机制统一管理。

MEV 攻击面的转移。当交易由服务端中继时，交易的广播策略直接影响 MEV 暴露程度。如果中继器使用公共 mempool 广播，交易可能被 MEV 搜索者前置。生产环境应连接 Flashbots Protect 或其他私有中继，避免交易在 mempool 中暴露。

Server Action 的速率限制。Server Action 是公开端点，任何人都可以调用。必须在中间件层实现基于 IP 和 userAddress 的速率限制，防止攻击者通过大量无效请求耗尽中继器的 Gas Token 或触发 RPC 提供商的速率限制。

五、总结

Next.js Server Actions 为 DApp 带来了架构层面的重新思考机会。将交易构建和签名中继迁移到服务端，核心收益有三点：前端代码简化、Gas 策略集中优化、用户签名与交易执行的职责分离。

但同时需要正视引入的新风险：服务端私钥管理、签名重放防护的持久化、MEV 暴露面的变化。这些不是 Server Actions 本身的缺陷，而是"服务端中继"这一架构模式固有的挑战。在设计具体方案时，建议从 ERC-4337 的 Account Abstraction 标准出发，尽可能复用现有的 Bundler 基础设施，避免从零构建私钥管理和 Gas 支付系统。