Как алгоритм консенсуса RAFT в Кворуме обеспечивает детерминированное расширение цепочки?

Question

В документах RAFT о кворуме упоминается, что

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

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

Answer 1

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

Репликация плота происходит в два этапа: этап подготовки и этап фиксации. И то, и другое происходит через сообщение Append, которое имеет водяной знак committed.

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

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

Я настоятельно рекомендую поиграть с визуализацией на https://raft.github.io/:

1. Отключить большинство узлов, но оставить активным лидер и еще один узел;
2. запросить значение у лидера;
3. Отключить лидера, включить другие узлы;
4. Тайм-аут одного из только что активированных вами узлов (не одного со значением, которое вы запрашивали).
5. Посмотрите, что произойдет.