병렬 블록체인의 설계 공간 살펴보기

저자: 알리 셰이크, 암호화폐 분석가, 골든 파이낸스 샤오저우 번역

이 글에서는 솔라나, 세이, 모나드 등 세 가지 관련 사례를 통해 블록체인의 병렬 설계 아키텍처에 대한 개요를 설명합니다.이 글에서는 낙관주의와 결정론적 병렬화의 차이를 강조하고 이러한 체인에서 상태 및 메모리 액세스의 뉘앙스에 대해 이해하고자 합니다.

1, 서문

1837년, 컴퓨터 과학자이자 수학자인 찰스 베이비지는 "분석 엔진 "을 설계하여 병렬 컴퓨팅의 이론적 토대를 마련했습니다. 오늘날 병렬화는 암호화폐 세계에서 핵심 주제이며, 블록체인은 처리량, 효율성, 처리량의 경계를 확장하기 위해 노력하고 있습니다.

병렬 컴퓨팅을 사용하면 연산을 순차적으로 또는 차례로 수행하지 않고도 많은 연산이나 프로세스를 동시에 실행할 수 있습니다. 병렬 컴퓨팅은 큰 문제를 공유 메모리를 통해 통신하는 여러 프로세서에서 실행할 수 있는 여러 개의 작은 독립적인 부분으로 분해하는 것을 말합니다. 병렬 시스템은 효율성 및 속도 향상, 확장성, 안정성 및 내결함성 향상, 리소스 활용 최적화, 대용량 데이터 세트 처리 능력 등 많은 이점을 제공합니다.

현재 병렬화된 블록체인의 상태 액세스를 최적화하는 데는 결정론적 병렬처리와 낙관적 병렬처리라는 두 가지 학설이 있습니다. 결정론적 병렬처리에서는 코드가 블록체인 상태의 어느 부분에 액세스하고 수정할지 미리 명시적으로 선언해야 합니다. 이를 통해 시스템은 충돌 없이 병렬로 처리할 수 있는 트랜잭션을 미리 결정할 수 있습니다. 결정론적 병렬화는 예측 가능성과 효율성을 지원합니다(특히 대부분 독립적인 트랜잭션의 경우). 그러나 개발자에게는 더 많은 복잡성을 초래합니다.

낙관적 병렬 처리에서는 충돌이 발생하지 않는 것처럼 트랜잭션을 병렬로 처리하기 위해 코드가 상태 액세스를 미리 선언할 필요가 없습니다. 충돌이 발생하면 낙관적 병렬 처리는 충돌하는 트랜잭션을 재실행, 재처리 또는 연속적으로 실행합니다. 낙관적 병렬화는 개발자에게 더 큰 유연성을 제공하지만 충돌이 발생하면 재실행이 필요하므로 이 접근 방식은 트랜잭션이 충돌하지 않을 때 가장 효과적입니다. 어떤 접근 방식이 더 나은지에 대한 정답은 없습니다. 단지 병렬화를 구현하기 위한 두 가지 실행 가능한 접근 방식일 뿐입니다.

아래에서는 블록체인 병렬 실행을 위한 설계 공간을 살펴보기 전에 비암호화 병렬 시스템과 관련된 몇 가지 기본 사항을 살펴보고, 암호화 병렬 시스템의 개요, 메모리 및 상태 액세스 방법, 병렬 설계 기회라는 세 가지 핵심 영역에 초점을 맞출 것입니다.

2, 비암호화 병렬 시스템

방금까지 병렬 컴퓨팅의 기능과 병렬 시스템의 장점에 대해 알아보았으니 이제 지난 몇 년 동안 병렬 컴퓨팅이 인기를 얻기 시작한 이유를 쉽게 이해하실 수 있을 것입니다. 그리고 병렬 컴퓨팅은 지난 수십 년 동안 많은 혁신을 이루며 인기를 얻고 있습니다.

• 의료 영상: 병렬 처리는 의료 영상을 근본적으로 변화시켜 다양한 영상 방식(예: MRI, CT, X-레이 및 광학 단층 촬영)에 속도와 효율성을 제공했습니다. 광학 단층 촬영)은 MRI, CT, X-레이 및 광학 단층 촬영과 같은 다양한 이미징 방식에서 속도와 해상도를 크게 향상시켰습니다. NVIDIA는 이러한 발전의 선두에 서서 병렬 처리 툴킷을 통해 방사선 전문의에게 더욱 강력한 AI 기능을 제공하여 이미징 시스템이 더 많은 데이터와 연산 부하를 보다 효율적으로 처리할 수 있도록 지원합니다.

• 천문학: 블랙홀에 대한 이해와 같은 일부 새로운 천문 현상은 병렬 슈퍼컴퓨터를 사용해야만 가능합니다.

• Unity게임 엔진: Unity 엔진은 대규모 그래픽 워크로드용으로 제작된 GPU 성능을 사용하여 성능과 속도를 향상시킵니다. 이 엔진은 원활한 게임 경험을 위한 멀티스레딩 및 병렬 처리 기능을 갖추고 있어 복잡하고 사실적인 게임 환경을 제작할 수 있습니다.

병렬 실행 환경을 구축한 세 가지 블록체인을 살펴봅시다. 먼저 솔라나를 살펴본 다음, 모나드와 세이라는 두 개의 EVM 기반 체인을 살펴보겠습니다.

3, 병렬 설계 개요

( 1)솔라나

솔란의 디자인 철학은 하드웨어가 발전함에 따라 블록체인 혁신도 발전해야 한다는 것입니다. 무어의 법칙에 따라 하드웨어가 시간이 지남에 따라 개선됨에 따라 솔라나의 디자인도 성능과 확장성이 향상될 것이며, 솔라나의 공동 창립자인 아나톨리 야코벤코(Anatoly Yakovenko)는 5년여 전에 솔라나의 독창적인 병렬 아키텍처를 설계했으며 오늘날 병렬성은 블록체인 설계 원칙으로 빠르게 확산되고 있습니다.

솔라나가 결정론적 병렬성을 사용하는 것은 일반적으로 모든 상태가 미리 선언되는 임베디드 시스템에서 일한 아나톨리의 과거 경험에서 비롯되었습니다. 이를 통해 CPU는 모든 종속성을 파악하여 메모리의 필요한 부분을 미리 로드할 수 있습니다. 그 결과 시스템 실행이 최적화되지만 다시 한 번 개발자의 추가 작업이 필요합니다. 솔라나에서는 프로그램의 모든 메모리 종속성이 빌드된 트랜잭션(즉, 액세스 목록)에 필요하고 선언되어 있으므로 런타임(런타임)이 여러 트랜잭션을 효율적으로 예약하고 병렬로 실행할 수 있습니다.

솔라나 아키텍처의 다음 주요 구성 요소는 솔라나의 병렬 스마트 컨트랙트 런타임인 실레벨 VM으로, 실레벨은 기본적으로 검증자의 코어 수에 따라 여러 컨트랙트 및 트랜잭션의 병렬 처리를 지원합니다. 블록체인의 검증자는 트랜잭션 검증, 새로운 블록 제안, 블록체인의 무결성 및 보안 유지를 담당하는 네트워크 참여자입니다. 트랜잭션은 읽기/쓰기 잠금이 필요한 계정을 미리 선언하기 때문에 솔라나 스케줄러는 어떤 트랜잭션을 병렬로 실행할 수 있는지 결정할 수 있습니다. 따라서 검증과 관련하여 "블록 생성자" 또는 리더는 수천 개의 보류 중인 트랜잭션을 분류하고 겹치지 않는 트랜잭션을 병렬로 예약할 수 있습니다.

솔라나의 최종 설계 요소는 "파이프라이닝"입니다. 파이프라이닝은 데이터를 일련의 단계로 처리해야 할 때 트리거되며, 각 단계는 다른 하드웨어에서 처리됩니다. 여기서 핵심 아이디어는 연속적으로 실행해야 하는 데이터를 가져와 파이프라이닝을 사용하여 병렬화하는 것입니다. 이러한 파이프라인은 병렬로 실행할 수 있으며 각 파이프라인 단계는 서로 다른 트랜잭션 패키지를 처리할 수 있습니다.

이러한 최적화를 통해 Sealevel은 단일 프로그램을 사용하여 한 번에 여러 데이터 포인트를 처리하는 하드웨어의 기능을 활용하여 독립적인 트랜잭션을 동시에 구성하고 실행할 수 있으며, Sealevel은 프로그램 ID별로 명령어를 정렬하고 모든 관련 계정에서 동일한 명령어를 병렬로 실행합니다.

이러한 혁신을 통해 솔라나는 의도적으로 병렬화를 지원하도록 설계되었다는 것을 알 수 있습니다.

(2)세이

세이는 디지털 자산 거래에 특화된 범용 오픈소스 L1 블록체인으로, 세이 V2는 낙관적 병렬 방식을 사용하여 개발자에게 더욱 친숙합니다. 낙관적 병렬 모드에서는 개발자가 리소스를 미리 선언할 필요 없이 스마트 컨트랙트를 보다 원활하게 병렬로 실행할 수 있습니다. 이는 체인이 모든 트랜잭션을 낙관적으로 병렬로 실행한다는 의미입니다. 그럼에도 불구하고 충돌이 발생하면(즉, 여러 트랜잭션이 동일한 상태에 액세스하는 경우) 블록체인은 충돌하는 각 트랜잭션의 영향을 받는 특정 스토리지 구성 요소를 추적합니다.

세이 블록체인은 "낙관적 동시성 제어(OCC)" 메커니즘을 사용하여 트랜잭션을 실행합니다. 동시 트랜잭션 처리는 시스템에서 동시에 여러 트랜잭션이 활성화되어 있을 때 발생합니다. 이러한 유형의 트랜잭션에는 실행과 유효성 검사의 두 단계가 있습니다.

실행 단계에서는 모든 읽기/쓰기를 트랜잭션 전용 저장소에 임시로 저장하여 트랜잭션이 최적으로 처리됩니다. 그 후 각 트랜잭션은 유효성 검사 단계로 이동하여 임시 저장소 작업의 정보를 이전 트랜잭션의 상태 변경 사항과 비교하여 확인합니다. 트랜잭션이 독립적인 경우 트랜잭션은 병렬로 실행됩니다. 한 트랜잭션에서 읽은 데이터가 다른 트랜잭션에 의해 수정된 경우 충돌이 발생합니다. Sei의 병렬 시스템은 트랜잭션의 읽기 데이터 세트와 다중 버전 저장소의 가장 최근 상태 변경 사항을 비교하여 각 충돌을 식별하며, Sei는 충돌이 발생한 위치에서 인스턴스를 재실행하고 다시 유효성을 검사합니다. 이는 충돌을 해결하기 위해 실행, 유효성 검사, 재실행이 포함된 반복적인 프로세스입니다. 다음 다이어그램은 충돌이 발생했을 때 Sei가 트랜잭션을 처리하는 방법을 보여줍니다.

Sei의 구현은 EVM 개발자에게 더 낮은 가스 요금과 더 넓은 설계 공간을 제공합니다. EVM 환경은 오랫동안 50TPS 미만으로 제한되어 개발자들이 정해진 패턴을 따르는 애플리케이션을 개발해야 했습니다. sei V2를 통해 개발자들은 일반적으로 고성능과 낮은 수수료가 필요한 DeFi, DePIN, 게임 등의 영역에 접근할 수 있게 되었습니다.

(3)Monad

모나드는 완전한 바이트코드 호환성을 갖춘 병렬 EVM L1을 구축하고 있으며, 병렬 엔진뿐만 아니라 내부에 구축한 최적화 엔진에서도 독보적입니다. 는 파이프라이닝, 비동기 I/O, 합의 실행 분리, MonadDB와 같은 몇 가지 주요 기능을 결합한 독특한 전체론적 설계 방식을 사용합니다.

모나드 설계의 주요 혁신 중 하나는 약간의 오프셋이 있는 파이프라이닝으로, 여러 인스턴스를 동시에 실행하여 더 많은 프로세스를 병렬화할 수 있도록 합니다. 결과적으로 파이프라이닝은 상태 액세스 파이프라이닝, 트랜잭션 실행 파이프라이닝, 합의 및 실행 내부 파이프라이닝, 합의 메커니즘 자체 내 파이프라이닝 등 많은 기능을 최적화하는 데 사용됩니다.

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

모나드는 또한 실행과 합의를 분리하고(솔라나 및 세이와 유사) 실행을 지연시킴으로써 성능을 향상시킵니다. 합의에 도달하기 전에 실행이 완료되도록 실행 조건을 완화하면 실행과 합의를 병렬로 실행하여 둘 다에 추가 시간을 더할 수 있다는 아이디어입니다. 물론 모나드는 이러한 상황을 처리하기 위해 결정론적 알고리즘을 사용하여 둘 중 하나가 너무 통제 불능 상태가 되지 않도록 합니다.

4, 상태 액세스와 메모리에 대한 독특한 접근 방식

이 글의 서두에서 언급했듯이, 상태 액세스는 블록체인의 대표적인 성능 병목 현상 중 하나입니다. 상태 액세스 및 메모리에 대한 설계 선택은 궁극적으로 병렬 시스템의 특정 구현이 실제로 성능을 향상시킬 수 있는지 여부를 결정할 수 있습니다. 아래에서는 솔라나, 세이, 모나드가 사용하는 다양한 접근 방식을 자세히 살펴보고 비교해보겠습니다.

(1) Solana상태 액세스: AccountsDB / Cloudbreak

Solana는 수평적 확장을 사용하여 여러 SSD 장치에서 상태를 분산 및 관리합니다. 데이터. 오늘날 많은 블록체인은 일반 데이터베이스(예: LevelDB)를 사용하는데, 이는 상태 데이터에 대한 대량의 동시 읽기 및 쓰기를 처리하는 데 한계가 있습니다. 이를 방지하기 위해 솔라나는 Cloudbreak를 사용하여 자체 맞춤형 계정 데이터베이스를 구축했습니다.

Cloudbreak는 자체적으로 빠른 RAM에만 의존하지 않고 I/O 작업 전반에 걸쳐 병렬 액세스를 위해 설계되었습니다.I/O 작업(입력/출력)은 디스크, 네트워크 또는 주변 장치와 같은 외부 소스에서 데이터를 읽거나 쓰는 작업입니다. 처음에 Cloudbreak는 RAM 내부 인덱스를 사용하여 공개 키를 잔액과 데이터를 보유한 계정에 매핑했습니다. 그러나 이 글을 쓰는 시점에서 v1.9 인덱스는 RAM에서 SSD로 이동되었습니다. 이러한 전환을 통해 Cloudbreak는 대기열에서 32개의 동시(I/O) 작업을 처리할 수 있게 되어 여러 SSD에서 처리량이 향상되었습니다. 그 결과, 메모리 매핑 파일을 사용하여 계정 및 트랜잭션과 같은 블록체인 데이터에 RAM에서처럼 효율적으로 액세스할 수 있습니다. 아래 다이어그램은 메모리 구조를 보여줍니다. RAM은 더 빠르지만, SSD보다 용량이 작고 더 비싼 경우가 많습니다.

수평적으로 확장하고 스테이트풀 데이터를 여러 장치에 분산함으로써 Cloudbreak는 지연 시간을 줄이고 Solana 생태계의 효율성, 탈중앙화 및 네트워크 복원력을 향상시킵니다.

(2)세이스테이트 액세스: 세이DB

세이는 스토리지인 세이DB를 재설계했습니다. -- 를 재설계하여 쓰기 증폭(데이터 구조를 유지하는 데 필요한 메타데이터의 양, 작을수록 좋음), 상태 부풀림, 느린 작업, 시간 경과에 따른 성능 저하 등 여러 문제를 해결했습니다. 이제 새로운 재설계는 상태 저장과 상태 커밋이라는 두 가지 구성 요소로 나뉩니다. 데이터에 대한 변경 사항을 기록하고 검증하는 것은 상태 약속에서 처리하고, 특정 시점의 모든 데이터를 기록하는 데이터베이스는 상태 저장소(SS)에서 처리합니다.

세이 V2에서 상태 약속은 메모리 매핑 IAVL 트리 아키텍처(MemIAVL)를 사용합니다. 메모리 매핑된 IAVL 트리는 메타데이터를 덜 저장하므로 상태 저장 및 상태 동기화 시간이 줄어들고 전체 노드를 더 쉽게 실행할 수 있습니다. 메모리 매핑 IAVL 트리는 디스크에 3개의 파일(kv 파일, 분기 파일, 리프 파일)로 표시되므로 추적해야 할 메타데이터가 적어져 상태 저장 공간을 50% 이상 줄일 수 있습니다. 새로운 MemIAVL 구조는 데이터 구조를 유지하는 데 필요한 메타데이터의 양을 줄이기 때문에 쓰기 증폭 계수를 줄이는 데 도움이 됩니다.

업데이트된 SeiDB는 상태 저장소 계층에 대한 유연한 데이터베이스 백엔드 지원을 가능하게 합니다.Sei는 노드 운영자마다 요구사항과 저장소 요구사항이 다르다는 점을 인식하고 있습니다. 따라서 SS는 다양한 백엔드 요구 사항을 수용하도록 설계되었으며, PebbleDB, RocksDB, SQLite 등과 같은 운영자에게 자유와 유연성을 제공합니다.

(3)모나드상태 액세스:모나드DB

모나드의 상태 액세스에는 몇 가지 중요한 뉘앙스가 있습니다. 첫째, 대부분의 이더넷 클라이언트는 두 가지 유형의 데이터베이스, 즉 B-Tree 데이터베이스(예: LMDB) 또는 로그 구조 병합 트리(LSM) 데이터베이스(예: RocksDB, LevelDB)를 활용합니다. 이 두 데이터베이스는 모두 블록체인을 위해 특별히 설계되지 않은 범용 데이터 구조입니다. 또한, 이러한 데이터베이스는 특히 비동기 작업 및 I/O 최적화와 관련하여 리눅스 기술의 최신 발전을 활용하지 못합니다. 마지막으로, 이더 자체는 암호화, 검증 및 증명 전용인 MPT 트리를 사용하여 상태를 관리합니다. 가장 큰 문제는 클라이언트가 이 특정 MPT 트리를 보다 일반적인 데이터베이스(예: B-Tree/LSM)에 통합해야 하며, 이로 인해 과도한 디스크 액세스와 같은 심각한 성능 저하가 발생한다는 것입니다.

이 모든 것이 모나드가 블록체인 데이터와 상태 액세스를 보다 효율적으로 처리하기 위한 맞춤형 모나드DB 데이터베이스를 만들기로 결정한 토대가 되었으며, 데이터베이스에 대한 병렬 액세스, 머클 트리 데이터에 최적화된 맞춤형 데이터베이스, 표준 RAM 사용량을 능가하는 효율적인 상태 액세스, 데이터베이스에 대한 분산화된 액세스 등이 모나드DB의 주요 특징 중 일부입니다. 효율적인 상태 액세스, 분산된 기능 및 확장성을 제공합니다.

MonadDB는 블록체인을 위해 특별히 설계되어 범용 데이터베이스를 사용하는 것보다 성능이 더 뛰어납니다. 커스텀 모나드DB는 머클 트라이 타입 데이터의 효율적인 관리에 특화되어 있으며, 동시에 여러 트라이 노드에 대한 병렬 액세스를 지원합니다. MonadDB는 위에서 언급한 일부 범용 데이터베이스와 읽기당 비용은 동일하지만, 여러 개의 읽기를 병렬로 실행할 수 있어 속도가 크게 향상된다는 것이 핵심 특징입니다.

MonadDB는 병렬 액세스 데이터베이스에 대한 동기식 상태 액세스를 지원합니다. 모나드는 처음부터 이 데이터베이스를 구축했기 때문에 최신 Linux 커널 기술과 비동기 I/O를 위한 SSD의 성능을 최대한 활용할 수 있습니다. 비동기 I/O를 사용하면 트랜잭션이 디스크에서 상태를 읽어야 하는 경우, 보류 중인 작업에 지연이 발생해서는 안 됩니다. 대신, 즉시 읽기를 시작하고 동시에 다른 트랜잭션을 계속 처리해야 합니다. 이것이 바로 비동기 I/O가 MonadDB 처리 속도를 획기적으로 높이는 방법입니다. Monad는 SSD 사용량을 최적화하고 과도한 RAM 의존도를 줄임으로써 하드웨어 성능 개선의 이점을 누릴 수 있습니다. 이는 탈중앙화 및 확장성에 부합하는 추가적인 이점이 있습니다.

5, 결론

요약하면, 솔라나, 세이, 모나드의 렌즈를 통해 블록체인의 병렬화 개발을 살펴봄으로써 다양한 아키텍처와 접근법이 어떻게 성능과 확장성을 향상시킬 수 있는지 포괄적으로 이해할 수 있습니다.솔라나에서의 결정론적 병렬처리(Deterministic Parallelism) 는 사전 선언된 상태 액세스에 중점을 두어 예측 가능성과 효율성을 제공하므로 처리량 요구 사항이 높은 애플리케이션에 적합한 선택입니다. 반면 세이의 낙관적 병렬 처리 방식은 개발자의 유연성을 우선시하며 트랜잭션 충돌이 빈번하지 않은 환경에 적합합니다. 고유한 낙관적 병렬처리 접근 방식과 맞춤형 모나드DB를 통해 모나드는 최신 기술 발전을 활용하여 상태 접근과 성능을 최적화하는 혁신적인 솔루션을 제공합니다.

각 블록체인은 고유한 절충점을 통해 병렬화 문제를 해결하는 독특한 접근 방식을 제공합니다. 솔라나는 하드웨어 활용도와 처리량을 극대화하도록 설계된 반면, 세이는 개발 프로세스를 단순화하는 데 초점을 맞추고 모나드는 블록체인 데이터를 위한 맞춤형 데이터베이스 솔루션을 제공하는 데 중점을 둡니다. 이러한 차이는 블록체인 생태계의 다양성과 애플리케이션의 특정 요구에 적합한 플랫폼을 선택하는 것의 중요성을 강조합니다.

블록체인 분야가 계속 진화함에 따라 솔라나, 모나드, 세이가 보여준 병렬화 기술의 발전은 의심할 여지 없이 더 많은 혁신을 불러일으킬 것입니다. 보다 효율적이고 확장 가능하며 개발자 친화적인 블록체인을 향한 여정은 현재 진행 중이며, 이러한 플랫폼에서 얻은 교훈은 블록체인 기술의 미래를 형성하는 데 중요한 역할을 할 것입니다.