Gulf Stream của Solana: Càng nhiều mempool, càng nhiều vấn đề

Những điểm chính có thể áp dụng

• Thuật ngữ "Gulf Stream" có thể được định nghĩa một cách khái quát là quá trình diễn ra từ lúc một node tiếp nhận giao dịch trên mạng cho đến khi giao dịch đến leader của slot hiện tại và được Fetch Stage của TPU (Đơn vị xử lý giao dịch) tiếp nhận.
• Solana nổi bật vì ngay từ đầu đã được thiết kế để vận hành mà không cần mempool. Không giống các blockchain truyền thống hơn vốn sử dụng giao thức gossip để truyền bá rộng rãi giao dịch trên toàn mạng, Solana chuyển tiếp mọi giao dịch đến một validator dẫn đầu được xác định trước, gọi là leader, cho mỗi slot. Leader luân phiên sau mỗi 4 slot, còn lịch leader được mọi node đang hoạt động trên mạng biết trước, qua đó bảo đảm việc chuyển tiếp giao dịch hiệu quả.
• Theo mặc định, giao dịch Solana phải chứa một blockhash gần đây mà nhà phát triển có thể dễ dàng yêu cầu qua một lệnh gọi API đơn giản. Một blockhash gần đây có hiệu lực tối đa 150 slot, tương đương khoảng 1 phút. Sau khoảng thời gian này, blockhash trở nên lỗi thời và các giao dịch tham chiếu đến nó sẽ bị mạng loại bỏ. Điều này bảo đảm các giao dịch chưa được xử lý không thể tồn đọng. Blockhash gần đây cũng hỗ trợ loại bỏ giao dịch trùng lặp. Nhà phát triển còn có thể thêm durable nonce.
• Các giao dịch trong Gulf Stream được mã hóa và gửi đến leader qua các luồng QUIC. Việc áp dụng QUIC vào cuối năm 2022 là một nâng cấp mạng quan trọng, thay thế các kết nối UDP được sử dụng trước đó. Động lực chính của thay đổi này là tăng cường khả năng lọc spam của mạng. Tuy nhiên, việc chuyển sang QUIC đã gây ra một số tranh luận khi Solana ghi nhận mức độ hoạt động chưa từng có trong suốt năm 2024.
• Việc ra mắt Chất lượng dịch vụ theo trọng số stake (SWQoS) vào đầu năm 2024 đã tạo ra thay đổi sâu sắc trong cách giao dịch đến leader thông qua Gulf Stream. Giờ đây, leader ưu tiên các thông điệp giao dịch được proxy qua những validator có stake khác. Cụ thể, 80% dung lượng của leader (2.000 kết nối) được dành cho các peer có stake, còn 20% (500 kết nối) được phân bổ cho thông điệp giao dịch từ các node không có stake.
• Hiện tại, hơn 80% stake trên Solana được khóa với các validator chạy client Jito-Solana thay vì client Agave nguyên bản. Jito đưa vào một phiên đấu giá không gian khối ngoài giao thức, làm tăng thêm độ phức tạp trong cách giao dịch đến leader. Cụ thể, Jito relayer thêm một “gờ giảm tốc” 200 mili giây để làm chậm luồng thông điệp giao dịch đến, giúp các searcher có đủ thời gian gửi bundle.

Giới thiệu

Thuật ngữ "Gulf Stream" bắt nguồn từ một loạt bài blog giới thiệu do đội ngũ sáng lập Solana viết vào năm 2019, trong đó họ đặt tên theo chủ đề hàng không cho nhiều cơ chế đổi mới của Solana. Trong các bài viết này, Gulf Stream được định nghĩa là “giao thức chuyển tiếp giao dịch không dùng mempool” của Solana. Tuy nhiên, khi tìm kiếm thuật ngữ “Gulf Stream” trong codebase Solana hiện nay, kết quả chỉ trả về một đề cập không đáng kể.

Trong bối cảnh rộng hơn của vòng đời giao dịch Solana, “Gulf Stream” có thể được hiểu là toàn bộ quá trình diễn ra từ lúc một giao dịch được node mạng, thường là RPC, tiếp nhận cho đến khi giao dịch đến leader của slot hiện tại (tức là khi được “fetch stage” của TPU tiếp nhận). Cũng có thể hình dung Gulf Stream là hình ảnh phản chiếu của Turbine, cơ chế truyền bá khối của Solana, vì Gulf Stream là cách giao dịch đến leader, còn Turbine là cách các giao dịch đã xử lý rời khỏi leader.

Trước tiên, sẽ hữu ích nếu định nghĩa các node RPC (Lệnh gọi thủ tục từ xa) trong bối cảnh Solana. Có thể xem các node này là cổng để tương tác và đọc dữ liệu từ mạng. Chúng đóng vai trò trung gian giữa người dùng và các validator của Solana. RPC chạy cùng phần mềm với validator đầy đủ nhưng có cấu hình khác, cho phép mô phỏng giao dịch chính xác và duy trì góc nhìn cập nhật về trạng thái hiện tại (bank). Tuy nhiên, các node RPC không có stake nên không tham gia đồng thuận. Khi không có stake, chúng không thể bỏ phiếu hoặc xây dựng khối. Thiết lập này khác với nhiều blockchain khác, nơi validator và node RPC thường là một. Đối với Gulf Stream, có thể tóm tắt vai trò của RPC như sau: nhận giao dịch qua HTTP, chuyển giao dịch sang QUIC (sẽ trình bày thêm ở phần sau), tra cứu địa chỉ và thông tin cổng của leader hiện tại bằng lịch leader, rồi chuyển tiếp giao dịch đến leader hiện tại và leader tiếp theo.

Kể từ khi mạng ra đời, Gulf Stream đã trải qua ít nhất hai đợt nâng cấp lớn là QUIC và QoS theo trọng số stake. Hai nội dung này sẽ được thảo luận chi tiết ở phần sau. Đây cũng có thể xem là phần của giao thức lõi chịu nhiều áp lực nhất trong những năm gần đây do lưu lượng mạng chưa từng có của Solana. Để hình dung rõ hơn, khi một validator trở thành leader, lưu lượng đến có thể tăng vọt lên hơn một gigabyte mỗi giây vì toàn bộ mạng hướng các gói tin về phía validator đó. Xử lý khối lượng dữ liệu đầu vào lớn như vậy là một thách thức kỹ thuật đáng kể.

Càng nhiều mempool, càng nhiều vấn đề

Định nghĩa ban đầu của đội ngũ sáng lập về Gulf Stream nhấn mạnh việc không có mempool. Có thể định nghĩa mempool, nghĩa đen là “bể nhớ”, là tập hợp các giao dịch đã được người dùng gửi và đang chờ mạng xử lý. Những giao dịch này thường không được mã hóa hoặc che giấu khi chờ công khai. Chúng được truyền bá trên toàn mạng bằng giao thức gossip. Tùy từng mạng, các giao dịch đã ký có thể tồn tại vô thời hạn trong mempool cho đến khi đáp ứng đủ điều kiện thực thi. Điều này đặc biệt đúng với những giao dịch đặt phí giao dịch, tức giá trên mỗi đơn vị tính toán, thấp hơn đáng kể so với khoảng giá thị trường thông thường. Trong trường hợp cực đoan, các giao dịch như vậy có thể mất nhiều ngày hoặc nhiều tuần mới được thực thi nếu điều kiện mạng không thuận lợi để đưa chúng vào một khối.

Kịch bản như vậy không thể xảy ra trên Solana. Solana không chỉ không có khái niệm mempool gốc mà còn yêu cầu mọi thông điệp giao dịch phải chứa một blockhash gần đây. Nhà phát triển có thể dễ dàng yêu cầu blockhash gần đây thông qua lệnh gọi JSON RPC API đến phương thức getLatestBlockhash. Blockhash này được nhúng trong thông điệp giao dịch và có hiệu lực tối đa 150 slot, tương đương khoảng 1 phút khi thời gian mục tiêu của mỗi slot là 400 mili giây. Sau 150 slot, blockhash trở nên lỗi thời và các giao dịch tham chiếu đến nó sẽ bị mạng loại bỏ. Theo mặc định, RPC cố gắng chuyển tiếp giao dịch sau mỗi 2 giây, nhưng khi blockhash gần đây hết hạn, giao dịch sẽ bị loại bỏ và được bảo đảm là không bao giờ thực thi on-chain.

Blockhash gần đây cũng là một cách phát hiện và loại bỏ giao dịch trùng lặp. Trên các mạng khác, điều này được thực hiện bằng cách bắt buộc thêm nonce, tức một số chỉ dùng một lần. Mặc dù có những phương thức để nhà phát triển thêm durable nonce vào giao dịch Solana trong một số trường hợp chuyên biệt, nonce không bắt buộc phải có trong giao dịch Solana tiêu chuẩn.

Hệ thống Gulf Stream của Solana khả thi vì mọi node đang hoạt động luôn biết trước lịch leader. Các node cập nhật lịch leader mỗi khi chiều cao slot vượt qua ranh giới epoch, tức khoảng 2 ngày một lần. Lịch leader của một epoch được tính từ trạng thái sổ cái ở đầu epoch trước đó. Quy trình thuật toán để tạo lịch leader như sau:

• Định kỳ sử dụng chiều cao tick của proof of history (PoH), tức một bộ đếm tăng đơn điệu, làm seed cho một thuật toán giả ngẫu nhiên ổn định.
• Tại chiều cao đó, lấy mẫu từ bank gồm tất cả account có stake với danh tính leader đã bỏ phiếu trong số tick do cluster cấu hình. Mẫu này được gọi là tập hợp đang hoạt động.
• Sắp xếp tập hợp đang hoạt động theo trọng số stake.
• Sử dụng seed ngẫu nhiên để chọn các node theo trọng số stake, từ đó tạo thứ tự theo trọng số stake.
• Thứ tự này có hiệu lực sau số tick do cluster cấu hình.

Nguồn: Tài liệu chính thức của Solana

Việc áp dụng trọng số stake bảo đảm các node đáng tin cậy có stake cao sẽ có xác suất được chọn làm leader thường xuyên hơn, còn các node có stake thấp được chọn ít hơn hoặc hoàn toàn không được chọn. 

‍Phân bổ tài nguyên theo trọng số stake là một chủ đề xuyên suốt giao thức lõi Solana, bao gồm phần thưởng bỏ phiếu, cây Turbine, lịch leader và mạng gossip*. Ngay cả Gulf Stream cũng áp dụng trọng số stake, như sẽ được trình bày ở phần sau.

Lưu ý về QUIC

Bản cập nhật lớn đầu tiên của Gulf Stream xuất hiện vào cuối năm 2022  khi giao thức mạng QUIC được áp dụng để xử lý việc truyền thông điệp giao dịch đến leader. Nâng cấp này được thúc đẩy bởi tình trạng gián đoạn mạng do các cuộc tấn công DDoS và giao dịch spam làm ngập blockchain trong những đợt mint NFT. Sau khi QUIC được tích hợp đầy đủ vào Mainnet-Beta trong bản phát hành 1.13.4, độ ổn định của mạng đã được cải thiện.

Trước đây, Solana dựa vào giao thức mạng UDP (Giao thức gói dữ liệu người dùng) để gửi giao dịch từ các node RPC đến leader hiện tại. Dù nhanh và hiệu quả, UDP không cần kết nối, đồng thời thiếu cả khả năng kiểm soát luồng lẫn xác nhận đã nhận. Vì vậy, không có cách hữu hiệu để ngăn chặn hoặc giảm thiểu hành vi lạm dụng. Nhằm kiểm soát lưu lượng mạng, giao thức tiếp nhận giao dịch của validator, tức Fetch Stage của TPU, đã được triển khai lại bằng QUIC.

Được Google phát triển lần đầu vào năm 2012, QUIC hướng đến việc kết hợp những ưu điểm tốt nhất của cả TCP và UDP. Giao thức này hỗ trợ giao tiếp nhanh, bất đồng bộ tương tự UDP, nhưng có các phiên bảo mật và chiến lược kiểm soát luồng nâng cao của TCP. Nhờ đó, mạng có thể đặt giới hạn cho từng nguồn lưu lượng để tập trung xử lý các giao dịch thực. QUIC cũng có khái niệm các luồng riêng biệt, nên nếu một giao dịch bị loại bỏ thì các giao dịch còn lại không bị chặn. Google là động lực chính thúc đẩy việc áp dụng QUIC trên toàn Web2. Các kết nối đến máy chủ Google được thiết lập bằng QUIC, đồng nghĩa nhiều ứng dụng thuộc Google sử dụng QUIC, chẳng hạn như Hangouts, Gmail và YouTube. Ngoài ra, QUIC không phải là từ viết tắt mà là tên thực tế của giao thức. 

Dù vậy, hiệu quả của việc triển khai QUIC trên Solana vẫn còn gây tranh luận. Khi lưu lượng mạng tăng đột biến, validator có thể bị quá tải bởi các phiên bắt tay QUIC. Có thể nói QUIC chưa phải giải pháp toàn diện như một số người kỳ vọng ban đầu để khắc phục vấn đề tắc nghẽn ở cấp độ mạng. Cũng cần lưu ý rằng ngoài cách triển khai của Solana, QUIC chưa được áp dụng rộng rãi trong ngành blockchain. Một số thành viên trong cộng đồng validator Solana đã công khai chỉ trích giao thức này và cho rằng việc áp dụng QUIC là một bước đi sai lầm.

Chất lượng dịch vụ theo trọng số stake (SWQoS)

Đầu năm 2024, Chất lượng dịch vụ theo trọng số stake (SWQoS) được áp dụng làm cơ chế ngăn chặn spam và tăng khả năng kháng Sybil. Hệ thống này cho phép leader ưu tiên các thông điệp giao dịch được định tuyến qua validator có stake. Validator có stake cao hơn được cấp dung lượng truyền các gói thông điệp giao dịch đến leader lớn hơn theo tỷ lệ, qua đó giảm thiểu hiệu quả các cuộc tấn công Sybil từ node không có stake hoặc có ít stake trên toàn mạng. Việc phân đoạn này khả thi vì địa chỉ IP có thể được xác minh qua QUIC, cho phép validator ưu tiên và giới hạn lưu lượng của từng kết nối cụ thể. 

Với SWQoS, validator có thể cho các node RPC thuê dung lượng theo trọng số stake của mình. Đổi lại, node RPC có thêm băng thông, giúp đạt tỷ lệ giao dịch được đưa vào khối cao hơn. Đáng chú ý, 80% dung lượng của leader (2.000 kết nối) được dành cho QoS theo trọng số stake, còn 20% (500 kết nối) được phân bổ cho thông điệp giao dịch từ các node khác. Chiến lược phân bổ này tương tự hệ thống làn ưu tiên trên đường cao tốc, nơi tài xế trả phí để tránh tắc đường.

Lượng stake tối thiểu cần có để đủ điều kiện trở thành peer có stake hiện là 0,04% tổng stake. Tại thời điểm viết bài, tổng stake là 384 triệu SOL, nên yêu cầu tối thiểu này tương đương 15.360 SOL.‍

SWQoS đã tác động đáng kể đến hệ sinh thái Solana khi nâng cao yêu cầu để chuyển tiếp giao dịch đến leader và làm giảm hiệu quả của các cuộc tấn công spam. Thay đổi này đã khuyến khích các ứng dụng có lưu lượng cao tích hợp hoạt động theo chiều dọc. Bằng cách vận hành node validator riêng, ứng dụng có thể bảo đảm quyền truy cập ưu tiên vào leader, từ đó nâng cao năng lực xử lý giao dịch. Tại Helius, chúng tôi tự hào vận hành một trong những validator hàng đầu trên mạng xét theo lượng stake, qua đó giúp chúng tôi bảo đảm nhiều giao dịch được đưa vào khối hơn. Tìm hiểu thêm về cách stake cùng chúng tôi trong hướng dẫn chi tiết tại đây.

Gờ giảm tốc Jito

Bài viết này sẽ thiếu sót nếu không đề cập đến Jito, vì tại thời điểm viết bài, hơn 80% stake của mạng sử dụng client validator Jito. Client này làm tăng thêm độ phức tạp cho cách giao dịch thường đến leader. Client validator Jito-Solana (Github) là một fork của client Agave (Github), trước đây là client Solana Labs. Nó đưa vào một phiên đấu giá không gian khối ngoài giao thức và cho phép validator nhận thêm động lực kinh tế dưới dạng tiền tip.

Việc phân tích toàn diện client Jito nằm ngoài phạm vi bài viết này, vì vậy chúng tôi chỉ tập trung vào cách client Jito ảnh hưởng đến luồng giao dịch thông thường qua Gulf Stream. Giao dịch có hai tuyến khả dĩ: chúng đi từ RPC đến một validator được ghép cặp rồi đến leader hiện tại (tuyến theo trọng số stake), hoặc được chuyển tiếp trực tiếp đến leader (tuyến kết nối mở). Trong cả hai trường hợp, nếu leader đang chạy client Jito-Solana, các giao dịch này trước tiên sẽ được gửi đến Jito-Relayer (Github), một phần mềm nguồn mở hoạt động như bộ định tuyến proxy giao dịch. 

Các node khác trên mạng không nhận biết Jito-Relayer. Chúng chỉ gửi giao dịch đến bất kỳ cấu hình địa chỉ và cổng nào mà leader đã chọn phát qua mạng gossip làm ingress_socket của mình. Relayer trì hoãn giao dịch 200 mili giây trước khi chuyển tiếp đến leader. Cơ chế “gờ giảm tốc” này làm chậm luồng thông điệp giao dịch đến và hỗ trợ các phiên đấu giá thời gian rời rạc hiệu quả. Sau 200 mili giây, relayer chủ động giải phóng các giao dịch bất kể kết quả đấu giá.

Trước đây, Jito vận hành một dịch vụ mempool ngoài giao thức chính thức, nhưng dịch vụ này hiện đã ngừng hoạt động. Khi một validator Jito-Solana là leader, các searcher vẫn có thể gửi các nhóm giao dịch được thực thi nguyên tử, gọi là bundle, cho những loại giao dịch MEV khác không phụ thuộc vào mempool, chẳng hạn như giao dịch chênh lệch giá và thanh lý.

Để tìm hiểu thêm, hãy tham khảo bài viết trên blog Helius tại đây, trong đó giới thiệu về MEV trên Solana.

Kết luận

Trong bài viết này, chúng ta đã xem xét nhiều khía cạnh của Gulf Stream trên Solana, bao gồm giao thức mạng QUIC, QoS theo trọng số stake và thiết lập validator Jito. Chúng ta đã đối chiếu Gulf Stream với kiến trúc mempool truyền thống hơn, đồng thời trình bày lợi ích từ cách tiếp cận của Solana về hiệu quả cao hơn và độ trễ thấp hơn. 

Không còn nghi ngờ gì rằng Gulf Stream sẽ tiếp tục phát triển. Giao thức Solana và hệ sinh thái rộng lớn hơn đang tiến triển nhanh chóng, với nhiều nâng cấp quan trọng được kỳ vọng. Một ví dụ là Anatoly Yakovenko, đồng sáng lập Solana, đã mạnh mẽ ủng hộ việc triển khai nhiều leader đồng thời. Nhiều leader đồng thời sẽ cho phép nhiều node trên toàn thế giới đồng thời sắp xếp giao dịch của người dùng, giảm độ trễ và loại bỏ nhu cầu thực hiện một vòng truyền toàn cầu đầy đủ trong trường hợp xấu nhất trước khi giao dịch được thêm vào blockchain.

Solana sẽ không đứng yên, và một tương lai đầy hứa hẹn đang chờ đón toàn bộ giao thức, bao gồm Gulf Stream. Vì vậy, nhà phát triển nên chuẩn bị đón nhận nhiều bản cập nhật và tối ưu hóa hơn nữa.

Nếu đã đọc đến đây, cảm ơn bạn! Hãy cân nhắc tham gia cộng đồng của chúng tôi trên Discord, theo dõi chúng tôi trên X hoặc đăng ký danh sách email bên dưới.‍

Xin chân thành cảm ơn Jacob Creech và 0xIchigo đã đánh giá các phiên bản trước của bài viết này.‍

Tài nguyên bổ sung

• Gulf Stream: Giao thức chuyển tiếp giao dịch không dùng mempool của Solana
• QUIC, phương thức truyền tải đa hợp trên UDP
• Hướng dẫn toàn diện về HTTP/3 và QUIC
• Tổng hợp các liên kết về SWQoS
• Hướng dẫn về Chất lượng dịch vụ theo trọng số stake trên Solana
• Đào tạo về validator Solana — QoS theo trọng số stake
• Tài liệu Jito Relayer
• Thực thi bất đồng bộ, kiến trúc đích cuối

‍