Итоги 06/03/2018



  • Block 832846

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

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


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

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

    --allow <address>

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

    --allow-remote

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


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

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

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

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

    1. Создана отдельная группа репозитариев 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 через сеть + контракт
      итд..