Выбор QuePaxa, необычного алгоритма консенсуса

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

QuePaxa — необычный выбор; большинство систем консенсуса используют хорошо зарекомендовавшие себя алгоритмы, такие как Raft, (Multi-)Paxos или Viewstamped Replication. Эти алгоритмы хорошо изучены, имеют зрелые реализации и обычно работают эффективно.

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

Глобальная среда развертывания Meerkat привела нас к более новому алгоритму консенсуса — QuePaxa, который обещает лучшую стабильность вопреки нестабильности, во многом благодаря тому, что для обеспечения прогресса не требуется наличие лидера. В этой статье мы объясним, почему мы выбрали QuePaxa и как работает этот алгоритм.

Что мы строим и почему это уникально

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

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

Meerkat использует свой журнал, работающий на основе консенсуса, для предоставления таких приложений, как хранилище «ключ-значение», где каждая запись в журнале является операцией получения (get) или записи (put). Поскольку алгоритм консенсуса гарантирует, что журналы реплик никогда не разойдутся, все они формируют одинаковое состояние «ключ-значение» (KV). К сопоставимым системам, работающим на основе консенсуса, относятся Consul, etcd и Apache ZooKeeper.

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

Проблемы консенсуса в глобальном масштабе

Хотя все алгоритмы консенсуса гарантируют, что реплики соглашаются с одним и тем же значением, многие из них становятся непропорционально недоступными или медленными при ухудшении сетевых условий (даже если машины не выходят из строя). Мы убедились в этом на собственном опыте: в 2020 году частичный отказ основного сетевого коммутатора Cloudflare привел к деградации системы, работающей на основе консенсуса, и панель управления работала в 80 раз медленнее обычного в течение шести часов. Важно отметить, что система не потеряла никаких данных. Но она стала недоступной для записи до тех пор, пока проблема не была решена, что неприемлемо.

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

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

Деструктивное вмешательство и лидеры

Рассмотрим Paxos, истинного прародителя большинства алгоритмов консенсуса. Многие алгоритмы консенсуса наследуют структуру Paxos — как хорошие, так и не очень хорошие стороны.

Опуская излишние детали, вот как работает Paxos. Существует два типа процессов: предложители (proposers) и акцепторы (acceptors). Абстрактно, цель системы заключается в том, чтобы большинство акцепторов согласились со значением, предложенным каким-либо предложителем. Есть две фазы: фаза подготовки (Prepare) и фаза принятия (Accept). На фазе подготовки любой предложитель может отправить номер бюллетеня большинству акцепторов. Этот номер бюллетеня служит обещанием — акцепторы будут принимать только предложения с этим номером бюллетеня или выше. Затем, на фазе принятия, предложитель снова отправляет свое предложение вместе с номером бюллетеня большинству акцепторов. Если большинство акцепторов все еще удерживают номер бюллетеня предложения, большинство принимает его, и предложитель может безопасно зафиксировать предложение.

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

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

Чтобы избежать постоянной конкуренции нескольких предложителей, большинство развернутых алгоритмов консенсуса, таких как Raft, Multi-Paxos и Viewstamped Replication, добавляют специального лидера-предложителя. Лидер — это единственная реплика, которая может делать предложения. Централизация полномочий по выдвижению предложений в одной реплике навязывает порядок одновременным запросам, позволяет избежать конкурирующих предложений и имеет дополнительное преимущество: решения принимаются за оптимальный один сетевой цикл (round-trip), а не за два. Пока лидер исправен, а сеть работает нормально, протоколы на основе лидера работают быстро.

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

Когда восстановление лидера нестабильно

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

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

Несколько реплик могут стать кандидатами — им достаточно лишь обнаружить, что лидер не работает. Затем все кандидаты могут одновременно попытаться получить большинство голосов. Проблема в том, что кандидаты будут конкурировать за большинство голосов, а это означает, что выборы в Raft страдают от деструктивной интерференции, которую мы только что видели в Paxos: две реплики могут взаимно мешать друг другу получить поддержку большинства и стать лидером. Чем чаще выборы заканчиваются неудачей, тем больше реплик будут пытаться избраться лидером.

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

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

Когда обнаружение сбоев идет не так

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

В распределенной системе, где машины разделены сетью, обнаружение сбоев в конечном итоге зависит от ожиданий. Процесс не может напрямую наблюдать, что удаленный процесс вышел из строя; он может только наблюдать, что ожидаемое сообщение пришло или не пришло. Нам нужен предсказуемый шаблон общения, такой как пульсации (heartbeats) или подтверждения, чтобы знать, что машина исправна. Если ожидаемое сообщение не приходит в ожидаемое время, мы подозреваем сбой. Сложность заключается в управлении этими ожиданиями.

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

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

В алгоритмах на основе лидера именно это предположение и запускает выборы лидера. Иногда лидер не работает; иногда его сообщения опаздывают или соединение молчаливо разорвано. Протокол не может знать, что именно произошло, прежде чем отреагирует. Если предположение неверно и реплика считает лидера неисправным, хотя это не так, начинаются выборы, и вся система должна остановиться. Пока лидер не будет заменен, прогресс не достигается — и, как мы только что видели, это может занять некоторое время.

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

Когда обнаружение сбоев происходит медленно

Даже когда детектор сбоев угадывает правильно, возникают проблемы. Детекторы сбоев реагируют на сбои, наблюдая за сообщениями в сети, поэтому время их отклика должно масштабироваться в зависимости от сетевой задержки — тайм-аут детектора не может быть меньше сетевой задержки. Именно поэтому Raft обычно развертывается с тайм-аутом выборов five to ten times the network round-trip time.. Он должен быть достаточно высоким, чтобы дать лидеру шанс подать сигнал о том, что он жив, и избежать ложного запуска выборов. Тайм-аут выборов может быть намного ниже, но поскольку выборы лидера полностью останавливают систему, тайм-ауты обычно устанавливаются консервативно высокими.

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

Почему QuePaxa — подходящий выбор

Мы поняли, что любой алгоритм, полагающийся на строгого лидера или точные тайм-ауты, неизбежно будет тормозить в системе консенсуса, работающей через Интернет. Мы искали алгоритмы консенсуса, разработанные для асинхронных сред — протоколы, которые не полагаются на хорошо работающую сеть или точное время для функционирования. Это привело нас к , опубликованному в 2023 году Tennage & Băsescu et al.

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

В QuePaxa, как и в Paxos, есть две роли: инициаторы (proposers) и регистраторы (recorders). Инициаторы подают предложения для принятия решения, а регистраторы служат посредниками между инициаторами, записывая каждое предложение, которое они видят.

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

Предостережение заключается в том, что предложения может не удасться распределить достаточно хорошо для достижения соглашения по какому-либо предложению, из-за чего инициаторам приходится пытаться снова, причем каждая такая попытка представляет собой раунд. Тем не менее, по мере того как все больше инициаторов отправляют предложения, возрастает вероятность того, что они сойдутся на предложении с наивысшим приоритетом. Именно это делает QuePaxa рандомизированным алгоритмом: случайно сгенерированные приоритеты инициаторов, не являющихся лидерами, с большой долей вероятности (хотя и не гарантированно) приводят к консенсусу по наивысшему известному приоритету в рамках раунда. И все же, если дать алгоритму достаточное количество раундов, достижение соглашения между инициаторами по какому-либо предложению гарантировано.

Один из инициаторов назначается лидером. Лидер — это единственный инициатор, способный принять решение за один сетевой круговой путь (round trip). Лидер всегда предлагает вариант с наивысшим приоритетом; если лидер знает, что он распространил свое предложение раньше любого другого инициатора, он может принять решение немедленно. Клиенты не обязаны делать запросы лидеру — предложение может выдвинуть любой инициатор. Если лидер выходит из строя, клиенты могут продолжать делать запросы другим инициаторам. Лидер полностью опционален. Просто у лидера выше вероятность принять решение, чем у любого другого инициатора, и сделать это быстрее, за один сетевой круговой путь.

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

Этот тайм-аут страховки сильно отличается от тайм-аутов, используемых в Raft или Multi-Paxos. Он не предназначен для обнаружения сбоев и поэтому не ограничен сетевой задержкой; он определяется репликами локально и может быть ровно таким маленьким, каким они захотят. В Raft установка пятимиллисекундного тайм-аута в сети со 100-миллисекундной задержкой полностью заморозила бы систему. Но в QuePaxa пятимиллисекундный тайм-аут страховки лишь увеличивает количество активных инициаторов.

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

Если лидер QuePaxa выходит из строя, мы можем восстановиться так быстро, как захотим — мы не связаны сетевой задержкой. Именно так QuePaxa обходит проблему обнаружения сбоев: поскольку предлагать может любой, а не только лидер, QuePaxa может упреждающе справляться с отказами лидеров с помощью подстраховки, а не реагировать на уже случившиеся сбои.

Как QuePaxa работает изнутри

Чтобы понять, как QuePaxa обеспечивает все эти полезные свойства, давайте посмотрим, как QuePaxa работает на самом деле.

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

• Фаза 0 (Предложение и принятие): Инициаторы случайным образом выбирают приоритет, отправляют свои предложения регистраторам и принимают предложение с наивысшим приоритетом, полученное от большинства регистраторов. Если это первый раунд и лидер знает, что его предложение достигло большинства регистраторов первым, лидер принимает решение немедленно.
• Фаза 1 (Распространение): Инициаторы распространяют свое принятое предложение среди большинства регистраторов.
• Фаза 2 (Проверка и принятие решения): Инициаторы запрашивают у большинства регистраторов предложение с наивысшим приоритетом, замеченное на предыдущей фазе. Если оно совпадает с их собственным принятым предложением, они принимают по нему решение.
• Фаза 3 (Перенос вперед): Любой инициатор, не сумевший принять решение, готовится к следующему раунду, принимая лучшее предложение из тех, что они видят у большинства регистраторов.

Давайте разберем пару примеров выполнения и посмотрим, как каждая фаза вносит свой вклад в общее поведение, которого мы ожидаем от QuePaxa. В каждом примере будет два инициатора (один из которых является лидером) и три регистратора.

Быстрый путь лидера (Фаза 0): Первая фаза выполняет три важные задачи: она рандомизирует приоритеты (что необходимо для обхода теоремы о невозможности FLP), проверяет, достиг ли лидер поддержки большинства в первую очередь, и помогает инициаторам прийти к консенсусу, если лидер этого не сделал. Предложение лидера не подвергается рандомизации и всегда имеет наивысший возможный приоритет.

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

Параллельный медленный путь (Фазы 0–3): Однако при наличии параллельных инициаторов нет гарантии, что лидер примет решение немедленно. Лидер может не успеть первым достичь большинства регистраторов или получить единственный ответ в поддержку другого инициатора. Давайте посмотрим, что происходит, когда другой инициатор оспаривает позиции лидера.

Фаза 0: Как показано на рисунке ниже, второй инициатор (выделен красным) первым достигает второго и третьего регистраторов. Быстрый путь заблокирован. Вместо того чтобы конкурировать, инициаторы принимают предложение с наивысшим приоритетом, полученное от большинства, и переходят ко второй фазе. На этой фазе оба инициатора могут сойтись на предложении лидера. В иллюстративных целях наш пример предотвращает схождение путем задержки сообщений лидера.

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

Фаза 2: Теперь может быть принято решение. Каждый инициатор определяет, получила ли предложение с более высоким приоритетом достаточную поддержку, чтобы обойти его собственное. Для этого он запрашивает у большинства регистраторов предложение с наивысшим приоритетом, замеченное во время Фазы 1. Если возвращенное предложение по-прежнему является их собственным принятым предложением, они принимают решение. На нашей схеме лидер видит, что большинство возвращает его собственное предложение, и благополучно принимает решение. Другой инициатор получает противоречивые сводки, поэтому он пока не может принять решение. Как и в Фазе 1, регистраторы отслеживают предложение с наивысшим приоритетом, которое они получили.

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

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

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

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

Ни один инициатор не должен обнаруживать, что лидер вышел из строя, прежде чем удастся продвинуться вперед, а неудачный раунд не отбрасывает уже проделанную работу. Когда сеть ведет себя нормально, QuePaxa работает быстро. Когда нет — QuePaxa продолжает движение.

Как QuePaxa делает Meerkat возможным

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

Скорость, с которой Meerkat обрабатывает запросы, также в целом предсказуема. Большинство решений — более 95% — принимаются лидером на первой фазе, что обеспечивает относительно стабильную пропускную способность. В тех случаях, когда решение не достигается на первой фазе, пропускная способность на мгновение падает, максимум до трети от обычного уровня, что сигнализирует о том, что для принятия решения потребовалось три круговых обхода (и, соответственно, три фазы) вместо одного. Система замедляется, но не останавливается полностью.

Что мы покажем дальше

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