Solana 핵심 개요

소개

Solana는 속도와 효율성, 사용자 경험에 중점을 둔 고성능 저지연 블록체인으로 잘 알려져 있습니다. 고유한 통합 아키텍처를 통해 전 세계에 분산된 네트워크에서 초당 수천 건의 트랜잭션을 처리합니다. 블록 시간은 400밀리초이며 트랜잭션 수수료는 1센트의 일부에 불과해 속도와 비용 효율성을 모두 제공합니다. 이 보고서에서는 Solana의 성능을 구현하는 핵심 메커니즘과 네트워크 토폴로지를 살펴보고, 설계와 운영 방식을 자세히 분석합니다.

Solana는 창립 팀이 수십 년간 분산 시스템을 구축하며 쌓은 경험을 활용해 블록체인 개발에 통합적으로 접근합니다. Solana의 핵심 원칙 중 하나는 소프트웨어가 하드웨어의 성능을 방해해서는 안 된다는 것입니다. 즉, 소프트웨어는 실행되는 하드웨어의 성능을 최대한 활용하며 하드웨어와 함께 확장됩니다. 하나로 통합된 생태계에서 이 단일 블록체인 위에 구축된 모든 애플리케이션은 조합 가능성을 공유합니다. 따라서 서로 원활하게 상호작용하고 기능을 확장할 수 있습니다. 또한 이 아키텍처는 브리징이나 별도의 체인 ID, 유동성 분산 없이 단순하고 직관적인 사용자 경험을 제공합니다.

Solana는 빠르게 발전하고 있으며, 최근에는 SVM 롤업과 ZK Compression이 중요한 확장 솔루션으로 등장했습니다. 이러한 프로젝트가 언젠가 Solana를 바라보는 관점을 바꿀 수 있지만, 현재는 개발 또는 도입의 극초기 단계이므로 이 보고서에서는 다루지 않습니다.

트랜잭션 수명 주기

이 보고서에서는 일반적인 트랜잭션의 수명 주기를 중심으로 Solana를 이해합니다. Solana 트랜잭션을 이해하기 위한 기본 모델은 다음과 같이 정리할 수 있습니다. 

• 사용자가 트랜잭션을 시작하면 모든 트랜잭션이 현재의 선도 블록 생성자, 즉 리더에게 전송됩니다. 리더는 이 트랜잭션들을 블록으로 구성하고 실행해 로컬 상태를 업데이트합니다.
• 이후 이 트랜잭션 블록은 네트워크 전체로 전파되며, 다른 검증인이 이를 실행하고 확인합니다.‍

이어지는 섹션에서는 핵심 참여자인 사용자부터 시작해 이 모델을 확장하고 전체 프로세스를 훨씬 자세히 살펴봅니다.

6단계

위의 6단계 도식은 Solana 핵심 요소 간의 관계를 일관된 체계로 이해할 수 있게 해주므로 이 보고서 전반에서 계속 참조합니다.

앞부분의 장은 이 6단계에 따라 구성했습니다. 마지막 장인 Gossip, Archive, Economics, Jito에서는 남은 내용을 정리합니다. 일부 장은 여러 단계에 걸쳐 있으며, 일부 단계는 여러 장에서 다뤄진다는 점에 유의해야 합니다.

6단계 체계에는 한계가 있으므로 이러한 중복은 피할 수 없습니다. 실제로 Solana는 상호 의존적인 요소가 많은 복잡한 분산 시스템입니다.

사용자

사용자의 여정은 일반적으로 지갑 애플리케이션을 설정하고 자금을 입금하는 것에서 시작합니다. Solana에서는 네이티브 모바일 애플리케이션이나 브라우저 확장 프로그램 형태로 제공되는 여러 인기 지갑 애플리케이션을 사용할 수 있습니다.

지갑은 공개 키와 비공개 키로 구성된 사용자 키 쌍을 암호학적으로 생성합니다. 공개 키는 계정의 고유 식별자 역할을 하며 네트워크의 모든 참여자에게 공개됩니다. Solana의 사용자 계정은 Solana 블록체인과 상호작용하며 생성된 정보와 상태를 담는 데이터 구조로 볼 수 있습니다. 이런 점에서 공개 키는 파일 이름과 유사합니다. 파일 이름이 파일 시스템 내의 파일을 고유하게 식별하듯, Solana 공개 키는 Solana 블록체인의 계정을 고유하게 식별합니다. Solana의 공개 키는 32바이트 Base58 인코딩 문자열로 표현됩니다.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

비밀 키라고도 하는 비공개 키는 계정에 접근하고 계정을 수정할 권한을 부여하는 비밀번호 또는 액세스 키로 볼 수 있습니다. 블록체인은 비공개 키 서명을 통해 권한을 처리합니다. 비공개 키를 알고 있으면 해당 계정에 대한 절대적인 권한을 갖습니다. Solana 비공개 키의 길이도 32바이트입니다. 키 쌍은 공개 키(앞 절반)와 비공개 키(뒤 절반)를 결합한 64바이트 데이터입니다.

예시:

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

비공개 키는 일반적으로 12개 또는 24개 단어로 이루어진 니모닉 시드 문구에서 파생할 수도 있습니다. 이 형식은 백업과 복구가 쉬워 지갑에서 자주 사용됩니다. 하나의 시드 문구에서 여러 키를 결정론적으로 파생할 수 있습니다.

Solana는 공개 키 암호화에 널리 사용되는 타원 곡선 디지털 서명 알고리즘인 Ed25519를 사용합니다. Ed25519는 키와 서명의 크기가 작고 계산이 빠르며 여러 일반적인 공격에 강해 선호됩니다. 각 Solana 지갑 주소는 Ed25519 타원 곡선 위의 한 점을 나타냅니다.

사용자는 비공개 키로 트랜잭션에 서명합니다. 이 서명은 트랜잭션 데이터에 포함되며 다른 참여자는 송신자의 공개 키를 사용해 검증할 수 있습니다. 이 과정은 트랜잭션이 변조되지 않았으며 해당 비공개 키의 소유자가 승인했음을 보장합니다. 서명은 트랜잭션의 고유 식별자 역할도 합니다.

Solana 트랜잭션‍

트랜잭션 전송은 Solana의 상태를 변경하는 유일한 방법입니다. 모든 쓰기 작업은 트랜잭션을 통해 수행되며, 트랜잭션은 원자성을 갖습니다. 즉 트랜잭션이 시도하는 모든 작업이 실행되거나 트랜잭션 전체가 실패합니다. 공식적으로 "트랜잭션 메시지"라고 하는 트랜잭션은 헤더, 계정 주소 목록, 최근 블록 해시, 명령의 네 부분으로 구성됩니다.

헤더

헤더에는 계정 주소 목록에 대한 참조가 있으며, 트랜잭션에 서명해야 하는 계정을 나타냅니다.

계정 주소

이 목록에는 트랜잭션 중에 읽거나 쓸 모든 계정이 포함됩니다. 모든 트랜잭션에 이러한 목록을 작성해야 하는 것은 Solana만의 요구 사항이며 개발자에게 어려울 수 있습니다. 하지만 트랜잭션이 상호작용할 상태를 미리 알면 다른 많은 블록체인에서는 불가능한 최적화를 수행할 수 있습니다.

최근 블록 해시

중복되거나 오래된 트랜잭션을 방지하는 데 사용됩니다. 최근 블록 해시는 150개 블록, 약 1분 후 만료됩니다. 기본적으로 RPC는 트랜잭션이 확정되거나 최근 블록 해시가 만료될 때까지 2초마다 트랜잭션 전달을 시도합니다. 블록 해시가 만료되면 트랜잭션은 폐기됩니다.

명령

명령은 트랜잭션의 핵심 부분입니다. 각 명령은 전송, 발행, 소각, 계정 생성, 계정 폐쇄 같은 특정 작업을 나타냅니다. 각 명령에는 실행할 프로그램, 필요한 계정, 명령 실행에 필요한 데이터가 지정됩니다.

트랜잭션의 명령 수는 우선 크기에 의해 제한되며 최대 1,232바이트까지 허용됩니다. 참조할 수 있는 계정 수에도 제한이 있습니다. 마지막으로 컴퓨팅 유닛(CU)으로 측정되는 트랜잭션 복잡도에도 제한이 있습니다. CU는 트랜잭션 처리에 사용되는 컴퓨팅 리소스를 수치화합니다.

트랜잭션 실행에 드는 SOL 비용은 기본 수수료와 우선순위 수수료의 두 부분으로 나뉩니다. 기본 수수료는 트랜잭션 복잡도와 관계없이 서명당 5,000 lamports로 고정됩니다. 일반적으로 트랜잭션당 서명은 1개입니다.

우선순위 수수료는 기술적으로 선택 사항이지만 블록 공간 수요가 많은 시기에는 필수적입니다. 이 수수료는 컴퓨팅 유닛당 micro-lamports(lamport의 100만분의 1)로 책정됩니다. 가격 신호로 작용해 검증인 노드가 해당 트랜잭션을 블록에 포함할 경제적 유인을 높이는 것이 목적입니다. ‍

total fee = prioritization fee + base fee

prioritization fee = compute unit price (micro-lamports) x compute unit limit

현재 트랜잭션 관련 수수료의 50%는 소각되어 해당 SOL이 유통량에서 영구적으로 제거되고, 나머지 50%는 블록 생성자에게 지급됩니다. 곧 새로운 변경 사항인 SIMD 96이 도입되어 우선순위 수수료의 100%가 블록 생성자에게 지급될 예정입니다. 기본 수수료는 변경되지 않습니다.

트랜잭션 전송

사용자가 지갑을 애플리케이션에 연결하면 앱이 사용자의 공개 키를 읽을 수 있습니다. 비공개 키는 암호화된 상태로 유지되며 애플리케이션과 분리된 환경에 안전하게 샌드박싱됩니다.

애플리케이션은 사용자의 상호작용을 기반으로 트랜잭션 메시지 매개변수를 구성합니다. 예를 들어 사용자가 두 토큰을 스왑하려는 경우 구매할 토큰 수량, 그에 대응해 판매할 토큰, 허용 가능한 트랜잭션 슬리피지를 지정합니다.

트랜잭션 메시지가 준비되면 사용자의 비공개 키로 서명하기 위해 지갑으로 전송됩니다. 이때 사용자에게 트랜잭션 진행 여부를 확인하는 팝업이 표시됩니다. 이 팝업에는 트랜잭션 결과의 시뮬레이션이 포함될 수 있습니다. 서명이 완료되면 트랜잭션 메시지와 서명이 앱으로 반환됩니다. 앱은 자체 RPC 제공업체나 지갑의 제공업체 등 원하는 RPC 제공업체로 트랜잭션을 전달할 수 있습니다.

RPC(Remote Procedure Call) 제공업체는 애플리케이션과 블록을 생성하는 검증인 사이의 중개자 역할을 합니다. 애플리케이션이 서명된 트랜잭션을 제출하거나 시뮬레이션하고 온체인 데이터를 효율적으로 가져올 수 있게 하는 필수 서비스입니다. 네트워크와 상호작용하려는 애플리케이션은 JSON-RPC 또는 WebSocket 엔드포인트를 사용합니다(문서).

Gulf Stream

RPC(Remote Procedure Calls)는 RPC 노드를 의미합니다. 이러한 노드는 네트워크와 상호작용하고 데이터를 읽는 게이트웨이로 볼 수 있습니다. 전체 검증인과 동일한 소프트웨어를 실행하지만 설정이 다르므로 트랜잭션을 정확히 시뮬레이션하고 현재 상태를 최신으로 유지할 수 있습니다. 이 글을 작성하는 시점에 Solana 네트워크에는 4,000개가 넘는 RPC 노드가 있습니다.

전체 검증인 노드와 달리 RPC 노드는 네트워크에 스테이크를 보유하지 않습니다. 스테이크가 없으므로 투표하거나 블록을 생성할 수 없습니다. 이는 검증인 노드와 RPC 노드가 일반적으로 동일한 다른 블록체인 대부분과 다른 구조입니다. RPC 노드는 스테이킹 보상을 받지 않으므로 운영 경제성도 검증인과 다릅니다. 많은 RPC 노드는 Solana 애플리케이션을 운영하는 개발자를 위한 유료 서비스로 운영됩니다.

Solana는 처음부터 멤풀 없이 작동하도록 설계되었다는 점에서 차별화됩니다. gossip 프로토콜을 사용해 네트워크 전반에 트랜잭션을 무작위로 광범위하게 전파하는 기존 블록체인과 달리, Solana는 각 슬롯에 미리 지정된 선도 검증인인 리더에게 모든 트랜잭션을 전달합니다.

RPC가 블록에 포함할 트랜잭션 메시지를 받으면 이를 리더에게 전달해야 합니다. 리더 일정은 각 에포크가 시작되기 전에 생성됩니다. 에포크는 약 이틀입니다. 다음 에포크는 각각 400밀리초로 고정된 슬롯으로 나뉘며, 각 슬롯의 리더가 선정됩니다. 스테이크가 많은 검증인일수록 각 에포크에서 리더로 더 자주 선정됩니다. 각 슬롯 동안 트랜잭션 메시지가 리더에게 전달되며, 리더는 블록을 생성할 기회를 얻습니다. 검증인의 차례가 되면 "리더 모드"로 전환해 트랜잭션을 적극적으로 처리하고 네트워크의 나머지 노드에 블록을 브로드캐스트합니다.

스테이크 가중 서비스 품질 - SWQoS

2024년 초, Solana는 스팸을 방지하고 시빌 저항성을 높이기 위한 새로운 메커니즘인 스테이크 가중 서비스 품질(Stake-Weighted Quality of Service, SWQoS)을 도입했습니다. 이 시스템을 통해 리더는 스테이킹된 다른 검증인을 거쳐 전달된 트랜잭션 메시지에 우선순위를 부여할 수 있습니다. 스테이크가 많은 검증인에게는 리더로 트랜잭션 메시지 패킷을 전송할 수 있는 용량이 비례해 더 많이 할당됩니다. 이 접근 방식은 네트워크 전반에서 스테이킹되지 않은 노드의 시빌 공격을 효과적으로 완화합니다.

‍이 모델에서 검증인은 스테이크 가중 용량을 RPC 노드에 임대하는 계약을 체결할 수도 있습니다. 그 대가로 RPC 노드는 더 많은 대역폭을 확보해 트랜잭션이 블록에 포함되는 비율을 높일 수 있습니다. 특히 리더 용량의 80%(2,000개 연결)는 SWQoS용으로 예약됩니다. 나머지 20%(500개 연결)는 스테이킹되지 않은 노드의 트랜잭션 메시지에 할당됩니다. 이 할당 전략은 운전자가 정체를 피하려고 통행료를 내는 고속도로의 우선 차로와 유사합니다.

SWQoS는 리더에게 트랜잭션을 전달하기 위한 요건을 높이고 스팸 공격의 효과를 줄여 Solana 생태계에 영향을 미쳤습니다. 이 변화는 트래픽이 많은 애플리케이션이 운영을 수직 통합하도록 장려했습니다. 애플리케이션은 자체 검증인 노드를 운영하거나 스테이킹된 연결에 접근해 리더에 대한 우선 접근권을 확보하고 트랜잭션 처리 역량을 높일 수 있습니다.

QUIC 참고 사항

2022년 말, Solana는 리더로 전송되는 트랜잭션 메시지를 관리하기 위해 QUIC 네트워킹 프로토콜을 도입했습니다. 봇이 온체인 NFT 민팅에 스팸을 보내 네트워크 장애를 일으킨 것이 전환의 계기가 되었습니다. QUIC는 빠른 비동기 통신을 지원합니다.

‍QUIC는 2012년에 Google이 처음 개발했으며 양쪽의 장점을 모두 제공하려 합니다. UDP와 유사한 빠른 비동기 통신을 지원하면서도 TCP의 보안 세션과 고급 흐름 제어 전략을 제공합니다. 이를 통해 개별 트래픽 소스에 제한을 적용하고 네트워크가 실제 트랜잭션 처리에 집중하도록 할 수 있습니다. 또한 별도의 스트림이라는 개념이 있어 트랜잭션 하나가 폐기되어도 나머지 트랜잭션을 차단할 필요가 없습니다. 간단히 말해 QUIC는 TCP와 UDP의 장점을 결합하려는 시도로 볼 수 있습니다.

블록 생성

많은 블록체인 네트워크는 전체 블록을 구성한 다음 브로드캐스트합니다. 이를 개별 블록 생성이라고 합니다. 반면 Solana는 할당된 시간 슬롯 동안 블록을 생성하는 동시에 동적으로 구성하고 스트리밍하는 연속 블록 생성 방식을 사용해 지연 시간을 크게 줄입니다.

각 슬롯은 400밀리초 동안 지속되며, 각 리더에게는 다음 리더로 교체되기 전에 연속된 슬롯 4개, 즉 1.6초가 할당됩니다. 블록이 승인되려면 블록 내의 모든 트랜잭션이 유효해야 하며 다른 노드가 동일하게 재현할 수 있어야 합니다.

검증인은 리더 역할을 맡기 두 슬롯 전에 트랜잭션 전달을 중단하고 예정된 작업 부하에 대비합니다. 이 구간에는 전체 네트워크가 차기 리더에게 패킷을 보내면서 유입 트래픽이 급증해 초당 1GB를 넘습니다.

트랜잭션 메시지를 수신하면 블록 생성을 담당하는 검증인의 핵심 로직인 트랜잭션 처리 장치(TPU)로 들어갑니다. 트랜잭션 처리 순서는 QUIC를 통해 트랜잭션을 수신하는 Fetch Stage에서 시작합니다. 이후 트랜잭션은 SigVerify Stage로 넘어가 엄격한 검증을 거칩니다. 여기서 검증인은 서명의 유효성과 서명 수가 정확한지 확인하고 중복 트랜잭션을 제거합니다.

‍Banking Stage

Banking Stage는 블록 생성 단계로 설명할 수 있습니다. TPU에서 가장 중요한 단계이며 이름은 “bank“에서 유래했습니다. bank는 특정 블록 시점의 상태입니다. Solana에는 각 블록마다 해당 블록의 상태에 접근하는 데 사용되는 bank가 있습니다. 충분한 검증인이 블록에 투표해 확정되면 bank의 계정 업데이트를 디스크에 기록해 영구 보존합니다. 체인의 최종 상태는 확인된 모든 트랜잭션의 결과입니다. 이 상태는 블록체인 기록을 통해 언제나 결정론적으로 재현할 수 있습니다.‍

트랜잭션은 병렬로 처리된 후 원장 “엔트리”로 패키징됩니다. 엔트리는 서로 충돌하지 않는 트랜잭션 64개의 배치입니다. Solana에서는 각 트랜잭션에 읽고 쓸 모든 계정의 전체 목록이 포함되어야 하므로 병렬 트랜잭션 처리가 수월합니다. 이 설계는 개발자에게 부담을 주지만, 검증인이 각 엔트리에서 서로 충돌하지 않는 트랜잭션만 쉽게 선택해 실행함으로써 경쟁 상태를 피할 수 있게 합니다. 두 트랜잭션이 동일한 계정에 쓰려고 하거나(쓰기 두 번), 하나는 읽고 다른 하나는 동일한 계정에 쓰려고 하면(읽기 + 쓰기) 충돌합니다. 따라서 충돌하는 트랜잭션은 서로 다른 엔트리에 들어가 순차적으로 실행되고, 충돌하지 않는 트랜잭션은 병렬로 실행됩니다.

트랜잭션을 병렬로 처리하는 스레드는 6개입니다. 4개는 일반 트랜잭션에 사용되고, 2개는 Solana 합의 메커니즘에 필수적인 투표 트랜잭션만 처리합니다. 모든 처리 병렬화는 여러 CPU 코어를 통해 이루어지며 검증인에게 GPU는 필요하지 않습니다(문서).‍

트랜잭션을 엔트리로 그룹화하면 Solana Virtual Machine(SVM)에서 실행할 준비가 됩니다. 트랜잭션에 필요한 계정이 잠기고, 트랜잭션이 최근에 생성되었지만 아직 처리되지 않았는지 확인합니다. 계정을 로드한 다음 트랜잭션 로직을 실행해 계정 상태를 업데이트합니다. 엔트리의 해시는 기록을 위해 Proof of History 서비스로 전송됩니다. 자세한 내용은 다음 섹션에서 다룹니다. 기록에 성공하면 모든 변경 사항이 bank에 커밋되고 첫 단계에서 설정한 각 계정의 잠금이 해제됩니다. 실행은 SVM이 담당합니다. SVM은 JIT 컴파일과 eBPF 프로그램용 가상 머신을 다루는 라이브러리인 rBPF의 Solana 포크를 사용해 구축한 가상 머신입니다. Solana는 검증인이 블록 내 트랜잭션 순서를 정하는 방식을 규정하지 않습니다. 이 유연성은 매우 중요한 부분이며 이 보고서의 Economics + Jito 섹션에서 다시 살펴봅니다.‍

클라이언트

Solana는 하나의 통합 원장을 유지하기 위해 협력하는 수천 개의 독립 운영 노드로 구성된 네트워크입니다. 각 노드는 “클라이언트”라고 하는 동일한 오픈 소스 소프트웨어를 실행하는 고성능 머신입니다.

Solana는 처음에 하나의 검증인 클라이언트 소프트웨어로 출시되었습니다. 원래 Solana Labs 클라이언트였으며 현재는 Agave 클라이언트로 불리는 Rust 기반 소프트웨어입니다. 이후 클라이언트 다양성을 확대하는 것이 주요 과제가 되었으며, Firedancer 클라이언트 출시와 함께 결실을 맺을 전망입니다. Firedancer는 기존 클라이언트를 C 프로그래밍 언어로 처음부터 완전히 다시 작성한 클라이언트입니다. 고빈도 거래 회사 Jump의 숙련된 팀이 개발했으며, 모든 블록체인을 통틀어 가장 뛰어난 성능의 검증인 클라이언트가 될 것으로 기대됩니다.

Proof of History

Proof of History(PoH)는 Solana의 핵심 기술입니다. 모든 검증인에서 특수한 시계처럼 작동하며 네트워크 전체의 동기화를 지원합니다. PoH는 이벤트 순서와 시간 경과를 판단할 신뢰할 수 있는 기준을 확립합니다. 가장 중요한 역할은 리더 스케줄 준수를 보장하는 것입니다. 이름은 비슷하지만 Proof of History는 작업 증명과 같은 합의 알고리즘이 아닙니다.

‍노드 간 통신 오버헤드는 일반적으로 네트워크가 확장될수록 증가하며, 조정도 점점 복잡해집니다. Solana는 노드 간 통신을 PoH 로컬 연산으로 대체해 이 문제를 완화합니다. 따라서 검증인은 단 한 번의 투표만으로 블록을 확정할 수 있습니다. 메시지의 신뢰할 수 있는 타임스탬프는 검증인이 서로의 순서를 침범하거나 블록을 너무 일찍 시작하지 못하게 합니다.

PoH의 기반에는 해싱 알고리즘, 특히 SHA256의 고유한 특성이 있습니다.

• 결정성: 동일한 입력은 언제나 동일한 해시를 생성합니다.
• 고정 크기: 입력 크기와 관계없이 출력 해시는 항상 256비트입니다.
• 효율성: 주어진 입력의 해시를 빠르게 계산할 수 있습니다.
• 역상 저항성: 해시 출력에서 원래 입력을 찾는 것은 계산상 불가능합니다.
• 눈사태 효과: 입력이 조금만 바뀌어도, 심지어 단일 비트만 변경되어도 해시가 크게 달라집니다. 이를 눈사태 효과라고 합니다.
• 충돌 저항성: 동일한 해시 출력을 생성하는 서로 다른 두 입력을 찾는 것은 불가능합니다.

각 검증인 클라이언트에서는 전용 "Proof of History 서비스"가 SHA256 해시 알고리즘을 계속 실행해 해시 체인을 생성합니다. 각 해시의 입력은 이전 해시의 출력입니다. 해싱 작업은 순서대로 수행해야 하고 미래 해시의 결과를 미리 알 수 없으므로, 이 체인은 검증 가능한 지연 함수처럼 작동합니다. PoH 서비스가 1,000개의 해시로 구성된 체인을 생성했다면 각 해시를 순서대로 계산할 만큼 시간이 흘렀음을 알 수 있습니다. 이를 “마이크로 작업 증명”으로 볼 수 있습니다. 하지만 각 해시의 입력과 출력이 네트워크에 브로드캐스트되므로, 다른 검증인은 이 1,000개 해시의 정확성을 병렬로 검증해 생성 시간보다 훨씬 빠르게 확인할 수 있습니다. 따라서 PoH는 생성하기 어렵지만 검증하기는 쉽습니다.

서로 다른 CPU에서 SHA-256을 계산할 때의 성능 편차는 놀라울 정도로 작으며, 가장 빠른 시스템 사이에도 차이가 크지 않습니다. Bitcoin이 이 함수에 크게 의존한 덕분에 오랜 시간과 노력을 들여 최적화했음에도 이미 일반적인 성능 상한에 도달했습니다.

‍리더의 슬롯 동안 PoH 서비스는 뱅킹 단계에서 새로 처리된 엔트리를 받습니다. 현재 PoH 해시와 엔트리에 포함된 모든 트랜잭션의 해시를 결합해 다음 PoH 해시를 만듭니다. 이는 엔트리를 해시 체인에 삽입하는 타임스탬프 역할을 하며, 트랜잭션이 처리된 순서를 증명합니다. 이 과정은 시간의 경과를 확인할 뿐 아니라 트랜잭션의 암호학적 기록으로도 기능합니다.

단일 블록에는 800,000개의 해시가 있습니다. PoH 스트림에는 리더의 활성 상태와 아주 짧은 시간의 경과를 나타내는 빈 엔트리인 "틱"도 포함됩니다. 틱은 6.25밀리초마다 발생하므로 블록당 64개의 틱이 생성되며, 전체 블록 시간은 400밀리초입니다.

검증인은 리더가 아닐 때도 PoH 시계를 계속 실행합니다. PoH 시계가 노드 간 동기화 과정에서 핵심 역할을 하기 때문입니다.

계정 모델

Solana 검증인 내부에서는 AccountsDB라는 계정 데이터베이스가 전역 상태를 유지합니다. 이 데이터베이스는 메모리와 디스크 모두에 모든 계정을 저장합니다. 계정 인덱스의 주요 데이터 구조는 해시맵이므로 AccountsDB는 본질적으로 거대한 키-값 저장소입니다. 여기서 키는 계정 주소이고 값은 계정 데이터입니다.

시간이 흐르면서 Solana 계정 수는 수억 개로 급증했습니다. 이렇게 많은 이유 중 하나는 Solana 개발자들이 즐겨 말하듯 "Solana에서는 모든 것이 계정이기 때문입니다!"

Solana 계정

계정은 컴퓨터의 파일과 비슷하게 데이터를 영구적으로 보관하는 컨테이너입니다. 계정에는 여러 형태가 있습니다.

• 사용자 계정: 비공개 키가 있으며 일반적으로 지갑 소프트웨어가 사용자를 위해 생성합니다.
• 데이터 계정: 사용자가 보유한 특정 토큰의 수량과 같은 상태 정보를 저장합니다.
• 프로그램 계정: 실행 가능한 바이트코드를 포함하는 더 큰 계정입니다. Windows의 .exe 파일이나 Mac의 .app 파일과 비슷합니다.
• 네이티브 프로그램 계정: 네트워크의 여러 핵심 기능을 수행하도록 미리 배포된 특수 프로그램 계정입니다. 예시로는 Vote Program과 BPF Loader가 있습니다.

모든 계정에는 다음 필드가 있습니다.

프로그램‍

Solana 프로그램 계정에는 실행 로직만 포함됩니다. 즉, 프로그램이 실행되면 다른 계정의 상태를 변경하지만 프로그램 자체는 바뀌지 않습니다. 이러한 코드와 상태의 분리는 Solana를 다른 블록체인과 구분하며 다양한 최적화를 뒷받침합니다. 개발자는 주로 안전성과 성능을 중시하는 범용 프로그래밍 언어 Rust로 프로그램을 작성합니다. 또한 애플리케이션 프런트엔드 개발과 네트워크와의 프로그래밍 방식 상호작용을 지원하는 TypeScript 및 Python SDK도 여러 개 제공됩니다.

여러 일반 기능은 네이티브 프로그램을 통해 기본 제공됩니다. 예를 들어 Solana에서는 토큰을 만들기 위해 개발자가 코드를 배포할 필요가 없습니다. 대신 미리 배포된 네이티브 프로그램에 명령을 보내면 토큰 메타데이터를 저장할 계정을 설정해 새 토큰을 생성합니다.

임대료

임대료는 사용자가 계정을 닫도록 유도해 상태 팽창을 줄이는 메커니즘입니다. 새 계정을 만들려면 "임대료 면제" 금액으로 알려진 최소 SOL 잔액을 계정에 보유해야 합니다. 이는 검증인의 메모리에서 계정을 유지하기 위해 발생하는 저장 비용으로 볼 수 있습니다. 계정 데이터 크기가 증가하면 필요한 최소 임대료 잔액도 비례해 늘어납니다. 계정이 더 이상 필요하지 않으면 닫을 수 있으며, 임대료는 계정 소유자에게 반환됩니다. 

예를 들어 사용자가 달러 표시 스테이블코인을 보유하면 이 상태는 토큰 계정에 저장됩니다. 현재 토큰 계정의 임대료 면제 금액은 0.002 SOL입니다. 사용자가 스테이블코인 잔액 전부를 친구에게 전송하면 토큰 계정을 닫고 0.002 SOL을 돌려받을 수 있습니다. 프로그램이 사용자를 대신해 계정 폐쇄를 자동으로 처리하는 경우가 많습니다. 오래되어 사용하지 않는 계정을 정리하고 그 안의 소액 SOL을 회수하도록 돕는 여러 애플리케이션도 있습니다.

소유권

누구나 계정 데이터를 읽을 수 있지만, Solana의 소유권 모델은 계정 데이터를 수정(쓰기)할 수 있는 주체를 엄격히 제한해 보안을 강화합니다. 이 개념은 Solana 블록체인에서 규칙과 권한을 적용하는 데 매우 중요합니다. 모든 계정에는 프로그램 "소유자"가 있습니다. 계정 소유자는 계정을 관리하며 권한이 있는 프로그램만 계정 데이터를 변경할 수 있게 합니다. 이 규칙의 대표적인 예외는 lamports(SOL의 최소 단위) 전송입니다. 소유권과 관계없이 누구나 계정의 lamports 잔액을 늘릴 수 있습니다.

상태 저장

읽기 전용 실행 파일인 Solana 프로그램은 “Program Derived Addresses”(PDA)를 사용해 상태를 저장해야 합니다. PDA는 특정 사용자가 아니라 프로그램과 연결되고 프로그램이 소유하는 특수한 계정 유형입니다. 일반 Solana 사용자 주소는 Ed25519 키 쌍의 공개 키에서 파생되지만 PDA에는 비공개 키가 없습니다. 대신 해당 공개 키는 흔히 키워드나 다른 계정 주소인 여러 매개변수와 소유 프로그램의 프로그램 ID(주소)를 조합해 파생됩니다.

PDA 주소는 "곡선 밖"에 있습니다. 즉, 일반 주소와 달리 Ed25519 곡선 위에 있지 않습니다. PDA를 소유한 프로그램만 프로그래밍 방식으로 해당 PDA의 서명을 생성할 수 있으므로, 그 프로그램만 PDA 상태를 수정할 수 있습니다.

Turbine

뱅킹 단계에서 트랜잭션은 엔트리로 구성되고 타임스탬프를 기록하기 위해 Proof of History 스트림으로 전송됩니다. 블록의 뱅크가 업데이트되면 엔트리는 다음 단계인 Turbine으로 넘어갈 준비를 마칩니다.

Turbine은 리더가 네트워크의 나머지 노드에 블록을 전파하는 과정입니다. BitTorrent에서 영감을 받아 빠르고 효율적으로 설계됐으며, 통신 오버헤드와 리더가 보내야 하는 데이터양을 줄입니다.

‍Turbine은 "샤딩"이라는 과정을 통해 트랜잭션 데이터를 "샤드"로 나눕니다. 샤드는 최대 1,280바이트의 작은 데이터 패킷으로, 동영상 스트림의 개별 프레임과 비슷합니다. 샤드를 다시 조립하면 검증인이 전체 블록을 재실행할 수 있습니다. 샤드는 UDP를 사용해 인터넷을 통해 검증인 사이에 전송되며, 패킷 손실이나 악의적인 패킷 폐기에 대응하기 위해 소거 코딩을 활용합니다. 소거 코딩은 다항식 기반 오류 감지 및 수정 방식으로 데이터 무결성을 보장합니다. 일부 샤드가 손실되어도 블록을 재구성할 수 있습니다.

샤드는 순방향 오류 정정(FEC) 배치라는 묶음으로 그룹화됩니다. 기본적으로 각 배치는 64개의 샤드(데이터 샤드 32개 + 복구 샤드 32개)로 구성됩니다. 데이터 복구는 FEC 배치 단위로 이루어지므로 배치 내 패킷의 절반까지 손실되거나 손상되어도 모든 데이터를 복구할 수 있습니다. 64개 샤드로 구성된 각 배치는 머클화되고, 루트에는 리더가 서명하며 이전 배치와 연결됩니다. 머클 루트 체인이 진위와 무결성을 검증할 수 있는 경로를 제공하므로, 네트워크에서 샤드를 보유한 어떤 노드에서도 안전하게 샤드를 가져올 수 있습니다.

리더는 먼저 하나의 루트 노드에 브로드캐스트하며, 이 노드는 다른 모든 검증인 노드에 샤드를 전파합니다. 루트 노드는 샤드마다 바뀝니다. 검증인은 여러 계층으로 구성되어 "Turbine 트리"를 형성합니다. 스테이킹 규모가 큰 검증인은 일반적으로 트리 상단에, 규모가 작은 검증인은 하단에 배치됩니다.

‍활성 검증인 수에 따라 트리는 일반적으로 2~3홉에 걸쳐 구성됩니다. 위 그림에서는 시각적 단순화를 위해 팬아웃을 3으로 표시했지만, 현재 Solana의 실제 팬아웃 값은 200입니다. 보안을 위해 새 샤드 배치마다 트리 순서가 바뀝니다.

이 시스템의 주요 목표는 리더와 루트 노드의 외부 데이터 송신 부담을 완화하는 것입니다. 전송과 재전송 시스템을 활용해 리더와 재전송 노드 사이에 부하를 분산하고 단일 노드에 가해지는 부담을 줄입니다.

합의

검증인이 Turbine을 통해 리더로부터 새 블록을 받으면 각 엔트리의 모든 트랜잭션을 검증해야 합니다. 전체 블록을 재실행하고, PoH 해시를 병렬로 검증하며, PoH가 지정한 순서대로 트랜잭션을 재현하고, 로컬 뱅크를 업데이트합니다. 

‍이 과정은 Transaction Validation Unit(TVU)이 처리합니다. TVU는 리더의 Transaction Processing Unit(TPU)에 대응하며, 샤드 처리와 블록 검증을 담당하는 핵심 로직입니다. TPU와 마찬가지로 TVU 흐름은 여러 단계로 나뉩니다. 먼저 Shred Fetch Stage에서 Turbine을 통해 샤드를 받습니다. 이어지는 Shred Verify Leader Signature Stage에서는 샤드에 여러 무결성 검사를 수행합니다. 가장 중요한 검사는 리더의 서명을 확인해 수신한 샤드가 리더에게서 생성됐음을 보장하는 것입니다. ‍

Retransmit Stage에서 검증인은 Turbine 트리 내 위치에 따라 적절한 하위 검증인에게 샤드를 전달합니다. Replay Stage에서는 로컬 뱅크 버전을 업데이트하면서 각 트랜잭션을 정확히 올바른 순서로 재현합니다.

Replay Stage는 TPU의 뱅킹 단계에 대응합니다. 가장 중요한 단계이며 블록 검증 단계라고 더 직접적으로 설명할 수 있습니다. Replay는 투표, PoH 시계 재설정, 뱅크 전환 등 여러 핵심 작업을 조율하는 단일 스레드 프로세스 루프입니다. 

합의

Solana는 합의를 달성하기 위해 널리 알려진 Practical Byzantine Fault Tolerance(PBFT) 알고리즘을 맞춤 구현한 Tower BFT(TBFT)를 사용합니다. PBFT는 대부분의 블록체인이 체인 상태에 합의할 때 널리 사용합니다. 모든 블록체인과 마찬가지로 Solana도 네트워크에 악의적인 노드가 존재한다고 가정하므로, 시스템은 노드 장애뿐 아니라 일정 수준의 공격도 견뎌야 합니다.

Tower BFT는 Proof of History가 제공하는 동기화된 시계를 활용한다는 점에서 다른 체인과 차별화됩니다. 기존 PBFT는 트랜잭션 순서에 합의하기 위해 여러 차례 통신해야 하지만, Solana 노드는 미리 확립된 이벤트 순서를 활용해 메시징 오버헤드를 크게 줄입니다.

투표

‍검증인은 합의에 참여하고 보상을 받기 위해 유효하다고 판단되는 블록, 즉 이중 지출이나 잘못된 서명 같은 문제가 없으며 정식 블록으로 간주해야 하는 블록에 투표합니다. 검증인은 이 투표에 트랜잭션 수수료를 지불합니다. 투표는 리더가 처리하고 일반 사용자 트랜잭션과 함께 블록에 포함합니다. 이 때문에 Solana 트랜잭션은 흔히 투표 트랜잭션과 비투표 트랜잭션으로 분류됩니다. 검증인이 정확하고 성공적인 투표를 제출하면 크레딧을 얻습니다. 이 메커니즘은 검증인이 포함될 가능성이 가장 높다고 판단한 포크, 즉 “가장 무거운” 포크에 투표하도록 유도합니다.

포크

Solana가 매우 빠른 이유 중 하나는 새 블록을 생성하기 전에 모든 검증인이 직전 블록에 합의할 때까지 네트워크가 기다리지 않도록 설계됐기 때문입니다. 그 결과 서로 다른 두 블록이 동일한 부모 블록에 연결되어 포크를 만드는 일이 드물지 않습니다.

Solana 검증인은 이러한 포크에 투표하고 합의 알고리즘을 사용해 채택할 포크를 결정해야 합니다. 경쟁 포크가 있으면 최종적으로 하나만 네트워크에서 확정되며, 제외된 포크의 블록은 폐기됩니다.

각 슬롯에는 미리 정해진 리더가 있으며 해당 리더의 블록만 허용됩니다. 하나의 슬롯에 두 블록을 제안할 수는 없습니다. 따라서 발생 가능한 포크의 수는 리더 교대 슬롯 경계에서 나타날 수 있는 "있음/없음" 형태의 스킵 포크 목록으로 제한됩니다. 검증인이 포크를 선택하면 잠금 시간이 만료될 때까지 해당 포크에 커밋되며, 최소 기간 동안 선택을 유지해야 합니다.

‍블록이 생성되지 않은 슬롯의 비율인 Solana "스킵 비율"은 2%~10%이며, 포크가 슬롯을 건너뛰는 주된 원인입니다. 새 에포크의 시작, 리더의 오프라인 상태, 유효하지 않은 블록 생성 등도 슬롯이 건너뛰어지는 원인이 될 수 있습니다.

기억하세요:

Solana 트랜잭션의 상태는 현재 합의 과정의 단계에 따라 달라집니다.

• 처리됨: 트랜잭션이 블록에 포함됐습니다.
• 확인됨: 트랜잭션이 포함된 블록에 3분의 2 이상의 압도적 다수가 투표했습니다.
• 확정됨: 트랜잭션이 포함된 블록 위에 31개가 넘는 블록이 생성됐습니다.

지금까지 Solana 역사에서 낙관적으로 확인된 블록이 확정되지 않은 사례는 단 한 번도 없습니다.‍

Solana는 모든 블록에서 뱅크를 사용해 해당 블록의 상태에 접근합니다. 뱅크가 확정되면 해당 뱅크와 조상 뱅크의 계정 업데이트를 디스크에 기록합니다. 또한 확정된 뱅크의 조상이 아닌 이전 뱅크의 계정 업데이트는 제거합니다. 이 과정을 통해 Solana는 여러 잠재적 상태를 효율적으로 유지할 수 있습니다.

Gossip + 아카이브

Gossip

Gossip 네트워크는 Solana 네트워크의 제어 영역으로 볼 수 있습니다. 트랜잭션 흐름을 처리하는 데이터 영역과 달리 제어 영역은 연락처 정보, 원장 높이, 투표 정보 등 블록체인 상태에 관한 핵심 메타데이터를 전파합니다. Gossip이 없으면 검증인과 RPC는 여러 서비스에서 통신을 위해 어떤 주소와 포트가 열려 있는지 알 수 없습니다. 새 노드도 네트워크에 참여할 때 Gossip에 의존합니다.

Solana의 Gossip 프로토콜은 수정된 PlumTree 알고리즘에서 영감을 받은 트리 브로드캐스트 방식의 비공식 P2P 통신을 사용합니다. 이 방식은 중앙 소스에 의존하지 않고 정보를 효율적으로 전파합니다.

Gossip은 다른 대부분의 검증인 구성 요소와 독립된 격리 시스템처럼 작동합니다. 검증인과 RPC는 Gossip을 통해 UDP로 0.1초마다 서명된 데이터 객체를 공유해 네트워크 전체에서 정보를 사용할 수 있게 합니다. 모든 Gossip 메시지는 최대 전송 단위(MTU)인 1,280바이트 이하여야 하며, 코드베이스에서는 이를 "packet struct"라고 부릅니다.

Gossip 레코드는 노드 간에 공유되는 실제 데이터 객체입니다. 약 10가지 유형이 있으며 각각 다른 용도로 사용됩니다. Gossip 레코드는 무결성과 최신성을 보장하기 위해 서명되고 버전과 타임스탬프가 지정됩니다.

Gossip 메시지는 네 가지 유형으로 나뉩니다.‍

1. Push: 가장 일반적인 메시지로, "푸시 피어" 일부와 정보를 공유합니다.
2. Pull & Pull Response: 누락된 메시지가 있는지 주기적으로 확인하며, Pull Response는 노드에 없는 정보를 돌려보냅니다.
3. Prune: 노드가 유지하는 연결 수를 선택적으로 줄일 수 있게 합니다.
4. Ping & Pong: 노드의 상태를 확인합니다. Ping을 보내면 Pong 응답을 기대하며, 이를 통해 피어 노드가 여전히 활성 상태임을 확인합니다.

Gossip 데이터는 Cluster Replicated Data Store(CrdsTable)에 저장됩니다. 이 데이터 구조는 매우 커질 수 있으므로 주기적으로 정리해야 합니다.

아카이브

Solana는 계정의 현재 상태를 파악하기 위해 전체 기록을 요구하지 않는다는 점에서 다른 블록체인과 차별화됩니다. Solana의 계정 모델은 특정 슬롯의 상태를 알 수 있도록 보장하므로, 검증인은 모든 과거 블록을 처리하지 않고도 각 계정의 현재 상태를 저장할 수 있습니다. RPC와 검증인은 설계상 전체 과거 원장을 보관하지 않습니다. 일반적으로 체인의 끝부분을 검증하기에 충분한 1~2개 에포크(2~4일) 분량의 트랜잭션 데이터만 저장합니다.

현재 아카이브는 전문 RPC 서비스 제공업체, Solana Foundation, 트랜잭션 기록의 가용성 보장에 관심이 있는 기타 생태계 참여자가 운영하는 "웨어하우스 노드"에서 관리합니다. 웨어하우스 노드는 일반적으로 다음 중 하나 또는 둘 다를 유지합니다.

1. 원장 아카이브: 처음부터 재실행하는 데 적합한 원시 원장과 AccountsDB 스냅샷을 업로드합니다.
2. Google Bigtable 인스턴스: 제네시스 블록 이후의 블록 데이터를 RPC 요청에 응답할 수 있는 형식으로 저장합니다.

경제 + Jito

Solana는 매 에포크마다 새 SOL 토큰을 생성하고 스테이킹 보상을 분배하기 위해 인플레이션을 활용합니다. 이 과정에서 비스테이커의 네트워크 지분은 스테이커에 비해 감소하며, 부가 비스테이커에서 스테이커로 이전됩니다. 인플레이션은 2021년 초 8%로 시작했으며, 장기 비율인 1.5%에서 안정될 때까지 매년 15%씩 감소합니다.

‍SOL 토큰 보유자는 누구나 하나 이상의 검증인에게 토큰을 스테이킹해 보상을 받고 네트워크 보안에 기여할 수 있습니다. 검증인에게 토큰을 할당하는 것을 위임이라고 합니다. 검증인에게 토큰을 위임한다는 것은 해당 검증인을 신뢰한다는 의미입니다. 하지만 검증인에게 토큰의 소유권이나 통제권을 주지는 않습니다. 모든 스테이킹, 언스테이킹, 위임 작업은 다음 새 에포크가 시작될 때 실행됩니다.

투표 보상

‍검증인이 투표를 제출하고 그 투표가 정확하며 성공하면 크레딧을 얻습니다. 투표 트랜잭션 비용은 0.000005 SOL이며 우선순위 수수료가 면제됩니다. 투표 비용은 검증인당 하루 약 1 SOL로, 검증인 운영의 주요 비용입니다. 검증인은 에포크 동안 투표로 크레딧을 쌓고, 에포크가 끝날 때 이를 인플레이션 지분으로 교환할 수 있습니다.

최고 성능의 검증인은 약 90%의 슬롯에서 투표에 성공합니다. 블록이 없는 슬롯의 비율인 스킵 슬롯 비율은 2%에서 10%를 넘기도 하며, 이런 슬롯에는 투표할 수 없습니다. 평균적인 검증인은 슬롯의 약 80%에서 성공적으로 투표해 432,000개 슬롯으로 구성된 에포크에서 345,600크레딧을 얻습니다.

전체 인플레이션 재원은 먼저 에포크에서 획득한 크레딧에 따라 나뉩니다. 전체 크레딧에서 검증인이 차지하는 비율, 즉 해당 검증인의 크레딧을 모든 검증인의 크레딧 합계로 나눈 값에 따라 비례 보상이 정해집니다. 여기에 스테이킹 가중치가 추가로 적용됩니다.

따라서 전체 스테이킹의 1%를 보유하고 평균 수준의 크레딧을 얻은 검증인은 전체 인플레이션의 약 1%를 받아야 합니다. 크레딧이 평균보다 많거나 적으면 보상도 그에 따라 달라집니다.‍

투표 성과의 차이는 검증인이 스테이커에게 제공하는 수익률(APY 기준)이 달라지는 이유 중 하나입니다. 또 다른 요인은 검증인이 부과하는 수수료율로, 해당 검증인에게 배정된 전체 인플레이션 보상 중 일정 비율입니다. 또한 검증인이 오프라인이거나 블록체인과 동기화되지 않은 상태인 비정상 상태도 수익률에 큰 영향을 줍니다.

블록 보상

특정 블록의 리더로 지정된 검증인은 추가 블록 보상을 받습니다. 이 보상은 블록 내 모든 트랜잭션의 기본 수수료 50%와 우선순위 수수료 50%로 구성되며, 나머지 수수료는 소각됩니다. 블록을 생성한 검증인만 이 보상을 받습니다. 에포크마다 분배되는 스테이킹 보상과 달리 블록 보상은 블록이 생성되는 즉시 검증인의 신원 계정에 적립됩니다.

유동 스테이킹

유동 스테이킹은 네이티브 스테이킹의 인기 있는 대안으로 자리 잡았습니다. 참여자는 SOL을 스테이킹하는 대가로 Liquid Staking Token(LST) 또는 Liquid Staking Derivative(LSD)라는 토큰을 받습니다. 일반적으로 여러 검증인에게 토큰을 위임하는 스테이크 풀을 사용합니다. 새로 받은 LST 토큰은 스테이킹된 SOL에서 사용자가 보유한 지분을 나타냅니다. 이 토큰은 계속 스테이킹 보상을 받으면서 거래하거나 애플리케이션에서 사용하거나 다른 사람에게 전송할 수 있습니다. 이 시스템의 주요 장점은 자본 효율성을 크게 높인다는 것입니다.

Price of LST = (total staked SOL in pool * price of SOL) / total LST minted

기존 네이티브 스테이킹에서는 시간이 지날수록 스테이커에게 더 많은 SOL이 직접 쌓입니다. 반면 유동 스테이킹에서는 보상이 풀에 재투자되어 LST의 공정 가치가 높아집니다. LST를 기반 자산인 스테이킹된 SOL로 상환할 수 있는 메커니즘이 있는 한 차익 거래자는 토큰 가격이 합리적인 수준을 유지하도록 합니다.

Jito

이 글을 작성하는 시점에 Solana 스테이킹의 80% 이상이(출처) Jito 검증인 클라이언트 소프트웨어를 사용합니다. 기존 Agave 클라이언트에서 포크된 이 클라이언트는 프로토콜 외부 블록 공간 경매를 도입해 팁을 통한 추가 경제적 인센티브를 검증인에게 제공합니다. 이 추가 인센티브는 검증인 사이에서 Jito 클라이언트가 널리 채택된 주요 요인입니다.

리더가 Jito 검증인 클라이언트를 사용하면 트랜잭션은 먼저 Jito-Relayer로 전달됩니다. 이 오픈 소스 소프트웨어는 트랜잭션 프록시 라우터 역할을 합니다. 다른 네트워크 노드는 Jito-Relayer의 존재를 알지 못합니다. 리더가 Gossip 네트워크에서 자신의 ingress_socket으로 알린 주소와 포트 구성을 리더의 것으로 간주하고 그곳에 트랜잭션을 보낼 뿐입니다.

‍릴레이어는 모든 트랜잭션을 200밀리초 동안 보관한 뒤 리더에게 전달합니다. 이 "과속 방지턱" 메커니즘은 들어오는 트랜잭션 메시지를 지연해 경매를 진행할 짧은 시간을 확보합니다. 200밀리초가 지나면 릴레이어는 경매 결과와 관계없이 트랜잭션을 낙관적으로 전송합니다.

블록 공간 경매는 Jito Block Engine을 통해 오프체인에서 진행됩니다. 검색자와 애플리케이션은 번들이라는 원자적으로 실행되는 트랜잭션 그룹을 제출할 수 있습니다. 이러한 번들에는 일반적으로 차익 거래나 청산처럼 시간에 민감한 트랜잭션이 포함됩니다. Jito는 모든 팁에 5%의 수수료를 부과하며 최소 팁은 10,000 lamports입니다. 팁은 프로토콜 내 우선순위 수수료 및 기본 수수료와 별개로 완전히 프로토콜 외부에서 작동합니다. 이전에 Jito는 표준 프로토콜 외부 멤풀 서비스를 운영했지만 현재는 지원이 중단됐습니다.