Trong gần 1 tuần vừa qua, Solana liên tục trở thành mục tiêu tấn công và là trò đùa của các “mạng lưới khác”. Tuy nhiên, lí do cụ thể của việc không xử lý giao dịch thành công trên Solana là gì? Liệu hiện tượng này có đồng nghĩa với việc mạng lưới “đóng băng”? Liệu các bản vá lỗi tiếp theo có xử lý triệt để được câu chuyện này? Hãy cùng đi tìm câu trả lời trong bài viết dưới đây anh em nhé!
Tổng quan về cách mạng lưới Solana hoạt động
Về cơ bản, quy trình xử lý giao dịch của Solana sẽ khác các mạng lưới phổ biến trong hệ sinh thái Ethereum Virtual Machine (EVM). Solana không có một Mempool để giao dịch được thả vào. Từ đó các node sẽ chọn lọc từ Mempool và đóng gói xử lý. Với Solana, các giao dịch sẽ được gửi trực tiếp đến Validator (hay cụ thể là Leader Validator – được chọn ngẫu nhiên) của block đó.
Quá trình gửi giao dịch này sẽ thông qua một lớp xử lý gọi là Networking Layer và lớp này sử dụng một cơ chế là QUIC. Nói một chút về QUIC, thì đây hiểu nôm na là dạng tổng hợp giữa 2 giao thức truyền thông tin phổ biến là TCP và UDP. Từ đó chúng bù đắp điểm mạnh và điểm yếu cho nhau.
- Transmission Control Protocol (TCP): Dữ liệu ổn định đảm bảo, nhưng tốc độ không nhanh và rất khó khởi tạo lại khi mất kết nối.
- User Datagram Protocol (UDP): Tốc độ nhanh hơn, tuy nhiên dữ liệu truyền qua giao thức này lại không được đảm bảo an toàn.
Vậy thì vấn đề nằm ở đâu?
Trước hết, chúng ta cần làm rõ việc vấn đề KHÔNG nằm ở đâu. Việc giao tiếp, đồng thuận giữa các Validator không phải là nguyên nhân. Theo quy trình này là bước nằm sau lớp Networking Layer chúng ta đề cập ở trên. Đây là những lí do đã khiến Solana đứng hình trong những lần trước đây.
Còn với hiện tượng lần này, nó là tổng hợp của 2 vài lí do dưới đây:
- Cơ chế cân bằng tải của QUIC: Khi lượng yêu cầu giao dịch tăng cao, QUIC sẽ chọn ngẫu nhiên giao dịch để xử lý. Tất nhiên điều này khiến các giao dịch không được chọn sẽ thất bại (và vẫn tốn tiền phí).
- Cơ chế phí giao dịch: Tuy nhiên, vì mức lợi từ các giao dịch Arbitrage là khá lớn, do đó các bot giao dịch sẵn sàng spam yêu cầu để tăng khả năng được chọn (vì mức tiền phí họ có thể mất quá bé so với lợi nhuận tiềm năng).
Bản cập nhật 1.18
Theo nhà phát triển Mert, bản cập nhật 1.18 sẽ có một vài sửa lỗi cho vấn đề trên. Dự kiến, bản cập nhật này sẽ được triển khai vào ngày 15/04.
Vậy thì cập nhật 1.18 có thể sẽ có những gì? Theo những kế hoạch Testnet (tất nhiên sẽ có thêm những thay đổi trong thời gian tới), Solana sẽ bỏ thêm hàm “Async Lock” vào luồng kết nối QUIC. Hàm Async Lock sẽ giúp quản lý các luồng yêu cầu bất đối xứng. Phần nào đó, nó sẽ giảm thiểu hiện tượng giao dịch thất bại.
Một chi tiết nữa đó là thay đổi này có thể chuẩn bị các cấu trúc cần có để mạng lưới tối ưu cơ chế “Phí ưu tiên”. Đây có thể là giải pháp tạm thời để người dùng có nhu cầu thực (không phải bot spam) chi trả phí ưu tiên để sử dụng mạng lưới. Tất nhiên, nếu triển khai Phí ưu tiên, có thể Solana sẽ lại đi vào vết xe đổ của các mạng lưới truyền thống và dẫn đến hiện tượng đội phí giao dịch lên cao.
Mạng lưới sắp tới có thể trở lại bình thường?
Về phần người dùng, có thể phần nào vấn đề sẽ được xử lý. Tuy nhiên với các lập trình viên, nhiều khả năng họ vẫn chưa thể quay lại hoạt động bình thường.
Một vài ý kiến khác cho rằng, cơ chế QUIC không phù hợp để vận hành blockchain. Dù vậy, những phiên bản cập nhật triệt để hơn sau này như Firedancer (dự kiến ra mắt cuối năm 2024) có thể sẽ giúp xử lý được vấn đề.
Như vậy, sẽ có cột mốc đến ngày 15/04 để Solana triển khai phiên bản 1.18. Vấn đề có thể sẽ được xử lý phần nào. Tuy nhiên, để có thể xử lý vấn đề cân bằng giữa phí giao dịch thấp và bot spam. Có thể mạng lưới Solana sẽ cần phải chờ lâu hơn đến cuối năm 2024.
Hoặc thậm chí, mạng lưới cần kết hợp với một cơ chế thu phí mới. Mục đích để có thể ngăn cản hành vi spam của các bot giao dịch trong tương lai.
Theo Coinviet tổng hợp
Cùng theo dõi Coinviet.net và xem thêm những tin tức hữu ích khác tại Dexnew.io nhé!
