三明治机器人原理

1. 有人使用较大的滑点进行交易, 称此交易为 victim tx ，后面简称为 vtx

2. 滑点代表的是对价格上升的容忍程度，较大的滑点导致在 vtx 买入代币，并且在 vtx 之后卖出代币的模式变得有利可图

3. 三明治机器人构造 buy tx 和 sell tx（可能还有额外的 approve tx，以保证卖出交易的成功），并且将这些交易与原始的 vtx 按照如下顺序排列：[buy tx, vtx, approve tx(optional), sell tx]

4. 找一个类似 flashbots 的交易捆绑服务商，将上面的交易 bundle(即上述的 tx 数组) 提交

构造一个三明治机器人的主要难点：

1. 检测到有利可图的交易、协议

2. 在合理的时间范围内构造出利润最大化的 bundle

个人感觉第 1 点，尤其对于短暂出现的 alpha 机会, 才是真正的难点。比如本例中的 meme 协议，合并并未开源，如何从一份未开源合约中提取到完成套利机器人的相关信息，是很复杂的.如何完成这一点在本文中不再展开，我们只需要知道 meme 协议是一个常量乘积 AMM 算法：即

x * y = k 并且会收取一定的交易手续费（体现在后续代码中的 fee_rate 和 min_fee）

下面主要讲套利交易构造部分: fourmeme-god 是基于 burberry (一个模块化的 mev 开发框架) 开发的。burberry 中, 一个 mev 项目被模块化的分解为:

• collector(s), 负责搜集数据。支持多方数据源，异构数据源等

• strategy, 负责解析搜集的数据,并且根据套利算法进行套利交易的构造

• executor, 负责执行套利交易的最终执行

在本项目中, collectors 采用了两个 burberry 内置的数据采集类，主要负责采集最新的区块信息和 mempool pending tx 信息.两个数据源的主要作用分别为:

• block 信息用于探测其他机器人竞争者，并且在后续的三明治套利中避免处理这些机器人地址的相关交易

• pending tx 信息用于识别潜在的 victim tx.

在 strategy 中整体流程如下:

1. 检查交易是不是一个 meme::Buy tx （通过解析 tx.data）

2. 对于 buy 交易，根据 meme 当前池子信息和这个 buy tx 信息，计算最优的三明治交易组合(即计算提前买入多少)

3. 计算一下加上 gas 消耗以后是否还有利可图(gas 根据链上交易设定固定值进行估算)

4. 构造 bundle 提交到区块链上完成交易(未实现，可以自己选择 bundle 服务提供商)

这里重点讲一下 search::go 的逻辑。在不考虑任何数学和代码之前，很容易得到一个感性的结论:

• 在一个临界点之前, 三明治机器人的利润肯定是随着买入 mev 机器人提前买入的代币数量的增加而增加。

• 这个临界点存在的原因是买入太多会导致滑点太大，进而让 victim tx 失败 那如何找到这个临界点呢? 这里简单使用了一个类似二分搜索法的搜索: 将输入区间标记为 4 个点

起点----起点+m(A)----起点+2m(B)----终点

我们只需要反复比较买入量为 A 和 B 时候，机器人的利润，然后再进行区间的收缩即可。即如果 Porfit(B) < Profit(A) ，则代表 B 已经超过了上面提到的临界点，最优解必然在起点到 B 之间的一个点, 我们重新对这部分输入进行等分搜索。通过反复迭代，我们可以找到最优解。(你可以问问 ai 看看有什么更好的寻求解的办法)需要指出的是，因为 mev 本质上还是需要和时间赛跑，而且最优解也没有那么重要，所以迭代次数被设置为 100，这个数据可以根据你的 CPU 性能进行调优（比如机器差，就改小点，机器好就调大一点）.

至于如何计算利润也比较简单，流程也是比较明朗的，给定你希望买入的 eth 数量(也就是 amount_in):

1. 先计算可以 buy tx 的 amount_out(买入的代币数量)

2. 模拟更新池子信息(内存中的数据)

3. 按照 victim tx 进行计算, 得到 victim tx 真正可以得到的代币

4. 模拟更新池子信息

5. 构造卖出交易(卖出数量为 1 中的 amount_out), 得到卖出获取的 eth 数量

6. 计算 mev 机器人的整体收益，即最终卖出 ETH 的数量减去 amount_in + fee

至此主要的逻辑我已经梳理完成,不过在读代码的过程中，我也遇到一些不理解的地方:

1. 在搜索最优解的时候，trial_ultimate(&mut context, lower_bound + m) 函数调用使用的相同的 context 引用，这会持续修改 context(也就是内存中虚拟池子的信息),但是这个修改其实是不应该发生的，也就是计算不同点的利润的时候，输入都应该是相同的 context. 不确定是代码确实有问题还是我的理解有误. 后面希望可以和作者请教讨论

1. 如何应用 EIP1167 来低成本的创建大量的代理合约以及其需要注意的点

2. immutable 的妙用

所有代码均在代码仓库中

https://github.com/neal-zhu/batcher.git

找到欢迎大家 clone & 玩耍 & star

在文章

https://mirror.xyz/0x3dbb624861C0f62BdE573a33640ca016E4c65Ff7/VoBIa7fC_lNLw6TPutj16KztvnQffDdBOv_A1Z2AxUw

中，我们实现了一个简单的通用型薅羊毛合约。但是在后续的测试过程中发现其有一个致命问题: 一次无法创建大量子合约地址。比如如果我们试图创建 100 个地址，则会报错（即使将 gasLimit 设置为 3000w）：

子合约太长导致报错这搞毛啊，说好的批量撸羊毛的，100 个地址都做不到，那还怎么玩？好在天无绝人之路，在各个 web3 技术群中发现了一个叫做 mini proxy 的神器，具体文档参考下面链接：

https://mirror.xyz/xyyme.eth/mmUAYWFLfcHGCEFg8903SweY3Sl-xIACZNDXOJ3twz8

限于篇幅，本文不会仔细的分析 mini proxy 的原理，大家只需要记住几个关键点：

1. mini proxy 合约非常短，只有 45 个字节

2. mini proxy 合约创建后没有存储任何数据（也就是未指定 owner），所以可以被 EOA 地址直接调用

3. mini proxy 会将所有调用，通过 delegatecall 转发到 logic 合约中

看看如何集成 miniproxy，代码(有 BUG 版本）如下：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.7;
import "hardhat/console.sol";

contract BatcherV2 {
    // https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1167.md
    bytes32 byteCode;
    uint n;
    address private immutable deployer;
    
    constructor(uint _n) {
        deployer = msg.sender;
        n = _n;
        createProxies(_n);
    }

    function createProxies(uint _n) internal {
        bytes memory miniProxy = bytes.concat(bytes20(0x3D602d80600A3D3981F3363d3d373d3D3D363d73), bytes20(address(this)), bytes15(0x5af43d82803e903d91602b57fd5bf3));
        byteCode = keccak256(abi.encodePacked(miniProxy));  
        address proxy;
        for(uint i=0; i<_n; i++) {
            bytes32 salt = keccak256(abi.encodePacked(msg.sender, i));
            assembly {
                proxy := create2(0, add(miniProxy, 32), mload(miniProxy), salt)
            }
        }
    } 

    function execute(address target, bytes memory data) external {
        require(msg.sender == deployer, "Only deployer can call this function.");
        for(uint i=0; i<n; i++) {
            address proxy = proxyFor(msg.sender, i);
            BatcherV2(proxy).callback(target, data);
        }
    }

    function callback(address target, bytes memory data) external {
        (bool success, ) = target.call(data);
        require(success, "Transaction failed.");
    }


    function proxyFor(address sender, uint i) public view returns (address proxy) {
        bytes32 salt = keccak256(abi.encodePacked(sender, i));
        proxy = address(uint160(uint(keccak256(abi.encodePacked(
                hex'ff',
                address(this),
                salt,
                byteCode
            )))));
    }

}

关于这次的代码，架构要比之前的更加复杂，BatcherV2 不但是我们的门面合约，而且还作为 mini proxy 的 logic 合约。目前的调用时序图如下:

现在我们来对上述合约的改动进行逐步分析:

1. createProxies 里面就是 MiniProxy 的创建代码，更为细致的解释可以参考上面的 github 链接。同时注意我们这里使用了 create2 来创建确定性地址合约。

2. callback 很简单，就是执行传来的任意 tx将部署 proxy 数量改为 100，

3. fallback 函数没有了，取而代之的是 execute 函数，其职能基本与之前的 fallback 一样，就是将调用转发到每一个 mini proxy 合约。有两点需要着重强调下：

   1. BatcherV2(proxy).callback(target, data); 这行代码值得详细说一下：因为 Batcher 是 MiniProxy 的 logic 合约，所以其实对 MiniProxy 的调用，最终都会落到 Batcher 自己身上，所以我们可以直接将 proxy 转换为一个 BatcherV2 调用 callback ，但是请务必注意，这个 fallback 是 MiniProxy 通过 delegatecall 调用的！

   2. proxy 的创建是使用 create2，所以我们在 proxyFor 处，动态的计算每个 MiniProxy 合约的地址

在仓库中运行

npx hardhat test

可以得到测试通过的输出

成功，非常好！除了我们的合约还存在一个极大的安全隐患！前面提到过 MiniProxy 刚创建时并为指定 owner，所以任何人都可以直接对其调用 claimMintRewardAndShare 方法。看下面的具体测试代码:

黑客直接调用 proxy对应的测试输出如下:

一个黑客直接获取到了我们一个（当然也可以全部拿走） mini proxy 的地址，然后直接在 mini proxy 合约上调用 callback() 取走了我们的 XEN。

那这个问题如何修复呢？一个很直接的想法就是，添加断言，只允许 Batcher 调用 MiniProxy，对应修复代码如下

:...skip
// 添加变量到第一个位置, 记录 batcher 地址
address private original;
    constructor(uint _n) {
        original = address(this);
        deployer = msg.sender;
        n = _n;
        createProxies(_n);
    }
    function callback(address target, bytes memory data) external {
        require(msg.sender == original, "Only original can call this function.");
        (bool success, ) = target.call(data);
        require(success, "Transaction failed.");
    }

看起来好像没问题，但是测试结果却给我们当头一棒，输出结果如下:

黑客确实偷不走了，合约也报废了！

这是为什么呢？其实接触过 proxy 模式的同学想必已经发现了问题所在：因为 delegatecall 会保留当前执行的上下文，即虽然 callback 是 Batcher 中的代码，但是执行的时候，却在 MiniProxy 的存储上下文：msg.sender == original 其实会被翻译成 msg.sender == slot0，而很不幸， MiniProxy 什么都没存（可以通过检查 MiniProxy 的 slot 来确定）。所以这个断言永远不可能成立。这怎么办呢？

一个最直观的办法是在 logic 合约（也就是本文的 Batcher）里面提供一个设置 owner 的接口，在每个 mini proxy 创建之后再调用一下设置 owner 的接口即可。

但是本人无意间发现了一个神奇的修饰词: immutable，其与 const 有一个重要特性:

太神奇了，immutable 变量在初始化之后，后续的使用都会被直接替换而不需要存储在 slot 中。msg.sender == original 的判断，将不再需要读取 storage，退化成类似和一个常量的比较！将 original 改为 immutable 之后，重新测试，终于完美通过:

最后让我们总结一下技术要点：

1. mini proxy 可以低成本创建大量的 proxy 合约，但是需要额外的机制保证不被黑客直接调用 proxy 合约

2. 代理模式下一定要注意权限的控制，以及上下文切换时一些违反直觉的情况

3. immutable 变量不占用任何 storage slot，可以与 mini proxy 完美配合，实现对 proxy 使用权的控制

1. 如何实现一个通用的、可复用的薅羊毛合约（仅供参考，本人是 Solidity 菜鸡， 相关代码可以在

   <https://github.com/neal-zhu/batcher >

   找到）

对于一些空投 token，free mint nft 项目，项目方有时候可能会无意（甚至是有意）的给科学家留下发挥的空间。这方面比较出名的有早前的小学生项目 RND，近有最近罕见的热点项目 Xen。这些项目的主要特点是合约代码中未进行 tx.origin == msg.sender 的判断。

有文章

<https://mirror.xyz/hackbot.eth/plbO7co90A6JhKSRSMsstrcP-X8CpfnaRs7k3HI3loY >

中有介绍如何通过运行时创建大量子合约来批量领取大量 RND 代币。主要代码如下：

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.9;

// Uncomment this line to use console.log
// import "hardhat/console.sol";

interface airdrop {
    function transfer(address recipient, uint256 amount) external;
    function balanceOf(address account) external view returns (uint256);
    function claim() external;
}

contract multiCall{
    //                                此处填写 RND 代币的合约地址
    address constant contra = address(0xcb33F7FB101E377a4b0e19fD647F391fAD14d0B5);
    function call(uint256 times) public {
        for(uint i=0;i<times;++i){
            new claimer(contra);
        }
    }
}
contract claimer{
    constructor(address contra){
        airdrop(contra).claim();
        uint256 balance = airdrop(contra).balanceOf(address(this));
        airdrop(contra).transfer(address(tx.origin), balance);
        selfdestruct(payable(address(msg.sender)));
    }
}

上面的代码实现清晰明了，但是也有一个明显的问题，即不具备可复用性。因为项目方不同，而且在空投这件事情上，也并不存在所谓的 ERCxxx 标准，所以可以撸 RND 项目的合约代码，往往在其他项目上就失效了。这也是为什么这种合约往往在撸毛结束以后，都会销毁批量创建的子合约。

这样导致了一些问题：

1. 面对不同项目时候，需要做更多重复的工作（部署合约，对合约进行小修改）

2. 多个项目，反复的批量创建、销毁合约， gas 消耗会更高

3. 大家都在撸的时候，进行的一些列包括部署、调用等操作，成本会更高

比如最近大火的 Xen，除了合约地址不同，其交互流程也更为复杂：

1. 调用 claimRank(uint256)

2. 挖矿时间足够以后，调用 claimMintReward() or claimMintRewardAndShare(address, uint256)

大家只好再起炉灶，赶紧写一份大体一致的代码，然后开始部署调用等操作。比如下面这份用来撸 Xen 的代码：

/**
 *Submitted for verification at Etherscan.io on 2022-10-10
*/

// SPDX-License-Identifier: MIT
pragma solidity 0.8.17;

interface IXEN1{
    function claimRank(uint256 term) external;
    function claimMintReward() external;
    function approve(address spender, uint256 amount) external returns (bool);
}

interface IXEN2{
    function transferFrom(
        address from,
        address to,
        uint256 amount
    ) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
}

contract GET{
    IXEN1 private constant xen = IXEN1(0x06450dEe7FD2Fb8E39061434BAbCFC05599a6Fb8);

    constructor() {
        xen.approve(msg.sender,~uint256(0));
    }
    
    function claimRank(uint256 term) public {
        xen.claimRank(term);
    }

    function claimMintReward() public {
        xen.claimMintReward();
        selfdestruct(payable(tx.origin));
    }
}
/// @author 捕鲸船社区 加入社区添加微信:Whaler_man 关注推特 @Whaler_DAO
contract GETXEN {
    mapping (address=>mapping (uint256=>address[])) public userContracts;
    IXEN2 private constant xen = IXEN2(0x06450dEe7FD2Fb8E39061434BAbCFC05599a6Fb8);
    address private constant whaler = 0x918Cb3c935d82eE20F4986158dFA755048F41d47;

    function claimRank(uint256 times, uint256 term) external {
        address user = tx.origin;
        for(uint256 i; i<times; ++i){
            GET get = new GET();
            get.claimRank(term);
            userContracts[user][term].push(address(get));
        }
    }

    function claimMintReward(uint256 times, uint256 term) external {
        address user = tx.origin;
        for(uint256 i; i<times; ++i){
            uint256 count = userContracts[user][term].length;
            address get = userContracts[user][term][count - 1];
            GET(get).claimMintReward();
            address owner = tx.origin;
            uint256 balance = xen.balanceOf(get);
            xen.transferFrom(get, whaler, balance * 10 / 100);
            xen.transferFrom(get, owner, balance * 90 / 100);
            userContracts[user][term].pop();
        }
    }
}

不难发现，两份合约代码主体框架是极为相似的，完全可以用一种更加通用的合约来尝试替代。实现思路也很简单：尽量让所有 hardcode 的部分动态化，作为参数传入。同时，因为这些合约已经可以复用，我们不再每次都动态批量创建合约，而是可以反复复用。实现的代码也很简单:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.9;

// Uncomment this line to use console.log
import "hardhat/console.sol";

// ERC20 interface
interface ERC20 {
    function transfer(address recipient, uint256 amount) external;
    function balanceOf(address account) external view returns (uint256);
}

// Proxy contract to execute multiple transactions
contract Proxy {
    address public owner;

    constructor(address _owner) {
        owner = _owner;
    }

    // only owner modifier
    modifier onlyOwner() {
        require(msg.sender == owner, "Only owner can call this function.");
        _;
    }

    // withdraw all tokens
    function withdraw(address token) public onlyOwner {
        uint256 balance = ERC20(token).balanceOf(address(this));
        ERC20(token).transfer(tx.origin, balance);
    }

    // withdraw all ETH
    function withdrawETH() public onlyOwner {
        payable(tx.origin).transfer(address(this).balance);
    }

    // execute encodeed transaction
    function execute(address target, bytes memory data)
        public
        payable
        onlyOwner
    {
        (bool success, ) = target.call(data);
        require(success, "Transaction failed.");
    }

    // Destroys this contract instance
    function destroy(address payable recipient) public onlyOwner {
        selfdestruct(recipient);
    }
}

contract Batcher {
    address public owner;
    Proxy[] public proxies;

    constructor(uint256 _n) {
        owner = msg.sender;
        // create proxy contracts, we will not destroy them
        for (uint256 i = 0; i < _n; i++) {
            // create with salt
            Proxy proxy = new Proxy{salt: bytes32(uint256(i))}(address(this));
            // append to proxies
            proxies.push(proxy);
        }
    }

    function getBytecode() public view returns (bytes memory) {
        bytes memory bytecode = type(Proxy).creationCode;
        return abi.encodePacked(bytecode, abi.encode(msg.sender));
    }

    function getAddress(uint256 _salt) public view returns (address) {
        // Get a hash concatenating args passed to encodePacked
        bytes32 hash = keccak256(
            abi.encodePacked(
                bytes1(0xff), // 0
                address(this), // address of factory contract
                _salt, // a random salt
                keccak256(getBytecode()) // the wallet contract bytecode
            )
        );
        // Cast last 20 bytes of hash to address
        return address(uint160(uint256(hash)));
    }

    fallback() external payable {
        require(owner == msg.sender, "Only owner can call this function.");
        // delegatecall to proxy contracts
        for (uint256 i = 0; i < proxies.length; i++) {
            address proxy = address(proxies[i]);
            (bool success, ) = proxy.call(msg.data);
            require(success, "Transaction failed.");
        }
    }

    receive() external payable {}
}

在我们的合约中主要有两个角色:

1. Proxy，即批量创建的合约，其主要作用就是动态的执行任何传入的 tx 数据，这样我们可以让 Proxy 以任何我们想要的姿势和项目方代码进行交互。

2. Batcher，门面合约，负责将交互 tx 转发到所有创建的 Proxy。任何对此合约的调用，最终都会转换为在 N 个 Proxy 合约上的操作。

以交互 Xen 为例，我们需要在 hardhat 中添加类似代码来实现交互:

require("@nomicfoundation/hardhat-toolbox");

const xenAddress = "0x06450dEe7FD2Fb8E39061434BAbCFC05599a6Fb8";
const xenABI = [] // skip

const batcherABI = [
  "function execute(address, bytes) payable",
  "function withdraw(address)",
  "function withdrawETH(address)",
  "function destroy()",
]

async function increaseTime(value) {
  if (!ethers.BigNumber.isBigNumber(value)) {
    value = ethers.BigNumber.from(value);
  }
  await ethers.provider.send('evm_increaseTime', [value.toNumber()]);
  await ethers.provider.send('evm_mine');
}

task("xen_claim_rank", "claimRank for xen").setAction(async (taskArgs, hre) => {
  const signer = (await hre.ethers.getSigners())[0];
  const xen = new hre.ethers.Contract(xenAddress, xenABI, signer);

  const batcher = new hre.ethers.Contract(taskArgs.batcher, batcherABI, signer);
  let tx = await batcher.execute(xenAddress, xen.interface.encodeFunctionData("claimRank", [1]));
  await tx.wait();

  console.log("XEN balance: ", (await xen.balanceOf(signer.address)).toString());

}).addParam("batcher", "address of batcher contract")

task("xen_claim_reward", "claim reward for xen").setAction(async (taskArgs, hre) => {
  const signer = (await hre.ethers.getSigners())[0];

  const xen = new hre.ethers.Contract(xenAddress, xenABI, signer);

  // increase and mine time so we can claimReward
  // FOR TEST ONLY
  await increaseTime(24*60*60);

  const batcher = new hre.ethers.Contract(taskArgs.batcher, batcherABI, signer);
  tx = await batcher.execute(xen.address, xen.interface.encodeFunctionData("claimMintRewardAndShare", [signer.address, 100]));
  await tx.wait();

  console.log("XEN balance: ", (await xen.balanceOf(signer.address)).toString());

}).addParam("batcher", "address of batcher contract")

我们只需要依次执行:

1. npx hardhat --network localhost run scripts/deploy.js # 如果已经部署过 batcher 合约，则不需要重复部署

2. npx hardhat --network localhost xen_claim_rank --batcher {batcherAddress}

3. npx hardhat --network localhost xen_claim_reward --batcher {batcherAddress}

观察 hardhat 中的脚本代码，不难看出，我们这次的重构本质是: 将链上代码搬移到链下。本来写在 Solidity 合约中的业务逻辑，出现在了 javascript 脚本中。

最后来总结下改造之后对比之前方案的优劣:

• 优点：

  • 可以在 gas 低的时候创建好批量合约，等热点项目出来的时候降低 gas 成本

  • 减少了部分重复性操作（比如大体框架一致的合约代码开发，新合约部署等）

  • javascript 代码的调试、迭代比 Solidity 更加便利

• 缺点：

  • 合约代码明显更加复杂，总体的开发量并没有减少