Полный туториал можно посмотреть в моем видео: https://youtu.be/AJduzEcD0QY

Некоторые детали, я опущу, ожидая, что у вас уже есть некоторый опы.

И так:

1. Устанавливаем Metamask, если еще нет: https://metamask.io/download/

2. Скачиваем Node.js и устанавливаем на компьютер (необходимо для работы HardHat)

3. Создаем папку для проекта и переходим в нее

  mkdir Ethereum
  cd ./Ethereum

4. Устанавливаем HardHat

 npm install --save-dev hardhat

5. Создаем новый проект

npx hardhat

в терминале выбираем js

6. Устанавливаем дополнительные пакеты: OpenZepplin (понадобятся в любом случае!), dotenv, ethersnan

  npm install --save-dev @nomiclabs/hardhat-etherscan
  npm install dotenv  
  npm install @openzeppelin/contracts

про dotenv можно почитать здесь https://www.npmjs.com/package/dotenv

7. Открываем проект в редакторе и настроим hardhat.config.js

- необходимо настроить network

по дефолту:

    networks: {
    hardhat: {
    },
    goerli: {
      url: "https://eth-goerli.alchemyapi.io/v2/123abc123abc123abc123abc123abcde",
      accounts: [privateKey1, privateKey2, ...]
    }
  }

через dotenv:

создаем в корне файл .env

‼️ не забудьте добавить исключение в файл .gitignore, если планируете заливать папку на git

прописываем необходимые переменные:

  NETWORK="sepolia"
  INFURA_URL="https://sepolia.infura.io/v3/xxx0000"
  PRIVATE_KEY="xxx000xxx"
  ETHERSCAN_API="xxx000"

где:

• вместо sepolia указываем совою сеть, в которую собираетесь деплоить контракт
• регистрируемся на сайте https://app.infura.io/ , нажимаем на кнопку CREATE NEW KEY и выбираем нужную ссылку на вашу сеть, вставляем в кавычки INFURA_URL
• заходим в Metamask, "три точки" -> реквизиты счета -> экспорт закрытого ключа, вставляем в PRIVATE_KEY
• заходим на сайт https://etherscan.io , регистрируемся и в меню, которое раскрывается по клику на ваш ник в верхнем правом углу, нажимаем API Keys -> +Add вводим название -> create -> копируем новый ключ

Вставляем в hardhat.config.js

    networks: {
     [process.env.NETWORK] : {
       url: process.env.INFURA_URL,
       accounts: [process.env.PRIVATE_KEY]
     }
    }

8. Импортируем необходимые зависимости

require("@nomiclabs/hardhat-etherscan");
require('dotenv').config();

9. Проверим настройки HardHat

 npx hardhat

если все норм - выпадет список команд

10. Удаляем стандартный (Lock.sol) и создаем ваш контракт в папке contracts

после сохраниения скомпилируем контракты

npx hardhat compile

11. Настроим скрип deploy.js

настройка зависит от конфигурации ваших контрактов (наличия аргументов и др)

стандартный файл выглядит так

const hre = require("hardhat");

async function main() {
  const TokenDrop = await hre.ethers.getContractFactory("TokenDrop");
  const tokenDrop = await TokenDrop.deploy();

  await tokenDrop.deployed();

  console.log("TokenDrop:", tokenDrop.address);
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

вместо TokenDrop прописываем названия своего контракта, также с большой и маленькой буквы

12. Deploy смарт-контракта

перед деплоем можно очистить скомпилированные контракты

npx hardhat clean

запускаем деплой

npx hardhat run scripts/deploy.js --network sepolia

13. Верифицируем смарт-контракт

для реботы etherscan в hardhat.config.js необходимо добавить:

  etherscan: {
    apiKey: process.env.ETHERSCAN_API
  }

после этого можно запустить команду для верификации

npx hardhat verify xxx000xxx --network goerli

При использовании аргументов при деплое, необходимо указать их в конце команды в ковычках

npx hardhat verify CONTRACT_VER --network goerli "0xaC560B3BC37EC0B1D4600000000000000" "100"

Если все успешно вы увидите надпись success в терминале.

Более подробно я рассказываю в своем видео: https://youtu.be/AJduzEcD0QY

Ошибка при вызове transferFrom

Требовалось написать контракт, который будет принимать от юзеров USDT в сети Ethereum и в дальнейшем выводить их по запросам тех же пользователей или owner'a.

Выглядело это так:

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";


contract TransferUSDT is Ownable {

    IERC20 private immutable USDTContract;

    mapping(address => uint) private balances;

    constructor(address _usdt) {
        USDTContract = IERC20(_usdt);
    }

    function deposit(uint _amount) external {
        require(getAllowance() >= _amount);
        USDTContract.transferFrom(msg.sender, address(this), _amount);
        balances[msg.sender] += _amount;
    }
    
    ...
    
}

После аппрува токенов USDT для возможности списания их с адерса юзера в пользу контракта TransferUSDT, я вызвал функцию deposit и получил ошибку:

Неизвестный модификатор

??? В поисках ответа я полез в контракт USDT и обнаружил не обычную функцию transferFrom:

// Forward ERC20 methods to upgraded contract if this one is deprecated
function transferFrom(address _from, address _to, uint _value) public whenNotPaused {
   require(!isBlackListed[_from]);
     if (deprecated) {
         return UpgradedStandardToken(upgradedAddress).transferFromByLegacy(msg.sender, _from, _to, _value);
     } else {
         return super.transferFrom(_from, _to, _value);
        }
    }

При положении deprecated = false, функция обращается к реализации transferFrom в родительском контракте:

contract StandardToken is BasicToken, ERC20 {

    mapping (address => mapping (address => uint)) public allowed;

    uint public constant MAX_UINT = 2**256 - 1;

    /**
    * @dev Transfer tokens from one address to another
    * @param _from address The address which you want to send tokens from
    * @param _to address The address which you want to transfer to
    * @param _value uint the amount of tokens to be transferred
    */
    function transferFrom(address _from, address _to, uint _value) public onlyPayloadSize(3 * 32) {
        var _allowance = allowed[_from][msg.sender];

        // Check is not needed because sub(_allowance, _value) will already throw if this condition is not met
        // if (_value > _allowance) throw;

        uint fee = (_value.mul(basisPointsRate)).div(10000);
        if (fee > maximumFee) {
            fee = maximumFee;
        }
        if (_allowance < MAX_UINT) {
            allowed[_from][msg.sender] = _allowance.sub(_value);
        }
        uint sendAmount = _value.sub(fee);
        balances[_from] = balances[_from].sub(_value);
        balances[_to] = balances[_to].add(sendAmount);
        if (fee > 0) {
            balances[owner] = balances[owner].add(fee);
            Transfer(_from, owner, fee);
        }
        Transfer(_from, _to, sendAmount);
    }

где сразу обращаешь внимание на модификатор onlyPayloadSize(3 * 32).

    modifier onlyPayloadSize(uint size) {
        require(!(msg.data.length < size + 4));
        _;
    }

Назначение модификатора

Модификатор проверяет размер data отправляемой в транзакции. Это ограничение на вызов функции из смарт-контракта и никак не влияет на перевод с обычных кошельков.

Вызывающий контракт может воспользоваться атакой короткого адреса.

Атака по короткому адресу — это когда контракт получает меньше данных, чем ожидалось, и Solidity заполняет недостающие байты нулями. Развернутый смарт-контракт не может предотвратить это и интерпретирует эти лишние нули как часть правильного значения, провоцируя серьезные проблемы.

Если атакуемый сгенерирует адрес типа 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0000. он может предоставить 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(нули опущены) передаточной функции. Это фактически вызовет передачу значения, сдвинутого на 16 бит, то есть в 65536 раз больше, чем X, на учетную запись Ethereum атакующего.

msg.dataбудет выглядеть следующим образом :

Function: transfer(address _to, uint256 _value)

0xa9059cbb0000000000000000000000000797350000000000000000000000000000000000000000000005150ac4c39a6f3f0000

Таким образом в нашем случае размер data не должен превышать

3 х 32 byte + 4 byte = 100 byte ,

что соответствует 3м слотам по 32 байта под 3 аргумента, передаваемых в функции и 4 байта селектор функции.

В момент передачи контракт дополняет msg.data до 128 байт, что в итоге приводит к ошибке.

Как обойти модификатор

Для обхода этого модификатора можно использовать библиотеку OpenZeppelinSafeERC20.sol. По примеру, Aave:

    function transferToFeeCollectionAddress(
        address _token,
        address _user,
        uint256 _amount,
        address _destination
    ) external payable onlyLendingPool {
        address payable feeAddress = address(uint160(_destination)); //cast the address to payable

        if (_token != EthAddressLib.ethAddress()) {
            require(
                msg.value == 0,
                "User is sending ETH along with the ERC20 transfer. Check the value attribute of the transaction"
            );
            ERC20(_token).safeTransferFrom(_user, feeAddress, _amount);
        } else {
            require(msg.value >= _amount, "The amount and the value sent to deposit do not match");
            //solium-disable-next-line
            (bool result, ) = feeAddress.call.value(_amount).gas(50000)("");
            require(result, "Transfer of ETH failed");
        }
    }

Тогда наш код будет выглядеть так:

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/access/Ownable.sol";
import "openzeppelin-solidity/contracts/token/ERC20/utils/SafeERC20.sol";

contract TransferUSDT is Ownable {
    using SafeERC20 for IERC20;
    IERC20 private immutable usdt;

    mapping (address => uint) private balances;

    constructor(address _usdt) {
        usdt = IERC20(_usdt);
    }

    function deposit(uint _amount) external {
        require(getAllawance() > _amount, "Not approved!");
        usdt.safeTransferFrom(msg.sender, address(this), _amount);
    }
    
....
}

safeTransfer передает аргументы через abi.encodeWithSelector(token.transferFrom.selector, from, to, value),

что потребляет немного больше газа, но для решения нашей задачи подходит.

Итог

Ряд аудиторских компаний предлагали отказаться от использования проверки на размер data в контракте и делать это на бирже. До сих пор никто не нашел способа воспользоваться атакой короткого адреса и это вызывает только некоторые проблемы.

1. Через HardHat (если вы продвинутый юзер😎)
2. Воспользовавшись плагином Flattener внутри Remix IDE

В этой статье рассмотрим 2 способ.

Проделать все шаги описанные ниже вы можете как перед деплоем контракта и использовать уже полученный код, так и после.

Обязательно используйте ту же версию компилятора, которая стояла в Remix, когда вы деплоили контракт

Также проверяйте не стояла ли галочка оптимизация

Инструкция

1. Открываем вкладку с плагинами в Remix

2 В поиске вводим Flattener и активируем плагин

3 Переходим на вкладку плагина Flattener

4 Сохраняем контракт с помощью плагина

5 Возвращаемся на вкладку с файлами в новом файле name_flat.sol в верхней строке вставляем лицензию из нашего контракта

6 Копируем полностью код из нового файла и вставляем в окно верификации etherscan

Немного предыстории. В поисках видео про скам-контракт с легендой о торговом LIQUIDITY BOTе, я наткнулся на это:

1,3 млн просмотров на откровенно мошенническом видео!

До этого я разбирал контракт с похожего видео, где деньги уводит код импортируемый с npm(вот его код - ТЫК ),

но в этом контракте ТЫК импорта не было!

Я решил разобраться

Для начала, я задеплоил контракт в Remix:

Публично открыты только две функции. Start, которую предлагают вызвать в видео и Withdraw.

Я решил убедиться, что контракт действительно уводит деньги, НУ МАЛО ЛИ :))

Я добавил функцию balanceThis, чтобы проверить баланс на контракте после пополнения

function balanceThis() external view returns(uint) {
   return address(this).balance;
}

и так как функция Start в контракте

function start() public payable {

помечена как payable, я могу отправить деньги на контракт вместе с ее вызовом.

Деньги отправились, проверяем баланс

Предположения верны, значит будем искать адрес, куда они отправляются!

Продолжаю поиск

Очевидно, нужно начинать поиск с публичных функций. В контракте их 2:

В них все понятно, они вызывают отправку всех денег с баланса

address(this).balance

на адрес:

payable(_callFrontRUnActionMempool() и payable(withdrawalProfits())

находим обе функции

они ссылаются на одну:

parseMemoryPool(callMempool())

которая принимает строку из функции callMempool

Для начала давайте посмотрим в Remix, что возвращают эти функции.

Для этого я изменю области видимости с internal на public.

Передеплоим контракт.

Дальше снова закинем 1 eth при вызове Start, посмотрим, что возвращает callMempool и вставим это значение в parseMemoryPool

Вуаля :) мы получаем адрес, на который уходит весь эфир с этого контракта 0x7a48a3b91c9402af425210907aa37f1aaea46800 - ТЫК (etherscan)!

Как это все получается?

Функция parseMemoryPool совершает бесполезные махинации, но выполняет главную задачу преобразует строку, возвращаемую из callMempool, в тип адрес, При этом сам адрес уже сформирован в callMempool.

В ней указаны значения

которые при помощи дополнительных функций преобразуются из десятичного в шестнадцатиричный формат

этой

и этой

и собирается в адрес

Итог

Мне пришлось потратить пару часов, чтобы разобраться в коде и понять, что меня собираются обмануть. К сожалению, не все это могут. Но вывод один: нельзя смотреть на цифры. Даже 1 300 000 просмотров скрывают обман.

Ссылку на видео добавлю, хотя его рано или поздно удалят - ТЫК

Благодарю тебя за то, что ты дочитал до конца мою первую статью!