Layer1 병렬 실행 상세 설명: Aptos, Sui, Linera 및 Fuel은 어떻게 구현하는가?

원문 제목：《The Case for Parallel Processing Chains》

원문 저자：Mohamed Fouda

원문 번역：심조 TechFlow

블록체인 기술의 진화를 재조명할 때, 새로운 L1이 병렬 실행에 중점을 두고 있다는 강력한 트렌드가 나타나고 있습니다.

이것은 새로운 기술이 아니며, 현재 Solana는 Sealevel 실행 환경에서 이를 사용하고 있습니다.

그러나 지난 상승장에서 DeFi와 NFT의 인상적인 성과는 기술이 시급히 개선되어야 한다는 인식을 가져왔습니다.

다음 시장에서 병렬 실행 개념을 채택한 몇몇 유명 프로젝트가 등장할 예정이며, 이들 프로젝트의 목록에는 Aptos, Sui, Linera 및 Fuel이 포함됩니다.

이 글에서는 이러한 프로젝트의 유사점과 차이점, 그리고 그들이 직면한 도전에 대해 논의할 것입니다.

문제

스마트 계약 플랫폼은 광범위한 탈중앙화 애플리케이션을 생성할 수 있습니다. 이러한 애플리케이션을 실행하기 위해서는 공유 계산 엔진이 필요합니다. 네트워크의 각 노드는 이 계산 엔진을 실행하며, 애플리케이션과 사용자 간의 상호작용을 수행합니다. 노드가 실행에서 동일한 결과를 얻으면, 그들은 합의에 도달하고 체인의 운영을 추진합니다.

이더리움 가상 머신은 가장 주요한 스마트 계약(SC) 실행 엔진으로, 약 20종의 다양한 구현 방식이 존재합니다.

EVM이 발명된 이후, 개발자들이 채택하는 기준 질량을 구축했습니다.

이더리움과 이더리움의 L2 외에도, Polygon, BNB 스마트 체인 및 Avalanche C 체인과 같은 다른 여러 체인도 EVM을 실행 엔진으로 채택하고, 네트워크 처리량을 향상시키기 위해 합의 메커니즘을 변경하는 데 집중하고 있습니다.

EVM의 주요 제한적 특징 중 하나는 거래의 순차 실행입니다. EVM은 기본적으로 한 번에 하나의 거래를 실행하며, 모든 다른 거래는 거래가 완료되고 블록체인 상태가 업데이트될 때까지 보류됩니다. 두 거래가 독립적일지라도, 예를 들어 Alice에서 Bob으로의 지불과 Carol에서 Dave로의 또 다른 지불처럼, EVM은 이러한 거래를 병렬로 실행할 수 없습니다. 이러한 실행 방식은 흥미로운 사용 사례를 허용하지만, 효율성과 확장성이 부족합니다.

이러한 순차 실행 거래는 네트워크 처리량의 주요 병목 중 하나입니다:

• 첫째, 이는 블록 내 거래 실행 시간을 더 길게 만들어 블록 시간을 제한합니다;
• 또한, 이는 노드가 거래를 실행하고 블록을 확인할 수 있도록 블록에 추가할 수 있는 거래 수를 제한합니다.

이더리움의 평균 처리량은 약 17 tx/초입니다. 이러한 낮은 처리량은 NFT 민트와 같은 높은 활동 기간 동안 네트워크의 채굴자/검증자가 모든 거래를 처리할 수 없음을 의미하며, 그 결과 우선 실행을 보장하기 위한 수수료 입찰 전쟁이 발생하여 거래 수수료가 상승합니다. 이더리움의 평균 수수료는 어떤 시점에서는 0.2 ETH(약 800달러)를 초과했으며, 많은 사용자들이 이로 인해 이더리움을 사용하기를 주저하게 되었습니다.

순차 실행의 두 번째 문제는 네트워크 노드의 비효율성입니다. 순차 명령 실행은 여러 프로세서 코어의 이점을 활용할 수 없으며, 이는 하드웨어 활용도를 낮추고 비효율성을 초래합니다. 이는 확장성을 저해하고 불필요한 에너지 소비를 초래합니다.

병렬 실행이 이 문제를 해결할 수 있을까요?

EVM 구조의 제한은 병렬 실행(PE)의 L1 새로운 영역을 위한 조건을 만듭니다. 병렬 실행은 여러 프로세서 코어 간에 거래 처리를 분할할 수 있게 하여 하드웨어 활용도를 높이고 더 나은 확장성을 실현합니다. 높은 처리량 체인에서는 하드웨어 자원의 증가가 실행 가능한 거래 수와 직접적으로 관련이 있습니다.

고빈도 활동 기간 동안, 검증자 노드는 추가 거래 부하를 처리하기 위해 더 많은 코어를 위임할 수 있습니다. 계산 자원의 동적 확장은 네트워크가 높은 수요 기간 동안 더 높은 처리량을 달성할 수 있게 하여 사용자 경험을 크게 개선합니다.

이 방법의 또 다른 장점은 거래 확인 지연을 개선하는 것입니다. 노드 자원의 동적 확장은 모든 가능한 네트워크 부하에 대한 낮은 지연 거래의 확인을 가능하게 합니다.

거래는 수십 개 또는 수백 개의 블록을 기다릴 필요가 없으며, 우선 확인을 위해 과도한 수수료를 발생시킬 필요도 없습니다. 개선된 확인 시간은 거래의 최종성을 높여 낮은 지연 블록체인에 대한 문을 열어줍니다. 거래 실행의 낮은 지연을 보장함으로써 몇 가지 이전에는 불가능했던 사용 사례가 가능해집니다.

체인 실행 방식을 변경하여 PE를 허용하는 것은 새로운 아이디어가 아니며, 일부 프로젝트는 이미 이에 대한 탐색을 진행했습니다. 한 가지 방법은 EVM이 사용하는 회계 모델을 Accounts 모델에서 Unspent Transaction Output (UTXO) 모델로 교체하는 것입니다. UTXO 실행 모델은 비트코인에서 사용되며, 거래를 병렬로 처리할 수 있게 하여 지불에 이상적인 선택이 됩니다.

하지만 UTXO의 기능이 제한적이기 때문에 스마트 계약에 필요한 복잡한 상호작용을 위해 확장이 필요합니다. 예를 들어, Cardano는 이를 위해 확장된 UTXO 모델을 사용하고, Findora는 두 가지 회계 모델을 구현하여 사용자가 두 모델 간에 자산 유형을 변경할 수 있도록 하는 혼합 UTXO 모델을 사용합니다.

PE의 또 다른 접근 방식은 계좌 모델을 변경하지 않고 체인 상태의 아키텍처와 수정을 개선하는 데 집중합니다. 예를 들어 Solana의 Sealevel 프레임워크입니다.

병렬 실행은 어떻게 작동하나요?

병렬 실행의 작동 방식은 독립적인 거래를 식별하고 동시에 실행하는 것입니다. 만약 한 거래의 실행이 다른 거래의 실행에 영향을 미친다면, 두 거래는 연관되어 있습니다. 예를 들어, 동일한 풀 내의 AMM 거래는 연관되어 있으며 순차적으로 실행되어야 합니다.

병렬 처리의 개념은 간단하게 들리지만, 세부 사항에서 어려움이 있으며, 주요 도전 과제는 "독립적인" 거래를 효과적으로 식별하는 방법입니다. 독립 거래의 분류는 각 거래가 블록체인 메모리 또는 체인 상태를 어떻게 변경하는지를 이해해야 하며, 동일한 스마트 계약(예: AMM 풀)과 상호작용하는 거래는 계약 상태를 동시에 변경할 수 있으므로 동시에 실행할 수 없습니다.

현재 애플리케이션 간의 조합 가능성을 고려할 때, 서로 연관되어 있는지를 식별하는 것은 도전적인 작업입니다. 예를 들어, UNI를 USDC로 교환하는 AMM 거래가 있다고 가정해 보겠습니다. AMM은 이를 실행하는 가장 효율적인 경로가 UNI -> ETH -> DAI -> AAVE -> USDC임을 발견합니다. 이 거래에 참여하는 모든 풀은 해당 거래가 완전히 실행될 때까지 다른 거래를 처리할 수 없으며, 그 후에야 모든 참여 풀의 상태가 업데이트될 수 있습니다.

독립 거래 식별

이 섹션에서는 다양한 병렬 실행 엔진에서 사용되는 방법을 비교합니다. 초점은 상태(메모리) 접근을 제어하는 방법에 있습니다. 블록체인 상태는 RAM 저장소로 간주될 수 있으며, 각 체인의 계좌 또는 스마트 계약은 수정할 수 있는 메모리 위치의 집합을 가집니다. 연관 거래는 동일한 블록 내에서 동일한 메모리 위치를 변경하려는 거래입니다. 서로 다른 체인은 이러한 거래를 식별하기 위해 서로 다른 메모리 아키텍처와 메커니즘을 사용합니다.

이 범주의 몇몇 체인은 Facebook이 개발한 블록체인 프로젝트 Diem의 기술 위에 구축되었습니다. Diem 팀은 스마트 계약 언어 Move를 만들어 SC의 실행을 개선했습니다. Aptos, Sui 및 Linera는 이 그룹에 속하는 세 가지 고명도 프로젝트입니다. 이 그룹 외에도 Fuel은 PE에 집중하는 또 다른 유명한 프로젝트로, 자체 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 방법은 거래가 수정하는 체인 상태 부분을 명시적으로 선언하도록 요구하는 것으로, 현재 Solana와 Sui가 이를 사용하고 있습니다.

Solana는 메모리 단위를 계좌라고 부르며, 거래는 어떤 계좌를 수정하는지를 명시해야 합니다. Sui도 유사한 방법을 사용합니다.

Sui는 또한 Diem의 기술 위에 MoveVM을 기반으로 구축되었습니다. 그러나 Sui는 다른 버전의 Move 언어를 사용합니다.

Sui Move의 구현은 Diem의 핵심 저장 모델과 자산 권한을 변경하여 Aptos의 핵심 Diem Move 사용과는 상당한 차이를 나타냅니다.

Sui Move는 독립 거래를 더 쉽게 식별할 수 있는 상태 저장 모델을 정의합니다.

Sui에서 상태 저장은 Objects로 정의됩니다. Objects는 일반적으로 자산을 나타내며 공유될 수 있습니다. 즉, 여러 사용자가 해당 객체를 수정할 수 있습니다. 각 Objects는 Sui 실행 환경에서 고유한 ID를 가지며, 소유자 주소를 가리키는 내부 포인터가 있습니다. 이러한 개념을 사용하여, 거래가 동일한 Objects를 사용하는지를 확인함으로써 연관성을 쉽게 식별할 수 있습니다.

연관성을 선언하는 작업을 개발자에게 전가함으로써 실행 엔진의 구현이 더 쉬워지며, 이론적으로 더 나은 성능과 확장성을 가질 수 있습니다. 그러나 이는 다소 이상적이지 않은 개발자 경험을 대가로 합니다.

Sui는 아직 시작되지 않았으며, 최근에 테스트넷을 출시했습니다.

Sui의 창립자는 병렬 실행의 구현과 Narwhal 및 Tusk 합의 메커니즘의 사용이 100,000 tx/초를 초과하는 처리량을 초래한다고 주장합니다. 이 처리량이 사실이라면, 현재 Solana의 약 2400 tx/초의 처리량보다 크게 향상될 수 있으며, Visa와 Mastercard의 처리량을 초과할 것입니다.

Linera

Linera는 병렬 처리 분야의 최신 구성원으로, 최근 a16z의 주도로 첫 번째 자금 조달 라운드를 발표했습니다. 프로젝트 구현에 대한 세부 사항은 많지 않습니다. 그러나 그들의 자금 조달 발표 게시물에 따르면, 이는 Facebook에서 개발된 FastPay 프로토콜을 기반으로 하고 있습니다.

Fastpay는 Byzantine Consistent Broadcast라는 기술을 기반으로 하며, 이는 판매 지점 네트워크에서 발생하는 독립적인 지불을 가속화하는 데 중점을 둡니다. 이는 3분의 2 이상의 검증자가 정직한 한, 검증자 그룹이 지불의 완전성을 보장할 수 있게 합니다. 빠른 지불은 은행 및 금융 기관 간의 네트워크를 위한 실시간 총액 결제(RTGS) 시스템의 변형입니다.

FastPay를 기반으로 Linera는 병렬 실행을 통해 지불 거래를 처리하고 빠른 결제와 낮은 지연에 중점을 둔 블록체인을 구축할 계획입니다. 주목할 점은 Sui도 간단한 지불을 위해 Byzantine Consistent Broadcast 방식을 사용한다는 것입니다. 다른 거래의 경우, Sui의 자체 합의 메커니즘인 Narwhal과 Tusk가 DeFi 거래와 같은 더 복잡하고 관계적인 거래를 효율적으로 처리하는 데 사용됩니다.

Fuel

Fuel은 모듈화 블록체인 내의 실행 레이어가 되는 데 중점을 두고 있으며, 이는 Fuel이 합의를 구현하지 않거나 블록체인 데이터를 Fuel 체인에 저장하지 않음을 의미합니다. 기능성 블록체인에 대해 Fuel은 Ethereum이나 Celestia와 같은 다른 체인과 상호작용하여 합의와 데이터 가용성을 달성합니다.

Fuel은 UTXO를 사용하여 동일한 상태에 대한 접근을 제어하는 엄격한 접근 목록을 생성합니다. 이 모델은 거래 정렬을 규범화하는 개념에 기반합니다. 이 계획에서 블록 내 거래의 정렬은 거래 간의 연관성을 감지하는 것을 크게 단순화합니다. 이 아키텍처를 구현하기 위해 Fuel은 FuelVM이라는 새로운 가상 머신과 Sway라는 새로운 언어를 구축했습니다.

FuelVM은 EVM에 대한 호환성과 단순화된 표현으로, 개발자가 Fuel 생태계에 쉽게 참여할 수 있도록 합니다.

또한 Fuel이 모듈화 블록체인에 중점을 두고 있기 때문에, Fuel SC의 실행은 이더리움 메인넷에서 해결될 수 있습니다. 이 방법은 합병 후 이더리움의 비전과 일치하며, 롤업 중심의 결제 및 데이터 가용성 레이어로서 기능합니다. 이 아키텍처에서 Fuel은 이더리움에서 대량 및 결제의 높은 처리량 실행을 실현할 수 있습니다.

이 개념을 검증하기 위해 Fuel 팀은 Uniswap과 유사한 AMM인 SwaySwap을 생성하고 테스트넷에서 운영하고 있습니다. 목적은 FuelVM이 EVM에 비해 성능이 더 높다는 것을 증명하는 것입니다.

병렬 실행 방법의 도전 과제

병렬 실행 방법은 논리적이고 직접적인 것처럼 보이지만, 현재 우리는 여전히 몇 가지 도전에 직면해 있습니다. 첫 번째는 이러한 병렬 실행 방식으로 가속할 수 있는 거래의 실제 비율을 추정하는 것입니다. 두 번째 도전 과제는 네트워크의 탈중앙화입니다. 즉, 검증자가 처리량을 높이기 위해 계산 능력을 쉽게 확장할 수 있다면, 전체 노드는 체인의 정확성을 보장하기 위해 어떻게 따라갈 수 있을까요?

병렬 거래의 비율

어떤 체인에서 병렬로 실행 가능한 거래의 비율을 정확하게 추정하는 것은 도전적입니다. 또한 네트워크 활동의 유형에 따라 이 비율은 블록 간에 크게 변동할 수 있습니다.

예를 들어, NFT 민트는 높은 비율의 연관 거래의 폭발을 초래할 수 있습니다. 즉, 우리는 몇 가지 가정을 사용하여 병렬 거래의 평균 비율에 대한 대략적인 추정을 얻을 수 있습니다.

예를 들어, 대부분의 ETH 및 ERC20의 전송은 독립적이라고 가정할 수 있습니다. 즉, 서로 다른 주소에서 시작하여 서로 다른 주소로 수신됩니다. 따라서 약 25%의 ETH 및 ERC20 전송이 서로 연관되어 있다고 가정할 수 있습니다. 즉, SC에 예치하거나 거래소의 핫 월렛 자산을 콜드 월렛으로 집계하는 것입니다.

반면, 동일한 풀 내의 모든 AMM 거래는 서로 연관되어 있습니다. 대부분의 AMM이 일반적으로 소수의 풀에 의해 주도되며, AMM 거래는 높은 조합 가능성을 가지며 여러 풀과 상호작용하기 때문에, 최소 50%의 AMM 거래가 서로 연관되어 있다고 안전하게 가정할 수 있습니다.

이더리움의 거래 유형을 분석해 보면, 이더리움에서 하루 약 120만 거래 중 20-30%가 ETH 전송, 10-20%가 스테이블코인 전송, 10-15%가 DEX 전송, 4-6%가 NFT 거래, 8-10%가 ERC20 승인, 12-15%가 기타 ERC20 전송임을 알 수 있습니다.

이 숫자와 가정을 사용하여, PE가 SC 플랫폼에서 약 70-80%의 거래를 가속할 수 있다고 추정할 수 있습니다.

이는 연관 거래의 순차 실행이 모든 거래의 20-30%를 차지한다는 것을 의미합니다. 다시 말해, 동일한 가스 제한을 사용할 경우 PE를 통해 3배에서 5배의 처리량 증가를 실현할 수 있는 가능성이 있습니다.

병렬 실행 EVM 구축에 대한 몇 가지 실험은 유사한 추정을 보여주었으며, 지속적으로 3-5배의 처리량 향상을 실현할 수 있습니다.

실제로 높은 처리량 체인은 더 높은 가스 제한과 더 짧은 블록 시간을 사용하여 최소 100배 이상의 이더리움 처리량 향상을 실현합니다. 증가된 처리량은 이러한 블록을 처리하기 위한 강력한 검증 노드를 필요로 하며, 이 요구는 네트워크의 중앙화라는 두 번째 도전 과제를 초래합니다.

네트워크의 중앙화

높은 처리량의 네트워크에서는 네트워크가 매초 수만 건의 거래를 처리할 수 있습니다.

검증 노드는 이러한 거래를 처리하기 위해 수수료와 네트워크 보상의 유인을 받으며, 이러한 거래를 처리하기 위해 전용 서버나 확장 가능한 클라우드 아키텍처에 투자합니다. 그러나 체인을 사용하고 전체 노드를 실행하여 체인과 상호작용해야 하는 회사나 개인에게는 상황이 다릅니다. 이러한 실체는 대규모 거래 부하를 처리하기 위한 복잡한 서버를 감당할 수 없습니다. 이는 체인 상의 사용자가 전문 RPC 노드 공급자(예: Infura)에 의존하게 만들며, 이는 더 많은 중앙화를 초래합니다.

소비자급 하드웨어를 사용하여 전체 노드를 실행하지 않으면, 높은 처리량의 체인은 폐쇄된 시스템이 될 수 있으며, 소수의 실체가 네트워크에 대한 절대적인 권력을 가질 수 있습니다. 이러한 경우, 이러한 실체는 거래, 실체 또는 애플리케이션(예: Tornado Cash)을 검열하도록 조정할 수 있으며, 이는 이러한 체인을 Web 2와 다를 바 없는 허가 시스템으로 전환할 수 있습니다.

현재 Sui 테스트넷에서 전체 노드를 운영하는 요구 사항은 Aptos 테스트넷 노드의 요구 사항보다 낮습니다. 그러나 우리는 메인넷이 시작되고 애플리케이션이 체인에서 등장하기 시작할 때 이러한 요구 사항이 크게 변화할 것으로 예상합니다.

탈중앙화를 옹호하는 사람들은 이러한 예상 문제를 해결하기 위한 솔루션을 제안해 왔습니다. 이러한 솔루션에는 경량 노드를 사용하고, ZK 유효성 증명 또는 사기 증명을 통해 블록의 정확성을 검증하는 것이 포함됩니다.

Fuel 팀은 이 분야에서 매우 적극적이며, 이더리움 커뮤니티와 탈중앙화의 중요성에 대한 정신을 일치시킵니다. Aptos와 Sui 팀이 이러한 방법이나 다른 탈중앙화를 촉진하는 방법을 우선적으로 구현할지는 불확실합니다. Linera 팀은 그들의 소개 게시물에서 이러한 문제를 간략하게 논의했지만, 프로토콜 구현은 이 약속을 확인하지 않았습니다.

결론

병렬 실행 엔진은 스마트 계약 플랫폼의 처리량을 높이는 유망한 솔루션입니다.

합의 메커니즘의 혁신과 결합된 거래의 병렬 실행은 체인의 처리량을 10만 TPS에 가깝게 또는 초과할 수 있게 하며, 이러한 성능은 Visa와 Mastercard와 견줄 수 있습니다. 이는 오늘날 가장 도전적인 몇 가지 사용 사례, 예를 들어 완전한 체인 상 게임과 탈중앙화 소액 결제를 실현할 수 있습니다.

이러한 인상적인 처리량 개선은 탈중앙화를 보장하는 방법에 대한 도전 없이 이루어지지 않으며, 우리는 이러한 문제를 해결하기 위해 노력하는 창립자들을 기대합니다.