getTransactionsForAddress và dữ liệu lưu trữ nhanh hơn tới 10 lần

Những thách thức khi truy vấn dữ liệu lịch sử trên Solana

Sổ cái của Solana lưu giữ mọi giao dịch từng được gửi on-chain. Dữ liệu lịch sử này bao gồm mọi hoạt động mint, chuyển, swap và tương tác với chương trình đã diễn ra kể từ khối khởi nguyên.

Tính đến nay, Solana đã tạo ra hơn 375 triệu block, và toàn bộ lịch sử giao dịch chưa cắt tỉa từ block khởi nguyên đến hiện tại có kích thước hàng trăm terabyte. 

Truy cập dữ liệu này một cách nhanh chóng và đáng tin cậy là điều thiết yếu đối với gần như mọi đội ngũ đang phát triển trên Solana hiện nay. Các phương thức lưu trữ của Solana hỗ trợ mọi thứ, từ tab lịch sử giao dịch trong ví yêu thích của bạn đến trình khám phá và bảng điều khiển danh mục đầu tư bạn thường dùng. 

Trước đây, các nhà phát triển chỉ có hai lựa chọn để truy vấn dữ liệu lưu trữ, và cả hai đều rất bất tiện: 

1. getBlock
2. getSignaturesForAddress kết hợp với getTransaction

Sử dụng getBlock quá chậm

Trước tiên, các nhà phát triển có thể thử truy vấn getBlock để truy xuất bổ sung dữ liệu. Mặc dù có thể thực hiện được, phương thức này tốn thời gian, chi phí và tài nguyên một cách không cần thiết:

1. Gọi getBlocks để tìm các block đã xác nhận trong phạm vi slot của bạn
2. Gọi getBlock trên từng block để lấy đầy đủ chi tiết giao dịch, chữ ký hoặc tài khoản
3. Phân tích mọi dữ liệu liên quan từ block và lưu vào cơ sở dữ liệu của bạn
4. Lặp lại cho đến khi xử lý xong tất cả block

Mặc dù phương thức getBlock hoạt động tốt với các chương trình có lưu lượng cao (ví dụ: lập chỉ mục các token phổ biến như USDC hoặc các chương trình Solana như Pump.fun), việc dùng phương thức này cho các tập dữ liệu nhỏ, cụ thể là không thực tế.

Lặp getSignaturesForAddress và getTransaction

Sử dụng getSignaturesForAddress (gSFA) cùng với getTransaction là một cách phổ biến khác để truy xuất bổ sung dữ liệu.

Cách tiếp cận “vòng lặp N+1” này liên tục lấy chữ ký giao dịch, thường là 1.000 chữ ký mỗi lần, rồi thực hiện các lệnh gọi RPC theo lô để lấy chi tiết của từng giao dịch. 

Do số lượng yêu cầu RPC rất lớn, các nhà phát triển cần triển khai cơ chế chờ tăng dần theo cấp số nhân và logic thử lại để tránh chạm giới hạn tốc độ cũng như bỏ sót dữ liệu. 

Mặc dù dùng gSFA và getTransaction linh hoạt hơn getBlock, cách này vẫn tốn kém, phức tạp và dễ phát sinh lỗi ở quy mô lớn.

Lợi ích của getTransactionForAddress

Phương thức RPC getTransactionsForAddress mới kết hợp getSignaturesForAddress với getTransaction trong một lệnh gọi duy nhất, đồng thời cung cấp các tính năng mạnh mẽ giúp việc xây dựng chỉ mục và truy vấn dữ liệu lịch sử trở nên dễ dàng, nhanh chóng hơn.

Dưới đây là các tính năng chính:

1. Tìm kiếm ngược

Các phương thức RPC lưu trữ hiện có, chẳng hạn như gSFA, yêu cầu nhà phát triển bắt đầu từ giao dịch mới nhất rồi lần ngược về trước.

Với getTransactionForAddress, giờ đây các nhà phát triển có thể chọn thứ tự sắp xếp tăng dần (tức là theo trình tự thời gian, cũ nhất trước) hoặc giảm dần (tức là mới nhất trước). 

Khi kết hợp với các bộ lọc theo thời gian, nhà phát triển có thể dùng getTransactionForAddress để truy vấn bất kỳ phần nào trong lịch sử Solana, từ bất kỳ thời điểm nào và theo bất kỳ thứ tự nào.

Ví dụ: Orb, trình khám phá block Solana mới của chúng tôi, sử dụng phương thức RPC getTransactionsForAddress để vận hành bộ lọc “Hiển thị cũ nhất trước”:

Nếu muốn truy vấn cùng dữ liệu này bằng getSignaturesForAddress và getTransaction, bạn sẽ cần:

1. Tìm dấu thời gian chính xác tương ứng với giao dịch đầu tiên
2. Tìm chữ ký giao dịch tương ứng với ngày bắt đầu
3. Lặp ngược từ chữ ký đó bằng before: lastSignature 
4. Tiếp tục lặp cho đến khi blockTime của các chữ ký được trả về đạt đến ngày kết thúc
5. Viết cơ chế chờ và logic thử lại để tránh chạm giới hạn tốc độ và bỏ sót dữ liệu

Quy trình này không chỉ truy vấn chậm mà còn khó thiết lập và dễ phát sinh lỗi.

2. Lọc nâng cao

Với phương thức getTransactionsForAddress mới, các nhà phát triển có thể lọc theo khoảng thời gian (tức là dấu thời gian Unix), slot và trạng thái (ví dụ: thành công hoặc thất bại). Các bộ lọc này giúp bạn kiểm soát chính xác và chi tiết hơn để truy vấn đúng dữ liệu mình cần.

Ví dụ: bộ lọc theo thời gian này sử dụng dấu thời gian Unix để nhận tất cả giao dịch thành công diễn ra từ 12:00 sáng (GMT) ngày 1 tháng 1 năm 2025 đến 12:00 sáng (GMT) ngày 1 tháng 10 năm 2025.

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

3. Phân trang dựa trên con trỏ

Khi cần truy vấn nhiều giao dịch hơn giới hạn mặc định của gTFA (1.000 chữ ký hoặc 100 bản ghi kèm đầy đủ chi tiết giao dịch), bạn có thể dùng paginationToken trong phản hồi để tải trang tiếp theo. paginationToken là một chuỗi đơn giản có định dạng "slot:position", cho API biết cần tiếp tục từ đâu.

Ví dụ: truy vấn này sử dụng paginationToken (một con trỏ) để quét lịch sử của địa chỉ theo từng lô 100 bản ghi.

// 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);

Hệ thống lưu trữ Solana mới

Bên cạnh phương thức getTransactionsForAddress mới, chúng tôi còn ra mắt một hệ thống lưu trữ hoàn toàn mới, được xây dựng lại từ đầu để tối ưu hóa các đường định tuyến và lưu trữ của kho dữ liệu.

Hệ thống mới được bật cho tất cả phương thức Solana RPC lưu trữ (ví dụ: getTransaction, getBlock, getInflationReward) và dành cho người dùng ở mọi gói miễn phí lẫn trả phí.

Điều này có nghĩa là mọi phương thức lưu trữ trên mọi gói hiện đều nhanh hơn 2–10 lần — độ trễ thấp hơn, hiệu năng tốt hơn và không cần thay đổi mã.

Bắt đầu

Phương thức RPC getTransactionsForAddress được cung cấp công khai từ hôm nay trên tất cả các gói trả phí và có thể dùng với URL Helius RPC hiện tại của bạn. Phương thức gTFA tốn 100 credit cho mỗi lệnh gọi và thuộc nhóm giới hạn tốc độ RPC của bạn.

Để tìm hiểu cách phương thức này hoạt động và bắt đầu sử dụng, hãy đọc tài liệu tham khảo API và làm theo hướng dẫn bắt đầu nhanh về getTransactionsForAddress.