ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 23.11.2023
Просмотров: 67
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
2.2 Содержательная постановка задачи
2.3 Математическая постановка задачи классификации с пересекающимися классами
2.4 Адаптация выбранного математического аппарата для решения задач ВКР
2.6 Выбор IT-инструментария для разработки программного обеспечения
2.8 Разработанное основное алгоритмическое обеспечение
когда и какой блокчейн создан, с какими параметрами, указаны валидаторы и кандидаты в валидаторы, сколько монет будет зачислено на какие адреса на определенной высоте блока. Нам также нужно добавить «доказательство» в наш блок генезиса, которое является результатом майнинга (или доказательства работы). Помимо создания блока genesis в нашем конструкторе (рисунок 2.18), также уточняем методы для new_block (), new_transaction () и hash ():
Рисунок 2.18 – Методы создания нового блока
Выше мы описали общее представление нашего блокчейна. Далее опишем, как новые блоки создаются, подделываются или добываются. Понимание доказательства работы: 52 Алгоритм Proof of Work (PoW) – это то, как новые блоки создаются или добываются в цепочке блоков. Цель PoW - найти число, которое решает проблему. Это число должно быть трудно найти, но его легко проверить – говоря вычислительным путем - любому, кто находится в сети. Это основная идея Proof of Work. Рассмотрим простой пример. Давайте решим, что хеш некоторого целого числа x, умноженного на другой y, должен заканчиваться на 0. Итак, hash (x * y) = ac23dc...0. И для этого упрощенного примера давайте предположим, что x = 5. Реализация этого в Python (рисунок 2.19)
Рисунок 2.19 – Упрощенный пример алгоритма PoW в Python
Решение здесь: y = 21. Так как полученный хеш заканчивается 0: hash (5 * 21) = 1253e9373e...5e3600155e860 В биткойнах алгоритм Proof of Work называется Hashcash [20] – алгоритм доказательства правильности работы, требующий выборочного объёма данных для вычислений, но при этом доказательство может быть эффективно подтверждено. Данный алгоритм используется в основном с целью уменьшенить количество спама и DoS-атак. Нам же алгоритм Hashcash необходим в первую очередь для создания нового блока. Сложность алгоритма определяется количеством символов, которые ищут в строке. Далее реализуем базовый алгоритм Proof of Work (рисунок 2.20) для нашей блокчейн-сети. Задача будет следующая: найти число p, которое при 53 хешировании с решением предыдущего блока создает хеш с 4 ведущими нулями.
Рисунок 2.20 – Алгоритм «Proof to Work»
Для настройки сложности алгоритма, мы можем изменить количество ведущих нулей. Но 4 достаточно. Ибо добавление даже одного начального нуля сильно увеличит время работы алгоритма. Наш класс почти завершен, и мы готовы начать взаимодействовать с ним с помощью HTTP-запросов. Следующим шагом будет представление нашей блокчейн-сети как API. Мы собираемся использовать Python Flask Framework [21]. Это микрофреймворк, позволяющий легко сопоставлять конечные точки с функциями Python. Это позволяет нам общаться с нашей цепочкой блоков через интернет, используя HTTP-запросы. Мы создадим три метода. 1. /transactions/new для создания новой транзакции в блоке 2. /mine
чтобы сообщить нашему серверу, чтобы мой новый блок. 3. /chain чтобы вернуть полный блокчейн. Настройка Flask (рисунок 2.21): Наш «сервер» сформирует единый узел в нашей сети блокчейн. Создадим некоторый шаблонный код:
Рисунок 2.21 – Настройка Flask Краткое объяснение того, что сделано выше:
1) создали экземпляр нашего узла;
2) сгенерировали случайное имя для нашего узла;
3) создали экземпляр нашего класса Blockchain;
4) определили конечную точку /mine, которая является запросом GET;
5) определили конечную точку /transactions/new, которая является запросом POST, поскольку мы будем отправлять на нее данные;
6) определили конечную точку /chain, которая возвращает полный блокчейн;
7) запустили сервер через порт 5000. Конечная точка транзакций: Вот так будет выглядеть запрос на транзакцию (то, что пользователь отправляет на сервер) (рисунок 2.22):
Рисунок 2.22 – Вид запроса на транзакцию
Так как у нас уже есть наш метод класса для добавления транзакций в блок, остается лишь написать функцию (рисунок 2.23) для добавления транзакций:
Рисунок 2.23 – Добавление транзакции
Конечная точка майнинга: Наша конечная точка майнинга – это то место, где происходит основная задача блокчейна.
1. Рассчитывается доказательство работы (Proof to Work) (рисунок 2.24). 2. Генерируется новый блок и добавляется в цепочку.
Рисунок 2.24 – Proof to Work, генерация и добавление блока в цепочку
Стоит обратить внимание, что получателем добытого блока является адрес нашего узла. И большая часть того, что мы сделали здесь, это просто взаимодействие с методами нашего класса Blockchain. На этом мы закончили и можем начать взаимодействовать с нашей цепочкой блоков. Взаимодействие с нашей цепочкой блоков: Используем Postman [22] для взаимодействия с нашим API по сети. Запустим сервер: $ python blockchain.py * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit) 57 Попробуем добыть блок, отправив запрос GET (рисунок 2.25) на http://localhost:5000/mine:
Рисунок 2.25 – Попытка «добычи» блока запросом GET
Создадим новую транзакцию, сделав POST-запрос (рисунок 2.26) к http://localhost:5000/transactions/new с телом, содержащим нашу структуру транзакции:
Рисунок 2.26 – Попытка создания транзакции
После перезапуска сервера были «добыты» ещё два блока, чтобы получить в итоге 3 блока. Далее проверим всю цепочку (рисунок 2.27), запросив http://localhost:5000/chain
Рисунок 2.27 – Проверка цепи
У нас есть базовый блокчейн, который принимает транзакции и позволяет нам добывать новые блоки. Но весь смысл блокчейна в том, что они должны быть децентрализованы. И если они децентрализованы, как же мы можем гарантировать, что все они отображают одну и ту же цепочку? Это называется проблемой консенсуса, и мы должны будем реализовать алгоритм консенсуса, если нам нужно более одного узла в нашей сети. Регистрация новых узлов: Прежде чем мы сможем реализовать согласованный алгоритм, нам нужен способ сообщения узлу о соседних узлах в сети. Каждый узел в нашей сети должен вести реестр других узлов в сети. Таким образом, нам понадобятся еще несколько конечных точек.
1. /nodes/register чтобы принять список новых узлов в виде URL-адресов.
2. /nodes/resolve для реализации нашего согласованного алгоритма, который разрешает любые конфликты – чтобы убедиться, что узел имеет правильную цепочку. Далее нам нужно изменить конструктор нашего блокчейн и предоставить метод для регистрации узлов (рисунок 2.28):
Рисунок 2.28 – Метод регистрации узлов
Для хранения списка узлов мы использовали set (). Это простой способ гарантировать, что добавление новых узлов идемпотентно – то есть независимо от того, сколько раз мы добавляем конкретный узел, он появляется ровно один раз. Реализация алгоритма консенсуса (рисунок 2.29)
Рисунок 2.30 – Реализация алгоритма консенсуса
Как уже упоминалось ранее, конфликт возникает, когда один узел имеет другую цепочку к другому узлу. Чтобы решить эту проблему, мы установим правило, что самая длинная действительная цепочка является авторитетной. 61 Другими словами, самая длинная цепочка в сети является де-факто. Используя этот алгоритм, мы достигаем консенсуса среди узлов в нашей сети. Первый метод valid_chain () отвечает за проверку допустимости цепочки, просматривая каждый блок и проверяя как хеш, так и доказательство. resol_conflicts () – это метод, который проходит по всем соседним узлам, загружает их цепочки и проверяет их, используя вышеуказанный метод. Если найдена правильная цепочка, длина которой больше нашей, мы заменяем нашу. Зарегистрируем две конечные точки в нашем API (рисунок 2.31), одну для добавления соседних узлов, а
другую для разрешения конфликто
Рисунок 2.31 – Регистрация двух конечных точек API
На данном этапе понадобится второй компьютер или же можно добавить узлы в сеть, используя разные порты на одном компьютере. Было решено развернуть другой узел на второй машине, на другом порту, затем производится регистрация его на текущем узле. Таким образом, имеем два узла: http://localhost:5000 и http://localhost:5001 (рисунок 2.32).
Рисунок 2.32 – Регистрация узлов на двух портах
Затем было добыто несколько новых блоков на узле 2 (рисунок 2.33), чтобы убедиться, что цепочка длиннее. После этого вызываем GET /nodes/resolve на узле 1, где цепочка была заменена алгоритмом консенсуса:
Рисунок 2.33 – «Добыча» новых блоков на узле 2
Стартовое окно приложения
Рисунок 2.34 – Стартовое окно приложения
При запуске программы открывается стартовое окно приложения (рисунок 2.35). Пользователю предлагается ввести свой секретный идентификатор и войти в сеть, либо создать новый кошелёк. При создании нового кошелька для пользователя случайным образом генерируется уникальный закрытый ключ, который будет являться его личным идентификатором для входа. При входе в приложение открывается главное окно, и на основе закрытого ключа генерируется открытый адрес кошелька пользователя, с 20 помощью которого он может совершать транзакции и отслеживать изменения баланса. Главное окно приложения содержит основные элементы управления, сгруппированные по вкладкам: Обзор, Мой кошелёк, Новая транзакция и Майнинг.
Обозреватель блоков
Рисунок 2.35 – Вкладка Обзор блоков
На вкладке обзор (рисунок 2.35) пользователь может просмотреть всю необходимую информацию о любом существующем блоке цепочки. Навигацию между блоками осуществляется посредством нажатия кнопок Предыдущий блок и Следующий блок, либо посредством указания номера блока в текстовом поле.
Рисунок 2.18 – Методы создания нового блока
Выше мы описали общее представление нашего блокчейна. Далее опишем, как новые блоки создаются, подделываются или добываются. Понимание доказательства работы: 52 Алгоритм Proof of Work (PoW) – это то, как новые блоки создаются или добываются в цепочке блоков. Цель PoW - найти число, которое решает проблему. Это число должно быть трудно найти, но его легко проверить – говоря вычислительным путем - любому, кто находится в сети. Это основная идея Proof of Work. Рассмотрим простой пример. Давайте решим, что хеш некоторого целого числа x, умноженного на другой y, должен заканчиваться на 0. Итак, hash (x * y) = ac23dc...0. И для этого упрощенного примера давайте предположим, что x = 5. Реализация этого в Python (рисунок 2.19)
Рисунок 2.19 – Упрощенный пример алгоритма PoW в Python
Решение здесь: y = 21. Так как полученный хеш заканчивается 0: hash (5 * 21) = 1253e9373e...5e3600155e860 В биткойнах алгоритм Proof of Work называется Hashcash [20] – алгоритм доказательства правильности работы, требующий выборочного объёма данных для вычислений, но при этом доказательство может быть эффективно подтверждено. Данный алгоритм используется в основном с целью уменьшенить количество спама и DoS-атак. Нам же алгоритм Hashcash необходим в первую очередь для создания нового блока. Сложность алгоритма определяется количеством символов, которые ищут в строке. Далее реализуем базовый алгоритм Proof of Work (рисунок 2.20) для нашей блокчейн-сети. Задача будет следующая: найти число p, которое при 53 хешировании с решением предыдущего блока создает хеш с 4 ведущими нулями.
Рисунок 2.20 – Алгоритм «Proof to Work»
Для настройки сложности алгоритма, мы можем изменить количество ведущих нулей. Но 4 достаточно. Ибо добавление даже одного начального нуля сильно увеличит время работы алгоритма. Наш класс почти завершен, и мы готовы начать взаимодействовать с ним с помощью HTTP-запросов. Следующим шагом будет представление нашей блокчейн-сети как API. Мы собираемся использовать Python Flask Framework [21]. Это микрофреймворк, позволяющий легко сопоставлять конечные точки с функциями Python. Это позволяет нам общаться с нашей цепочкой блоков через интернет, используя HTTP-запросы. Мы создадим три метода. 1. /transactions/new для создания новой транзакции в блоке 2. /mine
чтобы сообщить нашему серверу, чтобы мой новый блок. 3. /chain чтобы вернуть полный блокчейн. Настройка Flask (рисунок 2.21): Наш «сервер» сформирует единый узел в нашей сети блокчейн. Создадим некоторый шаблонный код:
Рисунок 2.21 – Настройка Flask Краткое объяснение того, что сделано выше:
1) создали экземпляр нашего узла;
2) сгенерировали случайное имя для нашего узла;
3) создали экземпляр нашего класса Blockchain;
4) определили конечную точку /mine, которая является запросом GET;
5) определили конечную точку /transactions/new, которая является запросом POST, поскольку мы будем отправлять на нее данные;
6) определили конечную точку /chain, которая возвращает полный блокчейн;
7) запустили сервер через порт 5000. Конечная точка транзакций: Вот так будет выглядеть запрос на транзакцию (то, что пользователь отправляет на сервер) (рисунок 2.22):
Рисунок 2.22 – Вид запроса на транзакцию
Так как у нас уже есть наш метод класса для добавления транзакций в блок, остается лишь написать функцию (рисунок 2.23) для добавления транзакций:
Рисунок 2.23 – Добавление транзакции
Конечная точка майнинга: Наша конечная точка майнинга – это то место, где происходит основная задача блокчейна.
1. Рассчитывается доказательство работы (Proof to Work) (рисунок 2.24). 2. Генерируется новый блок и добавляется в цепочку.
Рисунок 2.24 – Proof to Work, генерация и добавление блока в цепочку
Стоит обратить внимание, что получателем добытого блока является адрес нашего узла. И большая часть того, что мы сделали здесь, это просто взаимодействие с методами нашего класса Blockchain. На этом мы закончили и можем начать взаимодействовать с нашей цепочкой блоков. Взаимодействие с нашей цепочкой блоков: Используем Postman [22] для взаимодействия с нашим API по сети. Запустим сервер: $ python blockchain.py * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit) 57 Попробуем добыть блок, отправив запрос GET (рисунок 2.25) на http://localhost:5000/mine:
Рисунок 2.25 – Попытка «добычи» блока запросом GET
Создадим новую транзакцию, сделав POST-запрос (рисунок 2.26) к http://localhost:5000/transactions/new с телом, содержащим нашу структуру транзакции:
Рисунок 2.26 – Попытка создания транзакции
После перезапуска сервера были «добыты» ещё два блока, чтобы получить в итоге 3 блока. Далее проверим всю цепочку (рисунок 2.27), запросив http://localhost:5000/chain
Рисунок 2.27 – Проверка цепи
2.9 Разработанное программное обеспечение
У нас есть базовый блокчейн, который принимает транзакции и позволяет нам добывать новые блоки. Но весь смысл блокчейна в том, что они должны быть децентрализованы. И если они децентрализованы, как же мы можем гарантировать, что все они отображают одну и ту же цепочку? Это называется проблемой консенсуса, и мы должны будем реализовать алгоритм консенсуса, если нам нужно более одного узла в нашей сети. Регистрация новых узлов: Прежде чем мы сможем реализовать согласованный алгоритм, нам нужен способ сообщения узлу о соседних узлах в сети. Каждый узел в нашей сети должен вести реестр других узлов в сети. Таким образом, нам понадобятся еще несколько конечных точек.
1. /nodes/register чтобы принять список новых узлов в виде URL-адресов.
2. /nodes/resolve для реализации нашего согласованного алгоритма, который разрешает любые конфликты – чтобы убедиться, что узел имеет правильную цепочку. Далее нам нужно изменить конструктор нашего блокчейн и предоставить метод для регистрации узлов (рисунок 2.28):
Рисунок 2.28 – Метод регистрации узлов
Для хранения списка узлов мы использовали set (). Это простой способ гарантировать, что добавление новых узлов идемпотентно – то есть независимо от того, сколько раз мы добавляем конкретный узел, он появляется ровно один раз. Реализация алгоритма консенсуса (рисунок 2.29)
Рисунок 2.30 – Реализация алгоритма консенсуса
Как уже упоминалось ранее, конфликт возникает, когда один узел имеет другую цепочку к другому узлу. Чтобы решить эту проблему, мы установим правило, что самая длинная действительная цепочка является авторитетной. 61 Другими словами, самая длинная цепочка в сети является де-факто. Используя этот алгоритм, мы достигаем консенсуса среди узлов в нашей сети. Первый метод valid_chain () отвечает за проверку допустимости цепочки, просматривая каждый блок и проверяя как хеш, так и доказательство. resol_conflicts () – это метод, который проходит по всем соседним узлам, загружает их цепочки и проверяет их, используя вышеуказанный метод. Если найдена правильная цепочка, длина которой больше нашей, мы заменяем нашу. Зарегистрируем две конечные точки в нашем API (рисунок 2.31), одну для добавления соседних узлов, а
другую для разрешения конфликто
Рисунок 2.31 – Регистрация двух конечных точек API
На данном этапе понадобится второй компьютер или же можно добавить узлы в сеть, используя разные порты на одном компьютере. Было решено развернуть другой узел на второй машине, на другом порту, затем производится регистрация его на текущем узле. Таким образом, имеем два узла: http://localhost:5000 и http://localhost:5001 (рисунок 2.32).
Рисунок 2.32 – Регистрация узлов на двух портах
Затем было добыто несколько новых блоков на узле 2 (рисунок 2.33), чтобы убедиться, что цепочка длиннее. После этого вызываем GET /nodes/resolve на узле 1, где цепочка была заменена алгоритмом консенсуса:
Рисунок 2.33 – «Добыча» новых блоков на узле 2
2.10 Результаты
Стартовое окно приложения
Рисунок 2.34 – Стартовое окно приложения
При запуске программы открывается стартовое окно приложения (рисунок 2.35). Пользователю предлагается ввести свой секретный идентификатор и войти в сеть, либо создать новый кошелёк. При создании нового кошелька для пользователя случайным образом генерируется уникальный закрытый ключ, который будет являться его личным идентификатором для входа. При входе в приложение открывается главное окно, и на основе закрытого ключа генерируется открытый адрес кошелька пользователя, с 20 помощью которого он может совершать транзакции и отслеживать изменения баланса. Главное окно приложения содержит основные элементы управления, сгруппированные по вкладкам: Обзор, Мой кошелёк, Новая транзакция и Майнинг.
Обозреватель блоков
Рисунок 2.35 – Вкладка Обзор блоков
На вкладке обзор (рисунок 2.35) пользователь может просмотреть всю необходимую информацию о любом существующем блоке цепочки. Навигацию между блоками осуществляется посредством нажатия кнопок Предыдущий блок и Следующий блок, либо посредством указания номера блока в текстовом поле.