(отредактировано) В дополнение к предыдущему (неполному) ответу может помочь цитата из Практическая византийская устойчивость к ошибкам и упреждающее восстановление . Обратите внимание, что автор утверждает, что фазы Prepare достаточно для упорядочения запросов в одном представлении, но этого недостаточно для упорядочения запросов по изменениям представления, поэтому необходима фаза Commit.
Это гарантирует, что реплики согласовывают общий заказ для запросов в одном представлении.
но недостаточно обеспечить общий порядок запросов при изменениях представления . Реплики могут собирать подготовленные сертификаты в разных представлениях с одинаковым порядковым номером и разными запросами. Фаза фиксации решает эту проблему
следующее.
Запросы клиента должны быть полностью упорядочены и выполняться в том же порядке. Реплики достигают консенсуса в отношении порядка запросов на этапе подготовки, собирая сообщения подготовки по указанному вами размеру кворума, но не выполняют его сразу на этом этапе, поскольку им приходится выполнять один и тот же запрос в том же порядке. (В системе State Replication Machine все конечные автоматы должны определенно выполнять один и тот же запрос в одном и том же порядке, чтобы удовлетворить условие безопасности; порядок выполнения влияет на состояние конечного автомата)
Таким образом, на этапе фиксации они должны достичь консенсуса по времени выполнения, чтобы выполнить один и тот же запрос в одно и то же время для условия безопасности.
После вашего комментария «После того, как реплики получили 2/3, они могут зафиксировать», внутреннее состояние каждого конечного автомата (узла PBFT) будет отличаться, что нарушает условия безопасности. Вот почему фаза фиксации необходима.
Ответ на ваш комментарий;
Вышеописанная ситуация возможна, когда реплики выполняют запрос, как только получают сообщения подготовки по размеру кворума. Я думаю, что важный факт, что PBFT предполагает частичную синхронизацию; сообщения могут быть произвольно задержаны из-за нестабильной скорости сети или злоумышленника, но в конце концов получены. Таким образом, каждая реплика может выполнить сообщение запроса в разные моменты времени, и проиллюстрирована одна примерная ситуация.
Ответ на второй комментарий
Мне кажется, мне нужно уточнить ответ с иллюстрацией скоординированной атаки вредоносных реплик, включая первичные. Скажем, n реплик, где n = 3f + 1 = 100, f = 33 в византийской отказоустойчивой системе. В системе система может допускать количество византийских дефектных реплик. Теперь я привожу контрпример, чтобы ответить на ваш вопрос. Рассмотрим следующую настройку;
Я разделил реплики на три группы;
- G1 = {b1, b2, ..., b33} для византийских дефектных реплик, включая византийские первичные (b1), | G1 | = 33
- G2 = {r1, r2, ..., r33} для правильной группы реплик, | G2 | = 33
- G3 = {r34, r35, ..., r67} для правильной группы реплик, | G3 | = 34
Потому что n = | G1 | + | G2 | + | G3 | = 33 + 33 + 34 = 100, приведенный выше раздел имеет смысл.
И G1 полностью контролируется координированным образом супер-гениальным хакером, который особенно заинтересован в уничтожении протокола.
Теперь я покажу, как указанная выше настройка нарушает условие безопасности, если фаза фиксации исчезает из протокола; (Условие безопасности означает, что состояние G2 и G3 должно быть одинаковым). Для простого описания консенсусное значение упрощается как двоичное значение, а не как запрос с порядковым номером.
- [Pre-Prepare phase]: Primary (b1) отправляет значение 0 в G2 и 1 значение в G3. Эта ситуация не является проблемой, потому что мы предполагаем, что византийский первичный.
[Подготовительная фаза]: теперь реплики в G2 и G3 обмениваются сообщениями с первичного сервера, чтобы проверить, имеют ли они оба одинаковое сообщение. Но на этом этапе реплики из G1 отправляют значение 0 в G2 и отправляют значение 1 в G3. После обмена сообщениями ситуация выглядит следующим образом
а. Реплики в G2 получили следующие результаты; 66 голосов за 0, 34 голоса за 1.
б. Реплики в G3 получили следующие результаты; 33 голоса за 0, 33 + 34 = 67 голосов за 1.
Поскольку размер кворума равен 2f + 1 = 67, реплики в G3 принимают предложенное значение от византийского первичного, который координирует с византийскими репликами, в то время как реплики в G2 - нет.
Таким образом, в системе, хотя система может допускать до 33 византийских неисправных реплик, включая первичные, она, по вашему предположению, сразу дает сбой.