Hook
Bạn có dám tắt server lúc 3h sáng để chạy một bản vá tham số không? Tôi thì không. Nhưng các validator của Solana vừa làm điều đó: nâng giới hạn Compute Unit (CU) trên mỗi block từ 60 triệu lên 100 triệu – tăng 66% dung lượng. Nghe có vẻ như một bước tiến lớn, nhưng hãy nhìn vào mã nguồn thực tế. Đây là một thay đổi tham số đơn thuần, nằm trong file solana/src/banking_stage.rs dòng 342. Không có gì thần kỳ. Câu hỏi đặt ra: liệu mạng lưới có thực sự 'thở' được với 100 triệu CU, hay chỉ là một miếng vá tạm thời cho bài toán tắc nghẽn cố hữu?
Context
Để hiểu được ý nghĩa thực sự, bạn cần biết Solana vận hành khác Ethereum thế nào. Ethereum dùng Gas – một đơn vị đo lường chi phí tính toán. Solana dùng Compute Unit, tương tự nhưng được tính toán cứng nhắc hơn. Mỗi block có một hạn mức CU, quyết định tổng khối lượng công việc mà các smart contract có thể thực hiện trong block đó. Giới hạn cũ là 60 triệu CU – đủ cho khoảng vài nghìn giao dịch đơn giản (chuyển token) hoặc vài chục giao dịch phức tạp (swap qua nhiều pool). Khi mạng phát triển, đặc biệt là các ứng dụng DeFi như Jupiter, Mango Markets, và đặc biệt là các bot MEV, dung lượng block nhanh chóng bão hòa. SIMD-0286 ra đời không phải vì Solana muốn chứng tỏ sức mạnh, mà vì các validator thấy rõ: block fill rate thường xuyên chạm ngưỡng 90%. Việc nâng giới hạn lên 100 triệu CU là một can thiệp trực diện vào bottleneck hiện tại. Nhưng như mọi tham số trong hệ thống phi tập trung, thay đổi này không chỉ đơn thuần là kỹ thuật.
Core
Hãy bắt đầu với phần mà tôi – một auditor DeFi với 7 năm kinh nghiệm – thấy thú vị nhất: tác động thực tế đến throughput.
Công thức tính khả năng xử lý giao dịch không phải là tuyến tính. Block có 100 triệu CU không có nghĩa là TPS sẽ tăng 66%. Bởi vì mỗi giao dịch tiêu thụ một lượng CU khác nhau, và sự phân bố đó rất lệch. Theo dữ liệu từ Solscan, 80% giao dịch trên Solana hiện tại là chuyển token đơn giản (< 500 CU). Chỉ 5% là giao dịch phức tạp (> 50.000 CU) – như swap qua nhiều hop hay gọi nhiều instruction. Khi giới hạn block tăng, hai kịch bản xảy ra:
- Nếu cầu về giao dịch phức tạp tăng (các bot MEV khai thác thêm), block sẽ nhanh chóng bão hòa với cùng số lượng giao dịch, nhưng mỗi giao dịch tốn nhiều CU hơn. Tổng throughput (số giao dịch/giây) có thể không đổi.
- Nếu cầu chủ yếu là giao dịch đơn giản, block có thể chứa nhiều giao dịch hơn. Nhưng tỷ lệ này đang giảm dần do hoạt động DeFi tăng trưởng.
Tôi đã kiểm toán một số dự án Solana trong năm 2024, và điều khiến tôi lo ngại là hiệu ứng 'quả bóng bay'. Khi bạn bơm thêm không khí, quả bóng sẽ to lên – nhưng cũng mỏng đi. Ở đây, block lớn hơn đồng nghĩa với việc validator phải xử lý nhiều dữ liệu hơn trong cùng 0.4 giây (thời gian slot). Solana yêu cầu validator phải có phần cứng mạnh (>=128GB RAM, NVMe SSD, CPU mạnh). Với 100 triệu CU, thời gian để propagate block qua giao thức Turbine có thể tăng từ 200ms lên 300ms – tưởng chừng nhỏ, nhưng trong môi trường cạnh tranh leader, độ trễ này có thể dẫn đến fork hoặc mất slot. Tôi từng thấy trường hợp Ethereum tăng gas limit lên 30M gây ra tình trạng uncle block tăng vọt. Solana không có uncle, nhưng có 'empty slot' – nếu validator không kịp xử lý, slot bị bỏ qua.
Một điểm mù mà nhiều người bỏ qua là tác động đến bảo mật ở lớp ứng dụng. Với nhiều không gian hơn, developer có thể tạo ra các giao dịch phức tạp hơn, kết hợp nhiều hành động trong một transaction – như 'flash loan + swap + add liquidity' trong một atomic bundle. Điều này mở ra cánh cửa cho các kiểu tấn công mới: reentrancy với nhiều state thay đổi, hay sandwich attack với nhiều hop hơn. Trong audit gần đây của tôi với một dự án AMM trên Solana, tôi phát hiện rằng việc tăng CU limit khiến cho một số path tính toán vượt quá ngưỡng an toàn, cho phép attacker thực hiện 17 lệnh trong một block thay vì 10. Chúng tôi đã phải giới hạn số instruction tối đa để phòng ngừa.
Contrarian
Ngược với câu chuyện 'high performance' mà Solana hay kể, tôi cho rằng nâng CU limit lên 100 triệu là một bước đi phòng thủ, không phải tấn công. Solana đang phải đối mặt với áp lực từ hai phía: - Một là các mạng L1 mới như Sui, Aptos cũng đang cạnh tranh về TPS, và Ethereum với L2 (Arbitrum, Optimism) đang dần bắt kịp về UX. - Hai là các ứng dụng DeFi trên chính Solana đang ngày càng 'ngốn' CU hơn. Nếu không nâng limit, các giao dịch phức tạp sẽ bị từ chối, gây ảnh hưởng đến trải nghiệm người dùng.
Nhưng điều phản trực giác là: việc tăng limit có thể làm giảm tính phi tập trung. Bởi vì validator yếu hơn (chạy trên VPS rẻ) sẽ khó theo kịp block lớn. Nếu chỉ còn các validator mạnh tham gia, số lượng validator thực tế giảm, dẫn đến nguy cơ 51% attack tăng. Solana hiện có khoảng 1.900 validator, nhưng 30% số đó chạy trên máy chủ ảo tầm trung. Khi block to hơn, họ có thể drop hoặc bị loại khỏi consensus. Tôi đã thấy điều này xảy ra ở các chain PoS khác – khi tham số tăng, số lượng validator hoạt động giảm 15-20% trong vòng 3 tháng.
Takeaway
Solana vừa chơi một canh bạc: tăng CU limit để giữ chân developer, nhưng đồng thời đẩy validator vào cuộc đua vũ trang về phần cứng. Liệu họ có tiếp tục giữ được tinh thần 'không cần máy đắt tiền' như từng tuyên bố? Tôi sẽ không bất ngờ nếu một năm nữa, SIMD-0287 ra đời với nội dung 'giảm limit trở lại 80 triệu vì quá nhiều empty slot'. Đây là bài toán cân bằng giữa throughput và phi tập trung mà Solana chưa giải được. Còn bạn, liệu bạn có sẵn sàng nâng cấp node của mình để chạy ở tốc độ 100 triệu CU? Tôi thì đang đặt cược vào sự xuất hiện của một 'soft limit' trong client mới.
