На этой неделе разбираюсь с вопросом надежности сети операторов, потому что в белой книге описано, что Ньютон делает хорошо в обычных условиях, но она менее подробно говорит о том, чего следует ожидать приложениям, когда условия не являются нормальными.
В архитектуру встроена реальная отказоустойчивость. Шлюз обрабатывает маршрутизацию операторов, кэширование и дедупликацию запросов. Механизмы принудительного включения позволяют приложениям отправлять задачи непосредственно в сеть операторов, обходя шлюз целиком, если обнаружена цензура.
Двухфазный дизайн консенсуса означает, что один медленный оператор не блокирует полностью всю оценку: агрегатор выходит сразу, как только подписан достаточно большой объем доли (stake). Это действительно свойства устойчивости (resilience).
Что в белой книге не указано, так это порог отказа. Сколько операторов должно перейти в автономный режим, прежде чем консенсус-механизм Newton больше не сможет обеспечить достижение кворума? Что происходит с приложением, когда кворум не удается достигнуть: таймаут задачи с ошибкой или она будет блокироваться бесконечно? Какое ожидаемое время восстановления, если значительная часть набора операторов испытывает скоординированный простой?
Эти вопросы по-разному важны в зависимости от приложения. Протокол DeFi, которому требуется attestation Newton для каждой передачи, не допускает длительных простоев: если attestation перестают вырабатываться, передачи перестают выполняться. Более редкий сценарий использования, например ограниченный доступ к токенизированному фонду, может терпеть минуты деградации без существенного ущерба. Похоже, что в белой книге не проводится различие между этими случаями и не задаются разные ожидания по доступности для разных категорий сценариев использования.
Механизм принудительного включения (force inclusion) решает вопрос цензуры в конкретном случае, когда шлюз недобросовестно отказывается маршрутизировать задачи. Он не так ясно охватывает сценарий, при котором сами операторы находятся в офлайне, деградируют или просто не могут достигнуть консенсуса в обычных окнах задержек (latency windows).
На самом деле я думаю, что эта «брешь» сейчас важнее на этапе mainnet beta, чем позже. Ранние протоколы-адептеры берут на себя риск ненадежности сети, который не полностью задокументирован. Понимание того, как выглядят режимы отказа, и что ожидается от приложений, когда они происходят, кажется критически важной информацией для любой команды, которая внедряет Newton в производственном (production) контексте.
#newt #Newt #ShareYourThoughts
То, что я всё ещё не проработал, — это вопрос, предназначено ли требование к географическому распределению набора операторов специально для снижения риска коррелированных отказов или оно в основном связано с устойчивостью к цензуре, и нужно ли этим двум целям разное составление набора операторов.