Preconfirmations: Tín hiệu giao dịch sớm nhất trên Solana

​

Tổng quan

Preconfirmations truyền phát các giao dịch tại thời điểm sớm nhất có thể quan sát được — trước khi chúng được tập hợp thành các entry và chuyển đổi thành shred. Đây là tín hiệu giao dịch có độ trễ thấp nhất mà Helius cung cấp — sớm hơn Shred Delivery và sớm hơn các luồng ở mức cam kết processed. Bạn đăng ký qua WebSocket bằng phương thức preconfSubscribe và nhận từng giao dịch ngay khi giao dịch đó diễn ra. Luồng này kết hợp hai nguồn, cả hai đều được bao gồm theo mặc định và phát dữ liệu tại các thời điểm khác nhau trong quy trình:

• Helius Preconfirmations từ các validator chuyển tiếp dữ liệu đến Helius. Được phát ngay khi leader thực thi giao dịch, cùng với trạng thái thực thi — thời điểm đầu tiên mà kết quả xuất hiện ở bất kỳ đâu.
• BAM Preconfirmations từ các validator chạy client Block Assembly Marketplace (BAM) của Jito. Được phát khi validator cam kết thực thi giao dịch, trước khi giao dịch chạy — vì vậy chúng không có trạng thái thực thi.

​

Vị trí của Preconfirmations trong quy trình

Một giao dịch trải qua nhiều giai đoạn bên trong validator trước khi được ghi nhận onchain. Độ trễ tăng dần từ trái sang phải — bạn quan sát càng xa về bên phải thì càng biết về giao dịch muộn hơn. Helius Preconfirmations được phát từ giai đoạn thực thi — ngay khi leader thực thi giao dịch và trạng thái của giao dịch được xác định, nhưng trước khi kết quả được ghi vào một entry và chuyển thành shred. Đây là thời điểm đầu tiên trong vòng đời mà kết quả của giao dịch vừa tồn tại vừa có thể được báo cáo. BAM Preconfirmations được phát sớm hơn một giai đoạn, khi validator cam kết thực thi giao dịch nhưng trước khi giao dịch chạy. Cả hai đều đến trước khi giao dịch được chuyển thành shred, do đó có độ trễ thấp hơn rõ rệt so với phương thức phân phối dựa trên shred đối với cùng một giao dịch.

​

BAM Preconfirmations

BAM (Block Assembly Marketplace) là hệ thống xây dựng block của Jito dành cho Solana. Các validator chạy client tương thích với BAM phát Preconfirmation ngay khi cam kết thực thi một giao dịch. Helius tiếp nhận dữ liệu này từ các endpoint BAM theo khu vực của Jito và phân phối qua cùng gói đăng ký preconfSubscribe cũng như payload nhị phân dùng cho Helius Preconfirmations. Tại thời điểm ra mắt, BAM đã bổ sung phạm vi phủ từ các validator đại diện cho hơn 34% stake của mạng. BAM Preconfirmations sử dụng cùng bố cục payload nhưng khác nhau ở một số trường:

• tx_index luôn là 0. BAM sắp xếp giao dịch theo ID trình tự và vị trí trong bundle thay vì chỉ mục slot; cả hai đều không ánh xạ tới trường của Helius và không được truyền trên luồng. Xem Phân biệt hai nguồn.
• regionInclude khớp với endpoint BAM theo khu vực đã phát Preconfirmation, không phải khu vực Helius đã tiếp nhận dữ liệu đó.
• Một tỷ lệ nhỏ giao dịch đến Helius qua cả hai nguồn, vì vậy cùng một chữ ký có thể xuất hiện hai lần. Xem Thông báo trùng lặp.

Để chỉ nhận Helius Preconfirmations, hãy truyền includeBam: false trong bộ lọc đăng ký.

​

Khi nào nên sử dụng Preconfirmations

​

Giá

Preconfirmations yêu cầu gói Professional trở lên và có giá 10 credit cho mỗi thông báo — một thông báo cho mỗi giao dịch được truyền phát — được tính vào gói của bạn. Xem Credit để biết chi tiết.

​

Phạm vi phủ

Preconfirmations chỉ khả dụng cho các giao dịch do những validator chuyển tiếp luồng của họ đến Helius hoặc chạy client tương thích với BAM lên lịch. Phạm vi phủ tăng theo tỷ lệ stake mạng được hai nguồn này bao phủ, vì vậy luồng không liên tục. Việc đặt includeBam: false giới hạn phạm vi phủ ở các validator chuyển tiếp trực tiếp đến Helius. Phạm vi phủ tăng lên khi có thêm validator chuyển tiếp dữ liệu đến Helius. Nếu vận hành một validator, bạn có thể giúp thu hẹp những khoảng trống này và kiếm doanh thu.

​

Dành cho validator

Bạn đang vận hành một validator? Bạn có thể kiếm doanh thu bằng cách chuyển tiếp luồng Preconfirmation đến Helius — đồng thời cải thiện phạm vi phủ cho tất cả người dùng Preconfirmations.

​

Các bước tiếp theo