본문으로 건너뛰기

BOT Chain 노드 구성: 모범 사례

하드웨어 사양​

최적의 성능과 안정성을 보장하려면 BOT Chain의 트랜잭션 처리 및 상태 쿼리에 대한 특정 요구 사항을 기반으로 적절한 노드 유형을 선택하는 것이 중요합니다.

아카이브 및 전체 노드 배포 가이드​

  1. 저장소를 복제하고 디렉터리를 입력합니다.

  2. bash

git clone https://github.com/bl-BOHR/node-deploy.git && cd node-deploy

  1. 실행 권한 부여(Linux에서는 처음에만 필요)

  2. bash

chmod +x BOHR_full_node.sh BOHR_archive_node.sh bin/geth*

  1. 노드 초기화 및 시작

    • 풀 노드:

    • bash

    ./BOHR_full_node.sh reset

    • 아카이브 노드:

    • bash

    ./BOHR_archive_node.sh reset

  2. 로그 보기 노드 로그는.local/fullnode/node/BOHR-node.log에 있습니다. 경량 모드에서 최신 세계 상태에 액세스해야 하는 사용자에게는 빠른 노드가 이상적인 선택입니다. 시스템의 CPU 및 디스크 공간을 덜 요구합니다.

권장 구성​

BOT 메인넷의 전체 역사적 세계 상태에 포괄적으로 액세스하려면 아카이브 노드 배포를 고려하십시오. 자세한 지침은 BOT Chain GitHub 저장소에서 확인할 수 있습니다.(여기에는 저장소에 대한 외부 링크가 필요합니다.)

  • 프로세서: 최소 2코어 CPU.

  • 메모리: 최소 4GB RAM.

  • 스토리지: 최소 용량 128GB의 솔리드 스테이트 드라이브(SSD).

  • 네트워크: 안정적인 고속 인터넷 연결, 최소 1MBps.

아카이브 노드​

최신 세계 상태를 얻고 상태의 유효성을 확인하거나 데이터 증명을 생성하려면 표준 Full Node가 적합합니다.

  • 프로세서: 최소 4코어 CPU.

  • 메모리: 최소 8GB RAM.

  • 스토리지: SSD, 최소 용량 1TB(최적의 성능을 위해서는 NVME SSD가 권장됨)

  • 네트워크: 안정적인 고속 인터넷 연결, 최소 2MBps.

풀 노드​

검증인의 가장 귀중한 자산은 두 개의 키입니다. 하나는 트랜잭션 서명용이고 다른 하나는 블록 서명용입니다.

  • 프로세서: 최소 4코어 CPU.

  • 메모리: 최소 8GB RAM.

  • 스토리지: 최소 용량 1TB의 솔리드 스테이트 드라이브(SSD).

  • 네트워크: 안정적인 고속 인터넷 연결, 최소 2MBps.

피어 구성​

메인넷​

  • 정적 노드를 지정할 필요가 없으며, 코드에 이미 구성된 메인넷에는 부트노드만 필요합니다. 또한 최신 릴리스의 config.toml 파일을 사용해야 합니다.

테스트넷​

  • Testnet still need to configure the StaticNodes manually and hence, the StaticNodes list is contained in the latest release's config.toml.

테스트넷에 피어가 없는 문제 해결​

  • 잘못된 체인 ID, 잘못된 구성 파일/디렉터리와 같은 구성 문제를 확인하세요.

  • 최신 릴리스에 따라 config.toml 파일을 업데이트하십시오.

  • 테스트넷에서는 부트노드를 사용하지 마세요. 필수는 아닙니다.

  • geth/nodes 및 geth/nodekey 파일/디렉터리를 삭제하면 도움이 될 수 있습니다.

  • 스냅샷을 다시 다운로드하고 다시 시도해 보세요.

BOT를 하드웨어 지갑에 보관하세요​

RPC 엔드포인트를 공용 네트워크에 노출하지 마십시오.

해커로부터 전체 노드 RPC 보호​

BOT을(를) 보호하려면 24개의 단어를 누구와도 공유하지 마세요. 그들을 알아야 할 유일한 사람은 당신입니다. 간단히 말해서, HSM은 개인 키를 안전하게 생성, 저장 및 관리하는 데 도움이 되는 저렴하고 성능이 뛰어나며 휴대 가능한 하드웨어입니다. HSM이 올바르게 구성되면 악성 코드 공격과 개인 키의 원격 추출이 훨씬 더 어렵습니다.

계정 개인 키​

BOT을(를) 보호하려면 공식 소스에서 직접 소프트웨어만 다운로드해야 하며 항상 가장 안전한 최신 버전을 사용하고 있는지 확인하세요.

소프트웨어 취약점​

geth를 항상 계속 실행하는 것이 중요합니다. 이를 달성하는 방법에는 여러 가지가 있으며, 우리가 권장하는 가장 간단한 해결책은 geth를 systemd 서비스로 등록하여 시스템 재부팅 및 기타 이벤트 시 자동으로 시작되도록 하는 것입니다.

서버를 데몬으로 실행​

오랜 시간 동안 실행(동기화)되었다가 갑자기 종료된 후 다시 시작하면 아카이브된 노드만 빠르게 재동기화될 것으로 예상됩니다.

백업 노드 설정​

  • 아카이브 모드에서 검증인 노드 실행

  • 노드를 정상적으로 종료합니다.

  • Active monitoring with tools

Steps to Run a Backup Node​

  1. Install the latest version of geth

  2. 빠른 동기화 모드를 사용하여 최신 높이로 동기화하세요. 최신 스냅샷을 다운로드하거나 노드가 완전히 동기화되면 빠른 동기화를 시작할 수 있습니다.

  3. 노드를 정상적으로 종료합니다. kill -HUP $(pgrep geth)

  4. Restart your node.

Why Node will be Offline for a While After Restart? or What will Happen If the Client is Force Killed?​

Steps to reproduce:

이유

  • 일정 시간 동안 동기화된 노드를 실행합니다.

  • 노드를 갑자기 종료합니다(kill -9 또는 시스템 충돌).

  • 노드를 다시 시작하고 1시간 전에 블록 높이에서 재동기화되는 위치를 관찰합니다.

Geth이 충돌하거나 정상적으로 종료되지 않으면 메모리에 보관된 최근 상태가 손실되므로 다시 생성해야 합니다. 상태를 복원하는 데 Geth 시간이 오래 걸립니다.

근본적인 이유는 geth가 주기적으로 상태 트리를 플러시하기 때문입니다. 기간은 config.toml에서 trieTimeout으로 정의됩니다.

geth 콘솔에 명령을 보내면 새로운 블록 채굴을 중단할 수 있습니다.

백업 노드를 검증 노드로 업그레이드하는 방법은 무엇입니까?​

geth Attach ipc:path/to/geth.ipc를 사용하여 유효성 검사기 노드에 연결합니다.

그런 다음 백업 노드가 유효성 검사를 재개하도록 하고,

miner.stop()

다양한 설정이 네트워크의 탄력성을 높이기 때문에 각 검증인 후보는 독립적으로 운영을 실행하는 것이 좋습니다. 검증인이 투자한 금액이 높기 때문에 다양한 DoS 및 DDoS 공격으로부터 검증인을 보호하는 것이 매우 중요합니다. 이 섹션에서는 BOT Chain가 검증자를 위해 채택한 보안 메커니즘에 대해 논의합니다.

miner.start()

Securing the Validators​

검증인은 네트워크가 서비스 거부 공격을 견딜 수 있도록 보장할 책임이 있습니다. 이러한 위험을 완화하기 위해 권장되는 한 가지 방법은 검증인이 소위 센트리 노드 아키텍처에서 네트워크 토폴로지를 신중하게 구성하는 것입니다. 센트리 노드는 신속하게 가동되거나 IP 주소를 변경할 수 있습니다. 센트리 노드에 대한 링크는 개인 IP 공간에 있기 때문에 인터넷 기반 공격은 센트리 노드를 직접 방해할 수 없습니다. 이렇게 하면 검증인이 제안을 차단하고 투표가 항상 네트워크의 나머지 부분에 전달되도록 할 수 있습니다.

Sentry Nodes (DDOS Protection)​

센트리 노드 아키텍처를 설정하려면 아래 지침을 따르세요.

검증인 풀노드 RPC 엔드포인트를 공용 네트워크에 노출하지 마십시오.

  1. 개인 네트워크를 구축하고 검증자 노드와 해당 보초 사이에 신뢰할 수 있는 개인 연결을 설정합니다.

풀노드를 설치하세요

센트리 노드의 콘솔에서 admin.nodeInfo.enode를 실행하십시오. 다음과 비슷한 결과가 나올 것입니다.

  1. 센트리를 검증자 노드의 피어로 설정

!!! 참고: [::]는 localhost(127.0.0.1)로 구문 분석됩니다. 노드가 로컬 네트워크에 있는 경우 각 개별 호스트 시스템을 확인하고 ifconfig를 사용하여 IP를 찾으십시오. 피어가 로컬 네트워크에 없는 경우 enode URL을 구성하려면 외부 IP 주소를 알아야 합니다(서비스 사용). 이 값을 복사하고 첫 번째 노드 실행 콘솔에서 다음을 수행합니다.

enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[::]:30306?discport=0

검증인 노드의 config.toml 파일 업데이트

성공하면 true를 반환하지만 노드가 성공적으로 추가되었다는 의미는 아닙니다.

# make node invisible
NoDiscovery = true
# connect only to sentry
StaticNodes = ["enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[10.1.1.1]:30306"]

확인하려면 admin.peers를 실행하면 방금 추가한 노드의 세부 정보가 표시됩니다.

이렇게 하면 유효성 검사기 노드는 제공된 센트리 노드와만 피어링을 시도합니다.

확인하려면 admin.peers를 실행하면 방금 추가한 노드의 세부 정보가 표시됩니다.

  1. 연결 확인

geth는 다양한 목적으로 여러 TCP 포트를 사용합니다.

방화벽 구성​

geth는 기본적으로 31000에서 리스너(TCP) 포트와 검색(UDP) 포트를 사용합니다.

JSON-RPC를 실행하려면 TCP 포트 8545도 필요합니다. JSON-RPC 포트는 외부에 공개하면 안 됩니다. 그곳에서 관리 작업을 할 수 있기 때문입니다.

If you need to run JSON-RPC, you'll also need TCP port 8545. Note that JSON-RPC port should not be opened to the outside world, because from there you can do admin operations.