낙관적 병렬화를 한 줄로 말하면, 대부분의 트랜잭션이 충돌하지 않는다고 가정하고 병렬로 실행하되, 읽기/쓰기 충돌이 나면 고정된 순서로 다시 실행해 결과가 직렬 실행과 일치할 때까지 반복하는 것입니다. “더 빠른 마법”이 아니라, 충돌 처리를 예방에서 감지·복구로 옮기는 것입니다. EVM이 계정 접근 목록을 강제할 수 없을 때, 이는 바이트코드 호환성을 지키는 거의 유일한 주 경로입니다. 이론: OCC 입문; 경로: 병렬 실행으로 가는 세 가지 길. 아키텍처에서의 위치: 병렬 EVM 아키텍처 개요와 Bitroot 포지셔닝.
EVM이 결정적 사전 선언을 거부하는 이유
Solana Sealevel은 스케줄러가 실행 전에 그래프를 만들 수 있도록 계정 목록 선언을 요구합니다. EVM 트랜잭션이 어떤 스토리지 슬롯을 건드리는지는 조건 분기를 지나야 드러나는 경우가 많습니다. 접근 목록을 강제하면 기존 컨트랙트와 툴체인 가정이 많이 깨집니다. 그래서 Bitroot 같은 프로젝트는 호환성을 우선하고 충돌을 런타임에 맡깁니다. 호환성 경계: EVM 호환성이 의미하는 것.
대가는 충돌률이 높을 때 재실행이 병렬 이득을 갉아먹는다는 점입니다. 이는 “버그가 있는 구현”이 아니라 낙관적 방식에 내재한 곡선입니다, 특히 핫 컨트랙트에서요—충돌 핫스팟과 워크로드를 참고하세요.
3단계 충돌 감지가 하는 일
Bitroot 자료는 책임 기준으로 세 단계를 설명합니다(구체적 알고리즘은 노드 구현을 따릅니다):
-
실행 전 — 정적/휴리스틱 의존성 분석
이력 패턴, 정적 분석, 또는 대략적인 읽기/쓰기 추정으로 명백한 충돌을 같은 병렬 윈도우에서 배제합니다. -
실행 중 — 버전 또는 읽기/쓰기 집합 모니터링
트랜잭션은 사설 뷰에서 실행됩니다. 읽은 버전이 앞선 순서의 트랜잭션에 의해 이미 쓰였다면, 쓸모없는 작업을 끝내지 말고 조기에 중단합니다. -
실행 후 — 상태 루트 / 직렬화 가능성 검사
커밋 후보의 일관성을 검사해 병합된 병렬 결과가 정규 직렬 의미론과 일치하는지 확인하고, 놓친 충돌과 구현 버그를 잡습니다.
한 번의 검증 패스를 위해 배치 전체를 끝내는 순진한 OCC와 달리, 계층형 감지는 더 일찍, 더 작은 재실행 집합으로 실패하는 것을 목표로 합니다. 이는 Block-STM 협력적 스케줄링과 같은 문제 계열이지만 스케줄러와 중단 입도가 동일하지는 않습니다—충돌률 곡선을 마케팅 배수로 대체하지 마세요.
롤백과 재실행: 블록 전체 재실행이 아니라 선택적
효율적인 구현은 보통 영향받은 트랜잭션과 그 의존 폐포만 다시 실행합니다—블록의 모든 트랜잭션이 아니라. 합의 순서는 여전히 구속력이 있습니다. 처리량을 위해 몰래 순서를 바꿀 수는 없습니다. 순서 먼저, 수렴은 나중에: Pipeline BFT와 실행 디커플링. 멀티 엔진이 병렬 윈도우를 담는 방식: 멀티 엔진 병렬 실행.
에이전트와 고빈도 정산에는 이런 의미입니다. 충돌이 적으면 확인이 예측 가능하고, 핫 풀에서는 재실행이 늘어난다고 예상해야 합니다—“병렬 = 항상 빠름”이라고 가정하지 마세요. 스택 맥락: 탈중앙화 AI 스택.
결정성: 블록체인 OCC가 요구하는 추가 층
단일 노드 데이터베이스 OCC는 그 인스턴스에서 직렬화 가능성만 보장하면 됩니다. 온체인에서는 모든 정직한 노드가 같은 상태를 독립적으로 계산해야 합니다. 따라서 스레드 스케줄링 순서, 로컬 시계, 불안정한 부동소수점 같은 비결정성에 의존하는 것을 금지합니다. 병렬성이 바뀌어도 정규 결과는 유일해야 합니다. 이는 안전성 속성이지, 성능 이스터 에그가 아닙니다.
경쟁 접근법 비교 (절제된 서술)
| 경로 | 핵심 직관 | 기존 EVM |
|---|---|---|
| 결정적 선언 | 실행 전에 의존성 파악 | 마이그레이션 비용 높음 |
| 객체 모델 | 객체 소유권으로 격리 | 새 언어/패러다임 |
| 낙관적 OCC | 런타임 감지 + 재실행 | 바이트코드 호환성에 가장 가까움 |
“고전 EVM 대비 배수 처리량”이라는 공개 주장은 특정 부하와 테스트넷 조건에서의 엔지니어링 관찰로 읽어야 합니다. 충돌이 높으면 배수는 줄어듭니다. 읽기 가이드: 성능 지표 용어집. 검증인 임계값이 사용 가능한 병렬성을 어떻게 제한하는지: 탈중앙화 대 성능. 이는 투자 조언이 아닙니다.
피크 배수보다 충돌 곡선
실험실의 “직렬 EVM 대비 N배”는 보통 저충돌 합성 부하에 대응합니다. 같은 엔진도 공유 풀 핫스팟에서는 배수가 빠르게 줄어듭니다. 단일 배율보다 충돌–처리량 곡선, 재실행 비중, p95 지연을 선호하세요. 핫스팟 해부: 병렬 EVM 워크로드 핫스팟.
클라이언트 세부는 다르지만 평가 체크리스트는 공유할 수 있습니다. 읽기/쓰기 집합 입도(계정 대 슬롯), 중단이 즉시 재실행되는지 큐에 들어가는지, 검증이 병렬인지, 병렬 병합 후 상태 루트가 어떻게 확정되는지. 체크리스트가 구체적일수록 “세 단계”를 얼버무리기 어렵습니다. 데이터베이스 계보: OCC 입문; 아키텍처: 병렬 EVM 아키텍처 개요.
충돌률 곡선과 엔지니어링 손잡이
핵심 손잡이는 “엔진이 많을수록 항상 좋다”가 아니라, 병렬 윈도우 폭, 중단 정책, 재실행 우선순위, 휴리스틱 분석의 보수성입니다. 윈도우가 너무 넓으면 충돌 연쇄가 길어지고, 너무 좁으면 직렬 실행에 가까워집니다. 휴리스틱이 너무 보수적이면 처리량이 묶이고, 너무 공격적이면 재실행 폭풍을 부릅니다.
공개 테스트는 무충돌 기준선, 중간 합성 충돌 부하, AMM에 가까운 핫스팟 스트레스 부하를 보고해야 합니다. 첫 번째 수치만 공개하면 낙관적 가정이 성립할 때의 상한을 보여줄 뿐입니다. 용어집: 성능 지표 용어집. 워크로드 분류: 충돌 핫스팟과 워크로드.
블록체인 OCC 대 데이터베이스 OCC—다시
데이터베이스는 프라이머리에 커밋한 뒤 복제할 수 있지만, 체인은 모든 정직한 복제본이 독립적으로 같은 루트에 수렴해야 합니다. “거의 직렬화 가능”으로는 부족합니다—결정성은 필수입니다. 부동소수점 모델 출력, 로컬 엔트로피, 순서 없는 병렬 리덕션은 정규 상태 전이에 들어와서는 안 됩니다. 이들은 오프체인에 남아 증명이나 집계 서명으로 앵커링할 수 있습니다.
그래서 AI 추론이 합의에 직접 들어가서는 안 됩니다. 확률적 출력은 결정적 재현과 충돌합니다. 패턴은 오프체인 컴퓨팅, 온체인 정산, 선택적 증명입니다—탈중앙화 AI 스택, 신뢰 컴퓨팅 프레임워크.
낙관적 병렬화의 교육적 가치는 “빠름”을 측정 가능한 충돌률과 재실행 비중으로 번역한다는 데 있습니다. 그 번역을 유지하면 다음번 더 큰 TPS 포스터를 무비판적으로 믿기 어려워집니다. 구현 세부는 여전히 클라이언트 코드와 감사를 따릅니다.
정합성 테스트 (개념적)
처리량 벤치를 넘어: 같은 배치가 병렬성 수준에 관계없이 하나의 상태 루트를 내야 하고, 주입한 읽기/쓰기 충돌이 직렬 동등성으로 수렴해야 하며, 크래시 복구 재생이 포크를 만들지 않아야 하고, 퍼징한 무작위 흐름이 병렬 모드와 직렬 모드에서 일치해야 합니다. 이를 통과하는 것이 또 하나의 피크 TPS 주장보다 엔지니어링된 낙관적 병렬화를 더 잘 보여줍니다.
감지, 재실행, 결정성은 낙관적 병렬의 삼각형을 이룹니다. 감지가 없으면 롤백이 늦고, 선택적 재실행이 없으면 처리량이 무너지며, 결정성이 없으면 안전성 모델이 실패합니다. 세 가지가 모두 있어야 TPS 수치가 스스로 설명됩니다.
속도 향상은 충돌률, 재실행 비중과 함께 공개하세요. 고립된 피크는 피하세요. 투자 조언이 아닙니다.
구체적 알고리즘은 노드 구현과 감사를 따릅니다. 이 글은 메커니즘 직관만 세웁니다.
핵심 요약
낙관적 병렬화는 Bitroot가 개발자에게 접근 패턴 재작성을 강요하지 않고 멀티 코어 이득을 끌어내게 합니다. 천장은 충돌률과 재실행 효율이 정하지, 백서의 형용사가 정하지 않습니다. 감지 계층과 결정성 제약을 이해하는 것이 어떤 TPS 수치를 외우는 것보다 유용합니다.