Пишу с сыном домашнее задание до одиннадцати. Он вдруг говорит: «А что будет, если компьютер зависнет?», — и меня это озадачило.
Я машинально хотела ответить: «Перезагрузишься, и всё», но потом вдруг вспомнила отрывок из Dusk whitepaper, который я копала в последние дни — там это называют «режимом аварийного реагирования».
В нормальных условиях выпуск блока делается по стандарту: три шага — предложение, проверка, одобрение. Если 2/3 участников кивают, всё проходит. Но если вдруг отваливается или зависает большая часть узлов, и подряд случается 16 неудачных попыток, система автоматически переключается в аварийный режим. Механизм тайм-аута сразу выключается — и оно продолжает работать, пока не появится действительно выпущенный блок. Проще говоря, это не «перезагрузка после зависания», а «сменить способ и тянуть до конца».
Эта штука обычно никого не интересует: в ончейне всё ровно или нет — никому не важно, насколько строгий там консенсус. Но в финансовых сценариях всё иначе: институтам нужно как раз «чтобы даже в экстремальной ситуации нельзя было остановиться», и это куда важнее, чем TPS. Награды за выпуск блока тоже продуманы довольно детально: 80% — тому, кто выпустил блок, 10% — голосующим, и 10% — самому протоколу. Это специально сделано, чтобы защититься от тех, кто нарочно провоцирует провал первых раундов, чтобы попытаться урвать награду.
Такие детали я обычно не расписываю, но чем глубже копаю, тем больше убеждаюсь: проект готов или не готов ясно рассказать, что он будет делать в «самом плохом сценарии», — это ценнее, чем насколько красиво у него оформлена рекламная страница. Сейчас DuskEVM ещё в тестовой сети, и насколько эта схема реально выдерживает экстремальные условия рынка, ещё не прошло большой масштабной проверки.
Сможет ли это взлететь — не знаю. Но проекты, которые смело вывешивают на виду план аварийного реагирования, — я бы хотела присмотреться к ним повнимательнее.
@Dusk $DUSK
#dusk
Я машинально хотела ответить: «Перезагрузишься, и всё», но потом вдруг вспомнила отрывок из Dusk whitepaper, который я копала в последние дни — там это называют «режимом аварийного реагирования».
В нормальных условиях выпуск блока делается по стандарту: три шага — предложение, проверка, одобрение. Если 2/3 участников кивают, всё проходит. Но если вдруг отваливается или зависает большая часть узлов, и подряд случается 16 неудачных попыток, система автоматически переключается в аварийный режим. Механизм тайм-аута сразу выключается — и оно продолжает работать, пока не появится действительно выпущенный блок. Проще говоря, это не «перезагрузка после зависания», а «сменить способ и тянуть до конца».
Эта штука обычно никого не интересует: в ончейне всё ровно или нет — никому не важно, насколько строгий там консенсус. Но в финансовых сценариях всё иначе: институтам нужно как раз «чтобы даже в экстремальной ситуации нельзя было остановиться», и это куда важнее, чем TPS. Награды за выпуск блока тоже продуманы довольно детально: 80% — тому, кто выпустил блок, 10% — голосующим, и 10% — самому протоколу. Это специально сделано, чтобы защититься от тех, кто нарочно провоцирует провал первых раундов, чтобы попытаться урвать награду.
Такие детали я обычно не расписываю, но чем глубже копаю, тем больше убеждаюсь: проект готов или не готов ясно рассказать, что он будет делать в «самом плохом сценарии», — это ценнее, чем насколько красиво у него оформлена рекламная страница. Сейчас DuskEVM ещё в тестовой сети, и насколько эта схема реально выдерживает экстремальные условия рынка, ещё не прошло большой масштабной проверки.
Сможет ли это взлететь — не знаю. Но проекты, которые смело вывешивают на виду план аварийного реагирования, — я бы хотела присмотреться к ним повнимательнее.
@Dusk $DUSK
#dusk