레이어1 병렬 실행을 한눈에 파악한다: Aptos, Sui, Linera, Fuel은 어떻게 구현하고 있는가?
저자: Mohamed Fouda
번역: TechFlow
블록체인 기술의 진화를 되돌아보면 새로운 L1들이 병렬 실행(parallel execution)에 집중하고 있다는 강력한 추세가 나타나고 있음을 알 수 있다.
이는 전혀 새로운 기술은 아니며, 현재 솔라나(Solana)도 Sealevel 실행 환경에서 이를 사용하고 있다.
그러나 지난 번 불장에서는 DeFi와 NFT의 인상적인 성과로 인해 기술 개선이 시급하다는 인식이 높아졌다.
다음 시장 사이클에서는 병렬 실행 개념을 채택한 유명한 프로젝트들이 등장할 예정인데, 그 대표적인 사례로는 Aptos, Sui, Linera, Fuel가 있다.
본문에서는 이러한 프로젝트들의 차이점과 공통점, 그리고 직면한 과제들을 논의한다.
문제점
스마트 컨트랙트 플랫폼은 다양한 탈중앙화 애플리케이션을 만들 수 있게 한다. 이러한 애플리케이션을 실행하기 위해서는 공유된 컴퓨팅 엔진이 필요하다. 네트워크 내 모든 노드는 이 컴퓨팅 엔진을 실행하며, 애플리케이션과 사용자 간 상호작용을 처리한다. 노드들이 실행 결과에서 동일한 값을 도출하면 합의에 도달하고 체인이 진행된다.
이더리움 가상 머신(EVM)은 가장 주요한 스마트 컨트랙트(SC) 실행 엔진으로, 약 20종의 다양한 구현 방식이 존재한다.
EVM이 발명된 이후로 개발자들 사이에서 임계 규모(critical mass)를 형성하며 널리 채택되어 왔다.
이더리움과 이더리움 L2 외에도 폴리곤(Polygon), BNB 스마트 체인, 아발란치 C체인 등의 여러 체인들이 EVM을 실행 엔진으로 채택하고 있으며, 주로 합의 메커니즘을 변경하여 네트워크 처리량을 향상시키는 데 초점을 맞추고 있다.
EVM의 주요 제약 중 하나는 트랜잭션의 순차적 실행이다. EVM은 기본적으로 한 번에 하나의 트랜잭션만을 실행하며, 다른 모든 트랜잭션은 해당 트랜잭션이 완료되고 블록체인 상태가 갱신될 때까지 대기하게 된다. 두 트랜잭션이 서로 독립적이더라도 예를 들어 앨리스에서 밥에게 보내는 송금과 캐롤에서 데이브에게 보내는 송금이라 할지라도, EVM은 이를 병렬로 처리할 수 없다. 이런 실행 모델은 플래시론(Flash Loan) 같은 흥미로운 사례를 가능하게 하지만 효율성이나 확장성 측면에서는 부족하다.
이러한 순차적 실행은 네트워크 처리량의 주요 병목 현상 중 하나이다:
- 첫째, 블록 내 트랜잭션 실행 시간이 길어지고, 블록 생성 시간이 제한된다;
- 둘째, 노드가 트랜잭션을 처리하고 블록을 검증할 수 있도록 하기 위해 블록에 포함할 수 있는 트랜잭션 수가 제한된다.
이더리움의 평균 처리량은 약 17tx/초 정도이다. 이처럼 낮은 처리량은 NFT 민팅과 같은 고부하 활동 기간에는 마이너/검증자가 모든 트랜잭션을 처리하지 못하게 되고, 우선 실행을 보장하기 위한 수수료 경쟁이 발생하며, 이로 인해 거래 수수료가 급등하게 된다. 이더리움의 평균 수수료는 일부 시기에 0.2 ETH(약 800달러)를 넘기도 하여, 많은 사용자들이 이더리움 사용을 꺼리게 되었다.
순차적 실행의 두 번째 문제는 네트워크 노드의 낮은 효율성이다. 순차적 명령 실행은 다수의 프로세서 코어로부터 이점을 얻지 못하므로 하드웨어 활용률이 낮아지고 비효율성이 발생한다. 이는 확장성을 저해하며 불필요한 에너지 소비를 초래한다.
병렬 실행이 이 문제를 해결할 수 있을까?
EVM 아키텍처의 제한은 병렬 실행(PE)을 지향하는 새로운 L1들의 등장을 가능하게 했다. 병렬 처리는 트랜잭션 처리를 여러 프로세서 코어에 분산시켜 하드웨어 활용도를 높이고, 더 나은 확장성을 실현한다. 고처리량 체인에서는 하드웨어 자원 증가가 직접적으로 실행 가능한 트랜잭션 수의 증가로 연결된다.
고주파 활동 기간에는 검증자 노드가 추가적인 트랜잭션 부하를 처리하기 위해 더 많은 코어를 할당할 수 있다. 계산 자원의 동적 확장은 수요가 많은 시기에 네트워크가 더 높은 처리량을 달성할 수 있게 하여 사용자 경험을 크게 향상시킨다.
이 방법의 또 다른 장점은 트랜잭션 확인 지연 시간의 개선이다. 노드 자원의 동적 확장을 통해 모든 가능한 네트워크 부하에서도 낮은 지연 시간으로 트랜잭션을 확인할 수 있다.
사용자는 수십 또는 수백 개의 블록을 기다릴 필요 없으며, 우선 확인을 위해 과도한 수수료를 지불할 필요도 없다. 개선된 확인 시간은 트랜잭션의 종결성을 높이며, 저지연 블록체인의 문을 열게 된다. 트랜잭션 실행의 낮은 지연 시간을 보장함으로써 기존에는 불가능했던 여러 새로운 활용 사례가 가능해진다.
병렬 처리(PE)를 가능하게 하기 위해 체인의 실행 모드를 변경하는 것은 새로운 아이디어가 아니다. 일부 프로젝트들은 이미 이를 탐색해왔다. 한 가지 접근법은 EVM이 사용하는 어카운트(Accounts) 모델을 미사용 트랜잭션 출력(UXTO, Unspent Transaction Output) 모델로 대체하는 것이다. UXTO 실행 모델은 비트코인에서 사용되며, 트랜잭션의 병렬 처리를 가능하게 하여 결제에 이상적이다.
하지만 UXTO는 기능이 제한적이므로 스마트 컨트랙트가 요구하는 복잡한 상호작용을 지원하려면 확장이 필요하다. 예를 들어 카르다노(Cardano)는 이를 위해 확장된 UXTO 모델을 사용하며, 파인도라(Findora)는 두 가지 회계 모델을 모두 구현하고 자산 유형을 전환할 수 있는 하이브리드 UXTO 모델을 사용한다.
또 다른 PE 접근법은 계정 모델을 변경하지 않고 체인 상태 아키텍처와 수정 방식을 개선하는 데 초점을 둔다. 예를 들어 솔라나의 Sealevel 프레임워크가 있다.
병렬 실행은 어떻게 작동하는가?
병렬 실행은 독립된 트랜잭션을 식별하여 동시에 실행하는 방식으로 작동한다. 한 트랜잭션의 실행이 다른 트랜잭션의 실행에 영향을 준다면 두 트랜잭션은 연관되어 있다고 간주된다. 예를 들어 동일한 풀 내 AMM 트랜잭션은 서로 연관되어 있으므로 순차적으로 실행되어야 한다.
병렬 처리 개념 자체는 간단해 보이지만, 핵심적인 어려움은 "독립된" 트랜잭션을 효과적으로 식별하는 데 있다. 독립 트랜잭션을 분류하려면 각 트랜잭션이 블록체인 메모리 또는 체인 상태를 어떻게 변경하는지를 이해해야 한다. 동일한 스마트 컨트랙트(예: AMM 풀)와 상호작용하는 트랜잭션은 동시에 컨트랙트 상태를 변경할 수 있으므로 동시에 실행될 수 없다.
현재 애플리케이션 간 조합(composability) 수준을 고려하면, 트랜잭션 간 연관성을 식별하는 것은 매우 도전적인 작업이다. 예를 들어 UNI를 USDC로 교환하는 AMM 트랜잭션이 있다고 하자. AMM이 최적의 경로로 UNI → ETH → DAI → AAVE → USDC를 선택했다면, 이 경로에 참여하는 모든 풀들은 해당 트랜잭션이 완전히 실행되고 모든 관련 풀의 상태가 갱신될 때까지 다른 트랜잭션을 처리할 수 없다.
독립 트랜잭션 식별하기
이 절에서는 다양한 병렬 실행 엔진이 사용하는 방법을 비교한다. 특히 상태(메모리) 접근을 제어하는 방식에 초점을 둔다. 블록체인 상태는 RAM 저장소로 간주할 수 있으며, 체인 상의 각 계정 혹은 스마트 컨트랙트는 수정 가능한 일련의 메모리 위치를 갖는다. 연관 트랜잭션은 동일 블록 내에서 동일한 메모리 위치를 변경하려는 트랜잭션이며, 각 체인은 서로 다른 메모리 아키텍처와 메커니즘을 이용해 이러한 트랜잭션을 식별한다.
이 범주에 속하는 여러 체인들은 페이스북의 중단된 블록체인 프로젝트 Diem이 개발한 기술을 기반으로 하고 있다. Diem 팀은 스마트 컨트랙트 실행을 개선하기 위해 Move라는 스마트 컨트랙트 언어를 만들었다. Aptos, Sui, Linera는 이 그룹에 속하는 주요 프로젝트 세 곳이다. 이 그룹 외에도 Fuel은 자체 SC 언어를 사용하며 병렬 실행에 집중하는 또 다른 유명한 프로젝트이다.
Aptos
Aptos는 Diem의 Move 언어와 MoveVM을 기반으로 고처리량 체인을 구축하며 병렬 실행을 실현했다.
Aptos의 접근법은 연관 관계를 감지하면서도 사용자/개발자에게 투명하다, 즉 트랜잭션이 어떤 상태(메모리 위치) 부분을 사용할 것인지 명시적으로 선언할 필요가 없다.
Aptos는 Software Transactional Memory(STM)의 변형인 Block-STM을 사용한다.
Block-STM에서는 트랜잭션이 블록 내에서 미리 정렬되고, 여러 프로세서 스레드에 분배되어 실행된다.
실행 과정에서 모든 트랜잭션은 서로 연관되지 않는다는 가정 하에 처리된다. 트랜잭션에 의해 수정된 메모리 위치가 기록되며, 실행 후 모든 트랜잭션 결과가 검증된다. 검증 과정에서 앞선 트랜잭션에 의해 수정된 메모리 위치에 접근한 트랜잭션이 발견되면 해당 트랜잭션은 무효화된다. 그 결과는 버려지고 다시 실행된다.
이 과정은 블록 내 모든 트랜잭션이 성공적으로 실행될 때까지 반복된다.
여러 프로세서 코어를 사용할 때 Block-STM은 실행 속도를 가속화하며, 그 정도는 트랜잭션 간 연관성 수준에 따라 달라진다.
Aptos 팀의 실험 결과에 따르면, 32개 코어를 사용할 경우 높은 연관성 환경에서 8배, 낮은 연관성 환경에서 16배의 성능 향상이 가능하다. 만약 블록 내 모든 트랜잭션이 상호 의존적이라면 Block-STM은 순차 실행보다 약간 느려질 수 있다. Aptos는 이 방법으로 최대 160,000 TPS의 처리량을 달성할 수 있다고 주장한다.
Sui
다른 PE 접근법은 트랜잭션이 수정할 체인 상태 부분을 명시적으로 선언하도록 요구하는 것으로, 현재 솔라나와 Sui가 이를 사용하고 있다.
솔라나는 메모리 단위를 '계정(account)'이라고 부르며, 트랜잭션은 자신이 수정할 계정을 명시해야 한다. Sui 역시 유사한 방식을 사용한다.
Sui 역시 MoveVM을 활용해 Diem 기술을 기반으로 하고 있다. 그러나 Sui는 Diem의 Move 언어와는 다른 버전을 사용한다.
Sui Move는 Diem의 핵심 스토리지 모델과 자산 권한을 변경하여, 핵심 Diem Move를 사용하는 Aptos와 중요한 차이를 보인다.
Sui Move는 독립 트랜잭션을 쉽게 식별할 수 있는 상태 저장 모델을 정의한다.
Sui에서 상태 저장은 Objects로 정의된다. Objects는 일반적으로 자산을 나타내며 공유될 수 있어, 여러 사용자가 동일 객체를 수정할 수 있다.각 Objects는 Sui 실행 환경 내에서 고유 ID를 가지며, 소유자 주소를 가리키는 내부 포인터를 갖는다. 이러한 개념을 활용하면 트랜잭션이 동일 Objects를 사용하는지 여부를 확인함으로써 연관성을 쉽게 식별할 수 있다.
연관성 선언 책임을 개발자에게 넘김으로써 실행 엔진의 구현이 쉬워지며, 이론적으로 더 나은 성능과 확장성을 제공할 수 있다. 그러나 이는 다소 열악한 개발자 경험을 수반한다.
Sui는 아직 출시되지 않았으며 최근 테스트넷을 론칭했다.
Sui 창립자들은 병렬 실행 구현과 Narwhal 및 Tusk 합의 메커니즘 사용으로 초당 100,000건 이상의 트랜잭션 처리량을 달성할 수 있다고 주장한다. 이 처리량이 사실이라면 현재 솔라나의 약 2,400tx/초보다 큰 향상이며, 비자(VISA)와 마스터카드의 처리량을 능가할 수 있다.
Linera
Linera는 병렬 처리 분야의 최신 참가자로, 최근 a16z가 리드한 첫 번째 펀딩 라운드를 발표했다. 프로젝트 구현에 관한 자세한 정보는 많지 않다. 그러나 펀딩 공고글에 따르면, Linera는 페이스북에서 개발된 FastPay 프로토콜을 기반으로 한다.
FastPay는 '비잔틴 일관 브로드캐스트(Byzantine Consistent Broadcast)' 기술을 기반으로 하며, 판매 시점(PoS) 네트워크에서 발생하는 독립적인 결제를 가속화하는 데 초점을 둔다. 검증자 그룹이 3분의 2 이상 성실하다면 결제의 무결성을 보장할 수 있다. FastPay는 은행 및 금융기관 간 네트워크에서 사용되는 실시간 총액 정산(RTGS) 시스템의 변형이다.
FastPay를 기반으로 Linera는 결제 트랜잭션의 병렬 실행을 통해 빠른 정산과 낮은 지연 시간에 집중하는 블록체인을 구축할 계획이다. 참고로 Sui도 간단한 결제에는 비잔틴 일관 브로드캐스트 방식을 사용한다. 다른 트랜잭션의 경우, DeFi 거래와 같은 더 복잡하고 연관된 트랜잭션을 효율적으로 처리하기 위해 Sui 자체의 Narwhal 및 Tusk 합의 메커니즘이 사용된다.
Fuel
Fuel은 모듈러 블록체인에서 실행 계층이 되는 것을 목표로 하며, 즉 Fuel은 합의를 구현하거나 블록체인 데이터를 Fuel 체인에 저장하지 않는다. 기능적인 블록체인을 위해 Fuel은 이더리움 또는 Celestia와 같은 다른 체인과 상호작용하여 합의와 데이터 가용성을 확보한다.
Fuel은 UTXO를 사용하여 엄격한 접근 목록(strict access list)을 생성한다. 즉, 상태의 동일 부분에 대한 접근을 제어하는 목록을 만든다. 이 모델은 표준 트랜잭션 정렬 개념을 기반으로 한다. 이 방식에서 블록 내 트랜잭션 정렬은 트랜잭션 간 연관성 식별을 크게 단순화한다. 이 아키텍처를 실현하기 위해 Fuel은 새로운 가상머신 FuelVM과 새로운 언어 Sway를 개발했다.
FuelVM은 EVM과 호환되면서도 간소화된 형태로, 개발자들이 Fuel 생태계에 쉽게 참여할 수 있도록 한다.
또한 Fuel이 모듈러 블록체인에 집중함에 따라 Fuel 스마트 컨트랙트의 실행은 이더리움 메인넷에서 해결될 수 있다. 이 접근법은 이더리움의 '합병(Merge)' 이후 로롤업 중심의 정산 및 데이터 가용성 계층이 되겠다는 비전과 일치한다. 이 아키텍처에서 Fuel은 이더리움 위에서 고처리량 실행을 구현하고 배치 처리 및 정산을 수행할 수 있다.
컨셉을 검증하기 위해 Fuel 팀은 유니스왑(Uniswap)과 유사한 AMM인 SwaySwap을 테스트넷에서 운영하고 있다. 이는 FuelVM이 EVM 대비 우수한 성능을 입증하기 위한 목적이다.
병렬 실행 방식의 과제
병렬 실행 접근법은 논리적이고 직관적이지만, 여전히 몇 가지 과제가 존재한다. 첫째, 이러한 병렬 실행 방식으로 가속화할 수 있는 트랜잭션의 실제 비율을 추정하는 것이 어렵다. 둘째, 네트워크의 탈중앙화 문제로서, 검증자가 처리량 향상을 위해 계산 능력을 쉽게 확장할 수 있다면, 전체 노드는 이를 따라가며 체인의 정확성을 유지할 수 있을까?
병렬화 가능한 트랜잭션의 비율
어떤 체인에서 병렬 실행 가능한 트랜잭션의 비율을 정확히 추정하는 것은 도전적인 일이다. 게다가 네트워크 활동 유형에 따라 이 비율은 블록 간에 크게 달라질 수 있다.
예를 들어 NFT 민팅은 연관성 높은 트랜잭션의 급증을 유발할 수 있다. 그러나 몇 가지 가정을 통해 병렬화 가능한 트랜잭션의 평균 비율을 대략적으로 추정할 수 있다.
예를 들어 대부분의 ETH 및 ERC20 전송은 서로 다른 주소에서 시작하여 서로 다른 주소로 수신되므로 독립적이라고 가정할 수 있다. 따라서 ETH 및 ERC20 전송의 약 25%는 상호 연관적일 수 있는데, 스마트 컨트랙트에 예치하거나 거래소 핫월렛의 자산을 콜드월렛으로 집계하는 경우 등이 이에 해당한다.
반면 동일 풀 내 모든 AMM 트랜잭션은 연관적이다. 대부분의 AMM은 소수의 풀에 의해 지배되며, AMM 트랜잭션은 고도로 조합 가능하여 여러 풀과 상호작용하므로, 적어도 50%의 AMM 트랜잭션이 상호 연관적이라고 안전하게 가정할 수 있다.
이더리움의 트랜잭션 유형을 분석해 보면, 하루 약 120만 건의 트랜잭션 중 20-30%는 ETH 전송, 10-20%는 스테이블코인 전송, 10-15%는 DEX 전송, 4-6%는 NFT 거래, 8-10%는 ERC20 승인, 12-15%는 기타 ERC20 전송이다.
이 수치들과 가정을 바탕으로, PE는 스마트 컨트랙트 플랫폼에서 약 70-80%의 트랜잭션을 가속화할 수 있다고 추정할 수 있다.
즉, 연관 트랜잭션의 순차적 실행이 전체 트랜잭션의 20-30%를 차지한다는 의미다. 즉, 동일한 가스 한도를 사용한다면 PE를 통해 처리량을 3~5배 증가시킬 수 있다.
병렬 실행 EVM을 구축하려는 실험들에서도 유사한 추정치가 나오며, 지속적으로 3~5배의 처리량 향상이 가능하다.
실제로 고처리량 체인은 더 높은 가스 한도와 더 짧은 블록 시간을 사용하여 이더리움 대비 최소 100배 이상의 처리량 향상을 달성한다. 증가된 처리량은 이러한 블록을 처리할 수 있는 강력한 검증 노드를 필요로 하며, 이것이 두 번째 과제인 네트워크의 중앙화를 초래한다.
네트워크의 중앙화
고처리량 네트워크에서는 네트워크가 초당 수만 건의 트랜잭션을 처리할 수 있다.
검증 노드는 수수료와 네트워크 보상을 받기 위해 이러한 트랜잭션을 처리하며, 전용 서버나 확장 가능한 클라우드 아키텍처에 투자한다. 그러나 체인을 사용하고 전체 노드를 실행하여 체인과 상호작용해야 하는 기업이나 개인의 경우는 그렇지 않다. 이들은 대규모 트랜잭션 부하를 처리할 수 있는 복잡한 서버를 감당할 수 없다. 이는 사용자들이 Infura와 같은 전문 RPC 노드 제공업체에 의존하게 만들며, 결국 중앙화를 심화시킨다.
소비자용 하드웨어로 전체 노드를 운영할 수 없는 경우, 고처리량 체인은 소수의 실체만이 절대적인 권한을 갖는 폐쇄 시스템이 될 수 있다. 이 경우 이들 실체는 Tornado Cash와 같은 특정 트랜잭션, 실체, 애플리케이션을 공동으로 검열하며, 웹2와 별반 다르지 않은 허가형 시스템으로 전환할 수 있다.
탈중앙화 옹호자들은 이러한 예상 문제를 해결하기 위한 솔루션을 제안하고 있다. 예를 들어 ZK 유효성 증명이나 사기 증명(fraud proof)을 사용하여 경량 노드(light node)가 블록의 정확성을 검증하는 방식이 있다.
Fuel 팀은 이 분야에서 적극적이며, 이더리움 커뮤니티의 탈중앙화 중요성에 대한 정신과 일치한다. Aptos와 Sui 팀이 이러한 방법이나 탈중앙화 촉진 방안을 우선시하는지 여부는 명확하지 않다. Linera 팀은 소개 글에서 이 문제를 간략히 언급했지만, 프로토콜 구현이 이를 뒷받침할지는 아직 확인되지 않았다.
결론
병렬 실행 엔진은 스마트 컨트랙트 플랫폼의 처리량을 향상시키는 유망한 해결책이다.
합의 메커니즘 혁신과 결합된 트랜잭션의 병렬 실행은 체인의 처리량을 초당 10만 건 이상으로 끌어올릴 수 있으며, 이는 비자와 마스터카드 수준에 맞먹는 성능이다. 이는 현재 가장 도전적인 활용 사례들, 예를 들어 완전한 체인 상 게임 및 탈중앙화 마이크로 페이먼트 등을 가능하게 한다.
이처럼 인상적인 처리량 향상은 탈중앙화를 어떻게 보장할 것인가라는 과제 없이 이루어지지 않는다. 우리는 이러한 문제 해결에 헌신하는 창업자들을 기대한다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@MohamedFFouda
