새로운 퍼블릭 체인이 병렬 실행을 달성하는 방법에 대한 심층 분석: Aptos, Sui, Linera, Fuel

Ethereum 및 Ethereum의 L2 외에도 Polygon, BNB Smart Chain 및 Avalanche C Chain을 비롯한 여러 다른 체인은 모두 EVM을 실행 엔진으로 채택하고 합의 메커니즘을 변경하여 네트워크 처리량을 향상시키는 데 중점을 둡니다.EVM의 주요 제한 기능은 트랜잭션의 순차적 실행입니다.

EVM은 기본적으로 트랜잭션을 한 번에 하나씩 실행하여 트랜잭션이 실행되고 블록체인 상태가 업데이트될 때까지 다른 모든 트랜잭션을 보류합니다. 예를 들어 Alice가 Bob에게 지불하고 Carol이 Dave에게 지불하는 것과 같이 두 개의 트랜잭션이 독립적인 경우에도 EVM은 이러한 트랜잭션을 병렬로 실행할 수 없습니다. 이 실행 모드는 플래시 론과 같은 흥미로운 사용 사례를 허용하지만 효율적이거나 확장 가능하지 않습니다.

이 트랜잭션의 순차적 실행은 네트워크 처리량의 주요 병목 현상 중 하나입니다.
첫째, 블록의 트랜잭션을 실행하는 데 더 오래 걸리게 하여 블록 시간을 제한합니다.

또한 노드가 트랜잭션을 실행하고 블록을 확인할 수 있도록 블록에 추가할 수 있는 트랜잭션 수를 제한합니다.

이더리움의 평균 처리량은 약 17tx/s입니다. 이 낮은 처리량은 NFT Mint와 같이 활동이 많은 기간 동안 네트워크 채굴자/검증인이 모든 트랜잭션을 처리할 수 없으며 우선 순위 실행을 보장하기 위해 수수료 입찰 전쟁이 발생하여 트랜잭션 수수료가 상승한다는 것을 의미합니다. 이더리움의 평균 수수료는 어느 시점에서 0.2 ETH(~$800)를 초과하여 많은 사용자가 이더리움을 사용하지 못하게 했습니다.순차 실행의 두 번째 문제는 네트워크 노드의 비효율성입니다.

순차 명령 실행은 다중 프로세서 코어의 이점을 얻을 수 없으므로 하드웨어 활용도가 낮고 비효율적입니다. 이는 확장성을 저해하고 불필요한 에너지 소비로 이어집니다.

병렬 실행이 이 문제를 해결할 수 있습니까?EVM 아키텍처의 제약은 병렬 실행(PE)의 새로운 L1 영역을 허용합니다.

병렬 처리를 통해 트랜잭션 처리를 여러 프로세서 코어로 나누어 하드웨어 활용도를 높이고 확장성을 높일 수 있습니다. 처리량이 많은 체인에서 증가하는 하드웨어 리소스는 실행할 수 있는 트랜잭션 수와 직접적인 관련이 있습니다.

활동이 많은 기간 동안 유효성 검사기 노드는 추가 트랜잭션 부하를 처리하기 위해 더 많은 코어를 위임할 수 있습니다. 컴퓨팅 리소스의 동적 확장을 통해 네트워크는 수요가 많은 기간 동안 더 높은 처리량을 달성하여 사용자 경험을 크게 향상시킵니다.

이 방식의 또 다른 장점은 트랜잭션 확인 대기 시간이 개선되고 노드 리소스의 동적 확장으로 지연 시간이 짧은 트랜잭션으로 가능한 모든 네트워크 부하를 확인할 수 있다는 것입니다.트랜잭션은 수십 또는 수백 블록을 기다릴 필요가 없으며 우선 확인을 위해 과도한 수수료를 부과할 필요가 없습니다.

개선된 확인 시간은 거래 완결성을 높이고 대기 시간이 짧은 블록체인의 문을 엽니다. 트랜잭션 실행을 위한 낮은 대기 시간을 보장하면 이전에는 불가능했던 여러 사용 사례가 가능합니다.

PE를 허용하도록 연결된 실행 모델을 변경하는 것은 새로운 아이디어가 아니며 여러 프로젝트에서 이를 탐색했습니다. 한 가지 접근 방식은 EVM에서 사용하는 회계 모델을 Accounts 모델에서 UTXO(Unspent Transaction Output) 모델로 교체하는 것입니다. 비트코인에 사용되는 UTXO 실행 모델은 트랜잭션을 병렬로 처리할 수 있어 결제에 이상적입니다.그러나 UXTO의 제한된 기능으로 인해 스마트 계약에 필요한 복잡한 상호 작용을 가능하게 하려면 확장해야 합니다.

예를 들어 Cardano는 이러한 목적을 위해 확장된 UTXO 모델을 사용하는 반면 Findora는 두 가지 회계 모델을 구현하고 사용자가 두 모델 간에 자산 유형을 변경할 수 있는 하이브리드 UTXO 모델을 사용합니다.PE에 대한 또 다른 접근 방식은 계정 모델을 변경하지 않고 대신 아키텍처 개선 및 체인 상태 수정에 중점을 둡니다.

예를 들어 Solana의 Sealevel 프레임워크입니다.

병렬 실행은 어떻게 작동합니까?병렬 실행은 독립적인 트랜잭션을 식별하고 동시에 실행하는 방식으로 작동합니다.

한 트랜잭션의 실행이 다른 트랜잭션의 실행에 영향을 미치는 경우 두 트랜잭션이 연결됩니다. 예를 들어, 동일한 풀의 AMM 트랜잭션은 연결되어 있으며 순차적으로 실행되어야 합니다."병렬 처리의 개념은 간단해 보이지만 세부 사항에 어려움이 있습니다. 주요 과제는 효과적으로 식별하는 방법입니다."독립적인

거래. 독립적인 트랜잭션의 분류는 각 트랜잭션이 블록체인 메모리 또는 체인 상태를 어떻게 변경하는지 이해해야 합니다.동일한 스마트 컨트랙트(예: AMM 풀)와 상호 작용하는 트랜잭션은 동시에 컨트랙트 상태를 변경할 수 있으므로 실행할 수 없습니다. 동시에.

현재 응용 프로그램 간의 구성 가능성 수준에서 응용 프로그램이 서로 관련되어 있는지 식별하는 것은 어려운 작업입니다. UNI를 USDC로 교환하는 AMM 트랜잭션을 상상해보십시오. AMM은 이를 실행하는 가장 효율적인 경로가 UNI -> ETH -> DAI -> AAVE -> USDC임을 알게 됩니다. 트랜잭션에 참여하는 모든 풀은 트랜잭션이 완전히 실행될 때까지 다른 트랜잭션을 처리할 수 없습니다. 그런 다음 참여하는 모든 풀의 상태를 업데이트할 수 있습니다.

독립 트랜잭션 식별

이 범주의 여러 체인은 Facebook의 소멸된 블록체인 프로젝트 Diem에서 개발한 기술을 기반으로 합니다. Diem 팀은 특히 SC 실행을 개선하기 위해 스마트 계약 언어 Move를 만들었습니다. Aptos, Sui 및 Linera는 이 그룹에 속하는 세 가지 주요 프로젝트입니다. 이 그룹 외에도 Fuel은 자체 SC 언어를 사용하는 PE에 초점을 맞춘 또 다른 잘 알려진 프로젝트입니다.

Aptos

보조 제목

Aptos는 Diem의 Move 언어와 MoveVM을 기반으로 병렬 실행을 가능하게 하는 고처리량 체인을 생성합니다.Aptos의 접근 방식은 사용자/개발자에게 투명하면서 연관성을 감지하는 것입니다.

즉, 트랜잭션은 자신이 사용하는 상태(메모리 위치)의 어느 부분을 명시적으로 명시할 필요가 없습니다.

Aptos는 Block-STM이라고 하는 STM(Software Transactional Memory)의 수정된 버전을 사용합니다.

Block-STM에서 트랜잭션은 블록 내에서 미리 정렬되고 실행을 위해 프로세서 스레드 간에 분할됩니다.

이 과정에서 트랜잭션 실행은 관련이 없는 것으로 간주됩니다. 트랜잭션에 의해 수정된 메모리 위치가 기록되고 실행 후 모든 트랜잭션의 결과가 검증됩니다. 확인하는 동안 트랜잭션이 이전 트랜잭션에 의해 수정된 메모리 위치에 액세스하는 것으로 발견되면 트랜잭션이 무효화됩니다. 트랜잭션 결과는 플러시되고 다시 실행됩니다.

이 프로세스는 블록의 모든 트랜잭션이 실행될 때까지 반복됩니다.

다중 프로세서 코어가 사용될 때 Block-STM은 트랜잭션이 상호 연결된 방식에 따라 실행 속도를 높입니다.Aptos 팀의 결과는 다음과 같이 나타났습니다.블록의 모든 트랜잭션이 상호 의존적인 경우 Block-STM은 순차 실행에 비해 성능이 약간 저하될 수 있습니다. Aptos는 이 접근 방식이 160,000 TPS의 처리량을 달성할 수 있다고 주장합니다.

Sui

보조 제목

또 다른 PE 접근 방식은 트랜잭션이 수정하는 체인 상태의 부분을 명시적으로 명시하도록 요구하는 것으로 현재 Solana와 Sui에서 사용하는 접근 방식입니다.

Solana는 메모리 단위를 계정으로 지칭하며 트랜잭션은 수정하는 계정을 명시해야 합니다. Sui도 비슷한 접근 방식을 사용했습니다.Sui는 또한 MoveVM을 사용하여 Diem의 기술을 기반으로 합니다.

그러나 Sui는 다른 버전의 Move 언어를 사용합니다.

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

Sui Move는 독립 트랜잭션을 보다 쉽게 식별할 수 있는 상태 저장 모델을 정의합니다.

Sui에서 상태 저장소는 객체로 정의됩니다. 개체는 일반적으로 자산을 나타내며 공유할 수 있습니다. 즉, 여러 사용자가 개체를 수정할 수 있습니다. 각 개체는 Sui 실행 환경에서 고유한 ID를 가지며 소유자의 주소를 가리키는 내부 포인터를 가집니다. 이러한 개념을 사용하면 트랜잭션이 동일한 개체를 사용하는지 여부를 확인하여 연결을 쉽게 식별할 수 있습니다.

관계를 선언하는 작업을 개발자에게 옮김으로써 실행 엔진의 구현이 더 쉬워진다는 것은 이론적으로 더 나은 성능과 확장성을 가질 수 있다는 것을 의미합니다. 그러나 이것은 이상적이지 않은 개발자 경험을 희생합니다.

Sui의 창립자들은 병렬 실행의 구현과 Narwhal 및 Tusk 합의 메커니즘의 사용으로 초당 100,000 tx 이상의 처리량이 발생했다고 주장합니다. 이 처리량은 사실이라면 솔라나의 현재 처리량인 약 2400tx/sec보다 크게 향상될 수 있으며 Visa 및 Mastercard의 처리량을 초과할 것입니다.

Linera

보조 제목Linera는 병렬 처리 공간의 최신 참가자이며 최근 a16z가 이끄는 첫 번째 자금 조달을 발표했습니다.

프로젝트 구현에 대한 세부 정보가 거의 없습니다. 그러나 자금 조달 발표 게시물을 기반으로 Facebook에서 개발한 FastPay 프로토콜을 기반으로 한다는 것을 알고 있습니다.

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

Fuel

보조 제목Fuel은 모듈식 블록체인의 실행 계층이 되는 데 초점을 맞추고 있습니다. 즉, Fuel이 합의를 시행하거나 블록체인의 데이터를 Fuel 체인에 저장하지 않는다는 의미입니다.

기능적 블록체인의 경우 Fuel은 Ethereum 또는 Celestia와 같은 합의 및 데이터 가용성을 위해 다른 체인과 상호 작용합니다.

Fuel은 UTXO를 사용하여 엄격한 액세스 목록, 즉 동일한 상태에 대한 액세스를 제어하는 목록을 만듭니다. 이 모델은 정식 트랜잭션 순서 지정 개념을 기반으로 합니다. 이 체계에서 블록의 트랜잭션 순서는 트랜잭션 간의 연관성을 감지하는 데 상당한 단순화를 가져옵니다. 이 아키텍처를 구현하기 위해 Fuel은 FuelVM이라는 새로운 가상 머신과 Sway라는 새로운 언어를 만들었습니다.

FuelVM은 개발자가 Fuel 생태계에 효과적으로 참여할 수 있도록 EVM의 호환 가능하고 단순화된 표현입니다.

개념을 증명하기 위해 Fuel 팀은 Uniswap과 유사한 SwaySwap이라는 AMM을 만들어 테스트넷에서 실행했습니다. EVM에 비해 FuelVM의 성능이 더 높다는 것을 입증하는 것이 목적입니다.

첫 번째 레벨 제목

병렬 실행의 접근 방식은 논리적이고 간단해 보이지만 현재 우리는 여전히 몇 가지 문제에 직면해 있습니다. 첫 번째는 이러한 유형의 병렬 실행을 사용하여 가속할 수 있는 트랜잭션의 실제 비율을 추정하는 것입니다. 두 번째 과제는 네트워크의 탈중앙화입니다. 즉, 유효성 검사기가 쉽게 컴퓨팅 성능을 확장하여 처리량을 늘릴 수 있다면 전체 노드가 어떻게 체인의 정확성을 보장할 수 있을까요?

첫 번째 레벨 제목

병렬화할 수 있는 트랜잭션의 비율모든 체인에서 병렬로 실행될 수 있는 온체인 트랜잭션의 비율을 정확하게 추정하는 것은 어렵습니다.

또한 이 비율은 네트워크 활동 유형에 따라 블록마다 크게 다를 수 있습니다.

예를 들어, NFT Mint는 관련 트랜잭션의 비율이 높은 폭발을 일으킬 수 있습니다. 즉, 몇 가지 가정을 사용하여 병렬화할 수 있는 트랜잭션의 평균 비율을 대략적으로 추정할 수 있습니다.

예를 들어, 우리는 대부분의 ETH 및 ERC20 전송이 독립적이라고 가정할 수 있습니다. 즉, 서로 다른 주소에서 시작되고 수신됩니다. 따라서 우리는 ETH 및 ERC20 전송의 약 25%가 상호 연관되어 있다고 가정할 수 있습니다.

반면에 동일한 풀의 모든 AMM 트랜잭션은 상관 관계가 있습니다. 대부분의 AMM은 일반적으로 소수의 풀에 의해 지배되고 AMM 트랜잭션은 구성 가능성이 높으며 여러 풀과 상호 작용한다는 점을 감안할 때 AMM 트랜잭션의 50% 이상이 상호 연결되어 있다고 안전하게 가정할 수 있습니다.

이더리움의 거래 카테고리를 분석해보면 하루 약 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배의 처리량 증가를 달성할 수 있습니다.

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

첫 번째 레벨 제목

네트워크의 중앙 집중화

처리량이 많은 네트워크에서 네트워크는 초당 수만 건의 트랜잭션을 처리할 수 있습니다.

검증인은 이러한 트랜잭션을 처리하기 위해 수수료 및 네트워크 보상으로 인센티브를 받고 이러한 트랜잭션을 처리하기 위해 전용 서버 또는 확장 가능한 클라우드 아키텍처에 투자합니다. 체인을 사용하고 체인과 상호 작용하기 위해 전체 노드를 실행해야 하는 회사나 개인에게는 해당되지 않습니다. 이러한 엔터티는 이러한 대규모 트랜잭션 로드를 처리하기 위해 복잡한 서버를 감당할 수 없습니다. 이는 온체인 사용자가 Infura와 같은 전문화된 RPC 노드 공급자에 의존하도록 유도하여 더 많은 중앙 집중화로 이어집니다.

전체 노드를 실행하기 위해 소비자 등급 하드웨어를 사용하는 옵션이 없으면 높은 처리량 체인은 폐쇄된 시스템이 될 수 있으며 소수의 엔터티 그룹이 네트워크를 통해 절대적인 권한을 갖습니다. 이 경우 이러한 엔터티는 이러한 체인을 Web 2와 다르지 않은 허가된 시스템으로 전환할 수 있는 Tornado Cash와 같은 심사 트랜잭션, 엔터티 및 애플리케이션까지 조정할 수 있습니다.현재 Sui 테스트넷에서 전체 노드를 운영하기 위한 요구 사항은 Aptos 테스트넷 노드에 대한 요구 사항보다 낮습니다.

그러나 메인넷이 출시되고 애플리케이션이 온체인에 나타나기 시작하면 이러한 요구 사항이 크게 변경될 것으로 예상합니다.

요약하다

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

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

원본 링크