Прошлой ночью я вернулся к документации Dusk ( @Dusk ) и чем глубже разбирался в консенсусе, тем интереснее становились случаи отказов.
Сначала аварийный режим казался простым резервным вариантом. Но зачем Dusk он, если обычный протокол и так может повторять неудачные итерации? В документации объясняется, что после повторных сбоев протокол может держать открытыми итерации, пока консенсус не будет достигнут. Это заставило меня задуматься, насколько при экстремальных условиях сети приоритет отдается живучести по сравнению с эффективностью.
Затем возник вопрос про форки. Как два кандидата-блока могут прийти к консенсусу в одном и том же раунде? Dusk использует номера итераций и механизм отката для разрешения, но блок с более высокой итерацией всё равно может быть отменён. Для финансовых расчетов такое различие, похоже, имеет принципиальное значение.
Я также заметил структуру вознаграждений. Генераторы получают большую часть награды за блок, а избиратели — отдельную долю. Это стало более понятным, когда я рассмотрел проблему стимулов: что мешает будущему генератору извлечь выгоду, если более ранние итерации не удались?
Система ошибок добавляет ещё один уровень. Почему отделять незначительные сбои от крупных? Приостановка и мягкое slashing выглядят спроектированными иначе, чем жёсткое slashing для серьезного поведения, такого как двойное голосование или недействительные блоки.
И наконец, Moonlight и Phoenix заставили меня по-новому взглянуть на уровень транзакций. Почему нужно поддерживать и аккаунтную прозрачную модель, и модель приватности на базе UTXO?
Создает ли эта двойная конструкция полезную гибкость или же добавляет дополнительную сложность? И по мере роста Dusk где может стать труднее сохранять децентрализацию и безопасность?
@Dusk_Foundation #dusk $DUSK
Сначала аварийный режим казался простым резервным вариантом. Но зачем Dusk он, если обычный протокол и так может повторять неудачные итерации? В документации объясняется, что после повторных сбоев протокол может держать открытыми итерации, пока консенсус не будет достигнут. Это заставило меня задуматься, насколько при экстремальных условиях сети приоритет отдается живучести по сравнению с эффективностью.
Затем возник вопрос про форки. Как два кандидата-блока могут прийти к консенсусу в одном и том же раунде? Dusk использует номера итераций и механизм отката для разрешения, но блок с более высокой итерацией всё равно может быть отменён. Для финансовых расчетов такое различие, похоже, имеет принципиальное значение.
Я также заметил структуру вознаграждений. Генераторы получают большую часть награды за блок, а избиратели — отдельную долю. Это стало более понятным, когда я рассмотрел проблему стимулов: что мешает будущему генератору извлечь выгоду, если более ранние итерации не удались?
Система ошибок добавляет ещё один уровень. Почему отделять незначительные сбои от крупных? Приостановка и мягкое slashing выглядят спроектированными иначе, чем жёсткое slashing для серьезного поведения, такого как двойное голосование или недействительные блоки.
И наконец, Moonlight и Phoenix заставили меня по-новому взглянуть на уровень транзакций. Почему нужно поддерживать и аккаунтную прозрачную модель, и модель приватности на базе UTXO?
Создает ли эта двойная конструкция полезную гибкость или же добавляет дополнительную сложность? И по мере роста Dusk где может стать труднее сохранять децентрализацию и безопасность?
@Dusk_Foundation #dusk $DUSK