Skip to main content

​
Tổng quan

Giao dịch được tiền xử lý là các giao dịch Solana trước thực thi được phân phối trước khi đạt mức cam kết processed. Helius tổng hợp nhiều nguồn trước thực thi — chủ yếu là các shred được giải mã trực tiếp khi đến trình xác thực, kết hợp thêm tín hiệu preconfirmation — rồi phân phối chúng dưới dạng một luồng duy nhất đã loại bỏ trùng lặp, không yêu cầu bạn nhận các gói shred thô hoặc vận hành cơ sở hạ tầng tái hợp shred. Các giao dịch bắt nguồn từ tín hiệu preconfirmation xuất hiện trên luồng này muộn hơn so với sản phẩm Preconfirmations chuyên dụng, vốn vẫn cung cấp quyền truy cập sớm nhất vào chúng. Cách sử dụng giao dịch được tiền xử lý là thông qua phương thức WebSocket preprocessedSubscribe (Public Beta) — khả dụng trên tất cả các gói trả phí với mức phí 0,1 credit cho mỗi thông báo.

preprocessedSubscribe (WSS)

Cách được khuyến nghị để truyền phát giao dịch được tiền xử lý: lọc tài khoản, payload nhị phân nhỏ gọn, hỗ trợ tất cả các gói trả phí.

​
Vị trí của giao dịch được tiền xử lý trong vòng đời

Trong kiến trúc của Solana, giao dịch trải qua nhiều giai đoạn trước khi được xử lý hoàn toàn:
  1. Tiếp nhận shred → Trình xác thực nhận các shred giao dịch (mảnh dữ liệu). ← Shred thô (UDP) được phân phối tại đây.
  2. Giải mã shred → Các shred được giải mã thành giao dịch thô. ← Giao dịch được tiền xử lý chủ yếu được phân phối tại đây.
  3. Thực thi giao dịch → Giao dịch được runtime thực thi.
  4. Tạo siêu dữ liệu → Số dư trước/sau, nhật ký và thông tin lỗi được tính toán.
  5. Cam kết → Giao dịch đạt trạng thái processed/confirmed/finalized. ← LaserStream gRPC và LaserStream WebSocket phân phối tại đây.
Các gói đăng ký sau thực thi phân phối dữ liệu ở giai đoạn 5 — sau khi hoàn tất thực thi và tạo siêu dữ liệu. Giao dịch được tiền xử lý được phân phối theo thời điểm của giai đoạn 2 — sau khi giải mã shred và trước khi hoàn tất thực thi. Để nhận tín hiệu sớm hơn nữa, Preconfirmations truyền phát giao dịch trước khi chúng trở thành shred. Sự đánh đổi: bạn nhận dữ liệu giao dịch sớm hơn nhưng không có siêu dữ liệu thực thi như thay đổi số dư, nhật ký hoặc thông tin lỗi.
Đây là luồng chỉ chứa giao dịch. Các cập nhật trạng thái tài khoản và chương trình chưa tồn tại cho đến khi runtime thực thi giao dịch. Nếu cần các cập nhật tài khoản hoặc chương trình theo thời gian thực — số dư token, trạng thái đường cong liên kết, tài khoản chương trình — hãy sử dụng LaserStream gRPC ở mức cam kết processed thay thế.

​
Có những dữ liệu nào?

Giao dịch được tiền xử lý bao gồm toàn bộ giao dịch đã ký nhưng không có siêu dữ liệu thực thi:

​
Dữ liệu có sẵn

  • ✅ Chữ ký giao dịch - Mã định danh giao dịch duy nhất
  • ✅ Khóa tài khoản - Tất cả tài khoản được giao dịch tham chiếu
  • ✅ Chỉ thị - Toàn bộ dữ liệu chỉ thị và lệnh gọi chương trình
  • ✅ Blockhash gần đây - Tham chiếu thời điểm hết hạn của giao dịch
  • ✅ Chữ ký - Tất cả chữ ký của giao dịch
  • ✅ Số slot - Slot mà giao dịch được quan sát thấy

​
Dữ liệu còn thiếu

  • ❌ Siêu dữ liệu giao dịch - Thay đổi số dư token, số dư trước/sau, trạng thái giao dịch
  • ❌ Lỗi giao dịch - Không thể xác định giao dịch có thất bại hay không
  • ❌ Chỉ thị nội bộ - Không bao gồm các lệnh gọi xuyên chương trình (CPI)
  • ❌ Thông báo nhật ký - Nhật ký chương trình được tạo trong quá trình thực thi
  • ❌ Đơn vị tính toán đã sử dụng - Không có chỉ số thực thi
Có thể hình dung giao dịch được tiền xử lý là việc nhận được “đề xuất” nhưng chưa có “kết quả”. Bạn thấy điều người gửi cố gắng thực hiện, nhưng không thấy điều thực sự đã xảy ra.

​
Đảm bảo phân phối

Việc phân phối chỉ được thực hiện trong khả năng tốt nhất, không được đảm bảo và không có tính năng phát lại dữ liệu lịch sử. Giao dịch được truyền phát là tín hiệu trước thực thi, không phải mức cam kết — giao dịch có thể thất bại, bị loại bỏ hoặc được đưa vào một fork khác. Hãy loại bỏ trùng lặp theo chữ ký và đối chiếu với luồng processed hoặc confirmed khi kết quả thực thi có vai trò quan trọng. Đối với các ứng dụng quan trọng yêu cầu phân phối được đảm bảo và dữ liệu đầy đủ, hãy sử dụng LaserStream gRPC thay thế.

​
Khi nào nên sử dụng giao dịch được tiền xử lý

Các ứng dụng nhạy cảm với độ trễ cần giao dịch trước thực thi đã giải mã mà không phải vận hành bộ giải mã shred:
  • propAMM
  • Bot sniper
  • Bot sao chép giao dịch
  • Bot thanh lý
  • Kinh doanh chênh lệch giá
Nếu từng micro giây đều quan trọng và bạn có thể tái hợp shred ở tốc độ đường truyền, hãy sử dụng shred thô (UDP). Nếu cần tín hiệu sớm nhất có thể, hãy sử dụng Preconfirmations.

​
Giá

preprocessedSubscribe khả dụng trên tất cả các gói trả phí và được tính ở mức 0,1 credit cho mỗi thông báo — mỗi giao dịch được phân phối tương ứng với một thông báo. Xem Credit để biết chi tiết.

​
Câu hỏi thường gặp

Không, bộ lọc được cố định bởi preprocessedSubscribe ban đầu. Để tránh gián đoạn, bạn nên mở một kết nối thứ hai với bộ lọc mới, chờ xác nhận đăng ký rồi chuyển dịch vụ sang bộ lọc mới.
Giới hạn 10 kết nối đồng thời được áp dụng cho mỗi khóa API. Mỗi khóa API trong một dự án có giới hạn riêng là 10 kết nối.

​
Các bước tiếp theo

Subscribe with preprocessedSubscribe

Endpoint, lọc tài khoản, bố cục payload nhị phân và ví dụ mã.

Preconfirmations

Giao dịch được truyền phát trước khi trở thành shred — tín hiệu giao dịch sớm nhất.

Raw Shreds (UDP)

Các gói shred chưa xử lý qua UDP. Bạn tự triển khai việc tái hợp shred.

Helius Sender

Hành động dựa trên dữ liệu quan sát được với tốc độ đưa giao dịch vào chuỗi nhanh nhất.