getTransactionsForAddress dan Data Arsip hingga 10x Lebih Cepat

Tantangan dalam Mengkueri Data Historis di Solana

Ledger Solana menyimpan setiap transaksi yang pernah dikirim secara on-chain. Data historis ini mencakup setiap mint, transfer, swap, dan interaksi program yang terjadi sejak genesis.

Hingga saat ini, Solana telah menghasilkan lebih dari 375 juta blok, dan riwayat transaksi lengkapnya yang belum dipangkas, mulai dari blok genesis hingga saat ini, berukuran ratusan terabyte. 

Akses yang cepat dan andal ke data ini sangat penting bagi hampir setiap tim yang kini membangun di Solana. Metode arsip Solana mendukung semuanya, mulai dari tab riwayat transaksi di dompet favorit Anda hingga explorer dan dasbor portofolio favorit Anda. 

Sebelumnya, developer hanya memiliki dua opsi untuk mengkueri data arsip, dan keduanya merepotkan: 

1. getBlock
2. getSignaturesForAddress ditambah getTransaction

Menggunakan getBlock Terlalu Lambat

Pertama, developer dapat mencoba mengkueri getBlock untuk mengisi data lama. Meskipun memungkinkan, metode ini memerlukan terlalu banyak waktu, mahal, dan menghabiskan banyak sumber daya:

1. Panggil getBlocks untuk menemukan blok yang telah dikonfirmasi dalam rentang slot Anda
2. Panggil getBlock pada setiap blok untuk mendapatkan detail transaksi lengkap, tanda tangan, atau akun
3. Urai semua data yang relevan dari blok dan simpan di basis data Anda
4. Ulangi hingga semua blok selesai diproses

Meskipun metode getBlock berfungsi dengan baik untuk program yang sibuk (misalnya, mengindeks token populer seperti USDC atau program Solana seperti Pump.fun), penggunaannya untuk set data yang kecil dan spesifik tidak praktis.

Melakukan Perulangan getSignaturesForAddress dan getTransaction

Menggunakan getSignaturesForAddress (gSFA) bersama getTransaction adalah cara umum lainnya untuk mengisi data lama.

Pendekatan “perulangan N+1” ini mengambil tanda tangan transaksi berulang kali, biasanya 1.000 sekaligus, lalu membuat panggilan RPC batch untuk mengambil detail setiap transaksi. 

Karena jumlah permintaan RPC yang sangat besar, developer perlu menerapkan exponential backoff dan logika percobaan ulang agar tidak mencapai batas laju dan kehilangan data. 

Meskipun penggunaan gSFA dan getTransaction lebih fleksibel daripada getBlock, pendekatan ini tetap mahal, rumit, dan rentan terhadap kesalahan dalam skala besar.

Manfaat getTransactionForAddress

Metode RPC getTransactionsForAddress yang baru menggabungkan getSignaturesForAddress dengan getTransaction dalam satu panggilan dengan fitur canggih yang membuat pembuatan indeks dan pengkuerian data historis lebih mudah serta cepat.

Berikut fitur-fitur utamanya:

1. Pencarian Terbalik

Metode RPC arsip yang ada, seperti gSFA, mengharuskan developer memulai dari transaksi terbaru dan menelusuri ke belakang.

Dengan getTransactionForAddress, developer kini dapat memilih urutan menaik (yaitu, secara kronologis, yang terlama terlebih dahulu) atau menurun (yaitu, yang terbaru terlebih dahulu). 

Jika digabungkan dengan filter berbasis waktu, developer dapat menggunakan getTransactionForAddress untuk mengkueri bagian mana pun dari riwayat Solana, dari titik waktu mana pun, dalam urutan apa pun.

Sebagai contoh, Orb, explorer blok Solana baru kami, menggunakan metode RPC getTransactionsForAddress untuk mendukung filter “Tampilkan yang terlama terlebih dahulu”:

Jika ingin mengkueri data yang sama menggunakan getSignaturesForAddress dan getTransaction, Anda harus:

1. Menemukan stempel waktu yang tepat untuk transaksi pertama
2. Menemukan tanda tangan transaksi yang sesuai dengan tanggal mulai Anda
3. Melakukan perulangan mundur dari tanda tangan tersebut menggunakan before: lastSignature 
4. Terus melakukan perulangan hingga blockTime dari tanda tangan yang dikembalikan mencapai tanggal akhir
5. Menulis logika backoff dan percobaan ulang agar tidak mencapai batas laju dan kehilangan data

Proses ini tidak hanya lambat untuk dikueri, tetapi juga merepotkan untuk disiapkan dan rentan terhadap kesalahan.

2. Pemfilteran Lanjutan

Dengan metode getTransactionsForAddress yang baru, developer dapat memfilter berdasarkan rentang waktu (yaitu, stempel waktu Unix), slot, dan status (misalnya, berhasil atau gagal). Filter ini memberi Anda kendali yang lebih presisi dan terperinci untuk mengkueri data yang benar-benar Anda perlukan.

Sebagai contoh, filter berbasis waktu ini menggunakan stempel waktu Unix untuk menerima semua transaksi berhasil yang terjadi antara 1 Januari 2025 pukul 00.00 (GMT) dan 1 Oktober 2025 pukul 00.00 (GMT).

// Time range with successful transactions only
"filters": {
  "blockTime": {
    "gte": 1767225600,
    "lte": 1759363200
  },
  "status": "succeeded"
}

3. Paginasi Berbasis Kursor

Saat Anda perlu mengkueri lebih banyak transaksi daripada batas default gTFA (1.000 tanda tangan atau 100 catatan dengan detail transaksi lengkap), Anda dapat menggunakan paginationToken dari respons untuk mengambil halaman berikutnya. paginationToken adalah string sederhana dalam format "slot:position" yang memberi tahu API dari mana proses harus dilanjutkan.

Sebagai contoh, kueri ini menggunakan paginationToken (sebuah kursor) untuk memindai riwayat alamat dalam batch berisi 100.

// First request
let paginationToken = null;
let allTransactions = [];

const getNextPage = async (paginationToken = null) => {
  const params = [
    'ADDRESS',
    {
      transactionDetails: 'signatures',
      limit: 100,
      ...(paginationToken && { paginationToken })
    }
  ];

  const response = await fetch(rpcUrl, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 1,
      method: 'getTransactionsForAddress',
      params
    })
  });

const data = await response.json();
  return data.result;
};

// Paginate through all results
do {
  const result = await getNextPage(paginationToken);
  allTransactions.push(...result.data);
  paginationToken = result.paginationToken;

  console.log(`Fetched ${result.data.length} transactions, total: ${allTransactions.length}`);
} while (paginationToken);

Sistem Arsip Solana Baru

Selain metode getTransactionsForAddress yang baru, kami meluncurkan sistem arsip baru yang dibangun ulang dari awal untuk mengoptimalkan router dan jalur penyimpanan arsip.

Sistem baru ini diaktifkan untuk semua metode RPC arsip Solana (misalnya, getTransaction, getBlock, getInflationReward) dan tersedia bagi pengguna di semua paket gratis maupun berbayar.

Artinya, setiap metode arsip di setiap paket kini 2–10x lebih cepat — latensi lebih rendah, performa lebih baik, dan tidak memerlukan perubahan kode.

Mulai sekarang

Metode RPC getTransactionsForAddress tersedia untuk publik mulai hari ini di semua paket berbayar dan dapat digunakan dengan URL RPC Helius Anda yang sudah ada. Metode gTFA memerlukan 100 kredit per panggilan dan termasuk dalam grup batas laju RPC Anda.

Untuk mempelajari cara kerja metode ini dan mulai menggunakannya, baca referensi API dan ikuti panduan mulai cepat getTransactionsForAddress kami.