Jump to content

Консенсус (информатика)

(Перенаправлено из алгоритма консенсуса )

Фундаментальной проблемой распределенных вычислений и многоагентных систем является достижение общей надежности системы при наличии ряда сбойных процессов. Это часто требует координации процессов для достижения консенсуса или согласования некоторого значения данных, которое необходимо во время вычислений. Примеры применения консенсуса включают в себя согласование того, какие транзакции и в каком порядке фиксировать в базе данных, репликацию конечного автомата и атомарные широковещательные рассылки . Реальные приложения, часто требующие консенсуса, включают облачные вычисления , синхронизацию часов , PageRank , формирование мнения, интеллектуальные энергосистемы , оценку состояния , управление БПЛА (и несколькими роботами/агентами в целом), балансировку нагрузки , блокчейн и другие.

Описание проблемы

[ редактировать ]

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

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

Протоколы, решающие проблемы консенсуса, предназначены для работы с ограниченным числом ошибочных процессов . Чтобы быть полезными, эти протоколы должны удовлетворять нескольким требованиям. Например, тривиальный протокол мог бы заставить все процессы выводить двоичное значение 1. Это бесполезно; таким образом, требование изменяется таким образом, что производство должно зависеть от ресурсов. То есть выходное значение протокола консенсуса должно быть входным значением некоторого процесса. Другое требование состоит в том, что процесс может принять решение о выходном значении только один раз, и это решение является безотзывным. Метод считается корректным при выполнении, если он не вызывает сбоя. Протокол консенсуса, допускающий сбои остановки, должен удовлетворять следующим свойствам. [1]

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

вариации определения целостности В зависимости от применения могут быть уместны . Например, более слабый [ нужны дальнейшие объяснения ] тип целостности будет заключаться в том, чтобы значение решения равнялось значению, предложенному каким-то правильным процессом – не обязательно всеми из них. [1] В литературе также существует условие, известное как достоверность , которое относится к свойству, согласно которому сообщение, отправленное процессом, должно быть доставлено. [1]

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

При оценке производительности консенсусных протоколов интерес представляют два фактора: время работы и сложность сообщения . Время выполнения указывается в нотации Big O в виде количества раундов обмена сообщениями в зависимости от некоторых входных параметров (обычно количества процессов и/или размера входного домена). Сложность сообщения относится к объему трафика сообщений, генерируемого протоколом. Другие факторы могут включать использование памяти и размер сообщений.

Модели вычислений

[ редактировать ]

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

Каналы связи с прямой или передаваемой аутентификацией

[ редактировать ]

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

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

Вклады и результаты консенсуса

[ редактировать ]

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

Особый случай проблемы консенсуса с одним значением, называемый двоичным консенсусом , ограничивает входной и, следовательно, выходной домен одной двоичной цифрой {0,1}. Хотя протоколы двоичного консенсуса сами по себе не очень полезны, они часто полезны в качестве строительных блоков в протоколах более общего консенсуса, особенно для асинхронного консенсуса.

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

Крах и византийские неудачи

[ редактировать ]

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

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

Более сильная версия консенсуса, допускающего византийские неудачи, достигается за счет усиления ограничения целостности:

Честность
Если правильный процесс решает , затем должно быть, было предложено каким-то правильным процессом.

Асинхронные и синхронные системы

[ редактировать ]

Проблема консенсуса может рассматриваться в случае асинхронных или синхронных систем. Хотя коммуникации в реальном мире часто по своей сути асинхронны, более практично и зачастую проще моделировать синхронные системы. [4] учитывая, что асинхронные системы, естественно, связаны с большим количеством проблем, чем синхронные.

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

Результат невозможности FLP для асинхронного детерминированного консенсуса

[ редактировать ]

В полностью асинхронной распределенной системе передачи сообщений, в которой по крайней мере один процесс может произойти сбой , 1985 года доказали в знаменитом результате невозможности FLP Фишер, Линч и Патерсон , что детерминированный алгоритм достижения консенсуса невозможен. [5] Этот результат невозможности вытекает из сценариев планирования наихудшего случая, которые вряд ли возникнут на практике, за исключением состязательных ситуаций, таких как интеллектуальный злоумышленник типа «отказ в обслуживании» в сети. В большинстве нормальных ситуаций планирование процессов имеет определенную степень естественной случайности. [4]

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

Алгоритмы рандомизированного консенсуса могут обойти результат невозможности FLP, обеспечивая как безопасность, так и жизнеспособность с подавляющей вероятностью, даже при наихудших сценариях планирования, таких как интеллектуальный злоумышленник типа «отказ в обслуживании» в сети. [6]

Разрешенный и неразрешенный консенсус

[ редактировать ]

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

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

Эквивалентность проблем соглашения

[ редактировать ]

Представляют интерес три проблемы соглашения.

Прекращение надежного вещания

[ редактировать ]

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

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

Это также известно как «Проблема генерала».

Консенсус

[ редактировать ]

Формальные требования к протоколу консенсуса могут включать:

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

Слабая интерактивная согласованность

[ редактировать ]

Для n процессов в частично синхронной системе (система чередует хорошие и плохие периоды синхронности) каждый процесс выбирает личное значение. Процессы взаимодействуют друг с другом по раундам, чтобы определить общественную ценность и создатьвектор консенсуса со следующими требованиями: [7]

  1. если правильный процесс отправляет , то все корректные процессы получают либо или ничего (свойство целостности)
  2. все сообщения, отправленные в раунде правильным процессом, принимаются в одном раунде всеми правильными процессами (свойство согласованности).

Можно показать, что варианты этих задач эквивалентны в том смысле, что решение проблемы в модели одного типа может быть решением другой проблемы в модели другого типа. Например, решение слабой византийской общей проблемы в модели синхронной передачи сообщений с проверкой подлинности приводит к решению слабой интерактивной согласованности. [8] Алгоритм интерактивной согласованности может решить проблему консенсуса, заставляя каждый процесс выбирать значение большинства в своем векторе консенсуса в качестве значения консенсуса. [9]

Результаты разрешимости некоторых задач согласования

[ редактировать ]

Существует t-устойчивый анонимный синхронный протокол, который решает проблему византийских генералов . [10] [11] если и дело о слабых византийских генералах [8] где это количество неудач и это количество процессов.

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

В полностью асинхронной системе не существует консенсусного решения, которое могло бы выдержать один или несколько сбоев, даже если требуется только свойство нетривиальности. [5] Этот результат иногда называют доказательством невозможности FLP, названным в честь авторов Майкла Дж. Фишера , Нэнси Линч и Майка Патерсона , которые были удостоены премии Дейкстры за эту значительную работу. Результат FLP был механически проверен и справедлив даже при предположениях о справедливости . [13] Однако FLP не утверждает, что консенсус никогда не может быть достигнут: просто, согласно предположениям модели, ни один алгоритм не может всегда достичь консенсуса за ограниченное время. На практике это маловероятно.

Некоторые протоколы консенсуса

[ редактировать ]

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

Примером бинарного консенсусного протокола с полиномиальным временем, который допускает византийские сбои, является алгоритм Phase King Гарая и Бермана. [14] Алгоритм решает проблему консенсуса в модели синхронной передачи сообщений с n процессами и до f сбоями, при условии n > 4 f .В алгоритме фазового короля имеется f + 1 фаз по 2 раунда на фазу.Каждый процесс отслеживает свой предпочтительный выходной сигнал (изначально равный собственному входному значению процесса). На первом этапе каждой фазы каждый процесс передает свое предпочтительное значение всем другим процессам. Затем он получает значения от всех процессов и определяет, какое значение является наибольшим, и его количество. Во втором раунде фазы процесс, идентификатор которого соответствует текущему номеру фазы, назначается королем фазы. Король передает значение большинства, которое он наблюдал в первом раунде, и служит тай-брейком. Затем каждый процесс обновляет свое предпочтительное значение следующим образом. Если количество значений большинства, наблюдаемых в первом раунде процесса, больше, чем n /2 + f , процесс меняет свое предпочтение на это значение большинства; в противном случае используется значение короля фазы. В конце На этапе f + 1 процессы выдают свои предпочтительные значения.

Google реализовал распределенную библиотеку службы блокировки под названием Chubby . [15] Chubby хранит информацию о блокировках в небольших файлах, которые хранятся в реплицируемой базе данных, чтобы обеспечить высокую доступность в случае сбоев. База данных реализована поверх отказоустойчивого уровня журнала, основанного на алгоритме консенсуса Paxos . В этой схеме клиенты Chubby связываются с мастером Paxos для доступа/обновления реплицированного журнала; т.е. чтение/запись в файлы. [16]

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

Другой хорошо известный подход называется алгоритмами типа MSR, которые широко используются от информатики до теории управления. [17] [18] [19]

Источник Синхронность Аутентификация Порог Раунды Примечания
Пиз-Шостак-Лэмпорт [10] синхронный Оральный полное общение
Пиз-Шостак-Лэмпорт [10] синхронный Написано полное общение
Бен-Ор [20] Асинхронный Оральный
(ожидал)
ожидал раунды, когда
Долев и др. [21] синхронный Оральный полное общение
Долев-Стронг [2] синхронный Написано полное общение
Долев-Стронг [2] синхронный Написано полное общение
Фельдман-Микали [22] синхронный Оральный
(ожидал)
Кат-Ку [23] синхронный Написано
(ожидал)
Требуется инфраструктура открытых ключей (PKI)
ПБФТ [24] Асинхронный (безопасность)
Синхронный (живость)
Оральный
Медоед [25] Асинхронный Оральный
(ожидал)
за передачу сообщения - требует шифрования с открытым ключом
Авраам и др. [26] синхронный Написано
Византийское соглашение стало тривиальным [27] [28] синхронный Подписи
(ожидал)
Требуются цифровые подписи

Несанкционированные протоколы консенсуса

[ редактировать ]

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

Другие криптовалюты (например, Ethereum , NEO, STRATIS, ...) используют доказательство доли , при котором узлы соревнуются за добавление блоков и получение соответствующих вознаграждений пропорционально ставке или существующей криптовалюте, выделенной и заблокированной или поставленной на некоторый период времени. Одним из преимуществ «доказательства доли» перед системой «доказательства работы» является высокое потребление энергии, требуемое последней. Например, майнинг биткойнов (2018 г.), по оценкам, потребляет невозобновляемые источники энергии в количестве, аналогичном целым странам Чехии или Иордании, в то время как общее потребление энергии Ethereum, крупнейшей сети с доказательством доли, находится чуть ниже это 205 средних домохозяйств США. [29] [30] [31]

Некоторые криптовалюты, такие как Ripple, используют систему проверки узлов для проверки реестра.Эта система, используемая Ripple, называемая алгоритмом консенсуса протокола Ripple (RPCA), работает в раундах:

Шаг 1: каждый сервер составляет список действительных транзакций-кандидатов;
Шаг 2: каждый сервер объединяет всех кандидатов из своего списка уникальных узлов (UNL) и голосует за их достоверность;
Шаг 3: транзакции, прошедшие минимальный порог, передаются на следующий раунд;
Шаг 4: для финального раунда требуется согласие 80%. [32]

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

В отличие от вышеупомянутых правил участия без разрешения, каждое из которых вознаграждает участников пропорционально сумме инвестиций в какое-либо действие или ресурс, протоколы доказательства личности направлены на то, чтобы предоставить каждому реальному участнику-человеку ровно одну единицу голоса в рамках консенсуса без разрешения, независимо от экономических инвестиций. . [33] [34] Предлагаемые подходы к достижению единоличного распределения полномочий для подтверждения личности включают в себя физические партии под псевдонимами, [35] социальные сети, [36] псевдонимные удостоверения личности, выданные правительством, [37] и биометрия. [38]

Консенсусный номер

[ редактировать ]

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

Консенсусное число параллельного объекта определяется как максимальное количество процессов в системе, которые могут достичь консенсуса по данному объекту в реализации без ожидания. [39] Объекты с согласованным числом может реализовать любой объект с согласованным числом или ниже, но не может реализовать объекты с более высоким числом консенсуса. Консенсусные числа образуют так называемую Херлихи . иерархию объектов синхронизации [40]

Консенсус
число
Объекты
атомарные регистры чтения/записи , мьютекс
проверка и установка , замена , выборка и добавление без ожидания , очередь или стек
... ...
присвоение n-регистров
... ...
сравнение и замена , привязка к загрузке/условное сохранение , [41] перемещение и обмен между памятью, очередь с операцией просмотра, выборка и минусы, липкий байт

Согласно иерархии, регистры чтения/записи не могут обеспечить консенсус даже в двухпроцессной системе. Структуры данных, такие как стеки и очереди, могут обеспечить достижение консенсуса только между двумя процессами. Однако некоторые параллельные объекты являются универсальными (отмечены в таблице знаком ), что означает, что они могут достичь консенсуса между любым количеством процессов и моделировать любые другие объекты посредством последовательности операций. [39]

См. также

[ редактировать ]
  1. ^ Перейти обратно: а б с Джордж Кулурис; Джин Доллимор ; Тим Киндберг (2001), Распределенные системы: концепции и проектирование (3-е изд.), Аддисон-Уэсли, с. 452, ISBN  978-0201-61918-8
  2. ^ Перейти обратно: а б с д Долев, Д.; Стронг, HR (1983). «Аутентифицированные алгоритмы византийского соглашения». SIAM Journal по вычислительной технике . 12 (4): 656–666. дои : 10.1137/0212045 .
  3. ^ Гонг, Ли; Линкольн, Патрик; Рашби, Джон (1995). «Византийский договор с аутентификацией» . Надежные вычисления для критически важных приложений . 10 . Архивировано из оригинала 5 января 2020 г. Проверено 28 мая 2019 г.
  4. ^ Перейти обратно: а б Агилера, МК (2010). «Спотыкаясь о консенсусном исследовании: недоразумения и проблемы». Репликация . Конспекты лекций по информатике. Том. 5959. стр. 59–72. дои : 10.1007/978-3-642-11294-2_4 . ISBN  978-3-642-11293-5 .
  5. ^ Перейти обратно: а б Фишер, MJ ; Линч, Северная Каролина ; Патерсон, М.С. (1985). «Невозможность распределенного консенсуса с одним неисправным процессом» (PDF) . Журнал АКМ . 32 (2): 374–382. дои : 10.1145/3149.214121 . S2CID   207660233 . Архивировано (PDF) из оригинала 30 января 2023 г. Проверено 13 ноября 2017 г.
  6. ^ Аспнес, Джеймс (май 1993 г.). «Рандомизированный консенсус, эффективный по времени и пространству» . Журнал алгоритмов . 14 (3): 414–431. дои : 10.1006/jagm.1993.1022 . Архивировано из оригинала 16 февраля 2023 г. Проверено 28 октября 2020 г.
  7. ^ Милошевич, Жарко; Мартин Хаттл; Андре Шипер (2009). «Объединение алгоритмов византийского консенсуса со слабой интерактивной согласованностью» . Принципы распределенных систем . Конспекты лекций по информатике. Том. 5293. стр. 300–314 . CiteSeerX   10.1.1.180.4229 . дои : 10.1007/978-3-642-10877-8_24 . ISBN  978-3-642-10876-1 . {{cite book}}: |journal= игнорируется ( помогите )
  8. ^ Перейти обратно: а б Лэмпорт, Л. (1983). «Проблема слабых византийских генералов» . Журнал АКМ . 30 (3): 668. дои : 10.1145/2402.322398 . S2CID   1574706 .
  9. ^ Фишер, Майкл Дж. «Проблема консенсуса в ненадежных распределенных системах (краткий обзор)» (PDF) . Архивировано из оригинала (PDF) 22 апреля 2014 года . Проверено 21 апреля 2014 г.
  10. ^ Перейти обратно: а б с Лэмпорт, Л. ; Шостак Р.; Пиз, М. (1982). «Проблема византийских генералов» (PDF) . Транзакции ACM в языках и системах программирования . 4 (3): 382–401. CiteSeerX   10.1.1.64.2312 . дои : 10.1145/357172.357176 . S2CID   55899582 . Архивировано (PDF) из оригинала 7 февраля 2017 г. Проверено 29 августа 2015 г.
  11. ^ Лэмпорт, Лесли; Маршалл Пиз; Роберт Шостак (апрель 1980 г.). «Достижение соглашения при наличии ошибок» (PDF) . Журнал АКМ . 27 (2): 228–234. CiteSeerX   10.1.1.68.4044 . дои : 10.1145/322186.322188 . S2CID   6429068 . Архивировано (PDF) из оригинала 28 января 2007 г. Проверено 25 июля 2007 г.
  12. ^ Аттия, Хагит (2004). Распределенные вычисления (2-е изд.). Уайли. стр. 101–103. ISBN  978-0-471-45324-6 .
  13. ^ Биспинг, Бенджамин; и др. (2016), «Механическая проверка конструктивного доказательства FLP», в Бланшетт, Жасмин Кристиан; Мерц, Стефан (ред.), Интерактивное доказательство теорем , Конспекты лекций по информатике, том. 9807, Springer International Publishing, стр. 107–122, номер doi : 10.1007/978-3-319-43144-4_7 , ISBN.  978-3-319-43144-4
  14. ^ Берман, Петр; Гарай, Хуан А. (1993). «Голосование по закрытию: n/4-устойчивый распределенный консенсус за t + 1 раунд». Теория вычислительных систем . 2. 26 : 3–19. дои : 10.1007/BF01187072 . S2CID   6102847 .
  15. ^ Берроуз, М. (2006). Служба блокировки Chubby для слабосвязанных распределенных систем (PDF) . Материалы 7-го симпозиума по проектированию и внедрению операционных систем. Ассоциация USENIX Беркли, Калифорния, США. стр. 335–350. Архивировано (PDF) из оригинала 14 декабря 2009 г. Проверено 28 октября 2014 г.
  16. ^ Тушар, К.; Гриземер, Р.; Редстоун, Дж. (2007). Paxos Made Live – инженерный взгляд (PDF) . Материалы двадцать шестого ежегодного симпозиума ACM по принципам распределенных вычислений . Портленд, Орегон, США: ACM Press Нью-Йорк, Нью-Йорк, США. стр. 398–407. дои : 10.1145/1281100.1281103 . Архивировано из оригинала (PDF) 12 декабря 2014 г. Проверено 6 февраля 2008 г.
  17. ^ ЛеБлан, Хит Дж. (апрель 2013 г.). «Устойчивый асимптотический консенсус в надежных сетях». Журнал IEEE по избранным областям коммуникаций . 31 (4): 766–781. CiteSeerX   10.1.1.310.5354 . дои : 10.1109/JSAC.2013.130413 . S2CID   11287513 .
  18. ^ Дибаджи, С.М. (май 2015 г.). «Консенсус мультиагентных систем второго порядка при наличии локально ограниченных неисправностей». Системы и контрольные письма . 79 : 23–29. doi : 10.1016/j.sysconle.2015.02.005 .
  19. ^ Дибаджи, С.М. (июль 2017 г.). «Отказоустойчивый консенсус сетей агентов второго порядка: правила асинхронного обновления с задержками». Автоматика . 81 : 123–132. arXiv : 1701.03430 . Бибкод : 2017arXiv170103430M . дои : 10.1016/j.automatica.2017.03.008 . S2CID   7467466 .
  20. ^ Бен-Ор, Майкл (1983). «Еще одно преимущество свободного выбора (расширенное резюме): полностью асинхронные протоколы соглашения». Материалы второго ежегодного симпозиума ACM по принципам распределенных вычислений . стр. 27–30. дои : 10.1145/800221.806707 . S2CID   38215511 .
  21. ^ Долев, Дэнни; Фишер, Майкл Дж.; Фаулер, Роб; Линч, Нэнси; Стронг, Х. Рэймонд (1982). «Эффективный алгоритм византийского соглашения без аутентификации» . Информация и контроль . 52 (3): 257–274. дои : 10.1016/S0019-9958(82)90776-8 .
  22. ^ Фельдман, Пешех; Микали, Сильвио (1997). «Оптимальный вероятностный протокол для синхронного византийского соглашения». SIAM Journal по вычислительной технике . 26 (4): 873–933. дои : 10.1137/S0097539790187084 .
  23. ^ Кац, Джонатан; Ку, Чиу-Юэнь (2006). Об ожидаемых протоколах постоянных раундов к Византийскому соглашению . КРИПТО 2006. doi : 10.1007/11818175_27 .
  24. ^ Кастро, Мигель; Лисков, Барбара (1999). «Практическая византийская отказоустойчивость» (PDF) . Материалы третьего симпозиума по проектированию и внедрению операционных систем, Новый Орлеан, США, февраль 1999 г. Архивировано (PDF) из оригинала 4 марта 2018 г. Проверено 28 мая 2019 г.
  25. ^ Миллер, Эндрю; Ся, Ю; Кроман, Кайл; Ши, Элейн ; Песня, Рассвет (октябрь 2016 г.). «Мёд протоколов BFT» (PDF) . CCS '16: Материалы конференции ACM SIGSAC 2016 г. по компьютерной и коммуникационной безопасности . стр. 31–42. дои : 10.1145/2976749.2978399 . Архивировано (PDF) из оригинала 3 июня 2023 г. Проверено 4 июля 2023 г.
  26. ^ Авраам, Иттай; Девадас, Шринивас; Долев, Дэнни; Наяк, Картик; Рен, Линг (11 сентября 2017 г.). «Эффективный синхронный византийский консенсус» (PDF) . Архив электронной печати по криптологии . Бумага 2017/307. Архивировано (PDF) оригинала 4 июля 2023 г. Проверено 4 июля 2023 г.
  27. ^ Микали, Сильвио (19 марта 2018 г.). «Византийское соглашение стало тривиальным» (PDF) . Кембридж, Массачусетс: CSAIL, MIT. Архивировано (PDF) из оригинала 7 декабря 2022 г. Проверено 28 мая 2019 г.
  28. ^ Чен, Цзин; Микали, Сильвио (2016). «АЛЬГОРАНД». arXiv : 1607.01341v9 [ cs.CR ].
  29. ^ Ирфан, Умайр (18 июня 2019 г.). «Биткойн — это пожиратель энергии. Откуда берется все это электричество?» . Вокс . Архивировано из оригинала 16 февраля 2023 года . Проверено 28 августа 2019 г.
  30. ^ «Слияние — последствия для потребления электроэнергии и углеродного следа сети Ethereum» . 7 сентября 2022 года. Архивировано из оригинала 5 сентября 2023 года . Проверено 5 сентября 2023 г.
  31. ^ «Потребление электроэнергии на душу населения в мире в 2022 году по выбранным странам» . Архивировано из оригинала 5 сентября 2023 г. Проверено 5 сентября 2023 г.
  32. ^ Шварц, Дэвид; Янгс, Ной; Бритто, Артур (2014). «Алгоритм консенсуса протокола Ripple» (PDF) . Ripple Labs (проект). Архивировано (PDF) из оригинала 29 августа 2017 г. Проверено 03 июля 2023 г.
  33. ^ Мария Борге; Элефтериос Кокорис-Когиас; Филипп Йованович; Лайнус Гассер; Николя Гайи; Брайан Форд (29 апреля 2017 г.). Доказательство личности: редемократизация неразрешенных криптовалют . Безопасность и конфиденциальность IEEE в блокчейне (IEEE S&B) . дои : 10.1109/EuroSPW.2017.46 . Архивировано из оригинала 12 ноября 2020 года . Проверено 21 декабря 2020 г. .
  34. ^ Дивья Сиддарт; Сергей Ивлиев; Сантьяго Сири; Паула Берман (13 октября 2020 г.). «Кто наблюдает за стражами? Обзор субъективных подходов к сопротивлению Сивиллы в протоколах доказательства личности». arXiv : 2008.05300 [ cs.CR ].
  35. ^ Форд, Брайан; Штраус, Джейкоб (апрель 2008 г.). Офлайн-фонд подотчетных онлайн-псевдонимов . 1-й семинар по системам социальных сетей — SocialNets '08 . стр. 31–36. дои : 10.1145/1435497.1435503 . ISBN  978-1-60558-124-8 . Проверено 28 октября 2020 г.
  36. ^ Галь Шахаф; Эхуд Шапиро; Нимрод Талмон (октябрь 2020 г.). Подлинные личные идентификаторы и взаимные поручительства для роста сообщества, устойчивого к Сибилле . Международная конференция по социальной информатике . arXiv : 1904.09630 . дои : 10.1007/978-3-030-60975-7_24 .
  37. ^ Дипак Марам; Харджаслин Малваи; Фань Чжан; Нерла Жан-Луи; Александр Фролов; Тайлер Келл; Тайрон Лоббан; Кристин Мой; Ари Джулс; Эндрю Миллер (28 сентября 2020 г.). «CanDID: децентрализованная идентичность Can-Do с совместимостью с предыдущими версиями, устойчивостью к Сивилле и подотчетностью» (PDF) . Архивировано (PDF) из оригинала 9 октября 2022 года . Проверено 28 октября 2020 г.
  38. ^ Мохаммад-Джавад Хаджиалихани; Мохаммад-Махди Джаханара (20 июня 2018 г.). «UniqueID: децентрализованное доказательство уникальности человека». arXiv : 1806.07583 [ cs.CR ].
  39. ^ Перейти обратно: а б Херлихи, Морис (январь 1991 г.). «Синхронизация без ожидания» (PDF) . Транзакции ACM в языках и системах программирования . 11 (1): 124–149. дои : 10.1145/114005.102808 . S2CID   2181446 . Архивировано (PDF) из оригинала 5 июня 2011 года . Проверено 19 декабря 2011 г.
  40. ^ Имбс, Дэмиен; Рейналь, Мишель (25 июля 2010 г.). «Мультипликативная сила консенсусных чисел» (PDF) . Материалы 29-го симпозиума ACM SIGACT-SIGOPS по принципам распределенных вычислений . Ассоциация вычислительной техники. стр. 26–35. дои : 10.1145/1835698.1835705 . ISBN  978-1-60558-888-9 . S2CID   3179361 . Архивировано (PDF) из оригинала 27 января 2022 года . Проверено 22 апреля 2021 г.
  41. ^ Фич, Вера; Хендлер, Дэнни; Шавит, Нир (25 июля 2004 г.). «О присущей примитивам условной синхронизации слабости». Материалы двадцать третьего ежегодного симпозиума ACM по принципам распределенных вычислений . Ассоциация вычислительной техники. стр. 80–87. CiteSeerX   10.1.1.96.9340 . дои : 10.1145/1011767.1011780 . ISBN  1-58113-802-4 . S2CID   9313205 .

Дальнейшее чтение

[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: d6ea54184743af964f2ad8718c59af20__1721375340
URL1:https://arc.ask3.ru/arc/aa/d6/20/d6ea54184743af964f2ad8718c59af20.html
Заголовок, (Title) документа по адресу, URL1:
Consensus (computer science) - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)