Узлы хранения моржей: Слушать, Проверять, Хранить, Подтверждать – Сделано
Жизненный цикл валидатора хранения моржей элегантно прост. В отличие от сложных протоколов консенсуса, требующих постоянной передачи сообщений и координации, валидаторы моржей имеют простой операционный поток с минимальным количеством движущихся частей.
Слушать приходит первым. Валидаторы поддерживают открытые каналы для входящих заявок на фрагменты. Они слушают записи, направленные к ним в соответствии с позицией в сетке. Нет сложного обнаружения — клиенты точно знают, к каким валидаторам обращаться, исходя из детерминированной структуры сетки.
Проверка происходит по получении. Валидатор проверяет, что входящий фрагмент соответствует его ожидаемому обязательству. Он проверяет, что криптографический хеш согласован с ID блоба и параметрами кодирования. Если проверка проходит, фрагмент является подлинным. Если нет, он немедленно отклоняется — дальнейшая обработка не требуется.
Хранить означает постоянное сохранение фрагмента на диске. Валидатор записывает данные в надежное хранилище, обеспечивая долговечность в случае перезагрузок или сбоев диска. Это просто — нет специального механизма консенсуса, нет координации с другими валидаторами, нет сложных структур данных.
Подтверждать завершает цикл. После подтверждения хранения валидатор подписывает сертификат, подтверждающий: "Я получил фрагмент X с обязательством Y и буду хранить его до эпохи Z." Эта подпись является обязательством валидатора, зафиксированным в цепочке, когда клиент объединяет ее в PoA.
Простота задумана. Валидаторам не нужно координироваться, сплетничать или достигать консенсуса. Каждый работает независимо над своими назначенными фрагментами. Протокол работает, несмотря на асинхронность, задержки и частичные сбои, потому что роль каждого валидатора изолирована и проверяема.
