Как морж наказывает ленивые узлы с помощью обнаружения в цепочке
Тонкий режим сбоя преследует децентрализованное хранилище: ленивый валидатор. Этот узел хранит данные правильно, но иногда игнорирует запросы на получение или отвечает медленно. Он не нечестен — просто работает слабо. Тем не менее, ленивые валидаторы ухудшают надежность системы без явного мошенничества.
Традиционные системы испытывают трудности с обнаружением ленивости, потому что отличить её от условий сети сложно. Игнорировал ли валидатор запрос или сеть сбросила пакет? Без предположений о синхронном времени вы не можете сказать. В результате вся система терпимо относится к низкой производительности — надежность всех страдает.
@Walrus 🦭/acc решает это через обнаружение в цепочке. Когда валидатор выбирается для обслуживания блоба, это обязательство записывается в цепочке через Sui. Если валидатор не выполняет запрос на получение в течение определенного окна времени — не из-за задержки сети, а из-за доказуемой недоступности — сбой обнаруживается и фиксируется в цепочке. Экономические штрафы следуют автоматически.
Это создает мощные стимулы.
Ленивый валидатор сталкивается с реальными экономическими последствиями. Он не может укрыться за условиями сети или заявить о неизбежности. Запись в цепочке показывает, выполнил ли он свои обязанности. Честные валидаторы, работающие в условиях ухудшенной сети, защищены — они могут доказать, что хранили данные, и задержка сети не считается против них.
Это различие имеет значение: морж не наказывает условия сети, он наказывает отказ от обслуживания. Валидаторы должны быть надежно доступны, а не просто правильно хранить данные. Это поднимает надежность системы с теоретической гарантии до принудительной операционной реальности.
