Собственная нода Signum хранит копию блокчейна на вашем компьютере и проверяет его целостность. Это не обязательно для просто хранения криптовалюты, но полезно разработчикам, кто строит сервисы на блокчейне, или тем, кто хочет меньше зависеть от публичных серверов. Процесс установки прямолинеен: нужна Java 21, стабильный релиз Signum Node, минимальная настройка конфига — и нода начнёт синхронизацию с сетью.
Прежде всего проверьте техническую базу. Минимум: 64-битная Java 21, 1 vCPU, 1 ГБ RAM, 20 ГБ свободного места на диске и стабильное интернет-соединение на время первой синхронизации. На Linux добавьте 2 ГБ swap. Рекомендуется 2 vCPU, 2 ГБ RAM, 20 ГБ диска и 4 ГБ swap. Проверьте версию Java командой java -version — должна отобразиться версия 21. Скачайте последний стабильный пакет из официального репозитория для вашей ОС, распакуйте его в отдельную папку и скопируйте conf/node-default.properties в conf/node.properties. На Windows запустите signum-node.exe, на других системах используйте java -jar signum-node.jar (добавьте флаг --headless для сервера без графического интерфейса). Для mainnet специальные параметры встроены в версию 3.3.0 и выше, поэтому дополнительная настройка не требуется.
Новичку подходит встроенная SQLite: она включена по умолчанию, не требует отдельной установки сервера БД и рекомендована для локальных нод. MariaDB или PostgreSQL нужны только публичным узлам и сложным сервисам. При первом запуске нода загружает и проверяет весь блокчейн — это может занять время в зависимости от компьютера, диска и качества соединения. Если перезапустить программу, она продолжит работу с того же места; удаление базы данных заставит начать синхронизацию заново.
Проверить готовность ноды легко через API. По адресу http://127.0.0.1:8125/api-doc откроется документация; найдите метод getBlockchainStatus, который возвращает версию, последний блок, общее число блоков, высоту источника синхронизации и флаг isScanning. Когда isScanning равен false, это не означает завершение синхронизации — обязательно сравните высоту и номер последнего блока с официальным Explorer или другой известной синхронизированной нодой. Если значения заметно отстают, узел ещё не догнал сеть или не получает данные от пиров.
Безопасность ноды зависит от правильной работы с портами и конфигурацией. Стандартные порты: 8123 для P2P-соединений между нодами и 8125 для пользовательского HTTP API. По умолчанию API слушает только 127.0.0.1 и разрешает локальные запросы — это хороший выбор. Участие в P2P-сети не означает обязательное открытие API наружу. Никогда не устанавливайте API.Listen = 0.0.0.0 только ради синхронизации. Если внешний доступ к API действительно нужен, отдельно настройте firewall, список API.allowed, DoS-защиту, SSL и администрирование. Главное: не записывайте recovery phrase, приватные ключи или solo-mining passphrase в конфигурацию — это критический риск безопасности.
Опционально в node.cashBackId можно указать account ID, и тогда транзакции, созданные через вашу ноду, будут генерировать 25% кешбэка от комиссии получателю (механика описана в SIP-35). Это не означает полный возврат комиссии и не является просто доходом за включённую ноду. Для первого запуска эту настройку можно пропустить.
Если нода не синхронизируется, начните с базовых проверок: версия Java 21, свободное место на диске, логи запуска (есть ли подключённые пиры и ошибки БД), настройки firewall на исходящие соединения. Убедитесь, что случайно не включили testnet и не перенесли несовместимые параметры из старой конфигурации. После обновления ноды сверяйте свои изменения с новым шаблоном node-default.properties. Финальный чек-лист: 64-битная Java 21 установлена, скачан стабильный официальный релиз, создан отдельный конфиг, для локального старта используется SQLite, API остаётся на localhost (если не нужен внешний доступ), секреты не хранятся в публичном файле, синхронизация завершена (isScanning = false, высота совпадает с сетью).