Sự thật về thị trường phí cục bộ của Solana

Những điểm chính có thể áp dụng

• Thị trường phí cục bộ (LFM) cho phép Solana thiết lập mức phí chi tiết cho từng phần trạng thái dựa trên mức độ tranh chấp. Giao dịch trả phí dựa trên trạng thái cụ thể mà chúng ghi vào, qua đó ngăn các điểm nóng cục bộ làm tăng phí trên toàn bộ blockchain. 
• LFM đóng vai trò thiết yếu trong việc hiện thực hóa tầm nhìn của Solana về một lớp cơ sở hợp nhất, có khả năng mở rộng, nơi mọi ứng dụng cùng tồn tại liền mạch. Nếu không có LFM, phí tăng đột biến ở một phần của chuỗi sẽ làm tăng phí cho mọi giao dịch—một vấn đề thường thấy ở các mạng chỉ dựa vào thị trường phí toàn cục để định giá không gian khối.
• Khi hoạt động kinh tế trên Solana bắt đầu tăng tốc vào cuối năm 2023, một số khiếm khuyết nghiêm trọng trong cách triển khai LFM ban đầu đã trở nên rõ ràng. Đáng chú ý nhất là cơ chế ưu tiên không tất định của bộ lập lịch. Giao dịch chủ yếu được sắp xếp theo thời điểm đến trình tạo khối, còn phí ưu tiên chỉ là yếu tố thứ cấp.
• Bản cập nhật Agave client v1.18 vào tháng 5 năm 2024 đã giới thiệu một bộ lập lịch giao dịch mới và công thức tính độ ưu tiên giao dịch được tinh chỉnh. Bộ lập lịch xây dựng đồ thị phụ thuộc để quản lý tốt hơn việc xử lý và ưu tiên các giao dịch xung đột trên nhiều luồng. Bản cập nhật lớn này đã cải thiện đáng kể khả năng sắp xếp giao dịch một cách tất định của giao thức.
• Một chỉ số hữu ích để đánh giá LFM có hoạt động hiệu quả hay không là so sánh phí ưu tiên giao dịch trung vị và trung bình. Phí liên quan đến trạng thái không bị tranh chấp (trung vị ở phân vị thứ 50) được kỳ vọng sẽ duy trì ở mức thấp. Phí cho trạng thái bị tranh chấp sẽ tăng vọt khi nhu cầu tăng, kéo mức trung bình lên theo. Dữ liệu gần đây xác nhận mô hình này. Vào tháng 11 năm 2024, phí trung bình cho giao dịch không bỏ phiếu đạt mức cao nhất mọi thời đại, hơn 0.0003 SOL. Tuy nhiên, phí trung vị vẫn ổn định ở mức 0.00000861 SOL, thấp hơn khoảng 35 lần.
• Hiện nay, LFM của Solana đã hoạt động, nhưng vẫn còn nhiều dư địa để cải thiện. Phân tích khối lượng công việc của các luồng ở giai đoạn banking do các kỹ sư Anza thực hiện cho thấy một lỗi trong bộ lập lịch khiến validator client không thể tận dụng toàn bộ công suất. Do đó, Agave client chỉ hoạt động ở một phần nhỏ tiềm năng. Hơn nữa, chưa có đặc tả chính thức về cách sắp xếp giao dịch.
• Các API phí ưu tiên hiện tại chưa đủ tinh vi để cung cấp kết quả tất định cho nhà phát triển. Mỗi nhà cung cấp RPC lớn đều cung cấp API phí ưu tiên tùy chỉnh riêng, điều này có thể trở thành một dạng phụ thuộc mềm vào nhà cung cấp. Cách triển khai RPC API mã nguồn mở cốt lõi không xem xét các động lực mạng quan trọng như ảnh hưởng của Jito, dẫn đến ước tính phí thiếu chính xác.
• Khi không có phương pháp tất định để tính phí ưu tiên, nhà phát triển thường chọn cách thận trọng là trả dư phí để đảm bảo giao dịch được xử lý. Ngoài ra, họ có thể lạm dụng tiền boa Jito như một cơ chế thay thế, ngay cả với các giao dịch không cần giành vị trí đầu khối.
• Nhiều chiến lược đã được đề xuất để tiếp tục cải thiện cấu trúc phí của Solana. Trong đó có phí khóa ghi theo cấp số nhân và phí cơ sở động. Mạng vẫn chưa tìm ra cách tạo áp lực ngược về kinh tế để hạn chế spam mà vẫn duy trì phí thấp cho người dùng thực.

Giới thiệu

Thị trường phí là cơ chế kinh tế được thiết kế để phân bổ hiệu quả không gian khối khan hiếm cho các giao dịch có giá trị cao nhất thông qua việc điều chỉnh phí giao dịch linh hoạt. Mức phí mà một giao dịch sẵn sàng trả đóng vai trò đại diện cho giá trị của giao dịch đó. LFM tinh chỉnh khái niệm chung này bằng cách thiết lập mức phí chi tiết cho từng phần trạng thái dựa trên mức độ tranh chấp. Hai giao dịch được coi là xung đột khi truy cập cùng một trạng thái—hoặc cả hai cùng ghi, hoặc một giao dịch đọc và một giao dịch ghi vào cùng một tài khoản.

Với LFM, giao dịch trả phí dựa trên trạng thái cụ thể mà chúng ghi vào, qua đó ngăn các điểm nóng cục bộ làm tăng phí trên toàn bộ blockchain. Giao dịch truy cập các trạng thái có nhu cầu cao hoặc bị tranh chấp phải chịu phí cao hơn, trong khi giao dịch tương tác với trạng thái có nhu cầu thấp hơn sẽ trả phí thấp hơn. Điều này rất quan trọng vì Solana xử lý giao dịch không xung đột tốt hơn nhờ thực thi song song.

Ngược lại, thị trường phí toàn cục áp dụng một mức chi phí chung để truy cập trạng thái mạng, nghĩa là mọi giao dịch đều cạnh tranh ngang nhau để được đưa vào khối, bất kể chúng tương tác với tài khoản nào. Mô hình phí của Ethereum, được triển khai trong EIP-1559, là một ví dụ điển hình về thị trường phí toàn cục. EIP-1559 điều chỉnh phí cơ sở động dựa trên nhu cầu mạng để duy trì mức sử dụng tài nguyên tính toán (gas) tối ưu trên mỗi khối. Khi dung lượng khối được lấp đầy, phí tăng đối với mọi giao dịch. Ví tính phí dựa trên phí cơ sở hiện tại và giới hạn gas của giao dịch. Cách tiếp cận này được thực thi trong giao thức và cho phép tính phí có thể dự đoán; tuy nhiên, nó không thể cô lập các điểm nóng có nhu cầu cao khỏi phần còn lại của mạng. Khi phí tăng đột biến, chúng tăng với mọi giao dịch.

Nhu cầu cao đối với những phần trạng thái cụ thể không phải là vấn đề chỉ có ở blockchain. Thách thức này tương tự vấn đề khóa điểm nóng, thường được gọi là "vấn đề người nổi tiếng", phổ biến trong các ứng dụng xã hội Web2.

Trong bài viết này, chúng tôi hướng đến việc cung cấp một phân tích dễ tiếp cận về LFM của Solana. Nội dung được chia thành các phần sau:

• Kiến thức cơ bản về phí Solana: Cung cấp kiến thức nền tảng cho người đọc về cách giao dịch được xử lý trên Solana hiện nay.
• Các vấn đề ban đầu của thị trường phí cục bộ: Khám phá những vấn đề trong các cách triển khai LFM ban đầu và những hạn chế của chúng.
• Bản cập nhật bộ lập lịch trung tâm v1.18: Nêu bật bản cập nhật then chốt năm 2024 đã cải thiện đáng kể chức năng của LFM.
• Đo lường hiệu quả của thị trường phí cục bộ: Cung cấp dữ liệu liên quan để hiểu trạng thái hoạt động hiện tại của LFM trên Solana.
• Các vấn đề còn tồn tại và lĩnh vực cần cải thiện: Thảo luận về những vấn đề chưa được giải quyết và các lĩnh vực cần chú ý để LFM phát huy hết tiềm năng.
• Các giải pháp được đề xuất: Xem xét những giải pháp được đề xuất nhằm tinh chỉnh LFM và đưa ra các động lực kinh tế tốt hơn để định giá không gian khối một cách chi tiết hơn.

Người đọc đã quen thuộc với cấu trúc phí giao dịch của Solana có thể bỏ qua phần kiến thức cơ bản về phí sau đây.

Kiến thức cơ bản về phí Solana

Giao dịch Solana bao gồm hai loại phí—phí cơ sở và phí ưu tiên. Phí cơ sở hiện được cố định ở mức 5.000 lamport cho mỗi chữ ký. Hầu hết giao dịch Solana có một chữ ký. Phí ưu tiên được tính bằng microlamport (tức một phần triệu lamport) trên mỗi đơn vị tính toán (CU) được yêu cầu. Phí được khấu trừ từ tài khoản trả phí (bên ký). Giao dịch sẽ bị loại nếu bên trả phí không có đủ lamport để thanh toán. Tại thời điểm viết bài, trình tạo khối giữ lại 50% phí cơ sở và phí ưu tiên như một động lực để đưa giao dịch vào khối. 50% còn lại bị đốt. Sau cuộc bỏ phiếu quản trị thành công đối với đề xuất SIMD-096 vào tháng 5 năm ngoái, cơ chế này sẽ thay đổi để trình tạo khối giữ lại 100% phí ưu tiên. Ví dụ: 

Một giao dịch có một chữ ký và yêu cầu 500.000 CU. Người gửi đặt phí ưu tiên là 50.000 microlamport trên mỗi CU được yêu cầu. Tổng phí giao dịch là 5.000 lamport + (500.000 CU được yêu cầu * 50.000 microlamport trên mỗi CU được yêu cầu) = 25.000 lamport, hay 0.000025 SOL.

Validator có tài nguyên tính toán hữu hạn và giao thức giới hạn tổng tài nguyên tính toán trên mỗi khối ở mức 48 triệu CU. Con số này được lựa chọn dựa trên thực nghiệm về khối lượng mà validator có thể xử lý hợp lý để đạt thời gian khối 400 mili giây. CU tối đa cho mỗi tài khoản trên mỗi khối được giới hạn ở mức 12 triệu, còn tài nguyên tính toán tối đa cho mỗi giao dịch là 1,4 triệu CU. Thông điệp giao dịch cũng bị giới hạn ở kích thước tối đa 1.232 byte, tương đương đơn vị truyền tối thiểu của IPv6 (1280 byte) trừ đi các header.

Để ngăn chặn việc lạm dụng tài nguyên tính toán, mỗi giao dịch trên Solana được gán một ngân sách tính toán. Theo mặc định, mạng đặt giới hạn tối đa là 200.000 đơn vị tính toán (CU) cho mỗi lệnh. Tuy nhiên, giao dịch có thể chỉ định giới hạn đơn vị tính toán tùy chỉnh bằng cách đưa vào một lệnh `SetComputeUnitLimit`, từ đó cho phép phân bổ tài nguyên hiệu quả hơn. Mã nguồn Agave client liệt kê chi phí CU cho nhiều thao tác.

Solana yêu cầu mọi giao dịch chỉ định danh sách đầy đủ các địa chỉ tài khoản sẽ được đọc hoặc ghi trong giao dịch. Kích thước tối đa của danh sách này là 35 địa chỉ và có thể được mở rộng thông qua Address Lookup Table trên chuỗi. Việc xây dựng danh sách địa chỉ tạo thêm chi phí cho nhà phát triển, nhưng đây là chìa khóa để khai thác nhiều cơ chế tối ưu hóa của Solana, bao gồm thực thi giao dịch song song và thị trường phí cục bộ.

Các vấn đề ban đầu của thị trường phí cục bộ trên Solana

Khi hoạt động kinh tế trên Solana bắt đầu tăng tốc vào cuối năm 2023, một số khiếm khuyết nghiêm trọng trong cách triển khai LFM ban đầu đã trở nên rõ ràng. Trong khoảng thời gian này, Eugene Chen từ Ellipsis Labs đã đưa ra một phân tích toàn diện về những thách thức đó trong bài viết Solana Fees, Part 1 của Umbra Research. Dưới đây là phần tóm tắt các luận điểm chính mà Chen nêu ra.

Thiếu động lực để yêu cầu CU chính xác

Cấu trúc phí của Solana thu phí cơ sở theo từng chữ ký mà không xét đến số đơn vị tính toán (CU) đã sử dụng hoặc yêu cầu. Trong khi đó, phí ưu tiên chỉ tạo ra động lực hạn chế để giảm mức sử dụng CU trong giai đoạn tắc nghẽn. Thiết kế này khiến người gửi giao dịch có rất ít động lực để tối ưu hóa mức sử dụng tài nguyên tính toán hoặc điều chỉnh yêu cầu CU cho phù hợp với nhu cầu thực tế. Do đó, giao dịch thường yêu cầu quá nhiều CU, gây ra sự kém hiệu quả trong quy trình lập lịch của mạng.

Động lực sử dụng cơ chế ưu tiên ngoài giao thức

Việc đốt 50% phí ưu tiên khuyến khích người gửi giao dịch bỏ qua giao thức bằng cách thông đồng với trình tạo khối và sắp xếp các khoản thanh toán ngoài chuỗi để được ưu tiên truy cập. Hành vi này thể hiện rõ qua mức độ sử dụng ngày càng tăng của các phiên đấu giá Jito. Validator chạy Jito-Agave client hưởng lợi từ thu nhập phí cao hơn và có thể phân phối hiệu quả lợi nhuận này cho những người staking ủy quyền thông qua phần thưởng hoa hồng Jito MEV. Khi mức độ sử dụng Jito-Agave client tăng lên, Jito bundle đã chứng minh là dịch vụ phân phối giao dịch vượt trội trong nhiều trường hợp. 

Cơ chế ưu tiên không tất định của bộ lập lịch

Cả cơ chế đồng thuận lẫn bộ lập lịch của Solana đều không áp đặt thứ tự giao dịch nghiêm ngặt dựa trên phí ưu tiên. Giao dịch chủ yếu được sắp xếp theo thời điểm đến trình tạo khối, còn phí ưu tiên chỉ là yếu tố thứ cấp. Phí ưu tiên cao hơn có thể làm tăng khả năng được đưa vào khối khi có trạng thái bị tranh chấp, nhưng quy trình sắp xếp vẫn không tất định. Độ dao động mạng trước khi đến đơn vị xử lý giao dịch (TPU) và độ dao động nội bộ trong bộ lập lịch càng làm tăng tính khó dự đoán.

Sự thiếu tất định này làm giảm khả năng dự đoán và độ tin cậy khi thực thi giao dịch, khiến người dùng tràn ngập mạng bằng giao dịch spam để tăng cơ hội được đưa vào khối nhanh hơn. Tuy nhiên, tăng phí ưu tiên chỉ mang lại lợi ích giảm dần sau một ngưỡng nhất định, làm suy yếu hiệu quả của phí này với vai trò là cơ chế giúp giao dịch có vị trí tốt hơn. Không gian khối dùng chung của Solana cuối cùng đã trở thành nạn nhân của "bi kịch tài nguyên chung" kinh điển. Các tác nhân riêng lẻ, hành động vì lợi ích cá nhân, đã góp phần khiến tài nguyên công này bị sử dụng quá mức và trở nên kém hiệu quả.

Bản cập nhật bộ lập lịch trung tâm v1.18

Cách triển khai bộ lập lịch Agave client ban đầu chỉ đảm bảo ở mức hạn chế rằng giao dịch có phí ưu tiên cao sẽ có cơ hội được đưa vào một khối nhất định cao hơn. Đơn vị xử lý giao dịch (TPU) của leader hoạt động bằng sáu luồng song song: bốn luồng xử lý giao dịch không bỏ phiếu và hai luồng dành riêng cho giao dịch bỏ phiếu. Mỗi luồng trong bốn luồng giao dịch không bỏ phiếu duy trì hàng đợi riêng, nơi các giao dịch đến chờ được nhóm thành các entry để thực thi. Trước đây, giao dịch được phân bổ ngẫu nhiên vào các luồng này và các hàng đợi ưu tiên packet một cách độc lập mà không biết đến những packet được các luồng khác xử lý.

Trong hệ thống này, mỗi luồng lần lượt duyệt qua hàng đợi để cố gắng khóa và thực thi giao dịch. Sau khi hoàn tất chu kỳ hiện tại, luồng sẽ thu thập thêm packet rồi bắt đầu lại quy trình. Cấu trúc này gây khó khăn cho việc sử dụng phí ưu tiên một cách hiệu quả. Chẳng hạn, trong khi một giao dịch có độ ưu tiên cao đứng đầu hàng đợi của một luồng, một luồng khác có thể đồng thời xử lý từ cuối hàng đợi một giao dịch có phí ưu tiên thấp hơn nhưng liên quan đến cùng tài khoản. Phí ưu tiên chỉ tác động đến thứ tự giao dịch trong từng luồng (nội luồng), chứ không phải trên toàn bộ các luồng (liên luồng). Do đó, mỗi hàng đợi áp dụng cơ chế sắp xếp kết hợp giữa xử lý vào trước-ra trước (FIFO) và cân nhắc phí ưu tiên. Tuy nhiên, không có thứ tự toàn cục nào được áp đặt trên các luồng.

Khi một luồng chuẩn bị thực thi giao dịch, trước tiên nó phải giành được các khóa tài khoản cần thiết. Nếu không có sẵn khóa ghi cần thiết, giao dịch sẽ được đưa lại vào hàng đợi. Việc phân bổ giao dịch ngẫu nhiên vào các luồng làm vấn đề này trầm trọng hơn, vì cùng một loại giao dịch có thể rơi vào những vị trí khác nhau trong hệ thống lập lịch đa luồng. Bản chất ngẫu nhiên này của bộ lập lịch tạo ra độ dao động, khiến vị trí của một giao dịch trong khối thay đổi khó lường.

Bản cập nhật Agave client v1.18 vào tháng 5 năm 2024 đã mang đến một bộ lập lịch giao dịch mới, còn gọi là bộ lập lịch trung tâm. Trong cấu trúc mới này, bộ lập lịch trung tâm xây dựng một đồ thị phụ thuộc gọi là prio-graph để quản lý tốt hơn việc xử lý và ưu tiên các giao dịch xung đột trên mọi luồng. Bản cập nhật lớn này đã cải thiện đáng kể khả năng sắp xếp giao dịch một cách tất định của Solana; giao dịch có phí ưu tiên cao hơn có nhiều khả năng được đưa vào khối hơn.

Prio-graph là một đồ thị có hướng không chu trình (DAG), được cập nhật linh hoạt khi có giao dịch mới được thêm vào. Giao dịch được tổ chức trong đồ thị để tạo thành các chuỗi thực thi, được xử lý theo thứ tự ưu tiên thời gian. Với các giao dịch xung đột, phí ưu tiên quyết định thứ tự chèn. Cách tiếp cận này giảm thiểu tranh chấp khóa, cho phép các lô giao dịch được thực thi trơn tru và giảm độ trễ do xung đột tài nguyên. Hoạt động xác minh tiền biên dịch giao dịch đã được chuyển sang các luồng worker để nâng cao hiệu suất và cho phép xử lý hiệu quả hơn. 

Thiết kế bộ lập lịch mới cải thiện đáng kể khả năng mở rộng và tính linh hoạt, cho phép tăng số lượng luồng mà không có nguy cơ làm gia tăng xung đột khóa. Hơn nữa, phương pháp lập lịch tập trung đã cải thiện khả năng tạo phần thưởng, giúp nhiều đơn vị vận hành validator tăng thu nhập.

Để xem phân tích chi tiết hơn về bộ lập lịch trung tâm, độc giả có thể tham khảo bài viết trước đây trên blog Helius về bản cập nhật Agave 1.18.

Tính độ ưu tiên hiệu quả hơn

Cùng với bản cập nhật bộ lập lịch, công thức tính độ ưu tiên giao dịch được tinh chỉnh để tạo lợi thế cho các giao dịch yêu cầu ít tài nguyên tính toán hơn, mang lại lợi ích cho nhà phát triển và những giao dịch sử dụng ít tài nguyên. 

Công thức mới là:

Độ ưu tiên = (Phí ưu tiên * Số đơn vị tính toán được yêu cầu) + Phí cơ sở / 

(1 + CU thực thi được yêu cầu + CU chữ ký + CU khóa ghi)

Phép tính mới này xét đến mọi chi phí tính toán và vận hành gắn với một giao dịch, đảm bảo mức độ ưu tiên phản ánh chính xác mức tiêu thụ tài nguyên thực tế. Nhờ đó, các giao dịch chuyển token đơn giản hoặc giao dịch SOL gốc không có phí ưu tiên bổ sung được đảm bảo một mức ưu tiên cơ sở trong hàng đợi. Với các giao dịch phức tạp hơn, nhà phát triển không chỉ định giới hạn CU tùy chỉnh bằng lệnh `SetComputeUnitLimit` sẽ gặp bất lợi khi ưu tiên giao dịch so với những người có chỉ định.

Đo lường hiệu quả của thị trường phí cục bộ

Phần này sẽ xem xét dữ liệu liên quan đến LFM của Solana. 

Phí giao dịch trung vị và trung bình

Khi LFM hoạt động hiệu quả, phí cho các giao dịch liên quan đến trạng thái không bị tranh chấp, chẳng hạn như chuyển stablecoin đơn giản, được kỳ vọng sẽ duy trì ở mức thấp. Trong khi đó, phí cho giao dịch truy cập trạng thái bị tranh chấp, như token đầu cơ có thanh khoản thấp, sẽ tăng vọt cùng với nhu cầu. Một chỉ số hữu ích để đánh giá động lực này là so sánh phí ưu tiên giao dịch trung vị và trung bình. Phí trung vị đại diện cho mức phí mà người dùng ở phân vị thứ 50 trả, phản ánh chi phí điển hình, trong khi phí trung bình tính tổng mọi khoản phí chia cho tổng số giao dịch, qua đó làm nổi bật xu hướng tổng thể.

Dữ liệu gần đây xác nhận mô hình kỳ vọng này. Tháng 11 năm 2024 ghi nhận mức hoạt động kinh tế cao nhất từ trước đến nay trên Solana, với phí trung bình cho giao dịch không bỏ phiếu đạt mức cao nhất mọi thời đại, hơn 0.0003 SOL. Mặc dù vậy, phí trung vị vẫn ổn định ở mức 0.00000861 SOL, thấp hơn khoảng 35 lần. Điều này trái ngược với tháng 4 năm 2024, khi một đợt tăng hoạt động kinh tế tương tự khiến phí trung bình vượt 0.0002 SOL, đồng thời phí trung vị cũng tăng lên 0.00001862 SOL, thấp hơn khoảng 10 lần. Sự phân kỳ này nhấn mạnh hiệu quả của việc cô lập phí trong bảo vệ người dùng thông thường khỏi các đợt tăng chi phí trong thời kỳ nhu cầu cao và duy trì trải nghiệm người dùng cho những trường hợp sử dụng không thiên về đầu cơ.

Chúng tôi nhận thấy mối tương quan chặt chẽ giữa phí giao dịch trung vị và trung bình khi phân tích dữ liệu tương tự từ một mạng dựa trên EVM, chẳng hạn như Ethereum L2 Base do Coinbase vận hành, vốn không có LFM. Phí trung bình và trung vị biến động khá đồng bộ do phí cơ sở toàn cục tăng khi nhu cầu tăng. Ngoài ra, khoảng cách giữa phí giao dịch trung vị và trung bình nhỏ hơn đáng kể. Chẳng hạn, vào ngày 5 tháng 12 năm 2024, phí giao dịch trung bình trên Base tăng vọt lên 0,1115 USD, trong khi phí trung vị cũng tăng lên 0,0228 USD—thấp hơn khoảng năm lần.

Tỷ lệ giao dịch bị hoàn tác

Một xu hướng hữu ích khác cần xem xét là tỷ lệ giao dịch bị hoàn tác. Trong giai đoạn hoạt động kinh tế cao vào tháng 4 và tháng 5 năm 2024, người dùng Solana đã báo cáo rộng rãi rằng trải nghiệm người dùng suy giảm khi chuỗi phải chịu lượng spam lớn. Sự thiếu tất định làm giảm khả năng dự đoán và độ tin cậy của việc thực thi giao dịch, khiến người dùng tràn ngập mạng bằng giao dịch spam để tăng cơ hội được đưa vào khối nhanh hơn. 

Searcher thường xuyên gửi giao dịch để tận dụng các cơ hội giao dịch mà không xem xét xác suất thành công. Giao dịch chênh lệch giá có phí ưu tiên thấp không phù hợp vẫn hợp lệ. Giao thức sẽ xử lý chúng sau các giao dịch có phí ưu tiên cao hơn khác và nhiều khả năng chúng sẽ bị hoàn tác do logic trượt giá. 

Tỷ lệ giao dịch bị hoàn tác đạt đỉnh vào tháng 4 năm 2024, chiếm 75,7% tổng số giao dịch không bỏ phiếu. Tỷ lệ này giảm đáng kể sau khi các bản cập nhật quan trọng được triển khai, bao gồm bộ lập lịch trung tâm Agave 1.18.

Một phân tích theo nhóm từ Blockworks Research trong bảy ngày qua (ngày 6–13 tháng 1 năm 2024) cho thấy tỷ lệ hoàn tác khác nhau giữa các mức độ hoạt động. Các địa chỉ thực hiện 1–5 giao dịch mỗi ngày (chủ yếu là người dùng cá nhân) có tỷ lệ hoàn tác 1,4%, tăng lên 4,6% với các địa chỉ thực hiện 6–50 giao dịch mỗi ngày. Đáng chú ý, tỷ lệ hoàn tác của các địa chỉ thực hiện hơn 10.000 giao dịch mỗi ngày tăng vọt lên 66,7%. Hơn nữa, các địa chỉ có mức hoạt động cao với hơn 100.000 giao dịch mỗi ngày (bot) gây ra 95,2% tổng số giao dịch bị hoàn tác. Trong tháng 12 năm 2024, tỷ lệ hoàn tác tổng thể của mọi giao dịch không bỏ phiếu là 41,2%, cho thấy phần lớn tài nguyên tính toán của mạng được dùng để xử lý các giao dịch chênh lệch giá thất bại.

Các vấn đề còn tồn tại và lĩnh vực cần cải thiện

Mặc dù đã có những bước tiến đáng kể, bộ lập lịch của Agave validator client vẫn tiếp tục đối mặt với nhiều thách thức. Phân tích sau đây về khối lượng công việc của các luồng ở giai đoạn banking do kỹ sư Alessandro Decina của Anza thực hiện làm rõ những điểm kém hiệu quả hiện tại và các lĩnh vực cần cải thiện.

Luồng bộ lập lịch: Đây là luồng quan trọng nhất đối với việc tạo khối. Bộ lập lịch tiếp nhận mọi giao dịch đến, sau đó sắp xếp và lên lịch thực thi chúng. 

Các luồng giao dịch bỏ phiếu: Hai luồng chuyên dụng xử lý giao dịch bỏ phiếu, đảm bảo chúng được xử lý tách biệt với giao dịch của người dùng.

Các luồng giao dịch không bỏ phiếu: Bốn luồng tiếp nhận giao dịch theo lịch của bộ lập lịch và xử lý giao dịch người dùng.

Các luồng tiếp nhận QUIC: Các luồng Tokio quản lý việc tiếp nhận giao dịch qua giao thức QUIC khi validator là leader. Trong giai đoạn tắc nghẽn đầu năm 2024, các luồng này là một nút thắt cổ chai đáng kể.

Hình minh họa trên cho thấy mặc dù tất cả luồng worker thực thi giao dịch song song ở đầu khối đầu tiên của leader, tính song song này nhanh chóng suy giảm thành thực thi tuần tự. Cụ thể, chỉ có một luồng giao dịch không bỏ phiếu (luồng thứ ba) tiếp tục xử lý giao dịch, trong khi các luồng còn lại ở trạng thái nhàn rỗi.

Hành vi này cho thấy một lỗi trong bộ lập lịch đang ngăn validator client tận dụng toàn bộ công suất. Do đó, hệ thống chỉ hoạt động ở một phần nhỏ tiềm năng, đồng nghĩa với việc nếu vấn đề được giải quyết, validator có thể xử lý tải cao gấp bốn lần hiện tại.

Khả năng quan sát

Các API phí hiện tại dùng để ước tính khả năng giao dịch được xác nhận một cách có thể dự đoán vẫn chưa đủ tinh vi để cung cấp kết quả tất định. Mỗi nhà cung cấp RPC lớn đều cung cấp API phí ưu tiên tùy chỉnh riêng, trong khi cách triển khai RPC API mã nguồn mở cốt lõi vẫn chưa tối ưu. Cách triển khai này không xem xét các động lực mạng quan trọng như ảnh hưởng của Jito, dẫn đến ước tính phí kém chính xác hơn. 

Helius cung cấp phương thức RPC `getPriorityFeeEstimate`, đưa ra đề xuất phí dựa trên dữ liệu lịch sử từ cả thị trường toàn cục và LFM. Nhà phát triển có thể nhập giao dịch đã ký và tuần tự hóa hoặc danh sách khóa tài khoản liên quan đến giao dịch. Phương thức này hỗ trợ các mức phí ưu tiên tùy chỉnh, được phân thành sáu phân vị: tối thiểu, thấp, trung bình, cao, rất cao và mức tối đa không an toàn. Mức trung bình (phân vị thứ 50) được đặt làm đề xuất mặc định. Phí được tính bằng dữ liệu từ 50 slot gần nhất.

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 encoded serialized transaction
     "options": {
       "recommended": true
     }
   }
 ]
}

Phía trên: Payload mẫu cho getPriorityFeeEstimate sử dụng giao dịch đã tuần tự hóa và mã hóa bằng base58.

Khi không có phương pháp tất định để tính phí ưu tiên, nhà phát triển thường chọn cách thận trọng là trả dư phí để đảm bảo giao dịch được xử lý. Ngoài ra, họ có thể lạm dụng tiền boa Jito, ngay cả với các giao dịch không cần giành vị trí đầu khối. Những khoản tiền boa này thường được dùng để thay thế phí ưu tiên. Đáng chú ý, hầu hết tiền boa được ghi nhận trong năm 2024 không gắn với các hoạt động MEV truyền thống như giao dịch chênh lệch giá hoặc sandwich, mà nhằm giúp giao dịch được đưa vào khối nhanh hơn. Validator hưởng lợi từ sự kém hiệu quả này bằng cách thu phần thưởng khối và hoa hồng MEV cao hơn.

Một thách thức khác xuất hiện khi nhà phát triển không triển khai logic điều chỉnh linh hoạt phí ưu tiên để ứng phó với điều kiện biến động trên chuỗi. Trong các sự kiện lớn như biến động mạnh của thị trường, phí truy cập các tài khoản trạng thái cụ thể có thể tăng đột biến. Ứng dụng không có cơ chế phí động sẽ gặp khó khăn trong các tình huống này vì mức phí tĩnh không đủ để đảm bảo thực thi kịp thời.

Các giải pháp được đề xuất

Nhiều chiến lược đã được đề xuất để tiếp tục cải thiện cấu trúc phí của Solana. Các đề xuất này nhằm tối ưu hóa việc phân bổ tài nguyên mạng và giảm động lực spam.

Phí khóa ghi theo cấp số nhân

Được Tao Zhu (Anza) và Anatoly Yakavenko đề xuất vào tháng 1 năm 2023, SIMD-0110 đưa ra một cơ chế mới để quản lý tắc nghẽn bằng cách áp dụng phí động cho các tài khoản bị tranh chấp. Cơ chế này theo dõi Đường trung bình động hàm mũ (EMA) của mức sử dụng đơn vị tính toán (CU) đối với các tài khoản bị khóa ghi và tăng chi phí khóa ghi cho những tài khoản liên tục có mức sử dụng cao.

Để triển khai hệ thống như vậy, runtime Solana duy trì bộ nhớ đệm LRU (Ít được sử dụng gần đây nhất) chứa khóa công khai của các tài khoản bị tranh chấp và các Compute Unit Pricer (CUP) tương ứng. CUP theo dõi mức sử dụng CU theo EMA của tài khoản và cung cấp mức chi phí cập nhật khi được truy vấn.

Cơ chế này điều chỉnh linh hoạt phí khóa ghi. Mức chi phí khóa ghi tăng nếu mức sử dụng CU theo EMA của tài khoản vượt quá ngưỡng mục tiêu. Ngược lại, nếu mức sử dụng giảm xuống dưới mục tiêu, mức chi phí sẽ giảm. Các tham số ban đầu gồm:

• Mức sử dụng mục tiêu bằng 25% giới hạn CU tối đa của tài khoản.
• Mức chi phí khóa ghi ban đầu là 1.000 micro-lamport trên mỗi CU.
• Tỷ lệ điều chỉnh chi phí là 1% trên mỗi khối.

Phí khóa ghi của một tài khoản được tính bằng cách nhân mức chi phí của tài khoản đó với số CU mà giao dịch yêu cầu. Theo hệ thống này, tổng phí giao dịch là tổng của ba thành phần: phí chữ ký cơ sở, phí ưu tiên và phí khóa ghi. 100% phí khóa ghi bị đốt.

Khi được công bố, SIMD-0110 đã khơi lên cuộc tranh luận sôi nổi trong cộng đồng. Tuy nhiên, đề xuất này hiện không còn hoạt động và đã được đánh dấu là đóng.

Phí cơ sở động

Một giải pháp dài hạn khác để cải thiện LFM của Solana là đưa vào phí cơ sở động (DBF) toàn cục và theo từng tài khoản. Jarry Xiao và Eugene Chen từ Ellipsis Labs là những người ủng hộ nổi bật cho cách tiếp cận này.

Trong khi phí ưu tiên là tùy chọn, phí cơ sở là bắt buộc. Hiện tại, phí cơ sở của Solana được cố định ở mức 5000 lamport cho mỗi chữ ký. Người dùng gửi giao dịch chuyển token đơn giản trả cùng mức phí cơ sở với người thực hiện giao dịch swap phức tạp trên nhiều nền tảng hoặc searcher cố gắng thực hiện giao dịch chênh lệch giá MEV phức tạp. Phí cơ sở không phản ánh chính xác mức sử dụng tài nguyên tính toán của giao dịch.

Với phí cơ sở động, giao dịch chênh lệch giá có phí cơ sở không phù hợp có thể bị coi là không hợp lệ và bị loại trước khi đến bộ lập lịch. Việc tăng phí cơ sở khuyến khích bên spam gửi ít giao dịch hơn.

Phí cơ sở cuối cùng sẽ đạt trạng thái cân bằng và giao dịch sẽ được định giá dựa trên giá trị của thị trường không gian khối. Vì phí cơ sở tăng dần, cuối cùng nó sẽ đạt chi phí cận biên, tại đó chi phí cơ hội của giao dịch khiến việc gửi giao dịch không còn đáng giá. Phí không thể tăng quá cao, nếu không hoạt động của người dùng sẽ bị ảnh hưởng. Mức tối đa đủ cao đối với bot nhưng nhìn chung vẫn chấp nhận được với người dùng là lý tưởng. Theo hệ thống như vậy, các tài khoản spam giao dịch để được đưa vào khối sẽ đốt hết SOL của mình.

Thời gian khối nhanh của Solana cho phép dùng các thuật toán quyết liệt để thiết lập phí cơ sở. Trong giai đoạn nhu cầu cao, phí có thể được điều chỉnh nhanh chóng—có thể tăng gấp đôi sau mỗi khối—để phản ánh tình trạng tắc nghẽn mạng. Ngược lại, khi nhu cầu giảm, phí có thể được hạ dần. Nhờ thời gian khối ngắn của Solana, việc giảm phí vẫn diễn ra tương đối nhanh, đảm bảo mạng thích ứng nhanh chóng với các điều kiện thay đổi.

Một ví dụ về hình thức tạo áp lực ngược về kinh tế tương tự là chương trình Metaplex Candy Machine, chương trình đã áp dụng thuế bot như một cơ chế chống spam vào năm 2022. Thuế bot là khoản phí tùy chọn dành cho giao dịch không hợp lệ. Thông thường, đây là một khoản tương đối nhỏ để tránh ảnh hưởng đến người dùng thực mắc lỗi ngoài ý muốn. Khoản thuế này đã chứng minh tính hiệu quả; nguồn tiền của các bot săn mint nhanh chóng cạn kiệt và hoạt động spam chấm dứt.

Kết luận

LFM của Solana đã hoạt động, nhưng vẫn còn nhiều dư địa để cải thiện:

• Cải thiện cơ chế phí ưu tiên: Các lệnh gọi RPC phí ưu tiên cần được cải thiện. Lý tưởng nhất là nhà phát triển có một cách đơn giản, tất định để đặt mức phí đảm bảo giao dịch được đưa vào một trong vài khối tiếp theo.
• Tạo rào cản kinh tế đối với spam: Mạng phải tìm ra cách tạo áp lực ngược về kinh tế đối với bot trong giai đoạn hoạt động kinh tế cao, đồng thời duy trì phí thấp cho người dùng thực.
• Đào tạo nhà phát triển: Nhà phát triển cần ngừng đặt phí giao dịch tĩnh cho ứng dụng và giảm phụ thuộc vào các cơ chế ngoài giao thức như Jito đối với giao dịch thông thường.
• Tiếp tục tối ưu hóa bộ lập lịch: Bộ lập lịch giao dịch cần được tối ưu hóa thêm để đảm bảo mọi luồng worker đều được sử dụng trong giai đoạn nhu cầu cao.

Như Anatoly Yakovenko, đồng sáng lập Solana, đã chỉ ra, những thách thức này chủ yếu “chỉ là các vấn đề kỹ thuật”—có thể giải quyết nếu tập trung đúng vào kỹ thuật.

Tài nguyên bổ sung

• Phí Solana, Phần 1 - Umbra Research
• Hướng tới phí Solana đa chiều - Umbra Research
• Thị trường phí cục bộ là yếu tố cần thiết để mở rộng Ethereum - Eclipse Labs
• Thị trường phí cục bộ của Solana không thực sự tồn tại | Eugene Chen - Lightspeed Podcast
• Giai đoạn banking và bộ lập lịch của Solana - A.Fitzgerald