Firedancer đã hoạt động, nhưng Solana đang vi phạm quy tắc an toàn mà Ethereum coi là không thể thương lượng

Sau ba năm phát triển, Firedancer đã ra mắt trên Solana mainnet vào tháng 12 năm 2024, sau khi đã tạo ra 50.000 khối trong 100 ngày thử nghiệm trên một số lượng nhỏ các validator.

Cột mốc này, được công bố ngày 12/12 bởi tài khoản chính thức của Solana, đánh dấu không chỉ là một bản nâng cấp hiệu suất. Nó đại diện cho nỗ lực thực sự đầu tiên của mạng lưới nhằm loại bỏ điểm nghẽn kiến trúc đã gây ra những sự cố gián đoạn nghiêm trọng nhất: sự phụ thuộc gần như hoàn toàn vào một client validator duy nhất.

Solana đã dành nhiều năm để quảng bá tính chất hoàn tất giao dịch dưới một giây và khả năng xử lý hàng nghìn giao dịch mỗi giây, nhưng tốc độ không còn ý nghĩa khi 70% đến 90% sức mạnh đồng thuận của mạng lưới chạy cùng một phần mềm.

Một lỗi nghiêm trọng trong client chiếm ưu thế đó có thể làm ngừng toàn bộ chuỗi, bất kể về mặt lý thuyết nó chạy nhanh như thế nào. Ethereum đã học được bài học này sớm trong quá trình chuyển đổi sang proof-of-stake và hiện coi sự đa dạng client là yếu tố không thể thương lượng cho cơ sở hạ tầng.

Solana đang cố gắng thực hiện cùng một sự thay đổi, nhưng bắt đầu từ một vị trí tập trung hơn nhiều.

Firedancer không phải là một bản vá hoặc một nhánh của client Agave dựa trên Rust hiện có. Đây là một bản viết lại hoàn toàn bằng C/C++, được xây dựng bởi Jump Crypto với kiến trúc lấy cảm hứng từ giao dịch tần suất cao, theo mô-đun.

Hai client không chia sẻ mã, ngôn ngữ, và đội ngũ bảo trì. Sự độc lập đó tạo ra một miền lỗi riêng biệt: một lỗi trong quản lý bộ nhớ của Agave hoặc bộ lập lịch giao dịch, về mặt lý thuyết, sẽ không làm sập một validator đang chạy Firedancer.

Đối với một mạng lưới đã trải qua bảy lần gián đoạn trong năm năm, năm trong số đó do lỗi phía client, sự tách biệt đó là điểm quan trọng.

Vấn đề độc canh mà Solana không thể thoát khỏi

Lịch sử gián đoạn của Solana được xem như một nghiên cứu điển hình về rủi ro client đơn lẻ. Một lần dừng vào tháng 6 năm 2022 kéo dài bốn giờ rưỡi sau khi một lỗi trong tính năng giao dịch durable-nonce khiến các validator mất đồng bộ, đòi hỏi phải khởi động lại có điều phối.

Các sự cố khác được xác định là do rò rỉ bộ nhớ, giao dịch trùng lặp quá mức, và điều kiện đua trong quá trình tạo khối. Phân tích của Helius về toàn bộ lịch sử gián đoạn cho thấy năm trong số bảy lần thất bại là do lỗi validator hoặc client, không phải do khiếm khuyết trong thiết kế đồng thuận.

Khả năng xử lý mà mạng lưới quảng cáo trở nên không liên quan khi một lỗi triển khai đơn lẻ có thể đóng băng quá trình tạo khối.

Các con số xác nhận mức độ phơi nhiễm. Báo cáo sức khỏe mạng lưới tháng 6 năm 2025 của Solana Foundation cho thấy Agave và biến thể Jito đã sửa đổi kiểm soát khoảng 92% SOL đã stake.

Đến tháng 10 năm 2025, con số đó đã giảm. Tuy nhiên, chỉ giảm nhẹ: tổng quan về staking của Cherry Servers và nhiều hướng dẫn validator báo cáo rằng client Jito-Agave vẫn nắm giữ hơn 70% stake, ngay cả khi client lai Frankendancer tăng lên khoảng 21% mạng lưới.

Frankendancer sử dụng lớp mạng của Firedancer với backend đồng thuận của Agave.

Mặc dù vẫn là thiểu số, dữ liệu của Cherry Servers lưu ý rằng thị phần của Frankendancer đã tăng từ khoảng 8% vào tháng 6. Những lợi ích đó thể hiện sự áp dụng ổn định của một giải pháp một phần, nhưng client Firedancer đầy đủ đến mainnet vào tháng 12 thay đổi phương trình.

Các validator giờ đây có thể chạy một stack hoàn toàn độc lập, loại bỏ sự phụ thuộc chung đã biến các lỗi client trong quá khứ thành các sự kiện trên toàn mạng.

Kinh nghiệm của Ethereum cung cấp mô hình tham chiếu.

Tài liệu về đa dạng client của Ethereum Foundation cảnh báo rằng bất kỳ client nào kiểm soát hơn hai phần ba sức mạnh đồng thuận có thể đơn phương hoàn tất các khối không chính xác. Ngoài ra, một client trên một phần ba có thể ngăn chặn hoàn toàn tính chất hoàn tất nếu nó ngoại tuyến hoặc hoạt động không thể dự đoán được.

Cộng đồng Ethereum coi việc giữ tất cả các client dưới 33% là yêu cầu an toàn cứng, không phải là sự tối ưu hóa. Vị trí xuất phát của Solana với một client gần 90% tham gia nằm xa bên ngoài vùng an toàn đó.

Client	Ngôn ngữ	Trạng thái	Thị phần Stake (Tháng 10/2025)	Validators	Độc lập thực sự
Jito	Rust	Mainnet	~72%	~700+	Fork of Agave
Frankendancer	C + Rust	Mainnet	~21%	207	Hybrid Independent
Agave	Rust	Mainnet	~7%	~85	Original
Firedancer	C	Non-voting mainnet	0%	0	Fully Independent

Firedancer thực sự thay đổi điều gì

Firedancer triển khai lại pipeline validator của Solana với kiến trúc vay mượn từ các hệ thống giao dịch độ trễ thấp: các ô xử lý song song, các nguyên thủy mạng tùy chỉnh, và quản lý bộ nhớ được điều chỉnh cho hiệu suất xác định dưới tải.

Các điểm chuẩn từ các bài thuyết trình hội nghị kỹ thuật đã cho thấy client xử lý 600.000 đến hơn 1.000.000 giao dịch mỗi giây trong các bài kiểm tra có kiểm soát, cao hơn nhiều so với khả năng xử lý đã chứng minh của Agave.

Nhưng giới hạn hiệu suất ít quan trọng hơn sự tách biệt miền lỗi. Tài liệu Firedancer và hướng dẫn thiết lập validator mô tả client là thiết kế theo mô-đun, với các thành phần riêng biệt xử lý mạng, tham gia đồng thuận và thực thi giao dịch.

Một lỗi hỏng bộ nhớ trong bộ phân bổ Rust của Agave sẽ không lan truyền đến codebase C++ của Firedancer. Một lỗi logic trong bộ lập lịch khối của Agave sẽ không ảnh hưởng đến mô hình thực thi dựa trên ô của Firedancer.

Hai client có thể thất bại độc lập, điều đó có nghĩa là mạng lưới có thể sống sót sau một lỗi nghiêm trọng trong một trong hai client miễn là phân phối stake ngăn chặn một siêu đa số bị ngoại tuyến đồng thời.

Việc triển khai Frankendancer lai đóng vai trò như một bản triển khai theo giai đoạn. Các nhà điều hành đã thay thế các thành phần mạng và sản xuất khối của Agave bằng các thành phần tương đương của Firedancer trong khi vẫn giữ các lớp đồng thuận và thực thi của Agave.

Cách tiếp cận đó cho phép các validator áp dụng các cải tiến hiệu suất của Firedancer mà không gây rủi ro cho toàn bộ mạng lưới trên mã đồng thuận chưa được kiểm tra.

21% stake mà Frankendancer nắm giữ vào tháng 10 đã xác nhận mô hình lai nhưng cũng làm nổi bật giới hạn của nó: miễn là tất cả các validator vẫn phụ thuộc vào Agave để đồng thuận, một lỗi trong lớp chia sẻ đó vẫn có thể làm đình trệ chuỗi.

Việc ra mắt mainnet của client đầy đủ vào tháng 12 loại bỏ sự phụ thuộc chia sẻ đó.

Một số ít validator đã chạy Firedancer trong 100 ngày và tạo ra 50.000 khối đã chứng minh rằng client có thể tham gia vào đồng thuận, tạo ra các khối hợp lệ và duy trì trạng thái mà không phụ thuộc vào bất kỳ thành phần nào của Agave.

Thành tích sản xuất là hẹp, 100 ngày trên một vài node, nhưng đủ để mở cửa cho việc áp dụng rộng rãi hơn. Các validator hiện có một lựa chọn thay thế thực sự, và khả năng phục hồi của mạng lưới tỷ lệ trực tiếp với số lượng validator chọn di chuyển.

Tại sao các tổ chức quan tâm đến phần mềm validator

Mối liên hệ giữa sự đa dạng client và việc áp dụng của các tổ chức không phải là suy đoán.

Bài giải thích về Firedancer của Levex lập luận rằng client "giải quyết các mối quan tâm chính mà các nhà đầu tư tổ chức đã nêu ra về độ tin cậy và khả năng mở rộng của Solana" và rằng dự phòng đa client "cung cấp sự mạnh mẽ mà các doanh nghiệp yêu cầu cho các ứng dụng quan trọng."

Một bài viết của Binance Square vào tháng 9 về sự sẵn sàng của Solana cho các tổ chức coi các sự cố gián đoạn trong quá khứ là trở ngại chính cho sự tham gia của doanh nghiệp và định vị Firedancer như "phương thuốc tiềm năng."

Phân tích lập luận rằng độ tin cậy là "yếu tố khác biệt chính" trong cuộc cạnh tranh của Solana với Ethereum và các mạng layer-1 khác, và việc loại bỏ rủi ro client đơn lẻ "có thể loại bỏ điểm yếu lớn nhất của Solana" trong các bài thuyết trình cho các tổ chức không thể chấp nhận thời gian ngừng hoạt động ở cấp độ mạng.

Logic này phản ánh khuôn khổ được thiết lập cho chiến dịch đa dạng hóa client của Ethereum.

Các đội ngũ đánh giá rủi ro của tổ chức đánh giá cơ sở hạ tầng blockchain muốn biết điều gì xảy ra khi có sự cố.

Một mạng lưới mà 90% validator chạy cùng một client có một điểm lỗi duy nhất, bất kể phân phối token hoặc tập hợp validator của nó có vẻ phi tập trung như thế nào trên giấy tờ.

Một mạng lưới mà không có client nào kiểm soát hơn 33% stake có thể mất toàn bộ một client do lỗi nghiêm trọng và tiếp tục hoạt động. Sự khác biệt đó là nhị phân đối với các nhà quản lý rủi ro quyết định có nên xây dựng các sản phẩm được quy định trên một chuỗi nhất định hay không.

Khoảng 767 triệu đô la của Solana trong tài sản thế giới thực được token hóa đại diện cho một chỗ đứng, không phải là sự áp dụng ở quy mô lớn. Ethereum lưu trữ 12,5 tỷ đô la trong Kho bạc được token hóa, stablecoin và quỹ được token hóa, theo dữ liệu của rwa.xyz.

Khoảng cách phản ánh không chỉ hiệu ứng mạng lưới hoặc sự quan tâm của nhà phát triển, mà còn là niềm tin vào thời gian hoạt động.

Sự xuất hiện của Firedancer trên mainnet mang lại cho Solana một con đường để thu hẹp khoảng cách đó bằng cách đáp ứng cùng một ngưỡng đa dạng client mà cộng đồng Ethereum coi là điều kiện cơ bản cho cơ sở hạ tầng sản xuất.

Đường cong áp dụng phía trước

Quá trình chuyển đổi từ sự thống trị 70% của Agave sang một mạng lưới đa client cân bằng sẽ không xảy ra nhanh chóng. Các validator phải đối mặt với chi phí chuyển đổi: Firedancer đòi hỏi điều chỉnh phần cứng khác nhau, sổ tay vận hành khác nhau và đặc điểm hiệu suất khác nhau so với Agave.

Thành tích sản xuất 100 ngày của client, mặc dù thành công, nhưng nông so với nhiều năm hoạt động mainnet của Agave. Các nhà điều hành né tránh rủi ro sẽ chờ đợi thêm dữ liệu trước khi di chuyển stake.

Tuy nhiên, cấu trúc khuyến khích hiện ủng hộ sự đa dạng hóa. Báo cáo sức khỏe validator của Solana Foundation theo dõi công khai phân phối client, tạo áp lực về danh tiếng đối với các nhà điều hành lớn để tránh các vị trí tập trung trong bất kỳ triển khai đơn lẻ nào.

Lịch sử gián đoạn của mạng lưới cung cấp một lời nhắc nhở sâu sắc về mặt tiêu cực. Và câu chuyện về việc áp dụng của các tổ chức, với đầu cơ ETF, phát hành RWA và các thử nghiệm thanh toán doanh nghiệp, phụ thuộc vào việc chứng minh rằng Solana đã vượt qua các vấn đề về độ tin cậy của mình.

Kiến trúc hiện đã được thiết lập. Solana có hai client sản xuất, bằng các ngôn ngữ khác nhau, với codebase độc lập và các chế độ lỗi riêng biệt. Khả năng phục hồi của mạng lưới phụ thuộc vào tốc độ stake di chuyển từ nền văn hóa đơn canh mà nó bắt đầu đến một phân phối mà không có client đơn lẻ nào có thể làm cho chuỗi ngoại tuyến.

Đối với các tổ chức đánh giá liệu Solana có thể hoạt động như cơ sở hạ tầng sản xuất và có con đường thực tế để sống sót sau lỗi client tiếp theo mà không cần khởi động lại có điều phối.

Bài viết Firedancer đã hoạt động, nhưng Solana đang vi phạm quy tắc an toàn mà Ethereum coi là không thể thương lượng xuất hiện đầu tiên trên CryptoSlate.