Bên trong nguyên nhân dẫn đến tình trạng trình xác thực hoạt động chậm của Solana

Trong những năm qua, khi các lỗi trong mã nguồn của Solana đã được xử lý, thời gian tạo khối – tức là khoảng thời gian để mạng lưới tạo ra một khối giao dịch mới – đã liên tục giảm, thậm chí từng có thời điểm thấp hơn ngưỡng 400 mili giây mặc định của Solana.

Tuy nhiên, trong tháng vừa qua, một xu hướng thú vị đã xuất hiện: Thời gian tạo khối trung bình đột ngột tăng lên, khiến tốc độ ghi nhận giao dịch mới trên chuỗi của Solana trở nên chậm hơn đáng kể so với trước đây. Nguyên nhân xuất phát từ một “meta” mới trong cộng đồng validator Solana, cho thấy việc chủ động trì hoãn sản xuất khối có thể mang lại lợi ích kinh tế. Theo ghi nhận của Blockworks, các bên như Anza, Jito và Marinade đang xem xét các phương án khắc phục vấn đề này.

Độ dài epoch của Solana tăng mạnh trong tháng 6. Nguồn: Kamino

Trên Solana, mỗi khối đều có một validator giữ vai trò leader – người tập hợp giao dịch, tạo khối và phát sóng khối đó lên mạng lưới. Các leader sẽ nhận phí giao dịch từ những khối mà họ tạo ra. Lưu lượng lệnh càng lớn, cơ hội nhận phí càng nhiều, nên validator có thể tối ưu lợi nhuận bằng cách chờ đợi lâu hơn để gom nhiều giao dịch trong mỗi khối – ví dụ 500 mili giây thay vì 300 mili giây.

Ở mức cơ bản, nhiều validator Solana cố tình chờ đợi lâu nhất có thể để “nhồi” thật nhiều giao dịch vào khối, nhằm tối đa hóa phần thưởng. Chiến lược này đã khiến epoch trên Solana kéo dài hơn bình thường.

Điều này không phù hợp với định hướng của Solana – một mạng lưới ưu tiên tốc độ xử lý sánh ngang Nasdaq. Ngoài ra, số lượng epoch mỗi năm giảm cũng làm giảm bớt cơ hội lãi kép cho những người staking, theo ông Max Kaplan – Giám đốc Công nghệ của Sol Strategies.

Solana áp dụng cơ chế “grace ticks” (thời gian gia hạn), cho phép leader vẫn có thể xác nhận khối ngay cả khi quá thời hạn thông thường. Thiết kế này giúp những validator ở xa trung tâm không bị thiệt, nhưng đồng thời tạo điều kiện để một số validator cố ý nộp khối trễ.

Client thay thế Solana là Frankendancer cũng vừa triển khai bộ lập lịch tối đa hóa doanh thu. Kaplan cho biết các validator sử dụng client này có xu hướng tạo khối chậm hơn so với chuẩn mực.

Tuy nhiên, ông Kaplan nhấn mạnh tình trạng trì hoãn do Frankendancer gây ra tương đối nhẹ, không đến mức đáng lên án, đồng thời chiến lược trì hoãn khối vốn đã xuất hiện trên nhiều blockchain proof-of-stake khác. Việc nâng cấp Firedancer chỉ đơn giản khiến vấn đề trở nên dễ thấy hơn trên Solana. Phía Jump hiện chưa bình luận về vụ việc.

Đáng chú ý, kỹ sư phần mềm Firedancer – ông Michael McGee, đã giải thích hiện tượng này trong tập podcast Lightspeed gần đây.

Ông McGee nhận xét: “Một trong những điều nhóm chúng tôi nhận thấy ở validator hiện tại là việc trì hoãn xử lý giao dịch đôi khi giúp validator tạo ra khối sinh lời hơn.”

Nhà phân tích Victor Pham của Blockworks Research chỉ ra rằng các validator trì hoãn khối một cách rõ rệt chủ yếu đang sử dụng các bản tùy chỉnh của client Agave-Jito.

Chẳng hạn, trong epoch 802 – giữa tháng 6, thời gian tạo khối trung bình của Galaxy và Kiln đều vượt quá 570 mili giây. Nhiều validator không có nhãn cũng hoạt động chậm, trong khi validator của Temporal ghi nhận thời gian trung bình là 475 mili giây, theo dữ liệu từ Solana Compass.

Ông Ernest Oppetit, đồng sáng lập Kiln – validator lớn thứ sáu trên Solana theo tổng lượng stake – thừa nhận nhóm đã từng trì hoãn slot “một thời gian”, nhưng hiện đã chấm dứt hành động này.

Ông Oppetit chia sẻ: “Tại Kiln, chúng tôi tự hào mang lại tỷ suất staking APY hàng đầu thị trường mà vẫn đảm bảo an toàn. Đội ngũ luôn nghiên cứu phát triển nhiều khía cạnh kỹ thuật – kể cả các phương án về thời gian xử lý – đồng thời duy trì đối thoại thường xuyên với khách hàng, đội phát triển client và cả Foundation. Hiện nay, chúng tôi tuân thủ thông số kỹ thuật, không trì hoãn khối, dù vẫn còn nhiều đơn vị khác thực hiện. Về lâu dài, chúng tôi cho rằng động lực phần thưởng – khối sản xuất càng nhanh, phần thưởng càng thấp – cần được xử lý ở cấp độ giao thức.”

Khi được hỏi về việc validator của Temporal tham gia hiện tượng trì hoãn khối, Giám đốc kỹ thuật Ben Coverston cho biết: “Chúng tôi không phải là nguyên nhân khiến cộng đồng chú ý đến vấn đề này.”

Đại diện Galaxy cho biết: “Chúng tôi, với vai trò nhà cung cấp dịch vụ, cấu hình validator nhằm tối đa hóa lợi ích staking cho khách hàng. Trên Solana, điều này đôi khi đồng nghĩa với việc đề xuất khối chậm hơn bình thường để đạt phần thưởng cao hơn. Galaxy luôn lắng nghe ý kiến cộng đồng và hiện chúng tôi đã điều chỉnh thời gian tạo khối về mức chấp nhận được.”

Cộng đồng validator Solana nhìn chung phản đối cách làm chậm mạng, và các validator chậm đang vấp phải phản ứng gay gắt từ cộng đồng.

Trong thời gian tới, các biện pháp chế tài thậm chí sẽ quyết liệt hơn. Theo Blockworks, Jito dự kiến loại các validator chậm khỏi pool stake của mình – vốn là pool lớn nhất hệ sinh thái Solana.

Ông Brian Smith – Chủ tịch Jito Foundation – thông tin rằng đơn vị đang “soạn thảo đề xuất quản trị, trao quyền cho một hội đồng loại những validator chậm ra khỏi danh sách phân bổ JitoSOL. Đề xuất này sẽ sớm được công khai để cả cộng đồng cùng tham gia thảo luận.”

Ông Michael Repetny, đồng sáng lập Marinade – pool stake lớn thứ ba Solana, cho biết nhà cung cấp này đang “[xem xét] việc trình đề xuất lên cộng đồng để thảo luận về ưu và nhược điểm của việc cấm hoặc xử lý validator chậm như một tiêu chí vi phạm trong chiến lược phân bổ stake.”

Cải tiến ở tầng giao thức cũng đang được đẩy mạnh. Kho mã GitHub của Anza đã xuất hiện một đề xuất mới nhằm giảm một nửa thời gian “grace tick” của Solana. Ngoài ra, đề xuất cải tổ cơ chế đồng thuận của Solana dự kiến cũng sẽ khắc phục vấn đề.

Ông Brennan Watt, Phó chủ tịch phụ trách kỹ thuật của Anza, cho biết: “Alpenglow sẽ giải quyết vấn đề này thông qua việc triển khai tính năng skip vote (bỏ qua phiếu bầu).”

Theo chia sẻ mới nhất của ông Watt trên podcast Lightspeed, Anza hy vọng sẽ kịp triển khai Alpenglow lên mainnet trước thời điểm diễn ra hội nghị Breakpoint của Solana vào tháng 12 tới.

Tuyên bố miễn trừ trách nhiệm:

1. Bài viết này được đăng lại từ [Blockworks]. Mọi quyền tác giả thuộc về tác giả gốc [Jack Kubinec]. Nếu có ý kiến về việc chia sẻ lại bài viết này, vui lòng liên hệ đội ngũ Gate Learn để được xử lý nhanh chóng.
2. Miễn trừ trách nhiệm: Mọi quan điểm và ý kiến trong bài viết chỉ phản ánh ý kiến tác giả, không phải là lời khuyên đầu tư.
3. Các bản dịch bài viết sang ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Nếu không có sự cho phép, nghiêm cấm việc sao chép, phân phối hoặc đạo văn các bản dịch này.