使用“ Standard Json-Input“验证合约

前言

在上一篇 文章中介绍了使用单个文件验证合约，以及如何扁平化合约，但是如果引用的合约文件比较多的话，不方便查看源码，今天介绍一下使用“ Standard Json-Input”验证合约

---

一、Standard Json-Input

关于Standard Json-Input的介绍可以查看solidity文档

二、举例说明

以在BSC测试网发布token为例：

1.token部分代码截图如下：

将token部署到BSC测试网，部署后的地址为：0xb6570002bad3E52d3F968B1DbdA2393478B71a16

2.新建一个FaCaiToken1.json文件

FaCaiToken1.json文件内容如下：

{
   
  "language": "Solidity",
  "sources": {
   
    "FaCaiToken1.sol": {
   
      "content": "// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol\";\nimport \"@openzeppelin/contracts/access/Ownable.sol\";\nimport \"@openzeppelin/contracts/utils/math/SafeMath.sol\";\nimport \"./aa/Ajson.sol\";\n\ncontract FaCaiToken1 is ERC20Burnable, Ownable, Ajson {\n    using SafeMath for uint256;\n    \n    uint256 public maxSupply = 10000000000 * 1e18;     // the total supply\n    uint256 public preMineSupply = 9000000000 * 1e18;\n    \n    address public minter;\n\n    constructor() ERC20(\"FaCai Token\", \"FC\"){\n        _mint(msg.sender, preMineSupply);\n    }\n\n    // mint with max supply\n    function mint(address _to, uint256 _amount) public onlyMinter returns (bool) {\n        if (_amount.add(totalSupply()) > maxSupply) {\n            return false;\n        }\n        _mint(_to, _amount);\n        return true;\n    }\n\n    function setMinter(address _minter) public onlyOwner returns (bool) {\n        // require(_minter != address(0), \"_minter is the zero address\");\n        minter = _minter;\n        return true;\n    }\n\n    // modifier for mint function\n    modifier onlyMinter() {\n        require(msg.sender == minter, \"caller is not the minter\");\n        _;\n\n    }\n\n}"
    },
    "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol": {
   
      "content": "// SPDX-License-Identifier: MIT\n\npragma solidity ^0.8.0;\n\nimport \"../ERC20.sol\";\nimport \"../../../utils/Context.sol\";\n\n/**\n * @dev Extension of {ERC20} that allows token holders to destroy both their own\n * tokens and those that they have an allowance for, in a way that can be\n * recognized off-chain (via event analysis).\n */\nabstract contract ERC20Burnable is Context, ERC20 {\n    /**\n     * @dev Destroys `amount` tokens from the caller.\n     *\n     * See {ERC20-_burn}.\n     */\n    function burn(uint256 amount) public virtual {\n        _burn(_msgSender(), amount);\n    }\n\n    /**\n     * @dev Destroys `amount` tokens from `account`, deducting from the caller's\n     * allowance.\n     *\n     * See {ERC20-_burn} and {ERC20-allowance}.\n     *\n     * Requirements:\n     *\n     * - the caller must have allowance for ``accounts``'s tokens of at least\n     * `amount`.\n     */\n    function burnFrom(address account, uint256 amount) public virtual {\n        uint256 currentAllowance = allowance(account, _msgSender());\n        require(currentAllowance >= amount, \"ERC20: burn amount exceeds allowance\");\n        unchecked {\n            _approve(account, _msgSender(), currentAllowance - amount);\n        }\n        _burn(account, amount);\n    }\n}\n"
    },
    "@openzeppelin/contracts/token/ERC20/ERC20.sol": {
   
      "content": "// SPDX-License-Identifier: MIT\n\npragma solidity ^0.8.0;\n\nimport \"./IERC20.sol\";\nimport \"./extensions/IERC20Metadata.sol\";\nimport \"../../utils/Context.sol\";\n\n/**\n * @dev Implementation of the {IERC20} interface.\n *\n * This implementation is agnostic to the way tokens are created. This means\n * that a supply mechanism has to be added in a derived contract using {_mint}.\n * For a generic mechanism see {ERC20PresetMinterPauser}.\n *\n * TIP: For a detailed writeup see our guide\n * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How\n * to implement supply mechanisms].\n *\n * We have followed general OpenZeppelin guidelines: functions revert instead\n * of returning `false` on failure. This behavior is nonetheless conventional\n * and does not conflict with the expectations of ERC20 applications.\n *\n * Additionally, an {Approval} event is emitted on calls to {transferFrom}.\n * This allows applications to reconstruct the allowance for all accounts just\n * by listening to said events. Other implementations of the EIP may not emit\n * these events, as it isn't required by the specification.\n *\n * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}\n * functions have been added to mitigate the well-known issues around setting\n * allowances. See {IERC20-approve}.\n */\ncontract ERC20 is Context, IERC20, IERC20Metadata {\n    mapping(address => uint256) private _balances;\n\n    mapping(address => mapping(address => uint256)) private _allowances;\n\n    uint256 private _totalSupply;\n\n    string private _name;\n    string private _symbol;\n\n    /**\n     * @dev Sets the values for {name} and {symbol}.\n     *\n     * The default value of {decimals} is 18. To select a different value for\n     * {decimals} you should overload it.\n     *\n     * All two of these values are immutable: they can only be set once during\n     * construction.\n     */\