Разработка децентрализованного рынка цифровых предметов

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет информатики, математики и компьютерных наук

Программа подготовки бакалавров по направлению

09.03.04 Программная инженерия

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Разработка децентрализованного рынка цифровых предметов

Обрезков Вячеслав Андреевич

Научный руководитель:

Старший преподаватель

Бычков Илья Сергеевич

Нижний Новгород, 2020



СОДЕРЖАНИЕ

ВВЕДЕНИЕ

ГЛАВА 1. ТЕОРЕТИЧЕСКАЯ ЧАСТь

1.1 Цель и задача работы

1.2 Обзор технологии блокчейн

1.3 Платформа Ethereum

1.4 Обзор языка Solidity и смарт-контрактов

1.5 Обзор библиотеки React и Web3

1.6 Выбор IDE для разработки

1.7 Обзор существующих решений

1.8 Определение требований к приложению

ГЛАВА 2. ПРАКТИЧЕСКАЯ ЧАСТЬ

2.1 Пользовательские сценарии использования

2.2 Архитектура децентрализованного приложений

2.2.1 Использование библиотеки OpenZeppelin

2.2.2 Решение проблемы обновления контракта

2.2.3 Решение проблемы размера контракта

2.2.4 Управление массивами

2.2.5 Использование Truffle и Ganache

2.3 Архитектура веб-приложения

2.4Тестирование децентрализованного приложения

2.5 Стратегия дальнейшего развития

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЕ 1

ПРИЛОЖЕНИЕ 2



ВВЕДЕНИЕ

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

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

В наше время рынок цифровых продуктов стремительно растет. Сравнивая процесс от создания товаров и услуг до их распространения, физические товары сильно проигрывают их цифровым конкурентам. Изучая главные преимущества цифровых товаров, стоит отметить следующие:

Данный тип товаров достигает высокой рентабельности благодаря своей зачастую низкой себестоимости и возможности неограниченного тиража;

Всегда поддерживают моментальное распространение;

Возможность дёшево и быстро автоматизировать процесс продажи и поставки.

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

За любые финансовые операции платформа берёт комиссию, что влияет на обе стороны. Это вынуждает либо повышать цены на товар, либо получать только часть прибыли с продаж;

Данные о покупках хранятся на серверах у торговых платформ и зачастую они скудны в типах взаимодействия с товарами и такие операции как обмен, подарок или перепродажа недоступны. Это ограничивает как продавцов при интеграции подобных сервисов в свои магазины и программные продукты, так и покупателей

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

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



ГЛАВА 1. Теоретическая часть

1.1 Цель и задача работы

Целью данной работы является разработка децентрализованной торговой платформы для покупки, продажи и обмена цифровыми предметами.

Объект исследования - децентрализованные решения в электронной коммерции.

Предмет исследования - разработка смарт контракта на базе платформы Ethereum для проведения финансовых операций с цифровыми предметами.

Для достижения поставленной цели необходимо выполнить следующие задачи:

Изучить рынок цифровых предметов и рассмотреть существующие решения в исследуемой области;

Исследовать технологию блокчейн (blockchain) и платформу Ethereum;

Установить требования к разрабатываемой платформе;

Разработать смарт контракт для хранения цифровых предметов и взаимодействия с ними;

Разработать прототип веб-приложения для взаимодействия со смарт контрактом.

Разрабатываемая платформа нацелена как на продавцов, так и на покупателей. Для продавцов будет возможность создавать свои товары и продавать их. А покупатели смогут приобретать любые товары и, в зависимости от настроек, заданных создателями контента, обмениваться и перепродавать их.



1.2 Обзор технологии блокчейн

История блокчейна началась в 1991 году, когда Стюарт Хабер и В. Скотт Сторнетта представили свою первую работу, которая была связана с разработкой криптографически защищенной цепочкой блоков, в которой никто не мог подделать временные метки документов [1].

В 2008 году технология блокчейн начинает приобретать популярность, благодаря работе одного человека или группы людей по имени Сатоши Накамото. Именно он считается разработчиком криптовалюты Bitcoin. На сегодняшний данную технологию блокчейн широко обсуждают не только в мире финансов. Ее уже пробуют использовать для хранения и обработки персональных данных и идентификации, в маркетинге и компьютерных играх [5].

Блокчейн -- это распределенный защищенный пиринговый реестр [2], представляющий из себя последовательную цепочку блоков - структура данных, состоящая из списка заголовков и транзакций. Заголовки являются местом для хранения такой информации, как временная метка его создания, публичный адрес вычислительной машины создавшего его, ссылка в виде криптографического хэша на предыдущий. Транзакции - структура, содержащая в себе данные для изменения состояния блокчейна. По сути своей они представляют из себя дельту состояния данных.

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

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

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

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

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



1.3 Платформа Ethereum

Ethereum - глобальная платформа с открытым исходным кодом для написания и использования децентрализованных приложений, также называемых смарт-контрактами. Данная система предоставляет свою уникальную валюту - крипто-токен под названием Ethereum. Однако самое важно, что она предлагает - возможность запустить приложение на своей платформе. Так как платформа основана на технологии блокчейн, приложение будет запускаться не на каких-то конкретных серверах, а у всех майнеров. При запуске приложения в данной системе оно получается полностью децентрализованным и самоконтролируемым, не требующим от себя дальнейшей поддержки.

Благодаря использованию технологии блокчейн, в виде виртуальной машины по запуску приложений, получается полностью отказаться от централизованных серверов [3]. Также благодаря прозрачности и публичности системы, повышается доверие к смарт-контрактам со стороны пользователей, ведь исполняемый код неизменен и его можно посмотреть в любой момент.

Помимо перечисленных достоинств, также имеется особенность, из-за которой применение данной технологии ограничено. Заключается она в том, что при вызове какой-либо функции на платформе Ethereum, необходимо оформить транзакцию с подробным описанием действий [6]. Так как за транзакции пользователь обязан оплачивать фиксированную комиссию, то использование децентрализованных приложений становиться платным.

1.4 Обзор языка Solidity и смарт-контрактов

При написании смарт-контрактов используется разработанный специально для этих целей язык Solidity - объектно ориентированный язык, разработанный для трансляции в байт-код виртуальной машиной Ethereum [7]. Однако вместо обычных классов (class) в данном языке объявляются контракты (contract). Язык получил поддержку статической типизации для переменных и динамическую для возвращаемых объектов. Существует возможность множественного ромбовидного наследования, благодаря чему контракты можно составлять из различных переиспользуемых блоков, так как при подобном наследовании все внутренние переменные и функции становятся доступны для конструируемого класса.

Также в языке Solidity имеется особый тип функций, называемый модификаторами. Они позволяют устраивать логические проверки на различные передаваемые данные, чтобы в случае чего отменить выполняемую функцию. Такие модификаторы используются при объявлении функций.

Также существует особенность благодаря которой имеется возможность идентифицировать, кто вызывает функцию контракта, а также передавать и принимать криптовалюту. Это возможно благодаря тому, что в любой функции, помимо объявленных аргументов, имеется один скрытый, формирующийся благодаря данным транзакции - аргумент msg. Благодаря этому параметру можно получить публичный адрес пользователя, а также управлять криптовалютой, которая была прикреплена к транзакции [8]. Таким образом открывается доступ к возможности составлять приложения для финансовых секторов без использования реальных валют.

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

Язык Solidity удовлетворяет всем требованиям при разработке децентрализованных приложений. Однако также имеет существенный минус - ограниченный функционал. На момент написания работы в данном языке отсутствует возможность использования чисел с плавающей точкой, и нет функционала по управлению списками элементов: удаление и добавление по индексу.

Помимо этого, при исследовании данной технологии и языка были выявлены следующие особенности, которые следует учитывать при разработке:

Код контракта, находящегося в блокчейне, неизменен, а значит обновить его не представляется возможным;

Информация внешнего мира внутри контракта недоступна, невозможно произвести HTTP запрос. Для получение таких данных, как курс реальных валют, необходимо вмешательство третьей доверенной стороны;

В одном из обновления системы было установлено ограничение на размер кода смарт-контракта в 24 килобайт. Это следует учитывать при разработке архитектуры приложения;

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

1.5 Обзор библиотеки React и Web3

React - это библиотека для создания пользовательского интерфейса. Она предназначена для реализации уровня представления. Выходным продуктом является HTML разметка страницы.

Смарт-контракт является серверной частью разрабатываемой торговой платформы, хранящий в себе базу данных и реализующий возможности по ее управление. Соответственно, для разработки прототипа веб-приложения была выбрана библиотека React, которая позволяет быстро наладить общение с блокчейном и реализовать быстрый и отзывчивый интерфейс для вызова функций децентрализованного приложений [9]. Благодаря некоторым концепциям, которая данная библиотека привнесла с собой, ускоряется процесс разработки и улучшается качество кода.

Одной из концепций является JSX - расширение языка JavaScript, раскрывающее главный принцип библиотеки - логика рендеринга неразрывно связана с логикой пользовательского интерфейса (UI). Вместо того чтобы помещать HTML разметку и ее логику по разным файлам, данная технология позволяет их объединить. Появляется возможность писать HTML код прямо внутри JavaScript функций.

Выбранная библиотека представляет еще одну концепцию - компоненты, являющиеся изолированными частями интерфейса. Данная особенность позволяет разделить весь UI на переиспользуемые не взаимосвязанные блоки. Во многом, компоненты - обычные JavaScript классы, принимающие произвольные входные данные, имеющие внутреннее состояние и возвращающие React элементы, описывающие UI. Входные данные можно сравнить с атрибутами HTML-элементов, а выходные с разметкой. Компоненты можно использовать внутри других компонентов, тем самым составляя итоговый внешний вид веб-сайта.

Отдельного внимания заслуживает система Context API - встроенный в React модуль, позволяющий передавать данные по всему приложению, не используя HTML атрибуты. Она хорошо себя показывает, когда необходимо передать данные из одного компонента в другой, если их разделяют большое число потомков. Технология Context API позволяет отказаться от использования библиотеки Redux при разработке небольших проектов.

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



1.6 Выбор IDE для разработки

В ходе работы были исследованы некоторые IDE для принятия решения дальнейшего его использования. Локальных сред для разработки, предназначенных исключительно для проектирования смарт-контрактов, не было обнаружено. Однако существуют те, которые после установки дополнительных плагинов позволяют комфортно разрабатывать децентрализованные приложения. Также имеется вид браузерных IDE не требующие от пользователей дополнительного вмешательства, предоставляя готовое решение под ключ.

Изначально был сделан выбор в пользу браузерного варианта. В ходе исследования были выбраны Remix и Ethereum Studio. Проведено изучение таких составляющих как возможность переключение аккаунтов во время разработки, UNIT тестирования контрактов, а также базовые возможности компиляции и развертывании приложения в тестовой среде.

При исследовании Ethereum Studio были выявлены множество ошибок связанные с переключением аккаунтов, из-за чего было невозможно проводить ручное тестирование. В ходе первого знакомства с IDE Remix она показала себя с наилучшей стороны. Были разработаны пробные смарт-контракты. Однако при написании тестовых модулей были обнаружены критические ошибки, из-за которых дальнейшая разработка в данном браузерном решении была невозможна.

По итогу было выбрано решение, состоявшее из Visual Studio Code, плагина для подсветки синтаксиса и автоматического исправления кода. Помимо прочего потребовалось применение системы Ganache для запуска тестового блокчейна платформы Ethereum, а также библиотека Truffle предоставляющее возможности тонкой настройки тестирования смарт-контрактов и запуска приложения в тестовой сети.

Также для Visual Studio Code были установлены дополнительные плагины и библиотеки для разработки веб-приложения. Что позволило исключить использование нескольких IDE при разработке двух взаимосвязанных частей, как это было бы, если бы выбор был произведен в пользу браузерных решений.

1.7 Обзор существующих решений

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

В ходе изучения рынка было найдено два подобных решения и оба основаны на смарт-контрактах платформы Ethereum. Первое называется OpenSea, которое позволяет продать и приобрести любой предмет. Функционал ограничен тем, что предметы можно продать по фиксированной цене или предложить свою. Также есть возможность некоторой кастомизации профиля продавца в виде задании имени и использовании аватара с использованием смарт-контракта ethmoji. Главным минусом данной платформы является то, что для того, чтобы продать свой товар, его необходимо вначале создать в виде другого смарт-контракта, основанного на шаблоне из библиотеки OpenZeppelin под названием ERC721. Эта особенность очень сильно повышает порог входа, что ограничивает целевую аудиторию. Данная компания разработала свою криптовалюта на основе шаблона ERC20, что также можно отнести к минусам платформы. Основной причиной является необходимость конвертации из одной криптовалюты в другую, из-за чего ухудшается удобство использования торговой площадки.

Также было обнаружено решение под названием Game Credits. Основной аудиторией данный магазин для себя выбрал игровую индустрию. Благодаря этому они сконцентрировались на функционале, позволяющем максимально полно раскрыть данную торговую платформу в игровых мирах. Были разработаны поощрительные системы и функционал для организации соревнований. Также данная система повторяет функциональность платформы OpenSea, которая связана с шаблонами ERC721 и ERC20.

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

1.8 Определение требований к приложению

На основании проведенного исследования, для разрабатываемой торговой платформы были сформулированы следующие требования:

Для торговой платформы необходимо сохранить простоту в использовании, а значит исключить необходимость в разработке своих смарт-контрактов;

Разработать решение для реализации возможности обновления смарт-контракта;

Избежать превышения ограничения на объем кода децентрализованного приложения;

Использовать криптовалюту платформы Ethereum для организации финансовых операций;

Разработать прототип веб-интерфейса для возможности управления всем функционалом децентрализованного приложения;

Исключить манипулирование магазинами ценами на товар, тем самым предотвратив некоторые финансовые махинации;

Предоставить доступ к купленным продуктам только пользователям, исключив при этом вмешательство третьих лиц.



ГЛАВА 2. Практическая часть

2.1 Пользовательские сценарии использования

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

Посмотреть список всех магазинов;

Посмотреть список всех типов товаров и их характеристики;

Посмотреть список всех товаров, узнать их владельцев и другие внутренние данные;

Стать продавцом создав магазин или стать покупателем начиная приобретать товары.

Продавцы в разрабатываемой системе могут совершать следующие шаги:

Создание магазина и его администрирование;

Создание типов предметов для дальнейшей генерации предметов;

Реализация предметов различными способами:

Продажа по фиксированной цене;

Сдача предметов в аренду;

Создание предметов с заданным владельцем. Работает как система подарков;

Реализация предметов как поодиночке, так и группами;

Остановить и продолжить продажу предметов;

Сменить владельца магазина.

Покупателям доступен следующий функционал:

Покупка/аренда товаров из любого магазина;

Покупка/аренда товаров у других пользователей;

Различные взаимодействия с товаром:

Изменить редактируемое внутреннее состояние;

Начать продавать товар на рынке, если тип товара позволяет это делать;

Начать сдавать товар в аренду на рынке, если тип товара позволяет это делать;

Сменить владельца товара, если тип товара позволяет это делать.

2.2 Архитектура децентрализованного приложений

2.2.1 Использование библиотеки OpenZeppelin

При разработке смарт-контрактов использовалась библиотека с открытым исходным кодом OpenZeppelin. В данном проекте применялась лишь часть функционала, которую она предоставляет. В частности, каждый контракт наследуется от структуры Ownable, код которой представлен на Рисунке 1. Основной ее функционал заключается в определении создателя контракта и возможности смены владельца. Работает это благодаря конструкторам контрактов, которые вызываются только при их создании, и глобально доступной структуры данных msg, в котором имеется значение адреса, посылающего транзакцию. В данном случае в транзакции содержится развертываемое приложение. Буквально каждый разрабатываемый мной контракт наследуется от Ownable.

Рис. 1. Пример смарт-контракта Ownable

При разработке появилась острая необходимость в использовании функционала контракта ERC165. Он представляет из себя регистратор интерфейсов. При наследовании существующих контрактов от ERC165, появляется возможность, используя адрес контракта в блокчейне, проверить наличие реализованных интерфейсов у него. В дальнейшем в зависимости от ответа происходит либо вызов проверяемого функционала, либо отмена транзакцию с возвратом оставшейся суммы комиссии. В итоге любой контракт в разрабатываемой платформе имеет структуру, указанную на Рисунке 2.

Рис. 2. Стандартные зависимости всех контрактов

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

2.2.2 Решение проблемы обновления контракта

Как говорилось ранее, язык разработки и сами контракты поддерживают наследование. Также в платформе Ethereum присутствует возможность вызова одного контракта из функции другого, зная его адрес расположения и интерфейс, к которому будет идти вызов. В итоге сформировалась следующее решение, изображенное на диаграмме, которая представлена на Рисунке 3.

Рис. 3. Архитектурное решение проблемы обновления

В данном решении используется следующая тонкость: при вызове одного контракта из другого, значение msg.sender (адрес отправителя транзакции) меняется на адрес расположения контракта в блокчейне. Учитывая это был разработан ContractSubscriber отвечающий за то, каким контрактам разрешено вызывать функции, а каким нет. При его использовании и разделении всех контрактов на две части, в которых один будет зарезервирован под данные (DataContract), а другой под функциональность (FunctionsContract), получиться добиться частичной возможности по обновлению контрактов. Однако стоит заметить, что обновлять получиться только контракт содержащий функциональность при условии, что в нем не будет внутреннего состояния.

2.2.3 Решение проблемы размера контракта

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

Рис. 4. Архитектурное решение масштабируемости и достижения критического размера контрактов

Такое архитектурное решение, изображенное на Рисунке 4, позволяет улучшить процесс обновления, проводить разработку каждого модуля независимо друг от друга и избежать ситуации с достижением критического размера одного контракта. Дополнительно появляется возможность масштабирования приложения.

2.2.4 Управление массивами

В ходе разработки модуля по реализации продукции, появилась острая необходимость удаления элементов из массива. Если рассматривать более конкретно, то данный функционал требуется для удаления продукции из списка продаваемых позиций. Если использовать возможности только встроенного в язык массива, то сложность удаления элемента по индексу будет равняться O(n), что для разработки смарт-контрактов неприемлемо по той причине, что с ростом числа n, также будет расти и величина комиссии за транзакцию [4]. Был сделан вывод, что необходимо разработать свое решение, где удаление бы совершалось со сложностью O(1).

По итогу была создана библиотека со следующей структурой данных:

Рис. 5. Структура данных разработанного двунаправленного списка

List.rootId - индекс первого элемента. Отсчет начинается с единицы, поэтому если значение равно нулю, то список пуст;

List.lastId - индекс последнего элемента. Отсчет начинается с единицы.

List.freeIndexes - словарь свободных ячеек в словаре wrappers. Данное поле необходимо для избегания образовании дыр в словаре wrappers. Применяется как массив чисел с функцией чтения последнего элемента и добавления в конец. Используется именно словарь ввиду ограничений языка разработки Solidity;

List.wrappers - словарь, содержащий все элементы, сохраненные в списке. Данный словарь не гарантирует, что все элементы сохранены в том порядке, в котором они были добавлены;

List.freeIndexesLength - количество чисел, сохраненных в словарь freeIndexes;

List.nextWrapperId - максимальный порядковый номер свободный в словаре wrappers. Данное поле используется только в случае, если List.freeIndexesLength тождественно равен нулю;

List.length - количество элементов в списке;

ItemWrapper.data - элемент, добавленный в список;

ItemWrapper.nearbyWrappers - словарь из двух элементов содержащий информацию о предыдущей и следующей обертках, содержащих другие элементы, добавленные в список.

Удаление по индексу со сложностью O(1) происходит благодаря передаваемому внутреннему индексу, который ссылается на местоположение данных в словаре wrappers. Данный индекс можно получит до удаления с помощью View функций, которые являются бесплатными и не требуют оплаты комиссий. Следующим шагом будет применение полученных данных для удаления элемента.

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

2.2.5 Использование Truffle и Ganache

В ходе разработки применялись модуль Truffle и приложение Ganache для упрощения разработки смарт-контрактов. Truffle представляет из себя платформу для тестирования и развертывания (миграции). Он умеет много больше, но в ходе разработки применялся только перечисленный функционал.

Ganache - приложение, позволяющее запустить свой собственный блокчейн Ethereum для безопасного тестирования разрабатываемого приложения. Оно позволяет просматривать все проведенные транзакции, события пришедшие из смарт-контрактов, а также управлять аккаунтами для дальнейшего их использования во время тестов.

2.3 Архитектура веб-приложения

При разработке веб-приложения использовались библиотека React, Context API и библиотека Web3.

Для полноценной работы разрабатываемого сайта имеется необходимость в установке браузерного плагина для подключения к блокчейну. В ходе разработки и тестирования применялся плагин MetaMask. Он позволяет получать данные из блокчейна, а также отправлять и подписывать транзакции на перевод криптовалюты или вызов функций. Во время разработки он был настроен таким образом, чтобы все запросы отправлялись на локально запущенный блокчейн в приложении Ganache. Дополнительно были добавлены тестовые аккаунты для возможности взаимодействовать с контрактами от их имени.

Данные плагина MetaMask и его функциональность применялась библиотекой Web3. С помощью нее были настроены подключения к разработанным смарт-контрактам и было организовано формирование транзакций для выполнения функций приложения. Благодаря Web3 были настроены подписки на события, для реагирования на изменение состояния контрактов в блокчейне, что позволило организовать динамический интерфейс.

В разрабатываемом веб-приложении имелась необходимость почти в каждой ее части использовать функционал смарт-контрактов. Для решения этого вопроса была разработана сеть взаимосвязанных Context компонентов. Благодаря их особенностям получилось добиться распространения функциональности всех смарт-контрактов без дублирования кода.



Рис. 6. Зависимости модулей, используемых Context

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

Рис. 7. Интерфейс, демонстрирующий список типов предметов

Рис. 8. Интерфейс, демонстрирующий создание типа предмета

Рис. 9. Интерфейс, демонстрирующий создание магазина



2.4 Тестирование децентрализованного приложения

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

Изначально с учетом всех требований применялась методология Test Driven Development. Однако из-за неправильного выбора IDE, в определенный момент пришлось мигрировать из Remix в Visual Studio Code. Дальнейшее тестирование проходило с применением методологии Test Last Development. Однако качество тестирования не изменилось.

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

В итоге было достигнуто полное покрытие тестами функционала смарт-контрактов, отвечающих за хранение данных и 75% покрытие других. Все написанные тесты проходят успешно.

2.5 Стратегия дальнейшего развития

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

Помимо предложенной, можно также развивать и другие возможности системы. Рассмотрению подлежит разработка функционала, нацеленного на конкретно выбранную аудиторию. В качестве примера можно привести создание модуля для проведения турниров с призовыми отчислениями.

Другим аспектом разрабатываемой торговой платформы является ее веб-сайт, который требует улучшения. Также есть планы по развитию Rest API для взаимодействия с блокчейн посредством HTTP запросов. Благодаря этому появиться возможность для внедрения разработанного решения в любые программы или веб-страницы без необходимости разбирается в используемых технологиях.



ЗАКЛЮЧЕНИЕ

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

Результатом практической части стало создание полностью работоспособной, стабильной и масштабируемой системы смарт-контрактов для проведения финансовых операций с цифровыми предметами. Помимо этого, был разработан прототип веб-интерфейса для демонстрации возможностей системы. Ознакомиться с кодом торговой платформы можно на веб-сервисе Github [11][12].

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

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



СПИСОК ЛИТЕРАТУРЫ

Andreas M. Antonopoulos, “Mastering Bitcoin”, 21 July 2017

Ritesh Modi, “Solidity Programming Essentials”, 19 April 2018

Vikram Dhillon, David Metcalf, Max Hooper, “Blockchain Enabled Applications”, 2017

Sitepoint Team, “Learn Ethereum: The Collection”, July 2018

Swati Goyal, “The History of Blockchain Technology: Must Know Timeline”, 3 November 2018, [Электронный ресурс], - https://101blockchains.com/history-of-blockchain-timeline/

Mahesh Murthy, “Life Cycle of an Ethereum Transaction”, 26 December 2017, [Электронный ресурс], - https://medium.com/blockchannel/life-cycle-of-an-ethereum-transaction-e5c66bae0f6e

Michele D'Aliessi, “What is Ethereum”, 7 January 2018, [Электронный ресурс], - https://medium.com/@micheledaliessi/what-is-ethereum-f4c5e566ff77

“Using Ethereum for financial smart contracts”, 10 May 2016, [Электронный ресурс], - https://medium.com/@vishakh/using-ethereum-for-financial-smart-contracts-76d41900246d

Justin Davies, “Misadventures in React with Ethereum” 14 April 2018, [Электронный ресурс], - https://medium.com/coinmonks/misadventures-in-react-with-ethereum-7ab3d4ee1af6

React JS Team, “React JS Documentation”, [Электронный ресурс], - https://reactjs.org/docs

Репозиторий с открытым исходным кодом, [Электронный ресурс], - https://github.com/LordOfTheBees/MarketPool

Репозиторий с открытым исходным кодом, [Электронный ресурс], - https://github.com/LordOfTheBees/MarketPoolWeb



ПРИЛОЖЕНИЕ 1

Выдержка контракта MarketPool

pragma solidity >=0.6.0;

contract MarketPool {

event MarketCreated(uint256 indexed marketId, address indexed owner);

event MarketOwnershipTransferred(uint256 indexed marketId, address indexed previousOwner, address indexed newOwner);

Market[] public markets;

mapping (uint256 => address) public marketToOwner;

mapping (address => Counters.Counter) public addressToMarketCount;

function createMarket(string memory name) public returns (uint256) {

markets.push(Market(name));

uint256 id = markets.length.sub(1);

marketToOwner[id] = msg.sender;

addressToMarketCount[msg.sender].increment();

emit MarketCreated(id, msg.sender);

return id;

}

function getMarketData(uint256 marketId) public view onlyMarketExists(marketId) returns (string memory name) {

Market storage marketData = markets[marketId];

return (marketData.name);

}

function transferMarketOwnership(uint256 marketId, address newOwner) public onlyMarketOwner(marketId) notZeroAddress(newOwner) {

emit MarketOwnershipTransferred(marketId, marketToOwner[marketId], newOwner);

marketToOwner[marketId] = newOwner;

addressToMarketCount[msg.sender].decrement();

addressToMarketCount[newOwner].increment();

}

function isMarketOwner(uint256 marketId) public view onlyMarketExists(marketId) returns (bool) {

return marketToOwner[marketId] == msg.sender;

}

function marketExist(uint256 marketId) public view returns (bool) {

return markets.length > marketId;

}

modifier notZeroAddress(address checkAddress) {

require(checkAddress != address(0), "CheckAddress is the zero address");

_;

}

modifier onlyMarketExists(uint256 marketId) {

require(marketExist(marketId), "MarketPool: Market does not exist");

_;

}

modifier onlyMarketOwner(uint256 marketId) {

require(marketExist(marketId), "Market does not exist");

require(marketToOwner[marketId] == msg.sender, "Caller is not the owner");

_;

}

}



ПРИЛОЖЕНИЕ 2

Выдержка контракта MarketPool_Items

pragma solidity >=0.6.0;

contract MarketPool_Items is MarketPool {

event ItemTypeCreated(uint256 indexed marketId, uint256 indexed itemTypeId);

event ItemCreated(uint256 indexed marketId, uint256 indexed itemTypeId, uint256 indexed itemId);

event ItemOwnershipTransferred(uint256 indexed marketId, uint256 itemId, address indexed previousOwner, address indexed newOwner);

mapping(uint256 => Items.ItemType[]) public marketToItemTypes;

mapping(uint256 => Items.Item[]) public marketToItems;

mapping(uint256 => mapping(address => Counters.Counter)) public marketToUsersToItemsCount;

mapping(uint256 => mapping(uint256 => address)) public marketToItemToOwner;

function createItemType(

uint256 marketId,

string calldata name,

uint256 totalSupply,

bool allowSale,

bool allowAuction,

bool allowRent

) external onlyMarketOwner(marketId) returns (uint256) {

marketToItemTypes[marketId].push(

Items.ItemType(name, totalSupply, totalSupply, totalSupply > 0, allowSale, allowAuction, allowRent)

);

uint256 itemTypeId = marketToItemTypes[marketId].length.sub(1);

emit ItemTypeCreated(marketId, itemTypeId);

return itemTypeId;

}

function _transferItemOwnership(

uint256 marketId,

uint256 itemId,

address from,

address to

) internal notZeroAddress(to) {

require(from != to, "MarketPool_Items: 'from' address equal 'to' address");

require(itemExist(marketId, itemId), "MarketPool_Items: Item does not exist");

require(marketToItemToOwner[marketId][itemId] == from, "MarketPool_Items: It is not owner");

marketToUsersToItemsCount[marketId][from].decrement();

marketToUsersToItemsCount[marketId][to].increment();

marketToItemToOwner[marketId][itemId] = to;

emit ItemOwnershipTransferred(marketId, itemId, from, to);

}

function _createItem(uint256 marketId, uint256 typeId, address newItemOwner)

internal

returns (uint256)

{

Items.ItemType storage itemType = marketToItemTypes[marketId][typeId];

require(

itemType.creatingPossible(),

"MarketPool_Items: cannot create an item of this type"

);

marketToItems[marketId].push(Items.Item(typeId));

uint256 itemId = marketToItems[marketId].length.sub(1);

marketToUsersToItemsCount[marketId][newItemOwner].increment();

marketToItemToOwner[marketId][itemId] = newItemOwner;

itemType.recordItemCreated();

emit ItemCreated(marketId, typeId, itemId);

return itemId;

}

}

Размещено на Allbest.ru