@backmeupplz18 июн 2018 в 20:56

Как написать смарт-контракт для ICO за 5 минут

14 мин

68K

JavaScript * Node.JS * Solidity * КриптовалютыПлатежные системы *

+12

Комментарии 49

@wiwrel 19 июн 2018 в 05:27

Критику принимаете?
Ну тогда вот.

Поменьше жаргона
Расшифровать обозначения и малоупотребимые слова. В том числе и жаргон, если его нельзя избежать
Строго говоря за 5 минут не поднять этот смарт-контракт (кстати что это?). Я статью читал дольше
Язык Solidity может и простой, но пока во всей терминологии разберешься — потратишь кучу времени

И вот как пример — это можно на русский язык перевести?

Алсо, мы проверяем, что хардкеп у нас выше софткепа — алес гут! Алсо, не пугайтесь туче параметров в конструкторе MyCrowdsale — мы передадим их на этапе деплоя контракта в трюфеле.

@backmeupplz 19 июн 2018 в 05:37

Сорямба за жаргон, мне больше важно наполнение, нежели форма
Да все достаточно понятно — это просто мой художественный стиль, на самом деле
Нет, поднять за 5 минут после прочтения вполне можно — там пара-тройка команд в консоли (а про то, что такое смарт-контракт, написаны десятки статей)
Да нет, не особо-то и кучу времени — большинство вещей в Солидити заимствовано из других ЯП

В общем, спасибо за критику — но, к сожалению, это мой художественный стиль раздолбайский :( постараюсь в будущем исправиться!

Алсо, мы проверяем, что хардкеп у нас выше софткепа — алес гут! Алсо, не пугайтесь туче параметров в конструкторе MyCrowdsale — мы передадим их на этапе деплоя контракта в трюфеле.

«Алсо» — от английского «also», в переводе означает примерно «также»
«Хардкеп» и «софткеп» — устоявшиеся в сфере ICO термины границ сбора средств
«Алес гут» — от немецкого «alles gut», в переводе — «все хорошо»
«Конструктор» — это функция создания объекта соответственного класса
«Деплой» — от английского «deploy» — запуск написанного кода, часто в рабочее окружение пользовательской среды
«Трюфель» — это англицизм от названия командной программы «truffle»

Черт, меня не было полтора года на Хабре. Куда делись хардкорные разработчики, которые ценят подобный «раздолбайский» художественный стиль редактуры?

@wiwrel 19 июн 2018 в 05:47

Алсо, мы проверяем, что хардкеп у нас выше софткепа — алес гут! Алсо, не пугайтесь туче параметров в конструкторе MyCrowdsale — мы передадим их на этапе деплоя контракта в трюфеле.

Итого:

Также, мы проверяем, что жесткая граница сбора средств (hard-cap) у нас выше вариабельной границы сбора средств (soft-cap) — всё хорошо. Также, не пугайтесь большому количеству параметров в конструкторе MyCrowdsale — мы передадим их на этапе запуска кода контракта в командной программе truffle

Всё так?

P.S.: Простите мое занудство, написано интересно, но жаргон сбивает с толку

@backmeupplz 19 июн 2018 в 05:49

Все примерно так, да! Спасибо за расшифровку. В следующих статьях обязательно исправлюсь и начну использовать жаргон меньше — я новенький на Хабре, еще не освоился.

@wiwrel 19 июн 2018 в 05:55

Ну я бы не сказал что новенький :) Скорее я такой. Но вот вашу предыдущую статью — вполне приятно читать, несмотря на жаргон — он там есть, но его немного и не касается специфичных терминов.

@backmeupplz 19 июн 2018 в 05:58

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

@gaddyya 26 авг 2021 в 12:23

А по-моему тут как раз все хорошо с жаргоном, он очень к месту в такой статье! Продолжайте пожалуйста в том же духе. Успехов!

@AndreySu 19 июн 2018 в 05:42

Да, статью читать не приятно с таким жаргоном.

@backmeupplz 19 июн 2018 в 05:45

Хм, а наполнение вы как оцените по шкале от 1 до 10? Где 1 — сообществу абсолютно не нужно (очередной абстрактный очерк о смарт-контрактах в общем), и 10 — где статья, необходимая развитию отрасли (документация Solidity).

@Darth_Malok 19 июн 2018 в 06:40

Почему не ERC-223?

@backmeupplz 19 июн 2018 в 06:42

Потому же, почему не ERC721 и не ERC827 — нужно же с чего-то начинать. Может, следующей частью рассмотрю разные стандарты и как их запустить — там все достаточно одинаково.

@Darth_Malok 19 июн 2018 в 06:50

ERC721 не является заменой ERC-20, а ERC-223 исправляет пару проблем ERC-20 и обратно совместим. Он лучше во всём. И, вроде бы, не намного и сложнее. Могу ошибаться.

Просто забавно периодически читать, что скоро осуществится глобальный переход на ERC-223, и видеть всё новые токены на уже «устаревшем стандарте»)

@backmeupplz 19 июн 2018 в 06:52

Ну, насколько мне известно, ERC-223 это лишь токен с «защитой от дурака» — чтобы нельзя было перевести токены на какой-нибудь смарт-контракт без возможности вывода :) но это уже совсем частные детали. Согласен, что стоит переходить на убер ERC-223, похоже, точно стоит об этом статью начеркать. Спасибо!

@quantum 19 июн 2018 в 17:37

И где вы это читаете? Про глобальный переход

223 даже тут нет eips.ethereum.org/all, т.е. его статус не определено вообще

@kozyabka 19 июн 2018 в 07:16

Ждём статью «Как написать бэк-енд для магазина за 5 минут» или «Разворачиваем AWS окружение за 5 минут»

@backmeupplz 19 июн 2018 в 07:19

Ну а что, не стоило писать эту статью? :( Я, когда пытался запустить свой смарт-контракт, так и не нашел нормальной последовательной статьи о том, как это сделать. Ну и подумал, вдруг кому полезно будет, если такая статья окажется в Интернете :( можете поделиться другой актуальной статьей на тему запуска смарт-контракта ICO, пожалуйста?

@kozyabka 19 июн 2018 в 10:11

Таких статей скорее всего нету потому что у каждого свои требования к контрактам. А такие вот «за 5 минут» нередко потом выходят боком, который к тому же не всегда можно пофиксить)

@backmeupplz 19 июн 2018 в 14:46

Гхм. Если таких статей нет — то как начать писать типовые смарт-контракты под ICO? И чем эти требования уникальны? В последнее время что не ICO — так Timed, Capped, Refundable, etc. Все это уже есть в OpenZeppelin, а расширяется смарт-контракт максимально просто (в конце статьи пример привел).

Так же в статье я описал способы тестировать смарт-контракты на тестовых блокчейнах. Знаете, что чаще всего выходит боком? Когда разработчики вместо того, чтобы взять проаудированный OpenZeppelin начинают фигачить свой велосипед с нуля. Вот тогда — беда.

@kozyabka 19 июн 2018 в 18:21

Ну и зеплин не всегда сахар)
github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/token/ERC20/BasicToken.sol
Основной метод, transfer (31 строка):

function transfer(address _to, uint256 _value) public returns (bool) {

 require(_to != address(0));

 require(_value <= balances[msg.sender]);



balances[msg.sender] = balances[msg.sender].sub(_value);

 balances[_to] = balances[_to].add(_value);

 emit Transfer(msg.sender, _to, _value);

 return true;

 }

Не находите ничего странного?

sub в данном случае не нужен, так как проверка на необходимое значение балансу уже описано в require(_value <= balances[msg.sender]);
скажете неважный момент, представьте сколько таких контрактов и сколько было этих transfer и сколько газа система потратила на эту проверку)

@backmeupplz 19 июн 2018 в 19:03

Эм, простите, но 35 строка (balances[msg.sender] = balances[msg.sender].sub(_value);) — это не какая-то проверка, это изменение количества токенов на кошельке отправителя. Так что, честно скажу, не понимаю к чему вы тут придираетесь.

Если убрать 35 строку — то при переводе баланс отправителя не будет меняться и можно будет бесконечно создавать токены. Если убрать 33 строку (require(_value <= balances[msg.sender]);), то есть вероятность, что баланс отправителя уйдет в минус, а получатель получит токенов больше, чем было у отправителя.

Так в чем претензия? Ну, еще учтите, что компилятор от truffle тоже оптимизации какие-никакие, но делает.

@kozyabka 19 июн 2018 в 19:08

Строку не нужно убирать, а следует писать:
balances[msg.sender] = balances[msg.sender] - _value;
а в sub происходит еще одна дополнительная проверка которая в нашем случае лишняя.

@backmeupplz 19 июн 2018 в 19:27

Неправильно вы пулл-реквесты пишете, товарищ — нужно их делать на ГитХабе, а не на Хабре. Вот, засабмитил PR — спасибо, благодаря вам код станет лучше.

Линуксом тоже перестанем пользоваться из-за того, что он в некоторых местах недостаточно оптимизирован? Может и C++ дропнем по той же причине? А там и С не особо-то и вежливо пользуется регистрами процессора. Вот и будем жить с Assembly или машинным кодом. Вообще, идеал — перфокарты.

Никто не говорил, что OpenZeppelin идеален — но мы, как сообщество open-source, стараемся делать его лучше с каждым днем. И это далеко не аргумент против использования этого готового кода.

@quantum 24 июн 2018 в 22:11

Это разные проверки для разных вещей.

Тут require для пользовательского ввода (возвращает неиспользуемый газ)
Там assert для внутренних операций (логическая ошибка, жрет весь газ)

Находясь в функции вы не должны знать, как там работает внутри sub из safemath. Вы просто его используете, т.к. он безопасен (underflow).

Т.к. ZS — это примеры безопасного кода, а не оптимизированного, то я удивлюсь, если они примут этот PR

kozyabka — для привлечения внимания :)

@kozyabka 24 июн 2018 в 23:25

И в каком случае в это месте может произойти underflow?
ПС. проверка эта избыточна)

@backmeupplz 24 июн 2018 в 23:26

О! Вы вернулись. Как так получилось, что вы больше времени потратили на написание комментария на Хабре, когда могли бы гораздо меньше времени потратить на PR?

@kozyabka 19 июн 2018 в 19:17

Так что, честно скажу, не понимаю к чему вы тут придираетесь.

Вот Вам пример 5и минутных обучений ;)

@backmeupplz 19 июн 2018 в 19:28

Предложите альтернативу OpenZeppelin? :) Или каждому ICO переизобретать колесо снова и снова, делая одни и те же ошибки и наступая на одни и те же грабли?

@kozyabka 19 июн 2018 в 22:47

Дело в другом. Писать смарт контракты за «5 минут» без реального понимания кода, эфира и вот этого всего это не супер идея. Меня неоднократно просили разруливать проблемы с контрактами, и не всегда это вообще возможно. Лучше доверять профессиональным инженерам или самому разобраться на хорошем уровне. Если суммы серъёзные планируете собрать и плюс ко всему это утилити токены.

@backmeupplz 19 июн 2018 в 22:52

Никто и не советует в статье писать смарт-контракты «без реального понимания кода, эфира и вот этого всего» — наоборот, в статье я неоднократно призываю именно углубиться в реализацию контрактов, разобраться в них сильнее.

И да, закосячить смарт-контракт на основе OpenZeppelin и этой статьи — это нужно будет постараться. Эта статья, скорее, не призыв «делайте смарт-контракты за 5 минут», а просто пруф концепта: «вот так можно сделать смарт-контракт за 5 минут», объясняющий основные части разработки и запуска смарт-контракта.

@johnkimoo 19 июн 2018 в 07:19

Буду так же очень признателен, если поделитесь этой статьей со своими друзьями или знакомыми, которые хотят провести ICO — сэкономьте им $75,000 на недо-программистов, которые высасывают деньги из крипто-рынка, как паразиты, копи-пастя одни и те же 25 строк кода.

Некоторые ICO имеют специфичные условия продажи токенов, например, включают процедуру их сжигания; а где-то требуется заморозка токенов на определенный период. Подобные нюансы каждой кампании по сбору средств, видимо, и вынуждают обращаться к тем самым «недопрограммистам», которые высасывают деньги из крипто-рынка. Хотя согласен, что цена их услуг совершенно неподъемная для маленьких стартапов.

@backmeupplz 19 июн 2018 в 07:21

Но и сжигаемость, и заморозка есть в контрактах OpenZeppelin! :) Так что эта статья — это просто указание на путь программистам и проектам, мол, не сложно все это. Да и даже с нуля дописать сжигаемость и заморозку на основе контрактов от OpenZeppelin — это строк 10-20 кода, с чем смогут справиться штатные программисты проекта. В общем, сколько ни говори об уникальности ICO — а они все похожи и все уже придумано и написано до них.

@johnkimoo 19 июн 2018 в 07:30

Абсолютно с вами согласен. Порог вхождения, конечно, остается высоким, да и сама тема ICO у многих вызывает недоверие. Надеюсь, кто-нибудь уже наконец напишет «Конструктор ICO», чтобы не думать о коде и его последующем аудите. Вот тогда и цена на разработку смарт-контрактов упадет до среднерыночных и приемлемых $25-50 долларов в час.

@backmeupplz 19 июн 2018 в 07:33

Хе-хе-хе, это как-раз то, чем я сейчас занимаюсь: абсолютно бесплатный конструктор ICO с открытым исходным кодом — Fondu. Делаю пока что чисто ради фана — потом посмотрим, вдруг, людям понравится. Прямо там лежит и MVP — конструктор смарт-контрактов который я допилю завтра-послезавтра. Но монетизировать абсолютно никак не планирую: мое мнение — под каждый сбор денег на любую вещь можно создавать ICO, и именно этой мысли мы и придерживаемся.

@backmeupplz 21 июн 2018 в 07:57

Алсо, небольшой апдейт: теперь там можно собрать себе все нужные файлы смарт-контракта под ICO в конструкторе, скачать эти файлы и запустить небольшой скриптик, который задеплоит контракты в testrpc. Завтра, похоже, буду прикручивать `geth` :)

@backmeupplz 26 июн 2018 в 21:08

И еще один апдейт: теперь конструктор полностью рабочий. Указал все поля, скачал файлы, запустил ./deploy.sh и автоматически деплоишь смарт-контракты краудсейла в локальный, тестовый и главный блокчейны эфира.

@30mb1 19 июн 2018 в 10:17

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

Мало уметь писать на солидити. Надо также хорошо понимать принципы работы блокчейна и ообенности работы EVM. Если смарт-контракт представляет из себя что-то сложнее чем ERC-20 токен, то код, написанный опытным разработчиком, с высокой вероятностью будет как надежнее, так и эффективнее (не будем забывать, что хранение каждого байта стоит денег).

@backmeupplz 19 июн 2018 в 14:49

Не соглашусь, что «принципы работы блокчейна и особенности работы EVM» — это так уж сложно. EVM изначально был написан максимально просто для разработчиков — и основные принципы там далеко не такие страшные. Так что и джуниор разобраться сможет.

Ну и в этой статье мы рассмотрели именно ERC20, как базовый и самый распространенный способ работы с EVM. Что-либо сложнее — уже вне рамок статьи, что и является причиной, почему небольшое расширение упало в бонусную часть.

@JekaMas 19 июн 2018 в 19:02

Вы про какую реализацию EVM говорите? По долгу службы много копаюсь в Ethereum geth, недавно копался с багом с evm. И оно ни разу не для junior.

@backmeupplz 19 июн 2018 в 19:06

А, так и говорите: не «принципы и особенности работы EVM», а «внутреннее содержание кода EVM». Чтобы писать отличный код на Swift, не нужно быть экспертом в LLVM. Так же и с EVM. Чтобы писать отличный код на Solidity, не нужно знать все тонкости EVM.

С принципами и особенностями работы ознакомиться может любой джун, использовать их тоже. Никто не ведет речь про раскопки в коде EVM.

@JekaMas 19 июн 2018 в 19:54

Тогда ок. Просто насторожили слова "EVM изначально был написан максимально просто для разработчиков". Там в EVM не просто и немало мест с data race.

@backmeupplz 19 июн 2018 в 19:57

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

@JekaMas 19 июн 2018 в 20:18

Согласен полностью.
И да, интерфейс EVM простой, как и его идея, зачем он нужен и как контракты исполняются.

НЛО прилетело и опубликовало эту надпись здесь

@backmeupplz 19 июн 2018 в 14:51

Ни в коем случае не пропагандирую копи-пейст подход. Наоборот, в статье я не раз указывал, мол, сходите в суперклассы — посмотрите что и как там написано. OpenZeppelin большие молодцы — их код приятен для чтения и достаточно прост.

Кстати, работая с OpenZeppelin, гораздо проще понять, что делаешь, нежели с абстрактным примером из ethereum.org/token ;)

НЛО прилетело и опубликовало эту надпись здесь

@Ramesse 20 июн 2018 в 16:15

Огромное спасибо за статью!!! :)

@backmeupplz 20 июн 2018 в 16:15

Рад, что понравилось :) значит, писал не зря

@robert_ayrapetyan 8 сен 2018 в 16:28

Казалось бы, прошло не так много времени, а статься безнадежно устарела. Поменялись имена классов и методов (например, вместо transferOwnership появился addMinter), пришлось пройтись по всем граблям заново, но спасибо этой статье, без нее разобраться бы вряд ли получилось. Было бы шикарно увидеть статью по отладке солидити. Спасибо!

@robert_ayrapetyan 8 сен 2018 в 19:47

Ну и пара багов в самой статье:
— const openingTime = 1514764800; // 15 Июня 2018
Вот тут нужно было уточнить, что не только эта дата должна быть больше даты последнего блока, но что и ранее этой даты транзакции не пройдут. Поэтому в коде (тестовом) нужно писать что-то типа:
const ts = Math.round((new Date()).getTime() / 1000);
const openingTime = ts + 10;
чтобы можно было тестить контракт через 10 секунд после деплоя.

— const cap = 200 * 1000000; // Хардкеп
и далее в тесте: web3.eth.sendTransaction({from: account, to:c, value: web3.toWei(0.1, 'ether'), gas: 900000})
Низя, 0.1 эфира много больше хардкепа.

А вот отловить эти баги — та еще песня. Напишите об этом статью.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий