Новости Golos•Core. Статус софтфорка 0.16.5 на 16.02.2018.

Добрый день! 

Рады сообщить, что команда  Golos•Core выложила релиз-кандидат софтфорка 0.16.5. Принимая во внимание интерес делегатов и коммьюнити к софтфорку, мы хотим дополнительно пояснить, как и почему мы решили развивать блокчейн Голоса в сторону использование WebSocket, и какие будут преимущества при развитии в эту сторону. 

Блокчейн Голоса  - это одна из разновидностей базы данных, состояние которой меняется достаточно быстро ~±3 секунды.   И следовательно, клиенты базы данных должны реагировать на эти изменения так же быстро. Целесообразно в этом случае проанализировать те решения, которые имеются в классических базах данных.

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

В случае, когда базы данных завязаны на информацию, поступающую через Интернет (протокол [TCP|https://en.wikipedia.org/wiki/Transmission_Control_Protocol]), непрерывное соединение можно обеспечить только через использование  WebSockets  (прогрессивный стандарт двусторонней связи с сервером по TCP-соединению, совместимый с HTTP). Много работающих блокчейн-сервисов, в настоящий момент активно вводят в эксплуатацию именно это решение.

Блокчейны поддерживающие websockets:

• Bitcoin https://blockchain.info/api/api_websocket
• Ethereum https://etherscan.io/apis#websocket
• Ripple https://ripple.com/build/websocket-tool/
• Cardano https://cardanodocs.com/technical/wallet-frontend/
• NEO https://github.com/TakahikoKawasaki/nv-websocket-client

Биржи, поддерживающие websockets:

• Bitfinex https://docs.bitfinex.com/docs
• BitMEX https://www.bitmex.com/app/wsAPI
• Bitstamp https://www.bitstamp.net/websocket/
• GDAX https://docs.gdax.com/#websocket-feed
• Luno https://www.luno.com/en/api

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

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

Об изменении состояния системы  - о событиях - можно узнавать несколькими способами: либо периодически отправляя запросы (polling), например, когда клиент приходит на сервер с запросом на свежие данные, и получает ответ, что новые данные не появились; либо длинные запросы (long polling) — когда клиент посылает «ожидающий» запрос на сервер, а сервер смотрит, есть ли свежие данные для клиента, если их нет, то он держит соединение с клиентом до тех пор, пока эти данные не появятся; либо держать низкоуровневое соединение - когда клиент просит сервер сообщать об изменении состояния системы. 

Существуют критерии, позволяющие выбрать оптимальный тип соединения.

Чем выше скорость отклика:

• Тем больше времени база данных может выделить на обработку данных, а не на поддержание активных соединений.
• Тем большее количество запросов и соединений успеет обработать база данных.
• Тем быстрее пользователь получит ответ от базы данных.

Чем меньше объем данных, передаваемых по сети:

• Тем меньше нагрузка на сеть, как по объему, так и по скорости.
• Тем меньше работы надо сделать БД, чтобы начать обработку данных.
• Тем меньше работы надо сделать БД, чтобы отправить ответ клиенту.

Чем более независимы клиент и сервер в последовательности обработки данных:

• Тем большей гибкостью обладает сервер в планировании обработки запросов от клиентов.
• Тем большей гибкостью обладает клиент в определении стратегии запроса информации.

Однако, Websockets благодаря своей низкоуровневости и уменьшению количества полей в заголовках не может быть закеширован стандартными методами, которыми можно кешировать HTTP. Но это не является проблемой. В нашем понимании - демон не должен заниматься кешированием и другими специфическими функциями, его задача - работать с цепочкой и предоставлять информацию из нее, как классическая база данных. Задача кеширования должна решаться в отдельном от демона процессе, в качестве которого можно использовать любое in-memory хранилище, которые уже оптимизированы для подобного рода задач. 

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

Модель ниже демонстрирует как работает реализованный дизайн

Поток исполнение  и передачи управления  между компонентами системы 

В независимости от цвета такой стрелкой происходит логическое перемещение данных между компонентами системы 

Легенда к схеме:

1 ) Устанавливаем Websocket-соединение, получаем первое сообщение из соединения  

2,3 ) Формируем задачу на исполнение, получаем список зарегистрированных  обработчиков сообщений, все заворачиваем в специализированную структуру для обработки в пуле-потоков (threadpool).

4 ) Пул-потоков выбирает свободный поток (thread) для выполнения задачи

5 ) Поток запускает на выполнение полученную задачу.

6 ) Во время выполнения задачи, поток запрашивает необходимые данные из блокчейна 

7,8 ) Поток обрабатывает полученные для выполнения задачи значения и формирует результат, который передается в callback для записи в сетевое соединение.

8')  Происходит запись результата в сокет 

Плюсы:

• Использование в порядке, удобном для демона 
• Уменьшение расхода потребляемых ресурсов вычислительной ноды, за счет уменьшения объемов передаваемых данных 
• Возможность в будущем асинхронно отвечать на все запросы

Минусы:

• Перерасход открытых соединений, так как websockets подразумевает постоянное открытое соединение (решается с помощью установления ограничения на количество  портов на демоне и хост-машине).

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

Результаты бенчмарков golosd 0.16.4

Результаты бенчмарков golosd 0.16.5

Единица измерения в миллисекундах. (здесь под пингом подразумевается - latency (задержка))

Входные данные 8 клиентов и с каждого по 1875 запросов на демона (суммарно 15000 запросов). 

• на версии 0.16.4 средняя задержка: 25-30 мс, общее время выполнения тестов: 62.25 с.
• на версии 0.16.5 средняя задержка: 2-3 мс, общее время выполнения тестов: 5.03 с. Учитывая, что часть этого времени - создание соединения между клиентом и сервером.

При тестировании использовалось несколько тяжелых методов (по версии 0.16.4) на чтение.

Новый релиз-кандидат можно найти по ссылке:

https://github.com/GolosChain/golos/releases/tag/v0.16.5RC1 

Для всех желающих протестировать софтфорк 0.16.5 организован публичный тестнет: wss://ws.testnet.golos.io (доступен только демон без веб-интерфейса).

P.S. На этой неделе @ropox сообщил о сделанной оптимизации кода в части линейной функции. По-прежнему придерживаемся мнения, что линейная функция сначала должна быть тщательно замоделирована и проанализирована по ряду параметров. К сожалению, на подготовленный код не разработаны unit-тесты (если они в процессе разработки, то ждем инфо - как будут сделаны). Со своей стороны планируем протестировать предложенный ХФ и дать экспертную оценку возможности его принятия.

Мы будем очень рады, если вы поддержите делегата @goloscore. Заходите на страничку https://golos.id/~witnesses и проголосуйте за делегата Golos•Core

Спасибо за внимание и хорошего дня! 

С уважением,
Команда Golos•Core @kotbegemot, @korpusenko, @abgvedr, @andreypf, @epexa, @muhazokotuha, @mariadia