Tác giả: Carlos, Luke Leasure
Tiêu đề gốc: Solana’s block-building wars
Biên dịch và tổng hợp: BitpushNews
26年1月5日, JITO đã ra mắt một công cụ công khai có tên IBRL Explorer, nhằm đo lường hành vi đóng gói khối của người xác thực trên Solana và tiết lộ "trò chơi thời điểm" vốn không thể thấy trước đây trong việc xây dựng khối.
Trước tiên, chúng ta cần hiểu một số bối cảnh về cấu trúc thị trường của Solana. Solana được thiết kế như một hệ thống xử lý theo luồng (streaming system): trong điều kiện lý tưởng, khi một khối đang được xây dựng, Người Lãnh đạo (Leader) sẽ liên tục phát tán các mảnh dữ liệu (các gói dữ liệu nhỏ). Hành vi này nhằm mục đích tối thiểu hóa độ trễ xử lý giao dịch (khoảng thời gian từ khi người xác thực nhận được một giao dịch cho đến khi giao dịch đó được xử lý). Tuy nhiên, liệu quy trình xử lý giao dịch của Solana có thực sự liên tục hay không, trên thực tế phụ thuộc vào cách các trình xác thực lắp ráp các khối của họ.
Jito đã định nghĩa hành vi đóng gói khối tối ưu từ góc độ người xác thực: xây dựng nhanh, truyền phát liên tục, phổ biến trạng thái sớm. Điểm số IBRL của Jito là sự kết hợp có trọng số của ba biến số này:
-
Thời gian Slot (35%): Người xác thực đạt điểm cao nếu khối của họ được xây dựng xong trong các ngưỡng sau: slot tiếp quản từ một người xác thực khác nhỏ hơn 550 mili giây, hoặc slot liên tục (tức là bất kỳ slot nào còn lại trong nhiệm kỳ của Người Lãnh đạo) nhỏ hơn 380 mili giây.
-
Đóng gói giao dịch không bỏ phiếu (40%): Người xác thực được thưởng điểm khi các giao dịch được phân bố đều trong 64 tick của slot (thay vì nhồi nhét phần lớn giao dịch không bỏ phiếu vào vài tick cuối cùng của slot, tức là "đóng gói trễ"). Đây là biến số gây tranh cãi nhất trong điểm IBRL, sẽ được giải thích chi tiết ở phần sau.
-
Bỏ phiếu sớm (25%): Người xác thực đạt điểm tối đa khi ít nhất 90% giao dịch bỏ phiếu được xử lý trong 32 tick đầu tiên. Điểm số giảm dần nếu việc bỏ phiếu bị đẩy lùi vào phần muộn hơn của khối.
IBRL Explorer cho thấy, nhiều người xác thực có tình trạng đóng gói trễ các giao dịch không bỏ phiếu, trong một số trường hợp thậm chí còn kéo dài thời gian slot. Việc đóng gói trễ làm trì hoãn việc phổ biến trạng thái, làm tăng phương sai của kết quả thực thi, phá vỡ thiết kế dạng luồng của Solana và do đó làm tăng độ trễ mạng. Bạn nhận được không phải là một luồng dữ liệu liên tục, mà là một đợt phun trào dữ liệu đột ngột.
Trong một khối tối ưu, như ví dụ từ trình xác thực Helius dưới đây, hầu hết các giao dịch bỏ phiếu được xử lý trong nửa đầu của khối ("phổ biến trạng thái sớm"), trong khi các giao dịch không bỏ phiếu được phân bố tương đối đều trong 64 tick của slot ("truyền phát liên tục").
Theo Lucas Bruder, đồng sáng lập kiêm Giám đốc điều hành của Jito Labs, người xác thực được khuyến khích chờ đến thời điểm cuối cùng của slot để quan sát thêm các giao dịch đến, chọn các giao dịch trả phí cao nhất, từ đó tối đa hóa phần thưởng.
Nhưng tại sao người dùng nên quan tâm? Mặc dù việc tối đa hóa lợi nhuận là hành vi hợp lý đối với một người xác thực riêng lẻ, nhưng hành vi này sẽ tạo ra sự kiểm duyệt ngầm, trì hoãn việc phổ biến trạng thái và buộc Người Lãnh đạo tiếp theo phải "đuổi theo", từ đó làm chậm toàn bộ mạng lưới.
Quan trọng hơn, việc đóng gói trễ cũng liên quan trực tiếp đến động lực "Thanh toán cho dòng lệnh" (PFOF) mới nổi của Solana, như Benedict Brady đã phác thảo trong bài viết này. Bởi vì ví và ứng dụng thường tạo ra các giao dịch đã ký được định tuyến trước (tức lệnh thị trường với giới hạn trượt giá), nên quyền "chạy sau" (backrunning) có giá trị được nhúng trong lệnh. Cách làm có lợi cho người dùng là bán quyền chạy sau này cho các công ty giao dịch, còn cách làm có tính chiết xuất là thực hiện "tấn công kẹp" (sandwich attack). Dù bằng cách nào, cũng có động cơ làm chậm tốc độ xử lý giao dịch để tăng giá trị của việc chạy sau, đây chính xác là điều mà việc đóng gói trễ có thể đạt được.
Động lực này đẩy Solana tiến tới một cấu trúc thị trường đối kháng hơn đối với các ứng dụng và người dùng. Nó cũng làm suy yếu các đảm bảo quan trọng mà các nhà tạo lập thị trường dựa vào, đặc biệt là về việc hủy bỏ trong khối và thực thi xác định, dẫn đến chênh lệch giá mua-bán mở rộng. Không có truyền phát liên tục, bất kể logic ứng dụng xuất sắc đến đâu, thị trường thời gian thực thực sự vẫn còn xa vời đối với Solana.
Cuộc tranh luận giữa Temporal và Jito
Trước khi đi sâu vào cách Solana giải quyết vấn đề này, phải thừa nhận rằng, thậm chí còn có một cuộc tranh luận sôi nổi về việc thế nào là xây dựng khối "tốt". Nhà đóng góp cốt lõi của Harmonic, Temporal, đã phản đối khuôn khổ và phương pháp chấm điểm IBRL của Jito. Chỉ trích của họ là điểm số này nhúng một bộ sở thích thiết kế cụ thể, những sở thích này có lợi cho cách xây dựng khối của Jito và mặc định làm cho Harmonic trông tệ hơn, điều này được phản ánh qua việc những người xác thực chạy Harmonic liên tục đạt điểm số thấp hơn.
Theo đồng sáng lập Harmonic, các khối của Harmonic được thực thi liên tục mà không có độ trễ, nhưng các mảnh dữ liệu chỉ được giải phóng sau khi một cuộc đấu giá khoảng 300 mili giây hoàn tất. Phương pháp này cho người xây dựng khối đủ thời gian để cạnh tranh, và cũng cho phần còn lại của mạng đủ thời gian để phát lại khối của Harmonic. Hình ảnh trực quan dưới đây cho thấy cùng một slot (391,822,619) từ trình xác thực Temporal Emerald đang chạy Harmonic.
Xét trong ngữ cảnh cách khối được phổ biến (hình trên), việc thực thi của Harmonic có vẻ như được phân bố đều. Nói cách khác, người xây dựng khối liên tục xây dựng khối thông qua việc xây dựng khối song song, và lý do các giao dịch chỉ tập trung vào các tick cuối cùng (hình dưới) là vì đó là thời điểm quyết định đấu giá.
Trong 30 ngày qua, Harmonic đã vượt trội hơn cả Jito và Firedancer về tổng doanh thu trung bình và trung vị trên mỗi khối (phí ưu tiên + tiền tip), từ đó mang lại phần thưởng cao hơn cho người xác thực và người đặt cọc. Vấn đề còn bỏ ngỏ là, liệu hiệu suất vượt trội này có phải được thực hiện thông qua trò chơi thời điểm được mô tả ở trên, với cái giá phải trả là lợi ích của người dùng hay không.
Nguồn: https://reports.firedancer.io/
Đề xuất Đồng thời Nhiều (MCP) và BAM
Sau khi trình bày quan điểm của cả hai bên, một điểm vẫn đúng: truyền phát liên tục là cực kỳ quan trọng.
Luận điểm của Harmonic không phải là truyền phát không quan trọng, mà là IBRL không nắm bắt được cách Harmonic đạt được nó, và có thể phân loại sai cơ chế đấu giá của họ thành "trò chơi thời điểm". Ở giai đoạn này, tôi chưa có đủ nền tảng kỹ thuật hoặc dữ liệu để hình thành quan điểm rõ ràng, nhưng Solana đã và đang phát triển một giải pháp trong giao thức nhằm giải quyết vấn đề khuyến khích cơ bản.
Giải pháp đó là Đề xuất Đồng thời Nhiều (MCP), một kiến trúc được phát triển bởi Anatoly Yakovenko và Max Resnick. Động cơ rất đơn giản: trong mô hình Người Lãnh đạo đơn lẻ ngày nay, một người đề xuất kiểm soát việc sắp xếp thứ tự, và trên thực tế có thể hành động muộn hơn những người khác, từ đó cho phép đóng gói trễ và củng cố động lực kiểu PFOF nêu trên. MCP loại bỏ sự độc quyền của người lãnh đạo đơn lẻ bằng cách để nhiều người đề xuất xây dựng các khối ứng cử viên một cách độc lập và song song. Kiến trúc này ngăn chặn một Người Lãnh đạo đơn phương đàn áp giao dịch hoặc trì hoãn thực thi để chiết xuất lợi nhuận.
Tuy nhiên, một điều kiện tiên quyết cho MCP là Alpenglow phải ra mắt mainnet. Alpenglow dự kiến ra mắt vào năm 2026, nhưng lịch trình vẫn chưa chắc chắn. Trong khi chờ đợi, BAM của Jito có thể thúc đẩy sự thay đổi bằng cách làm cho logic sắp xếp thứ tự có thể kiểm tra được. BAM nhằm mở rộng không gian thiết kế vi cấu trúc của Solana, cho phép các ứng dụng cần kiểm soát sắp xếp thứ tự tinh vi hơn (ví dụ: ưu tiên xử lý lệnh hủy tại sàn giao dịch hợp đồng vĩnh viễn) đồng thời giúp giảm thiểu các tác động ngoại lai MEV tiêu cực, như giao dịch trước (frontrunning). Sơ đồ dưới đây phác thảo quy trình xử lý giao dịch của BAM.
Đáng chú ý theo dõi động thái cạnh tranh về xây dựng khối sẽ phát triển như thế nào trong những tháng tới, và điều đó có ý nghĩa gì đối với cấu trúc thị trường của Solana.
