Пишем смарт-контракт Ethereum — это просто: Часть 10 — ICO, исходники на Etherscan, типы эмиссии

В предыдущей статье мы научились добавлять бонусы и закончили писать контракты для проведения ICO. В этой статье мы коснемся некоторых тонкостей реализации и работы со смарт-контрактами ICO. А именно:

  1. Узнаем как добавить исходники на etherscan
  2. Познакомимся с типами эмиссий токенов и BurnableToken
  3. Познакомимся с архитектурой со множеством этапов распродаж

Как добавить исходники на Etherscan

Если посмотрите на чужие контракты в etherscan,  то можете заметить что у многих присутствует исходный код и вкладка «Read Smart Contract».  На  этой вкладке удобно представлен интерфейс.

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

При этом на вкладке «Contract code» ничего кроме байткода не будет. Давайте научимся делать интерфейс для нашего контракта в etherscan.

  1. Откройте etherscan и найдите по адресу свой контракт
  2. Нажмите на вкладку «Contract code»
  3. В поле «Contract Name» укажите имя вашего контракта. В поле Compiler версию, которой компилировали контракт во время заливки в блокчейн (именно версию компилятора а не ту версию которая у вас в верху контракта «pragma solidity 0.4….». ).  А в после Optimization выберите с оптимизацией компилировали или нет. Если не помните, то по-умолчанию оптимизация выключена в Parity и remix. В Mist оптимизация включена. Версия компилятора в remix обычно самая последняя как и в parity (на момент написания статьи). Mist на момент написания статьи поддерживал не самую последнюю версию 0.4.13. 
  4. В поле «Enter the Solidity Contract Code» вставьте весь код смарт-контракта со всеми зависимостями. И нажмите на кнопку низу «Verify And Publish».
  5. Если версии компилятора и оптимизация указаны верно, то получите сообщение об успешно выполнении. В котором нажмите на ссылку рядом с зеленой надписью. Если получите сообщение об ошибке, то скорее всего не верно указан компилятор.

Теперь на вкладке «Contract code» отображается код нашего контракта и заодно ABI интерфейс.

А на вкладке «Read Smart Contract» отображается интерфейс на чтение смарт-контракта.

В данном случае  я залил контракт нашего токена. Однако, как вы видите, токен отображается как обычный смарт-контракт. Для того чтобы отобразить наш контракт именно как токен ERC20 нужно в URL в браузере поменять «address» на «token«. В моем случае был URL:

https://ropsten.etherscan.io/address/0x275f215a3bfc4699e7278f4e521c0ed43d6011aa#readContract

После замены получаем:

https://ropsten.etherscan.io/token/0x275f215a3bfc4699e7278f4e521c0ed43d6011aa#readContract

В вашем случае слово ropsten в URL может отсутствовать. Ropsten — это просто тестовая сеть, но об этом позже. После замены мы увидим что etherscan отобразит наш контракт как токен ERC20.

Теперь появилась вкладка «Token holders». На ней будут отображаться адреса владельцев наших токенов и процент владения от общей суммы токенов. И появилась «Token transaction». На  которой будут отображаться все события Transfer.

Типы эмисси токенов и BurnableToken

В наших предыдущих контрактах эмиссия токенов осуществлялась в момент, когда инвестор вкладывал деньги. Однако, есть и другой тип эмиссии. Когда все токены выпускаются ограниченным количеством при создании контракта. А в последствие перемещаются на счет инвестора тогда, когда происходит оплата.

Жизненный цикл контракта такого токена:

  1. Во время создания контракта: на адрес владельца контракта записываются все токены.
  2. Распродажа токеновс адреса владельца контракта списывается токены и записываются на адрес инвесторов. При каждой покупке возникает событие Transfer.
  3. Распределение токенов основателям и на баунти: Ну тут все понятно.
  4. Сжигание нераспроданных токенов: токены, которые не были распроданы подлежат уничтожению или «сжиганию». При сжигании токенов генерируется событие Burn.

Зачем сжигать токены? Дело в том что за оставшиеся токены никто не заплатил. Есть купленные инвесторами токены, есть процент токенов на баунти, есть процент основателям. И есть токены которые никто не купил. Если мы их оставляем на балансе владельца контракта, то фактически оставляем возможность выпуска этих токенов на биржу. Тем самым мы размываем цену.  А это не очень приятно для инвестора. Очень важно указывать в WhitePaper тот факт что вы обязуетесь нераспроданные токены сжечь! А также укажите когда именно вы это сделаете! К примеру, в чате проекта Polybius пользователи часто интересовались моментом сжигания нераспроданных токенов.

Что нужно чтобы сделать токены с ограниченной начальной эмиссией? Для этого достаточно сделать две вещи:

  1. В контракте токена инициализировать баланс владельца контракта всеми токенами и не забыть прописать соответсвующее число токенов в totoalSupply. Можно сделать так:

    Помним, что количество токенов указывается с учетом знаков после запятой. К примеру, в нашем токене 18 знаков после запятой. Поэтому мы умножаем на 1 ether (1 ether = 1000000000000000000 wei).
  2. Сделать возможность уничтожать токены. Лучше воспользоваться готовым решенем. Например от OpenZepplein. И наследоваться от BurnableToken. Наследование от MintableToken нам не нужно, поэтому его убираем. Давайте взглянем на реализацию BurnableToken.

    К контракту токена добавляется функция Burn. Она и предоставляет возможность сжигать токены со своего и только своего баланса тому кто вызывает эту функцию. Если пользователь попытается сжечь токенов больше чем нужно, то библиотека безопасных математических операций, в частности функция sub, не позволит это сделать.

Фактически диаграмма наследования для токена с ограниченной эмиссией по структуре остается такой же как и раньше. Только вместо MintableToken мы наследуемся от BurnableToken.

Теперь полная реализация нашего токена выглядит так:

А теперь исправим наш контракт Crowdsale. Раньше, когда инвестор покупал токены мы вызывали mint у контракта токена. Теперь нам достаточно вызвать transfer и переместить токены со счета владельца контракта токена на счет инвестора. Для этого в функции createTokens достаточно заменить последнюю строчку

на

Функцию finishMinting так просто исправить не получится. Раньше она выполняла две задачи:

  1. Cчитала процент токенов для основателей и баунти по окончанию распродажи. Причем процент считался от totoalSupply. Раньше totalSupply — количество выпущенных токенов соответствовало количеству купленных. Теперь это не так. А считать нам нужно процент именно от купленных, иначе получится размывание цены токена.
  2. Запрещала всякую эмиссию после окончания распродажи

Чтобы процент токенов основателям считался корректно — мы будем считать его непосредственно при покупке токенов инвесторами и тут же перечислять на счет основателей. Для этого в конец createTokens добавим две строчки.

Поскольку токены у нас выпускаются единожды и больше возможности выпуска нет, то запрещать эмиссию нет смысла в конце распродажи. Поэтому функцию finishMinting теперь можно просто убрать.

Также из контракта распродажи можно смело убрать ограничение isUnderHardcap. Как только все токены закончатся,  функция покупки перестанет работать и все. Давайте теперь посмотри как выглядит весь код нашего ICO.

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

Между токенами с эмиссией во время распродажи и с ограниченной эмиссией вначале есть тонкое различие для отображения в etherscan.

Дело в том что etherscan вычисляет владельцев токенов и их доли только на основе события Transfer. В контракте токена с изначальной эмиссией все токены уже выпущены. Когда инвестор делает покупку токены просто перечисляются на счет инвестора с помощью функции transfer. A transfer генерирует событие Transfer. Поэтому доля инвестора вычисляется сразу корректно относительно суммы всех выпущенных токенов. Однако событие уничтожения токенов Burn не воспринимается etherscan. Поэтому доли останются рассчитаными относительно изначального числа токенов.

В том случае когда эмиссия происходит во время покупки, возникает событие Mint а не Transfer. Поэтому etherscan не сможет вычислять и отображать доли держателей токенов корректно. Такое будет до тех пор пока все держатели не выполнят хотя бы одно перемещение токенов.

Однако, в токене с эмиссией во время распродажи проблему можно решить. Нужно не сразу выпускать токены на счет инвестора. Нужно сначала делать эмиссию на счет владельца контракта . И только после этого перемещать токены со счета владельца контракта на счет инвестора (попробуйте это сделать самостоятельно). В таком случае все доли будут отображаться в etherscan корректно. В случае же с токеном с изначальной эмиссией решения этой проблемы нет.

Часто встречаются ICO в которых указывается изначально выпущенное количество токенов с аргументом: «инвесторы хотят знать сколько токенов выпущено всего«. На самом деле, если нераспроданные токены будут сжигаться (а сжигаться они должны если вы не обманываете инвесторов), то конечное число токенов никому не известно. Поэтому я всегда рекомендую выбирать реализацию с выпуском токенов во время распродажи. Но выбор конечно же  за вами вам.

Архитектура со множеством этапов раcпродаж

Кроме основной распродажи может быть предварительный этап продажи токенов. Так называемый pre sale. Если этапов распродажи токенов может быть много, то создают один контракт токена. А на каждую распродажу свой делают отдельный контракт. При этом контракт токена имеет поле saleAgent. В этом поле хранится адрес того контракта распродажи, который в данный момент имеет право эмитировать или продавать токены. Устанавливать это поле имеет право только владелец контракта токена. А эмитировать токены имеет право только тот контракт, который указан в saleAgent.

Продолжение читать тут. Предыдущий урок тут.

Если у вас возникли вопросы то можете смело писать на электронную почту (раздел «контакты«). Также приветствуется критика.

Если статья показалась вам полезной и вы желаете отблагодарить автора, то это можно сделать отослав немного эфира на адрес 0xEA15Adb66DC92a4BbCcC8Bf32fd25E2e86a2A770.

Полный список уроков тут.

 

32 Комментариев

    • Что вы имеете в виду под presale? Если сам контракт распродажи, то это такой же контракт как и mainsale, только может отличаться бонусами к примеру.

    • Я имею ввиду, как правильно сделать сперва пресейл а потом само ICO. К коду добавить contract PreSale is Ownable например.

    • Делайте один контракт токена и два контракта распродажи. Это и будет архитектура со множеством этапов раcпродаж. Т.е. у токена помимо владельца еще будет saleAgent. В текущий момент разрешено будет распродавать токены только тому контракту распродажи, который указан в saleAgent. При этом контракты распродажи будут приблизительно одинаковыми.

    • Спасибо. А по поводу перевода токенов владельцем ICO на любые эфириуме адреса инвесторов, что посоветуете?

    • Ну я уже ответил на этот вопрос, либо так:

      либо так (если контракт наследуется от Authorizable)

    • В этом примере контракты распродаж наследуются от контрактов распродаж OpenZeppelin и нам надо вызвать конструкторы суперконтрактов. Не лучше ли добавить все необходимые параметры в конструктор наших контрактов:

      А всю инициализацию вынести в 2_deploy_contracts.js файл:

    • Общая практика такая, что вызываются всегда суперконструкторы. Зачем это делается? Помимо банальной инициализации полей в суперконструкторе могут выполняться дополнительные действия, расчеты, зависящие от инициалиазции. А об этом вы можете забыть, если сделаете такую оптимизацию. Даже если в данном конкретном случае может и безопасно оптимизировать как вы говорите, но все же рекомендую придерживаться опыта. Или оптимизация должна быть аргументирована.

    • Согласен с inaword, что лучше не размазывать инициализацию по всему проекту. Конструктор как раз и нужен для инициализации, это его назначение.

    • RusT, может я чет не понимаю, но разве не должен быть установлен контракт распродажи:
      token = new SampleToken();
      token.setSaleAgent(this);

      плюс в контракте распродажи должна быть проверка saleAgent контракта токена в методе createTokens

  1. И ещё вопрос. Например ICO принимает оплату еще и в биткойнах. Значит нужно реализовать метод при котором создатель ICO может выпускать токены по своему желанию и отправлять их на нужные адреса, без использования контракта contract Crowdsale is Ownable. Как это лучше сделать ?

    • Можно и так. В TenX контракт наследуется от Authorizable и уже тем, кто авторизован на выпуск токена предоставляется соответствующая возможность:

      Почему именно Authorizable?

      • Потому что это позволяет задать несколько адресов авторизованных для выпуска токена. Т.е. могут быть несколько приложений dapp дергающих метод.
      • Потому что owner имеет доступ ко многим важным методам, а этот доступ нам мы крайне не хотелось бы предоставлять остальным DApp
    • Практический опыт по этому вопросу у меня отсутствует. Я специализируюсь только на смарт-контрактах эфира. Но как вы описали, да вполне возможно сделать метод который будет дергаться dapp. К примеру в реализации TenX есть поле:

      Это поле будет учитываться в модификаторе:

      Тем самым учитывая в границах сбора альтернативные вложения.
      Это поле будет обновляться DApp, которое принимает платежи в биткоинах.

      Ну и собственно как у TenX метод для выпуска токенов. (Сам контракт наследуется от Authorizable, видимо чтобы нескольким внешним DApp ограничить действия только этим методом).

      Далее одно из принимающих DApp может работать так:

      • Пользователь перечисляет сумму альтернативной валюты через DApp с указанием счета эфира, куда потом кидать токены (реализации могут быть разные)
      • Приложение пересчитывает вложения по своему токенах и дерагет authorizedCreateTokens
      • Приложение пересчитывает сумму вложения по своему курсу в эфире и обновляет hardcap с помощью setAltDeposites
  2. Добрый день!
    Создал по вашему шаблону контракт Crowdsale с токенами burnable, но контракт не эмитирует всю сумму указанную в total supply, а только процент, в зависимости от перечисления эфира с кошелька на адрес контракта. В обороте находится только та часть, которая выпущена контрактом на адрес инвестора и restricted. Т.е. работает как minted.

    • На балансе создателя контракта должна быть вся сумма. И создатель этой суммой может распоряжаться. Почему вы считаете что сумма не в обороте?

  3. На балансе создателя нет вообще ничего. Все токены выпускаются контрактом в момент отправки на него эфира (а не при создании контракта) и уходят инвестору и в restricted кошелек. Это видно по балансу токена. Т.е. загружаю контракт краудсейла в блокчейн. Получаю токен только при перечислении эфира на контракт краудсейла. Вот часть кода, которую я правил. На балансе аккаунта нет ни одного токена и распоряжатся ими он не может.

    contract EVAToken is BurnableToken {

    string public constant name = «EVA Coin Token»;

    string public constant symbol = «EVA»;

    uint32 public constant decimals = 6;

    uint256 public totalSupply = 480000000 * 1000000 wei;

    function EVAToken() {
    totalSupply = totalSupply;
    balances[msg.sender] = totalSupply;
    }

    }

    contract Crowdsale is Ownable {

    using SafeMath for uint;

    address multisig;

    uint restrictedPercent;

    address restricted;

    EVAToken public token = new EVAToken();

    uint start;

    uint period;

    uint rate;

    function Crowdsale() {
    multisig = 0x3246b1a2c13E28FcF6C9FFca7BB4e38a56cF8dd8;
    restricted = 0xB0D9A83a32E4B674Bb556Ab0D7C28a646d0E418c;
    restrictedPercent = 40;
    rate = 10000000000;
    start = 1505577600;
    period = 4;
    }

    modifier saleIsOn() {
    require(now > start && now < start + period * 1 days);
    _;
    }

    function createTokens() saleIsOn payable {
    multisig.transfer(msg.value);
    uint tokens = rate.mul(msg.value).div(1 ether);
    token.transfer(msg.sender, tokens);
    uint restrictedTokens = tokens.mul(restrictedPercent).div(100 — restrictedPercent);
    token.transfer(restricted, restrictedTokens);
    }

    function() external payable {
    createTokens();
    }

    }

    • не тот кусок отправил, часть с INITIAL SUPPLY вот так выглядит:

      uint256 public INITIAL_SUPPLY = 480000000 * 1000000 wei;

      function EVAToken() {
      totalSupply = INITIAL_SUPPLY;
      balances[msg.sender] = INITIAL_SUPPLY
      }

    • Не может быть такого. Токены отправляются с баланса владельца контракта. Если бы на балансе токегов не было, то они бы не отправились при вызове cteateTokens вообще никому.

  4. Я вам клянусь! 🙂 Пробовал уже всякие способы и сначала залить контракт монеты, а потом краудселйа. И сразу контракт краудсейла. Результат одинаковый в случае с краудсейлом. В первом случае создается монета, весь её баланс находится у создателя. Но при создании контракта создается ДРУГАЯ монета, с другим адресом и она же зачисляется на счета инвесторов.

    • Пишите в телеграмм группу или на почту разберёмся. Ссылки на залитые контракты нужны (проверифицированые в etherscan). Я подозреваю что вы перепутали адрес владельца контракта. А это не ваг личный адрес. В контракте есть ошибка, но это не та ошибка о которой вы говорите.

  5. inaword Спасибо за подробные статьи. Я тестировал в кошельке Mist в solonetwork — токены не появляются на балансе создателя. Брал Ваш конечный код, изменил только время старта и адреса multisig и restricted. Ваши уроки прочитал внимательно. Не могу понять почему не получается.

    • Токены не должны появляться на балансе создателя. Токены появляются на балансе инвестора и на балансе кошелька restricted. Вот кусок куда из функции createTokens:

      Тут msg.sender — адрес инвестора, а restricted — адрес кошелька токенов для основателей.

    • Следующая страница в черновиках пока. Это статья про механизм refund. Через неделю появится.

  6. Если же вы посмотрите на свой только что залитый контракт то увидите только две вкладки.
    бля сорри ни как не могу догнать как залить свой написанный контракт на etherscan, или я что то пропустил((

  7. Если мы PreSale и в MainSale создаем SimpleCoinToken public token = new SimpleCoinToken();
    то это совершенно разные токены. Каждый выпустил по INITIAL_SUPPLY и перевел владельцу, т.е контрактам PreSale и MainSale. Так? Какова практика? Создаём контракт токена отдельно и по адресу вместо new получаем его экземпляр? Тогда вместо transfer в функции createtokens() что использовать, на балансе контракта ***Sale ничего не будет. Не они же теперь владельцы контракта токена?

  8. Отличная статья, спасибо, очень важно показывать исходник для каждого проекта на github, потому что вопрос доверия инвесторов в условиях изменчивого рынка всегда актуален. Лучше с задачей ведения ico или sto справляются направленные на это агентства, например я работал с Flexe.io/p402 и рекомендую их всем, кто хочет качественно представлять свой продукт

  9. Задеплоил 2 контракта по вашему примеру, первый Burnable SimpleCoin, второй Crowdsale. 1й адрес был создателем 2-х контрактов, второй собирал коины на нужды проекта, 3 собирал эфир и перемещал их создателям. Контракт Burnable SimpleCoin оказался рабочим, все монеты поступили на счет 1 адреса создателя, а вот контракт Crowdsale не отрабатывает, он принимает эфир и не передает его адресу 1, также он не забирает монеты с адреса 1 и не отправляет их тому кто покупает, в чем может быть ошибка? ощущение что контракт Crowdsale не обращается к контракту SimpleCoin

Добавить комментарий