Распределённые системы *

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

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

77+ примеров использования смарт-контрактов

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

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

Чтобы преодолеть отсутствие такого связующего звена, гибридные смарт-контракты используют оракулы в качестве посредника для сбора информации из внешних источников данных, предоставления информации во внешние источники, и для вычислений off-chain. Оракулы обеспечивают не только двустороннюю связь между смарт-контрактами и внешним миром,  но и безопасную среду, которая защищает от любого риска единой точки отказа (single point of failure), например, от манипуляции данных или системного сбоя.

Второй уровень (Layer 2, L2) - это любая офф-чейн сеть, система или технология, построенная поверх блокчейна (обычно известного как сеть первого уровня), которая помогает расширить возможности сети базового уровня. Сети второго уровня могут поддерживать любой блокчейн для внедрения таких улучшений, как например, более высокая пропускная способность транзакций.

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

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

Нет централизованного сервера. Используется любой email-сервер, который укажете

Надежное e2e-шифрование Autocrypt Level 1. Реализация прошла независмый аудит

Open Source, не преследует коммерческих целей, финансируется НКО и пользователями

Аудитория ~1М. Точно не оценить из-за отсутсвия телеметрии

Недостатки: не такой быстрый и отсутсвуют (пока) редактирование сообщений, реакции и треды

Несколько месяцев назад мне захотелось сдуть пыль со своего аккаунта в Steam и поиграть в старые игры про программирование.

While True Learn в очередной раз показалась слишком скучной, я пару дней позалипал в TIS-100, реализуя свой многопоточный процессор, но в конечном итоге осознал, что интереснее не играть в игры про программирование, а самому писать такие игры.

В статье рассказываю, что из этого получилось и на чём я сломался. Под катом —гремучая смесь из ссылок, картинок, теории распределённых систем и способов визуализации Python в 2022 году.

Решения в области дистанционного банковского обслуживания юридических лиц (ДБО ЮЛ) довольно продолжительное время строились на монолитных автоматизированных системах подрядчика. Вначале было Legacy от BSS, потом решение от R-Style SoftLab. В таких монолитах нет ничего плохого, это отличный базис, который не просто поддерживает жизнеспособность системы, но и до определенного момента оставляет простор для развития. Однако есть в них и минусы, и чем больше массив становится, тем острее они ощущаются.

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

В этой статье поговорим о том, какие бывают способы общения в микросервисной среде. Расскажу на пальцах, какие обычно предъявляются требования к общению сервисов, почему большинство использует REST API, даже при том, что у него тоже хватает минусов, и при чем тут Kafka.

Рассчитываю на новичков, но если у вас есть интересный опыт в этих вопросах - добро пожаловать в комментарии.

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

В СИГМЕ комплексные задачки любят. Поэтому отдел решений по автоматизации расчетов технических условий, чья работа напрямую зависит от достоверности данных, взялся за создание универсального инструмента для их выверки. И начали мы с разработки механизма загрузки и выгрузки данных с помощью конструктора на базе стандартов CIM (Common Information Model, electricity).

Команда работала над модулем выверки в рамках СИГМА СУС — решения нашей компании для управления распределительными электрическими сетями. Однако созданный конструктор и наши рекомендации будут полезны не только тем, кто занимается выверкой данных в распределительных электросетевых компаниях, но и тем, кто работает с показателями на других проектах.  

Меня зовут Сергей Петренко, вот уже четыре года я работаю над репликацией в Tarantool, и сегодня хочу рассказать про слабые места алгоритма Raft и способы их преодоления. Эта статья — вольный пересказ нашего с Борисом Степаненко доклада на Hydra 2022. Если читатель не знаком с Raft, то предлагаю ознакомиться с моей статьёй о нём.

Узрев повторную статью-мнение-перевод на оригинальный пост фаундера Signal "web3 не будет: расходимся по домам" https://habr.com/ru/post/673836/, не смог устоять от соблазна дать расширенное op-ed опровержение. И в комментарий оно не влезло.

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

Рациональный анализ приземленный на уровни абстракций “имхо” таков:

Данная статья поможет всем интересующимся лучше узнать про технические особенности платформ: Cosmos, Polkadot, Avalanche.

Эти платформы нацелены на горизонтальное масштабирование с асинхронной гетерогенной сетевой моделью, где предметноспецифичные блокчейны сосуществуют в рамках общей сетевой модели и при необходимости взаимодействуют друг с другом. У каждой платформы есть свои собственные подходы и компромиссы по достижению межцепочной экономической безопасности. Они нацелены на создание блокчейнового междусетья, которое способно вместить не сотни тысяч (как сегодня), а миллионы активных пользователей в день и полноценно реализовать концептуальное видение Web3, принадлежащего и контролируемого пользователями. 

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

Привет! Я Team Lead в Scalable Solutions. Мы с командой давно работаем над нашей платформой и уже дошли до той точки, когда любые технические решения должны быть обоснованы и согласованы с коллегами. Так исторически сложилось, что у нас есть ряд технических решений, которые были приняты в начале, но никогда не проходили этапы обоснования. К такому решению относится Protobuf. Поэтому я решил сравнить популярные бинарные форматы, чтобы выяснить, какие недостатки есть у каждого, и что сегодня наиболее оптимально с точки зрения эксплуатации. 

Привет! Меня зовут Александр Кленов, и я работаю в Tarantool. В апреле вышел Tarantool 2.10 Enterprise Edition – обновленная версия платформы in-memory вычислений. В версии 2.10 появилось несколько новых функций, о которых уже немного рассказывали на Хабре. 

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

Эта статья не будет технически глубокой. Мы поговорим о Data Lake и Data Warehouse, важных принципах, которые следует учитывать, и о том, какие сервисы GCP можно использовать для создания такой системы. Мы коснёмся каждого из GCP сервисов и поймём почему они будут полезны при создании Data Lake и Warehouse.

Прежде чем перейти к своей версии Data Lake и Data Warehouse, я хотел бы привести несколько известных архитектур, с которыми вы, возможно, уже знакомы, если интересуетесь этой темой. Архитектура, которую я бы предложил, будет более общей, чем эти: Cloud Storage as a data lake и Architecture: Marketing Data Warehouse.

В своей более общей версии Data Lake и Data Warehouse я расскажу о таких сервисах GCP, как Data Transfer Service, Dataproc, Cloud Storage, Cloud Scheduler, BigQuery, и Cloud SQL.

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

Второй вариант может быть реализован в виде исполняемого кода, либо с использованием специальных движков для исполнения сценария бизнес-процесса, который может включать в себя вызов внешних сервисов. Стандартом в области описания бизнес-процессов является визуальная нотация BPMN 2.0 и наибольший интерес представляет соединение графической диаграммы и исполняемых сценариев, которое также называется Executable BPMN 2.0 и среды для его исполнения, среди которых можно назвать jBPM, Flowable, Camunda BPM и Activiti (она интересна еще и тем, что на ней реализуется управление процессами в Open Source системе управления документами Alfresco). В этой статье мы рассмотрим основы BPMN и создадим простой процесс для управления системой полива в зависимости от измеренной влажности (все компоненты системы реализованы как микросервисы).

При всех достоинствах Kafka как распределенного хранилища потока сообщений, боль вызывало раздельное хранение метаданных (топологии разделов, конфигурации кластера и прочего) и необходимость запуска в кластере рядом с Kafka еще и Apache Zookeeper. Побочным эффектом такого соседства (кроме дополнительных забот об администрировании и мониторинге) является долгое время восстановления после сбоя при больших размерах кластера, значительном количестве разделов или сложной топологии групп. Но ситуация улучшается и отличная новость появилась полторы недели назад в KIP-833, что в ближайшей версии Kafka 3.3 новый протокол согласования метаданных (KRaft), работающий внутри Kafka без Zookeeper, будет признан Production-Ready и далее постепенно зависимость от Zookeeper будет помечена как deprecated и удалена. В этой статье мы поговорим об особенностях протокола KRaft и разберемся как настроить новый кластер Kafka без необходимости установки Zookeeper.

… простите, мигрировали куда? Туда!

Почему именно CockroachDB?

Тема задержки доступа и скорости извлечения сетевых ресурсов никогда не перестанет быть актуальной. Максимально близкое расположение источника влияет не только на скорость загрузки и пользовательский опыт, но и на эффективность работы глобальной сети в целом, поскольку позволяет локализовать трафик и сократить загрузку магистральных каналов, предпочитая использовать кэшированные или расположенные локально реплики сетевых ресурсов. Не случайно Google реализует модель сохранения локальных кэшей на оборудовании крупных региональных провайдеров (Google Global Cache) и интеллектуальные алгоритмы в маршрутизации на ближайшую реплики. В этой статье мы обсудим различные подходы к реализации распределенной сети доставки контента (Content Delivery Network, он же CDN), а также акцентируем возможные решения для создания CDN в масштабах отдельно взятой страны или города.