Preconfirmations (Preconfs) trên Solana là gì?

Vòng đời của giao dịch bên trong leader

Phần sau đây chủ ý chỉ tập trung vào vòng đời giao dịch bên trong leader trong phạm vi liên quan đến Preconfirmations và khả năng quan sát. Để xem toàn bộ vòng đời của một giao dịch trên Solana, hãy đọc tổng quan kỹ thuật về Solana Virtual Machine (SVM) của chúng tôi.

Trước khi đến leader

Trên Solana, các giao dịch đã ký được gửi trực tiếp đến bên sản xuất block (tức leader) và các leader sắp tới. Giao dịch đến qua QUIC, với dung lượng kết nối được phân bổ theo trọng số stake, vì vậy các giao dịch được chuyển tiếp qua kết nối có stake có khả năng được tiếp nhận cao hơn nhiều khi tải lớn.

Tại thời điểm này, giao dịch chỉ hiển thị với người gửi và bất kỳ node RPC hoặc dịch vụ đưa giao dịch vào block nào đang chuyển tiếp giao dịch đó đến leader hiện tại và các leader sắp tới.

Ở giai đoạn này, chưa thể biết điều gì về số phận của giao dịch.

Giai đoạn 1: Tiếp nhận và SigVerify

Transaction Processing Unit (TPU) của leader nhận các giao dịch đến dưới dạng gói tin, giải tuần tự hóa, xác minh chữ ký và loại bỏ mọi giao dịch trùng lặp. Khi tải lớn, các gói tin không hợp lệ và giao dịch rác bị loại bỏ trước khi tiêu tốn thêm tài nguyên.

Một giao dịch được tiếp nhận và vượt qua bước xác minh chữ ký trong giai đoạn SigVerify mới chỉ là một ứng viên; hàng nghìn giao dịch ứng viên đến trong mỗi slot và nhiều giao dịch không bao giờ được đưa vào block.

Không có khả năng quan sát hữu ích ở giai đoạn này vì truyền trực tiếp các giao dịch này đồng nghĩa với truyền cả dữ liệu nhiễu.

Giai đoạn 2: Bộ lập lịch

Quá trình sản xuất block diễn ra tại Banking Stage, và kể từ Agave 1.18, thành phần cốt lõi là bộ lập lịch trung tâm: một luồng lập lịch duy nhất có cái nhìn tổng thể về mọi giao dịch đang chờ, phân phối công việc cho một nhóm worker thực thi. Ý tưởng là một luồng duy nhất với đầy đủ ngữ cảnh có thể đóng gói block với ít xung đột khóa hơn nhiều so với n luồng cạnh tranh để giành một hàng đợi dùng chung.

Về cơ bản, bộ lập lịch đưa giao dịch qua ba bước chính:

1. Tạo bộ đệm và ưu tiên

Các giao dịch đến được đưa vào thành phần receive and buffer của bộ lập lịch, nơi mức độ ưu tiên và chi phí của từng giao dịch được tính toán rồi chèn vào một vùng chứa được sắp xếp theo độ ưu tiên.

Tại thời điểm này, giao dịch vẫn chỉ là một trong hàng nghìn trường hợp “có thể” bị loại nếu bộ đệm đầy những tác vụ có mức ưu tiên cao hơn.

2. Lập lịch

Vòng lặp điều khiển trong controller của bộ lập lịch liên tục lấy các giao dịch có mức ưu tiên cao nhất khỏi vùng chứa, kiểm tra mọi xung đột khóa tài khoản và gom chúng thành lô để thực thi.

Kể từ Agave 2.3, thuật toán lập lịch được phát hành là greedy scheduler. Thuật toán này thay thế thiết kế prio-graph trước đó sau khi thử nghiệm cho thấy cách tiếp cận tham lam đóng gói block với ít chi phí phụ hơn.

3. Phân phối

Lô đã lập lịch được gửi qua một kênh đến worker thực thi. Lúc này, leader đã dành tài nguyên thực—một luồng worker, các khóa tài khoản và một vị trí trong block đang được tạo—cho giao dịch cụ thể này.

Tại thời điểm này, giao dịch vẫn đang chờ xử lý. Leader dự định thực thi giao dịch nhưng chưa có gì được chạy, nên chưa có kết quả để báo cáo. Preconfirmations xuất hiện ở bước tiếp theo.

Kiến trúc bộ lập lịch của Firedancer khác Agave như thế nào?

Firedancer đi đến cùng thời điểm đó thông qua một kiến trúc hơi khác. Thay vì các luồng dùng chung bộ nhớ, Firedancer chạy các tile tách biệt được kết nối qua hàng đợi bộ nhớ dùng chung, với logic lập lịch nằm trong pack tile.

Pack tile duy trì tất cả giao dịch đang chờ, theo dõi các tài khoản mà mỗi bank tile hiện nắm giữ, đồng thời chọn các giao dịch không xung đột và tối đa hóa phí để đưa vào các microblock rồi chuyển cho bank tile thực thi.

Quá trình bàn giao tương tự cũng diễn ra: các giao dịch được chọn đi từ logic đóng gói đến các đơn vị thực thi, nơi kết quả của chúng được xác định.

Giai đoạn 3: Thực thi

Các worker trong Agave hoặc bank tile trong Firedancer thực thi lô giao dịch đã lập lịch trên bank hiện tại, tải tài khoản, chạy chương trình và commit kết quả.

Đây cũng là nơi một giao dịch đã lập lịch có thể thất bại vì nhiều lý do, bao gồm không đủ tiền, lỗi chương trình, kiểm tra trượt giá khiến giao dịch bị hoàn tác hoặc các điều kiện runtime khác. Dù thế nào, lúc này kết quả chỉ tồn tại cục bộ trên máy của leader.

Đây là thời điểm một preconfirmation được phát. Leader truyền trực tiếp từng giao dịch ngay khi giao dịch được thực thi, kèm theo trạng thái, trước khi kết quả được ghi vào entry và rất lâu trước khi bất kỳ dữ liệu block nào rời khỏi máy.

Đây là thời điểm đầu tiên trong toàn bộ 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. Trước bước thực thi chỉ có một nhóm ứng viên đang chờ mà không có kết quả để truyền; sau bước thực thi, thông tin đã được đóng gói vào block đang nhanh chóng truyền đến phần còn lại của mạng.

Do đó, thực thi là nơi duy nhất một tín hiệu sớm như vậy có thể tồn tại. Đây cũng là lý do mỗi preconfirmation mang kết quả thực tế của giao dịch thay vì một dự đoán.

Tuy nhiên, preconfirmation không thể cho biết liệu block chứa giao dịch có trở thành block chính thức hay không. Block đó chưa được chia thành shred, truyền đi hoặc bỏ phiếu.

Vì lý do này, Preconfirmations là một tín hiệu chứ không phải sự bảo đảm.

Giai đoạn 4: Proof of History và các entry

Các lô đã thực thi được ghi vào luồng Proof of History để tạo ra các entry. Đây là những gói giao dịch được băm và đan vào đồng hồ có thể xác minh của leader. Entry là định dạng gốc của sổ cái, nhưng hiện chỉ tồn tại trên máy của leader.

Khả năng quan sát gần như bằng không đối với bất kỳ ai ngoài leader.

Lưu ý rằng Proof of History sẽ bị loại bỏ trong bản cập nhật Alpenglow, vì Rotor và Votor loại bỏ nhu cầu về một đồng hồ phi tập trung trên Solana. Mô hình preconfirmation không bị ảnh hưởng: các leader vẫn thực thi giao dịch trước khi phân phối chúng, vì vậy tín hiệu sớm nhất có thể quan sát vẫn là kết quả thực thi cục bộ của leader.

Giai đoạn 5: Chia thành shred và phát sóng

Các entry được cắt thành shred, tức các mảnh có kích thước MTU được mã hóa xóa để chịu được mất mát. Những shred này được ký và phát qua cây có trọng số stake của Turbine.

Đây là nơi cánh cửa quan sát được mở hoàn toàn. Shred là sản phẩm đầu tiên của một block nhất định rời khỏi máy của leader. Vì vậy, mọi sản phẩm dữ liệu sớm khác trên Solana, bao gồm các luồng shred, đều bắt đầu tại đây. Bất kỳ ai tái dựng giao dịch từ shred đều nhanh hơn so với các cấp độ cam kết RPC, nhưng chậm hơn preconfirmation vì leader đã thực thi giao dịch trước khi shred tồn tại.

Sau đó, các validator tiếp tục phát lại block, bỏ phiếu và các giao dịch lần lượt tiến qua các cấp độ cam kết processed, confirmed và finalized.

Preconfirmations nằm ở đâu trên thang độ trễ?

Preconfirmations là tín hiệu nhanh nhất trên Solana so với tất cả lựa chọn khác, bao gồm shred thô và shred đã giải mã, LaserStream cùng các phương thức truyền dữ liệu khác.

Tuy nhiên, nên hiểu preconfs là một bậc trên thang độ trễ, trong đó mỗi bậc đánh đổi một mức độ đầy đủ hoặc chắc chắn nào đó để có thể quan sát sớm hơn.

Theo thứ tự từ sớm nhất đến muộn nhất:

Có thể rút ra hai nhận xét từ bảng này.

Thứ nhất, tất cả các tín hiệu này bổ trợ cho nhau thay vì trực tiếp thay thế nhau.

Ví dụ, Preconfirmations báo cáo những gì leader vừa thực thi trước khi mạng biết, trong khi thông báo từ LaserStream cho biết đầy đủ những gì đã xảy ra kèm siêu dữ liệu.

Các hệ thống production thường cần sử dụng cả hai, hành động dựa trên Preconfirmations và dùng các tín hiệu ở giai đoạn sau để xác minh.

Thứ hai, khoảng cách giữa các bậc không đồng đều.

Bước từ các luồng processed lên shred tiết kiệm vài mili giây, trong khi bước từ shred lên Preconfirmations bỏ qua phần còn lại của quy trình sản xuất block (tức ghi entry, chia thành shred và truyền đi), vì điểm quan sát chuyển từ sản phẩm công khai đầu tiên của block sang kết quả chỉ tồn tại bên trong leader.

Do đó, Preconfirmations nhanh hơn shred khoảng 5 đến 50 mili giây.

Mô hình tin cậy của Preconfirmations: Tín hiệu, không phải sự bảo đảm

Mọi điều mà preconfirmation cam kết có thể gói gọn trong một câu: leader đã thực thi giao dịch này với kết quả này. Mọi điều mà preconf không cam kết cũng xuất phát từ chính câu đó.

Một giao dịch đã thực thi chưa phải là giao dịch đã được ghi nhận, nghĩa là block chứa giao dịch chưa được chia thành shred, truyền đi hoặc bỏ phiếu. Block này vẫn có thể bị bỏ qua hoặc bị tách khỏi fork trước khi được mạng xác nhận. Gần như tất cả giao dịch nhận preconfirmation đều được ghi nhận onchain thành công. Tuy nhiên, mọi hệ thống hành động dựa trên Preconfirmations đều phải xác nhận kết quả qua các bước kiểm tra khả năng quan sát khác trước khi coi chúng là cuối cùng.

Phạm vi bao phủ cũng được thiết kế chỉ mang tính một phần. Preconfirmations chỉ tồn tại đối với các slot mà leader chuyển tiếp luồng giao dịch đã lập lịch của mình đến Helius. Do đó, phạm vi bao phủ tăng theo tỷ lệ stake tham gia trong mạng và luồng không nhất thiết phải liên tục.

Nếu dịch vụ cần phạm vi bao phủ liên tục như một bảo đảm tuyệt đối, hãy cân nhắc chuyển sang LaserStream hoặc Shred Delivery khi xuất hiện khoảng trống.

Vì Preconfirmations được phát sau khi thực thi, người đăng ký nhìn thấy các kết quả đã được quyết định chứ không phải luồng lệnh đang chờ có thể bị khai thác. Điều này có nghĩa là cơ hội đi trước giao dịch đó trong block đã khép lại. Đây là điểm khác biệt then chốt giữa việc cung cấp khả năng quan sát sớm và làm rò rỉ luồng lệnh trước khi lập lịch: khả năng quan sát sớm cho phép người đăng ký phản ứng nhanh hơn phần còn lại của mạng, trong khi việc rò rỉ sẽ cho phép họ hành động chống lại chính những giao dịch đang được truyền. Preconfirmations hoàn toàn thuộc trường hợp đầu tiên.

Tín hiệu này phản ánh đúng bản chất của nó: không có cam kết kinh tế nào bảo đảm cho preconfirmation và cũng không có tuyên bố nào như vậy. Leader báo cáo kết quả cục bộ nhưng không đặt stake để bảo đảm kết quả đó sẽ được hoàn tất. Với các chiến lược mà Preconfirmations phục vụ, đây là sự đánh đổi phù hợp.

Ví dụ, một bot thanh lý không cần lời hứa tuyệt đối, có thể bị phạt stake, rằng giao dịch sẽ được ghi nhận; bot chỉ cần biết kết quả của một giao dịch nhất định sớm hơn đối thủ vài mili giây.

Helius Preconfirmations hoạt động như thế nào?

Helius Preconfirmations được cung cấp qua một đăng ký WebSocket duy nhất. Client có thể kết nối với endpoint Gatekeeper của chúng tôi (tức wss://beta.helius-rpc.com) và gửi yêu cầu preconfSubscribe:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

Các bộ lọc được áp dụng phía server theo tài khoản (tức bao gồm, loại trừ, bắt buộc), khu vực và trạng thái, đồng thời hỗ trợ bảng tra cứu (LUT), để người đăng ký chỉ nhận và trả phí cho các giao dịch đã lập lịch có liên quan đến chiến lược của họ.

Vì Preconfirmations được phát sau khi thực thi, bộ lọc trạng thái hoạt động trên kết quả thực tế: failed: false, nghĩa là các giao dịch thất bại không bao giờ được truyền hoặc tính phí.

Mức giá dựa trên credit, tương tự các đăng ký Helius WebSocket khác ở mức 10 credit cho mỗi thông báo, mỗi giao dịch được truyền tương ứng với một thông báo, áp dụng cho gói Professional trở lên.

Từ đó, mọi giao dịch đã lập lịch khớp với bộ lọc sẽ đến dưới dạng frame nhị phân nhỏ gọn. Cụ thể là một header cố định 18 byte chứa phiên bản giao dịch, slot nơi giao dịch được lập lịch, chỉ mục của giao dịch trong slot và trạng thái, tiếp theo là toàn bộ byte của giao dịch.

Định dạng này được chủ ý tối giản vì header cố định có thể được giải mã trong vài nano giây mà không cần phân tích JSON trên đường xử lý trọng yếu. JSON duy nhất cần dùng trong quá trình trao đổi này là thông báo xác nhận đăng ký để thuận tiện.

Lưu ý rằng preconfirmation chỉ là một nửa của giao dịch. Nhìn thấy giao dịch đầu tiên chỉ có ý nghĩa nếu phản hồi cũng được ghi nhận đầu tiên. Vì vậy, chúng tôi cũng ra mắt Sender Max, cấp Helius Sender có hiệu năng cao nhất.

Sender Max định tuyến một lần gửi (tức một giao dịch đơn lẻ hoặc một bundle nguyên tử gồm tối đa bốn giao dịch) qua mọi tuyến tốc độ cao hiện có và đưa vào bộ đệm tip ưu tiên, ưu tiên các tip cao nhất. Tip tối thiểu là 0.001 SOL.

Nhận tín hiệu với preconfSubscribe, đưa giao dịch vào block với Sender Max.

Bạn có thể xây dựng gì với Preconfirmations?

Mọi chiến lược có lợi nhuận giảm dần theo từng mili giây giữa thời điểm giao dịch được quyết định và thời điểm được quan sát đều được hưởng lợi từ preconfs. Các trường hợp sử dụng bao gồm nhưng không giới hạn ở những nội dung sau:

Sniping

Việc tạo pool mới và ra mắt token có thể được nhìn thấy ngay khi giao dịch triển khai được thực thi bên trong leader. Một sniper sử dụng Preconfirmations có thể phản ứng trong khi những người theo dõi shred vẫn đang chờ các mảnh đầu tiên của block xuất hiện.

Copy trading

Các chuyển động của ví mục tiêu xuất hiện trong luồng preconfirmation ngay khi leader thực thi chúng. Lọc theo địa chỉ mục tiêu bằng accountInclude biến luồng này thành nguồn dữ liệu sao chép chuyên biệt, cung cấp thông tin về các chuyển động trước những người copy trading khác.

Thanh lý

Một bản cập nhật oracle khiến vị thế rơi vào tình trạng mất khả năng thanh toán có thể được nhận biết ngay khi được thực thi. Bot thanh lý nhìn thấy điều đó tại đây sẽ kích hoạt toàn bộ quy trình sớm hơn bot đang theo dõi shred hoặc cấp độ cam kết processed, khiến Preconfirmations đặc biệt quan trọng đối với hoạt động thanh lý.

Tạo lập thị trường và propAMMs

Luồng vào có thể quan sát ngay tại thời điểm thực thi giúp propAMMs và các hệ thống báo giá khác có lợi thế khi định giá lại hoặc rút các báo giá cũ trước khi luồng này được công khai.

Trong mọi trường hợp, Preconfirmations chuyển thời điểm phản ứng của chiến lược từ “sau khi mạng biết” sang “ngay khi leader thực thi”.

Kiếm doanh thu bằng cách chuyển tiếp Preconfirmations

Phạm vi bao phủ của Preconfirmations là một hiệu ứng mạng, với các validator ở phía cung. Bất kỳ validator nào cũng có thể chuyển tiếp luồng của mình đến Helius và nhận doanh thu, biến sản phẩm phụ của quá trình sản xuất block thành nguồn thu nhập, bất kể validator có đang kiếm tiền từ vị thế của mình theo cách khác hay không.

Càng nhiều stake tham gia, phạm vi bao phủ càng rộng. Các validator muốn tham gia có thể liên hệ với chúng tôi và tìm thêm thông tin trong tài liệu về Preconfirmations dành cho validator.

Ethereum preconfs khác Solana preconfs như thế nào?

Ethereum Preconfirmations là cam kết của proposer nhằm bảo đảm giao dịch sẽ được đưa vào một block trong tương lai, còn Solana Preconfirmations là tín hiệu giao dịch onchain theo thời gian thực dành cho các giao dịch vừa được leader thực thi cục bộ cho block hiện tại. Loại đầu tiên giúp biết chắc sớm hơn, còn loại sau giúp nhìn thấy sớm hơn.

Ethereum Preconfirmations

Trên Ethereum, Preconfirmations—thường được gọi là based preconfs trong tài liệu nghiên cứu, một thiết kế được Justin Drake trình bày lần đầu vào năm 2023—là các cam kết đưa giao dịch vào block. Trước slot của mình, proposer cam kết một giao dịch sẽ được đưa vào block tương lai, với cam kết được bảo đảm bằng cơ chế kinh tế như slashing.

Hiện có một số triển khai đang hoạt động:

• MEV-Commit của Primev, một thị trường nơi ví, searcher và các giao thức intent trả giá cho nhà cung cấp dịch vụ thực thi (tức bên xây dựng block và sequencer) để nhận cam kết
• ETHGas, một mạng preconfirmation được bảo đảm về mặt kinh tế
• Bolt của Chainbound, cung cấp các cam kết proposer tương thích với MEV-Boost mà không cần cấp phép

Quan trọng nhất, Ethereum Preconfirmations:

• Liên quan đến giao dịch của chính bạn
• Được phát hành trước khi thực thi
• Được tối ưu cho sự chắc chắn

Ethereum Preconfirmations bảo đảm giao dịch của bạn sẽ được ghi nhận trước khi điều đó thực sự xảy ra.

Ethereum cần cơ chế này do cách các block được xây dựng. Hầu hết proposer đấu giá việc xây dựng block ngay trước thời điểm thực hiện thông qua MEV-Boost, nên không thể đưa ra lời hứa đáng tin cậy nào về block cho đến khi cuộc đấu giá kết thúc. Tuy nhiên, Solana chưa bao giờ có khoảng trống đó. Lịch leader được biết trước, không có mempool và một leader duy nhất liên tục nhận, sắp xếp, thực thi và truyền block của mình trong slot. Tín hiệu sớm mà Ethereum phải tạo ra bằng cơ chế kinh tế vốn đã tồn tại tự nhiên trong quy trình sản xuất block của Solana; nó chỉ cần được cung cấp ra bên ngoài.

Solana Preconfirmations

Solana Preconfirmations là tín hiệu onchain theo thời gian thực chứ không phải lời hứa trong tương lai: leader báo cáo các giao dịch mà mình đã thực thi trước khi những giao dịch đó được truyền đến phần còn lại của mạng.

Quan trọng nhất, Solana Preconfirmations:

• Bao gồm giao dịch của mọi người
• Được phát sau khi thực thi
• Được tối ưu cho độ trễ

Solana Preconfirmations cho phép bạn nhìn thấy các giao dịch đã thực thi sớm hơn vài mili giây trước khi chúng được quan sát trên toàn mạng qua shred hoặc các yêu cầu RPC ở cấp độ cam kết tiêu chuẩn.

Cơ chế tương đương gần nhất trên Solana với preconfirmation đặt trước không gian block của Ethereum là thị trường đơn vị tính toán của Raiku dành cho Ahead-of-Time (AOT) Transactions, cho phép ứng dụng đặt trước khả năng chắc chắn được đưa vào các block tương lai.

Kết luận

Mọi giao dịch trên Solana đều đi qua một thời điểm duy nhất khi số phận của nó chuyển từ chưa xác định sang đã quyết định: khoảnh khắc leader thực thi giao dịch. Preconfirmations chính là khoảnh khắc đó, được truyền trước khi phần còn lại của mạng có thể nhìn thấy. Chúng nằm trên shred trong thang độ trễ vì quan sát kết quả thực thi của leader thay vì các sản phẩm công khai của block. Preconfirmations là tín hiệu chứ không phải sự bảo đảm, vì block chưa được xem là chính thức cho đến khi mạng xác nhận.

Đối với các hệ thống nhạy cảm với độ trễ—sniper, người copy trading, bot thanh lý, nhà tạo lập thị trường và searcher—hãy đăng ký bằng preconfSubscribe, lọc các tài khoản quan trọng, phản hồi tín hiệu bằng Sender Max và xác minh qua các bước kiểm tra cấp độ cam kết tiêu chuẩn.

Toàn bộ tài liệu tham khảo về đăng ký, định dạng thông báo và ví dụ tích hợp đều có trong tài liệu Preconfirmations của chúng tôi.