Safety и liveness описывают две разные гарантии распределённой сети. Safety означает, что участники не принимают несовместимые результаты за окончательную историю. Liveness означает, что сеть продолжает продвигаться и допустимые операции в итоге получают возможность быть обработанными. Протокол может сохранить safety, но временно потерять liveness: блоки перестанут финализироваться, хотя конфликтующая история не появится. Поэтому выражение «сеть остановилась» само по себе ещё не говорит, что консенсус нарушен.
Safety: не принять две несовместимые истории
Представьте, что несколько участников пытаются записать платежи в общий журнал. Если две стороны одновременно объявят финальными блоки, в которых одна и та же монета потрачена разными получателями, участники больше не имеют единого состояния. Safety ограничивает именно такой конфликт: при выполнении предпосылок протокола честные узлы не должны подтвердить две несовместимые версии истории как окончательные.
Эта гарантия не означает, что интерфейс всегда мгновенно показывает всем один и тот же последний блок. Пока новые сообщения распространяются по сети, разные узлы могут временно видеть разную вершину цепочки. В сетях с вероятностной финальностью самые свежие блоки могут быть перестроены при реорганизации. В протоколах с отдельным механизмом финализации может существовать разница между новым блоком, оправданной контрольной точкой и уже финализированным участком. Для проверки конкретной операции важно различать receipt и состояние сети, как объяснено в материале о receipt транзакции.
Нарушение safety обычно означает серьёзную проблему: ошибки в реализациях клиентов, компрометацию необходимого порога участников, некорректную криптографию или нарушение модели сети. У некоторых proof-of-stake протоколов двойное голосование является основанием для slashing. У других архитектур экономические или социальные механизмы иные. Нельзя переносить конкретный порог или наказание одного блокчейна на все остальные.
Liveness: сеть должна продолжать работу
Liveness отвечает на другой вопрос: если пользователи отправляют допустимые транзакции, сообщения доходят до участников и протокол сохраняет необходимые условия, сможет ли сеть продолжать создавать блоки или финализировать состояние? Во многих системах ответ зависит от того, онлайн ли достаточное число валидаторов, доступна ли связь и могут ли участники обмениваться голосами. Если нужный порог недоступен, протокол иногда намеренно прекращает финализацию вместо того, чтобы рисковать противоречивыми результатами.
У Ethereum proof of stake контрольные точки получают статусы justified и finalized при наличии квалифицированного большинства голосов. Если голосов недостаточно, новые блоки всё ещё могут появляться, но цепочка не продвигается к обычной финальности. Это пример того, как конструкция сохраняет важное свойство согласованности, жертвуя завершением операции на время сбоя. Точные статусы и продолжительность зависят от механики конкретного протокола, поэтому один только зелёный значок в кошельке не заменяет проверку статуса в сети.
Проблемы liveness могут быть временными и операционными: потеря связи, перегрузка, ошибки клиента, сбой облачной площадки или недоступность RPC. Но последствия для пользователя практические: перевод задерживается, приложение не может получить финальное состояние или вывести актив из контракта. Это отличается от потери средств или переписывания истории. Различие между упорядочиванием и сменой цепочки разобрано в статье о реорганизации и двойной трате.
Как свойства связаны с консенсусом
У протокола есть правила выбора истории и условия, при которых она считается окончательной. Fork-choice помогает участникам выбирать предпочтительную цепь при появлении нескольких кандидатов. Механизм финализации добавляет критерий, после которого откат требует нарушения определённых предпосылок или становится чрезвычайно дорогим. Safety и liveness зависят от сочетания этих алгоритмов, сетевых допущений, состава валидаторов и конкретной реализации клиента, а не от названия «Proof of Stake» или «Proof of Work».
При высокой задержке сети алгоритм может ждать сообщений, чтобы не подтвердить конфликт. При слишком агрессивном продвижении он рискует объявить несовместимые данные. Практические протоколы выбирают баланс с явными условиями: какую долю голосов необходимо получить, что делать при пропуске сообщений, сколько ждать, как восстановиться после длительной остановки. История может быть доступна для чтения, но операция ещё не финализирована; поэтому узлы и обозреватели должны показывать эти состояния раздельно. Подробнее о том, как кошелёк может проверять данные с ограниченным набором информации, читайте в материале про light client.
Пример на платежах
Допустим, пользователь посылает токены продавцу. Liveness нужен, чтобы транзакция прошла через очередь, была включена в блок и получила подтверждение. Safety нужен, чтобы продавец и отправитель не приняли несовместимые ветви за одну окончательную запись, при которой токены одновременно оказались у разных владельцев. До финальности возможна задержка или смена недавнего блока, поэтому биржи и приложения выбирают собственные требования к числу подтверждений и состоянию консенсуса.
Если сеть продолжает выпускать блоки, но финализация стоит, это не равнозначно нормальному подтверждению. Если RPC не отвечает, это может быть проблема посредника, а не самой сети. Если интерфейс показывает ошибку, сама транзакция всё ещё может находиться в mempool или быть включена позже. Вначале проверяйте идентификатор транзакции и статус в обозревателе, а затем уточняйте, какой именно слой недоступен. Руководство по чтению статусов можно дополнить статьёй о проверке перевода по TxID.
Короткая схема диагностики
- Уточните, есть ли новые блоки и меняется ли высота цепочки.
- Проверьте, отмечает ли протокол контрольные точки как финализированные.
- Сверьте данные у другого обозревателя или независимого RPC-узла.
- Посмотрите, относится ли сообщение об ошибке к кошельку, RPC, исполнению или консенсусу.
- Не отправляйте повторный платёж, пока не установлено, что произошло с исходной транзакцией.
Эти шаги не диагностируют безопасность любого блокчейна полностью, но помогают не смешивать остановку обработки с конфликтом финализированной истории. В отчёте о проблеме полезно указывать сеть, время, TxID и то, какие именно статусы наблюдались.
Что важно запомнить
Safety защищает согласованность истории, а liveness – способность системы продвигать новые операции. Иногда протокол временно останавливается именно потому, что он не хочет рисковать safety. Для пользователя это означает, что поступление, включение, подтверждение и финальность – связанные, но разные состояния. Проверяйте их отдельно и учитывайте собственную модель сети, не распространяя гарантии одного протокола на весь рынок.
