솔로 채굴을 위해 Kaspa 노드를 설정하는 방법은 무엇입니까? (낮은 지연 시간)

Kaspa 노드 아키텍처 이해

1. Kaspa는 GHOSTDAG 프로토콜로 구동되는 blockDAG 구조를 사용하여 기존 체인 병목 현상 없이 병렬 블록 수용과 높은 처리량을 가능하게 합니다.

2. 전체 노드는 DAG의 모든 활성 분기와 동기화되어야 하며 상당한 I/O 대역폭과 짧은 지연 시간의 스토리지 하위 시스템이 필요합니다.

3. 노드 바이너리 kaspad는 합의, 피어 통신 및 블록 전파를 처리합니다. 응답성은 채굴 실행 가능성에 직접적인 영향을 미칩니다.

4. 단일 체인 헤드 추적 기능을 갖춘 PoW 체인과 달리 Kaspa 노드는 여러 팁을 동시에 유지합니다. 이는 메모리 압박을 증가시키고 피어에 대한 일관된 10ms 미만의 왕복 시간을 요구합니다.

5. 네트워크 토폴로지 인식은 필수입니다. 지리적으로 근접한 피어는 전파 지연을 줄이며, 특히 다음 승인 세트에 포함되기 위해 경쟁할 때 중요합니다.

하드웨어 및 OS 최적화

1. ≥7000MB/s 순차 읽기 및 ≥1200K IOPS 무작위 4K 읽기 기능을 갖춘 NVMe SSD를 사용하여 동기화 및 실시간 팁 업데이트 중에 DAG 통과를 유지합니다.

2. ≥64GB RAM 할당 - Kaspa의 활성 세트 캐시는 네트워크 활동에 따라 선형적으로 증가합니다. 메모리가 부족하면 대기 시간이 80ms 이상 급증하는 디스크 백업 조회가 발생합니다.

3. CPU 주파수 스케일링을 비활성화합니다. taskset -c 0-3 사용하여 거버너를 성능 으로 설정하고 kaspad를 격리된 CPU 코어로 고정합니다.

4. 커널 네트워크 스택 구성: net.core.somaxconn 65535로 늘리고, TCP 타임스탬프를 비활성화하고, tcp_fastopen 활성화하여 핸드셰이크 오버헤드를 줄입니다.

5. 컨테이너 추상화 없이 베어 메탈 Linux(Ubuntu 24.04 LTS 또는 Debian 12)에서 실행합니다. 모든 가상화 계층은 시스템 호출 대기 시간에 측정 가능한 지터를 추가합니다.

전파 지연을 최소화하기 위한 네트워크 구성

1. 채굴 장비와 동일한 데이터 센터 내에 노드를 배포합니다. 이상적으로는 동일한 /24 서브넷에 배치하여 랙 내 대기 시간을 0.2ms 이하로 보장합니다.

2. AS 번호 및 RTT < 5ms로 필터링된 Kaspa 공개 시드 목록의 IP와 함께 --addpeer를 사용하여 12~16개의 신뢰할 수 있는 피어를 수동으로 지정합니다.

3. UPnP 및 NAT-PMP를 비활성화합니다. 대신 TCP와 UDP 모두에서 포트 16111에 대한 정적 포트 전달을 구성하여 검색으로 인한 지연을 제거하세요.

4. --maxpeers=40을 설정하되 사용자 지정 ping 모니터링 스크립트를 통해 ping이 3ms 미만인 피어에 대한 아웃바운드 전용 연결을 적용합니다.

5. ethtool -K eth0 gro off lro off tso off gso off 사용하여 전용 10Gbps 인터페이스를 통해 모든 트래픽을 라우팅하여 패킷 병합 아티팩트를 방지합니다.

광부 통합 및 지연 시간이 중요한 플래그

1. 밀리초당 해시 반복 속도를 최대화하려면 -march=native -O3 -flto 로 컴파일된 kaspaminer v0.3.2+를 사용하십시오.

2. 로컬 호스트를 통해서만 채굴기를 노드에 연결합니다. 루프백 별칭이나 Docker 브리지를 통하지 마십시오. kaspad를 127.0.0.1:16111 에 바인딩하고 --rpcbind=127.0.0.1 시행합니다.

3. --blocktemplatecache를 활성화하여 유효한 템플릿을 사전 생성하고 보관함으로써 새 블록 도착과 채굴기 재시작 사이의 시간을 줄입니다.

4. --miningaddr을 레거시 주소가 아닌 기본 Kaspa 주소로 설정하여 블록 제출 중 즉각적인 스크립트 변환 지연을 방지합니다.

5. curl -o /dev/null -s -w '%{time_starttransfer}\n' http://127.0.0.1:16111/ 사용하여 RPC 대기 시간을 지속적으로 모니터링합니다. 12ms 이상의 판독값을 거부합니다.

자주 묻는 질문

Q: 단독 채굴 성공을 저해하지 않고 별도의 컴퓨터에서 kaspad와 kaspaminer를 실행할 수 있습니까? A: 아니요. 머신 간 RPC는 0.5ms 이상의 기본 대기 시간과 지터를 도입합니다. Kaspa의 현재 난이도 조정 창을 사용하면 경쟁 템플릿 재사용을 위해 밀리초 미만의 조정이 필수적입니다.

Q: 채굴자와 노드 사이에 WireGuard 터널을 사용하면 대기 시간에 큰 영향을 미치나요? 답: 그렇습니다. 커널 공간 WireGuard를 사용하더라도 암호화 오버헤드는 왕복당 ≥0.3ms를 추가하고 차이를 증폭시킵니다. 즉, localhost는 협상할 수 없습니다.

Q: 노드 머신에서 스왑을 완전히 비활성화해도 안전합니까? A: 그렇습니다. 권장됩니다. 스왑 사용은 예측할 수 없는 기간 동안 합의 스레드를 지연시키는 페이지 오류를 유발하여 Kaspa의 엄격한 타이밍 가정을 위반합니다.

Q: --maxpeers를 40 이상으로 늘리면 블록 전파 속도가 향상됩니까? A: 아니요. Kaspa의 GHOSTDAG 팁 선택은 더 적은 수의 고품질 피어로 더 빠르게 수렴됩니다. 과도한 연결은 전파 이점 없이 메시지 팬아웃과 CPU 경합을 증가시킵니다.