병렬 실행은 "코어를 더 켜면 처리량이 오른다"처럼 들립니다. 충돌이 적은 워크로드에서는 그 직관이 대체로 맞습니다. 같은 상태 슬롯을 건드리지 않는 트랜잭션은 서로 다른 실행 엔진이 동시에 소비할 수 있고, 멀티코어 활용률이 올라갑니다. 그러나 퍼블릭 체인을 실제로 혼잡하게 만드는 트래픽은 깔끔한 개인 간 이체가 아닙니다. 같은 핫 계정이나 스토리지 슬롯을 반복해서 읽고 쓰는 컨트랙트 호출입니다. 그때 병렬성은 더 이상 CPU 개수로 제한되지 않고 충돌률로 제한됩니다.
이 사실을 보면 어떤 "병렬 EVM" 성능 숫자든 올바르게 읽을 수 있습니다. 같은 엔진도 워크로드에 따라 한 자릿수 이상 차이가 날 수 있습니다.
충돌이 적을 때와 많을 때: 서로 다른 두 게임
충돌이 적은 부하는 서로 무관한 단순 이체가 많거나, 독립적인 NFT 보유자 간 이동이거나, 서로 다른 컨트랙트 인스턴스에 대한 읽기 전용 조회인 경우입니다. 읽기/쓰기 집합이 거의 겹치지 않으므로 낙관적 병렬화는 "이상적 속도 향상"에 가까워질 수 있습니다. N개의 엔진이 고정된 스케줄링 및 버전 검사 비용을 뺀 만큼, 거의 N배의 충돌 없는 작업을 흡수합니다.
충돌이 많은 부하는 반대입니다. 같은 AMM 페어, 같은 대출 이자 지수, 같은 NFT 민팅 카운터가 많은 트랜잭션을 작은 상태 집합에 몰아넣습니다. 낙관적 실행은 여전히 앞서 병렬로 달리지만, 검증 과정에서 버전 충돌이 드러나고 많은 트랜잭션이 직렬 순서로 다시 실행되어야 합니다. 엔진은 바빠 보이는데 실효 처리량은 롤백과 재실행 오버헤드를 더한 단일 스레드 수준으로 주저앉습니다.
따라서 "병렬 EVM은 빠른가?"는 예/아니오 질문이 아닙니다. "어떤 충돌 분포에서 얼마나 더 빠른가?"입니다.
AMM, 대출, NFT 민팅이 처리량을 깎는 이유
자동화 마켓 메이커는 유동성과 가격을 소수의 풀 컨트랙트 스토리지 슬롯에 집중시킵니다. 같은 블록의 여러 스왑이 흔히 같은 reserve나 가격 관련 슬롯을 읽고 씁니다. 충돌이 구조적입니다. 사용자 주소가 서로 달라도 컨트랙트 측 핫스팟만으로 병렬성을 평평하게 만들기에 충분합니다.
대출도 비슷합니다. 이자 지수, 전역 차입 총액, 공유 청산 파라미터가 사용자들을 가로지르는 만남의 지점이 됩니다. "사용자 A 예치" 트랜잭션이 사용자 B의 차입, 사용자 C의 청산과 전역 변수를 공유할 수 있습니다.
NFT 민팅은 더 극단적입니다. 순차 ID, 공급 카운터, 허용 목록 비트맵이 짧은 경합 아래에서 단일 쓰기 지점이 되는 경우가 많습니다. 이더리움의 과거 민팅 러시가 가스 경매를 터무니없는 범위로 밀어붙인 것은 "사람이 많이 몰려서"만이 아니라, 실행 계층이 그렇게 긴밀하게 결합된 쓰기를 나눌 수 없었기 때문입니다.
읽기/쓰기 집합의 입자성: 충돌률을 좌우하는 숨은 손잡이
낙관적 병렬화는 읽기/쓰기 집합으로 두 트랜잭션이 충돌 없는지 판단합니다. 집합은 계정 수준처럼 거칠 수도 있고 개별 스토리지 슬롯처럼 미세할 수도 있습니다.
- 더 거친 집합은 충돌을 과다 보고합니다. 같은 컨트랙트의 서로 다른 슬롯을 건드리는 두 트랜잭션이 그냥 직렬화됩니다.
- 더 미세한 집합은 분석과 버전 관리 비용을 높입니다. 의존성 그래프가 조각나고 메타데이터가 커지지만, 실제 병렬성도 함께 커집니다.
엔지니어링은 대개 계정 수준 휴리스틱과 슬롯 수준 정밀도를 균형 있게 섞습니다. 실행 전 정적 의존성 분석, 실행 중 버전 감시, 실행 후 상태 루트 검사가 그 예입니다(낙관적 동시성 제어(OCC) 입문 참고). 애플리케이션 개발자에게 주는 시사점은 구체적입니다. 무관한 상태를 여러 슬롯으로 나누고, 전역 카운터를 줄이고, 단일 핫 totalSupply 경로를 피하는 것이 체인을 바꾸는 것보다 확정 경험을 더 자주 개선합니다.
핫스팟에서 최대 TPS가 저하되는 방식
벤치마크는 곡선이 예쁘게 나오므로 합성 충돌 없는 부하를 선호합니다. 실제 블록은 혼합입니다. 어떤 이체는 병렬화되고, 어떤 DeFi 호출은 핫스팟에서 막힙니다. 실효 처리량은 대략 다음에 의해 제약됩니다(설명을 위한 식이며 정확한 공식은 아닙니다).
실효 처리량 ≈ 충돌 없는 비중의 병렬 이득 + 충돌 비중의 준직렬 처리량 − 롤백/재실행 비용.
충돌 비중이 올라가면 마지막 두 항이 지배합니다. 여기서 흔한 마케팅과 엔지니어링의 불일치가 생깁니다. 자료는 "이상적 부하에서의 최대 TPS"를 인용하지만, 민팅 당일이나 변동성 장세의 사용자는 더 느린 확정과 잦은 재시도를 체감합니다. 솔직한 공개는 충돌이 적은 경우와 많은 경우 수치를 모두 제시하고 하드웨어, 클라이언트 버전, 트랜잭션 구성을 명시합니다(성능 지표 용어집 참고).
이체 벤치마크만 최적화하지 않고 조합 가능한 DeFi를 정면으로 마주하기로 한 낙관적 병렬 EVM 체인에서는 충돌 탐지와 동적 그룹화의 품질이 포스터 처리량과 사용자 체감 처리량의 차이를 만듭니다.
컨트랙트와 프로토콜 설계를 위한 실무적 함의
- 핫 슬롯을 찾아라: 감사 과정에서 고빈도 쓰기를 매핑합니다. 전역 카운터, 단일 유동성 풀, 공유 설정 비트가 유력한 용의자입니다.
- 상태를 나눠라: 가능하면 쓰기를 사용자나 풀, 샤드별로 격리하고 하나의 슬롯에 깔때기처럼 몰아넣지 않습니다.
- 암묵적 순서 가정을 버려라: "같은 블록 내 암묵적 순서"에 의존하는 로직은 낙관적 병렬화 아래에서 더 취약합니다. 순서를 명시적으로 인코딩하거나 설계를 충돌 내성 있게 만듭니다.
- 벤치마크를 충돌률로 해석하라: TPS 숫자를 보면 먼저 트랜잭션 구성을 물어야 합니다. 충돌 분포 없는 피크는 참고 가치가 제한적입니다.
마무리: 병렬화는 공짜 점심이 아니다
병렬 EVM은 워크로드에 충돌 없는 트랜잭션이 충분히 있을 때만 여러 코어를 사용합니다. 핫 컨트랙트는 실행 엔진이 바뀌었다고 사라지지 않습니다. 병목이 "단일 스레드 인터프리터"에서 "충돌 탐지와 재실행"으로 옮겨갈 뿐입니다. 그것을 설명하는 편이 또 한 번의 엘리베이터 피치보다 유용합니다. 개발자에게는 스토리지 레이아웃을 바꿔야 하는지 알려주고, 독자에게는 다음 성능 포스터를 어떻게 의심해야 하는지 알려줍니다.