> ## 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. # Glosarium Helius: Definisi Istilah Solana dan Helius > Definisi untuk pengembang mengenai istilah yang digunakan di seluruh dokumentasi Helius dan ekosistem Solana — DAS, LaserStream, Preconfirmations, biaya prioritas, PDA, dan lainnya. Definisi referensi cepat untuk istilah yang digunakan di seluruh dokumentasi Helius dan di Solana. Setiap entri tertaut ke halaman produk atau panduan yang relevan jika tersedia. Langsung ke: * [Produk & Platform Helius](#produk-dan-platform-helius) * [Dasar-Dasar Solana](#dasar-dasar-solana) * [Mekanisme Transaksi](#mekanisme-transaksi) * [Token & Aset](#token-dan-aset) * [Konektivitas & Streaming](#konektivitas-dan-streaming) * [Ekosistem](#ekosistem) *** ## Produk dan Platform Helius ### Penskalaan Otomatis Mekanisme pengisian ulang kredit otomatis Helius untuk paket fiat. Ketika alokasi kredit bulanan habis, penskalaan otomatis membeli kredit tambahan hingga batas yang ditetapkan pengguna, sehingga error `429` tidak mengganggu trafik produksi. Paket kripto tidak memiliki penskalaan otomatis. Sebagai gantinya, paket tersebut menggunakan [kredit prabayar](/docs/id/billing/additional-credits#kredit-prabayar-paket-kripto), yang dibeli secara manual. Lihat [Penskalaan Otomatis](/docs/id/billing/additional-credits). ### Kredit Unit yang digunakan Helius untuk menagih penggunaan API dan streaming. Metode RPC, panggilan DAS, dan throughput streaming masing-masing memiliki biaya kredit tertentu. Setiap paket menyertakan alokasi kredit bulanan yang diatur ulang pada setiap siklus penagihan (kredit yang tidak digunakan tidak diakumulasikan ke siklus berikutnya). Lihat [Kredit](/docs/id/billing/credits) untuk tabel biaya lengkap. ### DAS API Digital Asset Standard — spesifikasi terbuka untuk antarmuka terpadu bagi aset digital Solana (NFT, NFT terkompresi, token fungibel). Implementasi DAS API Helius mengembalikan metadata yang diperkaya, kepemilikan, dan harga dalam satu respons terstruktur, sehingga parser khusus untuk data aset onchain tidak diperlukan. Lihat [DAS API](/docs/id/das-api). ### Node Khusus Node RPC Helius privat tanpa batas laju atau pengukuran kredit, yang ditagih dengan tarif bulanan tetap. Node ini sesuai untuk kasus penggunaan khusus yang memerlukan throughput tanpa batas; sebagian besar aplikasi lebih cocok menggunakan RPC Helius reguler karena performa, failover, dan cakupan fiturnya lebih unggul. Lihat [Node Khusus](/docs/id/dedicated-nodes). ### Transaksi yang Diperkaya API transaksi terurai Helius yang mendekode transaksi mentah Solana menjadi peristiwa yang mudah dibaca — transfer token, penjualan NFT, swap, operasi staking, dan lainnya — tanpa memerlukan parser instruksi per program. Lihat [Transaksi yang Diperkaya](/docs/id/enhanced-transactions/overview). ### Kode Error Kode status HTTP standar yang dikembalikan oleh API Helius, dengan konteks khusus Helius: * `400 Bad Request` — parameter tidak valid atau permintaan salah format (misalnya, format alamat tidak valid, kolom wajib tidak ada, JSON salah format) * `401 Unauthorized` — kunci API tidak ada atau tidak valid * `403 Forbidden` — akses ditolak, biasanya karena pembatasan IP, langganan yang tidak mencakup endpoint, atau izin kunci API yang tidak memadai * `404 Not Found` — tidak tersedia data untuk sumber daya yang diminta (normal untuk pencarian identitas pada dompet yang tidak dikenal) * `429 Too Many Requests` — alokasi kredit habis, batas laju terlampaui, atau batas permintaan bersamaan tercapai * `5xx` — masalah di sisi Helius; coba lagi dengan backoff eksponensial Lihat [Kode Error](/docs/id/faqs/error-codes) untuk detail lengkap dan langkah pemecahan masalah. ### Gatekeeper Gateway edge Helius yang memberikan latensi jauh lebih rendah daripada panggilan RPC standar dengan merutekan permintaan melalui armada proksi yang tersebar secara global. Akses dilakukan dengan mengganti `mainnet.helius-rpc.com` menjadi `beta.helius-rpc.com` dalam URL RPC. Lihat [Gatekeeper](/docs/id/gatekeeper/overview) dan [postingan blog Memperkenalkan Gatekeeper](https://www.helius.dev/blog/introducing-gatekeeper) untuk mengetahui latar belakang arsitekturnya. ### LaserStream Layanan streaming gRPC berperforma tinggi dari Helius untuk data onchain Solana, dengan pemutaran ulang historis, failover multiwilayah, dan kumpulan fitur terlengkap di antara produk streaming Helius. SDK resmi tersedia untuk JavaScript/TypeScript, Rust, dan Go. [LaserStream WebSocket](#laserstream-websocket) berjalan pada infrastruktur yang sama. Lihat [LaserStream](/docs/id/laserstream) dan [postingan blog performa SDK LaserStream](https://www.helius.dev/blog/laserstream-sdks) untuk pembahasan mendalam tentang tolok ukur SDK. ### LaserStream WebSocket Layanan streaming WebSocket persisten dari Helius. Layanan ini menyediakan metode WebSocket Solana standar dan ekstensi khusus Helius (`transactionSubscribe` serta `accountSubscribe` yang diperkaya dengan pemfilteran lebih lengkap) pada satu endpoint terpadu. LaserStream WebSocket menggunakan backend yang sama dengan gRPC [LaserStream](#laserstream). Lihat [LaserStream WebSocket](/docs/id/rpc/websocket). ### Preconfirmations Sinyal transaksi dengan latensi terendah dari Helius. Sinyal ini mengalirkan transaksi sebelum dikumpulkan menjadi entri dan dipecah menjadi shred: Preconfirmations Helius dikirim tepat saat leader mengeksekusinya, beserta status eksekusinya, sedangkan Preconfirmations BAM dikirim ketika validator berkomitmen untuk mengeksekusinya, sebelum transaksi dijalankan. Lebih awal daripada [Shred Delivery](#shred-delivery) dan stream dengan tingkat komitmen processed. Dikirim melalui langganan WebSocket `preconfSubscribe`. Memerlukan paket Professional atau lebih tinggi; diukur sebesar 10 kredit per pesan. Cakupan bergantung pada validator yang meneruskan stream mereka ke Helius, sehingga umpan ini tidak kontinu. Lihat [Preconfirmations](/docs/id/pre-confirmations/overview) dan [`preconfSubscribe`](/docs/id/pre-confirmations/preconf-subscribe). ### API Biaya Prioritas Endpoint estimasi biaya Helius yang mengembalikan nilai biaya prioritas yang direkomendasikan berdasarkan pasar biaya onchain secara real-time. Memungkinkan penetapan biaya yang kompetitif tanpa menebak atau membayar terlalu mahal saat terjadi kepadatan. Lihat [API Biaya Prioritas](/docs/id/priority-fee-api). ### Batas Laju Jumlah maksimum permintaan per detik yang diizinkan dalam paket Helius tertentu. Batas laju berbeda menurut tingkat paket dan kelompok API (RPC standar, Enhanced API, streaming). Pelampauan batas akan mengembalikan `429 Too Many Requests`. Lihat [Batas Laju](/docs/id/billing/rate-limits). ### Sender Layanan pendaratan transaksi khusus Helius yang dibuat untuk pedagang berlatensi rendah, menggabungkan biaya prioritas, tip Jito, dan perutean koneksi berbobot stake untuk memaksimalkan tingkat pendaratan. Tersedia di `https://sender.helius-rpc.com/fast`. Lihat [Sender](/docs/id/sending-transactions/sender). ### Shred Delivery Layanan Helius untuk melakukan streaming shred mentah Solana melalui UDP, yang dikirim sebelum perakitan blok akhir. Helius mengagregasi shred dari jaringan validator terdistribusi di berbagai wilayah untuk meminimalkan variasi latensi geografis dari satu validator. Berguna untuk perdagangan frekuensi tinggi, arbitrase, dan aplikasi berlatensi rendah lainnya. Shred mentah tersedia secara mandiri dari [Dasbor Helius](https://dashboard.helius.dev/shred-delivery-seats) - \$1.000/bulan per IP (\$800/bulan per IP pada paket Pro). Lihat [Shred Delivery](/docs/id/shred-delivery) dan postingan blog [Memenangkan Permainan Milidetik: Shred, LaserStream, dan Keunggulan Solana](https://www.helius.dev/blog/solana-shreds) untuk pembahasan mendalam tentang cara kerja shred. ### Koneksi Berbobot Stake Jalur pengiriman transaksi default untuk paket berbayar Helius. Koneksi berbobot stake merutekan transaksi ke leader blok mendatang melalui Stake-Weighted Quality of Service (SWQoS) tingkat protokol Solana, yang memberikan slot koneksi istimewa berdasarkan stake validator dan mengurangi paket yang hilang saat terjadi kepadatan. Paket berbayar Helius mewarisi keunggulan tingkat pendaratan ini tanpa mengharuskan pemanggil mengoperasikan validator dengan stake besar secara langsung. Lihat [Mengoptimalkan Transaksi](/docs/id/sending-transactions/optimizing-transactions) dan postingan blog [Stake-Weighted Quality of Service: Semua yang Perlu Anda Ketahui](https://www.helius.dev/blog/stake-weighted-quality-of-service-everything-you-need-to-know). ### Wallet API REST API Helius untuk mengueri saldo, riwayat transaksi, transfer, identitas, dan sumber pendanaan dompet Solana — menghasilkan respons terstruktur dengan harga dalam USD, bukan keluaran RPC mentah. API ini menerima nama domain SNS `.sol` dan ANS selain alamat. Lihat [Wallet API](/docs/id/wallet-api/overview). *** ## Dasar-Dasar Solana ### Akun Kontainer yang menyimpan data secara persisten di Solana dan diidentifikasi oleh kunci publik 32 byte. Semua status onchain — saldo pengguna, kode program, metadata token — berada dalam akun, termasuk program itu sendiri. Setiap akun memiliki pemilik, yaitu program yang diizinkan mengubah datanya atau menarik lamport, dan harus mempertahankan saldo SOL minimum (bebas sewa) agar tetap tersimpan. Lihat postingan blog [Model Pemrograman Solana: Pengantar Pengembangan di Solana](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana) untuk pembahasan lebih mendalam. ### Agave Klien validator Solana kanonis saat ini, yang dikelola oleh Anza — penerus klien Solana Labs asli dengan merek baru. Referensi ke rilis Agave tertentu (misalnya, ambang stake minimum [SWQoS](#stake-weighted-quality-of-service-swqos) pada v1.17.31) biasanya mengaitkan perilaku dengan versi klien tertentu. [Jito-Solana](#jito) adalah fork Agave dengan mesin blok mereka yang terintegrasi; [Firedancer](#firedancer) adalah alternatif independen berbasis C yang dikembangkan oleh Jump Crypto. Lihat postingan blog [Mesin Virtual Solana](https://www.helius.dev/blog/solana-virtual-machine) untuk memahami model SVM yang diimplementasikan Agave. ### Airdrop Pemberian SOL atau token SPL ke suatu alamat. Di Devnet dan Testnet, airdrop biasanya berarti sejumlah kecil SOL pengujian dari faucet yang digunakan untuk mendanai dompet pengembangan; di Mainnet, istilah ini mengacu pada distribusi token massal kepada pemegang yang sudah ada. Airdrop Devnet tersedia melalui [faucet Devnet](/docs/id/rpc/devnet-sol). ### Associated Token Account (ATA) Akun token yang diturunkan secara deterministik dan menyimpan token SPL tertentu untuk alamat dompet tertentu. Setiap dompet memiliki paling banyak satu ATA per mint token, sehingga ATA menjadi tempat kanonis untuk mencari saldo token pengguna. ATA diturunkan menggunakan alamat dompet dan mint token sebagai seed. ### Blok Struktur data yang berisi sekumpulan transaksi beserta metadata penting — termasuk hash blok dan hash blok sebelumnya, yang membentuk rantai tetap. Blok diproduksi selama slot: [leader](#leader--jadwal-leader) yang ditetapkan untuk suatu [slot](#slot) memvalidasi transaksi masuk, mengemasnya menjadi blok, lalu menyiarkan blok tersebut ke jaringan melalui [Turbine](#turbine). Tidak setiap slot menghasilkan blok — jika leader gagal memproduksinya tepat waktu, slot dilewati dan jaringan melanjutkan proses. Setelah blok menerima supermayoritas suara [validator](#validator) berbobot stake, blok dianggap terkonfirmasi (lihat [Tingkat Komitmen](#tingkat-komitmen)). Lihat postingan blog [Memahami Slot, Blok, dan Epoch di Solana](https://www.helius.dev/blog/solana-slots-blocks-and-epochs) untuk pembahasan lebih mendalam. ### Tingkat Komitmen Tingkat keyakinan bahwa suatu transaksi telah disertakan secara onchain: * `processed` — telah dilihat oleh leader saat ini tetapi belum dipilih; masih dapat dibatalkan jika blok kehilangan konsensus (\~0,4 dtk) * `confirmed` — ≥66% suara validator berbobot stake diberikan pada blok; secara historis, belum pernah ada blok terkonfirmasi yang dibatalkan (\~0,6 dtk) * `finalized` — blok memiliki ≥66% suara ditambah 31 blok berikutnya yang dibangun di atasnya (yaitu, lockout maksimum Tower BFT), sehingga secara efektif tidak dapat dibalik (\~13 dtk) `confirmed` adalah pilihan default yang direkomendasikan. Gunakan `processed` untuk umpan balik UI dan `finalized` untuk operasi bernilai tinggi seperti deposit bursa atau bridge lintas rantai. Blockhash yang diambil pada `finalized` kedaluwarsa lebih cepat daripada blockhash `confirmed`, sehingga mempersempit jangka waktu sebelum transaksi kedaluwarsa. Lihat postingan blog [Apa Itu Tingkat Komitmen Solana?](https://www.helius.dev/blog/solana-commitment-levels) untuk pembahasan lebih mendalam. ### Unit Komputasi (CU) Ukuran Solana untuk pekerjaan komputasi yang dilakukan oleh suatu transaksi, serupa dengan gas di Ethereum. Setiap transaksi menentukan batas unit komputasi dan harga unit komputasi (biaya prioritas dalam mikrolamport per CU); hasil perkaliannya menentukan total biaya prioritas. Transaksi gagal jika melampaui batas. ### CPI (Cross-Program Invocation) Mekanisme Solana yang memungkinkan satu [program](#program) onchain memanggil program lain dengan meneruskan akun dan data instruksi — mekanisme dasar yang memungkinkan komposabilitas Solana. CPI diekspos melalui syscall `sol_invoke_signed`, yang memverifikasi bahwa pemanggil memiliki izin yang sesuai untuk akun yang diteruskan; [PDA](#program-derived-address-pda) memungkinkan program menandatangani atas nama akun yang dimilikinya. Program yang dipanggil beroperasi dalam sisa [anggaran komputasi](#unit-komputasi-cu) program pemanggil: jika anggaran habis atau batas yang ditetapkan terlampaui, seluruh rantai panggilan gagal — termasuk transaksi awal. Lihat postingan blog [Mesin Virtual Solana](https://www.helius.dev/blog/solana-virtual-machine) untuk pembahasan lebih mendalam. ### Epoch Sekelompok sekitar 432.000 slot Solana — interval organisasi tingkat tinggi ketika Solana memperbarui kumpulan validator, jadwal leader, delegasi stake, dan distribusi imbalannya. Setiap epoch memerlukan waktu \~2 hari dengan target slot saat ini. Lihat postingan blog [Memahami Slot, Blok, dan Epoch di Solana](https://www.helius.dev/blog/solana-slots-blocks-and-epochs) untuk pembahasan lebih mendalam. ### Firedancer Klien [validator](#validator) Solana independen kedua, yang ditulis dari awal dalam C oleh Jump Crypto. Tujuan Firedancer adalah (1) mendokumentasikan dan menstandardisasi protokol Solana melalui implementasi independen, (2) meningkatkan keragaman klien (tidak ada satu klien pun yang mengendalikan >33% stake), dan (3) meningkatkan performa ekosistem. Arsitekturnya modular: banyak proses Linux bertujuan tunggal yang disebut "tile" (tile QUIC, tile verifikasi, dan sebagainya) berkomunikasi melalui memori bersama, berbeda dengan desain proses tunggal [Agave](#agave). Frankendancer adalah versi hibrida perantara mereka — kode jaringan C berperforma tinggi Firedancer dipadukan dengan runtime dan kode konsensus Rust Agave. Lihat postingan blog [Apa Itu Firedancer?](https://www.helius.dev/blog/what-is-firedancer) untuk pembahasan lebih mendalam. ### Instruksi Unit kerja terkecil di dalam transaksi Solana — satu pemanggilan program dengan akun dan data yang relevan. Transaksi menggabungkan satu atau beberapa instruksi yang dieksekusi secara atomik (semuanya berhasil atau semuanya dibatalkan bersama-sama). Lihat postingan blog [Model Pemrograman Solana: Pengantar Pengembangan di Solana](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana) untuk pembahasan lebih mendalam. ### Lamport Unit SOL terkecil: 1 SOL = 1.000.000.000 lamport (10⁻⁹ SOL), dinamai menurut Leslie Lamport, pemenang Turing Award atas karya fundamentalnya dalam sistem terdistribusi. Metode RPC mentah Solana mengembalikan saldo dan biaya dalam lamport; [Wallet API](/docs/id/wallet-api/overview) Helius menangani konversi secara otomatis. Biaya prioritas dinyatakan dalam mikrolamport — sepersejuta lamport (10⁻¹⁵ SOL). ### Leader / Jadwal Leader Leader adalah [validator](#validator) yang ditugaskan untuk mengusulkan [blok](#blok) baru selama [slot](#slot) tertentu. Leader dipilih melalui jadwal acak berbobot stake yang dihitung pada awal setiap [epoch](#epoch), sehingga setiap validator dapat menentukan secara independen siapa yang akan memimpin setiap slot dalam rentang \~2–3 hari mendatang. Setiap leader diberi empat slot berturut-turut (\~1,6 detik pada \~400 md per slot), yang memberinya jangka waktu singkat untuk memproduksi blok secara berurutan. Jika leader gagal menghasilkan blok dalam slotnya, slot tersebut dilewati — jaringan melanjutkan proses alih-alih menunggu blok yang hilang. Layanan pengiriman transaksi seperti [Sender](#sender) merutekan transaksi yang telah ditandatangani ke leader saat ini dan dua leader berikutnya untuk memaksimalkan probabilitas pendaratan. Lihat postingan blog [Konsensus di Solana: Tower BFT dan Proof of History](https://www.helius.dev/blog/consensus-on-solana) untuk pembahasan lebih mendalam. ### Pohon Merkle Struktur pohon kriptografis dengan setiap node non-daun merupakan hash dari anak-anaknya, sehingga satu hash akar berkomitmen pada seluruh set data. Untuk memverifikasi bahwa suatu bagian data termasuk dalam pohon, hanya diperlukan hash sibling di sepanjang jalur dari daun ke akar — bukti Merkle — yang berukuran O(log n) terlepas dari ukuran pohon. Untuk pohon berkedalaman 26, bukti tersebut terdiri dari 26 hash sibling (\~832 byte), yang kecil tetapi tetap diperlukan per daun: inilah bentuk bukti yang digunakan oleh [NFT terkompresi](#nft-terkompresi-cnft). [ZK Compression](#zk-compression) menggantinya dengan satu [Bukti Validitas](#bukti-validitas) berukuran konstan yang tidak bertambah seiring ukuran set data. Lihat postingan blog [Dasar-Dasar Alat Kriptografi: Penjelasan Fungsi Hash dan Pohon Merkle](https://www.helius.dev/blog/cryptographic-tools-101-hash-functions-and-merkle-trees-explained). ### Program Akun yang dapat dieksekusi dan berisi bytecode sBPF terkompilasi (yaitu smart contract di Solana). Program tidak memiliki status — program membaca dan menulis akun data yang dimilikinya, serta diidentifikasi oleh ID program (alamat 32 byte miliknya). Solana dilengkapi sekumpulan program native (System, Stake, Vote, dan sebagainya) yang tertanam dalam runtime; program lainnya merupakan program yang di-deploy pengguna. Lihat postingan blog [Model Pemrograman Solana: Pengantar Pengembangan di Solana](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana) untuk pembahasan lebih mendalam. ### Program Derived Address (PDA) Alamat deterministik yang diturunkan dari ID program dan sekumpulan seed. PDA memungkinkan program menandatangani untuk akun yang dikendalikannya, sehingga penting untuk desain program berstatus. PDA sengaja dibuat berada di luar kurva, sehingga tidak memiliki kunci privat. ### Proof of History (PoH) Primitif sinkronisasi Solana — bukan algoritma konsensus. PoH menyediakan fungsi stempel waktu kriptografis yang memungkinkan validator menyepakati urutan peristiwa tanpa saling berkomunikasi. Implementasinya berupa rantai hash SHA-256 berurutan yang berjalan terus-menerus pada satu inti CPU per validator, dengan keluaran setiap iterasi digunakan sebagai masukan iterasi berikutnya. Pembuatannya berurutan dan berutas tunggal; verifikasinya dapat diparalelkan. PoH menyediakan "tick" yang menentukan kapan suatu [blok](#blok) valid. Leader harus memublikasikan blok dalam rentang tick PoH tertentu — blok di luar rentang dianggap dilewati. PoH berjalan bersama [Tower BFT](#tower-bft), yang merupakan mekanisme konsensus sebenarnya. Lihat postingan blog [Penjelasan Proof of History, Proof of Stake, dan Proof of Work](https://www.helius.dev/blog/proof-of-history-proof-of-stake-proof-of-work-explained) untuk pembahasan lebih mendalam. ### Sewa / Bebas Sewa Saldo SOL yang harus dimiliki setiap akun Solana agar tetap tersimpan secara onchain, yang disesuaikan dengan ukuran penyimpanan akun. Akun harus dibuat dalam kondisi bebas sewa: transaksi yang menyebabkan saldo akun turun di bawah minimum akan gagal. Setelah bebas sewa, akun tetap tersimpan tanpa batas waktu dan tanpa pembayaran tambahan. ### Sealevel Mesin eksekusi transaksi paralel Solana. Tidak seperti VM berurutan seperti EVM, Sealevel mengeksekusi beberapa transaksi secara bersamaan di berbagai inti CPU. Hal ini dimungkinkan karena setiap transaksi Solana secara eksplisit mendeklarasikan [akun](#akun) yang akan dibaca dan ditulis sebelum eksekusi dimulai, sehingga penjadwal dapat mengidentifikasi batch yang tidak berkonflik tanpa analisis runtime. Aturan penjadwalannya sederhana: transaksi yang menyentuh akun berbeda berjalan paralel; transaksi yang hanya membaca akun yang sama juga berjalan paralel (pembacaan tidak berkonflik); transaksi yang menulis ke akun yang sama berjalan berurutan untuk mencegah kondisi balapan. Lihat postingan blog [Mesin Virtual Solana](https://www.helius.dev/blog/solana-virtual-machine) untuk pembahasan lebih mendalam. ### Slot Unit waktu fundamental Solana, yaitu periode ketika validator leader yang ditunjuk memiliki kesempatan untuk menghasilkan blok. Slot saat ini menargetkan 400 md, meskipun durasi aktual dapat berbeda sesuai kondisi jaringan. Jika leader gagal menghasilkan blok selama slotnya, slot tersebut dilewati — jaringan beralih ke slot berikutnya alih-alih menunggu, sehingga tidak setiap slot menghasilkan blok. Lihat postingan blog [Memahami Slot, Blok, dan Epoch di Solana](https://www.helius.dev/blog/solana-slots-blocks-and-epochs) untuk pembahasan lebih mendalam. ### SVM (Solana Virtual Machine) Stack eksekusi transaksi lengkap Solana — bukan sekadar interpreter bytecode. SVM mencakup komponen Bank yang mengorkestrasi eksekusi, penjadwal Banking Stage, pemuat BPF, dan mesin virtual sBPF itu sendiri (VM berbasis register dengan 11 register serbaguna dan \~100 opcode, yang dikompilasi JIT untuk performa). Ini berbeda dari EVM, yang secara jelas mengacu pada satu eksekutor bytecode. Program Solana dikompilasi menjadi sBPF, fork Linux eBPF milik Solana. Bahasa apa pun dengan frontend LLVM (C, C++, Rust, Zig) dapat menargetkan sBPF. Persyaratan agar transaksi mendeklarasikan akses akun sejak awal memungkinkan eksekusi paralel [Sealevel](#sealevel) dan pasar biaya lokal Solana. Lihat postingan blog [Mesin Virtual Solana](https://www.helius.dev/blog/solana-virtual-machine) untuk pembahasan lebih mendalam. ### Tower BFT Mekanisme konsensus Solana. Tower BFT adalah algoritma serupa pBFT yang memanfaatkan jam tersinkronisasi [Proof of History](#proof-of-history-poh), sehingga tidak memerlukan putaran konsensus sinkron pada setiap slot. Validator membangun "menara suara" — tumpukan suara berurutan dengan setiap suara baru menggandakan periode lockout semua suara sebelumnya, sehingga biaya kehilangan stake akibat berpindah fork meningkat secara eksponensial. Ambang konfirmasi: blok menjadi **terkonfirmasi** setelah ≥2/3 suara berbobot stake diberikan kepadanya (≥4,6% dari total stake harus terkena slashing untuk melanggar finalitas). Blok menjadi **final** setelah memperoleh suara ditambah 31 blok berikutnya yang dibangun di atasnya, yaitu lockout maksimum Tower BFT. Lihat [Tingkat Komitmen](#tingkat-komitmen) untuk panduan penggunaan. Lihat postingan blog [Konsensus di Solana: Tower BFT dan Proof of History](https://www.helius.dev/blog/consensus-on-solana) untuk pembahasan lebih mendalam. ### Turbine Protokol propagasi blok Solana. Leader membagi setiap blok menjadi [shred](#shred) berukuran MTU ditambah shred pemulihan dengan pengodean penghapusan Reed-Solomon — tingkat FEC (biasanya 32:32) memungkinkan jaringan merekonstruksi blok bahkan dengan kehilangan paket \~33%. Leader kemudian meneruskan shred melalui pohon deterministik validator peer berbobot stake (yang diberi seed per grup shred oleh `(leader id, slot, shred index, shred type)`), alih-alih menyiarkan seluruh blok secara langsung ke setiap validator. Pohon tersebut (`DATA_PLANE_FANOUT = 200`) menjaga bandwidth keluar leader tetap relatif konstan terlepas dari jumlah validator dan memungkinkan blok mencapai jaringan dalam 2–3 hop, bukan O(n). Lihat postingan blog [Turbine: Propagasi Blok di Solana](https://www.helius.dev/blog/turbine-block-propagation-on-solana). ### Validator Node di jaringan Solana yang berpartisipasi dalam konsensus dengan menghasilkan blok selama slot leader yang ditetapkan kepadanya dan memberikan suara pada blok dari validator lain. Validator dipilih untuk slot leader secara proporsional berdasarkan stake aktifnya. *** ## Mekanisme Transaksi ### Address Lookup Table (ALT) Tabel alamat Solana onchain yang dapat dirujuk oleh transaksi berversi menggunakan indeks 1 byte, bukan pubkey lengkap 32 byte, sehingga satu transaksi dapat merujuk hingga 256 akun. ALT sangat penting untuk operasi DeFi kompleks yang jika tidak menggunakannya akan melampaui batas ukuran transaksi. ### Blockhash Hash 32 byte yang mengidentifikasi blok terbaru, disertakan dalam setiap transaksi Solana untuk membuktikan kebaruan. Blockhash kedaluwarsa setelah \~150 slot (\~1 menit); transaksi dengan blockhash kedaluwarsa akan ditolak. Klien mengambil blockhash terbaru melalui [`getLatestBlockhash`](/docs/id/api-reference/rpc/http/getlatestblockhash) tepat sebelum penandatanganan. ### Biaya Prioritas Tip per unit komputasi yang dibayarkan kepada validator untuk memberi transaksi prioritas dibandingkan transaksi lain, sehingga mempercepat waktu penyertaannya. Biaya prioritas ditetapkan dalam mikrolamport per unit komputasi (µLamports/CU). [API Biaya Prioritas](/docs/id/priority-fee-api) Helius mengembalikan estimasi real-time berdasarkan pasar biaya onchain terbaru. ### Shred Unit terkecil dari blok Solana. Blok dibagi (yaitu, dipecah) menjadi shred untuk propagasi paralel di seluruh jaringan validator melalui [Turbine](https://www.helius.dev/blog/turbine-block-propagation-on-solana). Akses tingkat shred memberi pedagang sinyal onchain berlatensi ultra-rendah sebelum perakitan blok — meskipun [Preconfirmations](#preconfirmations) tiba lebih awal lagi, sebelum entri dipecah menjadi shred. Lihat [Shred Mentah (UDP)](/docs/id/shred-delivery/raw-shreds) dan [ikhtisar Shred Delivery](/docs/id/shred-delivery). ### Stake-Weighted Quality of Service (SWQoS) Mekanisme tingkat protokol Solana yang memprioritaskan transaksi masuk ke leader saat ini dan mendatang berdasarkan stake pengirim. Diperkenalkan setelah gangguan Solana pada 30 April 2022 sebagai langkah resistansi Sybil, SWQoS mencegah peer dengan stake rendah atau tanpa stake memonopoli bandwidth leader saat terjadi kepadatan. Leader mengekspos dua kumpulan koneksi masuk: \~500 koneksi terbuka yang digunakan bersama oleh semua peer tanpa stake, dan \~2.000 koneksi berbobot stake yang didistribusikan secara proporsional kepada validator dengan stake — validator yang memiliki X% dari total stake aktif dapat mengirim hingga X% paket kepada leader. Validator dengan stake aktif di bawah \~15.000 SOL (\~1/25.000 dari total stake jaringan) diperlakukan sebagai validator tanpa stake. Ambang stake minimum diterapkan pada Agave v1.17.31. [Koneksi Berbobot Stake](#koneksi-berbobot-stake) Helius mewarisi keunggulan tingkat pendaratan ini dengan merutekan transaksi pelanggan melalui validator terbesar Solana, sehingga pemanggil memperoleh manfaat SWQoS tanpa mengoperasikan validator dengan stake besar secara langsung. Lihat postingan blog [Stake-Weighted Quality of Service: Semua yang Perlu Anda Ketahui](https://www.helius.dev/blog/stake-weighted-quality-of-service-everything-you-need-to-know). ### Transaksi Berversi Format transaksi Solana yang diidentifikasi oleh byte versi pada awal transaksi berseri. Versi 0 (v0) menambahkan Address Lookup Table, sehingga satu transaksi dapat merujuk hingga 256 akun (dibandingkan \~35 pada transaksi lama). Versi 1 (v1, [SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md), Agave 4.2) memindahkan tanda tangan ke akhir transaksi dan membawa anggaran komputasi dalam kolom header `transactionConfig`, bukan instruksi ComputeBudget. Tetapkan `maxSupportedTransactionVersion: 1` pada permintaan RPC untuk menerima setiap versi. Lihat [dukungan Transaksi v1](/docs/id/rpc/transaction-v1). *** ## Token dan Aset ### Akun Terkompresi Akun terkompresi adalah akun Solana yang datanya dikomit ke ledger melalui log transaksi, sementara hanya sidik jari hash yang disimpan dalam status validator — bukan data lengkap yang menempati slot akun tradisional pada disk validator. Pengembang dapat memperlakukan akun terkompresi seperti akun biasa; pengindeks (seperti Photon) mengurai log transaksi untuk merekonstruksi status saat ini, dan bukti zero-knowledge Groth16 berukuran konstan memverifikasi integritas ketika akun dibaca atau diubah melalui ZK Compression. Model ini paling cocok untuk akun dengan data kecil — data yang lebih besar (di atas \~100 byte) membuat kompresi tidak praktis. ### NFT Terkompresi (cNFT) NFT Solana yang direpresentasikan sebagai daun dalam pohon Merkle konkuren onchain, bukan sebagai akun tersendiri. Pohon tersebut berada dalam akun Solana dan transisi statusnya diamankan oleh ledger; status NFT saat ini diturunkan dari riwayat transaksi oleh pengindeks, yang menghasilkan bukti Merkle yang dapat diverifikasi terhadap akar onchain pohon. Karena itu, membaca cNFT memerlukan pengindeks seperti [DAS API](/docs/id/das-api) — RPC Solana standar tidak dapat mengembalikan data cNFT secara langsung. Model ini mengurangi biaya mint hingga 99% dibandingkan NFT standar. ### Pohon Merkle Konkuren Varian [Pohon Merkle](#pohon-merkle) khusus Solana yang dirancang agar beberapa penulis dapat memperbarui pohon dalam slot yang sama tanpa membuat bukti satu sama lain menjadi tidak valid. Akun onchain tidak hanya menyimpan akar saat ini, tetapi juga buffer changelog akar valid terbaru dan canopy (subset node bagian atas pohon yang di-cache), sehingga validator dapat memverifikasi bukti yang dibuat terhadap akar apa pun yang masih berada dalam jendela buffer. Tiga parameter menentukan sebuah pohon: kedalaman maksimum (membatasi jumlah daun hingga 2^kedalaman), ukuran buffer (kedalaman changelog — jumlah penulisan yang dapat terjadi sebelum bukti lama yang masih diproses menjadi tidak valid), dan kedalaman canopy (yang menukar sewa onchain dengan bukti dalam transaksi yang lebih kecil). Pasangan (kedalaman, buffer) yang valid berkisar dari (3, 8) hingga (30, 2048); untuk komposabilitas praktis, pertahankan `maxDepth − canopyDepth ≤ 10`. Pohon Merkle konkuren diimplementasikan oleh program SPL Account Compression dan menjadi fondasi bagi [NFT terkompresi](#nft-terkompresi-cnft), yang dicetak sebagai daun melalui Metaplex Bubblegum. Lihat postingan blog [Semua yang Perlu Anda Ketahui tentang Kompresi di Solana](https://www.helius.dev/blog/all-you-need-to-know-about-compression-on-solana). ### Groth16 Sistem pembuktian zk-SNARK yang menghasilkan bukti zero-knowledge berukuran konstan (128 byte pada kurva BN254, menggunakan kompresi titik) terlepas dari kompleksitas pernyataan, dengan verifikasi O(1). [ZK Compression](#zk-compression) menggunakan Groth16 untuk menghasilkan [Bukti Validitas](#bukti-validitas) bahwa akun terkompresi merupakan bagian dari status yang diketahui pada akar tertentu — ukuran bukti yang kecil menjaga biaya transaksi akun terkompresi tetap rendah. Lihat postingan blog [Pengembang Solana: ZK Compression](https://www.helius.dev/blog/solana-builders-zk-compression). ### Akun Mint Akun onchain yang mendefinisikan properti token SPL — suplai, desimal, serta otoritas mint/pembekuan. Alamat akun mint adalah pengidentifikasi kanonis token ("alamat kontrak" dalam istilah Ethereum). ### Token SPL Token di Solana yang diterbitkan melalui Token Program dari Solana Program Library (SPL). Token fungibel (USDC, BONK, JUP, dan sebagainya) adalah token SPL; NFT standar (tidak terkompresi) juga merupakan token SPL, yang dicetak dengan suplai 1 dan 0 desimal. Token SPL kurang lebih setara dengan ERC-20 dan ERC-721 di Ethereum. Token-2022 adalah program yang lebih baru dan memperluas antarmuka ini dengan fitur opsional seperti biaya transfer dan transfer rahasia. ### Pohon Status Pohon Merkle yang digunakan [ZK Compression](#zk-compression) untuk menyimpan hash akun terkompresi. Akun onchain hanya menyimpan akar saat ini ditambah metadata minimal; data terkompresi yang sebenarnya berada dalam log transaksi dan direkonstruksi oleh pengindeks seperti [Photon](#photon). Program membaca atau mengubah status terkompresi dengan meneruskan [Bukti Validitas](#bukti-validitas) bahwa hash konten yang diklaim akun sesuai dengan daun di bawah akar saat ini. Lihat [ZK Compression](/docs/id/api-reference/zk-compression). ### Akun Token Akun onchain yang menyimpan saldo token SPL tertentu untuk pemilik tertentu. Dompet dapat memiliki akun token apa pun, tetapi konvensinya adalah menggunakan Associated Token Account (ATA) — akun token yang diturunkan secara deterministik untuk setiap pasangan (dompet, mint) dan dibuat oleh Associated Token Account Program. ### Token-2022 (Ekstensi Token) Varian SPL Token Program yang mendukung ekstensi opsional (misalnya, biaya transfer, transfer rahasia, token berbunga, token yang tidak dapat ditransfer). Token-2022 berjalan sebagai program onchain terpisah dengan ID programnya sendiri, tetapi dirancang sebagai penerus yang kompatibel dengan Token Program klasik, sehingga SDK biasanya dapat menangani keduanya. Mint harus dibuat di bawah program Token-2022 agar dapat menggunakan ekstensi. Lihat postingan blog [Apa Itu Ekstensi Token?](https://www.helius.dev/blog/what-is-token-2022). ### Bukti Validitas Bukti zero-knowledge [Groth16](#groth16) berukuran konstan bahwa konten yang diklaim suatu akun terkompresi pernah ada dalam [Pohon Status](#pohon-status) pada akar tertentu. Program [ZK Compression](#zk-compression) memerlukan bukti validitas setiap kali akun terkompresi dibaca atau diubah; bukti tersebut memungkinkan program memverifikasi status offchain tanpa mengharuskan validator menyimpan data secara onchain. [Photon](#photon) menyediakan bukti validitas kepada pemanggil melalui metode RPC [`getValidityProof`](/docs/id/api-reference/zk-compression/getvalidityproof). Bukti validitas membedakan ZK Compression dari [NFT terkompresi](#nft-terkompresi-cnft): cNFT menggunakan bukti Merkle biasa (daftar hash sibling dari daun ke akar yang bertambah sesuai kedalaman pohon), sedangkan bukti ZK berukuran konstan milik ZK Compression tidak mengungkap jalur atau status pohon di sekitarnya. Lihat postingan blog [Pengembang Solana: ZK Compression](https://www.helius.dev/blog/solana-builders-zk-compression). ### ZK Compression ZK Compression adalah primitif Solana yang dikembangkan oleh Helius dan Light Protocol, yang secara drastis mengurangi biaya penyimpanan onchain dengan mengomit data akun ke log transaksi dalam ledger dan hanya menyimpan sidik jari hash dalam status validator. Integritas kriptografis dipertahankan melalui bukti zero-knowledge Groth16 berukuran konstan yang dihasilkan dari data transaksi terindeks. Primitif ini berbeda dari NFT terkompresi, yang menggunakan pohon Merkle konkuren tanpa bukti zero-knowledge. Lihat [ZK Compression](/docs/id/api-reference/zk-compression) dan postingan blog [Pengembang Solana: ZK Compression](https://www.helius.dev/blog/solana-builders-zk-compression) untuk pembahasan lebih mendalam. *** ## Konektivitas dan Streaming ### Geyser Sistem plugin Solana untuk melakukan streaming perubahan status validator — akun, transaksi, slot, blok — kepada konsumen eksternal secara real-time. Validator memuat plugin Geyser sebagai pustaka dinamis; plugin menerima pembaruan status saat validator memprosesnya, sehingga polling RPC untuk perubahan tidak diperlukan. Yellowstone gRPC — plugin Geyser yang dominan — mengekspos pembaruan tersebut melalui gRPC. [LaserStream](#laserstream) Helius mengimplementasikan antarmuka Yellowstone gRPC dengan fitur tambahan seperti pemutaran ulang historis (hingga \~48 jam, \~691.200 slot pada kecepatan jaringan saat ini) dan failover multiwilayah. ### gRPC gRPC adalah protokol RPC biner serbaguna dan berperforma tinggi (akronim rekursif untuk "gRPC Remote Procedure Call"). Dalam konteks Solana, "gRPC" biasanya mengacu pada Yellowstone gRPC — antarmuka streaming yang dibangun pada sistem plugin Geyser Solana dan mengekspos pembaruan akun serta transaksi melalui gRPC. Layanan [LaserStream](/docs/id/laserstream) Helius dibangun di atas antarmuka berbasis Yellowstone dengan fitur tambahan seperti pemutaran ulang historis, failover multiwilayah, dan infrastruktur terkelola. ### RPC RPC adalah singkatan dari Remote Procedure Call, yaitu pola umum untuk memanggil metode server seolah-olah metode tersebut merupakan fungsi lokal. Di Solana, "RPC" paling sering mengacu pada node RPC — node yang melacak status Solana tetapi tidak berpartisipasi dalam konsensus, serta dikhususkan untuk melayani permintaan data (yaitu status akun, riwayat transaksi, dan pengiriman transaksi) melalui antarmuka JSON-RPC. Sebaliknya, validator menghasilkan blok dan memberikan suara atasnya. Layanan RPC Helius adalah armada node RPC yang tersebar secara global dan dioptimalkan untuk beban kerja produksi. Lihat postingan blog [Node Solana — Pengantar tentang RPC Solana, Validator, dan Penyedia RPC](https://www.helius.dev/blog/solana-nodes-a-primer-on-solana-rpcs-validators-and-rpc-providers) untuk pembahasan lebih mendalam. ### Webhook Webhook adalah permintaan HTTP POST yang dikirim server ke URL penerima ketika peristiwa yang dilanggani terjadi — HTTP "terbalik", yaitu server yang memulai panggilan. [Webhook](/docs/id/webhooks) Helius mengirim peristiwa onchain Solana (transfer, penjualan NFT, aktivitas program khusus) ke endpoint terdaftar, sehingga polling tidak diperlukan. ### WebSocket (WSS) WebSocket adalah koneksi TCP dua arah persisten yang ditingkatkan dari HTTP dan digunakan untuk streaming data Solana berbasis push tanpa permintaan HTTP berulang. WSS (WebSocket Secure) adalah protokol yang sama yang berjalan melalui TLS dan merupakan varian yang digunakan untuk koneksi Solana produksi. [LaserStream WebSocket](/docs/id/rpc/websocket) — produk streaming WebSocket Helius yang mencakup metode Solana standar serta ekstensi Helius seperti `transactionSubscribe` — menggunakan WSS. *** ## Ekosistem ### Anchor Anchor adalah framework Rust untuk membangun program Solana dengan cepat dan aman. Framework ini menangani kode boilerplate seperti serialisasi akun, validasi, dan dispatch instruksi melalui makro prosedural, sehingga pengembang dapat berfokus pada logika program, bukan detail tingkat rendah. Sebagian besar pengembang Solana menggunakan Anchor alih-alih menulis program dalam Rust native. Lihat postingan blog [Pengantar Anchor: Panduan Pemula untuk Membangun Program Solana](https://www.helius.dev/blog/an-introduction-to-anchor-a-beginners-guide-to-building-solana-programs) untuk pembahasan lebih mendalam. ### IDL IDL adalah singkatan dari Interface Definition Language. IDL adalah skema JSON yang menjelaskan instruksi, akun, dan tipe data program Solana; klien menggunakannya untuk membuat transaksi dan mendekode data program tanpa menyusun tata letak instruksi secara manual. Anchor menghasilkan IDL secara otomatis dan secara default memublikasikannya secara onchain dalam akun khusus agar dapat ditemukan oleh publik. ### Jito Perusahaan dalam ekosistem Solana yang mengoperasikan mesin blok dominan jaringan — lapisan infrastruktur MEV (maximal extractable value) yang menerima bundel transaksi (kelompok transaksi atomik yang semuanya dieksekusi bersama atau tidak sama sekali) dan memungkinkan pencari membayar tip kepada validator agar pendaratannya diprioritaskan. Klien validator Jito-Solana adalah fork Agave dengan mesin blok yang terintegrasi. Penyertaan bundel memerlukan tip minimum 10.000 lamport, dan Jito-Relayer menahan trafik masuk selama \~200 md untuk memungkinkan lelang bundel offchain. [Sender](#sender) Helius mengirimkan transaksi melalui koneksi berbobot stake dan mesin blok Jito secara bersamaan, lalu menggunakan jalur mana pun yang mendarat lebih dahulu. Lihat postingan blog [MEV Solana: Sebuah Pengantar](https://www.helius.dev/blog/solana-mev-an-introduction). ### Light Protocol Tim protokol Solana yang bersama Helius mengembangkan [ZK Compression](#zk-compression). Helius membangun pengindeks kanonis ([Photon](#photon)) dan mengoperasikan RPC publik; Light Protocol membangun program onchain dan stack pembuktian yang menjadi dependensi pengindeks. Lihat [github.com/Lightprotocol/light-protocol](https://github.com/Lightprotocol/light-protocol). ### Photon Pengindeks sumber terbuka [ZK Compression](#zk-compression) yang dibangun oleh Helius. Data akun terkompresi berada dalam log transaksi Solana, bukan status akun, sehingga validator tidak mengeksposnya melalui RPC standar — Photon mengurai transaksi Solana, merekonstruksi status akun terkompresi, dan menyajikannya melalui antarmuka JSON-RPC yang menyerupai RPC native Solana ditambah metode khusus ZK Compression seperti [`getCompressedAccount`](/docs/id/api-reference/zk-compression/getcompressedaccount) dan [`getValidityProof`](/docs/id/api-reference/zk-compression/getvalidityproof). Pengembang dapat meng-host sendiri dari [github.com/helius-labs/photon](https://github.com/helius-labs/photon) atau menggunakan endpoint Helius yang di-host. Lihat [ZK Compression](/docs/id/api-reference/zk-compression).