Reddio를 통해 본 병렬 EVM의 최적화 여정
글: 무월, 극객 web3
众所周시하듯이 EVM은 이더리움의 '실행 엔진'이자 '스마트 계약 실행 환경'으로 정의되며, 말할 것도 없이 이더리움에서 가장 중요한 핵심 구성 요소 중 하나이다. 공용 블록체인은 수천, 수만 개의 노드로 구성된 개방형 네트워크이며, 서로 다른 노드 간 하드웨어 사양의 차이가 매우 크다. 스마트 계약이 다양한 노드에서 동일한 결과를 산출하여 '일관성(consistency)'을 만족하려면 서로 다른 장비 상에서도 동일한 환경을 구축해야 하는데, 가상 머신(Virtual Machine)은 이러한 효과를 실현할 수 있다.
이더리움 가상 머신(EVM)은 윈도우, 리눅스, 맥OS 등 서로 다른 운영 체제와 기기에서도 동일한 방식으로 스마트 계약을 실행할 수 있으며, 이러한 크로스 플랫폼 호환성은 각 노드가 계약을 실행한 후 모두 일관된 결과를 얻도록 보장한다. 가장 전형적인 예로 자바 가상 머신(JVM)을 들 수 있다.
우리가 일반적으로 블록 탐색기에서 보는 스마트 계약은 먼저 EVM 바이트코드로 컴파일된 후 체인에 저장된다. EVM이 계약을 실행할 때는 이러한 바이트코드를 순차적으로 읽으며, 각 바이트코드에 대응하는 명령어(opCode)마다 해당하는 가스 비용이 존재한다. EVM은 각 명령어의 실행 과정에서 소모되는 가스를 추적하며, 그 소비량은 작업의 복잡도에 따라 달라진다.
또한 핵심 실행 엔진으로서, EVM은 거래를 직렬(순차적)로 처리하는데, 모든 거래가 단일 큐에 들어가서 결정된 순서대로 하나씩 실행된다. 병렬 처리 방식을 사용하지 않는 이유는 블록체인이 엄격한 일관성을 유지해야 하기 때문이다. 즉, 한 묶음의 거래들이 모든 노드에서 동일한 순서로 처리되어야 하며, 만약 거래 처리를 병렬화하면 정확한 순서를 예측하기 어렵다. 스케줄링 알고리즘을 도입하지 않는 한 말이다. 그러나 이는 상당히 복잡해진다.
2014~2015년 이더리움 창립 팀은 시간 제약 때문에 직렬 실행 방식을 선택했다. 설계가 간단하고 유지 관리가 용이하기 때문이다. 하지만 블록체인 기술의 진화와 사용자층 확대에 따라 TPS와 처리량에 대한 요구가 점점 높아졌고, 롤업(Rollup) 기술이 등장하고 성숙해지면서 EVM의 직렬 실행이 초래하는 성능 병목 현상은 이더리움 2층(Layer2)에서 명백하게 드러났다.
Sequencer는 Layer2의 핵심 구성 요소로서 단일 서버 형태로 모든 연산 작업을 담당한다. Sequencer와 협력하는 외부 모듈들의 효율성이 충분히 높다면 최종적인 병목은 Sequencer 자체의 효율성에 달려 있으며, 이때 직렬 실행은 큰 장애물이 된다.
opBNB 팀은 DA 계층과 데이터 읽기/쓰기 모듈을 극한까지 최적화함으로써, Sequencer가 초당 약 2,000건 이상의 ERC-20 송금을 처리할 수 있도록 했다. 이 숫자는 높아 보이지만, 만약 처리해야 할 거래가 ERC-20 송금보다 훨씬 복잡하다면 TPS 값은 크게 줄어들게 된다. 따라서 거래 처리의 병렬화는 미래의 필연적인 추세이다.
다음에서는 더 구체적인 세부 내용을 중심으로 기존 EVM의 한계와 병렬 EVM의 장점을 자세히 설명하겠다.
이더리움 거래 실행의 두 가지 핵심 구성 요소
코드 모듈 측면에서 EVM 외에도 go-ethereum 내에서 거래 실행과 관련된 또 다른 핵심 구성 요소는 stateDB로, 이더리움의 계정 상태 및 데이터 저장을 관리한다. 이더리움은 Merkle Patricia Trie라는 트리 구조를 데이터베이스 인덱스(디렉터리)로 사용하며, EVM의 매 거래 실행 시 stateDB에 저장된 일부 데이터가 변경되고, 이러한 변경사항은 결국 Merkle Patricia Trie(이하 글로벌 상태 트리)에 반영된다.
구체적으로 stateDB는 모든 이더리움 계정(EOA 계정 및 컨트랙트 계정 포함)의 상태를 관리하며, 저장하는 데이터에는 계정 잔액, 스마트 계약 코드 등이 포함된다. 거래 실행 과정에서 stateDB는 해당 계정의 데이터를 읽거나 쓰며, 거래 실행 후에는 새로운 상태를 저수준 데이터베이스(LevelDB 등)에 제출하여 영속화 처리를 수행한다.
요약하면, EVM은 스마트 계약 명령어를 해석하고 실행하며 계산 결과에 따라 블록체인 상태를 변경하는 역할을 하고, stateDB는 글로벌 상태 저장소 역할을 하여 모든 계정과 컨트랙트의 상태 변화를 관리한다. 두 구성 요소가 협력하여 이더리움의 거래 실행 환경을 구축한다.
직렬 실행의 구체적인 과정
이더리움의 거래 유형은 두 가지로 나뉜다: EOA 송금과 컨트랙트 거래. EOA 송금은 가장 간단한 거래 유형으로, 일반 계정 간 ETH 송금을 의미한다. 이 거래는 컨트랙트 호출을 포함하지 않으며 처리 속도가 매우 빠르다. 작업이 간단하기 때문에 EOA 송금의 가스 수수료는 매우 낮다.
간단한 EOA 송금과 달리, 컨트랙트 거래는 스마트 계약 호출 및 실행을 포함한다. EVM이 컨트랙트 거래를 처리할 때는 스마트 계약의 바이트코드 명령어를 하나씩 해석하고 실행하며, 계약 로직이 복잡할수록 포함된 명령어가 많아지고 소모되는 자원도 증가한다.
예를 들어, ERC-20 송금의 처리 시간은 EOA 송금의 약 2배 정도이며, Uniswap의 거래처럼 더 복잡한 스마트 계약의 경우 훨씬 오래 걸리며, 심지어 EOA 송금보다 10배 이상 느릴 수도 있다. 이는 DeFi 프로토콜이 거래 시 유동성 풀 관리, 가격 계산, 토큰 스왑 등의 복잡한 로직을 처리해야 하며, 매우 복잡한 계산이 필요하기 때문이다.
그렇다면 직렬 실행 모드에서 EVM과 stateDB 두 구성 요소는 어떻게 협력하여 거래를 처리하는가?
이더리움 설계상, 블록 내 거래들은 순서에 따라 하나씩 처리되며, 각 거래(tx)는 해당 거래의 구체적인 작업을 수행하기 위한 독립된 인스턴스를 갖는다. 각 거래는 서로 다른 EVM 인스턴스를 사용하지만, 모든 거래는 stateDB라는 동일한 상태 데이터베이스를 공유한다.
거래 실행 과정에서 EVM은 지속적으로 stateDB와 상호작용하며, stateDB에서 관련 데이터를 읽고 변경된 데이터를 다시 stateDB에 쓴다.
코드 수준에서 EVM과 stateDB가 어떻게 협력하여 거래를 실행하는지 대략 살펴보자:
1. processBlock() 함수가 Process() 함수를 호출하여 블록에 포함된 거래들을 처리한다;
2. Process() 함수 내에는 for 루프가 정의되어 있으며, 거래들이 하나씩 실행되는 것을 확인할 수 있다;
3. 모든 거래 처리가 완료되면, processBlock() 함수가 writeBlockWithState() 함수를 호출하고, 이후 statedb.Commit() 함수를 호출하여 상태 변경 결과를 제출한다.
블록 내 모든 거래의 실행이 완료되면, stateDB의 데이터는 앞서 언급한 글로벌 상태 트리(Merkle Patricia Trie)에 Commit되며 새로운 상태 루트(stateRoot)를 생성한다. 상태 루트는 각 블록의 중요한 파라미터로, 블록 실행 후 새로운 글로벌 상태의 '압축 결과'를 기록한다.
이러한 EVM의 직렬 실행 모드가 갖는 병목 현상은 분명하다: 거래는 반드시 순차적으로 대기열을 형성하고 실행되어야 하며, 실행 시간이 긴 스마트 계약 거래가 발생하면, 그 처리가 완료될 때까지 다른 거래는 대기해야 한다. 이는 CPU 등의 하드웨어 자원을 충분히 활용할 수 없으며, 효율성에 큰 제약을 받는다.
EVM의 멀티스레드 병렬 최적화 방안
직렬 실행과 병렬 실행을 생활 속 예로 비교하자면, 전자는 창구가 하나뿐인 은행이고, 병렬 EVM은 여러 개의 창구를 가진 은행에 비유할 수 있다. 병렬 모드에서는 여러 스레드를 동시에 열어 다수의 거래를 동시에 처리할 수 있어 효율이 몇 배로 향상되지만, 문제는 상태 충돌(conflict)이다.
여러 거래가 동일한 계정의 데이터 수정을 선언할 경우, 동시에 처리되면 충돌이 발생한다. 예를 들어 특정 NFT는 오직 하나만 민팅 가능하다고 할 때, 거래 1과 거래 2가 모두 해당 NFT를 민팅하겠다고 선언하면, 두 요청이 모두 승인되면 명백한 오류가 발생한다. 이런 상황은 조정 처리가 필요하며, 실제 운영에서 상태 충돌은 우리가 언급한 것보다 훨씬 빈번하게 발생한다. 따라서 거래 처리를 병렬화하려면 상태 충돌에 대응할 수 있는 조치가 반드시 필요하다.
Reddio의 EVM 병렬 최적화 원리
ZKRollup 프로젝트 Reddio의 EVM 병렬 최적화 접근 방식을 살펴보자. Reddio의 접근법은 각 스레드에 하나의 거래를 할당하고, 각 스레드에 임시 상태 데이터베이스(pending-stateDB)를 제공하는 것이다. 구체적인 세부 사항은 다음과 같다:
1. 멀티스레드 병렬 거래 실행: Reddio는 여러 스레드를 설정하여 서로 다른 거래를 동시에 처리하며, 스레드 사이에 간섭이 없다. 이를 통해 거래 처리 속도를 몇 배로 높일 수 있다.
2. 각 스레드에 임시 상태 데이터베이스 할당: Reddio는 각 스레드에 독립된 임시 상태 데이터베이스(pending-stateDB)를 할당한다. 각 스레드는 거래를 실행할 때 글로벌 stateDB를 직접 수정하지 않고, 상태 변화 결과를 일시적으로 pending-stateDB에 기록한다.
3. 상태 변경 동기화: 블록 내 모든 거래의 실행이 완료되면, EVM은 각 pending-stateDB에 기록된 상태 변경 결과를 차례로 글로벌 stateDB에 동기화한다. 서로 다른 거래의 실행 과정에서 상태 충돌이 발생하지 않았다면, pending-stateDB의 기록을 글로벌 stateDB에 원활히 병합할 수 있다.
Reddio는 읽기 및 쓰기 작업의 처리 방식을 최적화하여 거래가 상태 데이터에 올바르게 접근하고 충돌을 피할 수 있도록 했다.
-
읽기 작업: 거래가 상태를 읽어야 할 경우, EVM은 먼저 Pending-state의 ReadSet을 확인한다. ReadSet에 필요한 데이터가 존재하면, EVM은 pending-stateDB에서 바로 데이터를 읽는다. ReadSet에 해당 키-값(key-value) 쌍이 없으면, 이전 블록의 글로벌 stateDB에서 과거 상태 데이터를 읽는다.
-
쓰기 작업: 모든 쓰기 작업(즉, 상태 수정)은 글로벌 stateDB에 직접 기록되지 않고, 먼저 Pending-state의 WriteSet에 기록된다. 거래 실행이 완료된 후 충돌 검사를 거쳐 상태 변경 결과를 글로벌 stateDB에 병합하려 시도한다.
병렬 실행의 핵심 문제는 상태 충돌이며, 여러 거래가 동일한 계정의 상태를 읽고 쓰려 할 때 특히 두드러진다. 이에 대응해 Reddio는 충돌 검출 메커니즘을 도입했다:
-
충돌 검출: 거래 실행 과정에서 EVM은 서로 다른 거래의 ReadSet과 WriteSet을 모니터링한다. 여러 거래가 동일한 상태 항목을 읽고 쓰려는 경우 충돌이 발생한 것으로 간주한다.
-
충돌 처리: 충돌이 감지되면, 충돌 거래는 재실행이 필요하다는 표시를 받는다.
모든 거래의 실행이 완료되면, 여러 pending-stateDB의 변경 기록이 글로벌 stateDB에 병합된다. 병합이 성공하면 EVM은 최종 상태를 글로벌 상태 트리에 제출하고 새로운 상태 루트를 생성한다.
멀티스레드 병렬 최적화가 성능 향상에 미치는 영향은 명백하며, 특히 복잡한 스마트 계약 거래에 대응할 때 더욱 그렇다.
병렬 EVM 연구에 따르면, 충돌이 적은 작업 부하(low conflict workload, 거래 풀 내에서 충돌하거나 동일한 자원을 사용하는 거래가 적은 경우)에서 기준 테스트의 TPS는 기존 직렬 실행 대비 약 3~5배 향상되었다. 충돌이 많은 작업 부하(high conflict workload)에서는 이론적으로 모든 최적화 수단을 적용했을 때 최대 60배까지 도달할 수 있다.
결론
Reddio의 EVM 멀티스레드 병렬 최적화 방안은 각 거래에 임시 상태 데이터베이스를 할당하고 서로 다른 스레드에서 거래를 병렬로 실행함으로써 EVM의 거래 처리 능력을 현저히 향상시켰다. 읽기/쓰기 작업의 최적화와 충돌 검출 메커니즘 도입을 통해 EVM 계열 체인은 상태 일관성을 보장하면서도 거래의 대규모 병렬화를 실현하였으며, 기존 직렬 실행 모드의 성능 병목을 해결하였다. 이는 이더리움 롤업의 미래 발전에 중요한 기반을 마련하였다.
앞으로는 Reddio의 구현 세부 사항을 더 깊이 분석할 예정이다. 예를 들어 저장 효율을 통한 추가적인 성능 향상, 고충돌 상황에서의 최적화 방안, GPU 활용을 통한 최적화 등에 대해 다룰 계획이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@godrealmx
