Chuyển đến nội dung chính
Sử dụng Sender Max (tiền tip tối thiểu: 0.001 SOL) để hành động dựa trên Preconfirmations. Một preconfirmation chỉ mang lại lợi ích nếu giao dịch của bạn được ghi nhận trước tiên — Sender Max là cách nhanh nhất để làm điều đó. Hãy xây dựng trên Sender Max ngay từ đầu để tận dụng toàn bộ lợi ích của Preconfirmations.

preconfSubscribe là gì?

preconfSubscribe là một phương thức WebSocket của Helius dùng để truyền trực tiếp Preconfirmations — các giao dịch được phân phối trước khi chúng được tập hợp thành các mục nhập và chia thành shred. Đây là tín hiệu giao dịch có độ trễ thấp nhất mà Helius cung cấp. Một gói đăng ký cung cấp cả preconfirmation của Helius, được phát ngay khi leader thực thi giao dịch và kèm theo trạng thái thực thi, lẫn preconfirmation BAM từ các trình xác thực chạy ứng dụng khách Block Assembly Marketplace của Jito, được phát khi trình xác thực cam kết thực thi giao dịch. Tính năng này có trên tất cả các gói trả phí — xem Bảng giá.
Luồng không liên tục. Phạm vi bao phủ tăng theo tỷ lệ stake chuyển tiếp đến Helius hoặc chạy BAM, vì vậy có thể sẽ có các slot không có thông báo — hãy xử lý các khoảng trống này một cách phù hợp. Xem Phạm vi bao phủ.
preconfSubscribe được cung cấp từ wss://beta.helius-rpc.com — endpoint Gatekeeper của Helius — thay vì mainnet.helius-rpc.com. Xác thực bằng khóa API của bạn dưới dạng tham số truy vấn.
Tên máy chủ beta đề cập đến quá trình triển khai Gatekeeper, không phải mức độ hoàn thiện của Preconfirmations. Preconfirmations được ra mắt trước tiên trên endpoint Gatekeeper; endpoint này sẽ trở thành endpoint tiêu chuẩn khi Helius di chuyển lưu lượng truy cập sang Gatekeeper.

Đăng ký

Gửi một yêu cầu JSON-RPC bằng phương thức preconfSubscribe. Máy chủ phản hồi bằng ID đăng ký, sau đó truyền phát một thông báo cho mỗi giao dịch. Truyền một bộ lọc tùy chọn làm phần tử params đầu tiên để chỉ nhận các giao dịch khớp; bỏ qua params để nhận toàn bộ luồng từ cả Helius và BAM.

Phản hồi đăng ký

Lưu result — đây là ID đăng ký bạn dùng để hủy đăng ký. Sau thông báo xác nhận này, các thông báo sẽ được truyền phát dưới dạng frame nhị phân (xem bên dưới).

Lọc

Theo mặc định, preconfSubscribe truyền phát mọi giao dịch từ cả hai nguồn. Để thu hẹp luồng, hãy truyền một đối tượng bộ lọc làm phần tử đầu tiên của params. Quá trình lọc diễn ra ở phía máy chủ, vì vậy bạn chỉ trả phí và nhận các giao dịch mình quan tâm.
Mọi trường đều là tùy chọn — trường bị thiếu có nghĩa là “không có ràng buộc” đối với vị từ đó, vì vậy bộ lọc trống (hoặc không có params) sẽ khớp với mọi giao dịch từ cả hai nguồn. Quy tắc lọc:
  • Tất cả vị từ được kết hợp bằng phép AND và được đánh giá theo thứ tự includeSource → failed → regionInclude → signatures → accountExclude → accountRequired → accountInclude → signerExclude → signerInclude → instructions.
  • Các tiền xác nhận BAM có trạng thái không xác định sẽ bỏ qua bộ lọc failed. Các tiền xác nhận Helius có trạng thái không xác định không khớp với bộ lọc failed được chỉ định rõ ràng.
  • includeSource phải là một mảng chỉ chứa helius và bam. Giá trị không hợp lệ trả về lỗi JSON-RPC -32602 (tham số không hợp lệ).
  • Tài khoản là các khóa công khai được mã hóa base58. Giá trị không hợp lệ trả về lỗi JSON-RPC -32602 (tham số không hợp lệ).
  • Mỗi danh sách tài khoản hoặc bên ký bị giới hạn ở 10.000 mục. signatures bị giới hạn ở 1.000 mục.
Bộ lọc includeBam đã lỗi thời vẫn được cung cấp để tương thích ngược. includeBam: false tương đương includeSource: ["helius"]. includeBam: true hoặc việc bỏ qua trường sẽ chọn cả hai nguồn. Không gửi đồng thời includeBam và includeSource.
Để chỉ nhận các tiền xác nhận Helius:

Lọc theo bên ký và chữ ký

Dùng signerInclude để khớp các giao dịch được ký bởi một tài khoản cụ thể. Dùng signerExclude để loại bỏ các giao dịch được ký bởi bất kỳ tài khoản nào trong danh sách. Tài khoản được tham chiếu không được tính là bên ký. Dùng signatures khi đã biết các giao dịch cần theo dõi. Bộ lọc khớp với chữ ký đầu tiên của giao dịch, đây là chữ ký được các phương thức Solana RPC sử dụng. Không thể thay đổi bộ lọc sau khi đăng ký, vì vậy hãy tạo một đăng ký mới để theo dõi các chữ ký mới.

Lọc lệnh

Dùng instructions để khớp các lệnh cấp cao nhất theo chương trình và dữ liệu lệnh. Mỗi bộ lọc lệnh hỗ trợ các trường sau: Mỗi mục memcmp chấp nhận kiểu mã hóa base58, base64 hoặc hex. Mặc định là base58. Giao dịch khớp khi một lệnh cấp cao nhất đáp ứng mọi điều kiện trong bất kỳ bộ lọc lệnh nào. Yêu cầu sau khớp các lệnh pump.fun buy theo bộ phân biệt Anchor của chúng:
Bộ lọc chỉ kiểm tra các lệnh cấp cao nhất. Bộ lọc không thể khớp các lệnh được gọi thông qua lệnh gọi liên chương trình (CPI), vì các lệnh đó chưa tồn tại trước khi thực thi. Bạn có thể cung cấp tối đa 16 bộ lọc lệnh và bốn mục memcmp cho mỗi bộ lọc lệnh. Mỗi giá trị memcmp phải giải mã thành 1–128 byte. Độ lệch cuối của memcmp và dataSize không được vượt quá 4.096 byte.

Phân giải bảng tra cứu địa chỉ (ALT)

Các bộ lọc tài khoản khớp với nhiều dữ liệu hơn các khóa tài khoản tĩnh của giao dịch — Helius phân giải bảng tra cứu địa chỉ v0 ở phía máy chủ, vì vậy accountInclude, accountExclude và accountRequired cũng khớp với các tài khoản mà giao dịch tải qua ALT. Điều này có nghĩa là bạn có thể lọc theo bất kỳ tài khoản nào mà giao dịch truy cập, ngay cả khi tài khoản đó chỉ xuất hiện phía sau bảng tra cứu — không cần tự duy trì ánh xạ ALT hoặc phân giải bảng. Chỉ cần truyền khóa công khai của tài khoản và Helius sẽ xử lý việc phân giải trước khi áp dụng bộ lọc.

Lọc theo vị trí

Dùng regionInclude để chỉ nhận các giao dịch bắt nguồn từ những khu vực cụ thể. Truyền một hoặc nhiều mã khu vực; giao dịch được chấp nhận khi khu vực bắt nguồn khớp với bất kỳ mã nào.
Khu vực bắt nguồn phụ thuộc vào nguồn. Đối với tiền xác nhận Helius, đó là khu vực Helius đã tiếp nhận giao dịch. Đối với tiền xác nhận BAM, đó là điểm cuối BAM theo khu vực đã phát tiền xác nhận, chứ không phải nơi Helius tiếp nhận giao dịch. Các điểm cuối Singapore và Dallas của BAM ánh xạ tới sgp và dal. Các mã khu vực hợp lệ:
Khi đặt regionInclude, các giao dịch không mang thông tin khu vực sẽ bị loại bỏ. Mã khu vực không được nhận dạng trả về lỗi JSON-RPC -32602 (tham số không hợp lệ).

Payload thông báo

Thông báo được gửi dưới dạng khung WebSocket nhị phân (không phải JSON). Các tiền xác nhận Helius và BAM dùng chung một bố cục. Mỗi khung là một bố cục byte được đóng gói chứa một giao dịch duy nhất: Payload không có trường nguồn. Không suy ra nguồn gốc BAM từ tx_index = 0, vì các nguồn khác cũng có thể báo cáo 0.

Phân biệt hai nguồn

Vì không có trường nguồn, bạn không thể gắn nhãn một thông báo bất kỳ là Helius hay BAM. Byte status cung cấp một bộ phân loại một chiều:
  • status là 0 hoặc 1 — thông báo là tiền xác nhận Helius và giao dịch đã được thực thi. BAM không bao giờ báo cáo các giá trị này.
  • status là 2 — nguồn không rõ ràng: có thể là tiền xác nhận BAM hoặc tiền xác nhận Helius không có trạng thái thực thi.
Không trường nào khác có thể phân biệt. ID trình tự và vị trí trong gói của BAM không được truyền trên luồng này, vì vậy không có siêu dữ liệu thứ tự BAM để làm khóa; đồng thời, regionInclude là bộ lọc đăng ký chứ không phải trường payload nên không thể đọc theo từng thông báo. Nếu cần mọi thông báo trên một luồng mang cùng một loại bằng chứng, hãy đặt includeSource: ["helius"] hoặc includeSource: ["bam"]. Luồng chỉ có Helius chứa các tiền xác nhận được phát ra khi leader thực thi.
Luôn đọc và kiểm tra byte version trước tiên. Hiện byte này là 1. Nếu Helius cần cập nhật định dạng payload, phiên bản sẽ tăng — hãy rẽ nhánh theo phiên bản để bộ giải mã tiếp tục hoạt động qua các thay đổi lược đồ.
Tiền xác nhận là tín hiệu sớm, không phải sự bảo đảm. Giao dịch chưa được ghi nhận onchain và vẫn có thể bị loại bỏ — trạng thái thực thi của tiền xác nhận Helius phản ánh kết quả cục bộ của leader, kết quả này chưa phải cuối cùng cho đến khi khối được xác nhận. Hãy xác nhận việc ghi nhận bằng các bước kiểm tra mức cam kết tiêu chuẩn trước khi coi giao dịch là cuối cùng.

Giải mã giao dịch

Các byte giao dịch được chuyển tiếp chính xác như cách trình xác thực tuần tự hóa chúng, theo mã hóa truyền dẫn tiêu chuẩn dành cho phiên bản của giao dịch. Giao dịch cũ và v0 dùng bố cục chữ ký trước do bincode tạo ra. Giao dịch v1 (SIMD-0385) dùng bố cục thông báo trước với chữ ký ở cuối, vì vậy bincode không xử lý được payload v1. Hãy dùng bộ giải mã hỗ trợ mọi phiên bản:
  • Rust: agave-transaction-view phân tích tại chỗ các giao dịch cũ, v0 và v1 mà không cần bản sao trung gian. Đây là lựa chọn được khuyến nghị. wincode, trình tuần tự hóa tương thích với bincode được các Solana SDK hiện tại sử dụng, cũng giải mã v1 thành VersionedTransaction.
  • JavaScript / TypeScript: đảm bảo phiên bản thư viện hỗ trợ giao dịch v1. Các bản triển khai VersionedTransaction.deserialize cũ hơn chỉ xử lý giao dịch cũ và v0. Dùng @solana/kit 8.0+ hoặc @solana/web3.js v3. Xem Hỗ trợ giao dịch v1.

Thông báo trùng lặp

Các tiền xác nhận Helius và BAM được khử trùng lặp theo từng nguồn, không phải giữa các nguồn. Một tỷ lệ nhỏ giao dịch đến Helius qua cả hai nguồn, vì vậy bạn có thể nhận cùng một chữ ký hai lần và hai bản sao có thể báo cáo các slot khác nhau. Khử trùng lặp theo chữ ký ở phía máy khách và thiết kế các hành động do giao dịch kích hoạt theo tính lũy đẳng để thông báo thứ hai không kích hoạt cùng một hành động hai lần. Xác nhận việc thực thi và ghi nhận bằng các bước kiểm tra mức cam kết tiêu chuẩn.

Ví dụ

Hủy đăng ký

Để ngừng nhận thông báo, hãy gọi preconfUnsubscribe bằng ID đăng ký được trả về từ preconfSubscribe.

Giá

Preconfirmation có trên tất cả các gói trả phí: Developer, Business, Professional và Enterprise. Các gói miễn phí không đủ điều kiện. Xem Tín dụng để biết chi tiết. Các slot không phân phối thông báo nào sẽ không tốn tín dụng, ngay cả khi slot đó có phạm vi bao phủ preconfirmation. Khi một slot phân phối ít nhất một thông báo, mỗi gói đăng ký preconfSubscribe đang mở sẽ bị tính mức cao hơn giữa 300 tín dụng và 10 tín dụng cho mỗi thông báo được phân phối. Các slot không được bao phủ không tốn tín dụng. Xem Bảng giá để biết điều kiện tính phí theo nguồn và khu vực. Mỗi gói đăng ký đồng thời được tính phí độc lập khi nhận được ít nhất một thông báo. Đóng các gói đăng ký không còn cần thiết bằng preconfUnsubscribe. Khi dùng includeSource: ["helius"], các slot được bao phủ chỉ bởi BAM sẽ không bị tính phí. Khi đặt regionInclude, các slot được bao phủ nằm ngoài những khu vực đã chọn sẽ không tốn tín dụng đối với gói đăng ký đó; các slot khớp chỉ bị tính phí khi gói đăng ký nhận được ít nhất một thông báo. Việc tính phí dựa trên từng thông báo, không phải từng chữ ký duy nhất. Một giao dịch được cả Helius và BAM gửi sẽ được tính hai lần. Đặt includeSource: ["helius"] nếu bạn chỉ muốn nhận các tiền xác nhận Helius.
Để kiểm soát chi phí, hãy hợp nhất các bộ lọc tài khoản vào một gói đăng ký khi phù hợp, sử dụng regionInclude để giới hạn việc tính phí ở những khu vực cần thiết, đặt includeSource: ["helius"] khi không cần BAM và theo dõi tín dụng trong Bảng điều khiển Helius.
Preconfirmations là một sản phẩm mới và mức giá có thể thay đổi.

Liên quan

Preconfirmations Overview

Preconfirmations là gì và nằm ở đâu trong quy trình của trình xác thực.

transactionSubscribe

Truyền trực tiếp các giao dịch có mức commitment đã xác nhận với khả năng lọc chi tiết.

preconfSubscribe API reference

Các tham số yêu cầu, trường bộ lọc và bố cục thông báo nhị phân.