Я вернулся к документации и потратил больше времени, чем ожидал, на две области: отказоустойчивость Kadcast и правила окончательности (finality) протокола.
Сначала использование Kadcast DHT Kademlia выглядело довольно прямолинейно. Узлы могут обновлять свои таблицы маршрутизации, когда исчезают пиры, а несколько пиров в каждом бакете дают альтернативные пути, когда один узел выходит из строя. Но меня заинтересовал вопрос: как быстро сеть может адаптироваться, когда узлы постоянно присоединяются, покидают сеть или становятся ненадёжными? И могут ли сильно неравномерное участие создавать более слабые места в структуре маршрутизации?
Модель состояния консенсуса оказалась ещё более интересной.
Блок @Dusk может пройти через стадии accepted, attested, confirmed и, наконец, final. Понять это мне помогло различие между attested-блоком и accepted-блоком. Если предыдущие итерации завершались неудачно, успешный блок может быть принят, но при этом оставаться подлежащим замене. Чем больше неудачных итераций, тем дольше может занять подтверждение (confirmation).
Например, при двух предыдущих неудачных итерациях правила требуют четыре подряд attested или confirmed блока, прежде чем accepted-блок станет confirmed.
Это вызывает у меня вопросы по безопасности и децентрализации. Обеспечивает ли этот механизм достаточную защиту от временной нестабильности сети, не делая окончательность (finality) чрезмерно медленной? Как протокол ведёт себя, когда отказы коррелируют между многими узлами, а не являются изолированными?
Мне также интересно, как динамика таблиц маршрутизации и окончательность консенсуса взаимодействуют во время периодов серьёзных сбоев в сети.
Моё понимание всё ещё развивается, поэтому мне было бы интересно услышать, как другие интерпретируют эти компромиссы.
Какие сценарии отказов, по вашему мнению, Kadcast обрабатывает особенно хорошо? И где можно проверить обоснованность его предположений?
$DUSK #dusk
#dusk $DUSK @Dusk
Сначала использование Kadcast DHT Kademlia выглядело довольно прямолинейно. Узлы могут обновлять свои таблицы маршрутизации, когда исчезают пиры, а несколько пиров в каждом бакете дают альтернативные пути, когда один узел выходит из строя. Но меня заинтересовал вопрос: как быстро сеть может адаптироваться, когда узлы постоянно присоединяются, покидают сеть или становятся ненадёжными? И могут ли сильно неравномерное участие создавать более слабые места в структуре маршрутизации?
Модель состояния консенсуса оказалась ещё более интересной.
Блок @Dusk может пройти через стадии accepted, attested, confirmed и, наконец, final. Понять это мне помогло различие между attested-блоком и accepted-блоком. Если предыдущие итерации завершались неудачно, успешный блок может быть принят, но при этом оставаться подлежащим замене. Чем больше неудачных итераций, тем дольше может занять подтверждение (confirmation).
Например, при двух предыдущих неудачных итерациях правила требуют четыре подряд attested или confirmed блока, прежде чем accepted-блок станет confirmed.
Это вызывает у меня вопросы по безопасности и децентрализации. Обеспечивает ли этот механизм достаточную защиту от временной нестабильности сети, не делая окончательность (finality) чрезмерно медленной? Как протокол ведёт себя, когда отказы коррелируют между многими узлами, а не являются изолированными?
Мне также интересно, как динамика таблиц маршрутизации и окончательность консенсуса взаимодействуют во время периодов серьёзных сбоев в сети.
Моё понимание всё ещё развивается, поэтому мне было бы интересно услышать, как другие интерпретируют эти компромиссы.
Какие сценарии отказов, по вашему мнению, Kadcast обрабатывает особенно хорошо? И где можно проверить обоснованность его предположений?
$DUSK #dusk
#dusk $DUSK @Dusk
