병렬 실행 블록체인 시스템 연구

PREDA 작성, 체인피즈 리서치 편집

본 백서의 내용 및 목적

병렬 실행 모델의 설계는 전통적인 데이터베이스 영역과 블록체인 기술 모두에서 더 복잡합니다. 설계 과정에서 여러 차원을 종합적으로 고려해야 하며, 각 차원의 선택이 시스템의 전반적인 성능과 확장성에 큰 영향을 미칠 수 있기 때문입니다. 본 백서에서는 현재 사용 가능한 가장 대표적인 블록체인 실행 레이어 병렬 아키텍처 몇 가지를 심층적으로 살펴보고, 이러한 아키텍처의 성능과 확장성에 대한 실험 결과를 상세히 제시합니다.

블록체인 업계는 체인의 고성능과 확장성을 위해 끊임없이 노력해 왔습니다. 멀티체인과 레이어2 시스템이 등장했음에도 불구하고 각 스마트 컨트랙트를 실행하는 능력은 여전히 단일 가상머신 VM의 용량에 의해 제한됩니다. 병렬 가상 머신의 등장으로 이러한 제한이 깨졌습니다. 병렬 VM을 사용하면 단일 스마트 컨트랙트의 트랜잭션을 여러 EVM/VM에서 동시에 실행할 수 있으므로 더 많은 CPU 코어를 활용하여 성능을 향상시킬 수 있습니다.

병렬 VM을 지원하는 많은 고성능 블록체인 시스템 중 세이(V2), 앱토스, 수이, 크리스탈리티, PREDA가 가장 대표적이며, 각 시스템은 설계상 독특한 장점을 제공합니다.

이 백서의 서두에서는 첫 번째 실험 결과를 보여주었습니다. 아래 그래프는 128코어 머신에서 동일한 ERC20 스마트 컨트랙트를 실행할 때 세이, 앱토스, 수이, 크리스탈리티, PREDA의 초당 절대 트랜잭션 수(TPS)를 보여줍니다. 이 실험 결과를 보면, 5가지 병렬 실행 시스템의 TPS와 확장성 비교에서 PREDA 모델이 크게 우세한 것으로 나타났습니다.

다른 실험 데이터와 분석 결과는 나중에 더 자세히 설명하겠습니다.

<사진>< img src="https://img.jinse.cn/7289976_watermarknone.png" data-attrs="{" src": "https:="" substack-post-media.s3.amazonaws.com="" public="" "" images="" 047846A1-e372-43d6-bc3a-0a26748c6df7_512x384.png", "srcnowatermark":null, "fullscreen":null, "imagesize":null, "height":384 ,"width":512,"resizewidth":null,"bytes":null,"alt":null,"title":null,"type":null,"href":null,"belowthefold":true,"topimage":false,"internalredirect":null,"imagesize":null,"imagesize":null,"height":384,"imagesize":null,"imagesize":null,"height":384 "internalredirect":null}"="" class="sizing-normal" alt="" srcset="https://substackcdn.com/image/fetch/w_424,c_limit,f_auto,q_auto. good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F047846a1-e372-43d6-bc3a- 0a26748c6df7_512x384.png 424w, https://substackcdn.com/image/fetch/w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A% 2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F047846a1-e372-43d6-bc3a-0a26748c6df7_512x384.png 848w, https:// substackcdn.com/image/fetch/w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws. com%2Fpublic%2Fimages%2F047846a1-e372-43d6-bc3a-0a26748c6df7_512x384.png 1272w, https://img.jinse.cn/7289976_watermarknone.png 1456w" sizes="100vw" loading="lazy">

다음에서는 실험에 사용된 정확한 방법론과 작업에 대해 자세히 설명합니다.

우리는 먼저 5개 시스템의 TPS 값, 즉 처리량을 비교하는 것으로 시작했습니다. 서로 다른 체인에서 수행된 TPS 비교 실험에는 동일한 트랜잭션 볼륨이 사용되었습니다.

각기 다른 시스템에서 사용되는 프로그래밍 언어와 기본 VM이 다르기 때문에 단일 처리량 비교로는 시스템의 강점과 약점을 완전히 설명할 수 없기 때문에 상대적인 속도 향상 결과, 즉 하나의 VM에 비해 여러 VM에서 실행된 동일한 수의 트랜잭션의 속도 향상 비율인 속도 향상 비율 비교도 수행했습니다. 수이, 앱토스, 크리스탈리티, PREDA에서는 각 스레드에 전용 CPU 코어가 할당됩니다.

절대 TPS 값과 속도 향상 비율을 포함한 모든 자세한 실험 데이터는 전체 실험 보고서를 참조하십시오.

다음 표는 실험에 사용된 데이터 소스, 구현 프로세스 및 평가 방법론을 보여줍니다.

<사진>

병렬 실행 모델 살펴보기

앱토스와 수이는 모두 한때 페이스북으로 알려진 메타의 실패한 블록체인 프로젝트에서 파생된 프로젝트입니다. 두 프로젝트 모두 전직 메타 엔지니어가 설립한 것으로, 앱토스는 에이버리 칭이, 수이는 샘 블랙셔가 설립했습니다. 이후 두 프로젝트는 서로 다른 기술 경로를 따랐으며, 앱토스는 디엠을 위해 개발된 오리지널 무브 프로그래밍 언어를 엄격하게 따르지만, 수이는 무브에 여러 가지 수정을 가했습니다.

다음에서는 앱토스와 수이의 병렬화 모델의 차이점을 살펴보고, 서로 다른 접근 방식이 성능에 어떤 영향을 미치는지 분석하며, 각자의 강점을 강조하겠습니다.

앱토스: 낙관적 병렬화를 사용하는 고성능 레이어 1

앱토스는 낙관적 병렬화 메커니즘을 통해 스마트 콘트랙트의 병렬 실행을 가능하게 함으로써 고성능을 달성하는 레이어 1입니다. 특히 낙관적 병렬화에서는 트랜잭션이 처음에 상태 충돌이 없는 것으로 가정하고 병렬로 실행합니다. 실행 후 시스템은 충돌을 확인하고 충돌하는 트랜잭션을 직렬 실행 방식 또는 다른 스케줄링을 통해 롤백하고 다시 실행하여 충돌을 해결합니다. 이러한 추측 실행 방식은 대부분의 트랜잭션이 충돌하지 않는다고 가정하므로 병렬 실행의 이점을 극대화하는 동시에 충돌 처리를 위한 폴백 메커니즘을 제공합니다.

낙관적 병렬화의 장점: (1) 프로그램 수정이 필요 없음: 기존 코드를 변경하지 않고도 쉽게 구현할 수 있습니다. (2) 충돌 비율이 낮거나 중간 정도인 시나리오에서의 효율성: 많은 트랜잭션이 동시에 진행되도록 허용하고 충돌이 발생하는 즉시 처리함으로써 처리량을 극대화하며, 실제 시나리오에서는 충돌 비율이 상대적으로 낮은 경우가 많습니다.

앱토스는 스마트 컨트랙트 개발을 위해 MOVE 프로그래밍 언어를 사용하고 시스템 구현을 위해 앱토스 무브 가상 머신을 사용합니다.

Sui: 비관적 병렬화를 사용하는 고성능 레이어 1

Sui는 비관적 병렬화 전략을 사용합니다. 비관적 병렬화에서는 시스템이 트랜잭션을 실행하기 전에 가능한 리소스 경합을 미리 확인합니다. 프로그래머는 각 트랜잭션이 액세스해야 하는 리소스(즉, 상태)를 지정해야 합니다. 시스템은 들어오는 각 트랜잭션을 사전 검사하여 잠재적인 충돌을 감지합니다. 현재 실행 중인 트랜잭션과 리소스 경합이 없는 트랜잭션만 병렬 실행을 위해 실행 엔진으로 전송됩니다.

비관적 병렬화의 장점: (1) 롤백 방지: 이 접근 방식은 실행 전에 충돌을 식별하고 방지함으로써 롤백 및 재실행의 필요성을 최소화하여 보다 예측 가능한 성능을 제공합니다. (2) 충돌이 많은 시나리오에서의 효율성: 충돌이 많은 환경에서 매우 효과적이며, 충돌하지 않는 트랜잭션만 병렬로 실행되도록 하여 충돌 해결과 관련된 오버헤드를 줄입니다.

Sui는 MOVE 프로그래밍 언어도 사용하지만, 자체적인 Sui MOVE 확장 기능을 갖추고 있으며 시스템 구현에 Sui MOVE 가상 머신을 사용합니다.

Sei: 견고성과 EVM 호환성을 갖춘 최적의 병렬화

Sei는 처음에 코스모스 SDK에 구축된 트랜잭션 애플리케이션 체인으로 퍼블릭 체인으로 출시되었으며, 최초의 병렬화된 EVM 체인으로 업그레이드되었습니다. 병렬 실행 수준에서 세이는 낙관적 병렬화라고 부르는 앱토스 모델과 유사한 접근 방식을 사용합니다.

Sei(V2)에서 사용하는 낙관적 병렬화는 솔리디티 프로그래밍 언어와 표준 이더넷 가상 머신(EVM)을 사용하여 EVM과 솔리디티의 호환성을 보장한다는 점에서 차별화됩니다.

Crystality 및 PREDA: 병렬 릴레이 실행 분산 아키텍처

Crystality와 PREDA는 모두 다중 참여자, 다중 분야, 다중 당사자 실행을 지원하도록 설계된 병렬 릴레이 실행 분산 아키텍처(PREDA, Parallel Relay-Execution Distributed Architecture)를 지원합니다. PREDA는 다중 EVM 블록체인 아키텍처에서 일반 스마트 컨트랙트를 병렬화하기 위해 특별히 설계되었습니다. 둘 사이의 관계는 크리스탈리티가 PREDA 모델에 기반한 병렬 EVM/GPU용 프로그래밍 언어라는 점입니다. 시스템 관점에서 볼 때, PREDA는 블록체인 업계 최초로 컨트랙트 기능을 완전히 병렬화하여 트랜잭션 세트의 동시성을 극대화할 수 있게 해줍니다. 이를 통해 모든 EVM 인스턴스의 효율적인 활용을 보장하여 주어진 하드웨어 구성에 맞는 최적의 성능과 확장성을 제공합니다.

Solidity와 Move의 순차적 실행 및 Shared Everything의 아키텍처 설계와 달리, PREDA 모델은 병렬 실행에서 상태 의존성을 깨뜨리기 위해 처음으로 Shared Nothing 아키텍처를 채택하여 서로 다른 EVM 인스턴스가 동일한 계약 상태에 액세스하지 않도록 보장하므로 거의 완전한 쓰기 충돌을 피할 수 있습니다. 충돌을 방지합니다.

PREDA에서 컨트랙트 함수는 여러 개의 정렬된 단계로 분해되며, 각 단계는 병렬 실행이 가능하고 충돌이 없는 상태의 일부에 의존합니다. 사용자가 시작한 트랜잭션은 먼저 사용자 주소의 상태를 보관하는 EVM으로 전송됩니다. 트랜잭션이 실행되는 동안 데이터 이동 없이 실행 흐름을 구현할 수 있으며, 현재 관리에 필요한 컨트랙트 상태를 보유한 한 EVM에서 다른 EVM으로 전환하는 릴레이 트랜잭션을 발행하여 데이터 종속성에 따라 EVM 간에 실행 흐름을 이동할 수 있습니다.

대표적인 5개 컨트랙트에 대한 실험 데이터

이번 평가에서는 널리 사용되는 5개의 스마트 컨트랙트, 즉 ETH 토큰 전송, 투표, 에어드랍을 테스트했습니다, 크립토키티와 밀리언픽셀, 마이토큰(ERC20)을 테스트했습니다. 이러한 계약은 세이, 앱토스, 수이, 크리스탈리티, 프레다 등 다양한 블록체인 시스템에서 실행됩니다. 저희는 각 시스템별로 단일 가상머신에 비해 여러 가상머신에서 실행할 때 상대적인 성능 향상을 측정하는 초당 트랜잭션 수(TPS)와 가속 비율에 중점을 두고 다양한 병렬 실행 시스템의 성능을 비교하기 위해 세부적인 실험을 진행했습니다.

절대 TPS 값과 가속 비율을 포함한 모든 자세한 실험 데이터는 전체 실험 보고서를 참조하세요.

1. ETH 토큰 전송 컨트랙트: 이 실험에서는 표준 ERC20 스마트 컨트랙트와 동일한 실제 과거 ETH 트랜잭션을 사용했습니다.

2. 투표 컨트랙트: 투표 컨트랙트는 PREDA 모델이 어떻게 병렬 투표 알고리즘을 단순화하는지를 보여주는 좋은 예입니다. 이는 크리스탈리티와 PREDA의 데이터 분할, 릴레이, 실행 메커니즘을 활용하여 절대 TPS와 속도 향상 비율 측면에서 낙관적(앱토스)과 비관적(수이) 병렬화 방식 모두보다 뛰어난 성능을 발휘합니다. 솔리디티의 순차 알고리즘은 이제 VM 간 병렬 투표와 임시 어레이의 결과 집계가 가능합니다.

3. 에어드랍: 이 컨트랙트는 한 주소에서 여러 주소로 여러 토큰 또는 NFT 전송을 트리거합니다. 일대다 상태 변경 모드가 있습니다. 이 경우 세이, 앱토스 또는 수이에서 두 개의 트랜잭션을 동시에 실행할 수 없습니다. 더 세분화된 병렬성을 가진 PREDA 모델을 통해서만 파이프라인 모드에서 이러한 트랜잭션을 병렬로 처리할 수 있습니다.

4. 크립토키티: 이 계약은 부모 고양이의 유전자를 기반으로 자손 고양이를 번식하는 이더리움의 인기 게임 계약입니다. 이전 계약과 달리 이 계약은 사용자가 시작한 거래를 처리할 때 '부모 고양이', '어미 고양이', '갓 태어난 고양이' 등 여러 주소 상태에 대한 액세스가 필요합니다. 또한 이 컨트랙트는 부모의 유전자로부터 신생 고양이의 유전자를 계산할 때 이전 컨트랙트보다 더 복잡한 계산을 포함합니다.

5. 밀리언픽셀: 이더리움의 이 게임 컨트랙트에서 사용자는 지도에 좌표를 표시하기 위해 서둘러야 합니다. 이 스마트 컨트랙트는 PREDA 모델의 유연성을 보여주기 위해 사용됩니다. 프로그래머는 컨트랙트 상태를 주소별로 분할하는 것 외에도, 예를 들어 이 경우 주소 유형에서 uint32 유형으로 전환하는 등 분할 키를 커스터마이징할 수 있습니다.

   <그림>

   <그림>

위에서 설명한 방대한 양의 데이터에 대한 독자들의 이해를 돕기 위해 다음은 특히 대표적인 두 가지 계약에 대한 분석에 초점을 맞추고 있습니다.

ETH 토큰 전송 계약: 과거 ETH 거래 데이터를 재생했을 때, 5개 시스템 모두의 절대 처리량과 확장성 비율은 ERC20 실험보다 감소했습니다. 이는 과거 트랜잭션의 중복 주소로 인한 상태 경합(읽기-쓰기 충돌 또는 쓰기-쓰기 충돌)으로 인해 병렬 EVM에서 이러한 트랜잭션을 동시에 실행할 수 없기 때문입니다.

투표 컨트랙트: 세이 컨트랙트는 거의 전적으로 순차적으로 실행되며, 여러 EVM을 실행할 때 속도가 빨라지지 않습니다. 알고리즘을 병렬 알고리즘으로 변환하지 않으면 다른 시스템에서도 비슷한 결과를 볼 수 있습니다. 앱토스 및 수이의 병렬 구현의 경우, "제안" 변수의 임시 결과를 위해 여러 리소스를 서로 다른 주소에서 초기화해야 합니다. 또한 병렬 구현은 유권자의 주소를 기반으로 수동 스케줄링을 제공하고, 유권자의 트랜잭션을 다른 가상 머신으로 전송하며, 병렬 실행을 위한 임시 결과에 액세스해야 합니다.

실험 결과에서 얻은 인사이트

실험 결과를 통해 다음과 같은 사실을 알게 되었습니다.

낙관적 접근 방식과 비관적 접근 방식의 대조

앱토스와 수이는 각각 다른 특정 시나리오에서 최고의 성능을 발휘합니다. ERC20 전송의 경우, 각 트랜잭션에 대해 무작위로 생성된 주소를 사용하므로 충돌이 거의 발생하지 않기 때문에 앱토스가 수이보다 성능이 뛰어납니다. 반면, 이더리움 테스트 케이스에서는 과거 이더리움 트랜잭션 재생과 관련된 충돌이 많기 때문에 수이가 앱토스보다 성능이 뛰어납니다.

앱토스 실행 시간 분석

다음 표는 동일한 스마트 컨트랙트를 사용하지만 무작위로 생성되거나 과거 거래 데이터를 사용하여 두 컨트랙트를 실행할 때 앱토스에 대한 성능 분석 데이터를 보여줍니다. 데이터는 각각 무작위로 생성된 데이터 또는 과거 트랜잭션 데이터입니다). 성능 분석의 시간 소모적인 특성으로 인해 테스트에 사용된 병렬 가상 머신의 수는 최대 64개로 제한되었습니다.

앱토스의 거래 체결은 체결과 검증의 두 단계로 구성되며, 테스트 데이터에 따르면 체결 상태가 "SUSPEND"로 표시된 많은 수의 거래가 체결에 오랜 시간이 걸리는 것으로 나타났습니다. "SUSPEND"는 상태 종속성이 해결될 때까지 트랜잭션 실행이 일시 중지됨을 의미합니다. 64개의 VM에서 무작위 트랜잭션의 경우, 총 실행 및 유효성 검사 횟수는 각각 102,219회와 139,426회였습니다. 기록 트랜잭션의 경우, 이 수치는 186,948개와 667,148개로 증가하고 트랜잭션 중단 횟수는 66회에서 46,913회로 증가합니다. 그 결과, 트랜잭션 실행에 상태 충돌이 많을 때 롤백은 낙관적 병렬화에 큰 부담이 됩니다.

수이 실행 시간 분석

다음 도표는 이더 토큰 전송 컨트랙트 테스트와 투표 컨트랙트 테스트에서 수이가 소요된 시간을 분석해 보여줍니다. Sui의 병렬 실행 엔진에는 세 가지 주요 단계가 있습니다: (1) 대기 시간: 트랜잭션 매니저가 트랜잭션을 선택하기까지의 대기 시간, (2) 작업 관리 시간: 트랜잭션이 Sui의 실행 중인 Txns 해시맵 또는 대기 중인 Txns 해시맵에 배치되고 Sui의 실행 드라이버가 이를 수신하기까지의 시간, (3) ) 함수 실행 시간: 컨트랙트 함수가 실행 드라이버의 워커 스레드에 의해 실행되는 시간입니다.

<그림>

작업 관리 시간에는 잠금 및 대기 구성 요소가 모두 포함됩니다. 이 두 차트를 비교해보면 전체 실행 시간 대비 작업 관리 시간이 이더 토큰 전송 테스트보다 투표 테스트에서 훨씬 더 길다는 것을 알 수 있습니다. 이는 투표 테스트에서 공유 객체에 액세스하려면 충돌을 피하기 위해 잠그고 대기해야 하기 때문에 작업 관리 시간이 함수 실행 시간 및 대기 시간보다 2~4배 더 길기 때문입니다. 반면, 이더 토큰 전송 테스트에서는 동시성 제어를 우회하여 소유 오브젝트만 사용하므로 작업 관리 시간이 훨씬 짧습니다.

앱토스와 수이의 한계

요약하자면, 앱토스는 낙관적 병렬화를 사용하여 충돌이 있는 경우에도 병렬 트랜잭션 실행을 허용합니다. 이러한 낙관적 동시성 제어(OCC) 기반 접근 방식은 쓰기 요청이 드문 데이터베이스와 빅데이터 시스템에서 흔히 볼 수 있는 읽기 기반 워크로드에 잘 작동합니다. 그러나 블록체인 시스템에서는 온체인 실행과 관련된 가스 비용으로 인해 이 접근 방식은 상당한 가스 오버헤드를 발생시킬 수 있습니다. 실제로 사용자는 일반적으로 읽기 전용 요청(예: 기록 트랜잭션 또는 블록 쿼리)은 이더스캔과 같은 오프체인 데이터베이스로 전송하고, 쓰기 요청은 온체인 실행에 사용합니다. 이 경우 앱토스와 같은 OCC 시스템은 트랜잭션 "일시 중단"과 중단이 자주 발생하여 병렬 가상 머신의 전반적인 성능이 저하됩니다.

반면, Sui는 비관적 병렬화를 사용하여 트랜잭션 간의 상태 종속성을 엄격하게 검증하고 잠금 메커니즘을 통해 실행 중 충돌을 방지합니다. 이 비관적 동시성 제어(PCC) 기반 접근 방식은 PCC와 관련된 오버헤드가 무시할 수 있을 정도로 적은 컴퓨팅 집약적 워크로드에 더 적합합니다. 그러나 논리적으로 단순한 작업에서는 PCC 관련 오버헤드가 쉽게 성능 병목 현상이 될 수 있습니다. 실제 블록체인 시스템에서 실행되는 ERC20 토큰 전송, 무브 토큰 전송, NFT 전송과 같은 많은 트랜잭션은 비교적 간단한 연산을 수반합니다. 구체적으로 ERC20 토큰 전송은 일반적으로 한 주소에서 일정 금액을 빼고 다른 주소에 더하는 방식으로 이루어집니다. 마찬가지로 토큰 이동 전송 또는 NFT 전송은 리소스나 객체를 한 주소에서 다른 주소로 이동하는 작업입니다. 이러한 작업은 소유권 확인과 같은 추가 확인을 고려하더라도 매우 빠릅니다. 이 시점에서 PCC와 관련된 오버헤드는 병렬 시스템의 성능을 제한하는 요소가 됩니다.

이러한 문제를 해결하기 위해 PREDA는 PCC 오버헤드와 OCC 재실행의 필요성을 거의 완전히 피할 수 있는 시스템을 제안합니다. 이 접근 방식은 체인 상태를 효율적으로 분할하여 사실상 충돌이 없는 병렬 실행을 달성합니다.

크리스탈리티와 PREDA의 성능

크리스탈리티와 PREDA는 모든 컨트랙트 테스트에서 세이, 앱토스, 수이보다 훨씬 뛰어난 성능을 보였으며, PREDA는 WASM이 아닌 네이티브 바이너리 모드로 실행되므로 더 뛰어난 성능을 보였습니다. PREDA의 성능이 특히 우수한 이유는 WASM이 아닌 네이티브 바이너리 모드에서 실행되기 때문입니다. 이러한 높은 성능은 사실상 충돌이 없는 병렬 실행에 기인하며, PREDA는 두 가지 핵심 측면을 염두에 두고 설계되었습니다.

1. 시스템이 상태를 분할하고 유지하는 데 사용할 다양한 범위의 컨트랙트 상태를 정의할 수 있습니다.

2. 트랜잭션의 실행 흐름을 한 가상머신에서 다른 가상머신으로 전환할 수 있도록 합니다.

PREDA의 핵심은 컨트랙트 상태를 겹치지 않고 병렬화가 가능한 세분화된 조각으로 분할하는 프로그래밍 가능한 컨트랙트 범위와 비동기 기능 릴레이 (...)의 도입입니다. 비동기 함수형 릴레이)로 서로 다른 EVM 간의 실행 흐름 전환을 설명합니다.

이러한 개념의 의미를 더 설명하자면, PREDA에서 컨트랙트 함수는 여러 단계로 분해되며, 각 단계는 충돌을 일으키지 않는 병렬 처리가 가능한 단일 상태 조각에 의존합니다.

예를 들어, 토큰 전송은 일반적으로 발신자의 상태에 액세스하여 지정된 양의 토큰을 추출하는 추출 단계와 수신자의 상태에 액세스하여 적절한 양의 토큰을 입금하는 입금 단계의 두 단계로 이루어집니다. 최근 세이, 앱토스, 수이에서 구현한 것과 같은 병렬 메커니즘은 다음과 같은 시도를 합니다. 각 트랜잭션의 모든 단계의 실행을 동기화합니다. 발신자 또는 수신자가 동일한 경우와 같이 두 트랜잭션 간에 액세스된 상태가 공유되거나 업데이트되면 두 트랜잭션이 병렬로 실행될 수 없습니다.

그러나 PREDA는 트랜잭션의 단계가 데이터 액세스 종속성에 따라 분해되어 각 단계가 다른 단계와 독립적으로 비동기적으로 실행될 수 있는 분리형 비동기 메커니즘을 채택하고 있습니다. 동일한 상태에 대한 액세스는 원래 트랜잭션 블록에서 결정된 순서대로 엄격하게 직렬화되며 합의 알고리즘, 즉 블록 생성자에 의해 정렬된 알고리즘에 의해 보장됩니다.

예를 들어, 토큰 전송 트랜잭션 Txn 0(주소 상태 A에서 상태 B로 토큰 전송)과 Txn 1(상태 A에서 상태 C로 전송)은 순서대로 A에 두 번 액세스한 다음(각각 Txn 0과 Txn 1의 경우) B와 C에 병렬로 액세스할 수 있습니다.

<사진>

<사진>

앱토스, 세이, PREDA의 병렬 실행 아키텍처 비교

PREDA의 한계 및 크리스탈리티의 한계

PREDA와 크리스탈리티는 블록체인 시스템을 강화하고 상당한 성능 이점을 제공할 수 있지만, 다음과 같은 한계도 있습니다.

병렬 EVM 간의 워크로드 불균형

크리스탈리티의 데이터 분할 및 실행 흐름 리디렉션 메커니즘은 런타임에 병렬 EVM의 부하 불균형을 초래할 수 있습니다. 마이토큰 컨트랙트로 과거 이더리움 토큰 전송 트랜잭션을 재생할 때 이 문제가 관찰되었습니다.

부하 분포를 평가하기 위해 원본 트랜잭션과 릴레이 트랜잭션을 모두 포함하여 각 EVM에서 실행된 트랜잭션의 수를 세고 이 숫자의 극성과 표준 편차를 계산했습니다. 그 결과 64개의 EVM에서 실행된 거래 수의 극단적인 편차가 2개의 EVM에서 실행된 범위와 비슷한 것으로 나타났는데, 이는 일부 EVM 주소에 핫스팟 문제(즉, 일부 주소에서 발생한 기록 거래가 집중되는 현상)가 있음을 시사합니다. 이더리움 데이터 세트에 대한 추가 조사 결과, 각 핫스팟 주소에는 4000개 이상의 트랜잭션이 포함된 것으로 나타났습니다. 여기서 중요한 점은 앱토스와 수이 역시 이 경우 병렬화된 실행을 할 수 없다는 점입니다.

테스트 데이터에 따르면 EVM의 수가 증가할수록 표준편차가 감소하는 것으로 나타났는데, 이는 EVM을 더 추가하면 부하 불균형 문제를 완화하는 데 도움이 된다는 것을 의미합니다.

블록체인의 핫스팟 문제를 해결하기 위해 하나의 주소 대신 여러 주소를 사용하여 토큰을 주고받는 것도 한 가지 해결책이 될 수 있습니다. 동일한 가상 머신에 매핑된 여러 개의 핫스팟이 아닌 주소로 인해 부하 불균형이 발생하는 경우, 데이터 마이그레이션과 같은 샤딩 블록체인의 기존 방법이 도움이 될 수 있습니다.

절차적 재작성

PREDA와 크리스탈리티의 또 다른 주목할 만한 한계는 개발자가 지시문을 사용해 스마트 콘트랙트를 재작성해야 한다는 것입니다. 솔리디티, 무브 또는 러스트로 작성된 기존 스마트 컨트랙트를 동일한 크리스탈리티 스마트 컨트랙트로 자동 변환할 수 있는 도구가 있다면 개발자 경험을 크게 최적화할 수 있습니다. 이전 경험으로 볼 때 구현하는 것은 그리 어렵지 않아 보이며, 이미 솔리디티에서 무브, 파이썬에서 솔리디티 등 다른 언어 간의 번역을 연구한 바 있습니다.

자연어 처리의 기술적 발전은 자동화된 코드 생성의 가능성을 크게 향상시켰습니다. 이러한 발전은 빅 데이터를 위한 SQL-to-MapReduce 번역, 딥러닝을 위한 계산 그래프-to-matrix 번역과 같은 규칙 및 패턴 기반 컴파일러 번역 기술과 결합되어 스마트 계약을 위한 자동화된 번역 도구의 개발을 촉진할 수 있는 좋은 입지를 확보하고 있습니다.

결론

세이, 앱토스, 수이, 크리스탈리티/PREDA 간의 성능 비교는 진화하는 블록체인 병렬화 분야를 강조합니다. 앱토스(세이와 함께)와 수이는 각각 낙관적, 비관적 병렬화 메커니즘의 가능성을 보여주며 각각 다른 시나리오에서 장점을 입증하고 있습니다. 그러나 Crystality와 PREDA의 상당한 성능 향상은 더 높은 수준의 확장성과 효율성을 실현하는 데 있어 더 진보된 병렬화 모델이 핵심이 될 수 있음을 시사합니다.

블록체인 공간에서 병렬화에 대한 세 가지 주요 접근 방식에 대한 탐구와 관찰을 요약하기 위해 요약 표를 작성했습니다. 이 포스팅의 핵심을 파악하고 싶으시다면 이 표에 있는 내용을 참고하시기 바랍니다.

<사진>