Các lỗ hổng bảo mật quan trọng của Solana đã tiết lộ những thách thức trong việc điều phối các mạng "luôn hoạt động"

Nguồn: CryptoNewsNet Tiêu đề gốc: Lỗ hổng đáng sợ của Solana vừa phơi bày cách dễ dàng mạng “luôn hoạt động” có thể bị tắc nghẽn bởi hacker Liên kết gốc: Khi các nhà duy trì Solana yêu cầu các validator nhanh chóng cập nhật Agave v3.0.14, thông điệp đến kèm sự cấp bách hơn là chi tiết.

Tài khoản Trạng thái Solana gọi bản phát hành này là “khẩn cấp” và cho biết nó chứa “bộ vá lỗi quan trọng” cho các validator Mainnet Beta.

Trong vòng một ngày, cuộc trò chuyện công khai chuyển hướng sang một câu hỏi khó hơn: nếu một mạng proof-of-stake cần nâng cấp nhanh chóng và phối hợp, điều gì xảy ra khi các nhà vận hành không cùng nhau di chuyển?

Khoảng cách đó đã xuất hiện trong các bản chụp nhanh về việc chấp nhận ban đầu. Vào ngày 11 tháng 1, một tài khoản phổ biến cho biết chỉ có 18% cổ phần đã chuyển sang v3.0.14 vào thời điểm đó, để lại phần lớn trọng lượng kinh tế của mạng trên các phiên bản cũ hơn trong giai đoạn được gọi là khẩn cấp.

Đối với một chuỗi đã dành cả năm qua để bán độ tin cậy cùng tốc độ, câu chuyện chuyển từ mã nguồn sang việc liệu đội ngũ vận hành có thể hội tụ đủ nhanh khi cần thiết hay không.

Trong khoảng mười ngày tiếp theo, bức tranh trở nên rõ ràng hơn và hữu ích hơn so với các tiêu đề của làn sóng đầu tiên.

Anza, nhóm đứng sau Agave, đã công bố tóm tắt vá lỗi bảo mật vào ngày 16 tháng 1 giải thích tại sao v3.0.14 quan trọng và tại sao các nhà vận hành được yêu cầu nâng cấp nhanh chóng.

Cùng thời điểm đó, hệ sinh thái Solana báo hiệu rằng việc phối hợp không chỉ dựa vào thiện chí, vì tiêu chí ủy quyền của Quỹ Solana giờ đây rõ ràng tham chiếu các phiên bản phần mềm bắt buộc, bao gồm Agave 3.0.14 và Frankendancer 0.808.30014, như một phần của các tiêu chuẩn mà validator phải đáp ứng để nhận cổ phần ủy quyền.

Tổng thể, những diễn biến này biến v3.0.14 thành một nghiên cứu điển hình về những gì “tài chính luôn hoạt động” đòi hỏi trong thực tế trên Solana, không chỉ từ phần mềm mà còn từ các động lực và hành vi của nhà vận hành dưới áp lực thời gian.

Chuỗi tốc độ cao vẫn hoạt động dựa trên hoạt động của con người

Solana là một blockchain proof-of-stake được thiết kế để xử lý khối lượng lớn giao dịch nhanh chóng, với các validator bỏ phiếu cho các khối và bảo vệ sổ cái tỷ lệ thuận với SOL đã ủy quyền cho họ.

Đối với người dùng không vận hành validator, việc ủy quyền sẽ chuyển cổ phần đến một nhà vận hành, và cổ phần đó vừa là đầu vào an ninh vừa là tín hiệu kinh tế thưởng cho các validator duy trì trực tuyến và hoạt động tốt.

Thiết kế đó có một hậu quả dễ bỏ qua nếu chỉ xem biểu đồ giá token. Một blockchain không chỉ là một máy móc ở một nơi. Trên Solana, “mạng lưới” là hàng nghìn nhà vận hành độc lập chạy phần mềm tương thích, nâng cấp vào các thời điểm khác nhau, trên các cấu hình lưu trữ khác nhau, với các mức tự động hóa và chịu rủi ro khác nhau.

Khi mọi thứ diễn ra suôn sẻ, sự độc lập này hạn chế các điểm kiểm soát đơn lẻ. Khi cần nâng cấp khẩn cấp, cùng sự độc lập này lại làm cho việc phối hợp trở nên khó khăn hơn.

Cảnh quan validator-client của Solana nâng cao rủi ro cho việc phối hợp. Chuỗi sản xuất phổ biến nhất là client được duy trì qua nhánh Agave của Anza, và mạng cũng đang tiến tới đa dạng hóa client rộng hơn thông qua dự án Firedancer của Jump Crypto, với Frankendancer là một cột mốc sớm trên con đường đó.

Đa dạng hóa client có thể giảm rủi ro một lỗi khiến phần lớn cổ phần bị tắt cùng lúc, nhưng không loại bỏ hoàn toàn nhu cầu nâng cấp bảo mật có thời hạn.

Đây là bối cảnh mà v3.0.14 ra đời. Sự khẩn cấp liên quan đến việc đóng các lối đi tiềm năng dẫn đến gián đoạn trước khi chúng có thể bị khai thác.

Những gì đã thay đổi trong 10 ngày qua: lý do trở nên công khai, và động lực trở nên rõ ràng

Thông báo của Anza đã lấp đầy phần trung tâm còn thiếu của câu chuyện. Hai lỗ hổng tiềm năng quan trọng đã được tiết lộ vào tháng 12 năm 2025 qua các cảnh báo bảo mật trên GitHub, và Anza cho biết các vấn đề đã được vá trong quá trình hợp tác với Firedancer, Jito và Quỹ Solana.

Một vấn đề liên quan đến hệ thống gossip của Solana, cơ chế các validator dùng để chia sẻ các thông điệp mạng nhất định ngay cả khi việc sản xuất khối bị gián đoạn. Theo Anza, một lỗi trong cách xử lý một số thông điệp có thể khiến validator bị sập trong một số điều kiện nhất định, và một khai thác phối hợp lấy đủ cổ phần offline có thể làm giảm khả năng sẵn sàng của cụm.

Vấn đề thứ hai liên quan đến xử lý bỏ phiếu, trung tâm của cách validator tham gia vào đồng thuận. Theo Anza, một bước xác minh bị thiếu có thể cho phép kẻ tấn công làm quá tải validator bằng các thông điệp bỏ phiếu không hợp lệ theo cách gây cản trở xử lý bỏ phiếu bình thường, có thể làm đình trệ đồng thuận nếu thực hiện quy mô lớn.

Cách sửa là đảm bảo rằng các thông điệp bỏ phiếu được xác minh đúng trước khi chấp nhận vào quy trình làm việc trong quá trình sản xuất khối.

Thông báo này thay đổi cách nhìn nhận về “độ trễ chấp nhận ban đầu”. Việc nâng cấp là khẩn cấp vì nó đã đóng hai lối đi khả thi dẫn đến gián đoạn nghiêm trọng, một là làm sập validator và một là can thiệp vào bỏ phiếu quy mô lớn.

Vấn đề nhà vận hành vẫn còn quan trọng, nhưng trở nên cụ thể hơn: một đội ngũ phân tán có thể triển khai bản vá nhanh như thế nào khi các chế độ lỗi là rõ ràng và hệ thống?

Song song đó, quy tắc ủy quyền của Solana đã làm cho cơ chế phối hợp dễ nhận biết hơn. Tiêu chí ủy quyền của Quỹ Solana bao gồm yêu cầu về phiên bản phần mềm và tiêu chuẩn phản hồi đã được nêu rõ.

Lịch trình công khai các phiên bản phần mềm validator bắt buộc liệt kê Agave 3.0.14 và Frankendancer 0.808.30014 là các phiên bản bắt buộc qua nhiều epoch. Đối với các nhà vận hành nhận ủy quyền từ Quỹ, việc nâng cấp trở thành một yếu tố kinh tế, vì không đáp ứng yêu cầu có thể dẫn đến việc rút ủy quyền cho đến khi tiêu chuẩn được đáp ứng.

Đây là thực tế vận hành đằng sau “tài chính luôn hoạt động”. Nó được xây dựng qua mã nguồn, nhưng duy trì qua các động lực, bảng điều khiển và chuẩn mực thúc đẩy hàng nghìn tác nhân độc lập hội tụ trong các khung thời gian hẹp do các sự cố bảo mật tạo ra.

Ngay cả khi có các cảnh báo và cổ phần rõ ràng, việc nâng cấp nhanh vẫn còn nhiều trở ngại. Anza cho biết các nhà vận hành cần xây dựng từ mã nguồn theo hướng dẫn cài đặt của Anza.

Việc xây dựng từ mã nguồn không inherently rủi ro, nhưng nâng cao tiêu chuẩn vận hành vì validator dựa vào các pipeline xây dựng, quản lý phụ thuộc và kiểm thử nội bộ trước khi đưa các thay đổi vào sản xuất.

Những yêu cầu này đặc biệt quan trọng trong các nâng cấp khẩn cấp, vì sự cấp bách rút ngắn thời gian validator có để kiểm thử, chuẩn bị và lên lịch bảo trì, trong khi sai sót có thể dẫn đến mất phần thưởng trực tiếp và thiệt hại danh tiếng trong thị trường ủy quyền cạnh tranh.

Chương trình v3.0.14 cũng không làm gián đoạn chu kỳ phát hành rộng hơn của Solana.

Vào ngày 19 tháng 1, kho lưu trữ Agave đã phát hành v3.1.7, được gắn nhãn là bản phát hành testnet khuyến nghị cho devnet và lên đến 10% mainnet beta, báo hiệu một dòng các thay đổi mà các nhà vận hành phải theo dõi và lên kế hoạch. Vào ngày 22 tháng 1, trang lịch trình phát hành v3.1 của Agave đã được cập nhật với kế hoạch triển khai dự kiến.

Sẵn sàng trở nên đo lường được theo cách thực tế

Một thước đo là sự hội tụ của các phiên bản dưới áp lực, nghĩa là tốc độ chuyển đổi cổ phần sang phiên bản đề xuất khi có cảnh báo khẩn cấp, và các báo cáo sớm về v3.0.14 cho thấy chi phí của việc di chuyển chậm.

Một yếu tố nữa là khả năng chống chịu trước các thất bại liên kết, trong đó đa dạng hóa client qua Firedancer và Frankendancer giảm rủi ro một dòng phần mềm khiến mạng bị tắt, nhưng chỉ khi các client thay thế đạt mức triển khai có ý nghĩa.

Yếu tố thứ ba là sự phù hợp về động lực, trong đó tiêu chí ủy quyền và các phiên bản bắt buộc biến vệ sinh an ninh thành một yêu cầu kinh tế đối với nhiều nhà vận hành.

Chương trình v3.0.14 bắt đầu như một nhãn khẩn cấp và lo lắng về việc chấp nhận, rồi trở thành một cửa sổ rõ ràng hơn về cách Solana vá lỗi, phối hợp và thực thi các tiêu chuẩn trên một đội ngũ validator phân tán.