Firedancer란? Solana 2.0 심층 분석

이 글에서는 무엇을 다루나요?

Solana는 가장 빠른 블록체인입니다. 하지만 더 빨라질 수 있습니다. 현재 Solana Labs 검증인 클라이언트도 훌륭하지만, 빠른 시장 출시를 우선해 최적화되었습니다. Jump는 축적된 경험과 완전히 새로운 접근 방식, 수십 년간 쌓은 고성능 컴퓨팅 전문성을 바탕으로 Solana를 더 빠르고 안정적으로 만들고 있습니다. 고빈도 트레이딩 경험을 활용해 Firedancer를 개발하고 있습니다. Firedancer는 모든 블록체인을 통틀어 가장 뛰어난 성능을 제공하는 검증인 클라이언트입니다. 현재 Solana 검증인 클라이언트를 C 프로그래밍 언어로 완전히 다시 작성하는 프로젝트입니다.

이 글에서는 검증인과 검증인 클라이언트 다양성의 중요성을 살펴봅니다. 이어서 Jump가 새로운 검증인 클라이언트를 개발하는 이유와 고빈도 트레이딩 경험 덕분에 Firedancer 개발에 가장 적합한 팀인 이유를 설명합니다. 그런 다음 Firedancer가 무엇인지, 어떻게 작동하는지, 왜 빠른지, 어떻게 보안을 유지하는지, 현재 개발 상태는 어떤지 알아봅니다.

이 글을 끝까지 읽으면 Jump의 새로운 검증인 클라이언트를 깊이 이해하게 됩니다. 모든 블록체인을 통틀어 가장 뛰어난 성능을 구현한 획기적인 최적화 기법도 알게 됩니다. 또한 Firedancer가 Solana 네트워크의 성능과 안정성에 꼭 필요한 이유도 이해할 수 있습니다. Firedancer를 알아보는 데 필요한 글은 이것 하나면 충분합니다.

부록에는 컴퓨터 하드웨어와 네트워킹에 관한 기초 설명이 있습니다. 선택적으로 읽을 수 있는 내용입니다. 일반 독자가 이 글에서 다루는 고급 하드웨어 및 네트워킹 개념을 이해하는 데 필요한 배경을 제공하기 위해 추가했습니다. 필요한 부분에는 별도 설명도 제공합니다. Solana를 사용하는 누구나 Firedancer와 그 중요성을 이해할 수 있도록 쉽게 작성했습니다.

검증인과 검증인 클라이언트 다양성이란?

검증인은 Proof of Stake 블록체인에 참여하는 컴퓨터입니다. 검증인은 Solana 네트워크의 중추를 이룹니다. 트랜잭션을 처리하고 합의에 참여합니다. 검증인은 Solana의 네이티브 토큰을 일정량 스테이킹해 네트워크 보안에 기여합니다. 이를 검증인이 네트워크에 재정적으로 책임을 지도록 만드는 보증금이라고 생각하면 됩니다. 검증인은 기여에 따른 보상을 받으므로 맡은 작업을 정확하고 효율적으로 수행할 동기를 얻습니다. 악의적이거나 잘못된 활동에는 페널티가 부과됩니다. 부적절하게 행동하면 slashing이라는 절차를 통해 검증인의 스테이킹 지분이 줄어듭니다. 따라서 맡은 역할을 제대로 수행해 지분을 늘리는 것이 검증인에게 가장 유리합니다.

검증인 클라이언트는 검증인이 역할을 수행할 때 사용하는 애플리케이션입니다. 클라이언트는 검증인의 기반으로 작동하며, 암호학적으로 고유한 신원을 사용해 합의에 참여하게 합니다.

서로 다른 클라이언트가 여러 개 있으면 한 구현에 장애가 발생해도 내결함성이 향상됩니다. 예를 들어 어떤 클라이언트도 스테이킹 지분의 33%를 넘지 않는다면, 하나가 중단되거나 활성에 영향을 주는 버그가 발생해도 네트워크 전체가 멈추지 않습니다. 마찬가지로 클라이언트 버그가 잘못된 상태 전이를 일으켜도 해당 클라이언트를 사용하는 지분이 33% 미만이면 네트워크는 안전성 실패를 피할 수 있습니다. 네트워크 대부분이 유효한 상태를 유지하므로 블록체인의 분할이나 포크를 방지할 수 있기 때문입니다. 따라서 검증인 클라이언트가 다양하면 한 클라이언트의 버그나 취약점이 전체 네트워크를 마비시키지 않아 복원력이 높아집니다.

클라이언트 다양성은 각 클라이언트에서 실행되는 스테이킹 지분의 비율과 사용 가능한 전체 클라이언트 수로 측정합니다. 이 글을 작성하는 시점에 Solana 네트워크에는 검증인 1979개가 있습니다. 이 검증인들이 메인넷에서 사용하는 두 클라이언트는 Solana Labs와 Jito Labs가 제공합니다. Solana는 2020년 3월 Solana Labs가 개발한 하나의 검증인 클라이언트로 출시되었습니다. 2022년 8월에는 Jito Labs가 두 번째 검증인 클라이언트를 출시했습니다. 이 클라이언트는 Jito가 유지·배포하는 Solana Labs 코드의 포크입니다. 블록 내 MEV(최대 추출 가능 가치) 추출을 최적화합니다. Solana는 멤풀 없이 블록을 스트리밍하므로 Jito 클라이언트는 의사 멤풀을 만듭니다. 참고로 멤풀 또는 메모리 풀은 처리 대기 중인 미확정 트랜잭션의 목록입니다. 의사 멤풀을 사용하면 검증인이 이러한 트랜잭션을 탐색하고 최적으로 묶어 Jito의 Block Engine에 제출할 수 있습니다.

2023년 10월 기준 활성 스테이킹 지분 중 Solana Labs 클라이언트는 68.55%, Jito는 31.45%를 차지합니다. Jito 클라이언트를 사용하는 검증인 수는 Solana Foundation의 이전 Health Report보다 16% 늘었습니다. Jito 클라이언트 사용 증가는 클라이언트 다양성이 확대되고 있다는 긍정적인 신호입니다.

이러한 성장은 반가운 소식이지만 완벽하지는 않습니다. Jito 클라이언트가 Solana Labs 클라이언트의 포크라는 점이 중요합니다. Jito는 원본 검증인 코드베이스와 많은 구성 요소를 공유하므로 Labs 클라이언트에 영향을 주는 버그나 익스플로잇에 함께 노출될 수 있습니다. 이상적으로 Solana에는 독립적인 검증인 클라이언트가 최소 4개 있어야 합니다. 서로 다른 팀이 각기 다른 프로그래밍 언어로 개발해야 합니다. 각 클라이언트가 ~25%의 지분을 보유해 어떤 구현도 33%를 넘지 않아야 합니다. 이런 이상적인 구조라면 전체 검증인 스택에 단일 장애점이 없어집니다.

이러한 미래를 실현하려면 두 번째 독립 검증인 클라이언트가 반드시 필요합니다. Jump는 이를 현실로 만들고 있습니다.

Jump가 새로운 검증인 클라이언트를 만드는 이유는?

Solana 메인넷은 과거 네 차례 블록 생성을 중단했습니다. 매번 수백 개 검증인이 수동으로 문제를 해결해야 했습니다. 이러한 장애는 Solana 네트워크의 안정성에 관한 우려를 부각했습니다. Jump는 프로토콜 자체는 건전하다고 봅니다. 대신 합의에 영향을 미치는 소프트웨어 모듈 문제를 중단 원인으로 지목합니다. Jump는 이러한 문제를 해결하기 위해 새로운 검증인 클라이언트를 개발하고 있습니다. 궁극적인 목표는 Solana 네트워크의 안정성과 효율성을 높이는 것입니다.

독립적인 검증인 클라이언트를 개발하는 일은 어렵습니다. 하지만 Jump가 안정적인 글로벌 네트워크를 구축하는 것은 이번이 처음이 아닙니다. 과거에는 시장 전문가가 증권 거래, 즉 주식 매매를 수작업으로 처리했습니다. 전자 거래 플랫폼이 등장하면서 증권 거래소는 더욱 개방되었습니다. 그 결과 경쟁과 자동화가 확대되고 투자자의 거래 시간과 비용이 줄었습니다. 시장 전문가들 사이에는 기술 군비 경쟁이 시작되었습니다.

트레이더는 거래를 위해 존재합니다. 최적의 거래 경험을 위해서는 소프트웨어, 하드웨어, 네트워킹 솔루션 중 어느 하나도 타협할 수 없습니다. 이러한 시스템에는 높은 머신 인텔리전스, 짧은 실시간 지연 시간, 높은 처리량, 뛰어난 적응성, 높은 확장성, 높은 안정성, 강력한 책임성이 필요합니다.

범용 솔루션, 즉 기업이 바로 구매할 수 있는 소프트웨어는 경쟁 우위가 아닙니다. 정확한 주문을 거래소에 열 번 보내면서 매번 2등을 한다면 비용만 많이 들고 돈을 잃습니다. 고빈도 트레이딩의 치열한 경쟁은 최고 수준의 글로벌 거래 인프라를 구축하는 끊임없는 개발 주기로 이어집니다.

익숙한 이야기처럼 들릴 수 있습니다. 성공적인 거래 시스템의 요구 사항은 성공적인 블록체인의 요구 사항과 비슷합니다. 블록체인은 성능과 내결함성이 뛰어나고 지연 시간이 짧은 네트워크여야 합니다. 느린 블록체인은 현대 엔터프라이즈 애플리케이션의 요구를 충족하지 못하는 실패한 기술입니다. 혁신과 확장성, 실제 활용을 방해할 뿐입니다. Jump는 20년 넘게 글로벌 네트워크를 확장하고 고성능 시스템을 개발해 왔으므로 독립 검증인 클라이언트를 만들기에 가장 적합한 팀입니다. Jump Trading의 최고과학책임자 Kevin Bowers가 이 과정을 이끌고 있습니다.

빛의 속도도 너무 느린 이유는?

Kevin Bowers는 빛의 속도조차 너무 느리다는 점을 오랫동안 이야기해 왔습니다. 빛의 속도는 유한한 상수이므로 단일 트랜지스터가 처리할 수 있는 연산 수에 자연적인 한계를 만듭니다. 현재 비트는 트랜지스터를 통과하는 전자로 모델링됩니다. Shannon Capacity Theorem, 즉 채널을 통해 오류 없이 전송할 수 있는 최대 데이터양은 트랜지스터를 통과할 수 있는 비트 수를 제한합니다. 기본 물리학과 정보 이론에 따라 연산 속도는 전자가 물질을 통과하는 속도와 전송 가능한 데이터양에 의해 제한됩니다. 슈퍼컴퓨터를 한계까지 밀어붙이면 이러한 제약이 분명해집니다. 그 결과 “컴퓨터가 숫자를 계산하는 능력과 숫자를 이동하는 능력 사이에는 극적인 불균형”이 존재합니다.

Intel Core i9 13900K CPU를 예로 들어 보겠습니다. 기본 클록 2.2 GHz, 최대 터보 클록 5.8 GHz인 x86 코어 24개가 있습니다. 최악의 경우 빛은 이 CPU에서 총 ~52.0 mm를 이동해야 합니다. CPU의 맨해튼 거리, 즉 직각 축을 따라 측정한 두 점 사이의 거리는 ~73.6 mm입니다. CPU의 최대 터보 클록 속도인 5.8 GHz에서 빛은 공기 중으로 ~51.7 mm 이동할 수 있습니다. 즉, 신호는 단일 클록 주기 동안 CPU의 임의 두 지점 사이를 거의 한 번 왕복할 수 있습니다.

실제 상황은 훨씬 더 나쁩니다. 이 측정에서는 공기 중 빛의 속도를 사용하지만, 신호는 이산화규소(SiO2)를 통과합니다. 5.8 GHz 클록 주기 동안 빛은 이산화규소에서 ~26.2 mm 이동할 수 있습니다. 실리콘(Si)에서는 ~15.0 mm만 이동할 수 있습니다. CPU 긴 변의 절반을 조금 넘는 거리입니다.

Firedancer 팀은 최근 컴퓨팅 기술의 발전이 코어를 더 빠르게 만드는 대신 CPU에 더 많은 코어를 넣는 데 집중되었다고 말합니다. 더 높은 성능이 필요하면 하드웨어를 더 구매하라는 권고를 받았습니다. 처리량이 병목인 동안에는 이 방식이 통합니다. 하지만 실제 병목은 빛의 속도입니다. 이 자연적 제약은 의사결정을 마비시킵니다. 시스템에는 구성 요소가 많고 어느 것도 충분히 최적화되지 않았으므로 하나를 최적화해도 즉각적인 효과가 없기 때문입니다. 최적화되지 않은 부분은 사용할 수 있는 컴퓨팅 자원이 줄면서 시간이 갈수록 악화됩니다. 그렇다면 어떻게 해야 할까요?

고성능 컴퓨팅 세계에서는 결국 모든 것을 최적화해야 합니다. 그 결과 지구 규모에서 물리학과 정보 이론의 한계까지 작동하는 실거래 및 정량적 연구 시스템을 구축하게 됩니다. 여기에는 맞춤형 네트워크 스위칭 기술부터 이러한 물리적 한계를 고려해 설계한 lock-free 알고리즘까지 포함됩니다. Jump는 트레이딩 기업인 동시에 기술 기업입니다. Jump와 Solana가 당면한 문제가 놀라울 만큼 비슷한 가운데, 공상과학과 현실의 최전선에서 Jump는 Firedancer를 개발하고 있습니다.

Firedancer란?

Firedancer는 Firedancer 팀이 C 프로그래밍 언어로 개발한 완전히 독립적인 새 검증인 클라이언트입니다. 모듈식 아키텍처, 최소한의 의존성, 광범위한 테스트 프로세스를 통해 안정성을 우선하도록 설계되었습니다. Solana Labs 클라이언트의 세 가지 기능 구성 요소인 네트워킹, 런타임, 합의를 대대적으로 다시 작성합니다. 각 계층은 성능을 극대화하도록 최적화되므로 검증인 하드웨어만이 클라이언트 용량을 제한합니다. 소프트웨어 비효율성 때문에 검증인이 성능 제한을 받는 현재와는 다릅니다. Firedancer를 사용하면 Solana는 대역폭과 하드웨어에 맞춰 확장됩니다.

Firedancer의 목표는 다음과 같습니다.

• Solana 프로토콜 문서화 및 표준화(궁극적으로는 Rust 검증인 코드가 아니라 문서만 보고도 Solana 검증인을 만들 수 있어야 합니다)
• 검증인 클라이언트 다양성 확대
• 생태계 성능 개선

Firedancer는 어떻게 작동하나요?

모듈식 아키텍처

Firedancer는 독특한 모듈식 아키텍처로 기존 Solana 검증인 클라이언트와 차별화됩니다. 단일 프로세스로 작동하는 Solana Labs Rust 검증인 클라이언트와 달리, Firedancer는 tile이라고 하는 수많은 개별 Linux C 프로세스로 구성됩니다. tile은 하나의 프로세스와 일부 메모리입니다. 이 tile 아키텍처는 Firedancer의 운영 철학과 안정성·효율성 접근 방식의 토대입니다.

프로세스는 실행 중인 프로그램의 인스턴스입니다. 현대 운영 체제의 핵심 구성 요소이며 명령어 집합의 실행을 나타냅니다. 각 프로세스에는 운영 체제가 할당한 고유 메모리 공간과 리소스가 있으며 다른 프로세스와 독립적으로 작동합니다. 프로세스는 대형 공장에서 각자의 도구와 작업 공간으로 특정 업무를 처리하는 독립 작업자와 같습니다.

Firedancer에서 각 tile은 정해진 역할을 맡은 개별 프로세스입니다. 예를 들어 QUIC tile은 수신 QUIC 트래픽을 처리하고 캡슐화된 트랜잭션을 verify tile로 전달합니다. verify tile은 서명을 검증하며, 다른 tile도 각자 맡은 역할을 수행합니다. 이들은 독립적으로 동시에 작동하며 시스템 전체 기능에 기여합니다. 개별 Linux 프로세스를 사용하면 작고 독립적인 장애 영역을 만들 수 있습니다. 즉, 한 tile의 문제가 전체 시스템에 미치는 영향, 이른바 “폭발 반경”이 작습니다. 단일 장애점이 검증인 전체를 즉시 손상시킬 수 있는 Solana Labs Rust 클라이언트와 다릅니다.

Firedancer 아키텍처의 핵심 장점은 중단 시간 없이 몇 초 만에 각 tile을 교체하고 업그레이드할 수 있다는 것입니다. 업그레이드 전에 완전히 종료해야 하는 Solana Labs Rust 클라이언트와 극명하게 대비됩니다. 이러한 차이는 Rust에 ABI(Application Binary Interface) 안정성이 없다는 점에서 비롯됩니다. 이로 인해 순수 Rust 환경에서는 실행 중 업그레이드가 불가능합니다. C 런타임 모델의 바이너리 안정성을 활용하는 C 프로세스를 사용하면 업그레이드 관련 중단 시간이 크게 줄어듭니다. tile이 서로 다른 작업 공간에서 검증인 상태를 관리하므로 가능합니다. 이러한 공유 메모리 객체는 검증인의 전원이 켜져 있는 동안 유지됩니다. 각 tile은 재시작이나 업그레이드 중에도 중단한 지점부터 원활하게 처리를 재개할 수 있습니다.

전반적으로 Firedancer는 NUMA를 인식하는 tile 기반 아키텍처로 구축됩니다. 다음 섹션에서 그 의미를 설명합니다. 우선 이는 스레드마다 전용 하드웨어 리소스를 제공한다는 의미입니다. 이 아키텍처에서는 tile당 CPU 코어 1개를 사용합니다. 메모리 지역성, 리소스 배치, 구성 요소 지연 시간에 최적화된 고성능 tile 간 메시지 전달을 지원합니다.

네트워크 처리

Firedancer의 네트워크 처리는 Solana 네트워크가 초당 기가비트 속도로 확장될 때 발생하는 높은 부하를 처리하도록 설계되었습니다. 이 과정은 수신과 송신 작업으로 나뉩니다.

수신 작업은 주로 사용자의 트랜잭션을 받는 과정입니다. 검증인의 패킷 처리가 뒤처지면 합의 메시지가 손실될 수 있으므로 Firedancer의 성능이 중요합니다. 현재 Solana 노드의 운영 대역폭은 ~0.2 Gbps이며, Jump 노드에서 기록된 가장 큰 급증은 ~40 GBps였습니다. 이러한 대역폭 급증은 견고하고 확장 가능한 수신 처리 솔루션이 필요하다는 점을 보여줍니다.

송신 작업에는 블록 패킹, 블록 생성, 샤드 전송이 포함됩니다. 각 단계는 Solana 네트워크를 안전하고 효율적으로 운영하는 데 매우 중요합니다. 이러한 작업의 성능은 처리량뿐 아니라 네트워크 전체의 안정성에도 영향을 줍니다.

Firedancer는 트랜잭션을 처리하는 Solana P2P 인터페이스의 과거 약점을 해결하려 합니다. 과거 Solana P2P 인터페이스의 주요 단점은 수신 트랜잭션을 위한 혼잡 제어가 없었다는 것입니다. 이 문제로 2021년 9월 14일에는 17시간, 2022년 4월 30일에는 7시간 동안 대규모 네트워크 장애가 발생했습니다.

이에 대응해 Solana는 높은 트랜잭션 부하를 적절히 처리할 수 있도록 네트워크를 여러 차례 업그레이드했습니다. Firedancer도 흐름 제어에 QUIC을 도입했습니다. QUIC은 HTTP/3의 기반이 되는 다중화 전송 네트워크 프로토콜입니다. DDoS 방어와 네트워크 트래픽 관리에서 핵심 역할을 합니다. 하지만 경우에 따라 비용이 이점보다 크다는 점도 중요합니다. QUIC은 데이터 센터의 DDoS 공격 완화 전용 하드웨어와 함께 트랜잭션 플러딩의 유인을 제거합니다.

151페이지에 달하는 QUIC 사양은 개발에 상당한 복잡성을 더했습니다. 라이선스, 성능, 안정성 요구를 충족하는 기존 C 라이브러리를 찾지 못한 Firedancer 팀은 자체 구현을 개발했습니다. fd_quic이라는 Firedancer의 QUIC 구현은 메모리 할당을 최소화하고 메모리 고갈을 방지하는 최적화된 데이터 구조와 알고리즘을 도입합니다.

Firedancer의 맞춤형 네트워킹 스택은 처리 역량의 핵심입니다. 이 스택은 receive-side scaling (RSS)을 활용하도록 처음부터 설계되었습니다. RSS는 네트워크 트래픽을 여러 CPU 코어에 분산해 네트워크 처리 병렬성을 높이는 하드웨어 가속 네트워크 부하 분산 방식입니다. 각 CPU 코어가 최소한의 오버헤드로 수신 트래픽 일부를 처리합니다. 복잡한 스케줄러, 잠금, 원자 연산이 필요하지 않으므로 기존 소프트웨어 기반 부하 분산보다 뛰어납니다.

Firedancer는 고성능 tile로 애플리케이션을 구성하기 위한 새로운 메시지 전달 프레임워크를 도입합니다. 이 tile들은 AF_XDP를 사용해 소켓 기반이라 제약이 있는 커널 네트워킹을 우회할 수 있습니다. AF_XDP는 고성능 패킷 처리에 최적화된 주소 패밀리입니다. Firedancer는 AF_XDP를 통해 네트워크 인터페이스 버퍼에서 직접 읽을 수 있습니다.

이 tile 시스템은 Firedancer 스택에서 다양한 고성능 컴퓨팅 개념을 구현합니다. 다음과 같습니다.

• NUMA 인식 - NUMA(Non-Uniform Memory Access)는 프로세서가 다른 프로세서에 연결된 메모리보다 자체 메모리에 더 빠르게 접근할 수 있는 컴퓨터 메모리 설계입니다. Firedancer가 NUMA를 인식한다는 것은 다중 프로세서 구성에서 메모리를 효율적으로 처리할 수 있다는 의미입니다. 사용 가능한 하드웨어 리소스를 최적화하므로 대량 트랜잭션 처리에 중요합니다.
• 캐시 지역성 - 캐시 지역성은 프로세서 가까이에 있는 캐시의 데이터를 사용하는 개념입니다. 일반적으로 시간 지역성, 즉 최근에 접근한 데이터를 활용하는 복합적인 형태입니다. Firedancer는 캐시 지역성에 집중해 지연 시간을 최소화하고 속도를 극대화하면서 네트워크 데이터를 처리하도록 설계되었습니다.
• 잠금 없는 동시성 - 잠금 없는 동시성은 동시 작업을 관리할 때 mutexes 같은 잠금 메커니즘이 필요 없는 알고리즘을 설계하는 방식입니다. Firedancer에서는 잠금으로 인한 지연 없이 여러 네트워크 작업을 병렬로 수행할 수 있습니다. 이를 통해 많은 트랜잭션을 동시에 처리하는 능력이 향상됩니다.
• 큰 페이지 크기 - 메모리 관리에서 큰 페이지 크기를 사용하면 페이지 테이블 조회와 잠재적인 메모리 단편화를 줄여 데이터세트를 더 효과적으로 처리할 수 있습니다. Firedancer에서는 메모리 처리 효율이 향상되며, 대량의 네트워크 데이터를 처리하는 데 유리합니다.

빌드 시스템

Firedancer의 빌드 시스템은 안정성과 일관성을 보장하는 일련의 원칙에 따라 설계되었습니다. 외부 의존성을 최소화하고 빌드 과정에 사용되는 모든 도구 자체를 의존성으로 취급합니다. 컴파일러를 포함한 모든 의존성을 정확한 버전으로 고정합니다. 또한 빌드 단계에서 환경을 격리하는 것이 중요합니다. 빌드 프로세스가 시스템 환경의 영향을 받지 않으므로 이식성이 향상됩니다.

Firedancer는 어떻게 이렇게 빠른가요?

고급 데이터 병렬성

Firedancer는 ED25519 서명 검증과 같은 암호학 작업에 현대 프로세서 내부의 고급 데이터 병렬성을 활용합니다. 현대 CPU에는 여러 데이터 요소를 동시에 처리하는 Single Instruction, Multiple Data (SIMD) 명령어와 CPU 주기당 여러 명령어를 실행하는 최적화 기능이 있습니다. 하나의 명령어가 데이터 요소의 배열이나 벡터를 병렬로 처리하는 방식은 일반적으로 면적, 시간, 전력 측면에서 더 효율적입니다. 따라서 단순 처리 속도 향상보다 병렬 데이터 처리 개선이 처리량에 더 큰 영향을 줄 수 있습니다.

Firedancer가 데이터 병렬성을 사용하는 분야 중 하나는 서명 검증 연산 최적화입니다. 데이터 요소의 배열이나 벡터를 동시에 처리해 처리량을 극대화하고 지연 시간을 최소화합니다. 이 ED25519 구현의 핵심은 Galois Fields 산술입니다. 이 산술은 암호학 알고리즘과 이진 연산에 적합합니다. Galois Fields에서는 덧셈, 뺄셈, 곱셈, 나눗셈 같은 연산이 컴퓨터 시스템의 이진 특성에 맞게 정의됩니다. 다음은 23으로 정의된 Galois Field의 예입니다.

문제는 ED25519가 2255-19로 정의된 Galois Field를 사용한다는 점입니다. 필드 요소를 0부터 2255-19까지의 숫자로 생각해 보세요. 기본 연산은 다음과 같습니다.

• x + y → 초등학교식 덧셈 mod 2255-19
• x - y → 초등학교식 뺄셈 mod 2255-19
• x * y → 초등학교식 곱셈 mod 2255-19
• 1/x → x의 2255-21제곱 mod 2255-19

덧셈, 뺄셈, 곱셈은 거의 uint256_t 연산, 즉 최댓값이 2256-1인 부호 없는 정수 연산입니다. 나눗셈은 계산하기 어렵습니다. 범용 CPU와 GPU는 uint256_t 연산도, “거의 uint256_t 연산”도, 특히 까다로운 특수 나눗셈도 지원하지 않습니다. 이러한 연산을 구현하고 높은 성능을 내는 것은 이를 얼마나 잘 에뮬레이션하느냐에 달려 있습니다.

Firedancer 구현은 숫자를 더 유연하게 바라보며 산술을 분해합니다. 한 열에서 다음 열로 숫자를 올리는 초등학교식 긴 나눗셈과 곱셈 원리를 적용하면 이러한 열을 병렬로 처리할 수 있습니다. 이 연산을 가장 빠르게 에뮬레이션하는 방법은 uint256_t를 9비트 “올림수”가 있는 43비트 숫자 6개로 표현하는 것입니다. 이렇게 하면 CPU의 기존 64비트 연산을 활용하면서 올림 비트를 위한 충분한 공간을 확보할 수 있습니다. 이러한 숫자 배치는 잦은 올림 전파를 줄이고 Firedancer가 큰 수를 더 효과적으로 처리하게 합니다.

이 구현은 산술 계산을 병렬화된 열 합계로 재구성해 데이터 병렬성을 활용합니다. 열을 병렬로 처리하면 순차적 병목이 병렬화 가능한 작업으로 바뀌어 전체 연산이 빨라집니다. Firedancer는 AVX512와 IFMA 확장(AVX512-IFMA) 같은 벡터화 명령어 집합도 사용합니다. 이를 통해 앞서 설명한 Galois Fields 산술을 처리하여 속도와 효율성을 높입니다.

Firedancer의 AVX512 가속 구현은 빠릅니다. 단일 2.3 GHz Icelake-server 코어에서 코어 클록당 성능이 2022년 Breakpoint 데모의 두 배가 넘습니다. 100% 벡터 레인 활용률과 대규모 데이터 병렬화를 자랑합니다. Firedancer 팀은 빛의 속도로 인한 지연 때문에 맞춤형 하드웨어까지 투입하더라도 한 번에 하나씩 처리하는 것보다 서로 독립적인 작업을 병렬로 수행하는 편이 훨씬 쉽다는 점을 다시 한번 탁월하게 보여줍니다.

고속 네트워크 통신을 위한 FPGA 활용

CPU는 코어당 초당 ~30,000건의 서명 검증을 처리할 수 있습니다. 에너지 효율은 높지만 대규모 작업에는 부족합니다. 순차 처리 방식이 원인입니다. GPU는 코어당 초당 ~100만 건까지 처리 능력을 높입니다. 하지만 장치당 약 ~300W에 달하는 높은 전력 소비와 배치 처리에서 발생하는 고유한 지연 시간이 단점입니다.

FPGA는 더 뛰어난 대안입니다. GPU와 같은 처리량을 제공하면서 FPGA당 약 50W로 전력 소비가 훨씬 적습니다. 지연 시간도 GPU의 10밀리초보다 짧습니다. FPGA는 ~200마이크로초의 지연 시간으로 실시간 처리에 훨씬 빠르게 대응합니다. GPU의 배치 처리와 달리 Firedancer의 FPGA는 각 트랜잭션을 스트리밍 방식으로 개별 처리합니다. Firedancer는 FPGA 8개에 400W 미만의 전력을 사용하면서 초당 800만 건이라는 인상적인 서명 처리량을 달성합니다.

팀은 Breakpoint 2022에서 Firedancer의 ED25519 서명 검증 프로세스를 선보였습니다. 이 프로세스에는 순수 RTL 파이프라인에서의 SHA-512 계산과 맞춤형 ECC-CPU 프로세서 파이프라인의 여러 검사 및 계산 등 다양한 단계가 포함됩니다. 간단히 말해 Firedancer 팀은 맞춤형 프로세서를 위한 컴파일러와 어셈블러를 작성하고, RFC (Request for Comments)의 Python 코드를 가져와 연산자 오버로딩 객체로 실행해 머신 코드를 생성한 다음, 이 머신 코드를 ECC-CPU 위에 올렸습니다.

Firedancer는 안정성과 네트워크 연결성의 균형을 맞추기 위해 AWS 가속기 폼 팩터 스타일을 사용합니다. 이 선택은 클라우드 제공업체에서 흔히 제한되는 직접 네트워크 연결 문제를 해결합니다. Firedancer는 이를 통해 클라우드 기반 인프라의 제약 안에서도 고급 기능을 원활하게 통합합니다.

서로 다른 작업에는 개념적인 데이터 공간뿐 아니라 실제 물리적 공간도 필요하다는 점이 중요합니다. Firedancer는 이를 바탕으로 물리적 구성 요소를 서로 가깝고 재사용 가능하도록 전략적으로 배치합니다. 이 구성 덕분에 FPGA 효율을 극대화하여 8년 된 시스템의 7년 된 FPGA로 8m TPS를 달성합니다.

네트워크 통신을 위한 Reed-Solomon 코딩 최적화

네트워크 통신의 근본적인 과제는 새로운 트랜잭션을 전 세계로 브로드캐스트하는 것입니다. 인터넷의 지점 간 특성, 유한한 대역폭, 지연 시간 문제로 인해 네트워크를 직접 브로드캐스트에 사용하는 기존 방식을 구현하기 어렵습니다. 데이터를 링이나 트리 구조로 배포하면 일부 문제는 해결되지만 전송 중 데이터 패킷이 손실될 수 있습니다.

Reed-Solomon 코딩은 이러한 문제를 우아하게 해결합니다. 손실된 패킷을 복구할 수 있도록 데이터 전송에 중복성, 즉 패리티 정보를 추가합니다. 두 점이 하나의 선을 정의하며 이 선 위의 어느 두 점으로도 원본 데이터 점을 복원할 수 있다는 원리에 기반합니다. 데이터 점을 바탕으로 다항식을 만들고 이 함수의 서로 다른 점을 별도 패킷으로 배포하면, 수신자가 최소 두 패킷만 받아도 원본 데이터를 재구성할 수 있습니다.

직선 위 점을 위한 기존 공식(y = mx + b)은 계산이 느리므로 다항식을 만듭니다. Firedancer는 다항식 구성에 특화된 Lagrange Polynomials을 사용해 속도를 높입니다. Reed-Solomon 코딩에 필요한 다항식을 만드는 과정을 단순화합니다. 또한 고차 다항식에서도 작동하는 더 효율적인 행렬-벡터 곱으로 바꿉니다. 이 행렬은 패턴이 재귀적으로 반복되는 고도로 구조화된 형태이며, 패턴의 첫 번째 행만으로 전체를 결정할 수 있습니다. 이 구조 덕분에 모든 항을 더 빠르게 곱할 수 있습니다. Firedancer는 이 행렬을 곱할 때 2016년 논문에 제시된 O(n log n) 접근 방식을 사용합니다. 현재 알려진 Reed-Solomon 코딩의 이론적 접근 방식 중 가장 빠릅니다. 그 결과 기존 방식보다 패리티 정보를 효율적으로 계산합니다.

• 코어당 RS 인코딩 ~120 Gbps 이상
• 코어당 RS 디코딩 최대 ~50 Gbps
• 이 지표는 모두 현재 코어당 RS 인코딩 ~8 Gbps(rust-rse)와 비교한 값입니다

Firedancer는 최적화된 Reed-Solomon 코딩 방식으로 기존 방법보다 패리티를 14배 빠르게 계산할 수 있습니다. 그 결과 빠르고 안정적인 데이터 인코딩 및 디코딩이 가능해집니다. 이는 전 세계 규모에서 높은 처리량과 짧은 지연 시간을 유지하는 데 필수적입니다.

Firedancer는 어떻게 보안을 유지하나요?

기회

현재 모든 검증인은 원본 검증인 클라이언트를 기반으로 한 소프트웨어를 사용합니다. Firedancer가 Solana Labs 클라이언트와 확실히 구분된다면 Solana의 클라이언트 및 공급망 다양성을 높일 수 있습니다. 여기에는 유사한 의존성을 피하고 Rust가 아닌 언어로 클라이언트를 개발하는 것도 포함됩니다.

Solana Labs와 Jito 검증인 클라이언트는 단일 프로세스로 실행됩니다. 모놀리식 애플리케이션이 프로덕션에서 실행된 후 보안을 추가하기는 어렵습니다. 순수 Rust에서 실행 중 보안 업그레이드를 하려면 이 클라이언트를 실행하는 검증인을 종료해야 합니다. Firedancer 팀은 새 클라이언트에 처음부터 안전한 아키텍처를 구축할 수 있습니다.

Firedancer에는 기존 경험에서 배울 수 있다는 이점도 있습니다. Solana Labs는 스타트업 환경에서 검증인 클라이언트를 개발했습니다. 빠르게 움직이는 환경에서 시장에 신속히 출시해야 했습니다. 이로 인해 후속 개발에는 불리한 기반이 만들어졌습니다. Firedancer 팀은 Labs와 다른 체인의 팀이 수행한 작업을 살펴보고, 검증인 클라이언트를 처음부터 개발한다면 무엇을 다르게 할지 고민할 수 있습니다.

과제

Firedancer는 Solana Labs 클라이언트와 별개이지만 그 동작을 긴밀하게 재현해야 합니다. 그렇지 않으면 비호환성으로 합의 버그가 발생해 보안 문제가 될 수 있습니다. 일정 비율의 스테이킹 지분이 두 클라이언트 모두에서 실행되도록 장려하고, 장기간 Firedancer의 지분을 전체의 33% 미만으로 유지하면 위험을 완화할 수 있습니다. 어떤 경우든 Firedancer 팀은 정확하거나 안전하게 구현하기가 아무리 어렵더라도 프로토콜의 전체 기능을 구현해야 합니다. 모든 요소가 Firedancer와 일치해야 합니다. 따라서 코드를 독립적으로 개발할 수 없으며 Labs 클라이언트 기능과 대조해 검토해야 합니다. 사양과 문서가 부족해 Firedancer가 프로토콜의 비효율적인 구조까지 구현해야 한다는 점도 문제를 키웁니다.

Firedaner 팀은 새 클라이언트를 C로 개발한다는 점도 유의해야 합니다. C에는 Rust 같은 언어가 기본으로 제공하는 메모리 안전성 보장이 없습니다. Firedancer 코드베이스의 주요 목표는 메모리 안전성 취약점의 발생 횟수와 영향을 줄이는 것입니다. Firedancer는 빠르게 진행되는 프로젝트이므로 이 목표에 각별히 주의해야 합니다. 이러한 버그를 만들지 않으면서 개발 속도를 유지할 방법을 찾아야 합니다. OS 샌드박싱은 tile을 OS에서 격리하는 방식입니다. tile은 맡은 작업에 필요한 리소스에만 접근하고 시스템 호출만 수행할 수 있습니다. tile의 목적이 명확하고 클라이언트 코드 대부분을 Firedancer 팀이 개발했으므로, Principle of Least Privilege에 따라 tile 권한을 최소화합니다.

심층 방어 설계 구현

모든 소프트웨어에는 언젠가 보안 취약점이 생깁니다. Firedancer는 소프트웨어에 버그가 있다는 전제에서 역으로 접근해 한 취약점이 미칠 수 있는 영향을 제한합니다. 이를 심층 방어라고 합니다. 심층 방어는 다양한 보안 조치로 자산을 보호하는 전략입니다. 공격자가 시스템 한 부분을 침해해도 추가 조치가 위협이 전체 스택에 영향을 주는 것을 막습니다. Firedancer는 취약점이 익스플로잇으로 이어지는 단계를 차단하도록 설계되었습니다. 예를 들어 공격자가 메모리 안전성 취약점을 악용하기 어렵게 만듭니다.

이러한 공격을 막는 방법은 충분히 연구된 분야이기 때문입니다. C의 메모리 안전성에 관한 풍부한 연구 덕분에 팀은 Firedancer에 다양한 강화 기법과 컴파일러 기능을 활용합니다. 공격자가 업계 모범 사례를 우회하더라도 익스플로잇으로 시스템을 침해하기는 어렵습니다. tile 격리와 OS 샌드박싱 덕분입니다.

tile 격리는 Firedancer 병렬 아키텍처의 결과입니다. 각 tile은 자체 Linux 프로세스로 실행되므로 명확한 단일 목적을 갖습니다. 예를 들어 QUIC tile은 수신 QUIC 트래픽을 처리하고 캡슐화된 트랜잭션을 verify tile로 전달합니다. 이어서 verify tile이 서명을 검증합니다. QUIC tile과 verify tile은 공유 메모리 인터페이스, 즉 Linux 프로세스가 서로 데이터를 전달할 수 있는 방식을 통해 통신합니다. 두 tile 사이의 공유 메모리 인터페이스는 격리 경계 역할을 합니다. QUIC tile에 악성 QUIC 패킷을 처리할 때 공격자가 임의 코드를 실행할 수 있는 버그가 있어도 다른 tile에는 영향을 주지 않습니다. 모놀리식 프로세스라면 즉시 전체가 침해됩니다. 공격자가 여러 검증인에서 이 취약점을 악용하면 전체 네트워크에 피해를 줄 수 있습니다. QUIC tile의 성능을 떨어뜨릴 수는 있지만 Firedancer 설계는 영향을 QUIC tile로만 제한합니다.

OS 샌드박싱은 tile을 OS에서 격리하는 방식입니다. tile은 맡은 작업에 필요한 리소스에만 접근하고 시스템 호출만 수행할 수 있습니다. tile의 목적이 명확하고 거의 모든 코드를 Firedancer 팀이 개발했으므로 최소 권한 원칙에 따라 권한을 최소화합니다. tile은 자체 Linux 네임스페이스에 배치되어 시스템을 제한적으로만 볼 수 있습니다. 이 좁은 가시성은 tile이 파일 시스템 대부분, 네트워크, 동일한 시스템에서 실행되는 다른 프로세스에 접근하지 못하게 합니다. 네임스페이스는 보안을 우선하는 경계를 제공합니다. 하지만 공격자가 권한 상승을 위한 커널 익스플로잇을 보유했다면 우회할 수 있습니다. 시스템 호출 인터페이스는 tile에서 접근할 수 있는 커널 내 마지막 공격 벡터입니다. 이를 방어하기 위해 Firedancer는 seccomp-BPF로 커널 처리 전에 시스템 호출을 필터링합니다. 클라이언트는 tile이 선택된 시스템 호출만 사용하도록 제한할 수 있습니다. 경우에 따라 syscall 매개변수도 필터링할 수 있습니다. 따라서 Firedancer는 read 및 write syscall이 특정 파일 디스크립터에서만 작동하도록 보장할 수 있습니다.

내재화된 보안 프로그램 구현

Firedancer는 개발의 모든 단계에 포괄적인 보안 프로그램을 내재화하도록 설계되었습니다. 클라이언트 보안 프로그램은 개발팀과 보안팀이 지속적으로 협력하며 안전한 블록체인 기술의 새로운 기준을 세웁니다.

프로세스는 셀프서비스 퍼징 인프라에서 시작합니다. 참고로 퍼징은 취약점을 나타내는 충돌이나 오류 조건을 자동 탐지하는 기법입니다. P2P 인터페이스(파서)와 SBPF 가상 머신을 포함해 신뢰할 수 없는 사용자 입력을 받는 모든 구성 요소를 스트레스 테스트합니다. OSS-Fuzz는 코드가 변경되어도 지속적으로 퍼징 범위를 유지합니다. 보안팀은 지속적인 커버리지 기반 퍼징을 위해 전용 ClusterFuzzer 인스턴스도 구축했습니다. 개발자와 보안 엔지니어는 퍼징 하네스, 즉 보안 핵심 구성 요소를 위한 특별한 단위 테스트 버전도 제공합니다. 개발자가 새 퍼징 테스트를 추가하면 자동으로 수집해 테스트합니다. 모든 부분을 다음 단계로 넘기기 전에 집중적으로 퍼징하는 것이 목표입니다.

내부 코드 검토는 도구가 놓친 버그를 찾는 데 도움이 됩니다. 이 단계에서는 위험과 영향이 큰 구성 요소에 집중합니다. 또한 보안 프로그램의 다른 부분에 정보를 제공하는 피드백 메커니즘 역할을 합니다. 팀은 얻은 교훈을 모두 적용하고 검토 결과를 활용해 퍼징 범위를 개선하며, 특정 버그 유형을 위한 정적 분석 검사를 추가하고, 복잡한 공격 벡터를 설계 단계에서 제거하기 위해 대규모 코드 리팩터링도 수행합니다. 출시 전후에는 업계 최고의 전문가가 수행하는 외부 보안 검토와 적극적인 버그 바운티 프로그램이 내부 검토를 보완합니다.

Firedancer는 여러 테스트 네트워크에서 광범위한 스트레스 테스트도 거쳤습니다. 이 네트워크에서는 노드 복제, 네트워크 링크 장애, 패킷 플러딩, 합의 위반 같은 공격과 장애를 시험합니다. 실제 메인넷에서 발생할 수 있는 어떤 시나리오보다 훨씬 높은 부하를 적용합니다.

그렇다면 이제 이런 질문이 생깁니다. Firedancer의 현재 상태는 어떨까요?

Firedancer의 현재 상태와 Frankendancer란?

Firedancer 팀은 검증인 클라이언트를 모듈화하기 위해 Firedancer를 점진적으로 개발하고 있습니다. 이는 문서화와 표준화 목표에도 부합합니다. 이 접근 방식은 Firedancer가 Solana의 최신 개발 내용을 계속 반영하도록 합니다. 그 결과 Frankendancer가 탄생했습니다. Frankendancer는 Firedancer 팀이 개발한 구성 요소를 기존 검증인 클라이언트 인프라에 통합하는 하이브리드 클라이언트 모델입니다. 이러한 개발 프로세스를 통해 새 기능을 점진적으로 개선하고 테스트할 수 있습니다.

Frankendancer는 교통 흐름 한가운데 스포츠카를 넣는 것과 같습니다. 더 많은 구성 요소가 개발되고 병목이 제거될수록 성능이 향상됩니다. 이 모듈식 개발 프로세스는 맞춤화가 가능하고 유연한 검증인 환경을 만듭니다. 개발자는 필요에 맞게 검증인 클라이언트의 특정 구성 요소를 수정하거나 교체할 수 있습니다.

실제로 무엇이 실행되고 있나요?

Frankendancer는 Solana 검증인의 모든 네트워킹 기능을 구현합니다.

• 수신: QUIC, TPU, Sigverify, Dedup
• 송신: 블록 패킹, 샤드 생성/서명/전송(Turbine)

Frankendancer는 Solana Labs의 Rust 런타임 및 합의 코드 위에서 Firedancer의 고성능 C 네트워킹 코드를 사용합니다.

Frankendancer 아키텍처는 고성능 하드웨어 최적화를 염두에 두고 설계되었습니다. 표준 Linux 운영 체제를 실행하는 저사양 범용 클라우드 호스트도 지원하지만, Firedancer 팀은 코어 수가 많은 서버에 맞춰 Frankendancer를 최적화하고 있습니다. 장기적인 목표는 클라우드에서 이미 제공되는 하드웨어를 활용해 효율성과 성능을 높이는 것입니다. 클라이언트는 여러 동시 연결, 하드웨어 가속, 부하 분산을 위한 무작위 흐름 조정, 즉 네트워크 트래픽의 균등 분산, 구성 요소 사이의 보안을 강화하는 다수의 프로세스 경계를 지원합니다.

기술적 효율성은 Frankendancer의 핵심입니다. 시스템은 핵심 경로에서 메모리 할당과 원자 연산을 피하며, 초기화 시 모든 할당을 NUMA에 최적화합니다. 이 설계는 효율성과 성능을 극대화합니다. 또한 시스템 구성 요소를 비동기식으로 원격 검사할 수 있으며, tile을 비동기식으로 시작·중지·재시작할 수 있어 시스템의 안정성과 적응성이 향상됩니다.

성능은 어느 정도인가요?

Frankendancer는 네트워크 수신 측에서 tile당 초당 1,000,000건의 트랜잭션(TPS)을 처리할 수 있습니다. tile당 CPU 코어 1개를 사용하므로 사용 코어 수에 따라 성능이 선형으로 확장됩니다. Frankendancer는 코어 4개만 사용해 이 성능을 달성했으며 25 Gbps 네트워크 인터페이스 카드(NIC)의 한계까지 활용했습니다.

Frankendancer는 Turbine 최적화를 통해 네트워크 송신 작업을 크게 개선했습니다. 현재 표준 노드 하드웨어에서 tile당 6 Gbps 속도를 달성합니다. 여기에는 블록 데이터를 분할해 네트워크의 검증인에게 전송하는 shredding의 큰 속도 향상이 포함됩니다. 현재 표준 Solana 노드와 비교하면 Frankendancer의 shredding 속도는 Merkle 트리 없이 ~22%, Merkle 트리를 사용하면 거의 두 배 향상됩니다. 현재 검증인의 블록 전파와 트랜잭션 수집 성능을 크게 개선한 결과입니다.

Firedancer의 네트워크 성능은 하드웨어 한계에 도달했음을 보여줍니다. 현재 표준 검증인 하드웨어에서 가능한 최대 성능을 달성했습니다. 극단적인 워크로드도 효율적이고 효과적으로 처리할 수 있음을 입증한 중요한 기술적 이정표입니다.

Frankendancer가 테스트넷에서 가동 중입니다

현재 Frankendancer는 테스트넷에서 스테이킹하고 투표하며 블록을 생성하고 있습니다. ~2900개의 다른 Solana Labs 및 Jito 검증인과 호환되는 상태로 공존합니다. 이 실전 배포는 범용 하드웨어에서도 Firedancer가 강력한 성능을 제공한다는 점을 보여줍니다. 현재 AMD EPYC 7513 CPU를 탑재한 Equinix Metal m3.large.x86 서버에서 실행됩니다. 다른 많은 검증인도 같은 서버 유형을 사용합니다. 위치에 따라 달라지는 온디맨드 가격으로 비용 효율적인 솔루션을 제공합니다. 시간당 요금은 $3.10~$4.65입니다.

Firedancer가 메인넷 출시를 향해 진전하면서 노드 하드웨어에는 여러 가능성이 열립니다.

• 현재 검증인 하드웨어로 노드당 훨씬 높은 성능을 달성할 수 있습니다
• Firedancer의 효율성 덕분에 검증인은 비슷한 성능을 유지하면서 더 저렴하고 사양이 낮은 하드웨어를 사용할 수 있습니다
• Firedancer 설계는 하드웨어와 대역폭의 발전을 활용할 수 있습니다

이러한 발전과 Wiredancer, 즉 Firedancer 팀의 하드웨어 가속 실험, 모듈식 Rust 기반 Runtime/SVM 같은 다른 이니셔티브를 통해 Firedancer는 미래 지향적인 솔루션으로 자리 잡고 있습니다.

Firedancer의 진전은 검증인이 side-caring이라는 방식으로 Solana Labs 클라이언트와 Firedancer를 함께 실행할 가능성에 관한 논의도 촉발합니다. 두 클라이언트의 강점을 활용하고 어느 한쪽의 문제가 전체 네트워크에 미치는 영향을 완화해 네트워크 활성도를 극대화할 수 있습니다. 더 나아가 Jito 같은 프로젝트가 Firedancer를 포크할지도 주목됩니다. 이는 MEV 추출과 트랜잭션 처리 효율성을 한층 더 최적화할 수 있습니다. 결과는 시간이 지나야 알 수 있습니다.

결론

개발자는 일반적으로 작업이 물리적 공간이 아니라 데이터 공간을 차지한다고 생각합니다. 하지만 빛의 속도가 자연적인 제약으로 작용하므로 이러한 가정은 하드웨어를 제대로 최적화하지 못한 느린 시스템으로 이어집니다. 적대적이고 경쟁이 치열한 환경에서 Solana에 하드웨어만 더 투입하면 성능이 좋아질 것이라고 기대해서는 안 됩니다. 최적화가 필요합니다. Firedancer는 검증인 클라이언트의 구조와 운영 방식을 혁신합니다. Firedancer 팀은 안정적이고 고도로 모듈화되었으며 성능이 뛰어난 검증인 클라이언트를 구축해 Solana의 대중화를 준비하고 있습니다.

초급 개발자든 일반 Solana 사용자든 Firedancer와 그 중요성을 이해하는 것이 중요합니다. 이 기술적 성과는 현재 시장에서 가장 빠르고 뛰어난 성능을 제공하는 블록체인을 한층 더 발전시킵니다. Solana는 처리량이 높고 지연 시간이 짧은 글로벌 상태 머신으로 설계되었습니다. Firedancer는 이 목표를 완성하기 위한 거대한 도약입니다.

여기까지 읽어 주셔서 감사합니다, anon! 아래에 이메일 주소를 입력하면 Solana의 새로운 소식을 놓치지 않을 수 있습니다. 더 깊이 알아볼 준비가 되셨나요? 지금 Discord에 참여해 가장 뛰어난 성능의 블록체인에서 미래를 만들어 보세요.

추가 자료 / 더 읽을거리

• Jump 웹사이트
• Firedancer GitHub 저장소
• Breakpoint 2023: Firedancer 업데이트
• Breakpoint 2023: Firedancer 보안 강화
• Breakpoint 2023: 네트워크 통신을 위한 고속 Reed-Solomon 코딩
• Breakpoint 2023: 8m TPS로 작동하는 FPGA
• Firedancer의 fd_quic 기술적 이정표
• Solana 네트워크 업그레이드

부록

컴퓨터 하드웨어와 네트워킹 소개

컴퓨터는 산술 또는 논리 연산의 순서를 자동으로 수행하도록 프로그래밍할 수 있는 기계입니다. 이러한 작업은 기본 계산 자동화부터 복잡한 데이터 처리까지 다양합니다. 컴퓨터는 기본적으로 하드웨어와 소프트웨어 구성 요소를 결합해 명령을 실행하고 데이터를 관리합니다. 하드웨어는 물리적 구성 요소이며, 소프트웨어는 하드웨어의 작동 방법을 지시하는 프로그램과 운영 체제입니다.

유용한 연산에는 일반적으로 컴퓨팅, 메모리, 디스크 스토리지, 네트워킹이라는 네 가지 리소스가 필요합니다. 주로 CPU, GPU, 경우에 따라 FPGA가 담당하는 컴퓨팅은 매우 빨라 초당 수십억 번의 작업을 수행할 수 있습니다. RAM 접근은 일반적으로 CPU에서 연산을 수행하는 것보다 느립니다. 디스크 스토리지는 연산에 유용한 장기 저장 솔루션을 제공합니다. 하지만 Solid State Drive(SSDs)와 Hard Disk Drive(HDDs)의 데이터 접근은 CPU 작업보다 훨씬 느립니다. SSD는 보통 수천 배, HDD는 수만 배 느립니다. 인터넷과 로컬 네트워크를 포함한 네트워크는 가장 느립니다. CPU보다 100만 배 이상 느릴 수 있습니다.

이러한 속도 차이를 이해하는 것은 Firedancer 같은 고성능 컴퓨팅 애플리케이션의 설계 원칙과 효율성 고려 사항을 파악하는 데 중요합니다. CPU의 계산 속도가 기준이 되며 메모리, 디스크 스토리지, 네트워크 접근은 속도가 낮아지는 순서대로 지연을 추가합니다.

중앙 처리 장치(CPU)

CPU, 즉 중앙 처리 장치는 컴퓨터 기능의 핵심이며 기계의 두뇌입니다. CPU는 소프트웨어 명령을 실행하고 계산하며 입력을 바탕으로 결정을 내립니다. 0과 1의 연속인 이진 신호를 처리해 작동합니다. 고유한 이진 코드의 각 배열은 CPU가 해석하고 실행하는 특정 명령에 해당합니다. 명령은 순차적으로 처리되며 CPU는 한 작업을 완료한 뒤 다음 작업으로 넘어갑니다. 이러한 순차적 명령 처리는 CPU 역할의 근간이며, 복잡한 계산을 수행하고 입력을 바탕으로 결정을 내리는 방식을 좌우합니다.

현대 CPU는 흔히 멀티코어입니다. 하나의 칩 안에 코어라고 하는 여러 처리 장치가 있다는 의미입니다. 각 코어는 독립적으로 명령을 실행해 작업을 병렬 처리할 수 있습니다. 멀티코어 아키텍처는 CPU가 여러 작업을 동시에 처리하는 능력을 높여 전체 성능을 크게 개선합니다. 하지만 각 코어 내부에서는 여전히 작업이 순차적으로 처리됩니다. 따라서 CPU는 복잡하고 순차적인 작업에는 적합하지만 단순한 병렬 작업을 대량으로 처리할 때는 비효율적입니다.

CPU에는 캐시도 있습니다. CPU 내부의 작고 빠른 메모리 장치입니다. 캐시는 자주 접근하는 데이터와 명령을 저장해 RAM에서 데이터를 가져오는 것보다 빠르게 검색할 수 있도록 합니다. 일반적으로 크기와 속도가 다른 여러 캐시 계층(L1, L2, L3, 때로는 L4)이 있습니다. 가장 작고 빠른 L1 캐시에 먼저 접근합니다. 필요한 데이터가 없으면 더 크고 조금 느린 L2 캐시를 확인하는 식입니다. 이 계층적 캐싱 시스템은 CPU가 RAM 데이터를 기다리는 시간을 줄이고 전체 처리 속도를 높입니다. CPU와 RAM 사이의 거리가 성능을 저해할 수 있는 Firedancer 같은 애플리케이션에서는 효율적인 캐시 사용이 매우 중요합니다. 빛의 속도와 FPGA 활용에 관한 논의에서 특히 관련성이 큽니다.

참고로 “x86”은 Intel이 처음 개발한 특정 아키텍처를 따르는 CPU 제품군을 뜻합니다. 판매되는 데스크톱과 노트북 대부분이 x86 아키텍처 제품군을 기반으로 하므로 광범위한 소프트웨어와 호환됩니다.

그래픽 처리 장치(GPU)

GPU는 원래 컴퓨터 그래픽의 이미지 및 동영상 렌더링을 가속하기 위해 개발된 특수 프로세서입니다. 주요 기능은 그래픽 성능을 관리하고 향상하는 것입니다. 특히 비디오 게임이나 3D 모델링처럼 고해상도 시각 요소와 복잡한 그래픽 계산이 필요한 작업에 사용됩니다.

시간이 지나며 GPU는 원래 목적을 넘어 발전했습니다. GPU 아키텍처는 더 광범위한 데이터 처리 작업에서도 높은 가치를 제공합니다. 효율적인 병렬 처리 능력 덕분에 대규모 데이터세트를 동시에 처리해야 하는 애플리케이션에 적합합니다. 블록체인 기술에서는 GPU가 암호화폐 채굴에 널리 사용됩니다. 암호학 계산의 병렬 워크로드를 CPU보다 효율적으로 처리할 수 있기 때문입니다.

랜덤 액세스 메모리(RAM)

RAM은 현재 사용하거나 처리 중인 데이터를 저장하는 컴퓨터의 단기 메모리입니다. CPU는 여기에서 현재 작업 중인 내용을 “기억”하고 빠르게 접근하고 처리할 관련 정보를 보관합니다.

Error-Correcting Code(ECC) RAM은 일반적인 내부 데이터 손상 유형을 감지하고 수정할 수 있습니다. 데이터 정확성이 중요한 과학 컴퓨팅, 금융 트랜잭션, 블록체인 노드 같은 환경에서 필수적인 기능입니다. ECC RAM은 저장된 데이터의 작은 오류를 자동으로 찾아 수정할 수 있습니다. 이 오류 수정 과정은 RAM 모듈의 추가 하드웨어가 저장 데이터를 검사하는 방식으로 수행됩니다.

Non-ECC RAM은 일반 컴퓨터와 소비자 기기에서 더 흔히 사용하는 메모리 유형입니다. ECC RAM의 오류 수정 기능은 없지만 일반적으로 더 빠르고 저렴합니다. 표준 데스크톱 컴퓨팅에서는 데이터 오류 위험이 비교적 낮고 비용 효율적이므로 일반 용도로 선호됩니다.

디스크 스토리지

디스크 스토리지는 컴퓨터가 꺼진 상태에서도 데이터를 장기간 보존합니다. 주요 유형은 Hard Disk Drive(HDD)와 Solid State Drive(SSD) 두 가지입니다.

HDD는 플래터라는 자기 디스크에 데이터를 저장하는 구형 디스크 드라이브입니다. 플래터는 일반적으로 움직이는 액추에이터 암에 부착된 자기 헤드와 함께 작동합니다. 디스크가 회전하는 동안 이 암의 읽기/쓰기 헤드가 데이터에 접근합니다. 회전 디스크와 움직이는 헤드라는 HDD의 기계적 특성 때문에 SSD보다 상대적으로 느립니다. 하지만 더 저렴한 비용으로 더 큰 저장 용량을 제공합니다. 따라서 대용량 스토리지에 비용 효율적입니다.

반면 SSD는 플래시 메모리로 데이터를 저장합니다. 플래시 메모리는 지우고 다시 프로그래밍할 수 있는 전자식 비휘발성 저장 솔루션입니다. HDD와 달리 움직이는 부품이 없습니다. 대신 서로 연결된 플래시 메모리 칩이 데이터를 저장합니다. SSD는 디스크가 회전하거나 읽기/쓰기 헤드가 데이터를 찾을 때까지 기다리지 않고 즉시 접근할 수 있어 HDD보다 빠릅니다. 빠른 데이터 검색이 중요한 애플리케이션에 탁월합니다. 하지만 기가바이트당 비용은 HDD보다 높습니다.

NVMe (Non-Volatile Memory Express) SSD도 있습니다. 이 SSD는 컴퓨터의 Peripheral Component Interconnect Express (PCIe) 버스를 통해 높은 속도 잠재력을 활용하도록 설계되었습니다. NVMe 드라이브는 기존 SSD보다 훨씬 빠르고 지연 시간이 짧습니다. 고빈도 트레이딩과 블록체인 애플리케이션처럼 빠른 데이터 처리와 검색이 중요한 고부하 워크로드에 적합합니다. NVMe는 가격이 높지만 고성능 컴퓨팅의 표준으로 자리 잡기 시작했습니다.

마더보드

출처: Reddit r/buildapc 게시물의 Gigabyte X570 Elite 다이어그램

컴퓨터의 마더보드는 각 부품을 연결하고 통신을 지원하는 대형 회로 기판입니다. 이러한 부품에는 CPU, GPU, RAM, 저장 장치, 키보드와 마우스 같은 주변 기기가 포함됩니다.

마더보드는 모든 활동의 중심 허브입니다. 각 구성 요소가 서로 효과적으로 통신하도록 합니다. 전력 분배에서도 중요하며 전원 공급 장치의 전기를 각 주요 부품으로 전달합니다. 각 구성 요소가 작동하는 데 필요한 적절한 전력을 받도록 보장합니다.

마더보드는 시스템 내부의 데이터 흐름을 관리합니다. 처리를 위해 CPU에서 RAM으로, 저장을 위해 RAM에서 저장 장치로, 시각적 렌더링을 위해 GPU에서 디스플레이 출력으로 이동하는 데이터의 경로를 관리합니다. 또한 시스템의 BIOS(Basic Input/Output System)도 탑재합니다. BIOS는 시스템 제어와 모니터링에 필수적입니다. 컴퓨터가 시작될 때 하드웨어를 초기화하고 테스트합니다. 온도, 전압, 팬 속도 같은 요소를 모니터링하며 시스템 상태도 확인합니다.

Firedancer 설계에서는 마더보드 아키텍처가 핵심 역할을 합니다. CPU와 RAM 사이의 거리가 짧을수록 데이터 전송 속도가 높아지므로 두 구성 요소의 근접성이 성능에 큰 영향을 줍니다. 높은 처리량과 짧은 지연 시간이 필요한 Firedancer 같은 애플리케이션에서 이 거리는 중요합니다. 따라서 NUMA 인식 아키텍처와 잠재적인 FPGA 활용은 최적화된 메모리 할당과 처리 효율성이라는 Firedancer의 요구에 부합합니다. NUMA 인식의 의미와 FPGA가 무엇인지는 이 글의 뒷부분에서 설명합니다.

운영 체제, 가상 머신, 커널 수준 최적화

운영 체제(OS)는 컴퓨터의 하드웨어와 소프트웨어를 관리하는 핵심 소프트웨어입니다. 사용자와 컴퓨터 하드웨어의 상호작용을 지원하는 중개자입니다. 사용자가 시스템과 상호작용할 수 있는 인터페이스를 제공하고 다양한 애플리케이션에 리소스를 할당하고 관리합니다. 대표적인 예로 Windows, macOS, Linux가 있습니다.

커널은 모든 운영 체제의 중심에 있습니다. 시스템 하드웨어와 직접 상호작용하는 핵심 구성 요소입니다. 커널은 시스템의 모든 요소를 완전히 제어합니다. 메모리 할당, 프로세스 스케줄링, 입출력 요청을 관리합니다. 이러한 저수준에서 작동하며 시스템 성능과 안정성에 중요한 역할을 합니다.

시스템 호출(Syscall)은 사용자 애플리케이션과 커널을 연결합니다. 애플리케이션이 파일 읽기나 네트워크 데이터 전송처럼 시스템 리소스 접근이 필요한 작업을 수행할 때 syscall을 호출합니다. 그러면 커널이 애플리케이션을 대신해 요청된 작업을 수행합니다. 이 메커니즘은 시스템 리소스에 대한 접근을 통제해 보안과 안정성을 유지합니다.

가상 머신(VM)은 물리적 컴퓨터를 소프트웨어로 에뮬레이션한 것입니다. 하이퍼바이저, 즉 호스트 머신에서 가상 환경을 만들고 관리하는 소프트웨어 위에서 실행되며 격리된 환경에 물리적 컴퓨터의 전체 기능을 재현합니다. VM은 격리를 통한 보안, 리소스 효율성, 테스트 및 개발 유연성을 제공합니다.

Firedancer의 맥락에서 이러한 개념을 이해하는 것이 중요합니다. Firedancer는 성능을 높이기 위해 여러 커널 수준 최적화를 적용합니다.

• 대규모 정적 할당: Firedancer는 대규모 정적 할당, 즉 다른 프로세스가 공유할 수 있는 공유 메모리 할당을 사용해 동적 메모리 할당을 최소화합니다. 메모리를 한 번 할당한 뒤 재사용하여 잦은 할당과 해제에 따른 오버헤드를 줄입니다.
• 표준 라이브러리 우회: 표준 라이브러리 함수는 추가 추상화 계층을 더하는 경우가 많아 특정 작업에서 비효율적일 수 있습니다. Firedancer는 이러한 표준 라이브러리를 우회하고 syscall을 직접 수행합니다. Firedancer의 tile 아키텍처와 네트워킹 성능 최적화를 설명할 때 더 자세히 다룹니다.

Firedancer는 syscall과 OS 상호작용이 작업 속도를 크게 늦추므로 가능한 한 피합니다.

수신과 송신

수신과 송신은 컴퓨터 시스템이나 네트워크 안팎으로 흐르는 데이터를 설명하는 용어입니다.

수신은 데이터가 시스템에 들어오는 것을 뜻합니다. 인터넷에서 데이터를 받거나, 사용자 입력을 수락하거나, IoT(Internet of Things) 기기의 센서에서 정보를 수집하는 등 다양한 활동을 포함하는 일반적인 용어입니다. 서버나 블록체인 같은 네트워크 시스템에서 수신은 처리하거나 저장해야 하는 트랜잭션 요청, 사용자 쿼리, 수신 데이터 스트림을 받는 핵심 작업입니다. 수신 데이터를 효율적으로 처리하는 것은 시스템의 응답성과 기능에 중요합니다.

송신은 시스템에서 나가는 데이터를 뜻합니다. 온라인으로 정보를 전송하거나 사용자 요청에 대한 응답을 생성하거나 처리된 데이터를 다른 시스템으로 보내는 작업이 포함됩니다. 네트워크 시스템에서는 검증된 트랜잭션 전송, 블록체인 업데이트 브로드캐스트, 외부 저장 위치로의 데이터 전송 등이 해당합니다. 송신 데이터를 올바르게 관리해야 정보를 정확히 배포하고 시스템이 네트워크의 다른 부분과 효과적으로 통신할 수 있습니다.

파이프라인과 데이터 병렬성

파이프라인을 공장의 조립 라인이라고 생각해 보세요. 복잡한 프로세스를 더 작고 순차적인 단계로 나눕니다. 파이프라인의 각 단계는 특정 작업을 수행합니다. 블록체인이 트랜잭션을 계속 처리하는 것처럼 반복적이거나 연속적인 처리 작업에 매우 효율적입니다.

데이터 병렬성은 여러 요소를 동시에 독립적으로 처리하는 다른 접근 방식을 사용합니다. 공장에 데이터를 처리하는 조립 라인이 여러 개 있는 것과 같습니다. 더 작은 하위 작업으로 나눌 수 있는 업무에 효과적입니다. 블록체인, 특히 Firedancer 같은 시스템에서는 트랜잭션이나 데이터 처리 작업을 동시에 수행하는 데 데이터 병렬성이 중요합니다. Firedancer의 병렬 처리 기능은 연산 처리량을 극대화하고 처리 시간을 줄입니다.

파이프라인의 각 단계를 공장의 개별 작업대라고 생각해 보세요. 각 작업대는 독립적으로 동시에 작동할 수 있습니다. 한 단계에서 데이터 일부를 처리하는 동안 다음 단계가 다른 부분을 동시에 처리할 수 있습니다. 여러 파이프라인 단계가 동시에 활성화되어 처리량이 크게 증가합니다. Firedancer는 파이프라이닝의 순차적 효율성과 병렬성의 동시 처리 능력을 결합해 대량의 트랜잭션을 처리합니다.

Field-Programmable Gate Array(FPGA)

Field-Programmable Gate Arrays (FPGAs)는 제조 후에도 프로그래밍하거나 재구성할 수 있는 다목적 집적 회로입니다. 기존 하드웨어 구성 요소에는 없는 적응성을 제공합니다. 서로 연결된 방대한 프로그래머블 로직 블록 격자로 구성되며, 각 블록은 다양한 디지털 기능을 수행할 수 있습니다. 이러한 설계 덕분에 속도, 병렬 처리, 적응성이 중요한 애플리케이션에서 매우 유연하고 효율적입니다.

일반적인 FPGA는 프로그래밍 가능한 배선으로 모두 연결된 작은 프로그래머블 요소로 구성됩니다. 이 복잡한 부품과 연결망을 통해 사용자는 칩의 여러 영역을 프로그래밍하여 특정 작업을 수행할 수 있습니다. 완전히 맞춤화된 처리 환경을 만들 수 있습니다.

FPGA는 이러한 작은 프로그래머블 요소를 동시에 사용해 병렬 처리에서 뛰어난 성능을 냅니다. 구조적으로 데이터가 처리 단계를 통해 계속 전달되는 효율적인 파이프라이닝에 적합합니다. 잘 설계된 파이프라인은 시스템 처리량을 지연 시간과 분리합니다. 기존 CPU보다 출력 생성 시간이 더 걸릴 수 있지만 여러 입력 데이터 스트림을 동시에 처리할 수 있습니다. 호스를 따라 흐르는 물처럼 각 작업의 지연 시간은 전체 데이터 흐름에 거의 영향을 주지 않습니다.

Firedancer에서 FPGA는 큰 이점을 제공합니다. 데이터 파이프라인을 네트워크에 직접 연결할 수 있습니다. GPU가 데이터 이동을 CPU에 의존하는 기존 구성보다 네트워크 트래픽 처리에 효율적입니다. 직접 연결성과 FPGA 패브릭에 소프트 프로세서를 구축하는 등 맞춤형 처리 솔루션을 만드는 능력은 고성능 검증인 클라이언트 개발에 매우 중요합니다.

‍