Итоги 06/03/2018

TechnoL0g

Добавлены автоматизированные тесты для нескольких библиотек

системы автоматизированных тестов используют несколько проектов, в том числе команда bitcoin core, автоматизированные тесты исключают многие проблемы при разработке и тестировании

Полностью завершена и готова к использованию библиотека smartholdem-rpc, в последней версии добавлены параметры работы с RPC Json по whitelist ip:

Прием запросов с указанного адреса

--allow <address>

Прием запросов от всех адресов, для тестирования и настройки

--allow-remote

Добавлена работающая генерация иерархических адресов с masterpassword на основе протокола bip38

Добавлен протокол генерации специализированных qr-кодов с uri на основе протокола bip021 необходимой для выставления счетов, оплаты по ссылкам, новой версии desktop кошелька

Общедоступный репозитарий медиа материалов smartmedia постоянно обновляется

Анонсирован раздел SmartHoldem Improvement Proposals - SHIPs с собственным шаблоном, аналог BitCoin BIP, в данном разделе предлагаются к реализации будущие протоколоы платформы SmartHoldem

Создан Lite Java Client взаимодействия с blockchain SmartHoldem, это 1 из 4 необходимых библиотек развертывания SmartEvents Contracts и нового событийного протокола взаимодействия сервисов см п.7.

Создана отдельная группа репозитариев SmartEvents направлена на развитие SmartEvents протоколов, контрактов и нового событийного подхода взаимодействия с blockchain платформами, здесь подробнее:

Предисловие

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

По исследованиям многих кампаний, 99% ресурсов серверов тратятся впустую из-за "холостых" обращений к базам данных в сети, что приводит к дополнительным затратам наращивания серверного железа (RAM, CPU etc..)

Наше видение

100% эффективность использования ресурсов против 1%, сокращение серверных издержек. Данная проблема решается разработкой событийного подхода, состоящего из слушателей (listeners) и поставщиков услуг (services).

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

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

Как это работает

Пример 1 - необходимо получать информацию о поступающих транзакциях на тысячи адресов

Listeners слушают события сети в blockchain локально / удаленно, создавая больше возможностей для пользователей сети и децентрализуя службы. API позволяет потребителям создавать подписки и получать события blockchain в режиме реального времени с использованием обратных вызовов Webhook.
Services обрабатывают события и выполняют любые заданные условия и контракты. Создают и выполняют сервисные контракты, которые могут быть любыми: от загрузки файла до передачи ценностей, создания интеллектуальных контрактов, выполнения кода на вычислительных платформах на основе bockchain или взаимодействия с IoT.
Потребитель услуг (к примеру биржа с тысячей адресов SmartHoldem) подписывается на события в сети, в нашем примере это поступление транзакции на адреса N1000+ с условием 5+ подтверждений.

Когда происходит событие Services выполняют необходимую логику, к примеру отправить POST оповещение в базу данных/Callback URL о поступлении новой подтвержденной транзакции и добавить баланс STH в аккаунт пользователя.

!Здесь исключена любая лишняя нагрузка на сервера и 100% эффективность с минимальным потреблением ресурсов.

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

Пример максимально упрощен в понимании базовых принципов взаимодействия узлов.

В качестве безопасности могут использоваться white list, доверенные узлы и уникальный API Key, получаемый потребителем услуг на основе STH-Адреса. Т.е. все запросы в сети происходят с авторизацией. Запросы без авторизации отклоняются сервисами и слушателями сети.

Для получения Api Key потребитель пополняет свой адрес STH на необходимую сумму задаваемую поставщиками услуг от 0 до N монет. Если потребитель является и поставщиком собственных услуг он может задать 0.

Если потребитель использует доверенных поставщиков услуг, услуга будет предоставляться до тех пор пока не растратится весь баланс подписанного адреса с API Key в пользу поставщика услуг. Рекомендуемая начальная сумма для поставщиков услуг 100 единиц.

Услуги и контракты неограничены в своих модификациях. Первичные услуги и события могут быть следующего содержания:

создан новый блок - выполнить операцию
получена транзакция на адрес A с числом подтверждений N
получена транзакция на адрес A с числом подтверждений N и суммой > S
отправлена ставка на игровое событие E
инициировано игровое событие + сервисный контракт
получен блок N
прямой обмен BTC > STH через сеть + контракт
итд..