Phí Solana trong lý thuyết và thực tiễn

Giới thiệu

Cấu trúc phí của Solana được thiết kế để duy trì hiệu năng mạng, đồng thời cân bằng những biến động không đồng đều về cung và cầu. Phí trên mọi blockchain đều nhằm ngăn chặn spam và tạo động lực cho các validator. Trên Solana, một số loại phí được điều chỉnh linh hoạt theo tình trạng mạng, cho phép mạng định giá nhu cầu tại từng thời điểm chính xác hơn.

Phí trên Solana là một chủ đề được quan tâm, với “thị trường phí cục bộ” giúp Solana linh hoạt hơn trong việc định giá chính xác không gian khối và các tài khoản cụ thể. Cách triển khai hiện tại còn lâu mới hoàn hảo, nhưng vẫn đưa ra những đảm bảo tương đối về thứ tự trên từng tài khoản. Dù Solana vẫn đang ở giai đoạn đầu, lượng stake và hoạt động ngày càng tăng trên mạng đòi hỏi phải thảo luận và phân tích sâu hơn về các tác động bậc một và bậc hai của mọi thay đổi trong giao thức, chẳng hạn như thay đổi mô hình phí.

Trong bài viết này, chúng ta sẽ tìm hiểu phí cả về mặt lý thuyết lẫn cách chúng biểu hiện on-chain. Một số người đã chỉ trích Solana vì tính tập trung và các yếu tố thúc đẩy tập trung hóa trong thiết kế QoS có trọng số theo stake và Turbine, nhưng trong nhiều năm qua vẫn có sự khác biệt rõ rệt giữa những nhận định này và thực tế. Tương tự, chúng tôi hướng đến việc phân tích toàn diện cách phí biểu hiện qua hành vi on-chain.

Phí trong lý thuyết

Hệ thống phí của Solana gồm hai thành phần: phí cơ sở và phí ưu tiên. Nhìn chung, mỗi thành phần phí lý tưởng nhất sẽ phục vụ mục đích sau:

• Phí cơ sở: quyền sử dụng tài nguyên của mạng
• Phí ưu tiên: xác định thứ tự trong hàng đợi giao dịch của leader

Phí cơ sở

Phí cơ sở, hiện được đặt ở mức 0,000005 SOL (5.000 lamport) cho mỗi chữ ký, là nền tảng của chi phí giao dịch. Đây là khoản phí mà một địa chỉ trả để có quyền sử dụng tài nguyên của mạng. Khoản phí trọn gói này được trả trước cho mạng, bất kể lượng tài nguyên thực tế được dùng để thực thi giao dịch là bao nhiêu (hoặc giao dịch có được thực thi hay không). Các giao dịch Solana yêu cầu trước một số lượng đơn vị tính toán (CU) cụ thể. Nếu vượt quá con số này, giao dịch sẽ thất bại. Điều này có nghĩa là hiện tại các nhà phát triển có rất ít hoặc không có động lực tài chính để giảm thiểu số đơn vị tính toán yêu cầu.

Phí ưu tiên

Ngoài ra, người dùng có thể trả phí ưu tiên để đẩy nhanh giao dịch, qua đó tăng khả năng được đưa vào một khối. Đây là một đảm bảo không mang tính xác định dành cho người dùng trả phí để được ưu tiên. Các nỗ lực cải thiện tính xác định của giao dịch đang được tiến hành, với những thay đổi đáng kể đối với bộ lập lịch dự kiến sẽ xuất hiện trong phiên bản 1.18.

Lưu ý thêm rằng các giao dịch bỏ phiếu không có phí ưu tiên liên quan và được xử lý khác với giao dịch tiêu chuẩn.

Động lực để validator đưa các giao dịch có phí ưu tiên vào khối nằm ngoài runtime. Leader nhận 50% phí ưu tiên khi đưa giao dịch vào khối của mình, còn 50% kia bị đốt.

Hiện nay, hầu hết validator (trên 80%) chạy các phiên bản chưa sửa đổi của client Solana Labs hoặc Jito-Solana. Điều này có nghĩa là các validator này giao việc “sản xuất khối” cho bộ lập lịch mặc định (một số người trên Solana gọi “sắp xếp khối” là “sản xuất khối”, trong khi khái niệm này có ý nghĩa hoàn toàn khác trên Ethereum). Một số đội ngũ đã sửa đổi mã client và triển khai bộ lập lịch phức tạp hơn để kiểm soát luồng sắp xếp tốt hơn, cho phép họ khai thác MEV bằng cách sắp xếp lại hoặc chèn giao dịch kiểu sandwich.

Tính bất định của phí ưu tiên

Cách triển khai hiện tại của bộ lập lịch không đảm bảo rằng các giao dịch có phí ưu tiên cao hơn sẽ được đưa vào một khối nhất định. Thay vào đó, nó chỉ đảm bảo tương đối rằng giao dịch có phí ưu tiên sẽ có khả năng được đưa vào một khối nhất định cao hơn. Cách triển khai hiện tại của bộ lập lịch sử dụng 4 lõi thực thi (2 lõi bổ sung được dành riêng cho giao dịch bỏ phiếu).

Mỗi luồng vận hành hàng đợi riêng và ưu tiên các gói tin một cách độc lập, không biết các gói tin đang được những luồng khác xử lý. Mỗi luồng liên tục chạy theo chu kỳ từ đầu đến cuối, cố gắng khóa và thực thi các giao dịch. Khi hoàn tất chu kỳ hiện tại, luồng sẽ thu thập thêm gói tin và bắt đầu lại chu kỳ.

Do đó, một giao dịch có mức ưu tiên cao có thể đang được xử lý ở đầu hàng đợi của một luồng, trong khi một luồng khác đồng thời sắp hoàn tất hàng đợi của mình bằng cách xử lý một giao dịch liên quan đến cùng tài khoản đó.

Các chi tiết cụ thể về cách triển khai hiện tại và tương lai của bộ lập lịch sẽ được trình bày trong một bài viết riêng. Chỉ cần hiểu rằng phí ưu tiên chỉ hoạt động ở cấp độ nội luồng (trong cùng một làn), chứ không phải liên luồng (giữa các làn), là đủ để thấy bộ lập lịch còn lâu mới hoàn hảo và có hiện tượng “dao động”.

Phí trong thực tiễn

Giao dịch được ghi nhận

Mặc dù phí là yếu tố quan trọng quyết định một giao dịch có được ghi nhận hay không, đây không phải yếu tố duy nhất. Ví dụ, giao dịch có thể không được ghi nhận chỉ vì một gói tin mạng UDP bị mất. Trong thời gian mạng hoạt động ở mức cao, validator có thể nhận nhiều giao dịch hơn khả năng xử lý. Dù validator có thể chuyển tiếp các giao dịch dư thừa thông qua cơ chế tpu_forwards, chúng chỉ có thể xử lý một lượng dữ liệu hữu hạn và mỗi giao dịch cũng chỉ có thể được chuyển tiếp số lần hữu hạn (cho đến khi blockhash hết hạn). Chất lượng dịch vụ có trọng số theo stake giúp giảm nhẹ một số vấn đề này cho các địa chỉ có lượng stake cao hơn bằng cách cung cấp băng thông dành riêng và tăng khả năng giao dịch được đưa vào khối.

Ngoài ra còn có hai nguyên nhân ít được thảo luận hơn khiến giao dịch bị loại. Nguyên nhân đầu tiên liên quan đến sự không đồng nhất trong một pool RPC. Một phần của pool RPC có thể tiến nhanh hơn các phần khác, gây ra vấn đề phối hợp. Ví dụ, nếu recentBlockhash của một giao dịch được lấy từ phần đã cập nhật hơn rồi gửi đến một phần chậm hơn, phần chậm hơn có thể không nhận diện được blockhash mới và do đó loại bỏ giao dịch. Nhà phát triển có thể phát hiện những vấn đề này tại thời điểm gửi nếu đã bật bước kiểm tra preflight trong hàm sendTransaction.

Một vấn đề khác phát sinh quanh các fork mạng tạm thời. Nếu một validator chậm xử lý các khối của mình, giao dịch có thể rơi vào một fork thiểu số không trở thành chuỗi chính thức. Khi client tham chiếu đến một recentBlockhash trong giao dịch chỉ tồn tại trên fork thiểu số này, rồi mạng từ bỏ fork trước khi xử lý giao dịch, giao dịch sẽ bị loại vì không còn tìm thấy blockhash.

Phí ưu tiên

Trong thực tế, có bằng chứng cho thấy dù còn lâu mới hoàn hảo, phí ưu tiên vẫn phát huy tác dụng ở quy mô vĩ mô. Những giao dịch có phí ưu tiên nhiều khả năng được đưa vào khối hơn, và giao dịch đặt mức phí ưu tiên cao hơn có khả năng được đưa vào khối lớn hơn.

Dựa trên dữ liệu Helius RPC, chúng tôi nhận thấy giao dịch có phí ưu tiên nhiều khả năng được ghi nhận hơn và khi được ghi nhận, chúng nhìn chung cũng nhanh hơn:

Ngày 21 tháng 1, phí ưu tiên trung bình tăng đột biến do đợt airdrop mockJUP nhằm chuẩn bị cho đợt airdrop JUP chính thức vào tuần sau. Mặc dù nhu cầu về không gian khối thay đổi đáng kể, người dùng thực tế chỉ cảm nhận được rất ít thay đổi về tỷ lệ và thời gian giao dịch được ghi nhận.

Trải nghiệm người dùng này chủ yếu được hỗ trợ bởi phương thức Solana RPC getRecentPrioritizationFees, cho phép nhà phát triển xác định chính xác mức phí ưu tiên cần thêm vào giao dịch. Endpoint trả về danh sách phí ưu tiên trong 150 khối gần nhất đã được dùng để ghi nhận thành công ít nhất một giao dịch với địa chỉ và các tham số đầu vào tương ứng. Dữ liệu này cung cấp một ảnh chụp nhanh về giá trị tối thiểu cần đặt cho phí ưu tiên, nhưng tính hữu dụng tương đối hạn chế. Ngoài ra, Helius cung cấp Priority Fee API, thực hiện thêm các phép tính để đưa ra ước tính phí ưu tiên tốt hơn.

Mặc dù về lý thuyết phí ưu tiên phần nào hoạt động như dự kiến, những thay đổi sắp tới đối với bộ lập lịch trong phiên bản 1.18 sẽ cải thiện tính xác định khi đưa giao dịch vào khối. Điều này sẽ làm giảm lượng spam được ghi on-chain, vì chiến lược chủ đạo không còn đòi hỏi phải spam chuỗi để giao dịch được đưa vào khối.

Phí cơ sở

Phí cơ sở trên Solana chắc chắn quá thấp. Các khối bị lấp đầy trong khi phí không điều chỉnh linh hoạt, khiến phí cơ sở không thể đạt mức giá cân bằng thị trường cho không gian khối. Trên Ethereum, phí cơ sở linh hoạt được thực hiện thông qua cơ chế điều khiển của EIP-1559, xem xét các khối gần đây và nhắm đến tỷ lệ sử dụng 50%.

Solana ấn định mức phí cố định là 5.000 lamport cho mỗi chữ ký (thường là 1 chữ ký cho mỗi giao dịch). Điều này khiến phí cơ sở không hiệu quả vì không phản ánh bất kỳ thay đổi nào về nhu cầu không gian khối và mức sử dụng tài nguyên của validator. Trên thực tế, vai trò định giá bị đẩy sang phí ưu tiên như một giải pháp dựa trên thị trường thay cho phí cơ sở, khiến mạng càng tắc nghẽn khi validator xử lý thêm những giao dịch vốn có thể không bao giờ được đưa vào khối. Hơn nữa, chiến lược chủ đạo là gửi số lượng lớn giao dịch với mức phí ưu tiên tối thiểu để được đưa vào khối. Điều này gây ra tác động ngoại biên lớn đối với trải nghiệm người dùng của mọi bên tham gia mạng.

Động lực

RPC có động lực chuyển tiếp thông tin chính xác xuống hạ nguồn để đạt tỷ lệ giao dịch được đưa vào khối cao nhất với chi phí tối thiểu. Việc tích hợp với các validator có lượng stake hàng đầu giúp RPC có cái nhìn chính xác hơn về trạng thái hiện tại của mạng, vì nhiều cơ chế của Solana được tính trọng số theo stake. Từ đó hình thành mối quan hệ cộng sinh, trong đó các validator có lượng stake lớn và RPC tích hợp có thể nâng cao hiệu quả cũng như độ tin cậy của quá trình xử lý giao dịch, qua đó có khả năng tạo ra vòng phản hồi tiếp tục củng cố vị thế của các validator có lượng stake hàng đầu.

Ngoài ra, bản thân RPC — hiện được xem là validator không có stake — cũng sẽ được tính trọng số theo stake. RPC có thể tự thu hút stake mà không cần hợp tác với validator. Việc các ứng dụng tự vận hành validator để tích hợp theo chiều dọc sâu hơn không phải là hiếm. Điều này cho phép họ kiểm soát tốt hơn trải nghiệm người dùng cuối và chuỗi cung ứng giao dịch/MEV.

Mặc dù động lực kinh tế cho thấy xu hướng tập trung hóa stake, Solana vẫn chưa chứng kiến sự tập trung vốn trên quy mô lớn để hưởng lợi từ cơ chế tính trọng số theo stake. Điều này có thể xuất phát từ một số nguyên nhân:

• Các cá nhân có thể coi việc tối đa hóa tính phi tập trung ở cấp độ cục bộ là chiến lược chủ đạo để mạng đạt lợi ích dài hạn, chủ yếu nhờ văn hóa và tầng xã hội của Solana.
• Phần lớn bên tham gia Solana là nhà đầu tư cá nhân và prosumer, nên họ không nhạy cảm với lợi nhuận như các công ty chuyên nghiệp. Khi mức độ hoạt động và lợi nhuận tuyệt đối tăng lên, điều này có thể thúc đẩy những thay đổi về cơ cấu bên tham gia và mức độ nhạy cảm với lợi nhuận.
• Các cá nhân chưa phối hợp tốt trong hoạt động tiếp thị những sản phẩm khác biệt của mình.

Kết luận

Trong bài viết này, chúng tôi đã mô tả chi tiết lý thuyết tổng quan về cơ chế phí của Solana và cách cơ chế này tác động đến mạng on-chain. Phí tạo ra động lực, kéo theo những tác động ngoại biên lớn và ảnh hưởng đến hành vi của mọi bên tham gia Solana.

Các cơ chế như phí cơ sở và phí ưu tiên trên Solana chưa hoàn hảo trong cách triển khai hiện tại. Phí cơ sở không thể điều chỉnh và không phản ánh trạng thái cân bằng cung cầu hiện tại. Điều này dẫn đến những vấn đề như tắc nghẽn mạng và phân bổ tài nguyên kém hiệu quả. Phí ưu tiên có mức độ bất định nhất định do cách triển khai hiện tại của bộ lập lịch. Các bản cập nhật trong tương lai, chẳng hạn như những thay đổi dự kiến đối với bộ lập lịch, hứa hẹn mang lại tính xác định và hiệu quả cao hơn cho quá trình xử lý giao dịch, qua đó có thể định hình lại hành vi on-chain mà chúng ta quan sát hiện nay.

Các đề xuất mới đang được xem xét, chẳng hạn như phí lũy tiến cho các tài khoản bị khóa ghi, nhằm định giá chi phí giao dịch chính xác hơn khi giao dịch tùy ý khóa quyền truy cập vào tài khoản. Ngoài ra, cộng đồng cũng đang thảo luận về cơ chế phí cơ sở linh hoạt để định giá quyền truy cập vào trạng thái chính xác hơn.

Sự tương tác giữa phí, validator và RPC tạo thành một mạng lưới động lực phức tạp. Về lý thuyết, validator và RPC có động lực tích hợp với nhau và tăng trọng số stake, từ đó có thể làm dấy lên lo ngại về tính tập trung. Tuy nhiên, trên thực tế, Solana vẫn duy trì được một tập hợp nhà vận hành và stake phi tập trung. Điều này có thể nhờ cơ chế quản trị do cộng đồng thúc đẩy, các rào cản kỹ thuật, những động lực kinh tế đối trọng và các hàm tối ưu hóa hiện chưa chủ yếu hướng đến lợi nhuận.