Смарт контракты Ethereum: пишем простой контракт для ICO
В последнее время ко мне поступает огромное количество запросов за помощью в разработке смартконтракта для проведения ICO, при этом у меня не хватает времени, чтобы помочь каждому. Поэтому я решил написать этот небольшой пост (ссылка на видео в конце поста), в котором описываю очень простой смартконтракт для проведения crowdsale, который вы можете использовать в своих проектах.
Для экономии времени я написал контракт заранее. Давайте разберем его по шагам.
Смартконтракт является программой написанной на языке программирования. В нашем случае на языке Solidity. Для разработки простых контрактов я использую онлайн редактор и компилятор Remix.
Признаком хорошего тона считается начинать любую программу, в т.ч. и смартконтракт, с указания лицензии, на основе которой она распространяется. В нашем случае это GPL. Также можно указать себя в качестве автора контракта, конечно, если вы не пишете контракт для какого-нибудь скамового проекта, где стесняетесь указать себя в качестве автора.
Сразу после идет строка, которая указывает, какую версию компиллятора следует использовать. Если этой строки не будет, то смартконтракт не скомпилируется.
Далее идет непосредственно исходный код самого смартконтракта, который я структурировал в виде иерархии контрактов, каждый из которых реализует законченную функциональность. Это упрощает понимание и последующее использование кода в ваших контрактах.
Прежде всего следует понимать, что после загрузки смартконтракта в виртуальную машину Ethereum вы будете взаимодействовать с ним на общих основаниях, как и все остальные пользователи. Логично, что мы, как команда проекта, хотели бы находиться в привилегированных условиях, которые должны как минимум выражаться в том, что контракт должен сформировать именно на командные токены и конечно же отдал именно нам собранный эфир. Для этого контракт должен знать своего владельца и именно за это отвечает контракт «owned».
Контракт «owned» содержит лишь одно публичное поле «owner», значение которого инициализируется в конструкторе значением поля «sender» глобальной структуры «msg», таким образом, изначально владельцем контракта становится тот, кто осуществил его деплой.
Логично предусмотреть возможность смены владельца на случай, если наш private key будет скомпрометирован, для этого предусмотрена функция «changeOwner», которая получает в качестве параметра адрес нового владельца. Следует обратить на модификатор «onlyOwner», который определен внутри этого же смартконтракта. Модификаторы представляют собой очень удобную конструкцию, позволяющую сгруппировать и присвоить название условиям вызова функций смартконтракта. Модификатор «onlyOwner» проверяет, что вызов функции осуществляется с адреса, который сохранен в поле «owner».
Контракт «owned» полностью работоспособен и предельно прост, однако несет в себе одну скрытую угрозу, ведь при вызове функции «changeOwner» мы можем по ошибке указать несуществующий адрес, а значит, потеряем контроль над контрактом. Чтобы исправить этот недостаток, достаточно ввести еще поле, назовем его «candidate», а при вызове функции «changeOwner» будем сохранять новое значение сначала в «candidate», а перемещать его в «owner» будем, как только кандидат подтвердит свое вступление в права, вызвав со своего адресу функцию «confirmOwner».
Следующий в иерархии контракт – «Crowdsale», отвечает непосредственно за сбор средств и выдачу токенов и наследует рассмотренный ранее контракт «owned».
Особое внимание следует обратить на следующие элементы контракта:
Конструктор смартконтракта «Crowdsale» предельно прост. Прежде всего инициализируется значение поля «totalSupply». Наш контракт выпускает 21 миллион токенов, из которых 20 миллионов сразу будут перемещены на баланс смартконтракта. Будем считать, что токены с адреса смартконтракта как раз и доступны для продажи. Оставшиеся токены, в нашем случае 1 миллион, будут записаны на адрес владельца контракта. Ну и в конце конструктора испускается событие «Transfer», которое помещается в блокчейн и информирует пользователей контракта о том, что с баланса контракта на баланс владельца контракта переведено соответствующее количество токенов. Именно испускание этого события позволит etherscan.io корректно отобразить держателей токенов и их балансы.
Ну и самая главная функция смартконтракта «Crowdsale», так называемая fallback функция, которая вызывается каждый раз, когда эфир поступает на адрес нашего смартконтракта. В самом начале осуществляется проверка, что на балансе смартконтракта есть хоть какое-то количество токенов для продажи. Далее устанавливаем фиксированную цену токенов – 5000 штук за 1 эфир. Затем вычисляем, сколько токенов необходимо отправить отправителю эфира. Количество переданных в транзакции средств записано в поле «value» глобальной структуры «msg» и указано оно в «wei», поэтому при определении количества токенов осуществляем перевод «wei» в «ether».
Затем осуществляется проверка того, что на балансе смартконтракта есть достаточное количество токенов для продажи. Если запрошено больше токенов, чем есть у смартконтракта, то будем переводить все оставшиеся токены. Определяем стоимость в «wei» оставшихся токенов и возвращаем отправителю излишне переведенный эфир. Убеждаемся, что количество покупаемых токенов ненулевое, после чего записываем это количество токенов на баланс покупателя и списываем их с баланса смартконтракта. В конце не забываем испустить событие Transfer.
На этом собственно реализация функциональности сбора средств закончена, но теперь нужно сделать наш токен операбельным и реализовать еще некоторые функции стандарта ERC20. Это сделано в контракте «EasyToken», который наследуется от рассмотренного ранее контракта «Crowdsale».
Прежде всего определим 4 публичных поля, которые сейчас практически не используются никакими кошельками, но для порядка все же определим их. Здесь укажем полное и сокращенное наименование токена, а также количество дробных знаков. В нашем случае токен является неделимым, т.к. значение поля «decimals» установлено равным 0.
И наконец, единственной функцией смартконтракта «EasyToken», ради которой мы создавали этот контракт, является «transfer», которая также является частью стандарта ERC20 и позволит кошелькам пользователей осуществлять передачу токенов друг другу, переводить их на биржу и выводить их с нее. Реализация функции крайне проста, проверяется достаточность количества токенов на балансе отправителя, после чего баланс отправителя уменьшается, а баланс получателя увеличивается на запрошенное количество токенов. В конце испускается событие «Transfer». Теперь наш токен является операбельным и осталось сделать самое главное – предоставить владельцу контракта возможность вывести собранные эфиры. Это мы сделаем в контракте «EasyCrowdsale».
Функция «withdraw» имеет модификатор «onlyOwner», т.е. может быть вызвана только владельцем смартконтракта. Единственное, что она делает – переводит весь баланс смартконтракта на адрес владельца смартконтракта.
Несмотря на то, что рассмотренный нами смартконтракт является полностью функционально законченным и работоспособным, использовать его в реальном проекте я бы не рекомендовал. Чрезмерное упрощение логики контракта привело к тому, что такой контракт не обеспечивает защиту интересов инвесторов в должной мере, а именно, не устанавливает срок проведения crowdsale, не устанавливает минимальной границы сбора, не возвращает средства инвесторам в случае недостижения минимальной границы, а также содержит ряд известных уязвимостей на уровне компилятора языка Solidity, например, подвержен так называемой short address attack.
Многие из этих недостатков устранены в смартконтракте нашего проекта PROVER. Контракт PROOF загружен в Ethereum по этому адресу вместе с исходным кодом, с которым можно познакомиться. Можно даже проверить, как работает контракт, отправив на него реальный эфир, у нас как раз сейчас идет Pre-ICO:). На самом деле, мы будем рады, если вы присоединитесь к presale нашего проекта PROVER, который продлится до конца сентября. PROVER – это уникальная технология подтверждения подлинности видеоматериалов на базе блокчейн и видеоаналитики.
Введение в разработку умных контрактов Ethereum
В последнее время вокруг блокчейна, криптовалют, умных контрактов и связанных с ними технологий поднялся небывалый хайп. Создается ощущение, что даже самые ленивые и пассивные обыватели трубят об этом из каждого болота. Огромное количество стартапов и компаний с историей и опытом из сферы ИТ, услуг, ритейла и реального сектора экономики задумываются о внедрении блокчейна в свою деятельность, а более 100 000 компаний уже сделали это.
Механизм Initial Coin Offering не только способствовал новой волне интереса к краудфандингу, увеличив объем привлекаемых с его помощью инвестиций, но и подхлестнул интерес к криптовалютам и технологии блокчейн. Сегодня все чаще и чаще попадаются новые вакансии в этой области, а также просьбы о помощи в проведении ICO в целом и разработке смарт-контрактов в частности.
К сожалению, сегодня сильно ощущается нехватка специалистов в этой сфере, хотя в действительности процесс разработки умных контрактов гораздо проще, чем это может показаться на первый взгляд. Проблема нехватки специалистов напрямую проистекает из того, что технология блокчейн дошла до массового пользователя не так давно — в виде криптовалюты биткоин, а смарт-контракты в блокчейн пришли значительно позже. Так что лично у меня не вызвал большого удивления тот факт, что материалов по разработке смарт-контрактов все еще очень мало.
С другой стороны, будучи техническим директором компании, в которой мы занимаемся построением основанной на блокчейн цифровой юрисдикции и упрощением процесса создания смарт-контрактов для обычных пользователей, не владеющих навыками программирования, я ощущаю потребность в технических специалистах, имеющих представление о технологии, а еще лучше — опыт работы с ней.
В этом материале я хочу показать, что порог вхождения в разработку смарт-контрактов на самом деле довольно низкий, и постараться привлечь в сферу новых разработчиков. Конечно, не все в жизни бывает так же просто, как в обучающих материалах, и в разработке умных контрактов существует огромное количество тонкостей. Тем не менее, это справедливо и для любой другой технологии, включая знакомый многим JavaScript, и с этим нам, как правило, помогает справиться практический опыт, который невозможно получить, не начав программировать, проектировать, экспериментировать, тестировать и делать все то, чем разработчики обычно занимаются.
В этом уроке мы установим все необходимые для начала разработки инструменты, фреймворки, напишем свой первый токен ERC20 на языке Solidity, скомпилируем его, опубликуем в локальном блокчейне, напишем пару тестов и прогоним их. Мы будем использовать framework truffle, который поможет нам с управлением миграциями, компиляцией, управлением зависимостями, а также тестированием. Помимо этого, мы будем использовать фреймворк OpenZeppelin, который содержит в себе набор контрактов и библиотек, написанных на языке Solidity и уже доказавших свою полезность и безопасность временем.
Теперь откройте проект в вашем любимом текстовом редакторе (я использую Atom). Посмотрим на структуру проекта. Изначально вы можете увидеть в корневой директории три папки:
Как вы могли заметить, truffle уже создал пару простых умных контрактов для нас. Мы используем их для тестирования нашей установки.
После успешного запуска вы увидите хост и порт вашего блокчейн. Откройте файл `truffle.js` в корневой директории проекта. Этот файл содержит конфигурацию вашего проекта. Убедитесь, что хост и порт в конфигурации совпадают с хостом и портом запущенного testrpc.
Вскоре после этого вы увидите вывод команды в терминале и вывод события в клиенте testrpc. Поздравляю! Мы только что опубликовали наш первый умный контракт в эмулятор сети блокчейн.
Для создания более продвинутых контрактов мы воспользуемся фреймворком OpenZeppelin, который включает в себя несколько очень полезных библиотек, интерфейсов и готовых контрактов. Стоит отметить, что язык Solidity поддерживает наследование и мы можем с легкостью расширять функционал существующих контрактов. Это открывает большие возможности для продумывания вашей архитектуры.
Установить OpenZeppelin можно так же, как и любую другую JavaScript библиотеку, используя ваш любимый менеджер зависимостей, например, npm или yarn. Вы можете найти более подробную информацию на странице проекта OpenZeppelin на github, либо их сайте.
Вот мы и установили все необходимое для начала разработки собственных смарт-контрактов. И это было не так уж и сложно, верно?
Теперь перейдем к текстовому редактору и посмотрим файлы проекта. Можно заметить, что truffle уже создал некоторые базовые контракты при инициализации. Давайте удалим все эти файлы, за исключением файлов миграций. Мы удалим лишний контракт, библиотеку, тесты, а также уберем немного кода из миграций.
Создадим новый solidity-файл с кодом нашего кастомного умного контракта. Я буду делать токен под названием JCR для проведения ICO компании Jincor, а значит, и файл я назову JCR.sol.
Solidity — довольно молодой и динамично развивающийся язык программирования. Это накладывает определенные неудобства, одно из которых — это частые изменения, некоторые из которых способны поломать обратную совместимость, что, в свою очередь, может вызвать проблемы с уже опубликованными контрактами. Для того чтобы это предотвратить, нам необходимо указать версию компилятора языка Solidity. Лично я буду использовать `^0.4.11`.
Заметьте, что здесь `^` означает, что нас также устраивают более новые минорные версии и багфиксы, а не строго указанная версия 0.4.11. Можно определить намного более гибкие шаблоны версионирования точно так же, как вы делаете это в npm.
Как я уже говорил, мы собираемся использовать некоторые контракты из библиотеки OpenZeppelin для того, чтобы не изобретать велосипед, а просто воспользоваться работающими, безопасными наработками, содержащими лучшие практики сообщества и регулярно проходящие security-аудиты.
Для того чтобы импортировать контракт, нужно воспользоваться ключевым словом `import` и далее в кавычках указать путь к импортируемому файлу, как, например, это сделал я: `import «zeppelin-solidity/contracts/token/MintableToken.sol»;`.
Я настоятельно рекомендую ознакомиться с документацией OpenZeppelin от корки до корки и посмотреть на реализации их смарт-контрактов, чтобы иметь ясное представление о том, как именно они работают. Кроме того, в процессе изучения вы увидите примеры оформления кода и сможете найти вдохновение для написания новых контрактов. Вы можете найти исходники в директории node_modules.
Давайте посмотрим на Mintable token, который я собираюсь сегодня использовать. Сейчас мы не будем погружаться в детали очень глубоко, ведь с исходными кодами и документацией вы можете ознакомиться и без моей помощи. Мы просто обсудим самое важное.
Мы видим, что «Mintable token is Ownable, Standard token». Ключевое слово «is» обозначает примерно то же самое, что «extends» в Java или PHP. Контракт Mintable token добавляет 2 события, одно публичное свойство, 2 модификатора и 2 функции. Все вместе это составляет функционал для эмиссии токенов. Standard Token добавляет функционал передачи токенов от лица другого пользователя с предварительно полученным разрешением. Basic token — это просто реализация интерфейса ERC20Basic, который определяет передачу токенов и проверку баланса. Контракт Ownable добавляет модификатор onlyOwner, который, как правило, используется для ограничения вызова функций со стороны третьих лиц.
Теперь вернемся к исходникам нашего контракта и немного изменим их. После того как мы импортировали все необходимые контракты, мы называем наш собственный контракт JCR. Пожалуйста, давайте файлам контрактов и названиям одинаковые имена.
В контракте мы определим публично доступные имя, символ и количество знаков после запятой (равное 18, как у Эфириума).
Затем напишем код конструктора. Конструктор — это просто функция, которая называется точно так же, как контракт, и вызывается при инстанциировании объекта контракта, или, иными словами, при создании нового экземпляра. Это довольно удачное место для инициализационного кода. Лично я хочу сделать контракт, который сможет выпускать указанное количество токенов и передавать все токены на баланс создателю контракта. Для этого я просто добавляю аргумент amount в конструктор, назначаю создателя контракта его же владельцем и выпускаю указанное число токенов на кошелек владельца.
Итоговый файл JCR.sol (также доступен на github)
Теперь давайте попробуем скомпилировать то, что у нас получилось. Сделать это можно, набрав `truffle compile`. Заглянем в папку build и посмотрим, что же мы получили на выходе. Первое, что бросается в глаза — это то, что мы получили артефакты всех используемых контрактов от ERC20, до Mintable и JCR. Артефакты сохраняются в JSON-файлах. Эти JSON-файлы содержат название контракта, Application Binary Interface(abi), двоичный код, которой в последствии будет запущен на Ethereum Virtual Machine и немного дополнительной информации.
Мы можем использовать артефакты для того, чтобы опубликовать наши смарт-контракты в блокчейн. Однако лучше с самого начала приучить себя к хорошему и сразу же автоматизировать этот рутинный процесс, добавив миграцию. Помните, что мы еще должны передавать в конструктор количество выпускаемых токенов? Миграции — это хорошее место для подобных манипуляций. Давайте откроем файл 2_deploy_contracts.js и добавим немного кода. Я собираюсь выпустить 1,4 млн токенов.
Мы можем опубликовать контракты в скрипте миграции, используя метод deployer.deploy, в который первым аргументом мы передадим билд-артефакт, а за ним аргументы, которые дальше в том же порядке передадутся конструктору контракта. В нашем случае у нас всего один аргумент — 1 400 000. Все остальное truffle возьмет на себя. Чтобы сделать процесс деплоя проще и приятней, можно разблокировать аккаунт (разрешить совершать действия от его имени). Для этого при старте testrpc добавьте аргемент `-u 0`
Запустим нашу новую миграцию и посмотрим, работает ли она. Отлично! Теперь нам необходимо убедится в том, что наш токен работает так, как мы от него ожидаем. Для этого мы напишем пару тестов на JavaScript. Наберите `truffle create test` и имя тестируемого контракта, чтобы сгенерировать JavaScript-файл с тестом. Замечу, что тесты можно писать и на Solidity, но об этом мы поговорим позже.
Я надеюсь, что у вас уже есть какой-то опыт написания тестов на других языках программирования, например на PHP. Если вы уже сталкивались с фреймворками Mocha и Chai, то все покажется Вам уже знакомым, так как truffle использует именно их. Более подробную информацию можно найти в официальной документации.
Наконец, давайте попробуем убедится в том, что владелец получил правильное количество токенов при создании контракта и функция передачи токенов ведет себя ожидаемым образом.
На сегодня все. В следующем уроке мы попробуем протестировать наш контракт в более реальном окружении, а также напишем контракт ICO для продажи нашего токена.
Кстати! На youtube доступна видео-версия данной статьи в 2 частях:
Как написать смарт-контракт для ICO за 5 минут
В Интернетах этих ваших и так полно статьей про смарт-контракты, но как только начинаешь писать оный, сталкиваешься с тем, что информация везде повторяется, а туториалов, как запулить свой ERC20 попросту либо нет, либо они устарели что аж донельзя. К слову, чтобы эта статья оставалась актуальной, постараюсь указать потенциальные места, где она может устареть (и как это поправить). Поехали!
Solidity
Это название главного языка, который разработала команда кефира для запуска смарт-контрактов. Если вы программист, то просто пробегитесь глазами по документации языка — он неприлично простой. К слову, сделали его простым, чтобы было сложнее ошибиться в написании смарт-контракта. Так что абсолютно любой программист хотя бы уровня джуниора сможет разобраться в нем. Абсолютно нет смысла платить огромные деньги разработчикам, которые знают солидити — обучить уже существующего разработчика будет на порядок дешевле.
Смарт-контракты
А если вы пометите функцию в контракте словами Constant или View (означают одно и то же, разрешают только читать состояние), либо Pure (то же самое, только даже состояние не читает), то на исполнение этой функции даже кефир тратить не нужно будет! Даже больше скажу, эти функции не нужно вызывать транзакциями — ведь любой клиент кефира, теоретически, сможет ее выполнить у себя — и никому больше об этом знать не нужно (в блокчейн ведь ничего не пишется).
А еще есть две важные штуки в солидити: множественное наследование и модификаторы функций. Про них тоже нужно знать.
Второе — это возможности создавать функции, которые потом будут вставлены в другие функции. Это как простая инкапсуляция, только чуть более гибкая — это буквально шаблон функции. Когда вы создаете модификатор, вы пишете специальный символ _ там, где подразумеваете код функции, использующей этот модификатор. То есть модификаторы — это не просто инкапсулированный функционал, который возвращает значение; это — шаблон функции, когда код из модификатора буквально вставляется в функцию, использующую этот модификатор.
Перейдем к практике.
Готовим окружение
Если вы не знаете, что такое Терминал — почитайте вот эту статью. Если вы на окнах, ставьте себе Терминал через WLS. Если вы уже знакомы с Терминалом, продолжим. Алсо, сразу поставьте себе Node.js — он будет необходим для следующих шагов. Лучше ставить LTS, но, на самом деле, абсолютно без разницы, какую из современных версий ноды ставить.
Если вам выплюнуло версию geth — все в ажуре, продолжаем туториал. Если нет — хреново, исправляйте; придется, похоже, заняться любовными ласками с Терминалом и своей операционной системой — но вам не впервой, разберетесь. Как установите geth, запускайте в Терминале команду:
Это запустит процесс синхронизации вашей ноды с тестовым сервером, блоки которого можно глянуть вот тут. Проверить, синхронизировались ли вы с сетью в консоли geth можно, прописав:
Алсо, я накидал простенький баш-скриптик, который установит все за вас. Вызывается вот так:
— но я его ни разу не тестил еще, так что не уверен в его работоспособности. Однако пулл-реквестам буду только рад.
Фигачим контракт
За вас все уже придумано и написано — это хорошо. Немного головняка будет все равно — но я постараюсь вам его минимизировать. Использовать мы будем уже готовые ERC20 контракты от OpenZeppelin — это сейчас стандарт индустрии, они прошли аудит, да и вообще все их код используют. Спасибо им огромное за вклад в опенсоус.
Сделайте cd в какую-нибудь безопасную папку и после пропишите:
В этой папке и будем работать. Создадим здесь заглушку для нашего смарт-контракта:
Дальше нам нужно забрать текущий код смарт-контрактов из npm и, собственно говоря, начать сам проект:
Ага, вот вам и весь ERC20 интерфейс. Сложно? Не думаю. Дает возможность глянуть, сколько было выпущено токенов, проверить баланс адреса и перевести токенов на другой адрес, выплюнув в сеть событие перевода для легких клиентов кефира. И все это вы получаете фор фри в вашем MyToken.sol благодаря работе OpenZeppelin — они молодцы.
Так-так-так, что тут у нас? Что, пацаны, смарт-контракты? Наша публичная продажа токенов наследует три самых популярных свойства: у нее есть хард-кап, больше которого собрать не получится; софт-кап, не собрав который эфиры возвращаются; время начало и конца продажи токенов. Собственно говоря, а что еще для счастья нужно?
Вот и все — у вас есть готовые контракты вашего собственного ERC20 токена и даже смарт-контракт ICO, который настраивается по вашему желанию и раздает ваши токены за кефир. Алсо, его поддерживают все ERC20 кошельки — ляпота! Перейдем к ручным тестам и деплою.
Миграции
Заметка про web3.eth.accounts[0] : когда деплоите смарт-контракт, убедитесь, что geth или testrpc имеют правильный кошелек в web3.eth.accounts[0] — не теряйте приватный ключ к нему, хоть это никак вам не навредит, но вдруг владельцу что-нибудь потом нужно будет сделать, а ключа уже нет?
Тестирование и деплой
Йес, контракты готовы, миграции написаны, осталось только задеплоить и проверить. Как geth (тестовый и реальный), так и testrpc управляются одинаково через truffle console — так что опишу способ проверки для testrpc и просто расскажу, как включить geth после. И так, запускаем тестовый локальный блокчейн кефира:
Эм… вот и все. У вас локально работает симуляция блокчейна кефира.
Теперь открываем новое окошко Терминала ( testrpc не закрываем — он должен работать) и прописываем в папке проекта:
Эта магическая команда скомпилирует смарт-контракт (то есть не нужно каждый раз писать truffle compile ) и задеплоит его на микро-сервер блокчейна, найденный открытым локально. Стоит отметить, что если testrpc сделает это мгновенно, то тестовый и реальный блокчейны будут гораздо дольше включать транзакцию в следующие блоки. После этого у вас должно выплюнуться нечто подобное в консольку:
Прописываем следующее в теперь уже трюфеле (без комментариев только):
В случае с testrpc можно сразу же проверять снова баланс нашего кошелька, но в случае с тестовым и реальным блокчейном нужно подождать, пока транзакция наша будет включена в блок — обычно, когда это происходит, трюфель выдает вам номер транзакции. Подождали? Проверяем снова наш баланс в MyToken :
Заключение
Удачи в разработке смарт-контрактов! Остались вопросы? Милости прошу в комментарии — с удовольствием на все отвечу и постараюсь помочь с проблемами.
Бонус
А что, если вы хотите изменить логику, по которой считается цена покупки токенов? Конечно, можно изменить правильно rate или использовать один из классов контрактов от OpenZeppelin, но вдруг вы хотите чего-нибудь еще более извращенного? В смарт-контракте можно оверрайтнуть функцию getTokenAmount следующим образом:
В общем, так можно сделать цену токена зависящей от времени покупки — чем дальше в лес, тем дороже токены. Не бойтесь экспериментировать и переписывать некоторые функции смарт-контрактов — это весело!