Итоги 06/03/2018
Block 832846
Добавлены автоматизированные тесты для нескольких библиотек
smartholdem-rpc
smartholdem-blockexplorer
sth-js
системы автоматизированных тестов используют несколько проектов, в том числе команда 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 через сеть + контракт
итд..
Это, конечно, хорошо)) но охват нужен мировой в перспективе, и лучше сразу ориентироваться на это)
