PREDA: 병렬 가상 머신 퍼즐의 마지막 조각

작성자: PREDA 출처: chainfeeds

추상

컴퓨터 병렬 처리의 역사를 살펴봅니다: 첫 번째 병렬 처리 수준은 명령어 수준 병렬 처리였습니다. 명령어 수준 병렬 처리는 20세기 마지막 20년 동안 아키텍처가 성능을 향상시킨 주요 방식이었습니다. 명령어 수준 병렬 처리는 프로그래머들이 특히 선호하는 프로그램의 바이너리 호환성을 유지하면서 성능을 향상시킵니다. 명령어 수준 병렬 처리에는 두 가지 유형이 있습니다. 한 가지 유형은 시간적 병렬 처리 또는 명령어 파이프라이닝입니다. 명령어 파이프라인은 자동차를 생산하는 공장의 조립 라인과 같은 것으로, 자동차 생산 공장에서는 한 대의 자동차가 적재될 때까지 기다렸다가 다음 자동차 생산을 시작하는 대신 여러 번에 걸쳐 여러 대의 자동차를 동시에 생산합니다. 공간 병렬화의 또 다른 유형은 다중 발사 또는 수퍼스칼라입니다. 다중 실행은 여러 차선이 있는 도로와 같고, 순서 외 실행은 여러 차선에서 추월을 허용하는 것으로, 효율성을 높이기 위해 슈퍼스칼라와 순서 외 실행을 함께 사용하는 경우가 많습니다. 1980년대 RISC의 등장 이후 명령어 수준 병렬 처리의 발전은 이후 20년 동안 정점에 달했으며, 2010년 이후에는 명령어 수준 병렬 처리에 대해 더 이상 파고들 여지가 거의 없었습니다.

두 번째 병렬 처리 수준은 데이터 수준 병렬 처리로, 주로 단일 명령 스트림 다중 데이터 스트림(SIMD) 벡터 구조를 가리킵니다. 최초의 데이터 레벨 병렬 처리는 ENIAC에 등장했으며, 1960년대와 1970년대에는 Cray로 대표되는 벡터 머신이 Cray-1, Cray-2, 이후 Cray X-MP, Cray Y-MP에 이르기까지 매우 인기가 있었습니다. SIMD는 Cray-4 이후 한동안 휴면 상태였으나 이제 다시 활성화되기 시작하여 점점 더 일반적으로 사용되고 있습니다. 예를 들어, X86의 AVX 멀티미디어 명령어는 256비트 경로에서 4개의 64비트 연산 또는 8개의 32비트 연산을 수행할 수 있습니다. SIMD는 명령어 수준의 병렬 처리를 효과적으로 보완하는 미디어 스트리밍에서 중요한 역할을 하며, 초기에는 주로 전용 프로세서에서 사용되다가 현재는 범용 프로세서에서 표준으로 사용되고 있습니다.

세 번째 병렬 처리 수준은 작업 수준 병렬 처리입니다. 작업 수준 병렬 처리는 인터넷 애플리케이션에 많이 존재합니다. 작업 수준 병렬 처리는 멀티코어 프로세서와 멀티스레드 프로세서로 대표되며, 현재 컴퓨터 아키텍처에서 성능을 향상시키는 주요 방법입니다. 작업 수준 병렬 처리는 단일 스레드에서 수백 개 이상의 명령어를 처리하는 높은 수준의 병렬 처리 세분성을 갖습니다.

병렬 컴퓨팅의 발전이라는 관점에서 볼 때 오늘날의 블록체인은 첫 번째 수준에서 두 번째 수준으로 변화하는 과정에 있습니다. 주류 블록체인 시스템은 일반적으로 싱글 체인 또는 멀티 체인 아키텍처를 채택합니다. 비트코인이나 이더리움과 같은 단일 체인 시스템은 하나의 체인을 가지고 있으며, 체인의 각 노드는 정확히 동일한 스마트 계약 트랜잭션을 실행하고 정확히 동일한 온체인 상태를 유지합니다. 각 블록체인 노드 내에서 스마트 콘트랙트 트랜잭션은 일반적으로 순차적으로 실행되기 때문에 시스템 전반의 처리량이 낮습니다.
최근 단일 체인 아키텍처를 사용하면서도 스마트 콘트랙트 트랜잭션의 병렬 실행을 지원하는 고성능 블록체인 시스템도 등장했습니다. 브라운 대학교와 예일 대학교의 토마스 디커슨과 모리스 헐리히 등은 PODC'17 논문에서 STM(소프트웨어 트랜잭션 메모리) 접근법을 기반으로 하는 병렬 실행 모델을 처음으로 제안했습니다. 이 접근 방식은 낙관적 병렬 처리를 통해 여러 트랜잭션을 병렬로 실행하고, 병렬 실행 중 트랜잭션이 상태 액세스 충돌을 만나면 STM을 통해 상태를 롤백한 후 충돌하는 트랜잭션을 순차적으로 실행합니다. 이 접근 방식은 앱토스, 세이, 모나드 등 여러 고성능 블록체인 프로젝트에 적용되었습니다. 이와 대조적으로 또 다른 병렬 실행 모델은 비관적 동시성을 기반으로 하며, 트랜잭션이 병렬로 실행되기 전에 충돌하는 상태 액세스가 있는지 테스트하고 충돌하지 않는 트랜잭션만 병렬로 실행합니다. 이 접근 방식은 일반적으로 프로그램 분석 도구를 사용하여 스마트 컨트랙트 코드를 정적으로 분석하고 방향성 비순환 그래프(DAG)와 같은 상태 종속성을 구성하는 사전 계산을 수행합니다. 동시 트랜잭션이 시스템에 제출되면 시스템은 트랜잭션이 액세스해야 하는 상태와 상태 간의 종속성을 기반으로 트랜잭션이 병렬로 실행될 수 있는지 여부를 결정합니다. 서로에 대한 상태 종속성이 없는 트랜잭션만 병렬로 실행됩니다. 이러한 유형의 접근 방식은 질리카(코스플릿 버전), 수이 등 고성능 블록체인 프로젝트에서 사용됩니다. 위의 모든 병렬 실행 모델은 시스템의 처리 속도를 크게 높일 수 있습니다. 이 두 가지 방식은 위에서 언급한 명령어 수준의 병렬화에 해당합니다. 그러나 이러한 노력에는 1) 확장성 문제와 2) 병렬 의미 표현 문제라는 두 가지 문제가 있으며, 이에 대해서는 아래에서 자세히 설명하겠습니다.

병렬 설계

모나드 프로젝트의 대표적인 기술 솔루션인 Solana의 예를 사용해 병렬화 분류를 포함한 병렬 아키텍처 설계를 분해해 보겠습니다. 여기에는 병렬화 분류, 데이터 종속성 및 병렬화와 TPS에 영향을 미치는 기타 주요 메트릭이 포함됩니다.

솔라나

솔라나의 설계 철학은 하드웨어가 발전함에 따라 블록체인 혁신도 진화해야 한다는 것입니다. 무어의 법칙에 따라 하드웨어가 계속 발전함에 따라 솔라나는 더 나은 성능과 확장성의 이점을 누리는 것을 목표로 합니다. 솔라나의 공동 창립자인 아나톨리 야코벤코는 5년 전 솔라나의 병렬화 아키텍처를 처음 설계했으며, 오늘날 병렬화는 블록체인 설계 원칙으로 빠르게 확산되고 있습니다.

솔라나는 개발자가 일반적으로 모든 상태를 미리 선언하는 임베디드 시스템에 대한 아나톨리의 과거 경험에서 비롯된 결정론적 병렬화를 사용합니다. 이는 개발자가 일반적으로 모든 상태를 미리 선언하는 임베디드 시스템에 대한 아나톨리의 과거 경험에서 비롯된 것입니다. 이렇게 하면 CPU가 모든 종속성을 인식하고 메모리의 필요한 부분을 미리 가져올 수 있습니다. 그 결과 시스템 실행이 최적화되지만 개발자의 추가 작업이 필요합니다. 솔라나에서는 프로그램의 모든 메모리 종속성이 필요하고 구성된 트랜잭션(즉, 액세스 목록)에서 설명되므로 런타임이 여러 트랜잭션을 효율적으로 예약하고 병렬로 실행할 수 있습니다.
솔라나 아키텍처의 다음 주요 구성 요소는 검증자가 소유한 코어 수에 따라 여러 컨트랙트와 트랜잭션의 병렬 처리를 지원하는 &strong>세일레벨 VM입니다. 블록체인의 검증자는 거래를 검증하고 검증하며, 새로운 블록을 제안하고, 블록체인의 무결성과 보안을 유지하는 역할을 하는 네트워크 참여자입니다. 트랜잭션은 읽기 및 쓰기 잠금이 필요한 계정을 미리 선언하기 때문에 솔라나 스케줄러는 어떤 트랜잭션을 동시에 실행할 수 있는지 결정할 수 있습니다. 따라서 검증 시점에 '블록 생성자' 또는 리더는 수천 개의 보류 중인 트랜잭션을 분류하고 겹치지 않는 트랜잭션을 병렬로 예약할 수 있습니다.

Monad

Monad는 튜링 완전 병렬 EVM의 레이어 1을 구축하고 있습니다.  Monad는 병렬화 엔진뿐만 아니라 백그라운드에서 구축하는 최적화 엔진에서도 독보적입니다. 모나드는 파이프라인, 비동기 I/O, 분할 합의 및 실행, 모나드DB 등 몇 가지 주요 기능을 통합하여 전반적인 설계에 독특한 접근 방식을 취합니다.

세이와 마찬가지로 모나드 블록체인은 낙관적 동시성을 사용합니다. strong>"낙관적 동시성 제어(OCC)를 사용하여 트랜잭션을 실행합니다. 동시 트랜잭션 처리는 시스템에 여러 트랜잭션이 동시에 존재할 때 발생합니다. 이 트랜잭션 방식에는 실행과 유효성 검사의 두 단계가 있습니다.

실행 단계에서는 트랜잭션이 최적으로 처리되고 모든 읽기/쓰기가 트랜잭션별 스토리지에 임시로 저장됩니다. 그 후 각 트랜잭션은 임시 저장소 작업의 정보를 이전 트랜잭션이 변경한 상태와 비교하여 확인하는 유효성 검사 단계로 들어갑니다. 트랜잭션은 독립적인 경우 병렬로 실행됩니다. 한 트랜잭션이 다른 트랜잭션에서 수정한 데이터를 읽으면 충돌이 발생합니다.

모나드 설계의 핵심 혁신 중 하나는 약간의 오프셋이 있는 파이프라인입니다. 이 오프셋을 통해 여러 인스턴스를 동시에 실행하여 더 많은 프로세스를 병렬화할 수 있습니다. 결과적으로 파이프라인은 상태 액세스 파이프라인, 트랜잭션 실행 파이프라인, 합의 및 실행 내 파이프라인, 합의 메커니즘 자체의 파이프라인 등 많은 기능을 최적화하는 데 사용되며, 이는 아래 이미지에서 세탁, 건조, 접기, 옷장 수납에 해당합니다.

모나드에서는 트랜잭션이 블록 내에서 선형적으로 정렬되지만 병렬 실행을 활용하여 최종 상태에 더 빨리 도달하는 것이 목표입니다. 모나드는 실행 엔진을 설계할 때 최적 병렬화 알고리즘을 사용합니다. 모나드의 엔진은 트랜잭션을 동시에 처리한 다음, 트랜잭션이 차례로 실행될 때 결과가 동일한지 분석합니다. 충돌이 발생하면 다시 실행해야 합니다. 여기서 병렬 실행은 비교적 간단한 알고리즘이지만, 이를 Monad의 다른 주요 혁신 기술과 결합하면 새로운 접근 방식이 됩니다. 여기서 한 가지 주목할 점은 재실행이 발생하더라도 유효하지 않은 트랜잭션에 필요한 입력이 거의 항상 캐시에 유지되기 때문에 일반적으로 비용이 적게 들며, 따라서 단순한 캐시 조회가 될 것이라는 점입니다. 블록에서 이전 트랜잭션을 이미 실행했기 때문에 재실행은 확실히 성공할 것입니다.

실행 지연 외에도 모나드는 솔라나 및 세이와 마찬가지로 실행과 합의를 분리하여 성능을 개선합니다. 여기서 아이디어는 합의가 완료되면 실행을 완료하는 조건을 완화하면 두 가지를 병렬로 실행하여 둘 다에 추가 시간을 가져올 수 있다는 것입니다. 물론 모나드는 이러한 상황을 처리하기 위해 결정론적 알고리즘을 사용하여 어느 한쪽이 너무 앞서서 따라잡지 못하도록 합니다.

낙관적 병렬 실행이든 비관적 병렬 실행이든 위에서 설명한 시스템은 공유 메모리를 기본 데이터 모델 추상화로 사용하므로 병렬 실행 유닛 수에 상관없이 병렬 실행 유닛은 모든 데이터(이 경우 블록체인의 모든 온체인 데이터)에 액세스할 수 있으며 상태 데이터는 다른 병렬 실행 유닛에서 직접 액세스할 수 있습니다. 서로 다른 병렬 실행 유닛이 직접 액세스(즉, 모든 온체인 데이터를 병렬 유닛이 직접 읽고 쓸 수 있음). 공유 메모리를 기본 데이터 모델로 사용하는 블록체인 시스템은 일반적으로 단일 물리적 노드(솔라나)로 동시성이 제한되며, 각 물리적 노드의 동시성은 노드의 연산 능력, 즉 물리적 스레드 수에 따라 제한됩니다(각 스레드가 가상 머신을 지원한다고 가정할 때).

이러한 노드 내 병렬화는 시스템 합의 계층의 로직이 아닌 스마트 콘트랙트 실행 계층의 아키텍처만 수정하면 되기 때문에 단일 체인 시스템의 처리 속도를 높이는 데 매우 적합합니다. 결과적으로 데이터 저장소의 샤딩이 없기 때문에 블록체인 네트워크의 각 노드가 여전히 모든 트랜잭션을 실행하고 모든 상태를 저장해야 합니다. 한편, 분산 확장에 더 적합한 공유-무공유 아키텍처에 비해 공유 메모리를 기본 데이터 모델의 추상화로 사용하는 이러한 시스템은 처리 능력 측면에서 수평적 확장, 즉 실행 용량뿐만 아니라 시스템 상태 저장의 확장을 달성하기 위해 물리적 시스템의 수를 늘릴 수 없기 때문에 블록체인의 근본적인 확장성을 해결하지 못합니다. 블록체인은 확장성이 없다는 것이 문제입니다.

그렇다면 기성 솔루션이 있을까요?

병렬 프로그래밍 모델

PREDA를 소개하기 전에 당연한 질문을 던지고 싶습니다: 왜 병렬 프로그래밍을 사용해야 하나요? 병렬 프로그래밍을 사용하는가? 1970년대, 1980년대, 심지어 1990년대 일부까지만 해도 우리는 단일 스레드 프로그래밍(또는 직렬 프로그래밍이라고 불렸던)에 매우 만족했습니다. 어떤 작업을 수행하기 위한 프로그램을 작성할 수 있었죠. 실행이 끝나면 결과가 나왔습니다. 작업이 완료되고 모두가 행복해집니다! 작업이 완료되었지만 초당 수백만 또는 수십억 번의 계산이 필요한 입자 시뮬레이션을 수행하거나 수천 픽셀의 이미지를 처리하는 경우 프로그램이 더 빨리 실행되기를 원하므로 더 빠른 CPU가 필요합니다.
2004년 이전에는 CPU 제조업체인 IBM, Intel, AMD가 점점 더 빠른 프로세서를 제공할 수 있었습니다. 프로세서 클럭은 16MHz, 20MHz, 66MHz, 100MHz, 200MHz, 333MHz, 466MHz... 계속 더 빨라질 것처럼 보였고, 이는 계속 더 좋아질 수 있다는 것을 의미했습니다. 그러나 2004년이 되자 기술적 한계로 인해 CPU 속도 증가가 지속될 수 없다는 것이 분명해졌습니다. CPU 제조업체의 해결책은 두 CPU가 모두 단일 CPU보다 낮은 속도로 작동하더라도 단일 CPU 안에 두 개의 CPU를 넣는 것이었습니다. 예를 들어 200MHz로 작동하는 두 개의 CPU(제조업체는 이를 코어라고 부름)가 함께 작동하면 300MHz로 작동하는 단일 코어 CPU보다 초당 더 많은 계산(즉, 초당 처리하는 연산 수)을 수행할 수 있습니다. 예를 들어, 200MHz로 함께 작동하는 두 개의 CPU(제조업체는 이를 코어라고 부름)는 300MHz로 작동하는 단일 CPU보다 초당 더 많은 계산을 수행할 수 있습니다(즉, 직관적으로 2 x 200 > 300).
'단일 CPU, 다중 코어'라는 꿈처럼 들리던 이야기가 현실이 되었으며, 이제 프로그래머는 두 코어를 모두 활용하기 위해 병렬 프로그래밍 방법을 배워야 합니다. 단일 CPU로 두 개의 프로그램을 동시에 실행할 수 있다면 프로그래머는 두 프로그램을 모두 작성해야 합니다. 하지만 이것이 프로그램을 두 배 빠르게 실행하는 것으로 해석될까요? 그렇지 않다면 2 x 200 & gt; 300 아이디어에는 결함이 있습니다. 하나의 코어가 충분한 작업을 수행하지 못하면 어떻게 될까요? 즉, 하나의 코어만 정말 바쁘고 다른 코어는 아무것도 하지 않는다면요? 이 경우 단일 300MHz 코어를 사용하는 것이 더 나을 것입니다. 멀티코어가 도입되면서 이와 유사한 문제가 많이 발생하고 있으며, 이러한 코어를 효율적으로 사용할 수 있는 유일한 방법은 프로그래밍을 통해서입니다.

아래 이미지에서 밥과 앨리스를 두 명의 금 광부로 가정하고, 금을 캐려면 네 단계가 필요합니다.

1. 광산으로 운전하기

2. 채굴하기

3. 광석 적재

4. 저장 및 광택

< /ol><그림>

< img src="https://img.jinse.cn/7237611_watermarknone.png" title="7237611" alt="Z6TGfEMYxDRumydmxjGaLY7uNAy1sp4WU7EvJXE5.png">

전체 채굴 과정은 개별적이지만 순서대로 진행되는 네 가지 작업으로 구성되며, 각 작업에는 15분씩 소요됩니다. 밥과 앨리스가 동시에 작업을 수행하면 한 시간에 두 배의 채굴량을 채굴할 수 있는데, 각자의 자동차가 있고 도로를 공유할 수 있으며 샌딩 도구를 공유할 수 있기 때문입니다. <하지만 어느 날 밥의 채굴 트럭이 고장난다면 어떨까요? 밥은 트럭을 수리점에 맡기고 그 안에 채굴 도구를 두고 왔습니다. 작업장으로 돌아가기에는 너무 늦었지만 아직 해야 할 일이 남아 있습니다. 앨리스의 채굴 수레와 그 안에 있는 곡괭이 1개만 사용해도 분당 광석 2개를 얻을 수 있을까요?
위의 비유에서 채굴의 네 단계는 스레드, 채굴 카트는 코어, 광석은 스마트 컨트랙트가 실행하는 데 필요한 데이터 단위, 곡괭이는 실행 단위, 프로그램은 서로 의존하는 두 개의 스레드로 구성되며, 스레드 1이 실행을 완료할 때까지 스레드 2는 실행할 수 없으며, 수확한 광물의 수는 프로그램의 성능을 의미합니다. 성능이 높을수록 밥과 앨리스는 더 많은 광물을 캐낼 수 있습니다. 광산을 데이터 단위(금광석)를 얻는 메모리로 생각하면, 스레드 1에서 광석을 채굴하는 것은 메모리에서 데이터 단위를 읽는 것과 비슷합니다.
이제 밥의 채굴 트럭이 고장 나면 어떻게 되는지 살펴봅시다. 밥과 앨리스가 트럭을 공유해야 하는데, 처음에는 문제가 되지 않지만 채굴 장비가 채굴 효율을 보장하도록 업그레이드된 후에는 상황이 달라집니다. 광산에 넣을 수 있는 광석의 양이 전체 효율의 병목이 되는데, 아무리 효율적인 채굴기를 사용하더라도 분쇄기로 보낼 수 있는 광석의 양이 많지 않으므로 전체 효율이 떨어지게 되는 것이죠. 광산 기계의 효율이 아무리 높더라도 분쇄기로 보낼 수 있는 광석의 양은 "광산 수레의 최대 광물 용량"에 의해 제한됩니다.

이것은 솔라나의 병렬 가상 머신, 코어 공유의 특성이기도 합니다.

코어 공유

솔라나의 궁극적인 설계 요소는 "파이프라이닝"입니다. 파이프라이닝은 데이터를 일련의 단계를 거쳐 처리해야 하고 각 단계를 담당하는 하드웨어가 다를 때 발생합니다. 여기서 핵심 아이디어는 직렬로 실행해야 하는 데이터를 가져와 파이프라인을 사용하여 병렬화하는 것입니다. 이러한 파이프라인은 병렬로 실행될 수 있으며 각 파이프라인 단계는 서로 다른 트랜잭션 배치를 처리할 수 있습니다. 하드웨어의 처리 속도(채굴 트럭 적재 용량)가 높을수록 병렬화를 위한 스루아웃이 높아집니다. 오늘날 솔라나의 하드웨어 노드 요구사항으로 인해 노드 운영자는 데이터 센터라는 단 하나의 옵션만 남게 되었으며, 이는 효율성을 가져오지만 블록체인의 원래 목적과는 거리가 멀어집니다.

데이터 종속성 미분할(메모리 리소스 공유)

채굴 트럭을 업그레이드한 후 채굴 용량이 따라가지 못해 종종 채우지 못하는 경우가 발생했습니다. 밥은 채굴 효율을 높이기 위해 더 높은 비용으로 채굴기를 구입했습니다(실행 단위 업그레이드). 이 경우에도 15분 동안 10개의 광석을 생산할 수 있지만, 여전히 이전처럼 손으로 광석을 갈기 때문에 단위 시간당 더 많은 광석이 더 많은 금으로 전환되지 않고 창고에 더 많은 광석이 쌓이게 됩니다. 이 예는 메모리 액세스가 프로그램 실행 속도를 제한하는 요소일 때 어떤 일이 발생하는지 보여줍니다. 데이터가 얼마나 빨리 처리되는지(즉, 코어가 얼마나 빨리 실행되는지)는 더 이상 중요하지 않습니다. 데이터에 얼마나 빨리 액세스할 수 있는지에 따라 제한됩니다.
컴퓨터에서 가장 느린 부분은 입출력이며, 데이터의 비동기 입출력이 중요해지기 때문에 입출력 속도가 느려지면 심각한 문제가 될 것입니다.
밥이 15분 동안 10개의 광물을 채굴할 수 있는 채굴기를 가지고 있다고 해도 메모리 액세스 경쟁이 발생하면 15분마다 2개의 광물로 제한될 것입니다. 이 문제에 대한 기존의 병렬 블록체인 솔루션은 비관적 실행과 낙관적 실행이라는 두 가지 학설로 나뉩니다.
전자는 데이터를 쓰고 읽기 전에 데이터 상태 종속성을 명확하게 정의해야 하므로 개발자가 선제적인 정적 제어 종속성 가정을 해야 하는데, 스마트 콘트랙트 프로그래밍 영역에서는 현실과 동떨어지는 경향이 있습니다. 후자는 데이터 쓰기에 대한 가정이나 제한을 두지 않으며 충돌이 발생하면 롤백합니다.
모나드의 낙관적인 실행 시나리오를 예로 들어보면, 현실에서는 대부분의 워크로드가 트랜잭션 실행이며 병렬 발생은 생각만큼 많이 일어나지 않습니다. 아래 그래프는 이더리움 하루 동안 가스비 소비의 원천 유형을 보여줍니다. 인기 있는 스마트 콘트랙트만큼 분포가 높지는 않지만, 실제로는 다양한 유형의 트랜잭션 유형이 고르게 분포되어 있지 않다는 것을 알 수 있습니다. 그리고 웹2.0 시대에는 웹2.0 애플리케이션의 요청 대부분이 수정이 아닌 액세스이기 때문에 낙관적 실행의 병렬 로직이 가능합니다. 예를 들어 타오바오와 지터벅은 이러한 앱의 상태를 수정할 기회가 많지 않습니다. 하지만 웹3 공간에서는 정반대로, 대부분의 스마트 컨트랙트 요청이 정확히 상태를 수정하는 것, 즉 원장을 업데이트하는 것이므로 실제로 예상보다 많은 롤백이 발생하여 체인을 사용할 수 없게 만들 수 있습니다.



결론은 모나드가 병렬성을 달성하지만 이론적으로 2배에서 3배 사이인 컨커런시에 상한이 있다는 것입니다. 둘째, 더 많은 VM을 추가하여 확장할 수 있는 방법이 없기 때문에 더 많은 코어가 더 많은 처리 능력을 제공하는 단계에 도달할 수 없습니다. 마지막으로, 모나드는 데이터를 슬라이스하지 않기 때문에 체인의 부풀려진 상태로 인해 발생하는 노드 요구 사항에 대한 해답이 없다는 것도 진부한 이야기입니다. 가정용 컴퓨터가 처리할 수 있는 한계를 넘어서는 노드 요구 사항이 있으며, 메인넷이 출시되면서 데이터를 슬라이스하지 않는다면 모나드도 솔라나의 길을 가는 것은 피할 수 없을 것으로 보입니다. 그리고 마지막으로 중요한 것은 마지막으로, 낙관적인 실행은 블록체인 공간에서 병렬 처리에 적합하지 않습니다.



채굴을 마친 밥은 "왜 앨리스가 돌아와서 샌딩을 할 때까지 기다려야 할까요?"라는 질문을 스스로에게 던졌습니다. 그가 연마하는 동안 저는 차를 실을 수 있고, 연마하는 시간과 차를 싣는 시간이 똑같기 때문에 연마가 가능해질 때까지 기다려야 하는 상황은 발생하지 않을 것입니다. 앨리스가 채굴을 마칠 때까지 제가 계속 운전해서 채굴하면 우리 둘 다 100% 바쁠 수 있습니다." 이 천재적인 아이디어 덕분에 채굴 트럭을 추가하지 않고도 두 배의 효율로 돌아갈 수 있었습니다. 중요한 것은 밥이 스레드가 실행되는 순서인 프로세스를 재설계하여 모든 스레드가 채굴 카트나 돌을 고르는 것과 같은 코어 내 공유 리소스를 기다리는 데 걸리지 않도록 했다는 점입니다.
공유 리소스에 액세스해도 스레드가 대기열에 들어가지 않고 데이터 I/O 파이프라인이 최종 원자성에 도달하는 속도를 제한하지 않도록 스마트 컨트랙트의 상태를 분할하여 올바른 버전의 병렬화를 구현했습니다.
PREDA 모델은 컨트랙트 코드 실행 시점에 컨트랙트 상태에 대한 액세스 구조를 실행 계층에 노출하여 실행 계층이 적절하게 스케줄링하고 실행 결과의 롤백을 완전히 피할 수 있도록 합니다. 이 병렬 모델을 비동기 병렬이라고도 합니다.

비동기 병렬



비동기식 병렬 처리의 경우에만 스레드를 더 추가하면 선형적인 성능 향상이 이루어지기 때문입니다. 앞선 예시처럼 채굴 트럭의 용량을 업그레이드했지만 채굴 장비가 노후화되어 텅텅 비어 있는 것이 아니라, 멀티코어 CPU와 GPU의 차이처럼 공유 코어의 처리 효율이 병렬성의 병목현상이 아닌 것처럼 PREDA의 병렬 실행 환경은 Moand 및 Solana와 근본적인 차이가 있습니다. 병렬성 병목현상도 없고, I/O 읽기/쓰기에서 데이터 의존성 문제도 없으며, 더 중요한 것은 스레드 수가 증가함에 따라 PREDA 병렬 모델의 병렬성이 증가하여 GPU와 유사하다는 점입니다. 블록체인의 논리에서 스레드(VM)가 증가하면 전체 노드의 하드웨어 요구 사항이 감소하여 탈중앙화를 보장하면서 성능이 향상됩니다.





이 병렬 블록체인의 최종 단계에 도달한 업계는 아키텍처 설계 외에도 부족한 부분이 있습니다. 병렬 프로그래밍 언어에 대한 의미론적 표현도 부족합니다.

병렬 프로그래밍 언어의 시맨틱 표현

Nvidia에 CUDA가 필요했던 것처럼 병렬 블록체인에도 새로운 프로그래밍 언어인 PREDA가 필요했습니다. 오늘날 스마트 컨트랙트 개발자들은 병렬로 시맨틱을 표현하고 있어 기본 멀티체인을 효과적으로 활용하지 못합니다. 기본 멀티체인 아키텍처가 제공하는 지원(데이터 샤딩 또는 실행 샤딩 또는 둘 다)을 효과적으로 활용하여 일반적인 스마트 컨트랙트 트랜잭션을 효과적으로 병렬화할 수 없습니다. 모든 시스템에서 사용되는 프로그래밍 언어는 솔리디티, 무브, 러스트 등과 같은 기존의 일반적인 스마트 콘트랙트 프로그래밍 언어입니다. 이러한 프로그래밍 언어는 병렬 시맨틱이 부족합니다. 이러한 프로그래밍 언어에는 병렬 시맨틱을 표현하는 기능, 즉 CUDA와 같은 고성능 컴퓨팅이나 빅데이터에 사용되는 병렬 프로그래밍 모델 및 프로그래밍 언어와 유사한 병렬 단위 간의 제어 및 데이터 흐름을 표현할 수 있는 기능이 없습니다.

스마트 콘트랙트를 위한 병렬 프로그래밍 모델과 프로그래밍 언어가 부족하면 애플리케이션과 알고리즘을 직렬에서 병렬로 재구성할 수 없기 때문에 애플리케이션과 알고리즘이 병렬 실행 기능을 갖춘 기본 블록체인 시스템에 적용되지 못하여 애플리케이션의 실행 효율과 블록체인 시스템의 전체 처리량을 개선하지 못하게 됩니다.

PREDA는 프로그래밍 계약 범위를 통해 계약 상태를 세분화된 수준으로 분할하고, 함수 릴레이 시맨틱을 통해 트랜잭션 실행 흐름을 여러 병렬 실행 엔진에 분해 및 분산하는 분산 프로그래밍 모델을 제안합니다.

이 모델은 또한 프로그래머블 범위를 통해 컨트랙트 상태 분할 체계를 정의하여 개발자가 애플리케이션의 액세스 패턴에 따라 최적화할 수 있도록 합니다. 비동기 함수 릴레이를 사용하면 트랜잭션 실행 흐름을 상태에 액세스해야 하는 실행 엔진으로 이동하여 데이터가 아닌 실행 흐름을 이동할 수 있습니다.

이 모델을 사용하면 개발자가 기본 멀티체인 시스템의 세부 사항을 신경 쓸 필요 없이 컨트랙트 상태를 분산 분할하고 트랜잭션 트래픽을 공유할 수 있습니다. 실험 결과에 따르면 PREDA 모델은 이론적 병렬 한계에 가까운 256개의 실행 엔진에서 최대 18배의 처리량 향상을 달성할 수 있는 것으로 나타났습니다. 파티션 카운터와 스왑 가능한 명령어와 같은 기술을 사용하면 병렬 처리를 더욱 향상시킬 수 있습니다.

결론

블록체인 시스템은 전통적으로 모든 트랜잭션을 처리하기 위해 단일 순차 실행 엔진(예: EVM)을 사용해 확장성이 제한적이었습니다. 멀티체인 시스템은 병렬 실행 엔진을 실행하지만, 각 엔진이 스마트 컨트랙트의 모든 트랜잭션을 처리하기 때문에 컨트랙트 수준에서 확장성이 제한됩니다. 이 글에서는 솔라나로 대표되는 결정론적 병렬 처리의 핵심 공유와 모나드로 대표되는 낙관적 병렬 처리가 실제 블록체인 애플리케이션 시나리오에서 안정적으로 실행되지 못하는 이유 및 롤백이 빈번하게 발생할 수 있는 가능성에 대해 설명합니다. 또한 PREDA의 병렬 실행 엔진을 소개하며, PREDA 팀은 상태를 분할하고 실행 엔진 간에 트랜잭션 트래픽을 분산하여 개별 스마트 컨트랙트를 확장하는 새로운 프로그래밍 모델을 제안합니다. 이는 프로그래밍 가능한 컨트랙트 범위를 도입하여 컨트랙트 상태를 분할하는 방법을 정의합니다. 각 범위는 전용 실행 엔진에서 실행됩니다. 비동기 함수형 릴레이는 원하는 상태가 다른 곳에 있을 때 트랜잭션 실행 흐름을 세분화하여 실행 엔진 간에 이동하는 데 사용됩니다.



트랜잭션 로직을 컨트랙트 상태 분할에서 분리하여 데이터 이동 오버헤드 없이 내재적인 병렬성을 구현할 수 있게 합니다. 병렬 모델은 스마트 컨트랙트 수준에서 상태를 분할하고 데이터 게시 수준에서 종속성을 분리하며 Move와 유사한 멀티스레드 실행 엔진 클러스터 아키텍처를 제공합니다. 더 중요한 것은 블록체인 병렬성 퍼즐의 마지막 조각이 될 수 있는 새로운 프로그래밍 모델인 PREDA를 혁신했다는 점입니다.

<그림>

< img src="https://img.jinse.cn/7237633_watermarknone.png" title="7237633" alt="unk55T6o8UQrcxNrzHK7Kp0rVcep8uly9jt9gVjb.png">