Несколько дней назад я поймал себя на мысли об одном аспекте производительности блокчейна, который редко обсуждают: что происходит, когда сеть больше не может исходить из того, что всё работает нормально?
Большинство проектов легко восхищают, когда валидаторы в сети, сообщения передаются, а блоки производятся ровно так, как ожидается. Сложнее вопрос — что случается, когда внезапно исчезает значительная часть сети.
Раньше я думал, что это просто вопрос ожидания, пока система восстановится. Но после более внимательного изучения Dusk я понял, что наиболее интересная часть — это то, как протокол спроектирован реагировать, когда нормальная работа начинает давать сбои.
Консенсусное устройство Dusk учитывает деградирующее участие. Если заметная доля Provisioners уходит в офлайн или оказывается изолированной, протокол не просто предполагает, что ожидаемый набор валидаторов продолжит работать как обычно. Когда повторяющиеся итерации консенсуса не позволяют достичь требуемого результата, у протокола есть механизмы, позволяющие скорректировать поведение и продолжать обслуживать меняющиеся условия сети.
Эта разница важнее, чем может показаться.
Блокчейн может работать чрезвычайно хорошо в идеальных условиях. Настоящая проверка — способен ли он принимать разумные решения, когда участие снижается, связь становится ненадёжной или невозможно сформировать ожидаемый набор валидаторов.
Но есть ещё один вопрос, который я считаю не менее важным: как часто эти механизмы восстановления проходят проверку в реалистичных условиях?
У протокола может быть хорошо продуманная стратегия отказоустойчивости на бумаге, но реальную уверенность дают реализация, тестирование и наблюдение за тем, как сеть ведёт себя, когда что-то действительно идёт не так.
Вот почему я думаю, что устойчивость блокчейна нельзя измерять только по TPS или времени блоков. Более глубокий тест намного проще:
Когда всё ломается, понимает ли протокол, как реагировать?
@Dusk #dusk $DUSK
$TUT $UAI
Большинство проектов легко восхищают, когда валидаторы в сети, сообщения передаются, а блоки производятся ровно так, как ожидается. Сложнее вопрос — что случается, когда внезапно исчезает значительная часть сети.
Раньше я думал, что это просто вопрос ожидания, пока система восстановится. Но после более внимательного изучения Dusk я понял, что наиболее интересная часть — это то, как протокол спроектирован реагировать, когда нормальная работа начинает давать сбои.
Консенсусное устройство Dusk учитывает деградирующее участие. Если заметная доля Provisioners уходит в офлайн или оказывается изолированной, протокол не просто предполагает, что ожидаемый набор валидаторов продолжит работать как обычно. Когда повторяющиеся итерации консенсуса не позволяют достичь требуемого результата, у протокола есть механизмы, позволяющие скорректировать поведение и продолжать обслуживать меняющиеся условия сети.
Эта разница важнее, чем может показаться.
Блокчейн может работать чрезвычайно хорошо в идеальных условиях. Настоящая проверка — способен ли он принимать разумные решения, когда участие снижается, связь становится ненадёжной или невозможно сформировать ожидаемый набор валидаторов.
Но есть ещё один вопрос, который я считаю не менее важным: как часто эти механизмы восстановления проходят проверку в реалистичных условиях?
У протокола может быть хорошо продуманная стратегия отказоустойчивости на бумаге, но реальную уверенность дают реализация, тестирование и наблюдение за тем, как сеть ведёт себя, когда что-то действительно идёт не так.
Вот почему я думаю, что устойчивость блокчейна нельзя измерять только по TPS или времени блоков. Более глубокий тест намного проще:
Когда всё ломается, понимает ли протокол, как реагировать?
@Dusk #dusk $DUSK
$TUT $UAI
