Введение

В последние несколько лет большую популярность обретают системы, в основе которых лежит так называемый блокчейн, привлекающий пользователей рядом своих преимуществ: децентрализацией, неизменяемостью данных, прозрачностью, а также отсутствием доверенного центра, то есть посредника. Предоставление таких преимуществ возможно благодаря двум “китам” блокчейна: асимметричному шифрованию и использованию хэш-функций. Однако в связи с развитием квантовых вычислений безопасность этих примитивов стала под угрозой, поэтому возникает необходимость нахождения новых подходов к построению блокчейна, который будет устойчив к атакам с помощью квантового компьютера — так называемого постквантового блокчейна. В данной статье освещается, какие части блокчейна являются наиболее уязвимыми для атак с помощью квантового компьютера, насколько реальны эти угрозы, какие существуют подходы к построению постквантового блокчейна, устойчивого к ним, и насколько применимыми оказываются эти подходы.

Введение

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

Ключевая идея шардинга заключается в том, что вместо того, чтобы каждая транзакция в сети была выполнена каждым участником, только подмножество участников выполняют каждую транзакцию. Для достижения этой цели все состояние цепи (аккаунты, контракты, данные) разбиваются на несколько непересекающихся интервалов, которые называются “шардами”; каждый участник сети назначается на один или больше шардов, и скачивает и выполняет только транзакции, относящиеся к своим шардам.

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

Это приводит к потенциальной проблеме: без загрузки и проверки всей истории участник не может быть уверен, что состояние, с которым он взаимодействует, — это результат валидной последовательности блоков и что такая последовательность действительно является канонической цепочкой в этом шарде. В прошлой статье я показывал, почему этой проблемы нет в нешардируемых блокчейнах. 

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

Представим, что вам нужно настроить мониторинг распределённой базы данных, такой как GridGain. Метрики положим в Prometheus. Графики нарисуем в Grafana. Про систему оповещения не забудем – для этого настроим Zabbix. Для анализа трейсов воспользуемся Jaeger. Для управления состоянием и CLI хорош. А для SQL запросов воспользуемся бесплатным JDBC клиентом вроде DBeaver.

Теперь настраиваем для каждого из инструментов систему аутентификации, чтобы никакая информация не просочилась, и мы у цели. В итоге получили связку инструментов, которая сложнее самой распределённой системы, ради которой всё затевалось.

А теперь наймем для поддержки и настройки всего этого зверинца команду специалистов и будем жить долго и счастливо. Или нет, потому что столько ресурсов мы на эту задачу просто не получим. Придется искать способы удешевить обслуживание. В GridGain моя команда для этого написала собственный инструмент, закрывающий все потребности распределенной In-Memory платформы Apache Ignite или ее корпоративной версии GridGain.

Control Center умеет работать с GridGain начиная с версии 8.7.23 любой редакции, а также с Apache Ignite версии не младше 2.8.1.

Всем привет!

Дисклеймер:
Данная статья не несет в себе сведений ранее неизвестных читателям, знакомым с понятием CDN, а носит характер обзора технологии

Вчера произошел запуск NEAR, проекта, над которым я и мои коллеги работали последние 2 года.

NEAR – это протокол блокчейна и платформа для децентрализованных приложений, с акцентом на производительность и простоту использования.

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

Зачем нужны протоколы блокчейна

Протоколы блокчейна предоставляют очень важную инфраструктуру, которая позволяет запускать приложения, которые не контролируются никакой централизованной организацией.

В краткосрочной перспективе это уже используется для построения финансовых сервисов, которые не контролируются банками и государствами. На Ethereum – самой популярной на сегодня платформе для децентрализованных приложений – за последние два года появилось огромное количество интересных финансовых сервисов: MakerDAO построили децентрализованную валюту, чья цена почти точно равна одному доллару, позволяя использовать финансовые сервисы на платформе с использованием неволатильных активов. Compound построили возможность класть деньги в их сервис, и получать почти гарантированный доход, Augur и Flux построили сервисы, на которых можно делать ставки на различные события в реальном мире. Помимо этого на Ethereum запущено большое количество различных децентрализованных бирж. Все эти сервисы либо автономны и не контролируются никем, либо контролируются коллективно участниками сервиса.

Финансовые продукты, которые не контролируются государством и банками – это очень важное направление. Но протоколы блокчейна позволяют делать намного больше.

В конце октября запускаем новую группу курса «Архитектура и шаблоны проектирования» и приглашаем всех специалистов на бесплатный Demo-урок «Шаблон адаптер», который проведёт Матвей Калинин — главный разработчик в одном из крупнейших банков страны.

Введение

Привет, Хабр!

Наша компания специализируется на разработке программных решений класса ERP, в составе которых львиную долю занимают транзакционные системы с огромным объемом бизнес-логики и документооборотом а-ля СЭД. Современные версии наших продуктов базируются на технологиях JavaEE, но мы также активно экспериментируем с микросервисами. Одно из самых проблемных мест таких решений – интеграция различных подсистем, относящихся к смежным доменам. Задачи интеграции всегда доставляли нам огромную головную боль, независимо от применяемых нами архитектурных стилей, технологических стэков и фреймворков, однако в последнее время в решении таких задач наметился прогресс.

В предлагаемой вашему вниманию статье я расскажу об имеющихся у НПО «Криста» опыте и архитектурных изысканиях в обозначенной области. Также мы рассмотрим пример простого решения интеграционной задачи с точки зрения прикладного разработчика и выясним, что скрывается за этой простотой.

Привет, Хабр!

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

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

Привет, Хабр!

В этой статье мы обсудим генерацию псевдо-случайных чисел участниками, которые не доверяют друг другу. Как мы увидим ниже, реализовать “почти” хороший генератор достаточно просто, а вот очень хороший – сложно.

Зачем вообще нужно генерировать случайные числа участникам, не доверяющим друг другу? Одна из областей применения -- это децентрализованные приложения. Например, рассмотрим децентрализованное приложение, которое принимает ставку от участника и либо удваивает сумму с вероятностью 49%, либо забирает с 51%. Приложение будет работать только если алгоритм может непредвзято получить случайное число. Если злоумышленник сможет повлиять на результат или предсказать случайное число, и даже незначительно увеличить свой шанс получить выплату в приложении, он получит возможность опустошить его.

Когда мы разрабатываем распределенный протокол генерации случайных чисел, мы хотим, чтобы он обладал тремя свойствами:

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

Он должен быть непредсказуемым. Другими словами, ни один участник не должен иметь возможность предугадать, какое число будет сгенерировано (или вывести какие-либо его свойства) до того, как оно будет сгенерировано.

Протокол должен быть жизнеспособным, то есть устойчивым к тому, что какой-то процент участников отключатся от сети или намеренно попытаются остановить протокол.

В этой статье мы рассмотрим два подхода: RANDAO + VDF и подход, основанный на стирающих кодах. В следующей части мы подробно разберем подход, основанный на пороговых подписях.

Введение

Часть II. Узнаем, как писать агентов, обрабатывающих стрим событий из kafka, а так же как написать команды (обёртка на click).

1. Часть I: Введение
2. Часть II: Агенты и Команды

Как я дошёл до жизни такой?

Не так давно мне пришлось работать над бэкендом высоко нагруженного проекта, в котором нужно было организовать регулярное выполнение большого количества фоновых задач со сложными вычислениями и запросами на сторонние сервисы. Проект асинхронный и до того, как я пришёл, в нём был простой механизм крон-запуска задач: цикл с проверкой текущего времени и запуск групп корутин через gather — такой подход оказался приемлем до момента, пока таких корутин были десятки и сотни, однако, когда их количество перевалило через две тысячи, пришлось думать об организации нормальной очереди задач с брокером, несколькими воркерами и прочим.

Введение

Введение