При настройке валидатора существует бесчисленное множество способов настройки. Это руководство предназначено для того, чтобы показать один из них, дизайн сторожевого узла. Этот дизайн в основном предназначен для предотвращения DDOS.
сети
Схема основана на AWS, у других облачных провайдеров будут аналогичные решения для разработки решения. Запуск узлов не ограничивается облачными провайдерами, вы также можете запускать узлы на «голых» системах. Архитектура будет одинаковой независимо от того, какую настройку вы решите использовать.
Предложенная сетевая схема аналогична классическому разделению серверных и внешних сервисов в корпоративной среде. «backend» в данном случае — это частная сеть валидатора в дата-центре. Сеть центра обработки данных может включать несколько подсетей, брандмауэров и резервных устройств, которые не показаны на этой схеме. Важным моментом является то, что центр обработки данных обеспечивает прямое подключение к выбранной облачной среде. У Amazon AWS есть «Прямое подключение», а у Google Cloud — «Партнерское взаимодействие». Это выделенное подключение к облачному провайдеру (обычно непосредственно к вашему экземпляру виртуального частного облака в одном из регионов).
Все сторожевые узлы («интерфейс») подключаются к валидатору, используя это приватное соединение. Валидатор не имеет общедоступного IP-адреса для предоставления своих услуг.
Amazon имеет несколько зон доступности в одном регионе. Сторожевые узлы можно установить и в других регионах. В этом случае второй, третий и последующие регионы должны иметь приватное подключение к узлу валидатора. Этого можно достичь с помощью Peering VPC («сетевой Peering VPC» в Google Cloud). В этом случае сторожевые узлы второго, третьего и последующих регионов будут направлены в первый регион и через прямое подключение к ЦОД прибудут к валидатору.
Более устойчивое решение (не подробное на схеме) состоит в том, чтобы иметь несколько прямых подключений к разным регионам из центра обработки данных. Таким образом, Peering VPC не является обязательным, хотя и полезен для сторожевых узлов. Это устраняет риск зависимости от одного региона. Это более затратно.
Локальная конфигурация
Валидатор будет общаться только с предоставленным часовым, узлы-сторожа будут общаться с валидатором через секретное соединение, а с остальной частью сети - через обычное соединение. Сторожевые узлы также могут взаимодействовать друг с другом.
При инициализации узлов есть пять параметров config.toml, которые, возможно, потребуется изменить.
seed_mode:логический. Если вы хотите запустить узел как seed, измените его наtrue.pex:логический. Это включает или выключает реактор однорангового обмена для узла. При , для подключения доступенpex=falseтолько список.persistent_peerspersistent_peers:разделенный запятыми списокnodeID@ip:portзначений, определяющих список одноранговых узлов, которые, как ожидается, всегда будут в сети. Это необходимо при первом запуске, потому что при настройкеpex=falseузел не сможет присоединиться к сети.unconditional_peer_ids:список идентификаторов узлов, разделенных запятыми. Эти узлы будут подключены независимо от ограничений входящих и исходящих узлов. Это полезно, когда сторожевые узлы имеют полные адресные книги.private_peer_ids:список идентификаторов узлов, разделенных запятыми. Эти узлы не будут сплетничать в сети. Это важное поле, так как вы не хотите, чтобы ваш IP-адрес валидатора стал известен в сети.addr_book_strict:логический. По умолчанию для подключения будут рассматриваться узлы с маршрутизируемым адресом. Если этот параметр отключен (false), не-маршрутизируемые IP-адреса, например адреса в частной сети, могут быть добавлены в адресную книгу.double_sign_check_heightint64 высота. Сколько блоков нужно оглянуться назад, чтобы проверить наличие голосов консенсуса узла, прежде чем присоединиться к консенсусу. Если значение не равно нулю, узел будет паниковать при перезапуске, если тот же ключ консенсуса использовался для подписи последних блоков {double_sign_check_height}. Итак, валидаторы должны остановить конечный автомат, дождаться некоторых блоков, а затем перезапустить конечный автомат, чтобы избежать паники.
Конфигурация Validator Node
| Вариант конфигурации | Параметр |
|---|---|
| seed_mode | ЛОЖЬ |
| пекс | ЛОЖЬ |
| постоянные сверстники | список сторожевых узлов |
| частные одноранговые идентификаторы | никто |
| безусловные одноранговые идентификаторы | опционально идентификаторы сторожевого узла |
| адрес-книга-строгий | ЛОЖЬ |
| двойной знак-проверка-высота | 10 |
У ноды валидатора должно быть pex=falseтак, чтобы она не распространялась по всей сети. Постоянные пиры будут вашими сторожевыми узлами. Частные пиры можно оставить пустыми, так как валидатор не пытается скрыть, с кем он общается. Установка безусловных пиров необязательна для валидатора, потому что у них не будет полных адресных книг.
Конфигурация Sentry Node
| Вариант конфигурации | Параметр |
|---|---|
| seed_mode | ЛОЖЬ |
| пекс | истинный |
| постоянные сверстники | узел валидации, опционально другие сторожевые узлы |
| частные одноранговые идентификаторы | идентификатор узла валидатора |
| безусловные одноранговые идентификаторы | идентификатор узла валидатора, опционально идентификаторы сторожевого узла |
| адрес-книга-строгий | ЛОЖЬ |
Сторожевые узлы должны иметь возможность общаться со всей сетью, вот почему pex=true. Постоянные одноранговые узлы сторожевого узла будут валидатором и, возможно, другими сторожевыми узлами. Сторожевые узлы должны убедиться, что они не сплетничают об IP-адресе валидатора, для этого вы должны указать nodeID валидатора как частный узел. Безусловными идентификаторами одноранговых узлов будут идентификатор валидатора и, возможно, другие узлы-сторожа.
Не забудьте защитить брандмауэры вашего узла при их настройке.
Ключи валидатора
Защита ключа консенсуса валидатора — самый важный фактор, который следует учитывать при разработке вашей установки. Ключ, который валидатор получает при создании узла, называется консенсусным ключом. Он должен быть постоянно подключен к сети, чтобы голосовать за блоки. Не рекомендуется просто хранить закрытый ключ в файле json по умолчанию ( priv_validator_key.json). К счастью, Interchain Foundation работала с командой над созданием сервера управления ключами для валидаторов. Вы можете найти документацию о том, как его использовать здесь , он широко используется в производстве. Вы не ограничены в использовании этого инструмента, есть также HSM , рекомендуемого HSM нет.
В настоящее время Tendermint использует ключи Ed25519 , которые широко поддерживаются в секторе безопасности и HSM.
Ссылка
- https://forum.cosmos.network/t/sentry-node-architecture-overview/454
- https://polkachu.com/blogs/holy-trinity-a-system-approach-to-tendermint-based-chain-validation
- https://forum.cosmos.network/t/notionals-validatron-guide/5119
🗣Присоединяйтесь к русскоговорящему сообществу Aura Network: