> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Helius 용어집: Solana 및 Helius 용어 정의 > Helius 문서 및 Solana 생태계 전반에서 사용되는 용어에 대한 개발자 중심 정의 — DAS, LaserStream, Preconfirmations, 우선순위 수수료, 압축 NFT, PDA, 연산 단위 등. Helius 문서 전반과 Solana에서 사용되는 용어에 대한 빠른 참조 정의입니다. 각 항목은 관련 제품 페이지 또는 가이드에 연결됩니다 (적용 가능한 경우). 이동하기: * [Helius 제품 및 플랫폼](#helius-제품-및-플랫폼) * [Solana 기초](#solana-기초) * [거래 메커니즘](#거래-메커니즘) * [토큰 및 자산](#토큰-및-자산) * [연결 및 스트리밍](#연결-및-스트리밍) * [생태계](#생태계) *** ## Helius 제품 및 플랫폼 ### Autoscaling Helius의 자동 크레딧 충전 메커니즘으로, 월별 크레딧 할당이 소진되면 사용자가 설정한 한도 내에서 추가 크레딧을 구입하여 `429` 오류가 생산 트래픽을 방해하지 않도록 합니다. 암호화 계획은 자동 확장이 없으며, 대신 [선불 크레딧](/docs/ko/billing/additional-credits#선불-크레딧-암호화-플랜)을 수동으로 구입합니다. [Autoscaling](/docs/ko/billing/additional-credits) 참조. ### Credit Helius가 API 및 스트리밍 사용량을 청구하는 단위입니다. RPC 메서드, DAS 호출, 스트리밍 처리량마다 특정한 크레딧 비용이 있습니다. 모든 계획에는 매월 청구 주기에 다시 설정되는 월간 크레딧 할당이 포함되어 있습니다 (사용되지 않은 크레딧은 이월되지 않습니다). 전체 비용 표에 대해서는 [Credits](/docs/ko/billing/credits)를 참조하세요. ### DAS API 디지털 자산 표준 — Solana 디지털 자산(NFT, 압축 NFT, 대체 가능 토큰)을 위한 통합 인터페이스에 대한 개방형 사양입니다. Helius의 DAS API 구현은 풍부한 메타데이터, 소유권 및 가격을 단일 구조화된 응답으로 반환하여 온체인 자산 데이터에 대한 사용자 정의 파서가 필요하지 않습니다. [DAS API](/docs/ko/das-api) 참조. ### Dedicated Nodes 속도 제한이나 크레딧 측정 없이 월 정액으로 청구되는 개인 Helius RPC 노드입니다. 무제한 처리량이 필요한 좁은 사용 사례에 적합하나 대부분의 응용 프로그램은 성능, 장애 조치 및 기능 범위로 인해 일반 Helius RPC가 더 적합합니다. [Dedicated Nodes](/docs/ko/dedicated-nodes) 참조. ### Enhanced Transactions Helius의 해석된 거래 API로, 프로그램별 지시어 파서가 필요하지 않은 인간 판독 가능한 이벤트 — 토큰 전송, NFT 판매, 스왑, 스테이킹 작업 등을 Solana의 원시 거래로부터 디코딩합니다. [Enhanced Transactions](/docs/ko/enhanced-transactions) 참조. ### Error Codes 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 측 문제; 지수 백오프와 함께 재시도 자세한 내용과 문제 해결 단계는 [Error Codes](/docs/ko/faqs/error-codes)를 참조하세요. ### Gatekeeper 글로벌로 분산된 프록시 플릿을 통해 요청을 라우팅하여 표준 RPC 호출보다 현저히 낮은 대기 시간을 제공하는 Helius의 엣지 게이트웨이입니다. RPC URL에서 `mainnet.helius-rpc.com`를 `beta.helius-rpc.com`로 교체하여 액세스합니다. 아키텍처 배경은 [Gatekeeper](/docs/ko/gatekeeper/overview) 및 [Introducing Gatekeeper 블로그 게시물](https://www.helius.dev/blog/introducing-gatekeeper)을 참조하세요. ### LaserStream Helius의 고성능 Solana 온체인 데이터 gRPC 스트리밍 서비스로, 역사적 재생, 다중 지역 장애 조치 및 Helius 스트리밍 제품 중 가장 풍부한 기능 세트를 제공합니다. 공식 SDK는 JavaScript/TypeScript, Rust 및 Go용으로 제공됩니다. [LaserStream WebSocket](#laserstream-websocket)은 동일한 인프라에서 실행됩니다. SDK 벤치마크에 대한 깊이 있는 분석은 [LaserStream](/docs/ko/laserstream)과 [LaserStream SDK 성능 블로그 게시물](https://www.helius.dev/blog/laserstream-sdks)을 참조하세요. ### LaserStream WebSocket Helius의 지속 가능한 WebSocket 스트리밍 서비스입니다. 이는 표준 Solana WebSocket 메서드와 Helius 고유 확장(`transactionSubscribe` 및 풍부한 필터링 기능을 갖춘 향상된 `accountSubscribe`)을 단일 통합 엔드포인트에서 제공합니다. LaserStream WebSocket은 [LaserStream](#laserstream) gRPC와 백엔드를 공유합니다. [LaserStream WebSocket](/docs/ko/rpc/websocket) 참조. ### Preconfirmations Helius의 최저 대기 시간 거래 신호입니다. 스케줄러가 실행을 커밋하는 즉시 예약된 거래를 스트리밍합니다 — 항목으로 수집되고 분쇄되기 전입니다. [Shred Delivery](#shred-delivery)보다 빠르고 처리된 약속 스트림보다 빠릅니다. `preconfSubscribe` WebSocket 구독을 통해 배송됩니다. 전문 계획 이상에서 필요하며, 메시지당 10 크레딧으로 측정됩니다. 피드를 Helius에 전달하는 검증자에 따라 적용 범위가 다르므로 전송이 연속적이지 않습니다. [Preconfirmations](/docs/ko/pre-confirmations/overview) 및 [`preconfSubscribe`](/docs/ko/pre-confirmations/preconf-subscribe)를 참조하세요. ### Priority Fee API Helius의 수수료 추정 엔드포인트입니다. 실시간 온체인 수수료 시장에 기반한 추천 우선 수수료 값을 반환하여, 추측이나 혼잡 시에 과도한 지불 없이 경쟁적인 수수료 책정을 가능케 합니다. [Priority Fee API](/docs/ko/priority-fee-api) 참조. ### Rate Limit 주어진 Helius 계획에서 허용되는 최대 초당 요청 수입니다. 속도 제한은 계획 계층과 API 계열(표준 RPC, 향상된 API, 스트리밍)에 따라 다릅니다. 초과 시 `429 Too Many Requests`가 반환됩니다. [Rate Limits](/docs/ko/billing/rate-limits) 참조. ### Sender 우선 수수료, Jito 팁 및 스테이킹 된 연결 경로를 결합하여 착륙 비율을 최대로 하는 저지연 트레이더를 위해 구축된 Helius의 특수 트랜잭션 착륙 서비스입니다. `https://sender.helius-rpc.com/fast`에서 사용할 수 있습니다. [Sender](/docs/ko/sending-transactions/sender) 참조. ### Shred Delivery Helius의 UDP를 통해 원시 Solana 조각을 스트리밍하는 서비스로, 최종 블록 조립 전에 전달됩니다. Helius는 여러 지역의 분산된 검증자 네트워크에서 조각을 집계하여 개별 검증자의 지리적 대기 시간 변동성을 최소화합니다. 고빈도 거래, 차익 거래 및 기타 저지연 응용 프로그램에 유용합니다. 원시 조각은 [Helius 대시보드](https://dashboard.helius.dev/shred-delivery-seats)에서 자가 제공되며, IP당 1,000달러/월 (프로 계획은 IP당 800달러/월)입니다. 조각 작동 방식에 대한 심층 분석은 [Shred Delivery](/docs/ko/shred-delivery) 및 블로그 게시물 [Winning the Millisecond Game: Shreds, LaserStream, and the Edge of Solana](https://www.helius.dev/blog/solana-shreds)를 참조하세요. ### Staked Connections Helius 유료 계획의 기본 거래 제출 경로입니다. 스테이킹 된 연결은 Solana의 프로토콜 수준 Stake-Weighted Quality of Service (SWQoS)를 통해 다가오는 블록 리더에게 트랜잭션을 라우팅하여 검증자 스테이킹에 기반하여 우선 연결 슬롯을 제공하고 혼잡 시 패킷 감소를 줄입니다. Helius의 유료 계획은 통화자가 직접 무거운 스테이킹 된 검증자를 운영할 필요 없이 이 착륙률 이점을 상속합니다. [거래 최적화](/docs/ko/sending-transactions/optimizing-transactions) 및 블로그 게시물 [Stake-Weighted Quality of Service: Everything You Need to Know](https://www.helius.dev/blog/stake-weighted-quality-of-service-everything-you-need-to-know)를 참조하세요. ### Wallet API Solana 지갑의 잔액, 거래 내역, 전송, ID 및 출처를 쿼리하기 위한 Helius의 REST API입니다. 구조화된 USD 가격의 응답을 제공하며, 원시 RPC 출력 대신 합니다. SNS `.sol` 및 ANS 도메인 이름도 주소와 함께 수락됩니다. [Wallet API](/docs/ko/wallet-api/overview) 참조. *** ## Solana 기초 ### Account Solana에서 데이터를 지속적으로 보유하는 용기입니다. 32바이트의 공개 키로 식별됩니다. 모든 온체인 상태 — 사용자 잔액, 프로그램 코드, 토큰 메타데이터 —는 계정에 존재하며 프로그램 자체도 포함됩니다. 모든 계정에는 소유권이 있으며 소유자는 해당 데이터를 수정하거나 lamport를 인출할 수 있는 프로그램이며, 지속되려면 최소 SOL 잔액(임대 면제)을 유지해야 합니다. 더 나은 이해를 위해 블로그 게시물 [Solana 프로그래밍 모델: Solana 개발 소개](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana)를 참조하세요. ### Agave 현재의 표준 Solana 검증자 클라이언트로, Anza에서 유지 관리합니다 — 원래 Solana Labs 클라이언트의 이름을 바꾼 후속작입니다. 특정 Agave 릴리스에 대한 참조(예: v1.17.31 [SWQoS](#stake-weighted-quality-of-service-swqos) 최소 스테이크 기준)는 일반적으로 클라이언트의 특정 버전으로 동작을 고정시킵니다. [Jito-Solana](#jito)는 블록 엔진이 통합된 Agave의 포크이며, [Firedancer](#firedancer)는 Jump Crypto에서 개발한 독립적인 C 기반 대안입니다. Agave가 구현하는 SVM 모델에 대한 내용은 블로그 게시물 [Solana 가상 머신](https://www.helius.dev/blog/solana-virtual-machine)을 참조하세요. ### Airdrop 주소에 SOL 또는 SPL 토큰을 지원하는 것입니다. Devnet과 Testnet에서는 개발 지갑을 자금 조달하는 데 사용되는 소량의 테스트 SOL을 수반하는 것을 일반적으로 의미하며, Mainnet에서는 기존 보유자에게 대량으로 토큰을 배포하는 것을 의미합니다. Devnet airdrops는 [Devnet faucet](/docs/ko/rpc/devnet-sol)에서 사용할 수 있습니다. ### Associated Token Account (ATA) 특정 SPL 토큰을 지갑 주소에 대해 보유하는 결정론적으로 도출된 토큰 계정입니다. 각 지갑에는 토큰 민트당 최대 하나의 ATA가 있으므로, ATA는 사용자의 토큰 잔액을 조회하는 표준 위치가 됩니다. 지갑 주소와 토큰 민트가 시드로 사용되어 파생됩니다. ### Block 일련의 거래 및 필수 메타데이터를 포함하는 데이터 구조 — 블록의 해시 및 이전 블록의 해시를 포함하여 변경할 수 없는 체인을 형성합니다. 블록은 슬롯 동안 생성됩니다: [슬롯](#slot)에 대한 할당된 [리더](#leader--leader-schedule)는 들어오는 거래를 검증하고 이를 블록에 패키지하여, [터빈](#turbine)을 통해 네트워크에 블록을 브로드캐스트합니다. 모든 슬롯이 블록을 생성하는 것은 아니며, 리더가 제 시간에 블록을 생성하지 못한 경우, 슬롯이 건너뛰고 네트워크는 계속 진행합니다. 블록이 스테이크가 가중된 [검증자](#validator)의 과반수 투표를 받으면 확인된 것으로 간주됩니다 (참조 [Commitment Level](#commitment-level)). Solana의 슬롯, 블록 및 에포크에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/solana-slots-blocks-and-epochs)을 참조하세요. ### Commitment Level 거래가 온체인에 포함되었다는 신뢰 수준: * `processed` — 현재 리더에 의해 보였으나 아직 투표되지 않음; 블록이 합의에 도달하지 못하면 여전히 삭제될 수 있음 (\~0.4초) * `confirmed` — 블록에 대해 ≥66% 스테이크가 가중된 검증자 투표; 역사적으로 확인된 블록은 번복되지 않음 (\~0.6초) * `finalized` — 블록에 ≥66% 투표가 있고 그 상위에 31개의 후속 블록이 구축되어 (즉, Tower BFT의 최대 락아웃), 사실상 번복 불가능 (\~13초) `confirmed`은 기본적으로 추천됩니다. UI 피드백에는 `processed`를 사용하고, 교환 예금이나 체인 간 브리지를 포함한 고가치 작업에는 `finalized`를 사용하세요. `finalized`에서 가져온 블록 해시는 `confirmed`보다 더 빨리 만료되어 거래 만료 전 창이 축소됩니다. Solana Commitment Levels에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/solana-commitment-levels)을 참조하세요. ### Compute Units (CU) 거래에 의해 수행되는 계산 작업의 Solana 측정 방식으로, 이더리움의 가스와 유사합니다. 모든 거래는 계산 단위 한도와 계산 단위 가격(마이크로 람포트/CU 당 우선 수수료)을 지정합니다. 제품은 총 우선 수수료 비용을 결정합니다. 한도를 초과하면 거래가 실패합니다. ### CPI (Cross-Program Invocation) 한 온체인 [프로그램](#program)이 다른 프로그램을 호출하여 계정과 지시어 데이터를 전달하는 Solana 메커니즘입니다 — Solana의 결합 가능성을 가능하게 하는 기본 요소입니다. CPIs는 `sol_invoke_signed` 시스템 호출을 통해 노출되며, 이는 호출자가 전달되는 계정에 대한 적절한 권한을 가지고 있는지 확인합니다. [PDAs](#program-derived-address-pda) 통해 프로그램은 소유 계정을 대신해 서명할 수 있습니다. 호출된 프로그램은 호출 프로그램의 남은 [계산 예산](#compute-units-cu)을 사용하여 작업합니다. 예산이 고갈되거나 설정된 한도를 초과하면 원래 거래를 포함한 모든 호출 체인이 실패합니다. Solana Virtual Machine에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/solana-virtual-machine)을 참조하세요. ### Epoch 약 432,000개의 Solana 슬롯으로 이루어진 클러스터 — Solana가 검증자 세트, 리더 일정, 스테이크 위임 및 보상 분배를 업데이트하는 더 높은 수준의 조직적 간격입니다. 각 에포크는 현재 슬롯 타겟에서 \~2일 소요됩니다. Solana의 슬롯, 블록 및 에포크에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/solana-slots-blocks-and-epochs)을 참조하세요. ### Firedancer Jump Crypto가 처음부터 C로 작성한 두 번째 독립적인 Solana [검증자](#validator) 클라이언트입니다. Firedancer의 목표는 (1) 독립적인 구현을 통해 Solana 프로토콜을 문서화하고 표준화하며, (2) 클라이언트 다양성을 개선하고(단일 클라이언트가 >33% 스테이크를 제어하지 못하도록), (3) 생태계 성능을 증가시키는 것입니다. 아키텍처는 모듈식으로, 단일 목적의 Linux 프로세스(QUIC 타일, 검증 타일 등)가 공유 메모리를 통해 통신하는 방식을 사용합니다. [Agave](#agave)의 단일 프로세스 디자인과는 대조적입니다. Frankendancer는 Firedancer의 고성능 C 네트워킹 코드와 Agave의 Rust 런타임 및 합의 코드를 결합한 하이브리드 중간체입니다. Firedancer에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/what-is-firedancer)을 참조하세요. ### Instruction Solana 거래 내 가장 작은 작업 단위 — 관련 계정 및 데이터와 함께 단일 프로그램 호출입니다. 거래는 다수의 지시어를 모아서 원자적으로 실행됩니다 (모두 성공하거나 모두 함께 되돌리는 방식). Solana 프로그래밍 모델에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana)을 참조하세요. ### Lamport SOL의 가장 작은 단위입니다: 1 SOL = 1,000,000,000 lamports (10⁻⁹ SOL)로, 분산 시스템에 대한 기초적 작업으로 튜링상 수상자인 Leslie Lamport의 이름을 따서 명명되었습니다. 원시 Solana RPC 메서드는 잔액 및 수수료를 람포트 단위로 반환합니다. Helius의 [Wallet API](/docs/ko/wallet-api/overview)는 자동으로 변환을 처리합니다. 우선 수수료는 마이크로람포트(microlamports)로 표시되며, 람포트의 백만분의 일입니다 (10⁻¹⁵ SOL). ### Leader / Leader Schedule 리더는 지정된 [슬롯](#slot) 동안 새 [블록](#block)을 제안할 책임이 있는 [검증자](#validator)입니다. 리더들은 매 스테이크 비중 무작위 일정에 따라 선택되며, 에포크 시작 시 모든 검증자가 독립적으로 다가올 \~2-3일 창 내에서 누가 모든 슬롯을 이끌 것인지 계산할 수 있습니다. 각 리더는 약 1.6초 동안 네 개의 연속적인 슬롯에 할당되어, 연속적인 블록 생성의 짧은 창을 가지고 있습니다. 리더가 슬롯 내에서 블록을 생성하지 못하면 슬롯이 건너뛰어지고 — 네트워크는 누락된 블록을 기다리는 대신 다음 슬롯으로 이동합니다. [Sender](#sender)와 같은 트랜잭션 전송 서비스는 현재 리더와 다음 두 리더에게 서명된 트랜잭션을 라우팅하여 착륙 확률을 극대화합니다. Solana의 Tower BFT 및 History 증명을 통한 합의에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/consensus-on-solana)을 참조하세요. ### Merkle Tree 각 비리프 노드가 자식의 해시인 암호화 트리 구조입니다. 단일 루트 해시는 전체 데이터 세트를 커밋합니다. 데이터가 트리의 일부인지 검증하기 위해서는 리프에서 루트까지의 경로를 따라 형제 해시만 필요하며 — 이는 트리 크기에 관계없이 O(log n) 데이터입니다. 깊이 26 트리의 경우, 증명에는 26개의 형제 해시 (\~832 바이트)가 필요하며, 이는 작지만 여전히 리프당 존재합니다. 이는 [압축 NFT](#compressed-nft-cnft)에서 사용하는 증명 형태입니다. [ZK Compression](#zk-compression)은 데이터 셋 크기와 무관한 단일 일정 크기 [Validity Proof](#validity-proof)로 이를 대체합니다. 해시 함수와 Merkle Trees를 설명하는 블로그 게시물 [암호화 도구 101: 설명된 해시 함수 및 Merkle Trees](https://www.helius.dev/blog/cryptographic-tools-101-hash-functions-and-merkle-trees-explained)를 참조하세요. ### Program 컴파일된 sBPF 바이트코드를 포함하는 실행 가능한 계정 (즉, Solana의 스마트 계약). 프로그램은 상태가 없으며, 소유하는 데이터 계정을 읽고 씁니다. 프로그램 ID (32바이트 주소)로 식별됩니다. Solana에는 런타임에 내장된 기본 프로그램 세트(System, Stake, Vote 등)가 포함되어 있으며, 이 외에는 모두 사용자 배포 프로그램입니다. Solana 프로그래밍 모델에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana)을 참조하세요. ### Program Derived Address (PDA) 프로그램 ID와 시드 집합에서 도출된 결정론적 주소입니다. PDAs는 프로그램이 제어하는 계정에 대한 서명을 허용하여 상태 프로그램 설계에 필수적입니다. PDAs는 의도적으로 곡선 밖에 있어, 이에 대한 개인 키가 존재하지 않습니다. ### Proof of History (PoH) Solana의 동기화 기본 요소 - 합의 알고리즘이 아닙니다. PoH는 검증자가 서로 통신하지 않고도 이벤트의 순서에 동의할 수 있게 하는 암호화 시간 스탬프 함수를 제공합니다. 구현: 각 반복의 출력을 다음 반복의 입력으로 사용하는 연속 SHA-256 해시 체인이 단일 CPU 코어에서 지속적으로 작동합니다. 생성은 순차적이며 싱글 스레드 방식이고, 검증은 병렬로 수행 가능합니다. PoH는 유효한 [블록](#block)을 정의하는 "틱"을 제공합니다. 리더는 주어진 PoH 틱 범위 내에서 블록을 게시해야 하며, 이 범위를 벗어난 블록은 건너뛴 것으로 간주됩니다. PoH는 실제 합의 메커니즘인 [Tower BFT](#tower-bft)와 함께 실행됩니다. PoH, PoS 및 PoW에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/proof-of-history-proof-of-stake-proof-of-work-explained)을 참조하세요. ### Rent / Rent-exempt 온체인에 지속되려면 모든 Solana 계정이 보유해야 하는 SOL 잔액으로, 계정의 저장 크기에 따라 조정됩니다. 계정은 임대 면제로 생성되어야 하며, 계정을 최소한의 한도 이하로 남겨두는 거래는 실패합니다. 일단 임대 면제 상태가 되면, 계정은 추가 결제 없이 무기한 지속됩니다. ### Sealevel Solana의 병렬 거래 실행 엔진입니다. EVM과 같은 순차적 VM과 달리, Sealevel은 CPU 코어에 걸쳐 여러 거래를 동시에 실행합니다. 이는 모든 Solana 거래가 실행 시작 전 읽고 쓸 [계정](#account)을 명시적으로 선언하기 때문이며, 이에 따라 스케줄러는 런타임 분석 없이 비충돌 배치를 식별할 수 있습니다. 스케줄링 규칙은 간단합니다: 다른 계정을 터치하는 거래는 병렬로 실행됩니다; 같은 계정만 읽는 거래도 병렬로 실행됩니다 (읽기는 충돌하지 않음); 같은 계정을 쓰는 거래는 경합 조건을 방지하기 위해 순차적으로 실행됩니다. Solana Virtual Machine에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/solana-virtual-machine)을 참조하세요. ### Slot 지정된 리더 검증자가 블록을 생성할 기회를 가지는 Solana의 기본 시간 단위입니다. 슬롯은 현재 400ms를 목표로 하고 있으나, 실제 지속 시간은 네트워크 상태에 따라 다를 수 있습니다. 리더가 슬롯 내에 블록을 생성하지 못하면 슬롯이 건너뛰며 — 네트워크는 대기하는 대신 다음 슬롯으로 이동합니다. 따라서 모든 슬롯이 블록을 생성하지는 않습니다. Solana의 슬롯, 블록 및 에포크에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/solana-slots-blocks-and-epochs)을 참조하세요. ### SVM (Solana Virtual Machine) Solana의 전체 거래 실행 스택으로, 좁은 바이트코드 해석기가 아닙니다. SVM에는 실행을 지시하는 Bank 구성 요소, Banking Stage 스케줄러, BPF 로더, 스스로 JIT 컴파일된 성능을 위한 sBPF 가상 머신 자체가 포함됩니다 (11개의 범용 레지스터와 \~100개의 오코드가 있는 레지스터 기반 VM). 이는 한정된 바이트코드 실행기를 대체하는 EVM과는 다릅니다. Solana 프로그램은 Solana의 Linux eBPF 포크인 sBPF로 컴파일됩니다. LLVM 프론트엔드를 가진 모든 언어(C, C++, Rust, Zig)는 sBPF를 대상으로 할 수 있습니다. 거래가 계정 접근을 사전에 선언해야 하는 요구 사항은 [Sealevel](#sealevel)의 병렬 실행과 Solana의 지역화된 수수료 시장을 가능케 합니다. Solana Virtual Machine에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/solana-virtual-machine)을 참조하세요. ### Tower BFT Solana의 합의 메커니즘입니다. Tower BFT는 [Proof of History](#proof-of-history-poh)의 동기화된 시계를 이용하여 모든 슬롯에서의 동기화된 합의 라운드를 제거하는 pBFT 유사 알고리즘입니다. 검증자들은 득표탑(vote tower)을 구축합니다 — 각 새로운 투표는 모든 이전 투표의 락아웃 기간을 두 배로 늘려, 포크를 전환하는 스테이크 손실 비용을 기하급수적으로 증가시킵니다. 확인 기준: 스테이크가 중량화된 투표의 ≥2/3가 블록에 도달하면 블록이 **확인**됩니다 (최종성을 위배하려면 총 스테이크의 ≥4.6%를 슬래시해야 합니다). 하나 이상의 투표와 31개의 후속 블록이 추가된 경우 블록은 **최종화**됩니다, 즉 Tower BFT 최대 락아웃. 사용 지침은 [Commitment Level](#commitment-level) 참조. Solana의 Tower BFT 및 History 증명을 통한 합의에 대한 깊은 이해는 [블로그 게시물](https://www.helius.dev/blog/consensus-on-solana)을 참조하세요. ### Turbine Solana의 블록 전파 프로토콜입니다. 리더는 각 블록을 MTU 크기의 [조각](#shred)과 Reed-Solomon 에러 복구 코드를 포함한 복구 조각으로 나눕니다 — FEC 비율(일반적으로 32:32)로 네트워크가 \~33%의 패킷 손실과 함께 블록을 재구성할 수 있습니다. 리더는 전체 블록을 모든 검증자에게 직접 브로드캐스트하는 대신, (조각 그룹당 시드에 의해 `(leader id, slot, shred index, shred type)`) 결정론적인 스테이크 가중 트리로 동료 검증자에게 조각을 전달합니다. 트리(`DATA_PLANE_FANOUT = 200`)는 리더의 아웃바운드 대역폭을 검증자 수와 상관없이 대략 일정하게 유지하고 블록이 네트워크에 2-3홉 만에 도달할 수 있도록 합니다. Turbine: Solana의 블록 전파에 대한 블로그 게시물을 [참조하세요](https://www.helius.dev/blog/turbine-block-propagation-on-solana). ### Validator 할당된 리더 슬롯을 통해 블록을 생성하고 다른 검증자의 블록에 투표하여 합의에 참여하는 Solana 네트워크의 노드입니다. 검증자가 리더 슬롯에 선택되는 것은 활성 스테이크 비율에 비례합니다. *** ## 거래 메커니즘 ### Address Lookup Table (ALT) 버전된 거래가 전체 32바이트 공개키 대신 1바이트 인덱스를 사용하여 참조할 수 있는 Solana 주소의 온체인 테이블입니다. 단일 거래가 최대 256개의 계정을 참조할 수 있게 하며, 그렇지 않으면 거래 크기 제한을 초과할 복잡한 DeFi 작업에 필수적입니다. ### Blockhash 최근 블록을 식별하는 32바이트 해시로, 각 Solana 거래에 포함되어 신선함을 증명합니다. 블록해시는 약 150 슬롯 이후 (\~1분) 만료됩니다. 만료된 블록해시를 포함한 거래는 거절됩니다. 클라이언트는 [`getLatestBlockhash`](/docs/ko/api-reference/rpc/http/getlatestblockhash)를 통해 서명 직전에 최근 블록해시를 가져옵니다. ### Priority Fee 거래가 다른 거래보다 우선적으로 포함되도록 하는 연산 단위당 팁으로, 포함 시간을 개선합니다. 우선 수수료는 계산 단위(µLamports/CU)당 마이크로람포트로 설정됩니다. Helius의 [Priority Fee API](/docs/ko/priority-fee-api)는 최근 온체인 수수료 시장에 기반한 실시간 추정치를 반환합니다. ### Shred Solana 블록의 가장 작은 단위입니다. 블록은 [터빈](https://www.helius.dev/blog/turbine-block-propagation-on-solana)을 통해 검증자 네트워크에 병렬 전파되기 위해 (즉, 분할되어) 조각으로 나뉩니다. 조각 수준 액세스는 블록 조립 이전에 거래자가 초저지연 온체인 신호를 제공하지만 — [Preconfirmations](#preconfirmations)는 계획된 거래 단계에서 더 빨리 도착합니다. 원시 Shreds (UDP) 및 [Shred Delivery 개요](/docs/ko/shred-delivery)를 참조하세요. ### Stake-Weighted Quality of Service (SWQoS) 보낸 사람의 스테이크에 따라 현재 및 다가오는 리더에게 들어오는 거래를 우선 처리하는 Solana 프로토콜 수준 메커니즘입니다. Solana의 2022년 4월 30일 중단 이후 Sybil 저항 조치로 도입되었으며, 낮은 스테이크 또는 스테이크하지 않은 피어가 혼잡 시 리더 대역폭을 독점하지 못하도록 방지합니다. 리더는 두 개의 들어오는 연결 풀을 노출합니다: 모든 스테이크 하지 않은 피어에게 공유되는 \~500개의 개방형 연결과, 스테이크 된 검증자에게 비례적으로 분배되는 \~2,000개의 스테이크 가중 연결입니다 — 한 검증자가 총 활성 스테이크의 X%를 보유하면 리더에게 최대 X%의 패킷을 보낼 수 있습니다. 구성 한도는 Agave v1.17.31에 도착했습니다. Helius의 [Staked Connections](#staked-connections)는 고객 트랜잭션을 Solana의 가장 큰 검증자를 통해 라우팅하여 SWQoS의 착륙률 이점을 상속하므로, 통화자는 무겁게 스테이크 된 검증자를 직접 운영하지 않고도 이점을 얻습니다. 스테이크 가중 QoS에 대한 자세한 내용을 보려면 블로그 게시물 [Stake-Weighted Quality of Service: Everything You Need to Know](https://www.helius.dev/blog/stake-weighted-quality-of-service-everything-you-need-to-know)를 참조하세요. ### Versioned Transaction Address Lookup Tables를 지원하는 최신 Solana 거래 형식으로, 하나의 거래가 최대 256개의 계정을 참조할 수 있도록 합니다 (기존 거래에서는 약 35개). 대부분 현대 DeFi 통합에 필요한 형식입니다. 이는 직렬화된 거래 시작 시에 버전 바이트로 표시됩니다. *** ## 토큰 및 자산 ### Compressed Account 데이터가 거래 로그를 통해 장부에 기록되고, 전체 데이터를 검증자 상태에 전통적인 계정 슬롯에 차지하지 않고 해시 지문만 보관하는 Solana 계정입니다. 개발자는 압축된 계정을 정규 계정처럼 취급할 수 있으며, 인덱서(예: Photon)는 거래 로그를 구문 분석하여 현재 상태를 재구성하고, 일정 크기의 Groth16 영지식 증명이 압축 계정이 읽거나 수정될 때 무결성을 검증합니다. 이 모델은 작은 데이터 계정에 가장 적합합니다. 더 큰 데이터(\~100 바이트 이상)는 압축이 비실용적입니다. ### Compressed NFT (cNFT) Solana NFT는 자체 계정이 아니라 온체인 동시 Merkle 트리의 리프로 나타납니다. 트리는 Solana 계정에 존재하며, 상태 전환은 원장에서 보호됩니다. NFT의 현재 상태는 트리의 온체인 루트에 대해 증명을 생산하는 인덱서에 의해 거래 내역에서 도출됩니다. 따라서 cNFT를 읽으려면 [DAS API](/docs/ko/das-api)와 같은 인덱서가 필요합니다 — 표준 Solana RPC는 cNFT 데이터를 직접 반환할 수 없습니다. 이 모델은 표준 NFT 대비 최대 99%의 민팅 비용을 절감합니다. ### Concurrent Merkle Tree 동일한 슬롯에서 여러 작성자가 서로의 증명을 무효화하지 않고 트리를 업데이트할 수 있도록 설계된 Solana 특유의 [Merkle Tree](#merkle-tree) 변형입니다. 온체인 계정은 현재 루트뿐만 아니라 최근 유효 루트 및 캐노피(상위 트리 노드의 캐시된 하위 집합)의 변경 로그 버퍼를 저장하여, 검증자가 여전히 버퍼 창에 남아 있는 루트에 대해 생성된 증명을 검증할 수 있게 합니다. 트리의 세 가지 매개변수가 정의됩니다: 최대 깊이 (잎 수를 2^깊이로 한정), 버퍼 크기 (변경 로그 깊이 — 이전 진행중인 증명이 무효화되기 전에 얼마나 많은 쓰기가 발생할 수 있는지), 캐노피 깊이 (온체인 임대와 트랜잭션 내 증명의 크기 거래). 유효한 (깊이, 버퍼) 쌍은 (3, 8)에서 (30, 2048)까지 다양합니다; 실용적 결합 가능성을 위해 `maxDepth − canopyDepth ≤ 10` 유지합니다. 동시 Merkle 트리는 SPL Account Compression 프로그램에 의해 구현되며, Metaplex Bubblegum을 통해 리프로 민팅되는 [압축 NFT](#compressed-nft-cnft)의 기초입니다. 압축에 대한 자세한 내용은 블로그 게시물 [Solana 압축에 대해 알아야 할 모든 것](https://www.helius.dev/blog/all-you-need-to-know-about-compression-on-solana)을 참조하세요. ### Groth16 명제 복잡성과 무관하게 일정 크기의 영지식 증명(커브 BN254에서 128 바이트, 점 압축 사용)을 생성하고 O(1) 검증을 제공하는 zk-SNARK 증명 시스템입니다. [ZK 압축](#zk-compression)은 Groth16을 사용하여 압축 계정이 알려진 루트에서 알려진 상태에 속했음을 증명하는 [유효성 증명](#validity-proof)을 생성합니다 — 작은 증명 크기로 인해 압축 계정 거래가 저렴합니다. Solana의 ZK 압축에 대한 자세한 내용은 블로그 게시물 [Solana Builders: ZK 압축](https://www.helius.dev/blog/solana-builders-zk-compression)을 참조하세요. ### Mint Account SPL 토큰의 속성 — 공급, 소수점, 민트/동결 권한을 정의하는 온체인 계정입니다. 민트 계정의 주소는 토큰의 표준 식별자입니다 (이더리움 용어의 "계약 주소"). ### SPL Token Solana 프로그램 라이브러리(SPL)의 토큰 프로그램을 통해 발행된 Solana 토큰입니다. 대체 가능한 토큰(예: USDC, BONK, JUP 등)은 SPL 토큰입니다. 표준 (비압축) NFT 또한 SPL 토큰으로 공급 1 및 소수점 0으로 민팅됩니다. SPL 토큰은 이더리움의 ERC-20 및 ERC-721의 Solana 등가물입니다. Token-2022는 전송 수수료, 기밀 전송과 같은 선택적 기능을 통해 이 인터페이스를 확장하는 새로운 프로그램입니다. ### State Tree [ZK 압축](#zk-compression)이 압축 계정의 해시를 저장하기 위해 사용하는 Merkle 트리입니다. 온체인 계정은 현재 루트와 최소한의 메타데이터만 보유하고 있으며, 실제 압축 데이터는 거래 로그에 존재하며, [Photon](#photon)과 같은 인덱서에 의해 재구성됩니다. 프로그램은 계정의 주장된 내용이 현재 루트 아래의 리프로 해싱된다는 [유효성 증명](#validity-proof)을 통과함으로써 압축 상태를 읽거나 수정합니다. [ZK 압축](/docs/ko/api-reference/zk-compression)을 참조하세요. ### Token Account 특정 소유자를 위한 특정 SPL 토큰의 잔액을 보유하는 온체인 계정입니다. 지갑은 임의의 토큰 계정을 소유할 수 있지만, 관례상 (지갑, 민트) 쌍당 결정론적으로 파생된 토큰 계정인 연결 토큰 계정(ATA)을 사용합니다. 이는 연결 토큰 계정 프로그램에 의해 생성됩니다. ### Token-2022 (토큰 확장) 선택적 확장(예: 전송 수수료, 기밀 전송, 이자 제공 토큰, 비이전 가능 토큰) 을 지원하는 SPL 토큰 프로그램의 변형입니다. Token-2022는 별도의 온체인 프로그램으로 실행되며, 자체 프로그램 ID를 가지지만, 클래식 토큰 프로그램의 호환 가능한 후계자로 디자인되어 있습니다. 따라서 SDK는 일반적으로 둘 모두를 처리할 수 있습니다. 토큰 확장을 사용하려면 Token-2022 프로그램 하에 민트되어야 합니다. 토큰 확장에 대한 자세한 내용은 블로그 게시물 [Token Extensions는 무엇인가요?](https://www.helius.dev/blog/what-is-token-2022)를 참조하세요. ### Validity Proof 특정 루트에서 [State Tree](#state-tree)에 속한 압축 계정의 주장된 내용이 존재함을 증명하는 일정 크기의 [Groth16](#groth16) 영지식 증명입니다. [ZK 압축](#zk-compression) 프로그램은 압축 계정이 읽거나 수정될 때마다 유효성 증명을 요구합니다; 이 증명은 프로그램이 검증자에게 데이터를 온체인에 저장하지 않고 오프체인 상태를 검증할 수 있게 합니다. [Photon](#photon)은 자신의 [`getValidityProof`](/docs/ko/api-reference/zk-compression/getvalidityproof) RPC 메서드를 통해 호출자에게 유효성 증명을 제공합니다. 유효성 증명은 [압축 NFT](#compressed-nft-cnft)와 [ZK 압축](#zk-compression)을 구분합니다: cNFT는 트리 깊이에 따라 증가하는 경로와 주변 트리 상태를 공개하지 않는 일정 크기의 ZK 증명을 사용합니다. Solana의 ZK 압축에 대한 자세한 내용은 블로그 게시물 [Solana Builders: ZK 압축](https://www.helius.dev/blog/solana-builders-zk-compression)을 참조하세요. ### ZK Compression Helius와 Light Protocol에서 개발한 Solana 기본 요소로, 계정 데이터를 원장 내 거래 로그에 커밋하고 검증자 상태에 해시 지문만 저장하여 온체인 저장 비용을 크게 줄입니다. 암호화 무결성은 인덱싱된 거래 데이터에서 생성된 일정 크기의 Groth16 영지식 증명을 통해 유지됩니다. 이 기본 요소는 영지식 증명을 사용하지 않는 동시 Merkle 트리를 사용하는 압축 NFT와 구별됩니다. Solana의 ZK 압축에 대해 자세히 알아보려면 [ZK Compression](/docs/ko/api-reference/zk-compression) 및 블로그 게시물 [Solana Builders: ZK Compression](https://www.helius.dev/blog/solana-builders-zk-compression)을 참조하세요. *** ## 연결 및 스트리밍 ### Geyser 외부 소비자에게 실시간으로 계정, 거래, 슬롯, 블록 등 검증자 상태 변경을 스트리밍하기 위한 Solana의 플러그인 시스템입니다. 검증자는 Geyser 플러그인을 동적 라이브러리로 로드하며; 플러그인은 검증자가 상태를 처리할 때 업데이트를 수신하여 RPC를 폴링할 필요 없이 변경 사항을 가져옵니다. Yellowstone gRPC — 주요 Geyser 플러그인 — 은 gRPC를 통해 이러한 업데이트를 노출합니다. Helius의 [LaserStream](#laserstream)은 역사적 재생 (최대 약 216,000 슬롯 / \~24시간)과 다지역 장애 복구 등의 추가 기능을 갖춘 Yellowstone gRPC 인터페이스를 구현합니다. ### gRPC gRPC는 범용, 고성능 이진 RPC 프로토콜입니다 ("gRPC 원격 프로시저 호출"의 재귀적 약자). Solana 문맥에서, "gRPC"는 일반적으로 Solana의 Geyser 플러그인 시스템에 구축된 스트리밍 인터페이스인 Yellowstone gRPC를 나타내며, 계정 및 거래 업데이트를 gRPC를 통해 노출합니다. Helius의 [LaserStream](/docs/ko/laserstream) 서비스는 역사적 재생, 다지역 장애 복구 및 관리형 인프라 등의 추가 기능을 갖춘 Yellowstone 기반 인터페이스로 구축되었습니다. ### RPC RPC는 원격 프로시저 호출을 의미하며, 서버 메서드를 로컬 함수처럼 호출하는 일반적인 패턴입니다. Solana에서는 "RPC"가 대부분 RPC 노드를 의미합니다 — Solana의 상태를 추적하지만 합의에 참여하지 않으며, JSON-RPC 인터페이스를 통해 데이터 요청(즉, 계정 상태, 거래 내역, 거래 제출)을 서비스하는 데 특화되어 있습니다. 검증자는 이에 반해 블록을 생성하고 투표합니다. Helius의 RPC 서비스는 프로덕션 워크로드에 최적화된 글로벌로 분산된 RPC 노드 플릿입니다. Solana 노드에 대한 개요는 블로그 게시물 [Solana 노드 — Solana RPC, 검증자, 및 RPC 제공자 개요](https://www.helius.dev/blog/solana-nodes-a-primer-on-solana-rpcs-validators-and-rpc-providers)를 참조하세요. ### Webhook 구독된 이벤트가 발생할 때 서버에서 수신자 URL로 보내는 HTTP POST 요청입니다 — "역방향" HTTP로, 서버가 호출을 시작합니다. Helius [Webhooks](/docs/ko/webhooks)는 Solana 온체인 이벤트 (전송, NFT 판매, 사용자 정의 프로그램 활동)를 등록된 엔드포인트로 전송하여 폴링의 필요성을 없앱니다. ### WebSocket (WSS) Solana 데이터 스트리밍을 위해 반복적인 HTTP 요청 없이 푸시 기반으로 사용되는 지속적인 양방향 TCP 연결로, HTTP에서 업그레이드됩니다. WSS (WebSocket Secure)는 TLS를 통해 실행되는 동일한 프로토콜로, 프로덕션 Solana 연결에 사용되는 변형입니다. [LaserStream WebSocket](/docs/ko/rpc/websocket) — Helius의 WebSocket 스트리밍 제품으로, 표준 Solana 메서드와 `transactionSubscribe` 같은 Helius 확장 기능을 포함하여 WSS를 사용합니다. *** ## 생태계 ### Anchor Solana 프로그램을 빠르고 안전하게 구축하기 위한 Rust 프레임워크입니다. 프로시저 매크로를 통해 계정 직렬화, 검증 및 지시어 디스패치와 같은 보일러플레이트를 처리하여 개발자가 저수준 세부사항 대신 프로그램 로직에 집중할 수 있게 합니다. 대부분의 Solana 개발자는 기본 Rust로 프로그램을 작성하는 대신 Anchor를 사용합니다. Solana 프로그램 구축에 대한 초보자 가이드인 블로그 게시물 [Anchor 소개: Solana 프로그램 구축 초보자 가이드](https://www.helius.dev/blog/an-introduction-to-anchor-a-beginners-guide-to-building-solana-programs)를 참조하세요. ### IDL IDL은 Interface Definition Language의 약자입니다. IDL은 Solana 프로그램의 지시어, 계정 및 데이터 유형을 설명하는 JSON 스키마로, 클라이언트가 프로그램 데이터를 해독하고 프로그램 데이터를 디코딩하기 위해 사용합니다. Anchor는 기본적으로 온체인에 전용 계정을 통해 자동으로 IDL을 생성하고 게시합니다. ### Jito 네트워크의 주요 블록 엔진 — MEV(최대 추출 가능 가치) 인프라 레이어 — 트랜잭션 번들을 수락하고 검색자가 번들을 우선적으로 착륙시키기 위해 검증자에게 팁을 지불할 수 있도록 하는 Solana 생태계 회사입니다. Jito-Solana 검증자 클라이언트는 블록 엔진이 통합된 Agave의 포크입니다. 번들 포함에는 최소 10,000 람포트의 팁이 필요하며, Jito-Relayer는 오프체인 번들 경매를 가능하게 하기 위해 \~200ms 동안 인바운드 트래픽을 보유합니다. Helius의 [Sender](#sender)는 스테이크 연결과 Jito의 블록 엔진 모두를 통해 거래를 제출하며, 먼저 착륙하는 경로를 선택합니다. Solana MEV에 대한 소개는 블로그 게시물 [Solana MEV: An Introduction](https://www.helius.dev/blog/solana-mev-an-introduction)을 참조하세요. ### Light Protocol Helius와 함께 [ZK 압축](#zk-compression)을 공동 개발한 Solana 프로토콜 팀입니다. Helius는 표준 인덱서([Photon](#photon))를 구축하고 공개 RPC를 운영하며, Light Protocol은 인덱서에 필요한 온체인 프로그램 및 증명 스택을 구축합니다. [github.com/Lightprotocol/light-protocol](https://github.com/Lightprotocol/light-protocol)을 참조하세요. ### Photon Helius가 구축한 오픈 소스 [ZK 압축](#zk-compression) 인덱서입니다. 압축 계정 데이터는 계정 상태가 아닌 Solana 거래 로그에 존재하여, 검증자가 이를 표준 RPC를 통해 노출하지 않습니다 — Photon은 Solana 거래를 구문 분석하고 압축 계정 상태를 재구성하여 Solana의 기본 RPC를 반영한 JSON-RPC 인터페이스를 통해 제공합니다. [`getCompressedAccount`](/docs/ko/api-reference/zk-compression/getcompressedaccount) 및 [`getValidityProof`](/docs/ko/api-reference/zk-compression/getvalidityproof)과 같은 ZK-Compression 전용 메서드를 제공합니다. 개발자는 [github.com/helius-labs/photon](https://github.com/helius-labs/photon)에서 자가 호스팅하거나 호스팅 Helius 엔드포인트를 사용할 수 있습니다. [ZK 압축](/docs/ko/api-reference/zk-compression)을 참조하세요.