Сумерки все чаще сталкиваются с проблемами — тем больше я волнуюсь о том, кто сейчас контролирует восстановление сети
Прочитав часть про consensus у Dusk, я понял: обычный механизм — это не то, из-за чего стоит больше всего беспокоиться. Самое интересное начинается тогда, когда сети снова и снова не удаётся набрать quorum.
После 16 неудачных итераций Succinct Attestation переключается в emergency-режим. Таймауты отдельных шагов убираются, и несколько итераций могут открываться одновременно, чтобы повысить шанс найти корректный блок. Если несколько кандидатов одновременно достигают консенсуса, приоритет получает блок с более низким номером итерации.
Эта конструкция помогает сети не застревать только из‑за того, что некоторые provisioner медленные или потеряли соединение. Но она также заставляет меня обратить внимание на другую грань: когда условия сети ухудшаются, восстановление начинает заметнее зависеть от распределения stake.
В крайнем варианте emergency‑блок создаётся только тогда, когда группа provisioner запрашивает его, чтобы он контролировал большинство общего stake сети. А чтобы provisioner мог напрямую участвовать в consensus, ему сейчас нужен минимальный stake — 1.000 DUSK.
Поэтому я смотрю на staking не только как на способ получать вознаграждения. Он ещё и определяет, чья «весомость» растёт в момент, когда системе нужно выйти из аномального состояния.
Я думаю, важнейший тест для Dusk — это не то, насколько гладко сеть работает в течение одного дня. А то, что происходит, когда растёт congestion: некоторые узлы отстают, комитеты постоянно меняются, и при этом сеть восстанавливается так, чтобы полномочия принятия решений не концентрировались слишком сильно в рамках большой группы stake.
Механизм recovery может быть технически очень надёжным.
Но если право спасать сеть всё больше концентрируется по stake, тогда именно децентрализацию нужно измерять самым тщательным образом.
@Dusk $DUSK #dusk
$ONDO $BTC
Прочитав часть про consensus у Dusk, я понял: обычный механизм — это не то, из-за чего стоит больше всего беспокоиться. Самое интересное начинается тогда, когда сети снова и снова не удаётся набрать quorum.
После 16 неудачных итераций Succinct Attestation переключается в emergency-режим. Таймауты отдельных шагов убираются, и несколько итераций могут открываться одновременно, чтобы повысить шанс найти корректный блок. Если несколько кандидатов одновременно достигают консенсуса, приоритет получает блок с более низким номером итерации.
Эта конструкция помогает сети не застревать только из‑за того, что некоторые provisioner медленные или потеряли соединение. Но она также заставляет меня обратить внимание на другую грань: когда условия сети ухудшаются, восстановление начинает заметнее зависеть от распределения stake.
В крайнем варианте emergency‑блок создаётся только тогда, когда группа provisioner запрашивает его, чтобы он контролировал большинство общего stake сети. А чтобы provisioner мог напрямую участвовать в consensus, ему сейчас нужен минимальный stake — 1.000 DUSK.
Поэтому я смотрю на staking не только как на способ получать вознаграждения. Он ещё и определяет, чья «весомость» растёт в момент, когда системе нужно выйти из аномального состояния.
Я думаю, важнейший тест для Dusk — это не то, насколько гладко сеть работает в течение одного дня. А то, что происходит, когда растёт congestion: некоторые узлы отстают, комитеты постоянно меняются, и при этом сеть восстанавливается так, чтобы полномочия принятия решений не концентрировались слишком сильно в рамках большой группы stake.
Механизм recovery может быть технически очень надёжным.
Но если право спасать сеть всё больше концентрируется по stake, тогда именно децентрализацию нужно измерять самым тщательным образом.
@Dusk $DUSK #dusk
$ONDO $BTC
