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

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

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

Эта статья впервые появилась в журнале Computer и подготовлена InfoQ & IEEE Computer Society.

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

За десятилетие, прошедшее с появления теоремы, разработчики и исследователи использовали теорему CAP (а иногда и злоупотребляли ею) как повод для изучения широкого спектра новых распределенных систем. Движение NoSQL также использовало её в качестве аргумента против традиционных баз данных.

В теореме CAP говорится, что любая сетевая система с общими данными может иметь не более двух из трех желаемых свойств:

• согласованность (С), эквивалентная наличию единственной актуальной копии данных;
• высокая доступность (A) этих данных (для обновлений); и
• устойчивость к сетевым разделениям (P).

Такое толкование CAP помогало разработчикам быть открытыми для более широкого диапазона систем и компромиссов; действительно, за последнее десятилетие возникло множество новых систем и много споров об относительных достоинствах согласованности и доступности. Формулировка «2 из 3» всегда вводила в заблуждение, поскольку имела тенденцию чрезмерно упрощать противоречия между свойствами. Но сейчас такие тонкости имеют значение. CAP запрещает лишь крошечную часть проектного пространства: идеальная доступность и согласованность при наличии разделений, которые встречаются редко.

Привет, Хабр! Меня зовут Сергей Корнеев, и я хочу рассказать о том, как мы организовали сбор данных в компании “Россети”. На момент запуска проекта я работал в “Россети.Цифра” и руководил внедрением BI-платформы. Нам с командой удалось решить проблему ручного сбора данных на базе Visiology Smart Forms, и именно об этом я расскажу сегодня. 

Сеть Интернет по своей архитектуре допускает возможность прямого обмена трафиком между любыми узлами, но все же в большинстве сценариев используется асимметричный вариант использования с относительно небольшим количеством узлов, отдающих содержание (объединенных в CDN, кэширующие сети (например, Google Global Cache), либо отдельные зеркала, расположенные на высокоскоростных каналах). При многих достоинствах такой подход не лишен и серъезных недостатков, прежде всего из-за значительной разбалансированности сети и перегрузке некоторых каналов связи при относительно небольшом трафике на других.

Решением этой проблемы могло стать использование сетей, основанных на прямом обмене трафиком (peer-to-peer или p2p), но создание полностью децентрализованной сети представляет значительную сложность, поэтому во многих случаях все же оставляют некоторые общие реестры, хранящие информацию об узлах-носителях определенного содержания (так, например, работают торрент-трекеры) и на которых регистрируются клиенты сети при подключении. Основным недостатком такого псевдодентрализованного подхода является возможность относительно простой остановки функционирования сети через блокировку соответствующих трекеров. Альтернативой могут быть полностью децентрализованные сети и мы рассмотрим в этой статье основные подходы к их реализации на примере свободного протокола и сети Peernet.

Привет, Хабр! Сегодня мне хотелось бы поговорить о том, почему все больше клиентов ЦОДов предпочитают гибридные облачные инфраструктуры, и поговорить о том, как именно их можно реализовать на практике. Под катом вы найдете разные схемы создания гибридной облачной инфраструктуры. Всех заинтересованных приглашаю обсудить плюсы и минусы такого подхода в развитии ИТ-инфраструктуры.

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

Перед вами перевод Белой Книге, где описывается основная концепция Solana - доказательство истории (Proof-of-History, PoH).

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

Если вы работаете с вебом, вы обязательно столкнётесь с брокерами сообщений. Они бывают разные, но чаще остальных встречаются Kafka, RabbitMQ и AWS SNS/SQS. У каждого из них есть свои особенности, плюсы и минусы — выбирать брокер нужно под свою задачу. 

О том, как сделать правильный выбор, рассказали эксперты из команды курса «Go-разработчик» Яндекс Практикума: 

• Многоуровневая архитектура;
• «Клиент-сервер»;
• «Каналы и фильтры»;
• «SOA»;
• «Издатель-подписчик»;
• «Общие данные»;
• «Одноранговая сеть»;
• «Брокер сервисов».

Мы делаем Юлу уже 7 лет, из небольшого проекта она превратилась в сервис объявлений с аудиторией в 33 млн пользователей. За это время в Юле появилось значительное количество функций и настроек, реализованных в разных компонентах. Одна из трудностей, встающих перед разработчиками подобных распределённых систем, связана с обеспечением согласованной работы отдельных компонентов, а именно с поддержкой контрактов сервисов. Мы также столкнулись с некоторыми проблемами, вытекающими из первоначального отсутствия контрактов.

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

В идеальном децентрализованном приложении мы бы хотели хранить все в блокчейне на смарт-контрактах — в хранилище Ethereum: данные не могут быть изменены несанкционированным способом. Но запись какой-либо информации, размером 32 байта обойдется нам в 20000 газа. На момент написания статьи это примерно $0.26, c одной стороны не много, но что если мы хотим хранить в хранилище какой-то значительный массив информации.

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

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

Приветствую, коллеги.

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

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

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

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

Итак, рассмотрим подробно, как устроена предлагаемая система:

В основе системы лежат события, которые генерируют приложения. События сохраняются в лог (stdout, файл,..). Обработчик (сборщик) логов (в режиме реального времени) распознает в логах события приложений и отправляет их в хранилище (БД).

Немного иной взгляд на концепцию "Web3" технологий.

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

Однако финансовые рынки на основе блокчейна — обычно называемые децентрализованными финансами или просто DeFi — часто включают пользователей, которые идентифицируются только по псевдоанонимным адресам. Чтобы учесть эту уникальную динамику ограниченной кредитной репутации, рынки кредитования DeFi, как правило, имеют избыточное обеспечение, то есть заемщикам необходимо внести залог, превышающий стоимость кредита. Например, заемщику может потребоваться внести 150 долларов в ETH в качестве залога, чтобы взять 100 долларов USDC. Такой избыточный залог гарантирует, что если заемщик не сможет вернуть долг, залог может быть ликвидирован, чтобы возместить убытки кредиторов — основополагающий механизм поддержания платежеспособности.

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

К счастью, это становится возможным благодаря технологическим прорывам, таким как DECO — протокол оракула с сохранением конфиденциальности, который находится в стадии разработки. Примечательно, что DECO использует доказательство с нулевым разглашением (ZKP) для подтверждения информации вне блокчейн, не делая ее общедоступной на блокчейн или даже для самих оракулов.

В 2019 году к нам обратился «Ростелеком» с запросом о создании федеральной системы дистанционного электронного голосования (ДЭГ) на основе блокчейна. По сравнению с обычным голосованием ДЭГ на блокчейне явно дешевле и быстрее для подсчета голосов; оно также может обеспечить большую явку. Но при этом для большинства людей блокчейн-голосование — это черный ящик, а в голосованиях такого уровня ящик все-таки должен быть прозрачным. О том, как мы добились этого и выполнили другие требования заказчика, я расскажу далее в посте.

У нас есть задача постоянно компилировать тонны плюсового кода. Наш проект — почти 200 000 cpp- и h-файлов, множество Git-веток, сотни разработчиков, десятки билд-агентов: его нельзя единожды скомпилировать, приходится перекомпилировать постоянно, параллельно, разные версии.

Наш проект необычный. Потому что эти 200 000 файлов — это результат автогенерации. Потому что пишем мы на PHP, а потом через KPHP все PHP-исходники превращаются в плюсы. Именно так разрабатывается бэкенд ВКонтакте.

Компилировать тысячи объектников долго. Локально это занимает много часов. Мы использовали distcc — но всё равно медленно. Мы даже пропатчили distcc для поддержки precompiled headers — но даже тогда медленно. И решили написать своё — чтоб стало, наконец, быстро.

В итоге мы написали замену distcc — компилятор nocc. Он не имеет никакого отношения к PHP и даже к KPHP, а просто предназначен для компиляции .cpp → .o в промышленных масштабах.

Это техническая статья про параллелизацию, демоны и специфику С++. Ссылки на GitHub и видео приложу в конце статьи.

Привет! Меня зовут Антон Губарев, я инженер PaaS (Platform-as-a-Service) в Авито. Платформа как сервис позволяет продуктовым командам разработки не тратить время на рутинные инфраструктурные задачи, в том числе такие как определение  оптимальных значений request/limit CPU и RAM для контейнеров в кластерах Kubernetes. Вместо этого они могут сосредоточиться на качестве микросервиса, над которым работают. PaaS умеет автоматически рассчитывать ограничения и выделять ресурсы для каждого из 1 800 микросервисов Авито.

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

Закончилась конференция SmartCon 2022 организованная Chainlink, где выступили более 150 докладчиков и было представлено более 100 презентаций, собрались ведущие представители индустрии Web2 и Web3, такие как Google, Coinbase, SWIFT, FTX, BNY Mellon, T-Systems MMS и др.

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