设想这样一个场景 ：你被DeFi的高收益所吸引 ，所以决定将交易所里的元交易USDC全部提到钱包 ，然后投入到DeFi中，新型在提现完成后 ，授权你钱包确实收到了USDC，钓鱼但你发现你不能完成任何链上操作 ，风险不能交易，浅谈不能质押 。太坊所以 ，元交易你又需要重新从交易所中购买一些ETH再提到钱包....
在常规情况下 ，新型用户想要在区块链上发布一笔交易 ，授权需要账户内有足够的钓鱼的免费模板原生代币（native coin ，ETH 、风险BTC这类）作为交易手续费 ，浅谈然后才能上链 。而在使用元交易的情况下 ，用户可以不用自己发布交易 ，转而委托中继者（relay）代为发布 ，这样自然也就不需要用户自己有足够的的原生代币 。
要实现交易委托，需要目标智能合约支持元交易 ，实现的方式一般是使用消息签名技术 ，亿华云使用钱包进行签名是不需要任何手续费的 ，因为这完全是链下行为 ，用户构造相应的元交易数据 ，并签名 ，然后将这些信息发送给中继者 ，接着中继者再对目标合约进行调用 ，并附带数据与签名，目标合约收到这些信息后进行验证后再执行相应的业务。
有一点要搞明白 ，元交易虽然是GasLess（免gas）的云计算 ，但并不代表无需手续费 ，是否需要付出手续费 ，以及付出何种资产作为手续费，主要取决于中继者 ，一般来说 ，可以用主流token支付 ，所以你需要再签署一笔向中继者支付手续费的元交易。
总而言之，元交易的本质是一组信息凭证 ，是用户期望行为的高防服务器一种证明，且具有真实的可执行力 ，第三方可以拿这些信息替用户执行想要执行的动作。
二 、ERC20-permit(EIP-2612)场景继续 ：当你准备购买ETH作为手续费时 ，你突然发现 ，USDC居然支持元交易 ，只需要签署一则消息即可完成授权 ，简直不要太方便 ！
ERC20是在以太坊上面创建token的实现标准 ，但是它并不支持元交易 ，源码下载如果token需要支持授权元交易 ，则需要按照EIP-2612的规范来进行扩展 ，如下 ：
新增了3个函数 ：
复制function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external function nonces(address owner) external view returns (uint) function DOMAIN_SEPARATOR() external view returns (bytes32)1.2.3. permit函数 ：一般由中继者调用，负责验证参数与签名是否相符 ，然后进行授权（approve）操作nonces函数：返回指定用户的nonce ，在每次permit之后 ，nonce递增 ，为了防止一笔元交易被重复执行DOMAIN_SEPARATOR函数 ：根据chainId 、合约地址等信息生成一个唯一散列 ，防止一笔元交易在其他EVM链（ETC 、BSC等）上被重放最重要的是permit函数，源码库所以看一下这个函数的具体实现 ，这里参考uniswap：
https://github.com/Uniswap/v2-core/blob/master/contracts/UniswapV2ERC20.sol
复制function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external { require(deadline >= block.timestamp, UniswapV2: EXPIRED); bytes32 digest = keccak256( abi.encodePacked( \x19\x01, DOMAIN_SEPARATOR, keccak256(abi.encode(PERMIT_TYPEHASH, owner, spender, value, nonces[owner]++, deadline)) ) ); address recoveredAddress = ecrecover(digest, v, r, s); require(recoveredAddress != address(0) && recoveredAddress == owner, UniswapV2: INVALID_SIGNATURE); _approve(owner, spender, value); }1.2.3.4.5.6.7.8.9.10.11.12.13.很短几行代码，可以看到 ，在进行了验签以及其他检测后，会执行授权操作 ，所以整个流程其实很简单 ，用户完成链下签名 ，中继进行链上调用 ，仅此而已 。
三 、 隐患场景最后 ：钱包弹出了”请求签名“ ，上面的信息你有些看不懂 ，但是钱包并没有任何警告信息 ，也不用花钱 ，你很轻易的完成了确认 ，两分钟后 ，你钱包里的USDC全都消失了...
毫无疑问 ，与approve授权钓鱼类似 ，元交易也是存在钓鱼风险的 ，只要窃取到了签名 ，就窃取到了授权 ，更加危险 ，更容易中招 ，相对来说 ，元交易钓鱼目前存在以下”优势“
1 、主流币种支持虽然元交易尚未普及，但也有不少主流币种支持了ERC20-permit ：
USDCDAIUNI1INCHENS2 、警告信息缺失相对于approve授权钓鱼 ，钱包对于元交易授权的警告几乎没有 ，以下测试了最新版本的主流钱包告警情况
MetaMask ，无特别提醒
TokenPocket ，无特别提醒 ，签名内容未处理
imtoken ，无特别提醒
传统的授权钓鱼会在链上留下approve记录 ，而元交易钓鱼完全是链下行为，却又能够影响链上 ，对于元交易签名已泄露的用户来说 ，是一个定时炸弹 ，而且还不自知 。
4、成本低廉对于需要上链的操作 ，由于操作成本等原因 ，用户会相对谨慎 ，但对于链下签名，就会放松很多了 ，且无需成本 ，用户也很难会意识到签名操作也会影响到资产安全 。
5 、难以理解除了基于EIP-2612实现的ERC20授权元交易外 ，还有很多项目方自己设计的元交易实现 ，而这些实现是非标准的 ，所以也无法被钱包所理解 ，并形成相应的警告，用户也很难理解其中含义 。
技术雷达站
