Read-ноды и валидаторы
В Snapchain ноды двух видов. Валидаторы договариваются о порядке сообщений и производят блоки. Read-ноды скачивают эти блоки, хранят полное состояние и отдают его через HTTP и gRPC API. casty настраивает read-ноду. Документация Snapchain сравнивает их в разделе node types.
Что даёт read-нода
Заголовок раздела «Что даёт read-нода»- Касты, реакции, подписки, профили и ключи каждого аккаунта, читаемые с вашего собственного диска через
http://127.0.0.1:3381, когда поднят туннель. HTTP API описан в справочнике. - Вход для записей:
POST /v1/submitMessageработает на read-ноде. - Никакого API-ключа: данные берутся с вашего собственного хоста.
Работа такой ноды не приносит вознаграждений: в .env Snapchain должно быть AGREE_NO_REWARDS_FOR_ME=true,
что 1-node.sh пишет за вас.
Чего стоит её работа
Заголовок раздела «Чего стоит её работа»Snapchain просит 16 ГБ RAM, 4 vCPU, 2 ТБ свободного диска и публичный IP. При первом запуске
скачивается снимок в несколько сотен ГБ, затем синхронизируются блоки, вышедшие после него. База данных лежит в
~/snapchain/.rocks; пока восстанавливается снимок, рядом с ней существует .rocks.snapshot, и ему
тоже нужно место.
Порты, по документации Snapchain:
| Порт | Что | Открыт для |
|---|---|---|
| 3381/tcp | HTTP API | только вашего адреса, на хостах, которые арендует casty |
| 3382/udp | gossip с другими нодами (casty открывает и TCP) | всех |
| 3383/tcp | gRPC API | только вашего адреса, на хостах, которые арендует casty |
Grafana (3000) и statsd (8125/udp, 8126/tcp) публикуются только на loopback хоста:
1-node.sh задаёт STATSD_PUBLISH и STATSD_ADMIN_PUBLISH в .env Snapchain равными
127.0.0.1 на любом хосте, где он работает.
Записи проходят, но не хранятся
Заголовок раздела «Записи проходят, но не хранятся»Когда вы отправляете сообщение на read-ноду, она проверяет его, передаёт дальше через gossip и
ничего не хранит. HTTP 200 означает «принято для передачи», а не «в блоке». Если сообщение потеряется
по дороге, его больше нет, и его нужно отправить снова. Документация Snapchain говорит то же самое о
read-нодах: такая нода проверяет сообщение, передаёт его
валидаторам через gossip и не хранит копии, так что сообщение, потерянное по дороге, нужно отправить повторно,
и это вероятнее, когда сеть под большой нагрузкой.
Поэтому casty подтверждает каждую запись, читая её обратно с ноды, пока она не появится как слитая. Он ждёт 20 секунд, отправляет те же байты ещё раз, ждёт ещё 20 и затем останавливается с:
casty: <hash> was accepted but not merged within 40sСообщение может слиться и после этого. Поищите его, прежде чем отправлять снова, поскольку повторный запуск команды собирает новое сообщение.
Удаление старых блоков
Заголовок раздела «Удаление старых блоков»Read-нода по умолчанию хранит каждый блок. 1-node.sh --block-retention <days> включает удаление
старых блоков, которое Snapchain предлагает только на read-нодах. События по умолчанию хранятся 3 дня.