Skip to main content
Saat membangun aplikasi yang perlu merespons perubahan on-chain, melakukan polling pada endpoint RPC untuk mendapatkan pembaruan akun tidak efisien dan lambat. Langganan akun mengatasi masalah ini dengan mengirimkan pembaruan real-time tentang perubahan status akun langsung ke aplikasi Anda. Panduan ini membahas semua hal yang perlu Anda ketahui tentang langganan akun: definisinya, cara kerjanya, dan cara mengoptimalkannya untuk kasus penggunaan spesifik Anda.

Konteks model akun

Lewati bagian ini jika Anda sudah memahami akun Solana dan strukturnya.
Solana menggunakan model berbasis akun, tempat setiap bagian data berada dalam sebuah akun—kontainer yang menyimpan data dan metadata. Setiap akun memiliki:
  • Data: Byte aktual yang menyimpan status program, saldo token, atau informasi lainnya
  • Pemilik: Program yang mengontrol akun ini dan dapat mengubah datanya
  • Lamport: Saldo SOL akun untuk pengecualian biaya sewa
  • Dapat dieksekusi: Menunjukkan apakah akun ini berisi kode program
Program tidak memiliki status—program tidak menyimpan data secara internal. Sebagai gantinya, program membuat dan mengelola akun terpisah untuk menyimpan statusnya. Saat berinteraksi dengan program, Anda meneruskan akun yang harus dibaca atau ditulis oleh program tersebut. Desain ini menjadikan langganan akun sangat berguna: Anda dapat memantau perubahan pada akun tertentu, semua akun yang dimiliki oleh suatu program, atau akun yang cocok dengan kriteria tertentu.

Langganan akun dasar

Mari mulai dengan contoh sederhana yang berlangganan perubahan pada akun token. Skrip ini akan memberi tahu Anda setiap kali saldo token berubah:
Saat menjalankan langganan dasar ini, Anda akan melihat pembaruan akun real-time dialirkan ke konsol:
Apa yang baru saja terjadi? Langganan kita berfungsi dengan sempurna! Kita meminta Laserstream memberi tahu kita tentang perubahan akun token, lalu layanan tersebut mengirimkan pembaruan tentang akun BKMHWYLAX4un3HUbR7a3u9jPmzCiLNa4mSj1RiX11eWF. Akun ini memiliki:
  • 2.039.280 lamport (saldo ~0,002 SOL—ini adalah jumlah yang dikecualikan dari biaya sewa untuk akun token ini)
  • Program pemilik TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA (ini adalah program SPL Token)
  • Tanda tangan transaksi 5C9Hr5nG2j8eQz6inxPmfyjbYdmXddzUDyR1iQgEnjYQ3RNvuP4Zzc8t1enLNy7Rk8KNCtQPEQztENYWxkt9GaVD yang menunjukkan transaksi tertentu yang menyebabkan akun ini berubah
  • Slot 352366983 yang menunjukkan kapan pembaruan ini terjadi di blockchain
  • Kolom data yang berisi 165 byte data akun yang dienkode sebagai base58

Memahami pemfilteran akun dengan datasize

Kolom data sangat penting karena berisi struktur akun token yang sebenarnya. Mari gunakan pemahaman ini untuk pemfilteran akun cerdas.

Mengapa menggunakan pemfilteran datasize?

Untuk memahami alasan kita memerlukan pemfilteran, mari pahami terlebih dahulu apa sebenarnya akun token itu. Untuk setiap token yang dimiliki dompet, terdapat akun terpisah secara on-chain. Jika dompet Anda memiliki 3 token berbeda (USDC, BONK, dan SOL), sebenarnya Anda memiliki 1 akun dompet (akun SOL utama Anda) ditambah 3 akun token (satu untuk setiap jenis token). Setiap akun token berukuran tepat 165 byte dan menyimpan: token yang dimilikinya (alamat mint), pemiliknya (alamat dompet Anda), dan jumlah token yang dikandungnya. Token Program memiliki jutaan akun di Solana, tetapi tidak semuanya merupakan “akun token” yang menyimpan saldo pengguna. Berikut yang terjadi dengan dan tanpa pemfilteran: Tanpa pemfilteran—Banjir data:
Ini berlangganan SEMUA akun yang dimiliki Token Program, yang mencakup:
  • Akun token (165 byte) - Saldo pengguna: jutaan akun
  • Akun mint (82 byte) - Definisi token: ratusan ribu akun
  • Akun multisig (355 byte) - Kontrol dompet bersama: puluhan ribu akun
  • Akun Associated Token Program (berbagai ukuran) - jutaan akun
Hasil: Aplikasi Anda terus-menerus menerima jutaan pembaruan akun, yang sebagian besar tidak Anda perlukan.
Dengan pemfilteran cerdas—Presisi tinggi:
Ini menyaring hasil agar hanya mencakup akun berukuran 165 byte, yang secara khusus merupakan akun saldo token pengguna—tepat seperti yang Anda perlukan untuk melacak transfer token, perubahan saldo, dan pembaruan portofolio. Perbedaannya:
  • Tanpa pemfilteran: Jutaan pembaruan akun (pembuatan mint, perubahan multisig, dan sebagainya)
  • Dengan pemfilteran datasize: Hanya perubahan saldo token
Ini mengurangi derau secara signifikan karena hanya berfokus pada akun yang benar-benar merepresentasikan kepemilikan token pengguna.

Dari mana asal ukuran 165 byte?

Angka ini bukan muncul begitu saja—angka ini berasal dari struktur akun program SPL Token. Dengan melihat kode sumbernya, kita dapat melihat bahwa struct Account menetapkan ukuran tepat 165 byte:
Ukuran tetap ini memungkinkan kita memfilter akun token standar secara tepat dan mengecualikan:
  • Akun mint (82 byte)
  • Akun multisig (355 byte)
  • Akun program associated token account
  • Akun terkait token lainnya dengan ukuran berbeda
Untuk menghitung ukuran akun di program lain, lihat Referensi Ruang Anchor—referensi ini menunjukkan jumlah ruang yang digunakan oleh berbagai jenis data (Pubkey = 32 byte, u64 = 8 byte, dan sebagainya).

Mendekode struktur akun

Setelah memahami alasan kita memfilter akun berukuran 165 byte, mari dekode isi akun contoh kita:
Rincian 165 byte tersebut adalah:
  • Byte 0-31: Alamat mint (token yang disimpan akun ini)
  • Byte 32-63: Alamat pemilik (pihak yang memiliki akun token ini)
  • Byte 64-71: Jumlah token (jumlah token di dalam akun)
  • Byte 72-164: Metadata tambahan (delegasi, status, otoritas penutupan, dan sebagainya)
Pendekatan terstruktur ini memberikan presisi tinggi: kita hanya menerima pembaruan untuk akun token standar, tanpa derau dari jenis akun lainnya.

Menggabungkan filter: datasize + memcmp untuk presisi maksimal

Setelah mengetahui bahwa alamat mint berada pada byte 0-31, kita dapat membuat filter yang lebih spesifik. Misalnya, kita hanya ingin memantau akun token USDC. Kita dapat menggabungkan filter datasize dengan filter memcmp untuk menargetkan alamat mint yang tepat:
Strategi pemfilteran progresif:
  1. Filter pemilik: “Berikan akun yang dimiliki Token Program” (jutaan akun)
  2. Filter datasize: “Namun, hanya akun token standar berukuran 165 byte” (ratusan ribu)
  3. Filter memcmp: “Dan hanya akun yang menyimpan USDC” (ribuan)
Progresi dari cakupan luas ke spesifik ini merupakan kunci pemantauan akun yang efisien. Setiap filter mempersempit kumpulan hasil sehingga Anda hanya menerima pembaruan yang benar-benar Anda perlukan. Penting: Semua filter menggunakan logika AND—setiap kondisi harus terpenuhi agar pembaruan akun terpicu.

Membaca pembaruan akun USDC: Siapa, Berapa Banyak, Di Mana?

Sekarang mari lihat isi sebenarnya dari pembaruan yang telah difilter ini. Mari buat pemantau khusus USDC yang menjawab pertanyaan utama saat akun token berubah:
  • Siapa yang memiliki akun token ini?
  • Berapa banyak USDC yang sekarang tersimpan di dalamnya?
  • Di mana (akun spesifik mana) perubahan terjadi?
  • Kapan perubahan ini terjadi?
  • Transaksi apa yang menyebabkan perubahan tersebut?
Pembaruan akun mentah berisi data biner yang perlu kita dekode. Karena Solana menggunakan pengodean base58 untuk alamat dan tanda tangan, kita menggunakan fungsi bs58.encode() untuk mengonversi objek Buffer biner menjadi string yang dapat dibaca.
Saat menjalankan pemantau USDC ini, Anda akan melihat keluaran yang bersih dan terstruktur seperti berikut:
Setiap blok merepresentasikan akun USDC yang statusnya berubah. Akun pertama kini menyimpan 1.500 USDC, sedangkan akun kedua telah dikosongkan menjadi 0 USDC. Anda langsung mendapatkan saldo terkini setelah setiap transaksi, beserta akun spesifik yang berubah dan waktu terjadinya perubahan. Langganan akun menunjukkan hasil akhir dari hal yang terjadi pada setiap akun, bukan detail transaksinya. Jika perlu memahami konteks transaksi lengkap (siapa yang mengirim kepada siapa, biaya, dan sebagainya), Anda perlu mengambil transaksi lengkap menggunakan tanda tangan yang ditampilkan.

Referensi pemfilteran lengkap

Selain filter dasar owner, datasize, dan memcmp yang telah kita gunakan, langganan akun mendukung opsi pemfilteran tambahan untuk semakin mempersempit hasil Anda:

Pemfilteran akun tertentu

Pantau akun tertentu berdasarkan kunci publiknya:
Pendekatan ini cocok digunakan jika Anda mengetahui secara pasti akun yang penting bagi aplikasi—seperti memantau akun perbendaharaan aplikasi atau akun pengguna tertentu. Untuk kumpulan akun yang sangat besar, daftar pubkey eksplisit menjadi mahal—32 byte per akun dalam permintaan langganan. Untuk lebih dari ~10.000 akun, gunakan filter cuckoo terkompresi (~3–4 byte per akun) untuk melacak ratusan ribu akun dalam satu aliran. Tersedia di SDK Rust dan JavaScript.

Strategi pemfilteran gabungan

Kekuatan sebenarnya berasal dari penggabungan beberapa jenis filter. Berikut model mentalnya:
  1. Mulai dengan cakupan luas menggunakan owner - “Berikan semua akun yang dikelola oleh program ini”
  2. Filter berdasarkan struktur menggunakan datasize - “Namun, hanya akun dengan jenis spesifik ini”
  3. Targetkan data tertentu menggunakan memcmp - “Dan hanya akun yang berisi informasi spesifik ini”
  4. Pantau akun yang diketahui menggunakan account - “Atau cukup pantau akun tertentu yang saya perlukan ini”
Contohnya, memantau akun USDC bernilai tinggi:
Inti utamanya adalah setiap filter mengurangi volume pembaruan yang Anda terima. Tanpa pemfilteran, Anda mungkin menerima pembaruan akun dalam jumlah yang sangat besar. Dengan pemfilteran cerdas, Anda hanya mendapatkan pembaruan yang relevan dengan kasus penggunaan spesifik Anda.

Memahami gambaran besarnya

Bayangkan langganan akun sebagai pemantauan umpan langsung perubahan basis data. Status Solana pada dasarnya merupakan penyimpanan pasangan kunci-nilai berukuran sangat besar, dengan setiap akun sebagai satu entri. Saat program dieksekusi, program tersebut mengubah akun-akun ini. Langganan Anda memungkinkan Anda memantau perubahan pada entri tertentu secara real-time. Sistem pemfilteran bekerja seperti indeks basis data—Anda tidak sekadar memantau “semua perubahan”, tetapi “perubahan pada akun yang cocok dengan kriteria ini”. Hal ini memungkinkan Anda membangun aplikasi responsif yang langsung bereaksi terhadap peristiwa on-chain yang relevan tanpa membebani sistem dengan data yang tidak relevan.

Menerapkan pola ini pada program lain

Pendekatan yang telah kita pelajari dapat digunakan untuk program Solana apa pun. Berikut pola umumnya:
  1. Pelajari struktur akun - Periksa kode sumber atau dokumentasi program
  2. Mulai dengan pemfilteran pemilik - Targetkan program yang mengelola akun tersebut
  3. Terapkan filter struktural - Gunakan ukuran akun, pola data, atau karakteristik lain untuk mempersempit hasil ke jenis akun tertentu
  4. Tambahkan filter tertarget - Fokus pada akun, status, atau nilai data tertentu yang penting bagi aplikasi Anda