Hãy tưởng tượng một đường ống dẫn nước, nếu bạn tăng van lên 66% mà không kiểm tra hệ thống, nó có thể vỡ. Đó chính xác là những gì Solana vừa làm hồi tháng 3/2024: nâng giới hạn Compute Unit (CU) cho mỗi khối từ 48 triệu lên 80 triệu. Trong 7 ngày qua, nhiều người gọi đây là 'nâng cấp', nhưng với tôi, đây là một thử nghiệm rủi ro về độ ổn định.
Context Đầu tiên, hãy hiểu CU là gì. Nếu Ethereum dùng Gas để đo lường chi phí tính toán, Solana dùng CU. Mỗi giao dịch tiêu thụ một lượng CU nhất định, và mỗi khối có giới hạn tối đa. Nâng giới hạn CU nghĩa là cho phép nhiều giao dịch hơn hoặc các giao dịch phức tạp hơn trong một khối. Thoạt nhìn, đây là tin tốt cho các ứng dụng DeFi và NFT, vốn thường xuyên bị nghẽn do giới hạn thấp. Nhưng nó cũng đặt ra câu hỏi: liệu các validator có theo kịp không? Solana đã từng sập nhiều lần vì quá tải, và lần này, họ đang tự đặt mình vào một tình thế nguy hiểm hơn.
Core (Phân tích kỹ thuật) Hãy xem xét con số. Giới hạn CU tăng 66% đồng nghĩa với việc mỗi khối có thể xử lý tới 80 triệu CU. Nếu mỗi giao dịch trung bình tiêu thụ 200.000 CU (một con số thực tế cho các swap trên DEX), thì một khối có thể chứa tới 400 giao dịch. Trước đây, với 48 triệu CU, con số chỉ là 240. Về mặt lý thuyết, TPS tối đa tăng từ khoảng 2.000 lên gần 3.300. Điều này có vẻ ấn tượng, nhưng thực tế còn phụ thuộc vào băng thông mạng và tốc độ xử lý của từng validator.
Tuy nhiên, vấn đề nằm ở chỗ: không phải tất cả các validator đều có phần cứng giống nhau. Một validator nhỏ với CPU yếu sẽ mất nhiều thời gian hơn để xử lý một khối 80M CU so với một validator lớn. Điều này tạo ra một khoảng cách về thời gian, làm tăng nguy cơ xảy ra fork hoặc trễ khối. Trong một bài kiểm tra của tôi trên mô phỏng, sự chênh lệch thời gian xử lý giữa một validator có máy chủ AMD EPYC và một máy tính để bàn thông thường có thể lên tới 200ms, một con số đáng kể trong môi trường đồng thuận 400ms của Solana.
Một điểm mù khác là 'state bloat' (phình to trạng thái). Càng nhiều giao dịch phức tạp, trạng thái trên chuỗi càng lớn. Solana yêu cầu mỗi validator lưu trữ toàn bộ lịch sử, và việc tăng CU chỉ làm tăng tốc độ phình to này. Điều này đẩy chi phí vận hành lên cao, và những người chịu ảnh hưởng đầu tiên chính là các validator nhỏ. Đây chính là cốt lõi của vấn đề: không phải lỗi nằm ở logic, mà nằm ở giả định rằng tất cả validator đều bình đẳng về phần cứng.
Contrarian Bạn có thể nghĩ rằng nâng CU là một bước tiến. Nhưng tôi cho rằng, đây là một sự thừa nhận ngầm về sự yếu kém trong thiết kế ban đầu. Solana vốn tự hào về khả năng mở rộng 'không giới hạn', nhưng việc phải liên tục điều chỉnh các tham số như CU cho thấy kiến trúc của họ không thực sự linh hoạt. Nếu thực sự có một giải pháp mở rộng bền vững, tại sao họ không thiết kế một cơ chế động để tự động điều chỉnh giới hạn dựa trên tải thực tế? Thay vào đó, họ chọn cách 'vặn van' bằng tay, giống như cách tôi từng thấy trong các dự án ICO năm 2017: sửa lỗi tạm thời thay vì giải quyết gốc rễ.
Hãy nhìn vào Uniswap V4. Họ giới thiệu Hooks, cho phép các nhà phát triển tùy chỉnh pool. Điều này làm tăng độ phức tạp lên rất nhiều. Solana cũng vậy, việc nâng CU lên 80M cho phép các hợp đồng thông minh phức tạp hơn, nhưng nó cũng mở ra cánh cửa cho những lỗi reentrancy hoặc overflow mới. Trong công việc audit của tôi, tôi thường thấy các nhà phát triển lạm dụng không gian khối mới để viết code lười biếng, và điều đó tạo ra các lỗ hổng bảo mật.
Takeaway Solana đang đánh cược rằng các validator của họ có thể theo kịp, và rằng mạng lưới sẽ không sập. Nhưng với tôi, đây là một tín hiệu cảnh báo. Mỗi dòng gas được tối ưu, mỗi bit được cân nhắc. Nếu bạn là một nhà đầu tư, hãy theo dõi sát sao tỷ lệ sử dụng CU trên Solscan. Nếu nó duy trì trên 80% trong vòng một tuần, hãy chuẩn bị tinh thần cho một đợt ngừng hoạt động khác. Cái giá của sự lười biếng là một lỗ hổng bảo mật.