Skip to main content
Phương thức RPC getInflationReward cho phép bạn truy vấn phần thưởng lạm phát (thường được gọi là phần thưởng staking) đã được ghi có cho một hoặc nhiều địa chỉ trong một epoch cụ thể. Điều này hữu ích để xác minh phần thưởng mà các tài khoản stake hoặc bất kỳ tài khoản nào có thể đã nhận phần thưởng lạm phát đã nhận được.
Tránh gửi theo lô để có hiệu suất tốt hơnViệc gửi các phương thức lưu trữ theo lô làm tăng đáng kể độ trễ. Không cho phép các lô có hơn 10 yêu cầu.

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

  • Xác minh phần thưởng staking: Kiểm tra xem một tài khoản stake có nhận được phần thưởng dự kiến trong một epoch trước đó hay không.
  • Theo dõi lịch sử phần thưởng: Truy vấn phần thưởng của nhiều epoch để xây dựng lịch sử cho một địa chỉ.
  • Kiểm tra khoản thanh toán của trình xác thực: Trình xác thực có thể sử dụng phương thức này để xác minh việc phân phối phần thưởng (mặc dù phần thưởng được trả cho tài khoản stake chứ không trả trực tiếp cho danh tính trình xác thực).

Tham số yêu cầu

Phương thức này nhận hai tham số chính:
  1. addresses (mảng chuỗi): Danh sách khóa công khai được mã hóa base-58 của các tài khoản bạn muốn truy vấn. Số lượng địa chỉ tối đa được phép có thể khác nhau tùy theo nhà cung cấp RPC (ví dụ: Helius cho phép tối đa 1005 địa chỉ đối với các gói trả phí).
  2. config (đối tượng, không bắt buộc): Đối tượng cấu hình có các trường không bắt buộc sau:
    • commitment (chuỗi, không bắt buộc): Chỉ định mức cam kết. Mặc định là finalized nếu không được cung cấp.
    • epoch (số nguyên, không bắt buộc): Số epoch cần lấy phần thưởng. Nếu bỏ qua, nút RPC thường sẽ sử dụng epoch vừa hoàn tất gần đây nhất mà phần thưởng đã được phân phối.
    • minContextSlot (số nguyên, không bắt buộc): Slot tối thiểu mà tại đó yêu cầu có thể được đánh giá. Điều này đảm bảo truy vấn được thực hiện dựa trên trạng thái sổ cái đã xử lý ít nhất đến slot này.

Cấu trúc phản hồi

Trường result của phản hồi JSON-RPC sẽ là một mảng tương ứng với mảng addresses đầu vào. Mỗi phần tử trong mảng kết quả sẽ là một trong các giá trị sau:
  • Một đối tượng chứa thông tin chi tiết về phần thưởng lạm phát nếu địa chỉ đã nhận được phần thưởng trong epoch được chỉ định.
  • null nếu địa chỉ không nhận được phần thưởng lạm phát trong epoch đó hoặc nếu tài khoản không tồn tại.
Đối tượng phần thưởng có các trường sau:
  • epoch (u64): Epoch mà phần thưởng này được ghi có.
  • effectiveSlot (u64): Slot mà phần thưởng được áp dụng và bắt đầu có hiệu lực.
  • amount (u64): Số tiền thưởng, tính bằng lamport.
  • postBalance (u64): Số dư của tài khoản, tính bằng lamport, sau khi phần thưởng được ghi có.
  • commission (u8 | undefined): Đối với tài khoản biểu quyết, đây là tỷ lệ hoa hồng (0-100) mà trình xác thực nhận tại thời điểm phần thưởng được ghi có. Giá trị này sẽ là undefined đối với các tài khoản không phải tài khoản biểu quyết.

Ví dụ

1. Lấy phần thưởng lạm phát cho một địa chỉ (epoch trước)

Ví dụ này lấy phần thưởng lạm phát của một địa chỉ cụ thể trong epoch vừa hoàn tất gần đây nhất.

2. Lấy phần thưởng lạm phát cho nhiều địa chỉ trong một epoch cụ thể

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

  • Xác định đúng epoch: Phần thưởng được ghi có một lần trong mỗi epoch. Hãy đảm bảo bạn đang truy vấn đúng số epoch.
  • Thời điểm trao thưởng: Phần thưởng lạm phát được tính vào cuối một epoch và áp dụng vào đầu epoch tiếp theo. effectiveSlot cho biết thời điểm điều này xảy ra.
  • Kết quả null: Kết quả null cho một địa chỉ có nghĩa là không tìm thấy phần thưởng cho địa chỉ đó trong epoch được chỉ định. Nguyên nhân có thể là tài khoản không đủ điều kiện (ví dụ: tài khoản stake không có đủ lượng stake), phần thưởng bằng 0 hoặc tài khoản không tồn tại tại thời điểm đó.
  • Giới hạn tốc độ: Hãy lưu ý đến giới hạn tốc độ của nhà cung cấp RPC, đặc biệt khi truy vấn số lượng lớn địa chỉ.
Hướng dẫn này giúp bạn sử dụng phương thức getInflationReward để truy xuất và xác minh chính xác phần thưởng staking trên mạng Solana.