本次测试的合约地址：
本次实践课考察点：
1，如何在合约未开源情况下Mint NFT和交易复制
2，如何破除mint的数量限制
3，如何直接通过HEX Data进行链上交互
A:ABI
A:
mint：
0x1b2ef1ca (Method ID)
0000000000000000000000000000000000000000000000000000000000000000 (uint256 id)
0000000000000000000000000000000000000000000000000000000000000001 (uint256 amount)
原型为 mint(uint256 id, uint256 amount)
使用 keccak256(“mint(uint256,uint256)”)可以得到函数的hash值(1b2ef1ca104ec753c817f038e7e2a0c7cb28cc3c0877c7c2b78e5a14a407a623) ,取前四个字节即可得到函数的ID 0x1b2ef1ca 。
safeTransferFrom：
0xf242432a (Method ID)
address from
address to
0000000000000000000000000000000000000000000000000000000000000000 (uint256 id)
0000000000000000000000000000000000000000000000000000000000000001 (uint256 amount)
00000000000000000000000000000000000000000000000000000000000000a0 (bytes data)
0000000000000000000000000000000000000000000000000000000000000000 (bytes data)
原型为：
safeTransferFrom(address from, address to, uint256 id, uint256 amount, bytes data)
https://docs.openzeppelin.com/contracts/3.x/api/token/erc1155#IERC1155-safeTransferFrom-address-address-uint256-uint256-bytes-
此为1155的标准接口，不再做过多解释，具体内容可以看上面的OZ官方文档。
A3:EVM上的交互本身就是通过bytecode进行的，正如第二题所示，你完全可以通过手写HEX data来定位函数ID，组合函数参数。
ABI全称 Application Binary Interface，字面意思是应用程序二进制接口，记录的是已经编译成bytecode的合约中各个对外开放的变量与接口等所对应的定义时的原型，可以通俗的理解为合约的接口说明。
从第二题可以看出，合约编译时，是通过keccak256（”functionName(parameterType…)”） 计算hash，得到Method ID。而众所周知Hash计算是不可逆的，我们没法通过计算来反向得出函数ID所代表的函数定义。
实际部署到链上的合约，是只包含bytecode的，因此如果你没有编译时所生成的ABI文件的话，便只能通过自行组织HEX data进行互动。
所以ABI，实际上就是用来记录函数定义，方便在其他地方可以更清晰可读性更高的手段，以避免通过难以辨别的bytecode与合约进行交互。
结语：
所谓“科学家mint”一些比较基础的常用手段都在本次的试题中覆盖到了。
合约未开源，项目方的mint前端又因为流量太大瘫痪的情况下，可以考虑直接复制别人的交易数据，手动通过HEX Data进行mint。
在只允许一个账号mint固定数量个的情况下如何超过限制mint多个，只需要多个账号mint然后归结到一个账号里就行。最近的可以免费mint一个的各种图狗就有很多这种bot进行多账号，然后归结到同一个账号里进行售出。而如果是白名单限制了可以mint的帐户的情况，可以mint后将nft转出到别的账号，然后继续mint，之后再归结回来。
以上的例子看上去似乎很蠢，但都是实际项目中发生过的。
可以看出，在你学习了一些开发的基础知识之后，这些所谓“科学家手段”都并没有什么高深之处。将以上行为通过自己开发的脚本进行自动执行后，你也就成为了所谓“科学家”（也就是传统开发领域里所说的脚本小子）。
我们的推特：