Helius 제품 및 플랫폼
자동 확장
법정화폐 요금제를 위한 Helius의 자동 크레딧 충전 메커니즘입니다. 월간 크레딧 할당량을 모두 사용하면 자동 확장이 사용자가 설정한 한도까지 추가 크레딧을 구매하여429 오류로 인해 프로덕션 트래픽이 중단되지 않도록 합니다. 암호화폐 요금제에는 자동 확장이 없습니다. 대신 수동으로 구매하는 선불 크레딧을 사용합니다.
자동 확장을 참조하세요.
크레딧
Helius가 API 및 스트리밍 사용량을 청구하는 단위입니다. RPC 메서드, DAS 호출, 스트리밍 처리량에는 각각 정해진 크레딧 비용이 있습니다. 모든 요금제에는 각 청구 주기마다 초기화되는 월간 크레딧 할당량이 포함됩니다. 사용하지 않은 크레딧은 이월되지 않습니다. 전체 비용 표는 크레딧을 참조하세요.DAS API
Digital Asset Standard는 Solana 디지털 자산(NFT, 압축 NFT, 대체 가능 토큰)을 위한 통합 인터페이스의 개방형 사양입니다. Helius의 DAS API 구현은 보강된 메타데이터, 소유권, 가격 정보를 구조화된 단일 응답으로 반환하므로 온체인 자산 데이터용 커스텀 파서를 만들 필요가 없습니다. DAS API를 참조하세요.전용 노드
속도 제한이나 크레딧 측정 없이 고정 월 요금으로 청구되는 비공개 Helius RPC 노드입니다. 무제한 처리량이 필요한 제한적인 사용 사례에 적합합니다. 대부분의 애플리케이션에는 성능, 장애 조치, 기능 범위가 더 우수한 일반 Helius RPC가 더 적합합니다. 전용 노드를 참조하세요.향상된 트랜잭션
프로그램별 명령 파서 없이 원시 Solana 트랜잭션을 토큰 전송, NFT 판매, 스왑, 스테이킹 작업 등의 사람이 읽을 수 있는 이벤트로 디코딩하는 Helius의 트랜잭션 파싱 API입니다. 향상된 트랜잭션을 참조하세요.오류 코드
Helius API가 반환하는 표준 HTTP 상태 코드와 Helius 관련 설명은 다음과 같습니다.400 Bad Request— 잘못된 매개변수 또는 잘못된 형식의 요청(예: 잘못된 주소 형식, 필수 필드 누락, 잘못된 형식의 JSON)401 Unauthorized— 누락되었거나 유효하지 않은 API 키403 Forbidden— 액세스 거부. 일반적으로 IP 제한, 엔드포인트가 포함되지 않은 구독 또는 부족한 API 키 권한으로 인해 발생404 Not Found— 요청한 리소스에 사용 가능한 데이터가 없음(알 수 없는 지갑의 ID 조회에서는 정상)429 Too Many Requests— 크레딧 할당량 소진, 속도 제한 초과 또는 동시 요청 제한 도달5xx— Helius 측 문제. 지수 백오프로 재시도
Gatekeeper
전 세계에 분산된 프록시 집합을 통해 요청을 라우팅하여 표준 RPC 호출보다 지연 시간을 크게 낮추는 Helius의 에지 게이트웨이입니다. RPC URL에서mainnet.helius-rpc.com을 beta.helius-rpc.com으로 바꾸어 액세스합니다.
아키텍처 배경은 Gatekeeper와 Gatekeeper 소개 블로그 게시물을 참조하세요.
LaserStream
과거 데이터 재생, 다중 리전 장애 조치, Helius 스트리밍 제품 중 가장 풍부한 기능을 제공하는 Solana 온체인 데이터용 Helius 고성능 gRPC 스트리밍 서비스입니다. JavaScript/TypeScript, Rust, Go용 공식 SDK가 제공됩니다. LaserStream WebSocket은 동일한 인프라에서 실행됩니다. SDK 벤치마크에 대한 자세한 내용은 LaserStream과 LaserStream SDK 성능 블로그 게시물을 참조하세요.LaserStream WebSocket
Helius의 지속형 WebSocket 스트리밍 서비스입니다. 표준 Solana WebSocket 메서드와 Helius 전용 확장 기능(transactionSubscribe 및 더 다양한 필터링을 지원하는 향상된 accountSubscribe)을 하나의 통합 엔드포인트에서 제공합니다. LaserStream WebSocket은 LaserStream gRPC와 백엔드를 공유합니다.
LaserStream WebSocket을 참조하세요.
Preconfirmations
Helius의 지연 시간이 가장 짧은 트랜잭션 신호입니다. 트랜잭션이 엔트리로 수집되고 shred로 분할되기 전에 스트리밍합니다. 리더가 트랜잭션을 실행하는 즉시 실행 상태와 함께 Helius preconfirmations를 제공하며, 검증자가 트랜잭션 실행을 커밋하면 실제 실행 전에 BAM preconfirmations를 제공합니다. Shred Delivery보다 빠르고 processed commitment 스트림보다도 빠릅니다.preconfSubscribe WebSocket 구독을 통해 제공됩니다. 모든 유료 플랜에서 이용할 수 있으며, 전달된 메시지당 10크레딧이 부과됩니다. 메시지가 없는 슬롯에는 비용이 부과되지 않습니다. 하나 이상의 메시지가 전달된 슬롯에는 구독당 최소 300크레딧이 부과됩니다. 커버리지는 어떤 검증자가 스트림을 Helius로 전달하는지에 따라 달라지므로 피드는 연속적이지 않습니다.
Preconfirmations 및 preconfSubscribe을 참조하세요.
우선순위 수수료 API
실시간 온체인 수수료 시장을 기반으로 권장 우선순위 수수료 값을 반환하는 Helius의 수수료 추정 엔드포인트입니다. 혼잡할 때 추측하거나 과도하게 지불하지 않고 경쟁력 있는 수수료를 책정할 수 있습니다. 우선순위 수수료 API를 참조하세요.속도 제한
특정 Helius 요금제에서 허용되는 초당 최대 요청 수입니다. 속도 제한은 요금제 등급과 API 계열(표준 RPC, 향상된 API, 스트리밍)에 따라 다릅니다. 제한을 초과하면429 Too Many Requests이 반환됩니다.
속도 제한을 참조하세요.
Sender
우선순위 수수료, Jito 팁, 스테이크 연결 라우팅을 결합하여 랜딩 성공률을 극대화하도록 저지연 트레이더를 위해 구축된 Helius의 전문 트랜잭션 랜딩 서비스입니다.https://sender.helius-rpc.com/fast에서 사용할 수 있습니다.
Sender를 참조하세요.
Shred Delivery
최종 블록이 조립되기 전에 원시 Solana 슈레드를 UDP를 통해 스트리밍하는 Helius의 서비스입니다. Helius는 특정 검증인 한 곳의 지리적 지연 시간 편차를 최소화하기 위해 여러 지역에 분산된 검증인 네트워크에서 슈레드를 집계합니다. 고빈도 거래 및 기타 저지연 애플리케이션에 유용합니다. 원시 슈레드는 Helius Dashboard에서 셀프서비스로 이용할 수 있으며, 가격은 IP당 월 $1,000 USD입니다(Pro 요금제에서는 IP당 월 $800 USD). 슈레드 작동 방식에 대한 자세한 내용은 Shred Delivery와 블로그 게시물 밀리초 경쟁에서 승리하기: 슈레드, LaserStream, 그리고 Solana의 에지를 참조하세요.스테이크 연결
Helius 유료 요금제의 기본 트랜잭션 제출 경로입니다. 스테이크 연결은 Solana의 프로토콜 수준 Stake-Weighted Quality of Service(SWQoS)를 통해 예정된 블록 리더에게 트랜잭션을 라우팅합니다. 이 메커니즘은 검증자 스테이크에 따라 연결 슬롯을 우선 배정하고 혼잡 시 패킷 손실을 줄입니다. 호출자가 직접 대규모 스테이크를 보유한 검증자를 운영하지 않아도 Helius 유료 요금제를 통해 이러한 랜딩 성공률 이점을 얻을 수 있습니다. 트랜잭션 최적화와 블로그 게시물 Stake-Weighted Quality of Service: 알아야 할 모든 것을 참조하세요.지갑 API
Solana 지갑의 잔액, 트랜잭션 기록, 전송, ID, 자금 출처를 조회하는 Helius의 REST API입니다. 원시 RPC 출력 대신 구조화되고 USD로 가격이 표시된 응답을 제공합니다. 주소 외에도 SNS.sol 및 ANS 도메인 이름을 허용합니다.
지갑 API를 참조하세요.
Solana 기본 개념
계정
Solana에서 데이터를 영구적으로 보관하는 컨테이너로, 32바이트 공개 키로 식별됩니다. 사용자 잔액, 프로그램 코드, 토큰 메타데이터 등 모든 온체인 상태는 프로그램 자체를 포함하여 계정에 저장됩니다. 모든 계정에는 데이터를 수정하거나 램포트를 인출할 수 있는 프로그램인 소유자가 있으며, 영구적으로 유지되려면 최소 SOL 잔액(임대료 면제)을 보유해야 합니다. 자세한 내용은 블로그 게시물 Solana 프로그래밍 모델: Solana 개발 입문을 참조하세요.Agave
Anza에서 유지 관리하는 현재의 표준 Solana 검증자 클라이언트로, 원래 Solana Labs 클라이언트의 브랜드를 변경한 후속 제품입니다. 특정 Agave 릴리스에 대한 언급(예: v1.17.31의 SWQoS 최소 스테이크 임계값)은 일반적으로 동작을 특정 클라이언트 버전에 고정합니다. Jito-Solana는 블록 엔진을 통합한 Agave 포크이며, Firedancer는 Jump Crypto에서 개발한 독립적인 C 기반 대안입니다. Agave가 구현하는 SVM 모델은 블로그 게시물 Solana 가상 머신을 참조하세요.에어드롭
주소에 SOL 또는 SPL 토큰을 지급하는 것입니다. Devnet과 Testnet에서 에어드롭은 일반적으로 개발 지갑에 자금을 제공하기 위해 수도꼭지에서 받는 소량의 테스트 SOL을 의미합니다. Mainnet에서는 기존 보유자에게 토큰을 대량 배포하는 것을 의미합니다. Devnet 에어드롭은 Devnet 수도꼭지를 통해 이용할 수 있습니다.연결 토큰 계정(ATA)
특정 지갑 주소의 특정 SPL 토큰을 보관하도록 결정론적으로 파생된 토큰 계정입니다. 각 지갑에는 토큰 민트당 최대 하나의 ATA가 있으므로 ATA는 사용자의 토큰 잔액을 조회하는 표준 위치입니다. 지갑 주소와 토큰 민트를 시드로 사용하여 파생합니다.블록
트랜잭션 집합과 블록 해시 및 이전 블록 해시를 비롯한 필수 메타데이터를 포함하여 변경 불가능한 체인을 형성하는 데이터 구조입니다. 블록은 슬롯 중에 생성됩니다. 슬롯에 배정된 리더가 수신 트랜잭션을 검증하고 블록으로 패키징한 후 Turbine을 통해 네트워크에 브로드캐스트합니다. 모든 슬롯에서 블록이 생성되는 것은 아닙니다. 리더가 제시간에 블록을 생성하지 못하면 해당 슬롯을 건너뛰고 네트워크는 계속 진행합니다. 블록이 스테이크 가중치 기준 검증자 투표의 절대다수를 얻으면 확인된 것으로 간주합니다(커밋 수준 참조). 자세한 내용은 블로그 게시물 Solana의 슬롯, 블록, 에포크 이해하기를 참조하세요.커밋 수준
트랜잭션이 온체인에 포함되었다고 확신할 수 있는 정도입니다.processed— 현재 리더가 확인했지만 아직 투표되지 않음. 블록이 합의를 잃으면 여전히 삭제될 수 있음(~0.4초)confirmed— 블록에 스테이크 가중치 기준 검증자 투표가 66% 이상 모임. 지금까지 확인된 블록이 되돌려진 사례는 없음(~0.6초)finalized— 블록이 66% 이상의 투표를 얻고 그 위에 후속 블록 31개가 구축됨(즉, Tower BFT 최대 잠금). 사실상 되돌릴 수 없음(~13초)
confirmed을 기본값으로 사용하는 것이 좋습니다. UI 피드백에는 processed을 사용하고, 거래소 입금이나 크로스체인 브리지 같은 고가치 작업에는 finalized을 사용하세요. finalized에서 가져온 블록 해시는 confirmed에서 가져온 것보다 빨리 만료되므로 트랜잭션 만료 전까지의 시간이 짧아집니다.
자세한 내용은 블로그 게시물 Solana 커밋 수준이란?을 참조하세요.
컴퓨트 유닛(CU)
Ethereum의 가스와 유사하게 Solana 트랜잭션이 수행하는 계산 작업을 측정하는 단위입니다. 각 트랜잭션은 컴퓨트 유닛 한도와 컴퓨트 유닛 가격(CU당 마이크로램포트로 표시되는 우선순위 수수료)을 지정하며, 두 값을 곱하여 총 우선순위 수수료 비용을 결정합니다. 한도를 초과하면 트랜잭션이 실패합니다.CPI(프로그램 간 호출)
하나의 온체인 프로그램이 계정 및 명령 데이터를 전달하여 다른 프로그램을 호출할 수 있게 하는 Solana 메커니즘으로, Solana의 조합 가능성을 구현하는 기본 요소입니다. CPI는sol_invoke_signed 시스템 호출을 통해 제공되며, 이 호출은 호출자에게 전달되는 계정에 대한 적절한 권한이 있는지 확인합니다. PDA를 사용하면 프로그램이 소유 계정을 대신하여 서명할 수 있습니다.
호출된 프로그램은 호출 프로그램에 남은 컴퓨트 예산 내에서 작동합니다. 예산을 소진하거나 설정된 한도를 초과하면 원래 트랜잭션을 포함하여 전체 호출 체인이 실패합니다.
자세한 내용은 블로그 게시물 Solana 가상 머신을 참조하세요.
에포크
약 432,000개의 Solana 슬롯으로 구성된 집합으로, Solana가 검증자 집합, 리더 일정, 스테이크 위임, 보상 분배를 업데이트하는 상위 수준의 구성 간격입니다. 현재 슬롯 목표를 기준으로 각 에포크는 약 2일이 걸립니다. 자세한 내용은 블로그 게시물 Solana의 슬롯, 블록, 에포크 이해하기를 참조하세요.Firedancer
Jump Crypto가 C로 처음부터 작성한 두 번째 독립 Solana 검증자 클라이언트입니다. Firedancer의 목표는 (1) 독립적인 구현을 통해 Solana 프로토콜을 문서화하고 표준화하고, (2) 클라이언트 다양성을 개선하며(단일 클라이언트가 스테이크의 33% 초과를 제어하지 않도록 함), (3) 생태계 성능을 향상하는 것입니다. 아키텍처는 모듈식입니다. “타일”(QUIC 타일, 검증 타일 등)이라고 하는 여러 단일 목적 Linux 프로세스가 공유 메모리를 통해 통신하며, 이는 Agave의 단일 프로세스 설계와 대조적입니다. Frankendancer는 Firedancer의 고성능 C 네트워킹 코드와 Agave의 Rust 런타임 및 합의 코드를 결합한 하이브리드 중간 단계입니다. 자세한 내용은 블로그 게시물 Firedancer란?를 참조하세요.명령
Solana 트랜잭션 내부의 최소 작업 단위로, 관련 계정 및 데이터가 포함된 단일 프로그램 호출입니다. 하나의 트랜잭션은 하나 이상의 명령을 묶으며 원자적으로 실행됩니다. 즉, 모두 성공하거나 모두 함께 되돌려집니다. 자세한 내용은 블로그 게시물 Solana 프로그래밍 모델: Solana 개발 입문을 참조하세요.램포트
SOL의 최소 단위입니다. 1 SOL = 1,000,000,000램포트(10⁻⁹ SOL)이며, 분산 시스템의 기초 연구로 튜링상을 받은 Leslie Lamport의 이름에서 유래했습니다. 원시 Solana RPC 메서드는 잔액과 수수료를 램포트로 반환하며, Helius의 지갑 API는 변환을 자동으로 처리합니다. 우선순위 수수료는 마이크로램포트, 즉 램포트의 100만분의 1(10⁻¹⁵ SOL) 단위로 표시됩니다.리더/리더 일정
리더는 특정 슬롯 동안 새 블록을 제안하도록 배정된 검증자입니다. 리더는 각 에포크가 시작될 때 계산되는 스테이크 가중치 기반 무작위 일정에 따라 선정되므로 모든 검증자는 앞으로 약 2~3일 동안 각 슬롯을 누가 이끌지 독립적으로 계산할 수 있습니다. 각 리더에게는 연속된 슬롯 4개(슬롯당 약 400ms일 때 약 1.6초)가 배정되어 연속으로 블록을 생성할 수 있는 짧은 시간이 주어집니다. 리더가 자신의 슬롯에서 블록을 생성하지 못하면 해당 슬롯을 건너뜁니다. 네트워크는 누락된 블록을 기다리지 않고 계속 진행합니다. Sender 같은 트랜잭션 전송 서비스는 랜딩 확률을 극대화하기 위해 서명된 트랜잭션을 현재 리더와 다음 두 리더에게 라우팅합니다. 자세한 내용은 블로그 게시물 Solana 합의: Tower BFT와 Proof of History를 참조하세요.머클 트리
리프가 아닌 각 노드가 자식 노드의 해시인 암호학적 트리 구조로, 하나의 루트 해시가 전체 데이터 세트를 확약합니다. 데이터가 트리에 속하는지 확인할 때는 리프에서 루트까지 경로에 있는 형제 해시, 즉 머클 증명만 필요합니다. 이는 트리 크기에 관계없이 O(log n)의 데이터입니다. 깊이 26인 트리에서 이 증명은 형제 해시 26개(약 832바이트)이며 작지만 여전히 리프마다 필요합니다. 압축 NFT가 이 증명 형식을 사용합니다. ZK Compression은 이를 데이터 세트가 커져도 크기가 증가하지 않는 하나의 고정 크기 유효성 증명으로 대체합니다. 블로그 게시물 암호학 도구 입문: 해시 함수와 머클 트리 설명을 참조하세요.프로그램
컴파일된 sBPF 바이트코드를 포함하는 실행 가능 계정, 즉 Solana의 스마트 계약입니다. 프로그램은 상태 비저장 방식으로 작동합니다. 프로그램이 소유한 데이터 계정을 읽고 쓰며 프로그램 ID(32바이트 주소)로 식별됩니다. Solana에는 런타임에 내장된 기본 프로그램(System, Stake, Vote 등)이 있으며, 그 외에는 모두 사용자가 배포한 프로그램입니다. 자세한 내용은 블로그 게시물 Solana 프로그래밍 모델: Solana 개발 입문을 참조하세요.프로그램 파생 주소(PDA)
프로그램 ID와 시드 집합으로부터 파생되는 결정론적 주소입니다. PDA를 사용하면 프로그램이 제어하는 계정을 대신해 서명할 수 있으므로 상태 저장 프로그램 설계에 필수적입니다. PDA는 의도적으로 곡선 밖에 있으므로 해당하는 비공개 키가 없습니다.Proof of History(PoH)
Solana의 동기화 기본 요소이며 합의 알고리즘은 아닙니다. PoH는 검증자가 서로 통신하지 않고도 이벤트 순서에 합의할 수 있는 암호학적 타임스탬프 기능을 제공합니다. 구현 방식은 검증자당 하나의 CPU 코어에서 계속 실행되는 순차적 SHA-256 해시 체인으로, 각 반복의 출력을 다음 반복의 입력으로 사용합니다. 생성은 순차적이고 단일 스레드에서 이루어지지만 검증은 병렬화할 수 있습니다. PoH는 블록의 유효 시점을 정의하는 “틱”을 제공합니다. 리더는 지정된 PoH 틱 범위 내에서 블록을 게시해야 하며, 범위 밖의 블록은 건너뛴 것으로 간주합니다. PoH는 실제 합의 메커니즘인 Tower BFT와 함께 실행됩니다. 자세한 내용은 블로그 게시물 Proof of History, Proof of Stake, Proof of Work 설명을 참조하세요.임대료/임대료 면제
모든 Solana 계정이 온체인에 유지되기 위해 보유해야 하는 SOL 잔액으로, 계정의 저장소 크기에 따라 달라집니다. 계정은 임대료 면제 상태로 생성해야 합니다. 계정 잔액을 최솟값보다 낮게 만드는 트랜잭션은 실패합니다. 임대료가 면제되면 추가 결제 없이 계정이 무기한 유지됩니다.Sealevel
Solana의 병렬 트랜잭션 실행 엔진입니다. EVM 같은 순차적 VM과 달리 Sealevel은 여러 CPU 코어에서 여러 트랜잭션을 동시에 실행합니다. 모든 Solana 트랜잭션은 실행을 시작하기 전에 읽고 쓸 계정을 명시적으로 선언하므로, 스케줄러가 런타임 분석 없이 충돌하지 않는 배치를 식별할 수 있습니다. 스케줄링 규칙은 간단합니다. 서로 다른 계정에 접근하는 트랜잭션은 병렬로 실행됩니다. 같은 계정을 읽기만 하는 트랜잭션도 읽기는 충돌하지 않으므로 병렬로 실행됩니다. 같은 계정에 쓰는 트랜잭션은 경합 상태를 방지하기 위해 순차적으로 실행됩니다. 자세한 내용은 블로그 게시물 Solana 가상 머신을 참조하세요.슬롯
지정된 리더 검증자가 블록을 생성할 기회를 얻는 Solana의 기본 시간 단위입니다. 현재 슬롯의 목표 시간은 400ms이지만 실제 지속 시간은 네트워크 상태에 따라 달라질 수 있습니다. 리더가 슬롯 중 블록을 생성하지 못하면 해당 슬롯을 건너뜁니다. 네트워크는 기다리지 않고 다음 슬롯으로 진행하므로 모든 슬롯에서 블록이 생성되는 것은 아닙니다. 자세한 내용은 블로그 게시물 Solana의 슬롯, 블록, 에포크 이해하기를 참조하세요.SVM(Solana 가상 머신)
단순한 바이트코드 인터프리터가 아니라 Solana의 전체 트랜잭션 실행 스택입니다. SVM에는 실행을 조정하는 Bank 구성 요소, Banking Stage 스케줄러, BPF 로더 및 sBPF 가상 머신 자체(범용 레지스터 11개와 약 100개의 연산 코드를 갖추고 성능을 위해 JIT 컴파일되는 레지스터 기반 VM)가 포함됩니다. 이는 하나의 바이트코드 실행기를 명확히 지칭하는 EVM과 다릅니다. Solana 프로그램은 Linux eBPF의 Solana 포크인 sBPF로 컴파일됩니다. LLVM 프런트엔드가 있는 모든 언어(C, C++, Rust, Zig)는 sBPF를 대상으로 할 수 있습니다. 트랜잭션이 계정 액세스를 미리 선언하도록 요구하기 때문에 Sealevel의 병렬 실행과 Solana의 지역화된 수수료 시장이 가능해집니다. 자세한 내용은 블로그 게시물 Solana 가상 머신을 참조하세요.Tower BFT
Solana의 합의 메커니즘입니다. Tower BFT는 Proof of History의 동기화된 시계를 활용하여 모든 슬롯에서 동기식 합의 라운드를 수행할 필요가 없도록 하는 pBFT 계열 알고리즘입니다. 검증자는 “투표 타워”를 구축합니다. 이는 새 투표가 추가될 때마다 이전 모든 투표의 잠금 기간이 두 배로 늘어나 포크를 전환할 때 발생하는 스테이크 손실 비용이 기하급수적으로 증가하는 순차적 투표 스택입니다. 확인 임계값: 스테이크 가중치 기준 투표의 2/3 이상이 블록에 도달하면 확인됨 상태가 됩니다(최종성을 위반하려면 총 스테이크의 4.6% 이상을 삭감해야 함). 투표를 얻고 그 위에 후속 블록 31개가 구축되어 Tower BFT 최대 잠금에 도달하면 최종 확정됨 상태가 됩니다. 사용 지침은 커밋 수준을 참조하세요. 자세한 내용은 블로그 게시물 Solana 합의: Tower BFT와 Proof of History를 참조하세요.Turbine
Solana의 블록 전파 프로토콜입니다. 리더는 각 블록을 MTU 크기의 슈레드와 Reed-Solomon 삭제 코딩된 복구 슈레드로 분할합니다. FEC 비율(일반적으로 32:32)을 통해 약 33%의 패킷 손실이 발생해도 네트워크가 블록을 재구성할 수 있습니다. 그런 다음 리더는 전체 블록을 모든 검증자에게 직접 브로드캐스트하는 대신,(leader id, slot, shred index, shred type)에 따라 슈레드 그룹별로 시드가 지정된 결정론적 스테이크 가중치 기반 피어 검증자 트리를 통해 슈레드를 전달합니다. 이 트리(DATA_PLANE_FANOUT = 200)는 검증자 수와 관계없이 리더의 발신 대역폭을 대략 일정하게 유지하고 블록이 O(n) 대신 2~3홉 만에 네트워크에 도달하도록 합니다.
블로그 게시물 Turbine: Solana의 블록 전파를 참조하세요.
검증자
배정된 리더 슬롯 동안 블록을 생성하고 다른 검증자의 블록에 투표하여 합의에 참여하는 Solana 네트워크의 노드입니다. 검증자는 활성 스테이크에 비례하여 리더 슬롯에 선정됩니다.트랜잭션 메커니즘
주소 조회 테이블(ALT)
버전이 지정된 트랜잭션에서 전체 32바이트 공개 키 대신 1바이트 인덱스로 참조할 수 있는 Solana 주소의 온체인 테이블입니다. 단일 트랜잭션이 최대 256개 계정을 참조할 수 있게 합니다. ALT는 그렇지 않으면 트랜잭션 크기 제한을 초과할 수 있는 복잡한 DeFi 작업에 필수적입니다.블록 해시
최근 블록을 식별하는 32바이트 해시로, 최신 상태임을 증명하기 위해 모든 Solana 트랜잭션에 포함됩니다. 블록 해시는 약 150개 슬롯(약 1분) 후 만료됩니다. 만료된 블록 해시가 있는 트랜잭션은 거부됩니다. 클라이언트는 서명 직전에getLatestBlockhash를 통해 최근 블록 해시를 가져옵니다.
우선순위 수수료
트랜잭션이 다른 트랜잭션보다 우선 처리되도록 검증자에게 지급하는 컴퓨트 유닛당 팁으로, 포함까지 걸리는 시간을 단축합니다. 우선순위 수수료는 컴퓨트 유닛당 마이크로램포트(µLamports/CU)로 설정합니다. Helius의 우선순위 수수료 API는 최근 온체인 수수료 시장을 기반으로 실시간 추정값을 반환합니다.슈레드
Solana 블록의 최소 단위입니다. 블록은 Turbine을 통해 검증자 네트워크에 병렬로 전파되도록 슈레드로 분할됩니다. 슈레드 수준 액세스는 블록 조립 전에 트레이더에게 지연 시간이 매우 짧은 온체인 신호를 제공합니다. 단, Preconfirmations는 엔트리가 슈레드로 분할되기 전이므로 이보다 더 일찍 도착합니다. 원시 슈레드(UDP)와 Shred Delivery 개요를 참조하세요.Stake-Weighted Quality of Service(SWQoS)
송신자의 스테이크에 따라 현재 및 예정된 리더에게 들어오는 트랜잭션의 우선순위를 지정하는 Solana 프로토콜 수준 메커니즘입니다. Solana에서 2022년 4월 30일에 발생한 장애 이후 시빌 공격 방지 수단으로 도입된 SWQoS는 스테이크가 적거나 없는 피어가 혼잡 시 리더 대역폭을 독점하지 못하게 합니다. 리더는 두 개의 수신 연결 풀을 제공합니다. 스테이크가 없는 모든 피어가 공유하는 약 500개의 개방형 연결과 스테이크 보유 검증자에게 스테이크 비율에 따라 분배되는 약 2,000개의 스테이크 가중치 기반 연결입니다. 전체 활성 스테이크의 X%를 보유한 검증자는 리더에게 패킷의 최대 X%를 보낼 수 있습니다. 활성 스테이크가 약 15,000 SOL(전체 네트워크 스테이크의 약 1/25,000) 미만인 검증자는 스테이크가 없는 것으로 취급됩니다. 최소 스테이크 임계값은 Agave v1.17.31에 도입되었습니다. Helius의 스테이크 연결은 Solana 최대 검증자를 통해 고객 트랜잭션을 라우팅하여 이러한 랜딩 성공률 이점을 상속합니다. 따라서 호출자는 대규모 스테이크를 보유한 검증자를 직접 운영하지 않아도 SWQoS의 이점을 얻을 수 있습니다. 블로그 게시물 Stake-Weighted Quality of Service: 알아야 할 모든 것을 참조하세요.버전 지정 트랜잭션
직렬화된 트랜잭션 시작 부분의 버전 바이트로 식별되는 Solana 트랜잭션 형식입니다. 버전 0(v0)에는 주소 조회 테이블이 추가되어 하나의 트랜잭션이 최대 256개 계정을 참조할 수 있습니다(레거시 트랜잭션은 약 35개). 버전 1(v1, SIMD-0385, Agave 4.2)은 서명을 트랜잭션 끝으로 이동하고 ComputeBudget 명령 대신transactionConfig 헤더 필드에 컴퓨트 예산을 포함합니다. 모든 버전을 수신하려면 RPC 요청에 maxSupportedTransactionVersion: 1을 설정하세요. 트랜잭션 v1 지원을 참조하세요.
토큰 및 자산
압축 계정
압축 계정은 전체 데이터가 검증자 디스크의 기존 계정 슬롯을 차지하는 대신, 데이터가 트랜잭션 로그를 통해 원장에 확약되고 검증자 상태에는 해시 지문만 저장되는 Solana 계정입니다. 개발자는 압축 계정을 일반 계정처럼 처리할 수 있습니다. 인덱서(예: Photon)는 트랜잭션 로그를 파싱하여 현재 상태를 재구성하고, ZK Compression을 통해 계정을 읽거나 수정할 때 고정 크기 Groth16 영지식 증명으로 무결성을 검증합니다. 이 모델은 데이터가 작은 계정에 가장 적합합니다. 데이터가 약 100바이트보다 크면 압축이 비현실적입니다.압축 NFT(cNFT)
자체 계정 대신 온체인 동시성 머클 트리의 리프로 표현되는 Solana NFT입니다. 트리는 Solana 계정에 존재하고 상태 전환은 원장으로 보호됩니다. NFT의 현재 상태는 인덱서가 트랜잭션 기록에서 파생하며, 인덱서는 트리의 온체인 루트에 대해 검증할 수 있는 머클 증명을 생성합니다. 따라서 cNFT를 읽으려면 DAS API 같은 인덱서가 필요합니다. 표준 Solana RPC는 cNFT 데이터를 직접 반환할 수 없습니다. 이 모델은 표준 NFT보다 민팅 비용을 최대 99% 줄입니다.동시성 머클 트리
여러 작성자가 같은 슬롯에서 서로의 증명을 무효화하지 않고 트리를 업데이트할 수 있도록 설계된 Solana 전용 머클 트리 변형입니다. 온체인 계정은 현재 루트뿐 아니라 최근 유효한 루트의 변경 로그 버퍼와 캐노피(상위 트리 노드 중 캐시된 일부)를 저장합니다. 이를 통해 검증자는 버퍼 기간 내에 남아 있는 모든 루트를 기준으로 생성된 증명을 검증할 수 있습니다. 트리는 세 가지 매개변수로 정의됩니다. 최대 깊이(리프 수를 2^depth로 제한), 버퍼 크기(변경 로그 깊이, 즉 진행 중인 이전 증명이 무효화되기 전에 가능한 쓰기 횟수), 캐노피 깊이(온체인 임대료를 늘리는 대신 트랜잭션 내 증명을 줄임)입니다. 유효한 (깊이, 버퍼) 쌍은 (3, 8)부터 (30, 2048)까지입니다. 실용적인 조합 가능성을 유지하려면maxDepth − canopyDepth ≤ 10을 유지하세요.
동시성 머클 트리는 SPL Account Compression 프로그램으로 구현되며, Metaplex Bubblegum을 통해 리프로 민팅되는 압축 NFT의 기반입니다.
블로그 게시물 Solana 압축에 대해 알아야 할 모든 것을 참조하세요.
Groth16
명제의 복잡성과 관계없이 고정 크기 영지식 증명(BN254 곡선에서 점 압축을 사용할 때 128바이트)을 생성하고 O(1) 검증을 제공하는 zk-SNARK 증명 시스템입니다. ZK Compression은 Groth16을 사용하여 압축 계정이 알려진 루트의 알려진 상태에 속했음을 나타내는 유효성 증명을 생성합니다. 작은 증명 크기 덕분에 압축 계정 트랜잭션 비용이 낮게 유지됩니다. 블로그 게시물 Solana 빌더: ZK Compression을 참조하세요.민트 계정
공급량, 소수 자릿수, 민팅 및 동결 권한 등 SPL 토큰의 속성을 정의하는 온체인 계정입니다. 민트 계정 주소는 토큰의 표준 식별자(Ethereum에서의 “계약 주소”)입니다.SPL 토큰
Solana Program Library(SPL)의 Token Program을 통해 발행되는 Solana 토큰입니다. 대체 가능 토큰(USDC, BONK, JUP 등)은 SPL 토큰입니다. 표준(비압축) NFT도 공급량 1, 소수 자릿수 0으로 민팅된 SPL 토큰입니다. SPL 토큰은 대체로 Ethereum의 ERC-20 및 ERC-721에 해당합니다. Token-2022는 전송 수수료와 기밀 전송 같은 선택적 기능으로 이 인터페이스를 확장한 최신 프로그램입니다.상태 트리
ZK Compression이 압축 계정의 해시를 저장하는 데 사용하는 머클 트리입니다. 온체인 계정에는 현재 루트와 최소한의 메타데이터만 저장됩니다. 실제 압축 데이터는 트랜잭션 로그에 있으며 Photon 같은 인덱서가 재구성합니다. 프로그램은 계정의 선언된 콘텐츠가 현재 루트 아래의 리프로 해시된다는 유효성 증명을 전달하여 압축 상태를 읽거나 수정합니다. ZK Compression을 참조하세요.토큰 계정
특정 소유자의 특정 SPL 토큰 잔액을 보유하는 온체인 계정입니다. 지갑은 임의의 토큰 계정을 소유할 수 있지만, 일반적으로 Associated Token Account Program이 (지갑, 민트) 쌍마다 결정론적으로 파생하여 생성하는 토큰 계정인 연결 토큰 계정(ATA)을 사용합니다.Token-2022(토큰 확장)
전송 수수료, 기밀 전송, 이자 발생 토큰, 양도 불가 토큰 등의 선택적 확장을 지원하는 SPL Token Program의 변형입니다. Token-2022는 자체 프로그램 ID를 가진 별도의 온체인 프로그램으로 실행되지만 기존 Token Program과 호환되는 후속 프로그램으로 설계되었으므로 SDK는 일반적으로 둘 다 처리할 수 있습니다. 확장 기능을 사용하려면 Token-2022 프로그램에서 민트를 생성해야 합니다. 블로그 게시물 토큰 확장이란?을 참조하세요.유효성 증명
압축 계정에서 선언한 콘텐츠가 특정 루트의 상태 트리에 존재했음을 나타내는 고정 크기 Groth16 영지식 증명입니다. ZK Compression 프로그램은 압축 계정을 읽거나 수정할 때마다 유효성 증명을 요구합니다. 이 증명을 사용하면 검증자가 데이터를 온체인에 저장하지 않아도 프로그램이 오프체인 상태를 검증할 수 있습니다. Photon은getValidityProof RPC 메서드를 통해 호출자에게 유효성 증명을 제공합니다.
유효성 증명은 ZK Compression과 압축 NFT를 구분하는 요소입니다. cNFT는 트리 깊이에 따라 커지는 일반 머클 증명(리프에서 루트까지의 형제 해시 목록)을 사용하는 반면, ZK Compression의 고정 크기 ZK 증명은 경로나 주변 트리 상태를 공개하지 않습니다.
블로그 게시물 Solana 빌더: ZK Compression을 참조하세요.
ZK Compression
ZK Compression은 Helius와 Light Protocol이 개발한 Solana 기본 요소입니다. 계정 데이터를 원장의 트랜잭션 로그에 확약하고 검증자 상태에는 해시 지문만 저장하여 온체인 저장 비용을 크게 줄입니다. 인덱싱된 트랜잭션 데이터에서 생성되는 고정 크기 Groth16 영지식 증명으로 암호학적 무결성을 유지합니다. 이 기본 요소는 영지식 증명 없이 동시성 머클 트리를 사용하는 압축 NFT와 다릅니다. 자세한 내용은 ZK Compression과 블로그 게시물 Solana 빌더: ZK Compression을 참조하세요.연결 및 스트리밍
Geyser
계정, 트랜잭션, 슬롯, 블록 등 검증자 상태 변경을 외부 소비자에게 실시간으로 스트리밍하는 Solana 플러그인 시스템입니다. 검증자는 Geyser 플러그인을 동적 라이브러리로 로드합니다. 검증자가 상태를 처리할 때 플러그인이 상태 업데이트를 수신하므로 변경 사항을 확인하기 위해 RPC를 폴링할 필요가 없습니다. 가장 널리 사용되는 Geyser 플러그인인 Yellowstone gRPC는 이러한 업데이트를 gRPC로 제공합니다. Helius의 LaserStream은 Yellowstone gRPC 인터페이스를 구현하면서 과거 데이터 재생(현재 네트워크 속도에서 최대 약 48시간, 약 691,200개 슬롯)과 다중 리전 장애 조치 같은 기능을 추가합니다.gRPC
gRPC는 범용 고성능 바이너리 RPC 프로토콜이며, “gRPC Remote Procedure Call”의 재귀 약어입니다. Solana 맥락에서 “gRPC”는 일반적으로 Solana의 Geyser 플러그인 시스템을 기반으로 구축되어 계정 및 트랜잭션 업데이트를 gRPC로 제공하는 스트리밍 인터페이스인 Yellowstone gRPC를 의미합니다. Helius의 LaserStream 서비스는 Yellowstone 기반 인터페이스 위에 구축되었으며 과거 데이터 재생, 다중 리전 장애 조치, 관리형 인프라 같은 기능을 추가로 제공합니다.RPC
RPC는 Remote Procedure Call의 약자로, 서버 메서드를 로컬 함수처럼 호출하는 일반적인 패턴입니다. Solana에서 “RPC”는 주로 RPC 노드를 의미합니다. 이 노드는 Solana의 상태를 추적하지만 합의에는 참여하지 않으며 JSON-RPC 인터페이스를 통해 데이터 요청(예: 계정 상태, 트랜잭션 기록, 트랜잭션 제출)을 처리하는 데 특화되어 있습니다. 반면 검증자는 블록을 생성하고 투표합니다. Helius의 RPC 서비스는 프로덕션 워크로드에 최적화되어 전 세계에 분산된 RPC 노드 집합입니다. 자세한 내용은 블로그 게시물 Solana 노드 — Solana RPC, 검증자 및 RPC 제공업체 입문을 참조하세요.웹훅
웹훅은 구독한 이벤트가 발생할 때 서버가 수신자 URL로 보내는 HTTP POST 요청입니다. 서버가 호출을 시작하는 “역방향” HTTP입니다. Helius 웹훅은 Solana 온체인 이벤트(전송, NFT 판매, 커스텀 프로그램 활동)를 등록된 엔드포인트로 푸시하므로 폴링할 필요가 없습니다.WebSocket(WSS)
WebSocket은 HTTP에서 업그레이드된 지속형 양방향 TCP 연결로, HTTP 요청을 반복하지 않고 푸시 방식으로 Solana 데이터를 스트리밍하는 데 사용됩니다. WSS(WebSocket Secure)는 TLS에서 실행되는 동일한 프로토콜이며 프로덕션 Solana 연결에 사용하는 방식입니다. 표준 Solana 메서드와transactionSubscribe 같은 Helius 확장 기능을 포함하는 Helius의 WebSocket 스트리밍 제품인 LaserStream WebSocket은 WSS를 사용합니다.
생태계
Anchor
Anchor는 Solana 프로그램을 빠르고 안전하게 구축하기 위한 Rust 프레임워크입니다. 절차적 매크로를 통해 계정 직렬화, 검증, 명령 디스패치 같은 상용구 코드를 처리하므로 개발자는 저수준 세부 사항 대신 프로그램 로직에 집중할 수 있습니다. 대부분의 Solana 개발자는 네이티브 Rust로 프로그램을 작성하는 대신 Anchor를 사용합니다. 자세한 내용은 블로그 게시물 Anchor 입문: Solana 프로그램 구축을 위한 초보자 가이드를 참조하세요.IDL
IDL은 Interface Definition Language의 약자입니다. IDL은 Solana 프로그램의 명령, 계정, 데이터 유형을 설명하는 JSON 스키마입니다. 클라이언트는 이를 사용하여 명령 레이아웃을 직접 작성하지 않고 트랜잭션을 구성하고 프로그램 데이터를 디코딩합니다. Anchor는 IDL을 자동으로 생성하며 기본적으로 공개 검색을 위한 전용 계정에 온체인으로 게시합니다.Jito
네트워크에서 가장 널리 사용되는 블록 엔진을 운영하는 Solana 생태계 기업입니다. 이 블록 엔진은 트랜잭션 번들(모두 함께 실행되거나 전혀 실행되지 않는 원자적 트랜잭션 그룹)을 받고, 검색자가 검증자에게 팁을 지급하여 해당 번들의 랜딩 우선순위를 높일 수 있게 하는 MEV(최대 추출 가능 가치) 인프라 계층입니다. Jito-Solana 검증자 클라이언트는 블록 엔진이 통합된 Agave 포크입니다. 번들에 포함되려면 최소 10,000램포트의 팁이 필요하며, Jito-Relayer는 오프체인 번들 경매를 지원하기 위해 수신 트래픽을 약 200ms 동안 보류합니다. Helius의 Sender는 스테이크 연결과 Jito 블록 엔진을 통해 트랜잭션을 동시에 제출하고 먼저 랜딩되는 경로를 사용합니다. 블로그 게시물 Solana MEV 입문을 참조하세요.Light Protocol
Helius와 함께 ZK Compression을 공동 개발한 Solana 프로토콜 팀입니다. Helius는 표준 인덱서(Photon)를 구축하고 공개 RPC를 운영합니다. Light Protocol은 인덱서가 사용하는 온체인 프로그램과 증명 스택을 구축합니다. github.com/Lightprotocol/light-protocol을 참조하세요.Photon
Helius가 구축한 오픈 소스 ZK Compression 인덱서입니다. 압축 계정 데이터는 계정 상태가 아니라 Solana 트랜잭션 로그에 있으므로 검증자는 표준 RPC를 통해 이를 제공하지 않습니다. Photon은 Solana 트랜잭션을 파싱하고 압축 계정 상태를 재구성한 후, Solana의 네이티브 RPC와getCompressedAccount 및 getValidityProof 같은 ZK Compression 전용 메서드를 반영하는 JSON-RPC 인터페이스를 통해 제공합니다. 개발자는 github.com/helius-labs/photon에서 직접 호스팅하거나 Helius 호스팅 엔드포인트를 사용할 수 있습니다.
ZK Compression을 참조하세요.