Разработка и верификация Proxy/Factory смарт-контрактов. Solidity

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Factory смарт-контракты - контракты, являющаяся фабриками / заводами по производству других контрактов. Разберемся в их разработке на примере создания ERC-20 tokens Factory.

Создадим обычный контракт ERC-20, прибегнув к контракту OpenZeppelin. Допишем в конструктор _transferOwnership(owner). Это позволит тем, кто будет создавать контракты токенов через нашу Factory быть для них владельцем, иначе владельцем будет являться наш контракт фабрики контракта.

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

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

contract MyToken is ERC20, Ownable {
    constructor(
      string memory name_,
      string memory symbol_,
      uint256 totalSupply_,
      address owner_) ERC20(name_, symbol_) {
        _mint(owner_, totalSupply_);
        _transferOwnership(owner_);
      }

    function mint(address to, uint256 amount) public onlyOwner {
        _mint(to, amount);
    }
}

Создадим для него Factory - контракт для выпуска других ERC-20 токенов.

contract Factory {

    event tokenCreated(address tokenAddress);

    function deployNewERC20(
            string calldata name,
            string calldata symbol,
            uint256 totalSupply
            
        ) external returns (address) {
            Chrz token = new Chrz(
                name,
                symbol,
                totalSupply,
                msg.sender
            );
      
            emit tokenCreated(address(token));

            return address(token);
        }
}

Именно функция deployNewERC20 будет тем самым заводом по производству новых токенов, вызывая которую будут создаваться новые контракты токенов.

После написания контрактов деплоим контракт Factory в сеть. И заходим во вкладку Contracts в обозревателе блоков. Видим следующее:

Нажимаем на Verify and Publish.

Вводим тип файл, ту версию, в которой контракт был задеплоен и лицензию.

На следующем этапе нас интересует 2 поля:

В первое поле мы вставляем код наших контрактов в чистом, без импортов OpenZeppelin. В этом нам поможет разрешение Flattener для Remix IDE, которое достает из импортов нужный код и добавляет в наш контракт.

Во втором поле требуется записать аргументы конструктора в закодированном виде. Так как наш контракт Factory не подразумевает никаких аргументов для конструктора, оставляем это поле пустым.

Наш контракт успешно верифицирован.

Теперь создадим свой токен, используя наш контракт:

Теперь сталкиваемся с проблемой, собственно, ради которой изначально и планировалась эта статья.

Как верифицировать контракт из Factory?

Итак, приступим.

Нажимаем уже привычную нам кнопку Verify and Publish.

В появившемся окне вводим все тоже самое, что и для контракта Factory.

Далее вводим исходный код контракта, но что писать в конструкторе аргумента?

Для того, чтобы это понять, нужно обратить внимание, что при создании нового токена в конструктор создания поступает 4 переменных: name, symbol, supply и owner. Именно они должны попасть в этот конструктор. Для того, чтобы их захешировать, нам потребуется сервис https://abi.hashex.org/. Туда мы и вставляем параметры нашего конструктора, которые задавили при создании.

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

Копируем и вставляем данные в поле для аргументов конструктора контракта при верификации.

Таким образом, мы верифицировали оба наших контракта.

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

P.S. моя первая статья.

Источник: https://habr.com/ru/post/714938/


Интересные статьи

Интересные статьи

Приветствую, Хабр! В статье речь пойдет о разработке устройства, которое позволяет отправлять «команду сделать снимок» фотоаппарату, принимая ее от фотоловушки. И почему, например, не подойдет вариа...
Цель статьи, – показать примеры управления реализацией стратегии с помощью корпоративной единой информационной площадки на доступном инструменте, - Битрикс24. В статье на простом языке обсуждаются воз...
Продолжаем серию статей про язык Solidity и платформу Ethereum. В этой статье будет рассказываться про адреса в Ethereum. Статья была написана в августе 2019 года, с той порой язык изменился, поэтому ...
Кто бы что ни говорил, но я считаю, что изобретение велосипедов — штука полезная. Использование готовых библиотек и фреймворков, конечно, хорошо, но порой стоит их отложить и создать ...
Я не из тех инженеров, кто в детстве чинил паяльником старый бабушкин телевизор. Папа не покупал мне компьютер, потому что папы у меня и не было. Я вырос в Ташкенте, Узбекистан, ж...