실적 보고서
5월 17일 CoinGecko가 발표한 가장 빠른 체인 보고서에 따르면 Solana는 대형 블록체인 중 가장 빠르며 일일 평균 실제 TPS가 가장 높은 1,054(투표 거래는 제거됨)에 이르렀고 Sui는 두 번째로 빠른 블록체인으로 일일 최고치를 기록했습니다. 평균 실제 TPS는 854에 도달했고 BSC는 3위를 차지했지만 달성된 실제 TPS는 Sui의 절반에도 미치지 못했습니다.
이 보고서에서 볼 수 있듯이 가장 성능이 좋은 Solana와 Sui는 모두 EVM 비호환 블록체인입니다. 또한, EVM 비호환 블록체인 8개의 평균 실제 TPS는 284이고, EVM 호환 블록체인 17개와 평균 TPS입니다. Ethereum Layer 2의 레이어는 74에 불과하며, EVM 비호환 블록체인의 성능은 EVM 호환 블록체인의 약 4배입니다.
이 글에서는 EVM 호환 블록체인의 성능 병목 현상을 살펴보고 솔라나의 성능 방법을 공개할 것입니다.
EVM 호환 블록체인의 성능 병목 현상
먼저 EVM 블록체인을 일반 블록체인으로 일반화합니다. 일반적으로 블록체인이 TPS를 향상시키려면 다음과 같은 몇 가지 방법이 있습니다.
노드 성능 향상: 하드웨어 리소스를 쌓아서 노드 성능을 향상시킵니다. 예를 들어 Ethereum, Cpu 4 코어, 메모리 16G, 네트워크 대역폭 25Mbps, 일반 사용자의 권장 구성은 노드의 하드웨어 요구 사항에 영향을 미칩니다. 수준의 장비는 더 높은 수준의 분산화를 달성할 수 있습니다. Solana는 전문가 수준의 장비로만 달성할 수 있는 32개의 CPU 코어, 128G 메모리 및 1Gbps 네트워크 대역폭의 상대적으로 높은 구성을 권장하며 분산화 수준은 평균입니다. ;
네트워크 프로토콜, 암호화, 저장 등을 포함한 기본 프로토콜을 개선합니다. 블록체인의 기본 프로토콜을 개선해도 블록체인 자체의 속성이 변경되지 않으며 블록체인의 운영 규칙에도 영향을 미치지 않습니다. 하지만 근본적인 기술적 관심도가 낮고 현재 연구 분야에서 큰 진전이 없습니다.
블록 확장: 블록 크기를 늘리면 더 많은 트랜잭션이 포함될 수 있으므로 블록체인의 트랜잭션 처리량이 증가합니다. 예를 들어 비트코인 캐시(BCH)는 블록을 1MB에서 8MB로 확장한 다음 32MB로 확장했습니다. 그러나 블록을 확장하면 전파 지연도 증가하고 포크 및 DDoS 공격 가능성이 높아지는 등 보안 위협이 발생합니다.
합의 프로토콜: 합의 프로토콜은 블록체인의 모든 노드가 블록체인의 상태 업데이트에 대한 합의에 도달하도록 보장합니다. 블록체인에서 사용되는 합의 메커니즘에는 PoW, PoS, PBFT 등 확장성 요구 사항을 충족하기 위해 고성능 퍼블릭 체인은 일반적으로 합의 프로토콜을 개선하고 이를 Solana의 PoH 기반 합의 메커니즘 및 Avalanche의 눈사태 기반 합의 메커니즘과 같은 자체 특수 메커니즘과 결합합니다.
트랜잭션 실행: 트랜잭션 실행은 단위 시간당 처리되는 트랜잭션 수나 컴퓨팅 작업에만 관심이 있습니다. 이더리움과 같은 블록체인은 스마트 계약 트랜잭션을 블록 단위로 실행하기 위해 직렬 방식을 사용합니다. , 블록체인의 처리량을 심각하게 제한합니다. 일반적으로 고성능 퍼블릭 체인은 병렬 실행을 채택하고 일부는 Sui Move와 같이 스마트 계약을 구축하기 위해 병렬 처리에 더 도움이 되는 언어 모델을 제안합니다.
EVM 블록체인의 경우 가장 큰 난관은 가상 머신, 즉 트랜잭션 실행 환경의 한계로 인해 트랜잭션 실행에 있습니다 . EVM에는 두 가지 주요 성능 문제가 있습니다.
256비트: EVM은 명시적으로 256비트 출력을 생성하는 이더리움의 해싱 알고리즘을 더 쉽게 처리할 수 있도록 256비트 가상 머신으로 설계되었습니다. 그러나 실제로 EVM을 실행하는 컴퓨터는 실행을 위해 256비트 바이트를 로컬 아키텍처에 매핑해야 합니다. 하나의 EVM opcode는 여러 로컬 opcode에 해당하므로 전체 시스템이 매우 비효율적이고 비실용적입니다.
표준 라이브러리 부족: Solidity에는 표준 라이브러리가 없으며 Solidity 코드로 직접 구현해야 합니다. OpenZeppelin은 이러한 상황을 어느 정도 개선했지만 Solidity 구현을 위한 표준 라이브러리를 제공합니다(계약에 코드를 포함하거나 Delegatecall 형태로 배포된 컨트랙트를 호출) 하지만 EVM 바이트코드의 실행 속도는 미리 컴파일된 표준 라이브러리에 비해 훨씬 느립니다.
실행 최적화의 관점에서 볼 때 EVM에는 여전히 두 가지 주요 단점이 있습니다.
정적 분석의 어려움: 블록체인에서 병렬 실행은 관련 없는 트랜잭션을 동시에 처리하고 관련 없는 트랜잭션을 서로 영향을 주지 않는 이벤트로 처리하는 것을 의미합니다. 병렬 실행을 달성하는 데 있어서 가장 큰 과제는 어떤 트랜잭션이 관련이 없고 어떤 것이 독립적인지 결정하는 것입니다. 현재 일부 고성능 퍼블릭 체인은 트랜잭션에 대해 사전에 정적 분석을 수행하므로 EVM의 동적 점프 메커니즘으로 인해 코드를 정적으로 분석하기가 어렵습니다. ;
JIT 컴파일러는 미성숙합니다. JIT 컴파일러(Just In Time Compiler)는 최신 가상 머신에서 일반적으로 사용되는 최적화 방법입니다. JIT의 주요 목표는 해석 실행을 컴파일된 실행으로 바꾸는 것입니다. 런타임 시 가상 머신은 핫 코드를 로컬 플랫폼과 관련된 머신 코드로 컴파일하고 다양한 수준의 최적화를 수행합니다. 현재 EVM JIT 프로젝트가 있지만 아직 실험 단계에 있으며 충분히 성숙되지 않았습니다.
따라서 가상 머신 선택 측면에서 고성능 퍼블릭 체인은 EVM이 아닌 WASM, eBPF 바이트코드 또는 Move 바이트코드 기반의 가상 머신을 사용합니다. 예를 들어 솔라나는 고유한 가상 머신 SVM과 eBPF 기반 바이트코드 SBF를 사용합니다.
가장 빠른 체인: 솔라나
솔라나는 PoH(역사 증명) 메커니즘과 낮은 지연 시간, 높은 처리량으로 유명합니다. 가장 유명한 이더리움 킬러 중 하나입니다.
PoH의 핵심은 VDF(검증 가능한 지연 함수)와 유사한 간단한 해시 알고리즘입니다. Solana는 한 반복의 출력을 다음 반복의 입력으로 사용하여 지속적으로 실행되는 시퀀스 사전 이미지 방지 해시 함수(SHA-256)를 사용하여 구현됩니다. 이 계산은 유효성 검사기당 단일 코어에서 실행됩니다.
시퀀스 생성은 순차적이고 단일 스레드이지만 검증은 병렬로 수행될 수 있으므로 멀티 코어 시스템에서 효율적인 검증이 가능합니다. 해시 속도에는 상한이 있지만 하드웨어 개선을 통해 추가적인 성능 향상을 얻을 수 있습니다.
솔라나 합의 과정
PoH 메커니즘은 신뢰할 수 있고 신뢰할 수 없는 시간 소스 역할을 하여 네트워크 내에서 검증 가능하고 순서가 지정된 이벤트 기록을 생성합니다. PoH 기반 타이밍을 통해 솔라나 네트워크는 일정에 따라 투명하게 리더를 교체할 수 있습니다 . 이 회전은 4개 슬롯의 고정된 간격으로 발생하며 각 슬롯은 현재 400밀리초로 설정되어 있습니다. 이 리더 순환 메커니즘은 참여하는 모든 검증인이 리더가 될 수 있는 공평한 기회를 보장합니다. 이는 솔라나 네트워크가 분산화와 보안을 유지하여 단일 검증인이 네트워크에서 너무 많은 권력을 얻는 것을 방지하는 중요한 메커니즘입니다.
각 슬롯 기간마다 리더는 사용자로부터 받은 트랜잭션을 포함하는 새로운 블록을 제안합니다. 리더는 이러한 트랜잭션을 검증하고 이를 블록으로 패키징한 다음 해당 블록을 네트워크의 나머지 검증자에게 브로드캐스트합니다. 블록을 제안하고 전파하는 이러한 과정을 블록 생산이라고 하며, 네트워크의 다른 검증인은 블록의 유효성에 투표해야 합니다. 검증인은 블록의 내용을 확인하여 거래가 유효하고 네트워크 규칙을 준수하는지 확인합니다. 지분 가중치의 과반수 투표를 받으면 블록이 확정된 것으로 간주됩니다. 이 확인 프로세스는 솔라나 네트워크의 보안을 유지하고 이중 지출을 방지하는 데 매우 중요합니다.
현재 리더의 기간이 끝나면 네트워크는 정지하거나 블록 확인을 기다리지 않고 다음 기간으로 이동하여 후속 리더에게 블록을 생성할 기회를 제공하고 전체 프로세스가 다시 시작됩니다. 이러한 접근 방식을 통해 일부 검증인이 기술적 문제를 겪거나 오프라인이 되는 경우에도 솔라나 네트워크는 높은 처리량을 유지하고 탄력성을 유지합니다.
솔라나 퍼포먼스 타오
솔라나 네트워크는 리더를 미리 확인할 수 있기 때문에 솔라나는 사용자의 거래를 보관하기 위한 공용 메모리 풀이 필요하지 않습니다. 사용자가 트랜잭션을 제출하면 RPC 서버는 이를 QUIC 패킷으로 변환하고 즉시 리더의 유효성 검사기로 전달합니다. 걸프 스트림(Gulf Stream)이라고 불리는 이 접근 방식을 사용하면 빠른 리더 전환과 거래 사전 실행이 가능해 다른 검증인의 메모리 부하가 줄어듭니다.
솔라나의 블록 데이터는 커널 공간으로 가져온 후 병렬 서명 검증을 위해 GPU로 전달됩니다. GPU에서 서명이 검증되면 해당 데이터는 트랜잭션 실행을 위해 CPU로 전달되고 최종적으로 커널 공간으로 반환됩니다. 데이터 지속성. 파이프라인 기술이라고 불리는 데이터를 서로 다른 하드웨어 구성요소로 나누는 다중 처리 프로세스는 하드웨어 활용도를 극대화하고 블록 검증 및 전송 속도를 높일 수 있습니다.
솔라나의 트랜잭션은 액세스할 계정을 명시적으로 지정하기 때문에 솔라나의 트랜잭션 스케줄러는 읽기-쓰기 잠금 메커니즘을 활용하여 트랜잭션을 병렬로 실행할 수 있습니다. 솔라나 트랜잭션 스케줄러의 각 스레드는 자체적으로 관리되는 큐를 가지며, 트랜잭션을 순차적이고 독립적으로 처리하며, 트랜잭션 계정 잠금(읽기-쓰기 잠금)을 시도하고 계정 충돌이 있는 트랜잭션은 나중에 실행됩니다. 이 다중 스레드 병렬 실행 기술을 Sealevel이라고 합니다.
리더가 블록을 전파하고 QUIC 패킷(선택적으로 삭제 코딩 사용)을 더 작은 패킷으로 나누고 이를 계층 구조의 검증자에게 배포하는 프로세스입니다. 터빈이라고 불리는 이 기술은 본질적으로 리더의 대역폭 사용량을 줄입니다.
투표 과정에서 검증인은 포크 투표를 위한 합의 메커니즘을 사용합니다. 검증인은 투표가 블록 생성을 진행할 때까지 기다릴 필요가 없습니다. 대신 블록 생산자는 유효한 새 투표를 지속적으로 모니터링하고 이를 현재 블록에 실시간으로 포함시킵니다. 이 합의 메커니즘을 TowerBFT라고 하며, 실시간으로 포크 투표를 병합함으로써 솔라나는 보다 효율적이고 간소화된 합의 프로세스를 보장하여 전반적인 성능을 향상시킵니다.
블록 지속성 프로세스를 위해 Solana는 순차 작업 속도의 이점을 얻기 위해 계정 데이터 구조를 특정 방식으로 분할하고 메모리 매핑된 파일을 사용하여 SSD의 효율성을 극대화하기 위해 Cloudbreak 데이터베이스를 개발했습니다.
검증인의 부담을 줄이기 위해 솔라나는 데이터 저장소를 검증인에서 Archiver라는 노드 네트워크로 옮깁니다. 거래 상태 내역을 여러 조각으로 분할하고 이레이저 코딩(Erasure Coding) 기술을 사용합니다. Archiver는 상태 조각을 저장하는 데 사용되지만 합의에는 참여하지 않습니다.
요약하다
솔라나의 비전은 소프트웨어가 하드웨어의 속도에 맞춰 확장되는 블록체인이 되는 것입니다. 따라서 솔라나는 오늘날의 컴퓨터에서 사용할 수 있는 모든 CPU, GPU 및 대역폭 기능을 최대한 활용하여 이론적 최대 속도 65,000TPS로 성능을 극대화합니다.
솔라나가 초단타 거래와 복잡한 스마트 계약을 처리하는 데 선호되는 블록체인 플랫폼이 된 것은 바로 솔라나의 높은 성능과 확장성 때문입니다. 연초의 DePIN/AI 트랙이든, 최근 핫한 Meme 트랙이든, 솔라나는 엄청난 잠재력을 보여주었습니다.
이더리움 ETF 출시 이후 솔라나는 차기 ETF에서 가장 인기 있는 암호화폐가 되었습니다. SEC가 여전히 솔라나를 증권으로 등록하고 있지만, 다른 암호화폐 ETF는 단기적으로 승인되지 않을 것입니다. 하지만 암호화폐 시장에서는 합의가 곧 가치이며, 솔라나의 합의는 비트코인이나 이더리움만큼 파괴할 수 없게 될 수도 있습니다.
