В настоящее время (по состоянию на 25 сентября 2022 г.) рабочий узел потребляет около 2,5 ГБ ОЗУ и практически не потребляет ЦП (<1%), поэтому подойдет любая приличная конфигурация оборудования (если ЦП 64-битовый). Но при синхронизации, а иногда и при усложнении структуры DAG, потребление оперативной памяти вырастает как минимум до 8 ГБ. Также мощность процессора существенно влияет на время начальной синхронизации. Поэтому рекомендуется иметь 8 ГБ свободной оперативной памяти ( она требуется для синхронизации с нуля) и пару свободных ядер ЦП для запуска узла.
В нормальных условиях только что синхронизированный узел занимает около 4 ГБ дискового пространства, но это может быть больше в зависимости от структуры DAG, иногда до 20 ГБ и даже 45 ГБ (это действительно редкий случай). И это пространство растет примерно на 1 ГБ каждый день, поэтому убедитесь, что на вашем SSD/HDD достаточно свободного места. Скорость диска не имеет значения, так как поток данных Kaspa достаточно медленный (порядка десятков кбит/с). И вы можете в любое время повторно синхронизировать узел с нуля, чтобы сбросить используемое дисковое пространство до ~ 4 ГБ.
Загрузите ZIP-архив предварительно скомпилированных файлов последней версии из официального репозитория. Выберите подходящую версию для вашей ОС: xxx-win64.zip для пользователей Windows, xxx-osx.zip для пользователей Mac, xxx-linux.zip для Linux. Убедитесь, что вы не загружаете релиз тестовой сети (тот, что с постфиксом «Testnet» в названии выпуска), это для тестовой сети разработчиков, а не для основной, которая вам нужна.
Распакуйте загруженный архив в любое удобное для вас место.
В дальнейшем тексте все примеры будут написаны для случая, когда файлы распаковываются в C:\Kaspa\ фолдере. Если вы распакуйте архив в другую папку, замените этот путь в примерах и пояснениях на свой. Также все пояснения даны для Microsoft Windows.
После распаковки в папке будет 5 файлов в фолдере C:\Kaspa\: genkeypair.exe, kaspactl.exe, kaspad.exe, kaspaminer.exe и kaspawallet.exe, тот, который вам нужен, это kaspad.exe. Позже вам также понадобится kaspawallet.exe для создания кошелька, см. соответствующую статью. Не используйте kaspaminer.exe: это ссылочная реализация майнера, есть гораздо более эффективные, см. Майнинг.
Вы можете запустить kaspad.exe прямо здесь и сейчас, но поскольку иногда он может давать сбои, лучше поставить его в бесконечный цикл, создав файл (.bat). Чтобы создать его, щелкните правой кнопкой мыши на C:\Kaspa\ окно папки, выберите "Create->New text document" а затем переименуйте созданный файл, скажем, на kaspad.bat.Убедитесь, что Windows не скрывает от вас расширения файлов, иначе вы получите файл с именемkaspad.bat.txtне зная этого, и это не то, что вам нужно.
Откройте этот файл с помощью Windows Notepad и добавьте в него следующие строки:
:xxx
kaspad.exe --utxoindex
goto xxx
Таким образом, когда узел выходит из строя, он автоматически перезапускается. С этого момента вы можете запустить узел в любое время, дважды щелкнув его kaspad.bat файл. Хотя вы должны прочитать больше, прежде чем делать это.
--utxoindex флаг заставляет kaspad вычислять балансы по адресам и кэшировать их для дальнейшего использования с операциями кошелька. Если вам не нужно проверять баланс и отправлять монеты, а только майнить на ноду, то этот параметр можно не указывать.
Kaspad хранит свои данные (база данных DAG, лог-файлы, конфигурационные файлы, дампы памяти) в %localappdata%\Kaspad фолдере. После первоначальной синхронизации эта папка будет иметь размер около 3 ГБ, а примерно через месяц она вырастет до 30 ГБ.
Если вас это устраивает, ничего не делайте.
Если вы хотите, чтобы эти данные хранились в другом месте (скажем, у вас ограниченное пространство на системном диске), используйте --appdir (или-b ) параметр командной строки вместе с остальными. Например, если вы хотите, чтобы данные хранились в c:\kaspa_data фолдере, ваша командная строка должна выглядеть так kaspad.exe --appdir c:\kaspa_data --utxoindex. Kaspad пока не требует быстрых HDD/SSD, поэтому вы можете легко настроить хранение его файлов на низкоскоростном HDD большого объема.
В настоящее время использование бутстрапа DB почти никогда не оправдано, так как процесс синхронизации с нуля обычно занимает около 30 минут. Но если вы все же чувствуете, что с бутстрапом это закончится раньше (в случае, если у вас очень старый ПК, менее 8 Гб ОЗУ или очень медленное интернет-соединение), вы можете скачать архив базы данных каспада либо с http: //www.kaspadbase.com/ (архивы как для Windows, так и для Linux можно использовать в любой ОС, т.к. структура файлов kaspad кроссплатформенная), либо найти самый новый архив в #datadir_exchange channel сервера Kaspa Discord.
Распакуйте архив, так чтобы его kaspa-mainnet папка попала в %localappdata%\Kaspadпапку вашего ПК или любую другую папку, которую вы выбрали на предыдущем шаге. Если вы никогда раньше не запускали kaspad и не создавали указанную папку, вам придется сначала создать ее вручную.
Если уже есть kaspa-mainnet папку в папке назначения, настоятельно рекомендуется удалить ее заранее, чтобы избежать путаницы файлов из разных запусков kaspad. Движку Kaspad DB такой бардак точно не понравится, и он может зависнуть.
Если вы знаете IP какой-то рабочей ноды в вашей локальной сети и хотите сделать подсказку для kaspad об использовании этой ноды в качестве источника данных, используйте --addpeer <other node's IP address> параметр командной строки вместе с другими.
Если вы хотите, чтобы какая-либо нода была единственным источником данных для вашего kaspad, используйте --connect <other node's IP address> параметр командной строки.
Вы можете увидеть весь набор других доступных параметров вместе с их описаниями и, иногда, значениями по умолчанию, запустив kaspad через команду --help. Чтобы просмотреть более подробную справку по определенной команде, вы можете запустить kaspad <that command> --help.
Дважды щелкните свой kaspad.bat файл. Не запускайте его от имени администратора, в этом случае существует вероятность сбоя из-за неявного изменения рабочего каталога. Запустите его как обычный пользователь.
Вы увидите окно консоли (текстовое) с журналом выполнения kaspad.
Процесс синхронизации обычно состоит из 2 коротких и 3 больших этапов синхронизации: обработка подтверждения точки сокращения (короткая), обработка заголовков, выборка набора UTXO точки обрезки (еще одна короткая), обработка блоков и построение группы обеспечения доступности баз данных. Это для полной синхронизации с нуля; если вы используете DB snapshot, может быть меньше этапов в зависимости от состояния данных снимка по сравнению с фактическим состоянием DAG.
Обработка доказательства точки сокращения включает в себя подэтапы загрузки, проверки и применения доказательства. Обычно это занимает не более пары минут.
После завершения обработки проверки точек обрезки начнется относительно долгий этап обработки заголовков. Вы увидите, что заголовки блоков обрабатываются от 3 дней в прошлом до настаяшего времени. Время обработки заголовков в данный момент (т. е. когда были созданы соответствующие блоки этих заголовков) можно увидеть в последней части каждый "Processed 0 blocks and X headers" строки. Вы также увидите строку "[INF] PROT: IBD: Processed XXX block headers (N%)" за каждый следующий процент от общего завершения этапа.
Этот этап является самым продолжительным и обычно занимает от 20 минут до 2 часов в зависимости от структуры DAG за предыдущие 3 дня и скоростных характеристик вашего устройства для хранения.
Обработав заголовки, нода собирает набор UTXO, который соответствует точке сокращения. Этот этап обозначен строкой "[INF] PROT: Received XXX UTXO set chunks so far, totaling in YYY UTXOs" и занимает около пары минут, заканчиваясь строкой "[INF] PROT: Finished receiving the UTXO set. Total UTXOs: ZZZ".
Этот этап занимает около минуты.
После получения набора UTXO начнется еще один более длительный этап обработки соответствующих тел блоков, соответствующих ранее полученным заголовкам блоков. Теперь вы увидите, что блок обрабатывается с тех же 3 дней назад до настоящего времени. Время обработки блоков в данный момент (т.е. когда эти блоки были созданы) можно увидеть в последней части каждой "Processed X blocks and 0 headers" строки.
Этот этап обычно занимает от 5 до 20 минут.
Этот этап является последним и тоже коротким, и занимает всего несколько минут. Вы увидите несколько "[INF] PROT: Resolving virtual. Estimated progress: XX%" строк.
Поскольку процесс синхронизации занимает значительное время, а DAG все это время продолжает строиться, то к концу процесса синхронизации будет готов еще один пакет данных, который необходимо обработать, чтобы нода стала полностью синхронизированным. Таким образом, последние 3 этапа повторятся, но на этот раз намного быстрее, так как для обработки этих данных требуется от 20 минут до 2 часов, которые занял процесс синхронизации. А затем, возможно, еще раз, в зависимости от мощности процессора и объема оперативной памяти вашего ПК.
Когда вы увидите поток сообщений "[INF] PROT: Accepted block XXX via relay" в выходных данных окна узла это будет означать, что нода полностью синхронизирована.
Обычно большая часть выводныйх данных узла состоит из строк "Accepted block XXX via relay", но время от времени вы будете видеть такие строки, как "Ignoring duplicate block XXX", "Received a block with missing parents, adding to orphan pool: XXX", "Unorphaned block XXX", "Block XXX has X missing ancestors. Adding them to the invs queue" и еще раз "IDB", "Resolving virtual" и "IDB finished successfully". Все это является нормальным способом работы узла и основано на распределенной природе DAG, когда данные иногда поступают в неожиданном порядке, но узел должен об этом позаботиться.
Вот хороший пример однострочника от пользователя Discord @supertypo:
wget https://github.com/kaspanet/kaspad/releases/download/v0.12.2/kaspad-v0.12.2-linux.zip -O /tmp/kaspad.zip ; unzip -j /tmp/kaspad.zip bin/kaspad; ./kaspad --utxoindex
Просто не забудьте посетить страницу релизов Kaspa на github, чтобы узнать, какая последняя текущая версия, и заменить v0.12.2/kaspad-v0.12.2-linux.zip подстрока в этой однострочной строке с соответствующим путем к zip-файлу последней версии выпуска для Linux.
Все остальные части процесса установки узла аналогичны Windows, поэтому обратитесь к предыдущей главе, чтобы увидеть подробности.
Образ построен для Linux x86-64.
должен быть установлен Докер.
Для быстрого старта с докером можно использовать уже готовый образ:
docker run --pull always -d --restart unless-stopped -p 16110:16110 -p 16111:16111 --name kaspad supertypo/kaspad:latest
Дополнительная информация о запуске kaspad в докере, включая постоянное хранилище, несколько экземпляров и балансировку нагрузки: https://hub.docker.com/r/supertypo/kaspad
Для сборки узла из исходного кода можно использовать следующий Dockerfile:
FROM golang:1.18.2 as builder
RUN mkdir /app
WORKDIR /app
#RUN git clone --depth 1 --branch v0.12.1-rc7 https://github.com/michaelsutton/kaspad
RUN git clone https://github.com/kaspanet/kaspad
WORKDIR /app/kaspad
RUN go install -ldflags '-linkmode external -w -extldflags "-static"' . ./cmd/...
FROM alpine:latest
COPY --from=builder /go/bin /
EXPOSE 16110
EXPOSE 16111
EXPOSE 8082
CMD sh
Если вы хотите собрать тестовую версию, найдите строку с комментариями, где вы можете указать ветку/тег, который хотите скачать и собрать.
Чтобы создать образ ноды, введите:
docker build -t kaspa .
Чтобы запустить образ kaspa в докере, можно создать файл docker-compose.yml, как показано ниже:
version: '3.5'
services:
kaspad:
image: kaspa
container_name: kaspad
restart: always
volumes:
- ./datadir2:/root/.kaspad/kaspa-mainnet/datadir2
ports:
- "16110:16110"
- "16111:16111"
- "8082:8082"
command: '/kaspad --utxoindex'
Затем запустите контейнер командой:
docker-compose up -d
Если вы планируете заставить майнер и кошелек работать с вашей нодой на том же ПК, на котором запущена нода, вам ничего не нужно делать — нода полностью доступна на локальном хосте для них обоих.
Но если вы хотите иметь доступ к вашему узлу с другого ПК в той же локальной сети (скажем, для того, чтобы заставить отдельную майнинговую установку работать с этим узлом или иметь возможность проверять баланс и отправлять монеты с ноутбука в вашей домашней локальной сети) , затем убедитесь, что вы настроили фаерволл, чтобы разрешить подключение к порту 16110 для kaspad.exe процесс на ПК, на котором запущен узел (или KDX, если вы используете его узел). Этот порт принадлежит так называемому протоколу RPC, который используется как майнером, так и кошельком для связи с узлом.Если вы также хотите, чтобы другие узлы в вашей локальной сети могли активно подключаться к вашему узлу, вы должны разрешить подключения к порту 16111который используется для связи между узлами (как для начальной синхронизации, так и для дальнейшего обмена данными).
Оба эти номера порта установлены по умолчанию и могут быть изменены через --rpclisten localhost:<RPC port number> и --listen localhost:<node-to-node protocol port number> в указанном порядке. В этом случае не забудьте также явно указать свои порты не по умолчанию при настройке параметров командной строки для daemon-а кошелька и майнера.
Если вы также хотите, чтобы упомянутые функции были доступны при подключении к вашему узлу из Интернета, убедитесь, что вы перенаправили эти порты в своем маршрутизаторе (см. его руководство, чтобы узнать, как это сделать). И позвоните своему интернет-провайдеру, чтобы узнать, не находитесь ли вы за его NAT, или, возможно, вам следует в противном случае приобрести услугу «статический белый IP», чтобы гарантировать, что ваш маршрутизатор (и, следовательно, ваш узел) имеет IP-адрес для Интернета, который не будет изменяться со временем (или при каждом перезапуске маршрутизатора, или всякий раз, когда ваш интернет-провайдер хотел бы, чтобы он менялся).
Перенаправление портов не требуется, если вы хотите, чтобы ваш узел видел только другие узлы: он все равно сможет подключаться к другим общедоступным узлам, у которых есть свой открытый порт 16111. Переадресация портов позволяет другим узлам активно подключаться к вашему узлу, что делает ваш узел «общедоступным». С другой стороны, сделать ваш узел общедоступным (порт переадресации16111) увеличивает возможности подключения к сети Kaspa и в целом подходит для этого. Учтите, что порт переадресации 16110 (RPC) позволяет всем подключаться к вашему узлу, чтобы майнить на нем, проверять свой баланс на вашем узле и т. д.
Если что-то пойдет не так, рекомендуется добавить pause команду перед goto xxx строкой в вашем kaspad.bat файлечтобы увидеть выходные данные ноды, так чтобы kaspad.bat содержимое файла выглядели так:
:xxx
kaspad.exe --utxoindex
pause
goto xxx
Таким образом, вы можете сделать скриншот или скопировать текст вывода узла, чтобы обратиться за помощью в Discord's #help-node channel. Но перед этим убедитесь, что вы прочитали и сделали следующее: обычно, когда узел выходит из строя, он сразу же успешно перезапускается (если вы используете файл .bat), а затем продолжает работать. Если это не так, то вы должны сначала перейти к %localappdata%\Kaspad\kaspa-mainnet\datadir2 фолдеру и удалите в нем несколько самых новых файлов и попробуйте запустить ноду еще раз, возможно, стоит повторить это несколько раз. Если не поможет то удалите там все файлы и пересинхронизируйтесь с нуля (чтобы заставить каспада удалить все файлы ДБ вам так же можно использовать доп. --reset-dbпараметр командной строки, но не забудьте удалить этот параметр позже, иначе вы будете синхронизироваться с нуля при каждом перезапуске узла). Если и это не помогает, зайдите в Discord и попросите помощи у волонтеров.