逻辑陷阱型蜜罐合约

蜜罐是传统安全领域中的一个概念，通常指安全人员设置一些陷阱（比较明显的漏洞），让攻击者自己掉入我们设置好的陷阱中，以便安全人员分析攻击者的作恶手法。

蜜罐合约（HoneyPots Contract）也是类似的概念，但对象变了，一般指合约开发者设置了看似容易获利的合约逻辑，但其实是陷阱，普通用户观察合约，发现有利可图，便与蜜罐合约交互，结果发现交互的资产无法被自己提出。

蜜罐合约在中文圈子有时也称为貔貅合约，本文将简单讨论一下，我看见的几种逻辑陷阱型蜜罐合约。

逻辑陷阱蜜罐合约

比较多项目会在transfer函数（转账相关）中实现一些业务逻辑，蜜罐合约可能在transfer函数中加入一些强行限制用户交易的逻辑，从而实现截取用户资产的效果。

这类合约，我称为逻辑陷阱型蜜罐合约，是比较好识别的一类，主要关注其交易相关的逻辑在合约实现上是否透明以及是否有限制则可，这里介绍三个逻辑陷阱型蜜罐合约：

• 黑名单蜜罐合约

• 可变合约构成的蜜罐合约

• 限时限卖的蜜罐合约

  黑名单蜜罐合约

  我们看到BSC上一个叫Moco合约：https://bscscan.com/address/0x9d4bDdd642529a588f910Aad405C07e066A908Cf#code

  Moco合约继承了ERC20，即是一个代币合约，看到合约中的_transfer函数，部分代码如下：

  function _transfer(address sender, address recipient, uint256 amount) private returns (bool) {
      require(sender != address(0), "ERC20: transfer from the zero address");
      require(recipient != address(0), "ERC20: transfer to the zero address");
      require(!_isbclisted[recipient] && !_isbclisted[sender], "bclisted address");
      // ...

  在用户进行交易时，会调用_transfer函数，它有3个require做条件判断，主要看到第三个，判断sender与recipient都不在黑名单内，才能进行交易。

  根据_isbclisted进行搜索，可以发现addBot函数实现了将用户地址加入黑名单的操作。

  function addBot(address recipient) internal {
        if (!_isbclisted[recipient]) _isbclisted[recipient] = true;
    }

  那什么地方调用了addBot函数呢？搜索一下，发现还是在_transfer函数中，相关代码如下：

  if(sender == uniswapPair) {
      if (block.number  uint256)类型的变量，通过这些变量来记录转账的值。 
   
  看到_transfer函数，有限制交易时间与限制交易金额比例的逻辑，相关代码如下：
   
   
  // 限制交易时间
  if(block.timestamp