Cách sử dụng getAccountInfo

​

Các trường hợp sử dụng phổ biến

• Kiểm tra số dư SOL: Xác định số dư SOL gốc của bất kỳ tài khoản nào.
• Xác minh sự tồn tại của tài khoản: Kiểm tra xem tài khoản có khóa công khai đã cho đã được khởi tạo hay chưa (tức là có lamport hoặc dữ liệu).
• Kiểm tra tài khoản chương trình: Truy xuất dữ liệu được lưu trữ trong tài khoản do một chương trình sở hữu. Điều này rất quan trọng để hiểu trạng thái của chương trình.
• Xác định chủ sở hữu tài khoản: Tìm chương trình sở hữu một tài khoản. Điều này giúp xác định cách diễn giải dữ liệu của tài khoản hoặc liệu tài khoản có thuộc sở hữu của hệ thống hay không.
• Kiểm tra tài khoản có thể thực thi hay không: Xác định xem tài khoản có chứa một chương trình đã triển khai hay không.

​

Tham số

1. publicKey (chuỗi, bắt buộc): Khóa công khai được mã hóa base-58 của tài khoản cần truy vấn.
2. config (đối tượng, không bắt buộc): Đối tượng cấu hình có các trường sau:
   • commitment (chuỗi, không bắt buộc): Chỉ định mức cam kết dùng cho truy vấn. Giá trị mặc định là finalized.
     • finalized: Nút sẽ truy vấn khối mới nhất đã được cam kết vĩnh viễn. Nên ưu tiên giá trị này cho mã mới.
     • confirmed: Trong Alpenglow, tương đương với finalized; được giữ lại để đảm bảo khả năng tương thích.
     • processed: Nút sẽ truy vấn khối mới nhất của nó. Lưu ý rằng khối có thể chưa hoàn chỉnh.
   • encoding (chuỗi, không bắt buộc): Kiểu mã hóa cho dữ liệu tài khoản. Giá trị mặc định là base64.
     • base58 (chậm)
     • base64
     • base64+zstd (nếu dữ liệu được nén)
     • jsonParsed: Nếu dữ liệu tài khoản là trạng thái chương trình đã biết (ví dụ: tài khoản token, tài khoản stake), nút sẽ cố gắng phân tích dữ liệu thành cấu trúc JSON. Với tài khoản chương trình chung, dữ liệu thường được trả về dạng nhị phân (base64).
   • dataSlice (đối tượng, không bắt buộc): Giới hạn dữ liệu tài khoản được trả về ở một lát cắt cụ thể. Chỉ khả dụng với các kiểu mã hóa base58, base64 hoặc base64+zstd.
     • offset (số): Số byte tính từ đầu dữ liệu tài khoản để bắt đầu lát cắt.
     • length (số): Số byte cần trả về.
   • minContextSlot (số, không bắt buộc): Slot tối thiểu mà tại đó yêu cầu có thể được đánh giá.

​

Phản hồi

• context (đối tượng): Chứa siêu dữ liệu về yêu cầu.
  • slot (số): Slot tại đó thông tin được truy xuất.
  • apiVersion (chuỗi, không bắt buộc): Phiên bản API RPC.
• value (đối tượng | null): Nếu tài khoản không tồn tại, giá trị này sẽ là null. Nếu không, đây là một đối tượng chứa:
  • lamports (số): Số lamport (1 SOL = 1.000.000.000 lamport) thuộc sở hữu của tài khoản.
  • owner (chuỗi): Khóa công khai được mã hóa base-58 của chương trình sở hữu tài khoản này.
  • data (mảng | đối tượng | chuỗi): Dữ liệu được lưu trữ trong tài khoản. Định dạng phụ thuộc vào tham số encoding được dùng trong yêu cầu.
    • Với base64 (mặc định), base58, base64+zstd: Đây thường là một mảng [encoded_string, encoding_format], ví dụ: ["string_data", "base64"].
    • Với jsonParsed: Đây có thể là một đối tượng JSON nếu nút RPC có thể phân tích dữ liệu (ví dụ: đối với tài khoản SPL Token). Nếu không, giá trị có thể mặc định là ["", "base64"] hoặc giá trị tương tự nếu dữ liệu không được nhận dạng là một bố cục tiêu chuẩn.
  • executable (boolean): true nếu tài khoản chứa một chương trình; nếu không thì là false.
  • rentEpoch (số): Epoch tiếp theo mà tại đó tài khoản này sẽ phải trả phí thuê.
  • space (số, không bắt buộc): Độ dài dữ liệu tính bằng byte. (Lưu ý: Tài liệu chính thức của Solana liệt kê space và một số nhà cung cấp RPC có thể bao gồm trường này. Trường này biểu thị tổng dung lượng được phân bổ cho dữ liệu của tài khoản). Để biết thêm chi tiết về dữ liệu tài khoản và quá trình giải tuần tự hóa, hãy tham khảo hướng dẫn chi tiết của chúng tôi.

​

Ví dụ: Truy xuất thông tin tài khoản

curl https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY -X POST -H "Content-Type: application/json" -d \
'{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getAccountInfo",
  "params": [
    "9xQeWvG816bUx9EPjHmaT23yvVM2ZWbrrpZb9PusVFin",
    {
      "encoding": "jsonParsed"
    }
  ]
}'

const { Connection, PublicKey } = require('@solana/web3.js');

async function getAccountDetails() {
  const rpcUrl = 'https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY'; // Replace YOUR_API_KEY
  const connection = new Connection(rpcUrl, 'finalized');
  const accountPubKey = new PublicKey('9xQeWvG816bUx9EPjHmaT23yvVM2ZWbrrpZb9PusVFin');

  try {
    const accountInfo = await connection.getAccountInfo(accountPubKey);

    if (accountInfo === null) {
      console.log('Account not found.');
      return;
    }

    console.log('Account Info:');
    console.log(`   Lamports: ${accountInfo.lamports}`);
    console.log(`   Owner: ${accountInfo.owner.toBase58()}`);
    console.log(`   Executable: ${accountInfo.executable}`);
    console.log(`   Rent Epoch: ${accountInfo.rentEpoch}`);
    // Data is a Buffer, you might need to deserialize it based on the account type
    // console.log(`   Data: ${accountInfo.data.toString()}`); 
  } catch (error) {
    console.error('Error fetching account info:', error);
  }
}

getAccountDetails();

import { address, createSolanaRpc } from "@solana/kit";

const rpc_url = "https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY";
const rpc = createSolanaRpc(rpc_url);

const publicKey = address("vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg");
const accountInfo = await rpc.getAccountInfo(publicKey).send();

console.log("Account Info:", accountInfo);

use solana_client::nonblocking::rpc_client::RpcClient;
use solana_sdk::{commitment_config::CommitmentConfig, pubkey::Pubkey};
use anyhow::Result;
use std::str::FromStr;

#[tokio::main]
async fn main() -> Result<()> {
    let client = RpcClient::new_with_commitment(
        String::from("https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY"),
        CommitmentConfig::finalized()
    );
    let pubkey = Pubkey::from_str("vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg")?;
    let account = client.get_account(&pubkey).await?;

    println!("{:#?}", account);

    Ok(())
}

​

Mẹo dành cho nhà phát triển

• Hiệu suất: Đối với các ứng dụng cần kiểm tra thường xuyên nhiều tài khoản, hãy cân nhắc dùng getMultipleAccounts để gộp các yêu cầu theo lô và giảm số lượt trao đổi.
• Giải tuần tự hóa dữ liệu: Trường data thường cần được giải tuần tự hóa dựa trên cấu trúc dữ liệu của chương trình sở hữu. Thông thường, bạn cần các công cụ và thư viện dành riêng cho chương trình (ví dụ: thư viện SPL Token cho tài khoản token). Bài viết trên blog của chúng tôi về giải tuần tự hóa dữ liệu tài khoản cung cấp các kỹ thuật và ví dụ hữu ích.
• Giới hạn tốc độ: Hãy lưu ý đến giới hạn tốc độ của nút RPC, đặc biệt khi truy vấn số lượng lớn tài khoản hoặc gửi yêu cầu thường xuyên.
• Quản lý chi phí: getAccountInfo thường là một truy vấn có chi phí thấp, nhưng việc thăm dò thường xuyên có thể khiến chi phí tích lũy. Hãy tối ưu hóa cách thức truy vấn.
• Sử dụng jsonParsed hợp lý: Mặc dù jsonParsed có thể tiện lợi, tùy chọn này có thể không hỗ trợ tất cả các loại tài khoản và đầu ra của nó có thể thay đổi nếu chương trình cập nhật cấu trúc dữ liệu. Đối với các ứng dụng quan trọng, việc phân tích dữ liệu nhị phân theo bố cục đã biết sẽ ổn định hơn.
• Cân nhắc dataSlice: Nếu chỉ cần một phần nhỏ dữ liệu của tài khoản, hãy dùng dataSlice để giảm lượng dữ liệu được truyền và có thể giảm chi phí truy vấn.

​

Các phương thức liên quan