클라이언트 간 실행 메트릭 사양
@rjl493456442 님의 원본 제안 문서 및 사양 : 표준화된 이더리움 성능 측정 기준 - HackMD
이 아이디어는 게리가 Geth에 슬로우 블록 로깅을 구현하면서 시작되었습니다. 저는 그 후 이 기능이 아래에 나열된 여러 용도로 매우 유용할 것이라고 생각했고, 게리와 협력하여 이 기능을 표준화하고 비전을 구체화했습니다.
제 생각에는 이것이 가격 재조정 및 ScaleL1 트랙뿐만 아니라 네트워크 과부하 문제(현재 제가 집중하고 있는 부분)에도 도움이 될 수 있을 것 같습니다. 하지만 그보다 훨씬 더 많은 일을 할 수 있다고 생각합니다.
1. 서론 및 동기
이 계획이 존재하는 이유
이더리움의 멀티 클라이언트 철학은 핵심적인 강점이지만, 동시에 다음과 같은 과제를 안겨줍니다. 바로 다양한 구현 방식 간의 성능을 어떻게 비교할 것인가 하는 점입니다.
표준화된 실행 측정 지표는 다음과 같은 방식으로 이 문제를 해결합니다.
- 고객 간 성능 비교 — 공정하고 동일한 조건의 벤치마킹
- 네트워크 상태 모니터링 — 합의 영향을 미치기 전에 실행 병목 현상을 식별합니다.
- 데이터 기반 프로토콜 연구 — 실제 실행 데이터를 사용하여 이더리움 개선 제안(EIP) 제안의 유효성을 검증합니다.
- 이상 탐지 — 비정상적인 블록(높은 가스 사용량, 복잡한 상태 접근 패턴)을 감지합니다.
실제 사례: 이더리움 개선 제안(EIP)-7907 분석
이더리움 개선 제안(EIP)-7907 분석은 표준화된 실행 지표가 왜 중요한지 정확히 보여줍니다.
Geth 메트릭을 사용하여 다음을 측정했습니다.
- 코드 읽기 지연 시간 : 바이트코드 크기에 따라 107ms ~ 904ms
- 호출당 오버헤드 확장 : 5.9µs에서 49.9µs로 증가 (가장 작은 계약에서 가장 큰 계약으로 8.5배 증가)
- 블록 실행 분석 : 코드 읽기, 계정 읽기, 이더리움 가상 머신(EVM) 실행 및 데이터베이스 쓰기를 분리하여 분석
이러한 모든 통찰력 덕분에 훨씬 더 정보에 입각한 결정을 내릴 수 있었습니다. 따라서 ACD 의사 결정 과정이 크게 간소화되었습니다.
2. 핵심 지표
메트릭은 블록 실행 수명 주기를 포괄하는 범주로 구성됩니다.
| 범주 | JSON 경로 | 설명 |
|---|---|---|
| 블록 정보 | block.* | 블록 번호, 해시, 사용된 가스, 거래 횟수 |
| 타이밍 | timing.* | 실행, 유효성 검사, 커밋 및 총 소요 시간(밀리초) |
| 처리량 | throughput.* | Mgas/초 처리 속도 |
| 주별 읽기 | state_reads.* | 계정, 저장소 및 코드 읽기 작업 |
| 주정부가 작성함 | state_writes.* | 계정 및 저장소 변경 사항 |
| 은닉처 | cache.* | 계정, 저장소 및 코드 캐시의 적중률/실패율 |
측정 단위 정의
| 미터법 | 유형 | 설명 |
|---|---|---|
block.number | int64 | 블록 높이 |
block.hash | 끈 | 블록 해시 (0x 접두사) |
block.gas_used | int64 | 총 가스 소비량 |
block.tx_count | int32 | 거래 건수 |
timing.execution_ms | int64 | 거래 실행에 소요되는 시간 |
timing.state_read_ms | int64 | 상태 읽기에 소요된 시간(계정, 저장 슬롯 및 계약 코드) |
timing.state_hash_ms | int64 | 국가 재정비에 소요된 시간 |
timing.total_ms | int64 | 총 블록 처리 시간 |
throughput.mgas_per_sec | 플로트64 | 가스 처리량 (사용된 가스량 / 실행 시간 / 1e6) |
state_reads.accounts | int64 | 계정 데이터 로드(잔액, 논스, 코드 해시) |
state_reads.storage_slots | int64 | 저장 슬롯 읽기 |
state_reads.code | int64 | 계약 바이트코드 읽기 |
state_reads.code_bytes | int64 | 읽은 코드의 총 바이트 수 |
state_writes.accounts | int64 | 계정 상태 업데이트 |
state_writes.storage_slots | int64 | 저장 슬롯 쓰기 |
state_writes.code | int64 | 계약 바이트코드 작성 |
state_writes.code_bytes | int64 | 총 코드 쓰기 바이트 수 |
cache.{type}.hits | int64 | 계정/저장소/코드에 대한 캐시 적중률 |
cache.{type}.misses | int64 | 캐시 미스(필요한 데이터베이스 읽기) |
cache.{type}.hit_rate | 플로트64 | 적중률: (hits / (hits + misses)) * 100.0 |
3. 슬로우 블록 JSON 형식
블록 실행 시간이 설정 가능한 스레스홀드(Threshold) (기본값: 1000ms)을 초과하면 클라이언트는 구조화된 JSON 로그를 출력합니다.
{ "level" : "warn" "msg" : "Slow block" "block" : { "number" : 19234567 "hash" : "0x1234...abcd" "gas_used" : 29500000 "tx_count" : 234 } "timing" : { "execution_ms" : 1250 "state_read_ms" : 320 "state_hash_ms" : 150 "commit_ms" : 75 "total_ms" : 1475 } "throughput" : { "mgas_per_sec" : 23.60 } "state_reads" : { "accounts" : 5420 "storage_slots" : 12340 "code" : 890 "code_bytes" : 456000 } "state_writes" : { "accounts" : 234 "storage_slots" : 1890 } "cache" : { "account" : { "hits" : 4800 , "misses" : 620 , "hit_rate" : 88.60 } "storage" : { "hits" : 10200 , "misses" : 2140 , "hit_rate" : 82.68 } "code" : { "hits" : 870 , "misses" : 20 , "hit_rate" : 97.75 } } }현장 요구사항
| 필드 | 필수의 | 메모 |
|---|---|---|
level , msg |  | "warn" 와 "Slow block" 필수입니다. |
block.* | | 모든 블록 정보 입력란은 필수 입력 사항입니다. |
timing.execution_ms | | 핵심 타이밍 측정항목 |
timing.state_read_ms | | 데이터베이스/캐시에서 상태를 읽는 데 소요된 시간 |
timing.state_hash_ms | | 머클 트라이 재검토에 소요된 시간 |
timing.commit_ms | | 상태를 저장소에 저장하는 데 소요되는 시간 |
timing.total_ms | | 전체 블록 처리 시간 |
throughput.mgas_per_sec | | 데시멀(Decimal) 둘째 자리까지 |
state_reads.* | | 모든 읽기 카운터 |
state_writes.* | | 모든 쓰기 카운터 |
cache.* | | 적중/실패/적중률을 포함하는 중첩 구조 |
4. 이행 현황
5. 추가 개선 사항
보다 세밀한 성과 분석을 위한 중기 목표:
| 개선 | 설명 | 이론적 해석 |
|---|---|---|
| 거래별 지표 | 개별 거래별 접근 시점 및 상태 | 속도 저하를 유발하는 특정 트랜잭션을 식별하십시오. |
| 이더리움 가상 머신(EVM) 오퍼코드 개수 | SLOAD, SSTORE, CALL, CREATE, EXTCODECOPY | 실행 패턴을 이해하고 DoS 공격 벡터를 탐지합니다. |
| 고유 접근 추적 | 고유 계정, 저장 슬롯, 계약 | 상태 접근 다양성과 워킹 세트 크기를 측정합니다. |
| 사전 컴파일 분석 | 사전 컴파일 시간(ecrecover, sha256, modexp) | 비용이 많이 드는 암호화 작업을 식별합니다. |
| 머클화 타이밍 | 계정 트리와 스토리지 트리 재해싱 | 정확한 상태 루트 계산 비용 |
| 메모리/할당 통계 | 최대 메모리 사용량, 블록 당 할당량 | 리소스 계획을 위해 메모리 사용량을 추적합니다. |
| 트라이 깊이 통계 | 트라이 순회 깊이 평균/최대값 | 상태 비대화의 영향을 이해합니다. |
| 병렬 실행 지표 | 스레드 활용률, 경합 통계 | 병렬 이더리움 가상 머신(EVM) 구현의 경우 |
| 목격자 크기 | Verkle/상태 비저장 증인 데이터 크기 | 무국적 고객 준비 |
| 냉간 접근 vs 온간 접근 | 최초 접근과 캐시된 접근을 구분하세요. | 이더리움 개선 제안(EIP)-2929 가스 분석 |
이 글은 단순히 정보를 제공하는 것뿐만 아니라, 여러분의 의견을 수렴하기 위한 것입니다. 팀, 연구원, 그리고 그 외 모든 사람들이 추출하거나 알면 좋을 만한 흥미로운 정보는 무엇인지 알고 싶습니다. 이더리움 클래식(ETC), 고객사에서 수집하기 어려운 내부 데이터 같은 것들이요.
또한, 저희는 이것을 어떻게 활용할 수 있을지 알고 싶습니다. 몇 가지 아이디어가 있으며, 여기에 몇 가지 목표를 더 적어 보았습니다. 하지만 다른 분들은 저희보다 훨씬 더 많은 아이디어를 가지고 계실 거라고 생각합니다.
감사해요.
