우리는 Ethereum 2.0 테스트넷에서 거의 3,000개의 유효성 검사기를 실행합니다.
편집자 주: 이 기사의 출처는HashQuark 커뮤니티 (ID: HashQuarkPool), 승인을 받아 Odaily에서 재인쇄했습니다.
Prysm은 ETH2.0의 탁월한 구현이며 현재 Medalla 테스트넷에서 가장 많이 실행되는 구현입니다. Prysm은 Beacon Chain Node + Validator Node의 아키텍처를 채택하며 전자는 블록 데이터 동기화를 담당하고 후자는 블록 서명 및 증인을 담당합니다. 유효성 검사기 노드는 동시에 여러 유효성 검사기를 로드할 수 있으므로 로드할 수 있는 유효성 검사기 수와 관련 유효성 검사기 배포 단계를 정성적 및 정량적으로 이해하기 위해 특별히 이 테스트를 준비했습니다.
보조 제목
우리는 Medalla 테스트 네트워크를 복제하고, HashQuark의 자체 ETH2.0 Beacon Chain을 구축하고, 두 번의 테스트를 수행하고, 총 14개의 테스트 사례를 수행하고, 수십만 개의 Validator를 실행했습니다. 소량의 ETH(수십~수백개의 검증자)로 이더리움 스테이킹에 참여하려는 일반 사용자의 경우 4코어 8G 클라우드 서버로 비콘체인 노드와 검증자를 원활하게 구동할 수 있다. 실행 중인 프로세스에서 발생한 기술적 문제는 기술 인력이 아닌 일반 사용자가 해결할 수 없습니다.
수만 명의 유효성 검사기를 실행하는 전문 PoS 마이닝 풀의 경우 매우 높은 블록 속도를 보장하려면 더 높은 구성이 필요합니다. 유효성 검사기 수가 증가함에 따라 블록 비율이 감소합니다.
다음으로 공개 테스트 네트워크인 Medalla에서 다음 테스트를 진행하여 메인 네트워크 환경에 더 가깝게 할 것입니다.
보조 제목
테스트 환경
다음 테스트에 사용되는 클라우드 호스트 배포의 경우 범용 N 모델을 선택하고 CPU 플랫폼은 Intel/Broadwell입니다. 시스템은 Ubuntu 18.04.2 LTS를 사용합니다. geth 버전은 1.9.19-stable이고 Prysm 버전은 v1.0.0-alpha.24입니다.
사전 시도의 첫 번째 단계
보조 제목
테스트 프로그램
가장 기본적인 2개의 ETH1.0 노드 + 2개의 ETH2.0 비콘 체인 노드 + 2개의 유효성 검사기 노드 아키텍처를 사용하여 사설 네트워크를 시작 계획으로 구축합니다. 하루 동안 네트워크가 안정적으로 작동하는 것이 관찰 기간입니다.
보조 제목
아래 표는 테스트에 대한 개요를 제공합니다.
1 번 테이블
보조 제목
테스트 중에 각 인스턴스 서버의 CPU, 메모리, 디스크 IO, 네트워크 대역폭 IO 및 기타 지표를 수집했습니다.
보조 제목
테스트 1에서는 2코어 4G 비콘체인 노드의 메모리가 단계적으로 증가하여 약 6시간 실행 후 메모리 사용량이 100%에 도달하여 메모리 부족 오류로 인해 프로세스가 중지되고 CPU 사용량도 점차 증가함 증가했습니다. 아래 그림과 같이:
그림 1
이미지 설명
그림 2
이후 Beacon Chain Node의 구성을 4코어 8G로 업그레이드했습니다.
이후 서로 다른 지역에 ETH2.0 노드를 배치하여 서로 다른 지역의 네트워크 연결이 각 지표에 더 큰 영향을 미치는지 관찰했으며 실험 결과는 정상이었습니다.
보조 제목
사설망 테스트 상황에 따라 Beacon Chain Node는 4코어 8G 구성을 권장하고, Validator 노드는 2코어 4G 구성으로도 충분하지만 키 파일 가져오기 시 1코어 CPU를 점유하게 되어 CPU 사용률이 100%(아래 그림과 같이 표시됨), 안전을 위해 4C6G를 구성하는 것이 좋습니다.
이미지 설명
또한 이 테스트 단계에서 디스크 I/O 성능 및 외부 네트워크 대역폭에 대한 요구 사항은 매우 낮으며 이는 사설 네트워크 이유 때문일 수 있습니다.구체적인 해당 성능 요구 사항은 공식 ETH2.0에서 테스트해야 합니다. 테스트 네트워크 .
2상 비교 테스트
보조 제목
첫 번째 단계는 주로 서버 리소스에 대한 서로 다른 수의 검증자의 압력을 테스트했으며 검증자의 블록 생성 및 증인도 검증자의 중요한 지표입니다. 이를 위해 비교 테스트를 진행했습니다. 동일한 네트워크에서 비교 테스트를 위해 서로 다른 수의 유효성 검사기가 서로 다른 지역에 배포됩니다.
보조 제목
테스트 중에 CPU, 메모리, 디스크 IO, 네트워크 대역폭 IO, 생성해야 하는 블록 수, 생성된 실제 블록 수, 목격해야 하는 블록 수 및 목격한 실제 블록 수와 같은 지표를 수집합니다. 각 인스턴스 서버.
보조 제목
다음은 테스트 사례입니다.
이미지 설명
표 2
ETH1.0 네트워크는 3개의 2코어 4G 클라우드 서버(홍콩에 2개, 상파울루에 1개)로 구성됩니다. 차단 시간은 15초로 설정됩니다.
우리는 홍콩, 싱가포르, 로스앤젤레스, 프랑크푸르트, 상파울루, 런던에 비콘 체인 노드와 유효성 검사기 노드를 배포했습니다. 각 지역의 Beacon Chain Node와 Validator Node는 인트라넷을 통해 연결됩니다. 구성 및 해당 유효성 검사기 수는 위 그림에 나와 있습니다.
인스턴스 1과 인스턴스 2에는 모두 1k개의 검증자가 있으며, 차이점은 검증자 노드의 구성에 있습니다. 이는 구성이 다른 검증자의 수가 지표에 미치는 영향을 비교하는 데 사용됩니다.
각 지역의 비콘 체인 노드는 다른 노드와 연결됩니다.
보조 제목
테스트넷 매개변수 선택
우리는 먼저 ETH1.0 네트워크에 입금 계약을 배포하고 필요한 수의 유효성 검사기 키를 생성한 후 입금 트랜잭션을 배치로 보냈습니다. Prysm은 수정된 다음 매개변수로 시작합니다.
MinGenesisActiveValidatorCount는 8192로 설정되며 40,000개의 유효성 검사기가 테스트에 포함되어 있으므로 만족합니다.
Eth1FollowDistance는 20으로 설정됩니다. 즉, ETH1.0 네트워크의 예금 계약은 5분 후에 ETH2.0 네트워크에서 모니터링됩니다.
SecondsPerETH1Block은 ETH1.0 네트워크에서 각 블록의 시간 설정과 일치하는 15로 설정됩니다.
실제로 가장 빠른 시작 시간에 설정된 최소 검증자 수를 충족하기 위해 모든 입금 거래를 미리 보냈기 때문에 전체 ETH2.0 네트워크는 1599811207(2020-09-11T16:00:07+08:00)에 시작되었습니다. .
보조 제목
통계 및 테스트 결과
데이터를 쿼리하기 위해 ETH2.0 사설 네트워크에 연결하기 위해 비콘 체인 노드를 추가로 배포했습니다. --slots-per-archive-point=1 매개변수를 추가하여 각 블록의 데이터를 지속적으로 저장하여 쿼리 속도를 높입니다. --rpc-max-page-size=1000 매개변수를 추가하면 매번 더 많은 데이터를 쿼리할 수 있으므로 요청 수가 줄어들고 전체 속도가 빨라집니다.
네트워크가 비교적 안정적인 기간을 선택하여 75 epoch(대략 2020-09-12 00:00:00 +0800)에서 1200 epoch(2020-09-17 00:00:00 +0800)에서 이 세그먼트를 얻으십시오 블록 생성 데이터와 일정 기간 동안 다른 인스턴스의 검증자의 증인 데이터를 분석하고 다음 결과를 얻습니다.
다른 지역의 유효성 검사기 증인은 약간 다릅니다.
이미지 설명
표 3
여기서 우리는 증인 비율을 일정 기간 동안 포함된 증인 수로 나눈 값을 할당된 증인 수로 나눈 값을 정의합니다. 일반적으로 검증인의 수가 증가함에 따라 증인 비율이 감소하는 것을 보는 것은 어렵지 않습니다. 그러나 예제 3에서는 검증자의 수가 2k에 불과하지만 증인 비율은 6k 또는 10k의 증인 비율보다 낮습니다.
범위에 따라 각 검증자의 비율을 나누고 다음 데이터를 얻습니다.
이미지 설명
각 인스턴스의 검증자 수가 다르기 때문에 변환 비율이 더 직관적입니다.
이미지 설명
표 5
이를 위해 인스턴스 3의 로그를 확인한 결과 Beacon Chain Node와 다른 노드와 ETH1.0 사이의 연결이 불안정하여 비정상적인 목격률이 발생한 것으로 추측되며 추후 확인이 필요하다.
보조 제목
이 테스트 라운드에서 우리는 다음 표에서 성능 지수 데이터를 관찰했습니다.
이미지 설명
Beacon Chain Node
표 6
Validator Node
인스턴스 1-5에서 비콘 체인 노드의 CPU 사용량은 5~10% 사이이고 인스턴스 6의 비컨 체인 노드 CPU 사용량은 약 12%입니다. 메모리는 12%에서 17% 사이로 꾸준히 증가하고 있으며 디스크 IO와 대역폭에는 큰 차이가 없습니다.
또한 검증자 키 파일을 생성하기 위해 권장되는 Python 명령줄을 사용합니다.도구, 키를 생성하는 이 도구의 효율성은 상대적으로 낮으며 멀티 코어 시스템에서 1개의 코어만 차지하며 2000개의 키 쌍을 생성하는 데 약 2.5시간이 걸립니다. 한편, Validator Node의 가져오기 키 쌍도 단일 코어 실행이며 2000개의 키 쌍을 가져오는 데 걸리는 시간은 약 40분입니다.
보조 제목
이번 테스트를 통해 우리는 사설망에서 검증인의 증가가 노드에 있는 모든 검증인의 블록 생성 속도에 영향을 미친다는 것을 관찰했습니다. 하루에 약 10 블록 정도 적습니다. 블록 생성 측면에서 우리는 테스트에서 차이를 발견하지 못했습니다. CPU 및 대역폭과 비교할 때 메모리 및 디스크 IO 사용량은 유효성 검사기 수가 증가함에 따라 더 분명하게 증가합니다.
보조 제목
후속 테스트 계획 및 최적화할 단계
이 테스트 라운드에서 다음 측면은 준비 시간이 더 많이 걸립니다.
인증자 키 쌍 생성
보증금 계약 배포
유효성 검사기 노드 가져오기 키 쌍
후속 계획에서는 위의 단계를 최적화하여 테스트 효율성을 향상시킬 계획입니다.
또한, 후속 테스트 계획에서는 서로 다른 지역의 네트워크 간 안정성과 검증인 지표에 미치는 영향을 고려하여 다음과 같은 개선 사항을 고려할 수 있습니다.
동일한 지역에 여러 테스트 인스턴스를 추가하여 차이가 지역으로 인해 발생하는지 비교하십시오.
Beacon Chain Node가 ETH1.0 네트워크에 원활하게 연결되고 영향을 줄이기 위해 여러 ETH1.0 노드를 배포합니다.
같은 지역에 별도의 비교 테스트를 추가하고 검증자 수, 제어 변수를 늘리고 단순히 검증자 수의 영향을 비교하십시오.통계 데이터 측면에서 증인의 거리를 고려하는 등 차원을 더 추가하는 것을 고려하십시오. 이 기사를 참조하십시오.기사.
첫 번째 레벨 제목
시험 문제 요약
거의 4k 검증자로 증가할 때 유효성 검사기 노드는 grpc에서 얻은 메시지 크기 5350532(5M)가 최대값 4194304(4M)를 초과한다고 보고합니다.
이미지 설명
그림 4
해결 방법: 유효성 검사기 노드를 시작할 때 --grpc-max-msg-size 매개 변수를 사용하여 grpc에서 허용하는 메시지 크기를 늘리십시오.
첫 번째 테스트에서 네트워크에 두 개의 비콘 체인 노드만 있는 경우 두 노드 간에 블록을 동기화할 수 없고 어느 노드도 다른 노드를 적합한 피어로 간주하지 않는 문제가 발생하기 쉽습니다. 아래 그림과 같이:
이미지 설명
그림 5
솔루션: 현재 노드의 데이터 재동기화를 삭제하여 문제를 해결하고 있습니다. 테스트 중 비콘 체인 노드 수가 증가함에 따라 이 문제가 더 이상 발생하지 않는 것을 발견했습니다.
불충분한 입금액이 잘못 보고됨issue, 이 보고서의 최신 버전에서 수정되었습니다.
이미지 설명


