요약
- 본 연구에서는 실행 처리량과 밸런서(BAL) 크기 간의 절충점이 서로 다른 세 가지 밸런서(BAL) 설계 방식(전체 밸런서(BAL), 배치 I/O 밸런서(BAL), 병렬 I/O 밸런서(BAL) 을 평가합니다.
- 본 연구에서는 오버헤드가 가장 낮은 병렬 I/O 밸런서(BAL) 설계 방식이 전체 밸런서(BAL) 방식의 처리량에 얼마나 근접할 수 있는지 살펴봅니다.
- 병렬 I/O 밸런서(BAL) 전체 밸런서(BAL) 의 약 13.9 GGas/s에 비해 약 10.8 GGas/s의 처리량을 달성하여 전체 밸런서(BAL) 크기의 33%만으로 전체 처리량의 78%를 제공합니다.
블록 레벨 액세스 목록( 밸런서(BAL) )은 블록 실행 중에 접근하는 모든 계정과 스토리지를 실행 후 값과 함께 블록 공간에 명시적으로 인코딩함으로써 병렬 I/O 및 병렬 실행을 포함한 병렬 처리를 가능하게 합니다. 이전 논문 에서 우리는 트랜잭션 후 상태 차이와 블록 읽기 전 키 및 값을 포함하는 전체 밸런서(BAL) 의 병렬 실행 성능을 연구했습니다. 16코어 범용 머신에서 메가 블록 설정으로 약 15 GGas/s의 순수 병렬 실행 처리량을 달성했습니다.
그러나 이 연구는 I/O와 밸런서(BAL) 오버헤드라는 두 가지 주요 제약 조건을 간과하고 있습니다. 사전 준비(prewarming)를 하지 않는 시나리오에서 I/O는 전체 블록 처리 시간의 약 70%를 차지합니다. 밸런서(BAL) 병렬 디스크 읽기를 가능하게 하지만, BAL을 활용한 병렬 I/O의 효율성은 밸런서(BAL) 자체에 얼마나 많은 읽기 정보가 포함되는지에 따라 달라질 수 있습니다. 더 자세한 읽기 힌트는 I/O 병렬성을 향상시킬 수 있지만, 밸런서(BAL) 크기를 증가시켜 네트워크 대역폭과 스토리지 비용에 직접적인 영향을 미칩니다. 결과적으로 밸런서(BAL) 달성 가능한 병렬성과 밸런서(BAL) 크기 사이의 다양한 절충점을 나타내는 여러 설계 변형을 허용합니다. 읽기 힌트의 정밀도에 따라 주요 설계는 전체 밸런서(BAL), 배치 I/O 밸런서(BAL) 및 병렬 I/O 밸런서(BAL) 로 구분됩니다.
| 이름 | 세부 | 병렬 실행 | 병렬 I/O | 밸런서(BAL) 크기(RLP 인코딩)* |
|---|---|---|---|---|
| 전체 밸런서(BAL) | 트랜잭션 후 상태 차이 및 블록 읽기 전 키와 값 | 거래당 | 힌트별 (검증용) | 213kb |
| 배치 I/O 밸런서(BAL) | 거래 후 상태 차이 및 사전 블록 읽기 키 | 거래당 | 힌트당 | 110kb |
| 병렬 I/O 밸런서(BAL) | 거래 후 상태 차이 | 거래당 | 거래당 | 71kb (최저, 전체 밸런서(BAL) 의 33%, 배치 I/O 밸런서(BAL) 의 64%) |
* 23,770,000 ~23,771,999 블록에서 샘플링됨
이상적으로는 밸런서(BAL) 크기를 최소화하면서 처리량을 극대화하는 것이 바람직합니다. 전체 밸런서(BAL) 최고의 성능을 제공하지만, 가장 큰 오버헤드를 발생시키기도 합니다. 따라서 가장 중요한 질문이 제기됩니다. 오버헤드가 가장 낮은 병렬 I/O 밸런서(BAL) 설계가 전체 밸런서(BAL) 의 처리량에 어느 정도까지 근접할 수 있을까요? 이 질문에 대한 답을 찾는 것이 본 연구의 핵심 목표입니다.
이 질문에 답하기 위해, 우리는 다음과 같은 설정으로 I/O 읽기를 통한 상태 로딩을 명시적으로 포함하는 실행 환경을 구축했습니다.
- Reth에서 사용되는 계정, 저장 공간 및 계약 코드용 플랫 데이터베이스
- 대부분의 클라이언트에 이미 구현된 송신자 복구 병렬 처리를 활용하는 사전 복구된 트랜잭션 송신자
- 상태 루트 계산 및 상태 트라이 커밋은 대규모 블록의 경우 비용이 분산될 수 있고 본 연구의 초점이 아니므로 생략합니다.
이러한 설정을 사용하여 다양한 밸런서(BAL) 설계에 따른 트랜잭션별 병렬 실행(병렬 I/O 및 병렬 실행 포함) 벤치마킹을 수행했습니다. 결과에 따르면 병렬 I/O 밸런서(BAL) 메가 블록 설정에서 16코어 일반 머신에서 여전히 약 10.8 GGas/s의 처리량을 달성하며 , 이는 전체 밸런서(BAL) 의 약 13.9 GGas/s와 유사한 수준입니다. 이는 전체 밸런서(BAL) 대비 병렬 I/O 밸런서(BAL) 밸런서(BAL) 크기의 33%만으로 전체 밸런서(BAL) 처리량의 78%를 달성하여 처리량과 밸런서(BAL) 크기 오버헤드 간의 실용적인 균형을 제공함을 보여줍니다 .
이더리움 실행의 I/O 병목 현상
이더리움은 L1 확장을 지속하고 있습니다. 후사카 업그레이드를 통해 가스 한도가 45M에서 60M으로 증가했으며, 글램스터담 업그레이드를 통해 더욱 상향 조정될 것으로 예상됩니다. 저희의 이전 연구에 따르면 밸런서(BAL) 실행 처리량을 10배 이상 향상시킬 수 있어, 더 높은 가스 한도를 위한 견고한 기반을 제공합니다.
이러한 발전에도 불구하고, I/O는 오늘날 블록 처리 파이프라인에서 여전히 주요 병목 현상입니다. 사전 워밍업이 없는 환경에서 I/O는 전체 실행 시간의 약 70%를 차지합니다. Reth를 예로 들면 다음과 같습니다.
- MDBX를 사용한 I/O를 포함한 단일 스레드 실행은 약 350 MGas/s의 속도만 달성합니다.
- 예열을 통해 I/O 오버헤드는 약 20%로 감소하고 처리량은 약 700MGas/s까지 향상됩니다.
예열이 도움이 되기는 하지만, 여전히 상당한 여유 공간이 남아 있습니다. I/O의 근본적인 한계는 순차적인 I/O 접근 패턴에 있습니다. 최신 NVMe SSD는 깊은 I/O 큐(일반적으로 최대 64개)를 지원하지만, 대부분의 이더리움 클라이언트는 여전히 상태 읽기를 순차적으로 수행하여 사용 가능한 I/O 병렬성을 충분히 활용하지 못하고 있습니다.
밸런서(BAL) 병렬 I/O를 활성화하여 이러한 한계를 해결하지만, 그에 따른 비용이 발생합니다. 트랜잭션 후 상태 차이는 병렬 실행에 필수적이며, 이전 연구에서 이를 통해 순차 실행 대비 10배의 속도 향상을 달성할 수 있음을 보여주었습니다. 그러나 읽기 값과 읽기 힌트의 크기를 합치면 상태 차이와 비슷한 수준이 될 수 있으며 , 이러한 추가적인 네트워크 및 스토리지 오버헤드에 비해 성능 향상 효과가 얼마나 되는지는 불분명합니다.
이는 중요한 설계 문제를 제기합니다. 읽기 값이나 읽기 힌트를 포함하지 않고도 거의 최적의 성능을 달성할 수 있다면 밸런서(BAL) 크기를 크게 줄여 처리량을 희생하지 않고 네트워크 및 스토리지 비용을 절감할 수 있습니다. 이 가설을 검증하기 위해 우리는 트랜잭션 후 상태 차이만 포함하고 실행 중에 필요에 따라 상태를 읽는 병렬 I/O 밸런서(BAL) 에 초점을 맞춥니다.
실험 방법론
병렬 I/O 밸런서(BAL) 이 제공하는 궁극적인 성능 한계를 평가하기 위해, 앞서 언급한 관련 없는 부분을 제거하여 단순화된 실행 환경을 구축했습니다. 이를 통해 BAL 기반 병렬 처리의 진정한 상한값을 측정할 수 있습니다.
reth의 고성능 실행 엔진과 RocksDB의 멀티스레드 읽기 기능을 활용하여 reth 클라이언트를 수정하여 실행 종속성(블록, BAL, 최근 256 블록 해시 포함)을 덤프하고, 이더리움 가상 머신(EVM) 실행 엔진으로 REVM을 사용하며, 계정, 코드 및 스토리지 액세스를 위한 RocksDB 기반 상태 공급자를 도입했습니다.
I/O 실행 에뮬레이션을 위한 간소화
- 모든 거래는 발신자 정보가 이미 복구된 상태로 진행됩니다(발신자 정보 복구는 사전에 완벽하게 병렬화될 수 있습니다).
- 실행 후 상태 루트 계산이나 트라이 커밋은 수행되지 않습니다(플랫 상태 커밋만 수행됨). 이러한 비용은 본 연구의 초점과 무관하기 때문입니다.
엔지니어링 작업 및 설치
- Reth 클라이언트를 수정하여 블록, BAL, 최근 256 블록 해시를 포함한 전체 실행 종속성을 덤프할 수 있도록 했습니다.
- Revm에서 계정, 코드 및 스토리지 상태를 로드할 수 있도록 RocksDB 상태 공급자를 추가했습니다.
- Reth의 MDBX 바인딩은 초기에 테스트되었지만 멀티스레딩 환경에서 성능 저하를 보였습니다. 따라서 RocksDB가 채택되었으며, MDBX 데이터베이스를 RocksDB로 변환하는 마이그레이션 도구가 개발되었습니다.
- 병렬 I/O의 경우, 트랜잭션 간 중복 읽기를 방지하기 위해 공유 캐시 계층이 사용됩니다.
- 각 실험 전에 페이지 캐시를 삭제했습니다.
- 병렬 처리 세분성 = 트랜잭션별
- 하드웨어:
- AMD 라이젠 9 5950X (물리적 코어 16개, 하이퍼스레딩 사용 시 32개)
- 128GB RAM
- 7TB RAID-0 NVMe SSD (~4k 블록 기준 랜덤 읽기 IOPS 약 960k, 대역폭 3.7GB/s)
- 데이터셋: 메인넷 블록 2000개( #23770000 –23771999 ).
- 측정 항목: 초당 가스 사용량 = 총 가스 사용량 / I/O 시간을 포함한 실행 시간.
벤치마크 제품군은 여기에서 확인할 수 있습니다. 
GitHub - dajuguan/evm-benchmark
결과
먼저 병렬 I/O 및 병렬 실행 환경에서 다양한 스레드 수를 사용하여 이더리움 메인넷 블록을 평가했습니다. 이때 병렬 I/O 밸런서(BAL)( 블록 가스 제한)을 적용했습니다. 그 결과, 가장 오래 걸리는 트랜잭션이 지배하는 명확한 임계 경로가 나타났습니다. 이를 완화하기 위해 블록 가스 제한을 높여 밸런서(BAL) 사용 시 훨씬 더 많은 병렬 처리를 가능하게 하는 시뮬레이션을 수행했습니다.
16개의 스레드와 1G 가스 블록 사용하는 병렬 I/O 밸런서(BAL) 약 10.8 GGas/s의 처리량을 달성하여 전체 밸런서(BAL) 달성하는 약 13.8 GGas/s의 78% 에 근접합니다. 특히, 이러한 성능은 평균 밸런서(BAL) 크기가 약 71KB에 불과한 상태에서 구현되며, 이는 전체 밸런서(BAL) 에 비해 약 67% 감소한 수치 입니다.
병렬 I/O 및 병렬 실행에서의 임계 경로 분석
실제 속도 향상과 트랜잭션 수준 병렬 처리에 대한 암달의 법칙의 영향을 평가하기 위해, 우리는 트랜잭션별 병렬 실행 실험을 수행하여 가장 오래 실행되는 트랜잭션이 달성 가능한 속도 향상에 미치는 영향을 정량화했습니다.
자세한 결과는 아래와 같습니다(여기서 "가장 긴 트랜잭션 지연 시간"은 각 블록 에서 가장 오래 실행된 트랜잭션의 I/O 시간을 포함한 총 실행 시간입니다).
| 실 | 처리량(MGas/s) | 가장 긴 TX 지연 시간 | 총 소요 시간 |
|---|---|---|---|
| 1 | 740 | 6.85초 | 60.62초 |
| 2 | 1,447 | 6.75초 | 31.00초 |
| 4 | 2,167 | 8.11초 | 20.70초 |
| 8 | 2,994 | 9.02초 | 14.98초 |
| 16 | 3,220 | 8.92초 | 13.93초 |
| 32 | 3,253 | 9.57초 | 13.79초 |
전반적으로 결과는 암달의 법칙을 잘 따릅니다. 스레드 수가 많아질수록 처리량은 증가하지만, 전체 실행 시간은 가장 긴 트랜잭션에 의해 제한됩니다. 16개 미만의 스레드에서는 가장 긴 트랜잭션이 전체 실행 시간의 약 75%를 차지하여 속도 향상이 이상적인 16배가 아닌 약 4배로 제한됩니다.
이러한 한계를 극복하기 위해 블록 가스 제한을 늘리는 방안을 시도했습니다.
스레드 수가 물리적 코어 수를 초과하면(예: 16개 코어에 32개 스레드) 성능 향상이 더 이상 나타나지 않습니다. I/O 자체는 물리적 코어 수를 초과하여 확장될 수 있지만, 이는 RocksDB 캐시 조회(인덱스, 블룸 필터, 데이터 블록) 및 CPU 집약적인 값 인코딩/디코딩 작업으로 인해 제한될 가능성이 높습니다.
메가 블록은 대규모 병렬 처리를 가능하게 합니다.
블록별 임계 경로 제한을 극복하기 위해, 이전 연구에서와 같이 병렬 처리를 높이기 위해 더 많은 가스를 소모하는 "메가 블록"을 사용하는 실험을 진행했습니다. 이를 시뮬레이션하기 위해, 여러 개의 연속적인 메인넷 블록, 즉 메가 블록 또는 배치에 포함된 트랜잭션들을 병렬로 실행한 후, 배치에 포함된 모든 트랜잭션이 완료된 후에만 상태를 데이터베이스에 커밋했습니다. 이렇게 하면 여러 블록을 하나의 큰 실행 단위로 효과적으로 통합할 수 있습니다.
저희는 스레드 수에 따라 평균 블록 가스 사용량 1,121M을 시뮬레이션하여 50개의 블록 배치를 평가했습니다. 전체 결과는 아래에 나와 있습니다.
| 실 | 처리량(MGas/s) | 가장 긴 TX 지연 시간 | 총 소요 시간 |
|---|---|---|---|
| 1 | 943 | 0.53초 | 47.55초 |
| 2 | 1,857 | 0.53초 | 24.16초 |
| 4 | 3,505 | 0.56초 | 12.80초 |
| 8 | 6,524 | 0.57초 | 6.88초 |
| 16 | 10,842 | 0.61초 | 4.13초 |
| 32 | 10,794 | 1.07초 | 4.14초 |
메가 블록을 사용하면 가장 오래 걸리는 트랜잭션이 더 이상 핵심 경로를 지배하지 않습니다. 16개 스레드 미만에서는 전체 실행 시간의 15% 미만을 차지합니다. 처리량은 스레드 수에 거의 선형적으로 비례하여 최대 약 10.8 GGas/s에 도달하며, 이는 전체 밸런서(BAL) 성능의 78%에 해당합니다. 동시에 밸런서(BAL) 크기는 전체 밸런서(BAL) 대비 67% 감소합니다.
| 밸런서(BAL) 디자인 | RLP 인코딩 밸런서(BAL) 크기 | 16개 스레드를 사용한 처리량 |
|---|---|---|
| 전체 밸런서(BAL) | 213KB | 13,881 Mgas/s |
| 병렬 I/O 밸런서(BAL) | 71KB (213KB의 33%) | 10,842 Mgas/s |
결론
본 연구는 병렬 I/O 밸런서(BAL) 전체 밸런서(BAL) 에 버금가는 성능을 보이면서도 밸런서(BAL) 크기를 크게 줄일 수 있음을 보여줍니다. 메가 블록 환경에서 병렬 I/O 밸런서(BAL) 약 10.8 GGas/s(전체 밸런서(BAL) 처리량의 약 78%)의 처리량을 유지하면서 밸런서(BAL) 크기 오버헤드를 전체 밸런서(BAL) 의 약 33% 수준으로 줄입니다. 따라서 병렬 I/O 밸런서(BAL) 처리량과 네트워크 및 스토리지 오버헤드 간의 균형을 유지하는 실용적이고 효율적인 설계 방식입니다.
전반적으로 이러한 결과는 병렬 I/O BAL 기반 병렬 실행에 대한 실질적인 상한선을 설정하고 이더리움 클라이언트 최적화 및 향후 L1 확장 노력에 대한 실행 가능한 통찰력을 제공합니다.
기타 작품
실행 벤치마크 외에도 합성 무작위 읽기 워크로드 및 이더리움 가상 머신(EVM) 실행 환경에서 RocksDB와 MDBX를 비교하고, 다양한 블록 가스 제한에 따른 병렬 I/O 밸런서(BAL) 과 배치 I/O 밸런서(BAL) 간의 장단점을 분석했습니다.
MDBX와 RocksDB의 랜덤 읽기 벤치마크 비교
먼저 이전 실험에서 사용했던 동일한 하드웨어에서 MDBX와 RocksDB의 무작위 읽기 성능을 벤치마킹하고, 확장성을 평가하기 위해 읽기 스레드 수를 변경했습니다. 데이터베이스 구성은 다음과 같습니다.
| 목 | 값 |
|---|---|
| 키 크기 | 16바이트 |
| 값 크기 | 32바이트 |
| 항목 | 16억 |
| RocksDB 크기 | 85GB |
| MDBX 크기 | 125GB |
상세 결과:
| 실 | 데이터 베이스 | 아이옵스 | 평균 지연 시간(µs) | CPU 사용률(%) |
|---|---|---|---|---|
| 2 | 록스DB | 12K | 160 | 1.1 |
| 2 | MDBX | 2만 1천 | 85 | 0.8 |
| 4 | 록스DB | 30K | 130 | 2.2 |
| 4 | MDBX | 48K | 84 | 1.3 |
| 8 | 록스DB | 85K | 92 | 4.5 |
| 8 | MDBX | 97K | 83 | 2.5 |
| 16 | 록스DB | 180K | 90 | 8 |
| 16 | MDBX | 180K | 86 | 6 |
| 32 | 록스DB | 320K | 110 | 24 |
| 32 | MDBX | 360K | 90 | 13 |
RocksDB와 MDBX는 물리적 코어 16개를 넘어서도 스레드 수에 따라 처리량이 거의 선형적으로 증가합니다. 스레드 수가 8개를 초과하면 두 데이터베이스 간의 IOPS 및 지연 시간 차이는 미미해집니다.
벤치마크 도구 모음은 GitHub의 dajuguan/ioarena에서 이용 가능합니다. 이 도구는 libmdbx, rocksdb, lmdb 이더리움 클래식(ETC) 위한 임베디드 스토리지 벤치마킹 도구입니다.
MDBX와 RocksDB 이더리움 가상 머신(EVM) 의 병렬 I/O 환경 실행 벤치마크 비교
다음으로 MDBX를 사용하여 병렬 I/O를 통한 이더리움 가상 머신(EVM) 실행 처리량을 평가하고, 블록 가스 사용량 1,121M 조건에서 RocksDB와 비교했습니다. 자세한 결과는 다음과 같습니다.
| 실 | 데이터 베이스 | 처리량(MGas/s) |
|---|---|---|
| 8 | MDBX | 2,369 |
| 8 | 록스DB | 6,524 |
| 16 | MDBX | 3,705 |
| 16 | 록스DB | 10,842 |
| 32 | MDBX | 5,748 |
| 48 | MDBX | 6,662 |
| 64 | MDBX | 6,525 |
유사한 순수 I/O 성능에도 불구하고 MDBX를 사용한 실행 처리량은 상당히 낮습니다. 이러한 차이는 현재 reth의 MDBX 바인딩 사용 방식이 기본 I/O 병렬 처리를 충분히 활용하지 못하기 때문일 가능성이 높습니다. 특히, 스레드 간에 공유되는 읽기 권한을 적절히 관리하면 성능을 향상시킬 수 있지만, 아직 효과적인 방법을 찾지 못했습니다.
가스 사용량 제한에 따른 병렬 I/O와 배치 I/O 비교
이전 분석은 주로 실행 중에 필요에 따라 상태를 가져오는 병렬 I/O에 초점을 맞췄습니다. 그러나 배치 I/O는 일부 트랜잭션이 I/O 집약적인 경우, 물리적 CPU 코어 수와 관계없이 I/O 병렬성을 더 효과적으로 활용할 수 있는 시나리오에서 이점을 제공할 수 있습니다.
이러한 장단점을 평가하기 위해, 다양한 I/O 부하 패턴에서 병렬 I/O 밸런서(BAL) 과 배치 I/O 밸런서(BAL) 비교하고, 두 밸런서(BAL) 설계에서 실행 처리량이 어떻게 확장되는지 측정했습니다.
메인넷 데이터를 이용한 평균 I/O 부하 분석
먼저 평균적인 경우를 분석해 보겠습니다. 이 경우 스토리지 읽기는 각 트랜잭션 내에서 실행되는 명령어 중 극히 일부만을 차지하며, 이는 일반적인 메인넷 워크로드를 잘 반영하는 설정입니다. 다음 표는 다양한 밸런서(BAL) 설계, 스레드 수 및 블록 가스 사용량에 따른 처리량 결과를 요약한 것입니다.
| 입출력 유형 | 실 | 블록 배치 크기 | 평균 블록 가스(M) | 처리량(MGas/s) |
|---|---|---|---|---|
| 배치 | 16 | 1 | 22 | 3,587 |
| 배치 | 32 | 1 | 22 | 3,333 |
| 평행한 | 16 | 1 | 22 | 2,893 |
| 배치 | 16 | 10 | 224 | 7,221 |
| 배치 | 32 | 10 | 224 | 6,725 |
| 평행한 | 16 | 10 | 224 | 6,842 |
| 배치 | 16 | 50 | 1,121 | 10,159 |
| 배치 | 32 | 50 | 1,121 | 10,259 |
| 평행한 | 16 | 50 | 1,121 | 10,842 |
| 배치 | 16 | 100 | 2,243 | 11,129 |
| 배치 | 32 | 100 | 2,243 | 11,266 |
| 평행한 | 16 | 100 | 2,243 | 11,292 |
블록 가스 사용량이 증가함에 따라 두 설계 모두 처리량이 지속적으로 증가합니다. 그러나 배치형 I/O 밸런서(BAL) 의 상대적 이점은 블록 크기가 작을 때는 약 20%에서 블록 크기가 클 때는 거의 0%까지 꾸준히 감소합니다 .
또한, 배치 I/O 밸런서(BAL) 에 사용되는 스레드 수를 16개에서 32개로 늘려도 성능 향상이 미미한데, 이는 워크로드가 I/O 바운드가 아닌 CPU 바운드가 됨을 나타냅니다. 이러한 현상은 RocksDB 캐시 조회 및 CPU 집약적인 값 인코딩/디코딩 작업으로 인해 I/O 확장성이 제한되는 것으로 보입니다.
| 밸런서(BAL) 디자인 | RLP 인코딩 밸런서(BAL) 크기 |
|---|---|
| 병렬 I/O 밸런서(BAL) (읽기 제외) | 110KB |
| 배치 I/O 밸런서(BAL) (읽기 포함) | 71KB (35% 더 작음) |
결정적으로, 배치 I/O에 사용되는 RLP 인코딩 밸런서(BAL) 의 평균 크기는 병렬 I/O에 비해 약 35% 더 큽니다. 대용량 블록은 I/O 읽기 작업뿐만 아니라 다른 실행 병목 현상을 드러내기 때문에, 이러한 추가적인 네트워크 및 스토리지 오버헤드로 인해 병렬 I/O가 전반적으로 더 매력적인 밸런서(BAL) 설계 방식이 됩니다. 자세한 밸런서(BAL) 크기 측정 결과는 위의 벤치마크 스위트 에서도 확인할 수 있습니다.
시뮬레이션 데이터를 이용한 최악의 I/O 부하 분석
평균적인 결과를 보완하기 위해, 이제 디스크 읽기가 트랜잭션 실행의 대부분을 차지하는 최악의 I/O 부하 시나리오를 고려해 보겠습니다.
이러한 상황을 시뮬레이션하기 위해, 우리는 스토리지 접근 압력을 최대화하는 합성 트랜잭션을 구성합니다. 구체적으로, 우리는 임의 값의 해시 x 에 대해 반복적인 SLOAD(x) 연산을 수행하는 컨트랙트 호출로 채워진 opcode 스트림을 가진 트랜잭션을 생성합니다. BAL에서 제공하는 읽기 위치가 없으면, 이러한 트랜잭션은 스토리지 상태를 가져오기 위해 SLOAD opcode를 순차적으로 실행해야 하므로 최악의 I/O 바운드 워크로드를 나타냅니다.
현재 트랜잭션당 가스 사용량 제한이 1,600만 가스이고 슬롯당 상태 읽기 비용이 대략 다음과 같다고 가정하면:
-
SLOAD에 2000 가스, 케칵 해시 오버헤드에 약 39 가스 추가.
단일 거래는 최대 다음과 같은 작업을 수행할 수 있습니다: \frac{16{,}000{,}000}{2039} \approx 7{,}845 16,000,000 2039 ≈ 7,845
서로 다른 저장소 읽기 횟수입니다. 이 구성을 사용하여 메인넷 데이터베이스에서 최악의 I/O 부하 트랜잭션을 시뮬레이션합니다.
배치 처리 방식과 병렬 처리 방식의 I/O 설계 간의 성능 비교 결과는 아래와 같습니다.
| 입출력 유형 | 실 | 총 실행 시간(밀리초) | 평균 블록 가스(M) | 처리량(MGas/s) |
|---|---|---|---|---|
| 배치 | 16 | 14.4 | 64 | 4,571 |
| 배치 | 32 | 11.2 | 64 | 5,818 |
| 배치 | 48 | 10.7 | 64 | 6,400 |
| 배치 | 64 | 10.7 | 64 | 5,333 |
| 평행한 | 4 | 82.5 | 64 | 780 |
| 배치 | 16 | 42.6 | 640 | 11,034 |
| 배치 | 32 | 58.2 | 640 | 12,307 |
| 배치 | 32 | 60.3 | 640 | 10,158 |
| 평행한 | 16 | 82.2 | 640 | 7,804 |
블록 가스 사용량이 낮은 조건(64M 가스)에서 배치 I/O 밸런서(BAL) 48개 스레드에서 최상의 처리량을 달성하며, 병렬 I/O 밸런서(BAL) 보다 거의 8배 높은 처리량을 보입니다. 이는 스토리지 읽기가 실행의 대부분을 차지할 때 명시적 I/O 배치 처리가 매우 효과적임을 입증합니다.
하지만 이러한 결과를 전체 실행 맥락에서 해석하는 것이 중요합니다. 최악의 I/O 부하 시나리오에서도 병렬 I/O 밸런서(BAL) 의 총 실행 시간은 현재 인증 마감 시간(약 3초)보다 훨씬 짧습니다. 더욱이, 이 경우에는 상태 변화가 없으므로 병렬 실행에는 머클라이제이션 및 상태 커밋 비용이 포함되지 않습니다. 이 두 가지 비용은 실제 병렬 실행 파이프라인에서 전체 실행 시간의 거의 50%를 차지합니다.
10배 가스 사용량 메가 블록 설정(640M 가스)에서 성능 격차는 더욱 좁아집니다. 배치 I/O 밸런서(BAL) 병렬 I/O 밸런서(BAL) 보다 약 1.6배 정도 우수한 성능을 보이며, 두 방식 모두 검증 시간 제약 조건을 충분히 충족합니다.
| 입출력 유형 | 평균 블록 가스(M) | 최적 처리량(MGas/s) | RLP 인코딩 밸런서(BAL) 크기 |
|---|---|---|---|
| 배치 | 64 | 6,400 | 251kb |
| 평행한 | 64 | 6,400 | 0kb |
| 배치 | 640 | 15,238 | 2,511kb |
| 평행한 | 640 | 6,153 | 0kb |
종합적으로 볼 때, 최악의 I/O 부하 조건에서는 다음과 같은 현상이 관찰됩니다.
- 현재 메인넷 가스 제한에 따르면:
- 배치 I/O 밸런서(BAL) 병렬 I/O 밸런서(BAL) 에 비해 최대 8배의 처리량 향상을 달성합니다. 그러나 전체 블록 처리 시간을 고려할 때, 이 방식에서는 I/O 읽기가 주요 병목 현상이 아닙니다.
- 가스 허용량의 10배 미만:
- 배치 I/O 밸런서(BAL) 의 성능 이점은 상당히 줄어들어 병렬 I/O 밸런서(BAL) 대비 1.6배의 처리량을 제공하는 반면, 무시할 수 없는 약 2.5MiB의 밸런서(BAL) 크기 오버헤드가 추가로 발생합니다.
이러한 결과는 중요한 통찰을 뒷받침합니다. 배치 I/O 밸런서(BAL) 비정상적으로 I/O가 포화된 워크로드에서 최고의 성능을 제공하지만, 병렬 I/O 밸런서(BAL) 배치 처리로 인해 발생하는 추가적인 밸런서(BAL) 크기 오버헤드 없이도 최악의 시나리오에서도 충분히 견고합니다.
벤치마크 제품군은 여기에서 확인할 수 있습니다. GitHub - dajuguan/evm-benchmark
