Диплом: Применение технологии блокчейн для создания криптографических токенов

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
62
Remix
Remix но - это но интегрированная среда но разработки (IDE) для но разработки
смарт-контрактов на но языке программирования но Solidity. Имеет но встроенные
средства но отладки и но тестирования.
Работает но онлайн, в но браузере. Доступен по но адресу remix.ethereum.org.
но Также можно но использовать локальную но версию.
Remix но позволяет решать но следующие задачи:
Разрабатывать но смарт-контракты.
Отлаживать но выполнение смарт-контракта.
Предоставлять но доступ к но состоянию и но свойствам уже но развернутого
смарт-контракта.
Отлаживать но уже совершенную но транзакцию.
Анализировать но надежность кода.
Remix но имеет графический но интерфейс, состоящий из но четырех частей.
Проводник но файлов
Редактор но программного кода
Терминал
Панель но вкладок компиляции, но выполнения, настройки и но отладки
3.5. но Практическая реализация
3.5.1. но Смарт-контракт создания но токена
Описание но методов и но событий
Рассмотрим но подробней методы но и события, но входящие в
но смарт-контракт создания но токена, необходимые для его но соответствия
стандарту но ERC20:
63
1. но Метод
function но totalSupply() constant но returns (uint256 но totalSupply)
Возвращает но суммарное количество но выпущенных монет. Эту но функцию
может но вызвать любой.
2. но Метод
function но balanceOf(address _owner) но constant returns но (uint256 balance)
Возвращает но количество монет но принадлежащих _owner. но Может вызвать
но любой. Кошельки для но отображения количества но монеты вызывают но именно
эту но функцию.
3. но Метод
function но transfer(address _to, но uint256 _value) но returns (bool но success)
Передает но _value монет на но адрес _to. но Когда пользователь но будет перемещать
но свои монеты на но другой адрес но вызываться будет но именно эта но функция.
Соответственно но монеты должны но браться с но баланса пользователя, но который
вызвал эту но функцию. Метод но должен создавать но событие Transfer в но случае
успешного но перемещения монет.
4. но Метод
function но transferFrom(address _from, но address _to, но uint256 _value) но returns (bool
но success)
Передает но _value монет от но _from к но _to. Пользователь но должен иметь
но разрешение на но перемещение монеток но между адресами, но дабы любой
но желающий не но смог управлять но чужими кошельками. но Фактически эта
но функция позволяет но доверенному лицу но распоряжаться определенным
но объемом монеток на но счету _from. но Дать разрешение на но управление
средствами но можно следующей но функцией. Метод но должен создавать
но событие Transfer в но случае успешного но перемещения монет.
5. но Метод
function но approve(address _spender, но uint256 _value) но returns (bool но success)
64
Разрешает но пользователю _spender но снимать со но счета, вызвавшего но функцию
пользователя но средства не но более чем но _value. На но основе этого но разрешения
должна но работать функция но transferFrom. Метод но должен создавать но событие
Approval.
6. но Метод
function но allowance(address _owner, но address _spender) но constant returns но (uint256
remaining)
Возвращает но сколько монет со но своего счета но разрешил снимать но пользователь
_owner но пользователю _spender.
7. но Событие
event но Transfer(address indexed но _from, address но indexed _to, но uint256 _value)
Событие, но которое должно но возникать при но любом перемещении но монет. Т.е.
его но нужно создавать но внутри функций но transfer и но transferFrom в но случае
успешного но перемещения монет.
8. но Событие
event но Approval(address indexed но _owner, address но indexed _spender, но uint256
_value)
Событие но должно возникать при но получении разрешения на но снятие монет.
но Фактически должно но создаваться внутри но функции approve.
9. но Поле
string но public constant но name;
Хранит но полное название но токена
10. но Поле
Хранит но короткое название но токена. Иначе но говоря — но символ. С но этим
символом но токен будет но отображаться на но биржах и в но кошельках.
11. но Поле
uint8 но public constant но decimals = 18;
Количество но знаков после но запятой. 18 это но наиболее распространенное
но значение.
65
Структура но смарт-контракта
Контракт но токена ERC20 но обычно имеет но структуру наследования, но т.е.
использует но устоявшиеся шаблоны но проектирования. Такие но шаблоны
построены на но основе успешного но опыта решения но аналогичных задач и
но соответствуют принятым но стандартам.
В но разделе 3.2. но рассматривался стандарт но ERC20. А в но нижеописанной
структуре но используется также но ERC179. Его но использование объясняется
но тем, что не но всем нужна но часть, которая но отвечает за но предоставление
разрешений на но снятие средств. но Поэтому все но функции, не но относящиеся к
но механизму предоставления но разрешений, вынесли в но ERC179. Поэтому
но стандарт ERC20 но этот тот же но ERC179 только с но дополнительными
функциями и но событиями.
Контракты но StandartToken и но BasicToken — это но частичные реализации
но стандартов. Поскольку но создаваемый токен но полностью соответствует
но ERC20, то он но будет наследоваться от но контракта StandartToken.
Помимо но задач ERC20, в но создаваемом токене но есть еще но функция,
отвечающая за но эмиссию новых но монет. Это но тоже широко но используемый
шаблон. но Контракты, которые но могут выпускать но новые монеты, но обычно,
называют но Mintable. А но поскольку выпускать но новые монеты но может только
но владелец контракта, то но Mintable наследуется от но Ownable – но контракта
который но предоставляет возможность но ограничивать доступ к но функциям
всем но кроме владельца но контракта.
В но создаваемом контракте но необходимо предусмотреть
но арифметические проверки на но отрицательный баланс, на но переполнение,
деления на но ноль и так но далее. Все эти но проверки в но случае неудачи но прерывают
выполнение но функции. Они но используются очень но часто, поэтому но принято их
но выделять в но отдельную библиотеку но безопасных математических но операций
но SafeMath. Необходимо но заметить, что от но библиотек не но наследуются. Их
66
«используют», но т.е. подключают к но контракту. Например для но SafeMath это
но выглядит так: но using SafeMath for но uint256;
С но учетом всего но вышесказанного структура но контрактов токена
но выглядит так
Рисунок но 13 Иерархическая но структура наследования но контрактов
1. ERC20Basic но — интерфейс но ERC179, т.е. но ERC20 без но механизма
предоставления но разрешений
2. ERC20 но — интерфейс но ERC20
3. BasicToken но — абстрактная но реализация ERC179
4. StandartToken но — абстрактная но реализация ERC20
67
5. Ownable но — предоставляет но возможность ограничивать но доступ к
но функциям всем но кроме владельца но контракта
6. SafeMath но — библиотека но безопасных математических но операций. В
но случае проблем с но выполнением операции но работа функции но прерывается
7. MintableToken но предоставляет но возможность выпуска но новых монет.
но Если выпуск но новых монет но больше не но нужен, то но вызывается
finishMinting (в ICO но вызывается как но правило после но окончания
распродажи но монет). Возобновить но выпуск монет но больше будет но нельзя.
3.5.2. но Смарт-контракт первичного но предложения токена
Жизненный но цикл ICO, но рассмотренного в но разделе 3.3, но обычно состоит
из но следующих стадий:
1. Pre-sale но — момент, но когда разработчики но пробуют продать но токены
узкому но кругу людей. но Нужно чтобы но оценить интерес и но проверить
готовность к но основной продаже. Эта но стадия может но отсутствовать.
2. Непосредственная но открытая продажа но токенов. Назначается но дата, когда
но будет старт но продаж и но начинается продажа. По но наступлению какого-
либо но условия распродажа но токенов заканчивается. но Например по
но достижению необходимой но суммы или но наступлению даты но окончания
продажи.
3. Выпуск но токенов на но биржи.
Цель но работы – но продемонстрировать техническую но сторону процесса
но создания токенов, но поэтому сосредоточимся на но второй части. но Технически
процесс но прост. Инвестор но отправляет эфир на но контракт, отвечающий за
но распродажу. А но контракт распродажи но отдает команду но выпустить токены и
но зачислить их на но баланс покупателя.
68
Итак, но ICO состоит из но двух контрактов:
1. Контракт но распродажи. Назовем его но Crowdsale.
2. Контракт но токена.
В но предыдущем разделе был но реализован токен но стандарта ERC20. И он
был но создан с но применением шаблона но MintableToken. Т.е. он уже но содержит
функцию, но которая выпускает но новые токены на но адрес владельца. но Осталось
только но написать контракт но распродажи.
Итак, но в контракте но распродажи Сrowdsale но будут следующие
но переменные:
1. start но — дата но начала распродажи но токенов в но UNIX формате
2. token но — контракт но токена
3. owner но — адрес но владельца контракта но распродажи. На но этот адрес
но будут отправляться но вырученные деньги.
4. period но — сколько но дней будет но длиться распродажа
Когда но покупатель пришлет но деньги, контракт но проверит, что но текущая
дата но больше чем но дата начала но распродажи и но меньше чем но дата конца
но распродажи. Если но так, то но эфир, который но прислал пользователь, но контракт
переведет на но счет владельца но контракта. А но затем выполнит но выпуск токенов
на но счет пользователя но посредством вызова но mint.
Осталось но выяснить, как но контракт узнает, что но пользователь хочет
но купить токены? но Когда на но контракт пересылается но эфир, то у но контракта
вызывается но специальная функция — но fallback function.
function() но external payable {
....
}
Модификатор но payable ставится в тех но функциях, которые но принимают
эфир. А но сколько именно но пользователь прислал но эфира, хранится в
но msg.value.
Теперь но можно привести код но контракта распродажи:
69
contract но Crowdsale {
но address owner;
но SimpleTokenCoin public но token = new но SimpleTokenCoin();
но uint start = но 1500379200;
но uint period = 28;
но function Crowdsale() {
но owner = но msg.sender;
но }
но function() external но payable {
но require(now > но start && now но < start + но period*24*60*60);
но owner.transfer(msg.value);
но token.mint(msg.sender, msg.value);
но }
}
Функция но owner.transfer пересылает но эфир на но счет owner’а. но Контракт
токена но указан со но словом public. Это но необходимо для но того чтобы но можно
было но узнать адрес но контракта токена в но remix после но создания crowdsale. но Зная
адрес но контракта можно но вызывать его но функции и но тестировать.
3.5.3. но Загрузка в но блокчейн и но проверка выполнения
Загрузка но смарт-контракта в но блокчейн
Для но загрузки контракта в но блокчейн выполним но следующие действия:
1. Откроем но в левой но панели среды но разработки Remix но файл с но кодом нашего
но контракта.
2. Переключимся но на вкладку «compile» в но панели справа.
3. Выполним но «start compile». но Таким образом, но текст контракт на но языке
Solidity но будет скомпилирован в но байт-код EVM.
4. Переключимся но на вкладку «run».
70
5. В но поле «Environment» но выберем «JavaScript VM» — это но тестовая среда,
в но которой мы но будем исполнять но наши контракты.
6. Выберем но в списке но контрактов тот, но который будем но загружать –
но Crowdsale.
7. Нажмем но на кнопку «create» — но таким образом, мы но загрузили контракт в
но блокчейн Ethereum.
После но этих процедур но панели среды но разработки Remix но будут
выглядеть но так: (Рисунок 1 в но Приложении 2)
В но консоли выполнения но (нижняя панель) но появилось сообщение VME
об но успешном создании но контракта. В но правой панели но появилась панель
но управления контрактом с но кнопками «(fallbackно и «token». но Теперь наш
но контракт готов к но выполнению.
Обратим но внимание, что но среда Remix но предоставляет для но тестирования
несколько Etherium-аккаунтов, но с балансом на но каждом по 100 но ETH. Они
но перечислены в но поле Account. но (Рисунок 2 в но Приложении 2)
Мы но загрузили наш но контракт в но блокчейн с но адреса
0xca35b7d915458ef540ade6068dfe2f44e8fa733c, но именно этот но адрес будет
но являться владельцем но контракта распродажи но токенов Crowdsale, и но только с
но него будет но доступно выполнение но служебных функций но контракта, в
но отличие от но общедоступных пользовательских.
После но загрузки контракта в но блокчейн с но адреса
0xca35b7d915458ef540ade6068dfe2f44e8fa733c, его но эфирный баланс
но уменьшился – но списалось некоторое но количество эфира за но процедуру
загрузки. но (Рисунок 3 в но Приложении 2)
Эта но информация нам но понадобится далее, для но проверки работы
но контракта.
Проверка но работы контракта
Функции но отправить в но Remix в но явном виде но нет. Зато но перед вызовом
но функции всегда но можно указать но количество эфира. но Поэтому мы но будем
71
указывать но эфир и но явно вызывать но Fallback функцию. но Итак, попробуем
но купить токены.
Выберем но в поле но Account другой но адрес, отличный от но адреса владельца
но контракта, например но 0x14723a09acff6d2a60dcdf7aa4aff308fddc160c. И
но теперь попробуем но купить с но этого адреса но наши токены. но Укажем в но поле
Value — 15 ETH но (т.е. тратим 15 но единиц эфира, но взамен должны но получить 15
но созданных токенов). А но затем вызовем но функцию Fallback. но (Рисунок 4 в
но Приложении 2)
В но консоли управления но появилось сообщение EVM об но успешном
выполнении но операции. Эфирный но баланс указанного но счета уменьшился на
но величину потраченных но средств (плюс но небольшую комиссию за но вызов
контракта).
Теперь но купим еще но токенов на 25 но единиц эфира с но другого адреса
но 0x4b0897b0513fdc7c541b6d9d7e929c4e5364d2db, чтобы но далее проверить
но операцию отправки но токенов с но одного адреса на но другой. (Рисунок 5 в
но Приложении 2)
Проверим но балансы эфира но вышеуказанных аккаунтов: но (Рисунок 6 в
но Приложении 2)
Видно, но что заявленное но количество эфира но списалось с но адресов
покупателей и но зачислилось на но адрес владельца но контракта распродажи.
Теперь но проверим балансы но приобретенных токенов на но счетах
покупателей. но Чтобы это но сделать, нужно но вызвать balanceOf у но контракта
токена. Мы но сделали поле но адреса токена в но контракте распродажи но Crowdsale
публичным. но Поэтому можем но посмотреть адрес но токена, нажав на но кнопку
«token» в но панели управления но контрактом. Получили но адрес контракта
но токена - но 0x755014da263fc47d238078bb47d217f743e5b6a5. Затем но выберем из
но списка контрактов но контракт нашего но токена SimpleTokenCoin. но Вставим
полученный но адрес контракта в но поле рядом с но кнопкой «At address» и

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)
Value-based education: ценности в системе образования и способы их реализации на уроке английского языка. Опыт Европейских стран