Боевая машина ICO: смарт-контракт на Ethereum
Ошибка в смарт-контракте может стоить основателю проекта, решившему провести ICO, доверия инвесторов и всех собранных денег, а разработчику – репутации. Правильно организованное ICO – словно боевая машина, конструкция которой не терпит изъянов, а сам смарт-контракт должен работать как добротные швейцарские часы. За последние годы, разработчики успели накопить опыт, причём, достаточно горький. Поэтому приступая к созданию смарт-контракта – стоит обратить внимание на уже существующие постулаты.
Многие специалисты очень толково пишут о блокчейн-технологиях и, в частности, об особенностях смарт-контрактов и ICO в целом. Но подача материала зачастую довольно сложно поддаётся пониманию. Поэтому я взял на себя смелость адаптировать найденный на Хабре материал, так сказать, под более широкую аудиторию.
Профи и без меня разберутся, а остальным, думаю, будет полезно получить базовое представление относительно смарт-контрактов и организации ICO с технической стороны.
Техническое задание
Всё начинается с простой, на первый взгляд, задачи от основателей проекта, которые желают провести краудсейл и собрать от инвесторов как можно больше средств на развитие, и себе на чашечку кофе.
Как правило, задание сводится к выпуску энного количества токенов и продаже их инвесторам по текущему курсу к эфиру. Причём, зачастую, конкретных параметров сразу не даётся. Заказчик считает, что может подумать и выдать их прямо в ночь перед ICO.
Почему-то вполне себе подкованные в блокчейн-технологиях люди думают, что параметры смарт-контракта меняются «на лету» в любой момент. Поэтому важно донести до них понимание, что это не совсем так. Важно проработать экономическую модель сразу, чтобы потом ничего не менять в последний момент.
Необходимо получить и зафиксировать на бумаге все константы, чтобы сразу использовать их при разработке. Чем сложнее условия контракта – тем больше потребуется тестов с учётом конкретных параметров. При малейшем изменении – всё придётся тестировать заново. И только потом выкладывать открытый код на GitHub.
Как вариант – можно совместно с заказчиком написать этакую историю взаимодействия смарт-контракта с инвестором.
Выглядеть это может следующим образом:
Только так можно быть уверенным, что разработчик правильно понимает заказчика.
Если возникает ощущение, что основатели проекта сами не знают, как именно должно быть организованно взаимодействие – стоит предложить им всё хорошенько обдумать, и только потом продолжать совместное обсуждение. В противном случае, можно потратить даром много времени, и не прийти к конечному результату.
В принципе – большинство разработчиков и так понимают, что без хорошего ТЗ необходимого результата не выйдет. Каждый со временем выработает собственные алгоритмы взаимодействия с заказчиками. Поэтому стоит переходить к основной части.
Технические аспекты разработки смарт-контрактов в Ethereum
Да, безусловно – код смарт-контракта в Ethereum доступен всем, но не всё так просто. Если банально пульнуть в блокчейн транзакцию «create_contract», то после того, как её замайнят – инвесторы смогут увидеть только байт-код контракта:
И чего они здесь поймут? А надо? Ну вроде как.
Должен выглядеть вот так:
Здесь более или менее понимающий человек хоть что-то сможет понять. Если захочет, конечно. Полная версия здесь.
Но для создания читаемого вида – потребуется верификация смарт-контракта. Муторная процедура, но необходимая.
Причём не лишними будут комментарии, написанные на общечеловеческом языке.
Например – вот так.
Это смарт-контракт проекта MyWish – платформы для заключения смарт-контрактов, которая этой осенью провела успешное ICO.
Перевод комментариев к контракту подготовила команда сайта ICO Digest – каталога наиболее перспективных и надёжных блокчейн-проектов, решивших провести собственный токенсейл.
Ошибки, которых не стоит допускать
Не стоит забывать, что смарт-контракт – это публичный код, и каждый должен иметь возможность заглянуть в него, и с умным видом ткнуть пальцем в непонятный ему фрагмент кода. Поэтому если в контракте есть, скажем так, сомнительные моменты (чего быть не должно) – разработчики и основатели проекта должны быть готовы отвечать на «неудобные» вопросы. И если контракт будет позволять дополнительно выпустить некоторое количество токенов (что, например, противоречит обещаниям) или, тем более, перевести токены на другой адрес до окончания ICO – подозрения у инвесторов (из числа грамотных) непременно возникнут.
О чём может идти речь?
Выпуск дополнительного количества токенов после токенсейла. Никому не понравится если у бенефициаров будет, пускай и гипотетическая, возможность сгенерировать себе «+100500 мильонов токенов», продать их, и отправиться отдыхать на Багамы. Если смарт-контракт всё же допускает возможность дополнительного выпуска токенов – это должно быть заранее обоснованно в White Paper.
Возможность перевода средств только одним бенефициаром. Иными словами – отсутствие функции мультиподписи. А точно – разве можно доверить свои кровные 5000$, столь тяжко заработанные на росте курса Биткойна, всего одному компу бенефициара? Да пусть он будет хоть Папой Римским и собирает на новую церковь, но алчных хакеров святое распятие не остановит. Поэтому так важно, чтобы перевести средства было можно только посредством нескольких подписей. Иначе, полученные миллионы можно запросто подарить какому-нибудь Васе из 5Б.
Кстати, между мультиподписью для адреса в Биткойне и мультисиг-контрактом в Эфире есть значительная разница. Если для перевода с мультисиг-адреса Биткойна требуется сформировать транзакцию в оффлайн – создав файл, прогулявшись с флэшкой по компам, то для вывода средств с мультисиг-контракта в Эфириум требуется послать на него несколько транзакций с разных машин. Часто заданные условия позволяют совершить перевод при получении контрактом 2 из 3 подписей в виде транзакций.
И ещё один важный момент – создать мультисиг-контракт не проблема, но для того чтобы во всех используемых для этого клиентах отображались актуальные цифры, необходимо чтобы один из них был полным узлом.
Довыпуск токенов или их принудительная передача команде. Отсутствие условий в коде о времени вывода средств можно смело считать дурным тоном. Как минимум, на период токенсейла все переводы должны быть невозможны.
Отсутствие контракта на GitHub. Публичный доступ к коду – это уже необходимость априори. Причём, выложен он должен быть, как минимум, за несколько дней до начала продажи токенов. Ничего добавлять в него за пару часов до старта ICO не следует. А то выглядеть это будет так: «Подождите, подождите – я тут вот забыл… Всё – теперь забрасывайте меня своими миллионами». Дело в том, что желательно, чтобы перед запуском контракт оценили специалисты. И изменения после аудита доверия не добавят. Идеально – публикация контракта за месяц. И никаких изменений. Спешные правки выдают дилетантов. Поэтому перед публикацией – множество тестов и аудит у профессионалов.
Отсюда понятно, что будь вы разработчиком, финансистом или профессиональным инвестором в ICO – вам следует обязательно разбираться в коде смарт-контракта, а значит владеть языком Solidity. Даже если вы не разработчик – то основы, в любом случае, знать нужно. Для разработки идеального смарт-контракта потребуется грамотный финансист и одарённый разработчик – и лучше, если это будет один и тот же человек.
И напоследок – будьте внимательны к timestamp (временным меткам, программирующим контракт на определённые действия в определённое время). Никто ведь не хочет, чтобы смарт-контракт на определённом этапе «застрял» или закрыл токенсейл? Цена ошибки очень высока.
Деплой
Допустим, все детали учтены – и настало время развернуть смарт-контракт в сети. Иными словами – «задеплоить» его.
Для этого необходимо отправить из клиента Ethereum большую транзакцию, содержащую код смарт-контракта. Это равносильно указанию для сети поместить контракт по определённому адресу. Посредством адреса пользователи смогут обратиться к контракту.
По сути – контракт является своеобразным автоматизированным кошельком, у которого есть свой баланс, и который может принимать и отправлять эфир. В общем, такой же равноправный участник сети.
Работает всё просто – если на адрес контракта послать сумму в эфире, то он произведёт расчёт и отправит обратно определённое количество токенов. После этого майнеры включат эту информацию в очередной блок и таким образом исполнят контракт и транзакцию от пользователя.
Помните, что изменить контракт после деплоя не выйдет – можно только создать новый код и разместить его по другому адресу.
Ладно – стоит признаться честно, что всё не так страшно. На самом деле, есть возможность вносить правки. Для этого предусматривается контракт-контролёр, который хранит в себе адреса остальных простых контрактов.
В этом случае, пользователи отправляют средства на контракт-контролёр, а уже он делает перенаправление на любой другой контракт. Поэтому старый можно заменить на новый. Таким образом, разработчики могут исправить ошибку, просто создав новый код и изменив адрес в основном контракте. И, как правило, сложные системы смарт-контрактов без контролёров не делаются.
Но, в то же время, ничего не мешает разработчикам в любой момент просто заменить контракт на более выгодный для себя. В общем, обратная сторона монеты, которая может насторожить инвесторов. Никому это не понравится. Да и вообще – сложные системы, где один контракт вызывает другой, более уязвимы.
Поэтому лучше сразу учитывать все нюансы, делать один контракт, и ничего потом в нём не менять. Больше доверия будет.
Помните, что банальная опечатка в датах может обернуться тем, что на определённом этапе контракт просто заблокирует средства, и никто их оттуда уже не достанет.
Контролёр позволит создать новый контракт – но как всё это будет выглядеть в глазах инвесторов, которые сделают выводы относительно компетенции разработчика?
Также учитывайте, что чем сложнее контракт, например, если он позволяет одному пользователю предъявить «секрет», переданный ему другим пользователем и получить бонус к токенам – тем больше рисков. Это часто используется, если в токенсэйле задействованы реферальные программы и бонусные скидки.
В этом случае, неправильно составленный контракт может содержать логические дыры и позволить создать цепочку из инвесторов, которые по очереди зарабатывают бонусы сами на себе, циклически «продавая» сами себя.
К тому же, такие алгоритмы требуют дополнительных вычислений и соответственно, более значительных расходов газа. И чем сложнее – тем дороже транзакция.
Иными словами, дополнительная сложность – больше уязвимостей и головной боли.
Личный кабинет инвестора
Да – личный кабинет… У многих возникает вопрос – а насколько он нужен? Если бы дело для блокчейна Эфириума ограничивалось только переводами в эфире – то, вероятно, это было бы полным излишеством. Скажем так, «коммерческими понтами».
Без инвестиций в других криптовалютах и, тем более, фиате – кошелёк эфира подошёл бы в роли лучшего личного кабинета инвестора. Там ему и защита, и конфиденциальность, и удобства. История транзакций, бэкап и все остальные плюшки прямо из коробки. Нужно только указать на сайте адрес смарт-контракта и ждать поступлений. Красота. Даже со смарт-контрактом не нужно морочиться – берите готовый вариант, правьте под себя и дело готово. Так что задумайтесь о всех преимуществах сборов в чистом эфире.
Но не всё так просто в мире финансов и блокчейн-технологий. Некоторые познакомились только с Биткойном, завели себе адрес с пятой попытки и дрожащими руками перевели туда со Сбербанка кровные 300$. А некоторые вообще только вот решили познакомиться с миром криптовалют и желают перевести на счёт бенефициаров с банковской карты или электронной системы, наподобие, PayPal. Как быть?
Вот тут и нужен личный кабинет. С интерфейсом, вариантами оплаты, инструкциями и красивым отображением баланса. А может ещё и KYC как положено в цивильных странах привинтить? Ну тогда полный ажур. Но для всего этого придётся потрудится. И это уже, скажем так, выходит за рамки простой разработки смарт-контракта.
Нужно разбираться в веб-технологиях и, особенно, в защите сайта от фишинговых атак. Лучше использовать только статический html – минимум брешей в защите и ддосом уложить его тоже непросто. Поэтому клиента быстрее фишингуют на поддельный сайт где-нибудь на уровне подмены сертификатов или просто кинув ему ссылку в чате.
Мой кабинет – моя крепость
Ладно, оставим пока на фишинг напоследок и разберёмся, что требуется, чтобы наш дорогой инвестор смог сделать перевод, например, в биткойнах.
Для начала нужно показать ему – куда переводить биткойны. Вот для этого и нужен кабинет, где пользователь укажет свой эфириум-адрес. Да – без него, в любом случае, не обойдёмся. Потому что токены на эфире могут начисляться только на эфириум-адрес. В кабинете можно предоставить для этого инструкцию или возможность сгенерировать кошелёк прямо, так сказать, не отходя от кассы.
Для этого можно создать пары ключей самостоятельно и отдать инвестору, чтобы тот мог открыть ими, к примеру, MyEtherWallet. Но это всё равно требует от него конкретных действий, и нужно доказать ему, что сами вы эти ключи не видите. Проще дать ему инструкцию – как завести кошелёк. После чего он укажет адреса – откуда придут (BTC) и куда положить (ETH). Всё должно быть указано верно – это в его же интересах. А иначе – ну это уже его проблемы…
Теперь потребуется скрипт, который по расписанию будет мониторить блокчейн Биткойна, или любой другой, в поисках транзакции со знакомого адреса на указанный вами. Пришёл перевод – скрипт связывается с нодой Ethereum, откуда в смарт-контракт отправляется транзакция, вызывающая метод mint (address addr, uint amount). Иными словами – контракт получает указание отправить на конкретный адрес определённое количество токенов. Метод подходит даже для таких платёжных систем как VISA или MasterCard – если, конечно, есть доступ к логу их платежей.
И если с самим смарт-контрактом, скриптом и интерфейсом личного кабинета, как правило, проблем никаких, то с защитой от злостных хацкеров всё довольно сложно.
Поймите – удачное ICO привлечёт не только внимание спецслужб, но и разного рода злоумышленников, которые очень не прочь отхватить смачный кусок от этого вкусного пирога. Или даже завладеть им полностью. Они точно знают, что игра стоит свеч (баланс сборов на виду). И они – во всеоружии. А вы?
Им всего лишь нужно получить доступ к админ-панели сайта и подменить всего одну строчку, направив инвестиции на свой адрес. И не важно, что потом для того чтобы вывести средства им придётся нанять армию гоблинов для обнала – они найдут способы, было бы что обналичивать. И сайт со сборами от миллиона долларов они будут прессовать всем чем только могут – от троянов, которые могут подменить адрес прямо в буфере при копировании до масштабных ддос-атак. Это может стать настоящей войной, которую вы даже не заметите, если безопасность будет на высоте. Или узнаете, что проиграли, когда уже будет слишком поздно.
Поэтому, если хотите меньше рисковать – собирайте только в эфире. Лучший кабинет инвестора – Ethereum Wallet. Сурово и немногословно – не крутите дырявых украшательств сайта. Серьёзным людям – не к лицу.
И помните, даже при лучшей защите не стоит расслабляться. У вас должен быть готовый сценарий действий для основных типов проблем. Например – это ддос, нашествие фишеров в чаты или даже взлом контракта. Все должны быть готовы – от разработчиков до SMM-специалистов.
Но чтобы ваша команда не дежурила посменно у мониторов (что, конечно, желательно), тем более, что некоторые ICO идут от нескольких месяцев до года – автоматизируйте процесс. Ну пусть хотя бы простой скрипт будет ходить на сайт и проверять его работоспособность, а также наличие правильного адреса для транзакций инвесторов. Мониторьте блокчейн – ведь исходящая транзакция с адреса для сборов раньше положенного времени говорит об успешной атаке. Иными словами, что-то не так? Тогда боевая тревога – и вперёд спасать средства инвесторов и собственную репутацию.
Заключение
Поэтому так важно не только провести аудит смарт-контракта, но и всего crowdsale-комбайна. Это реально должно быть боевой машиной и никак иначе. Со временем, это, конечно, станет отработанной схемой и, по всей вероятности, данную заботу на себя возьмут конструкторы ICO. Возможно, даже страховку будут предлагать. Но пока многие предпочитают обходится собственными силами – и вся ответственность лежит только на них. Это ответственность не только за судьбу своего ICO, но и за репутацию блокчейн-технологий в целом. Помните это.
По материалам статьи
Источник: bitnovosti.com
