Giao dịch không tốn phí trên Solana: Hướng dẫn đầy đủ

Giao dịch không tốn phí trên Solana cho phép người tài trợ thanh toán phí mạng cho người dùng. Chúng không loại bỏ phí, làm cho mọi giao dịch trở nên miễn phí, hoặc đảm bảo rằng việc ký một giao dịch được tài trợ không thể di chuyển tài sản của người dùng.

Cập nhật lần cuối: Tháng 1 năm 2025

Giao dịch không tốn phí trên Solana là các giao dịch blockchain mà người dùng cuối không phải trả bất kỳ khoản phí mạng nào vì một bên thứ ba được chỉ định, gọi là nhà tài trợ phí, sẽ chi trả chi phí thay mặt họ. Thuật ngữ "không tốn phí" (gasless) được mượn từ thuật ngữ phí của Ethereum, nơi phí được gọi là "gas". Bản thân Solana sử dụng "phí giao dịch", không phải gas. Nhưng theo cách nói thông tục, "không tốn phí" đã trở thành có nghĩa tương tự trên các chuỗi: người dùng không trả gì, và người khác sẽ thanh toán hóa đơn.

Solana không miễn phí theo mặc định. Mọi giao dịch trên mạng đều yêu cầu một khoản phí thanh toán bằng SOL. Nhiều dApp (ứng dụng phi tập trung) sẽ tài trợ các khoản phí đó thay cho bạn, cho phép bạn bắt đầu mà không cần giữ bất kỳ SOL nào. Việc bạn có cần SOL hay không phụ thuộc vào dApp cụ thể: các dApp hỗ trợ không tốn phí sẽ chi trả phí cho bạn, trong khi các dApp khác yêu cầu bạn tự thanh toán. Hướng dẫn này bao gồm kiến trúc người trả phí, ai trả và tại sao, các trường hợp sử dụng thực tế, các lộ trình triển khai, phân tích chi phí và các cân nhắc về bảo mật.

Mục lục

1. Khái niệm cốt lõi: Kiến trúc người trả phí của Solana hoạt động như thế nào
2. Không tốn phí vs. Miễn phí: Làm rõ hiểu lầm phổ biến nhất
3. Solana vs. Ethereum: Giao dịch không tốn phí khác với trừu tượng hóa tài khoản như thế nào
4. Cách triển khai giao dịch không tốn phí trên Solana
5. Trường hợp sử dụng thực tế: Giao dịch không tốn phí đã được triển khai ở đâu trên Solana
6. Chi phí tài trợ giao dịch: Giao dịch không tốn phí thực sự tốn bao nhiêu chi phí cho nhà phát triển?
7. Cân nhắc về bảo mật: Nhà phát triển cần biết gì về rủi ro của relayer
8. Chọn phương pháp phù hợp: Triển khai gốc so với dịch vụ được quản lý
9. Các câu hỏi thường gặp về giao dịch không tốn phí trên Solana
10. Tóm tắt: Những gì bạn cần biết về giao dịch không tốn phí trên Solana

Khái niệm cốt lõi: Kiến trúc người trả phí của Solana hoạt động như thế nào

Mọi giao dịch Solana đều bao gồm một trường feePayer chỉ định tài khoản nào có số dư SOL sẽ bị trừ để trang trải phí mạng, và tài khoản này không nhất thiết phải là người khởi tạo giao dịch.

Mô hình phí giao dịch của Solana

Solana tính một mức phí cơ sở cho mỗi chữ ký và cũng có thể tính phí ưu tiên. Tham số phí cơ sở và số tiền được định giá bằng SOL của nó nên được kiểm tra với tài liệu hiện tại; tổng chi phí giao dịch có thể thay đổi tùy thuộc vào chữ ký, cài đặt tính toán, phí ưu tiên và điều kiện mạng. Các validator, các node mạng xử lý và xác thực giao dịch, thu thập các khoản phí này như một khoản đền bù cho công việc tính toán của họ. Proof of History là một thành phần ghi lại thời gian được sử dụng cùng với Proof of Stake và Tower BFT. Con số 65.000 TPS thường được trích dẫn là một điểm chuẩn lý thuyết thay vì thông lượng ứng dụng được đảm bảo.

Để biết cấu trúc phí đầy đủ, hãy xem tài liệu về phí giao dịch của Solana.)

Người trả phí trên Solana là gì?

Người trả phí trên Solana là tài khoản được chỉ định để thanh toán phí giao dịch. Trong một giao dịch tiêu chuẩn, người trả phí và người ký giao dịch là cùng một tài khoản (ví của người dùng). Trong giao dịch không tốn phí, chúng là các tài khoản khác nhau. Cả hai tài khoản phải ký giao dịch, nhưng chỉ số dư SOL của người trả phí mới bị trừ cho phí mạng.

Sự tách biệt này được tích hợp vào cấu trúc giao dịch cơ bản của Solana thông qua trường feePayer. Đây không phải là một giải pháp tạm thời, một chương trình riêng biệt trên chuỗi, hay một bổ sung ở lớp ứng dụng. Bất kỳ giao dịch Solana nào cũng có thể chỉ định một người trả phí khác bằng cách đặt trường này. Để biết thông số kỹ thuật, hãy xem tài liệu về người trả phí của Solana.

Luồng giao dịch không tốn phí qua mạng, từng bước:

1. Người dùng khởi tạo một hành động trong dApp (đúc NFT, hoán đổi token, hoặc bất kỳ hành động nào khác trên chuỗi).
2. dApp xây dựng một đối tượng giao dịch và đặt trường feePayer thành một tài khoản tài trợ riêng biệt, không phải ví của người dùng.
3. Người dùng ký giao dịch thông qua ví của họ, ủy quyền cho chỉ thị (hành động). Chữ ký của họ không trừ vào số dư của họ.
4. Giao dịch đã ký một phần được gửi đến máy chủ relayer, nơi giữ cặp khóa tài trợ.
5. Relayer xác thực nội dung giao dịch để xác nhận chúng khớp với chương trình và dữ liệu chỉ thị dự kiến.
6. Relayer thêm chữ ký của người trả phí bằng cách sử dụng cặp khóa tài trợ.
7. Relayer gửi giao dịch đã ký đầy đủ đến mạng Solana, mạng này sẽ trừ phí từ số dư của người trả phí, không phải của người dùng.

Hãy coi nó giống như một hóa đơn nhà hàng. Người dùng gọi món (ký chỉ thị), nhưng ứng dụng sẽ thanh toán hóa đơn (trả phí).

Relayer giao dịch là gì?

Relayer giao dịch là dịch vụ backend giúp giao dịch không tốn phí hoạt động. Relayer nhận một giao dịch đã ký một phần từ người dùng (người đã ký để ủy quyền chỉ thị nhưng chưa thanh toán phí), thêm chữ ký của người trả phí và gửi giao dịch đã ký đầy đủ đến mạng Solana. Tồn tại hai mô hình: relayer tự host, nơi nhà phát triển dApp tự chạy máy chủ của mình, và dịch vụ relayer được quản lý, nơi nhà cung cấp bên thứ ba như Helius xử lý cơ sở hạ tầng.

Trong một giao dịch tiêu chuẩn, ví của bạn thực hiện hai chức năng: nó ủy quyền hành động và nó thanh toán phí. Trong giao dịch không tốn phí, ví của bạn chỉ thực hiện chức năng đầu tiên. Khi bạn sử dụng dApp hỗ trợ không tốn phí, ví Phantom của bạn (hoặc Solflare, Backpack, hoặc bất kỳ ví Solana nào khác) sẽ nhắc bạn ký giao dịch như bình thường. Bạn phê duyệt nó. Việc ký này ủy quyền cho chỉ thị: đúc NFT này, thực hiện giao dịch hoán đổi này, cập nhật bản ghi này. Số dư SOL của ví bạn sẽ không thay đổi sau khi xác nhận đó. Phí sẽ được thanh toán bởi tài khoản người trả phí của dApp, tài khoản này được relayer kiểm soát. Một ví tương thích không nên tiết lộ khóa riêng tư của nó, và người tài trợ thanh toán phí mạng. Tuy nhiên, các chỉ thị mà người dùng ký vẫn có thể ủy quyền chuyển token hoặc các thay đổi trạng thái khác, vì vậy giao dịch đầy đủ phải được xem xét.

Để biết chi tiết triển khai kỹ thuật đầy đủ của từng phương pháp relayer, hãy xem hướng dẫn triển khai.

Thuật ngữ chính

• Người trả phí (Fee Payer): Tài khoản có số dư SOL chi trả phí giao dịch. Trong quy trình không tốn phí, tài khoản này do dApp kiểm soát, không phải người dùng.
• Relayer giao dịch (Transaction Relayer): Dịch vụ backend nhận giao dịch đã ký một phần, thêm chữ ký của người trả phí và gửi nó đến mạng.
• Nhà tài trợ phí (Fee Sponsor): Thực thể (nhà phát triển dApp, giao thức, hoặc dịch vụ được quản lý) tài trợ cho tài khoản người trả phí và chịu chi phí giao dịch.

[SƠ ĐỒ: Sơ đồ luồng ba nút hiển thị "Ví người dùng ký chỉ dẫn" với mũi tên ghi chú "Giao dịch đã ký một phần" trỏ đến "Relayer / Bên thanh toán phí ký + trả phí" với mũi tên ghi chú "Giao dịch đã ký đầy đủ" trỏ đến "Mạng Solana xác nhận" và mũi tên cuối cùng trỏ đến "Hành động hoàn tất trong ví người dùng." Nhóm thiết kế: các nút từ trái sang phải với các mũi tên định hướng có nhãn.]

Gasless so với Miễn phí: Làm rõ hiểu lầm phổ biến nhất

Gasless là cách gọi tắt của việc phí được tài trợ: phí mạng lưới vẫn tồn tại và luôn được chi trả, nhưng người dùng cuối không phải là bên chi trả khoản phí đó.

Có ba kịch bản phí tồn tại trên Solana, và chỉ một trong số đó là thực sự gasless:

• Giao dịch tiêu chuẩn: Người dùng trả phí từ Số dư SOL của chính họ. Phí là 0,000005 SOL cho mỗi chữ ký.
• Giao dịch Gasless (được tài trợ): dApp, giao thức hoặc dịch vụ relayer được quản lý sẽ trả phí thay cho người dùng. Số dư SOL của người dùng không bị ảnh hưởng.
• Giao dịch phí thấp: Người dùng trả một khoản phí nhỏ đến mức họ hầu như không nhận thấy. Đây không phải là gasless; người dùng vẫn cần SOL.

Tài trợ giao dịch là thuật ngữ hướng đến doanh nghiệp để mô tả cách thức hoạt động của các giao dịch gasless. Từ góc độ sản phẩm, việc chi trả phí giao dịch là một chi phí thu hút người dùng, tương tự như việc cung cấp bản dùng thử miễn phí hoặc trả tiền cho lượt hiển thị quảng cáo.

Một câu hỏi hợp lý nảy sinh: nếu tôi không trả tiền, điểm mấu chốt ở đây là gì? Câu trả lời rất minh bạch. Chi phí đối với bên tài trợ là không đáng kể ở mức Phí cơ sở của Solana. Tài trợ cho 100.000 giao dịch tốn 0,5 SOL Phí cơ sở. Một Nền tảng chạy đúc NFT gasless sẽ thu lại chi phí đó gấp nhiều lần thông qua phí thị trường, doanh thu bán hàng sơ cấp hoặc sự giữ chân người dùng. Một số Nền tảng thu hồi chi phí thông qua các gói đăng ký hoặc Tokenomics của giao thức.

Khoản phí luôn đi đến đâu đó. Nó chuyển đến các validator của Solana. Câu hỏi chỉ là ai là người gửi nó.

Để thảo luận đầy đủ về các rủi ro đi kèm với việc tài trợ phí, hãy xem phần cân nhắc bảo mật.

Solana so với Ethereum: Các giao dịch Gasless khác biệt thế nào với Account Abstraction

Mô hình gas của Ethereum là nguồn gốc của khái niệm "gasless", và việc so sánh kiến trúc bên thanh toán phí gốc của Solana với Account Abstraction EIP-4337 của Ethereum cho thấy lý do tại sao hai phương pháp này đạt được trải nghiệm người dùng tương tự thông qua các phương tiện kỹ thuật khác nhau.

Ethereum tính "gas" cho tính toán. Phí gas có tính biến động, do thị trường thúc đẩy và được thanh toán bằng ETH (tính theo đơn vị gwei). Trong thời gian tắc nghẽn mạng cao điểm, phí giao dịch Ethereum đã từng đạt mức 50 USD hoặc hơn cho mỗi giao dịch. Sự biến động này chính là lý do tại sao UX gasless trở thành một mục tiêu thiết kế có ý nghĩa ngay từ đầu. Khi so sánh phí Solana với gas Ethereum, khoảng cách Phí cơ sở giải thích tại sao việc tài trợ phí là không đáng kể về mặt kinh tế trên Solana và thực sự đắt đỏ trên Ethereum. Phí gas Ethereum so với phí giao dịch của Solana thể hiện sự chênh lệch nhiều bậc về chi phí thông thường.

Giải pháp của Ethereum cho UX gasless là EIP-4337, một tiêu chuẩn lớp ứng dụng (không phải thay đổi cấp độ giao thức) giới thiệu các paymaster. Paymaster là các hợp đồng thông minh tài trợ Phí gas thay mặt cho người dùng. Việc triển khai một paymaster yêu cầu một trình gom (bundler) UserOperation, một hợp đồng EntryPoint và chính hợp đồng paymaster đó. Đây là một khoản đầu tư cơ sở hạ tầng đáng kể trước khi bất kỳ người dùng nào có thể hưởng lợi. Để biết đặc tả đầy đủ, hãy xem đặc tả EIP-4337.

Trước EIP-4337, Ethereum đã sử dụng meta-transactions (được chuẩn hóa theo ERC-2771) như một giải pháp thay thế. Người dùng sẽ ký một thông báo thể hiện ý định, và một relayer sẽ gói thông báo đó thành một giao dịch đầy đủ và trả Phí gas. Cách tiếp cận của Solana sạch hơn về mặt kiến trúc vì việc tách biệt bên thanh toán phí là một tính năng giao thức cấp một thay vì là một mô hình gói thông báo lớp ứng dụng.

Từ "gasless" áp dụng cho Solana là thuật ngữ vay mượn. Tài liệu của Solana sử dụng "phí giao dịch", không phải "gas". Việc áp dụng thuật ngữ "gasless" trong giao tiếp thông thường phản ánh cách Ethereum đã định hình từ vựng của mô hình UX này trên khắp các chuỗi.

Các giải pháp Layer 2 của Ethereum đã giảm chi phí gas trên Mainnet, và lưu ý này cần có trong bất kỳ sự so sánh nào. Bảng trên phản ánh các phạm vi lịch sử của Ethereum Mainnet. Sự khác biệt về cấu trúc vẫn còn đó: bên thanh toán phí của Solana là một tính năng giao thức không yêu cầu triển khai thêm hợp đồng, trong khi EIP-4337 là một tiêu chuẩn lớp ứng dụng yêu cầu một ngăn xếp paymaster được triển khai.

Cách triển khai giao dịch Gasless trên Solana

Có ba cách tiếp cận triển khai để thêm tính năng tài trợ phí vào một ứng dụng Solana. Lựa chọn đúng đắn tùy thuộc vào khối lượng giao dịch, nguồn lực phát triển, yêu cầu bảo mật và khả năng chấp nhận các phụ thuộc từ Bên thứ ba. Cả ba phương pháp đều sử dụng trường feePayer gốc của Solana làm cơ chế giao thức nền tảng.

Cách tiếp cận 1: Thiết lập Bên thanh toán phí trong một SDK được hỗ trợ

Cách tiếp cận gốc thiết lập trường bên thanh toán phí trên một đối tượng giao dịch và sử dụng một tài khoản tài trợ được quản lý an toàn và được nạp SOL. Các nhóm nên sử dụng một SDK được duy trì phù hợp với môi trường kỹ thuật đã được phê duyệt và xác minh hành vi so với đặc tả giao dịch Solana hiện tại.

Điều kiện tiên quyết: một tài khoản tài trợ đã được nạp tiền được giữ trong một hệ thống ký hoặc quản lý bí mật đã được phê duyệt, một kết nối RPC, các quy tắc xác thực giao dịch, giám sát và một thư viện máy khách được duy trì.

Các bước:

1. Tạo một đối tượng Transaction mới.
2. Thêm chỉ dẫn liên quan (đúc, hoán đổi, chuyển tiền hoặc lệnh gọi chương trình khác).
3. Thiết lập transaction.feePayer = sponsorKeypair.publicKey để chỉ định tài khoản tài trợ.
4. Lấy recentBlockhash và gán nó cho giao dịch. Blockhash sẽ hết hạn sau khoảng 150 slot (khoảng 60 đến 90 giây); hãy gửi ngay lập tức hoặc triển khai các durable nonce cho các luồng có sự chậm trễ không thể tránh khỏi. Xem tài liệu về durable nonce của Solana cho mô hình đó.
5. Yêu cầu ví của người dùng ký các chỉ dẫn giao dịch. Bên tài trợ trả phí mạng lưới, nhưng các chỉ dẫn vẫn có thể di chuyển tài sản của người dùng hoặc tạo ra các thay đổi trạng thái khác.
6. Gửi giao dịch đã được tuần tự hóa, ký một phần đến điểm cuối của máy chủ relayer.
7. Relayer xác thực nội dung giao dịch, thêm chữ ký cặp khóa của bên tài trợ và gửi giao dịch đã ký đầy đủ qua RPC.

Các API SDK và loại giao dịch chính xác thay đổi theo thời gian. Việc triển khai nên xây dựng các chỉ dẫn dự định, thiết lập bên tài trợ làm bên thanh toán phí, lấy blockhash hiện tại hoặc nonce được hỗ trợ, thu thập các chữ ký bắt buộc mà không thay đổi nội dung đã ký, xác thực giao dịch đã tuần tự hóa trên relayer và gửi nó thông qua nhà cung cấp RPC đã được phê duyệt. Xác minh mọi bước so với tài liệu SDK và giao thức hiện tại.

Cặp khóa (keypair) của nhà tài trợ phải được lưu giữ ở phía máy chủ mọi lúc. Việc để lộ nó ở phía máy khách cho phép bất kỳ người dùng nào rút sạch Số dư SOL của nhà tài trợ. Để phân tích rủi ro đầy đủ, hãy xem phần thảo luận bảo mật chi tiết.

Để biết đặc tả trường chính thức, hãy xem tài liệu về người trả phí của Solana.

Phương pháp 2: Sử dụng Dịch vụ Relayer được Quản lý

Các dịch vụ relayer được quản lý thay mặt nhà phát triển xử lý cơ sở hạ tầng của người trả phí, cho phép tích hợp tài trợ phí thông qua một lệnh gọi API mà không cần xây dựng hoặc duy trì một máy chủ relayer.

Các sản phẩm từ nhà cung cấp được quản lý có thể bao gồm các tính năng giao dịch được tài trợ hoặc relayer. Helius, QuickNode và Alchemy là những ví dụ được nêu trong nguồn; sự hỗ trợ hiện tại của Solana và các điều khoản sản phẩm phải được kiểm tra trực tiếp. Một mô hình tích hợp điển hình là:

1. Nhận thông tin xác thực từ nhà cung cấp đã chọn bằng quy trình quản lý bí mật đã được phê duyệt.
2. Xây dựng giao dịch ở phía máy khách, thêm các hướng dẫn và đặt transaction.feePayer thành Public Key được chỉ định của nhà cung cấp.
3. Để ví người dùng ký một phần giao dịch.
4. Tuần tự hóa và gửi giao dịch đến điểm cuối không tốn phí gas (gasless) của nhà cung cấp thông qua HTTP POST.
5. Nhà cung cấp xác thực, đồng ký tên với tư cách là người trả phí và gửi giao dịch lên mạng lưới Solana.

Một dịch vụ được quản lý có thể giảm bớt công việc vận hành trực tiếp, nhưng nó dẫn đến sự phụ thuộc vào nhà cung cấp, thông tin xác thực, tính khả dụng, chính sách, quyền riêng tư và giá cả. Trách nhiệm lưu ký khóa phụ thuộc vào kiến trúc và hợp đồng của nhà cung cấp. Tài liệu của nhà cung cấp là điểm khởi đầu, không phải là sự thay thế cho việc đánh giá bảo mật.

Sự đánh đổi ở đây là sự phụ thuộc vào nhà cung cấp. Nếu dịch vụ được quản lý gặp sự cố gián đoạn, các giao dịch được tài trợ sẽ thất bại. Người dùng không thể quay lại tự trả phí cho mình nếu không có logic frontend bổ sung để phát hiện tính khả dụng của relayer và thay vào đó xây dựng một giao dịch tiêu chuẩn. Hãy đánh giá điều này so với mức độ chấp nhận rủi ro về tính khả dụng của Bên thứ ba đối với sản phẩm của bạn. Khung làm việc xây dựng-so-với-mua trong phần phương pháp tiếp cận phù hợp đề cập đầy đủ đến quyết định này.

QuickNode và Alchemy đều cung cấp cơ sở hạ tầng Solana với tính năng tài trợ phí hoặc các tính năng liên quan đến relayer. Hãy xác minh tính khả dụng của tính năng hiện tại trong tài liệu của từng nhà cung cấp, vì các dịch vụ được quản lý luôn phát triển.

Phương pháp 3: Xây dựng một Transaction Relayer Tùy chỉnh

Một transaction relayer tùy chỉnh sẽ phù hợp khi ứng dụng yêu cầu logic về điều kiện tài trợ tùy chỉnh, hoạt động ở quy mô lớn với các yêu cầu nghiêm ngặt về lưu trú dữ liệu hoặc cần toàn quyền kiểm soát đối với cặp khóa của người trả phí.

Kiến trúc của một relayer tùy chỉnh có năm thành phần:

1. Điểm cuối API: chấp nhận các giao dịch được tuần tự hóa đã ký một phần từ frontend của dApp thông qua HTTP.
2. Lớp xác thực: giải tuần tự hóa giao dịch và kiểm tra ID chương trình, dữ liệu hướng dẫn và danh sách tài khoản so với một danh sách cho phép (allowlist). Đây là thành phần nhạy cảm nhất về bảo mật. Relayer ký bất cứ thứ gì nó nhận được; do đó nó phải xác minh những gì nó nhận được trước khi ký.
3. Ký phí người trả: sử dụng một cặp khóa được lưu trữ trong biến môi trường hoặc trình quản lý bí mật. Không bao giờ lưu trữ cặp khóa trong mã nguồn hoặc commit nó vào kho lưu trữ mã (repository).
4. Gửi RPC: gửi giao dịch đã ký đầy đủ lên Solana thông qua RPC, với logic thử lại cho các lỗi xác nhận và xử lý các phản hồi giới hạn tốc độ.
5. Theo dõi Số dư: ví nhà tài trợ phải duy trì đủ SOL cho khối lượng giao dịch dự kiến. Triển khai các cảnh báo tự động và cơ chế nạp tiền (Top-up) để ngăn chặn tình trạng relayer ngừng hoạt động do cạn kiệt Số dư.

Đối với môi trường kỹ thuật chỉ sử dụng Python, chỉ sử dụng một máy khách Python Solana được bảo trì sau khi xác nhận rằng nó hỗ trợ định dạng giao dịch và quy trình ký được yêu cầu. Một relayer tùy chỉnh vẫn yêu cầu giám sát, xử lý giới hạn tốc độ, hàng đợi thử lại, kiểm soát Số dư, kiểm thử và phản ứng sự cố.

Các trường hợp sử dụng thực tế: Nơi các giao dịch không tốn phí gas (Gasless) đã được triển khai trên Solana

Các giao dịch không tốn phí gas đang được triển khai thực tế trên một vài danh mục dApp (ứng dụng phi tập trung) của Solana, mỗi danh mục đều có lý do kinh doanh rõ ràng cho việc hấp thụ chi phí phí giao dịch của người dùng.

Nền tảng đúc NFT là một trường hợp sử dụng không tốn phí gas. Khi một nền tảng tài trợ phí mạng lưới, một ví tương thích có thể ký giao dịch đúc mà không cần trả phí đó bằng SOL. Một lượt đúc không tốn phí gas vẫn có thể bao gồm giá đúc, chính sách phí ưu tiên, phí nền tảng, tiền bản quyền hoặc chi phí liên quan đến tài khoản sau này, vì vậy người dùng nên kiểm tra toàn bộ giao dịch và giá cả.

Các giao thức DeFi đối mặt với vấn đề cấu trúc về việc tiếp nhận người dùng mới mà việc tài trợ phí có thể giải quyết trực tiếp. Những người dùng đến với USDC hoặc một token không phải SOL khác không thể bắt đầu bất kỳ giao dịch hoán đổi, Stake hoặc Nạp tiền nào mà không có SOL trước để trả phí giao dịch. Điều này tạo ra một sự phụ thuộc vòng quanh: bạn cần SOL để tương tác với một giao thức có thể cung cấp SOL cho bạn, nhưng bạn không thể tương tác nếu không có SOL trước. Tài trợ cho một đến ba giao dịch đầu tiên cho người dùng mới sẽ loại bỏ rào cản này. Các sàn DEX, luồng chuyển đến từ cầu nối chuỗi chéo (cross-chain bridge) và các nền tảng cho vay đều áp dụng mô hình này. Sau giai đoạn tài trợ, những người dùng đã nhận được SOL thông qua hoán đổi có thể tự trả phí cho các giao dịch tiếp theo của họ.

Gaming Web3 tạo ra tần suất giao dịch cao, khiến việc tài trợ phí trở nên hấp dẫn về mặt kinh tế đối với các studio. Mọi hành động trong trò chơi có chạm đến chuỗi (mua vật phẩm, đúc thành tích, cập nhật bảng xếp hạng) sẽ hiển thị thông báo ví và khấu trừ phí nếu không có tài trợ. Với Phí cơ sở của Solana, việc tài trợ cho 1.000 giao dịch trong trò chơi tốn khoảng 0,005 SOL. Một studio trò chơi hấp thụ chi phí này như một chi phí vận hành, tương tự như cơ sở hạ tầng máy chủ, và kết quả là trải nghiệm người chơi hoạt động giống như một trò chơi Web2 tiêu chuẩn hơn là một ứng dụng Blockchain.

Tiếp nhận người dùng cho dApp tiêu dùng mở rộng mô hình này cho bất kỳ ứng dụng nào. Một dApp trên Solana có thể tài trợ cho N giao dịch đầu tiên của người dùng để hạ thấp rào cản đối với hành động Trên chuỗi đầu tiên, sau đó chuyển người dùng sang tự trả phí sau khi họ đã có SOL. Solana Pay (giao thức thanh toán mở của Solana) cung cấp một mô hình liên quan cho các bối cảnh của người bán: người bán có thể đóng vai trò là người trả phí, cho phép khách hàng thực hiện thanh toán mà không cần giữ SOL để trả phí.

Tôi có cần SOL để sử dụng các ứng dụng này không? Không, miễn là Nền tảng đang tích cực tài trợ phí giao dịch. Không tốn phí gas (gasless) là một quyết định về sản phẩm của mỗi dApp, không phải là một sự đảm bảo của mạng lưới. Luôn kiểm tra chính sách phí hiện tại của nền tảng trước khi giả định rằng phí được tài trợ. Các chương trình tài trợ có thể bị giới hạn thời gian, giới hạn khối lượng hoặc chỉ giới hạn cho các hành động cụ thể.

Hành vi không tốn phí gas chủ yếu là một tính năng của dApp và relayer, nhưng khả năng tương thích của ví và hỗ trợ định dạng giao dịch vẫn yêu cầu kiểm thử. Phantom, Solflare và Backpack là các ví dụ từ nguồn, không phải là sự chứng thực. Người dùng ký các hướng dẫn giao dịch, trong khi nhà tài trợ ủy quyền thanh toán phí.

Chi phí tài trợ giao dịch: Nhà phát triển thực sự phải trả bao nhiêu cho Gasless?

Nguồn mô hình hóa Phí cơ sở 5.000 lamport cho mỗi chữ ký bằng cách sử dụng tài liệu về phí giao dịch của Solana. Hãy coi đây là một thông tin đầu vào để xác minh, không phải là một báo giá vĩnh viễn. Tổng chi phí tài trợ cũng phụ thuộc vào số lượng chữ ký, phí ưu tiên, số lần thử lại, việc tạo tài khoản, phí nhà cung cấp, cơ sở hạ tầng và giá của SOL.

Các ước tính chi phí bên dưới mang tính minh họa và dựa trên dữ liệu phí được công bố công khai. Nội dung này không cấu thành lời khuyên tài chính. Giá SOL biến động; chi phí USD thực tế sẽ thay đổi.

Một SOL tương đương với 1.000.000.000 lamport. Phí cơ sở 5.000 lamport cho mỗi chữ ký là mức tối thiểu của mạng lưới. Phí ưu tiên là tùy chọn và do nhà tài trợ kiểm soát.

Phí ưu tiên là một chỉ lệnh computeUnitPrice tùy chọn giúp chuyển giao dịch lên đầu hàng đợi trong thời gian mạng lưới bị tải nặng. Việc thêm phí ưu tiên làm tăng chi phí cho mỗi giao dịch và gây ra sự biến động. Hãy lập ngân sách với một khoản dự phòng nếu ứng dụng của bạn tài trợ các giao dịch trong thời kỳ tắc nghẽn.

Chi phí dịch vụ quản lý thêm một lớp phí bên trên phí mạng lưới Solana. Khi sử dụng Helius hoặc một trình chuyển tiếp (relayer) được quản lý khác, nhà phát triển phải trả cả Phí cơ sở Solana và phí đăng ký API của nhà cung cấp hoặc phí dịch vụ trên mỗi giao dịch. Tham khảo tài liệu giá hiện tại của từng nhà cung cấp để biết chi tiết.

Bảng này là một minh họa sử dụng phí cơ sở và giá SOL giả định của nguồn. Chi phí thực tế phụ thuộc vào chữ ký, phí ưu tiên, các giao dịch thất bại hoặc được thử lại, việc tạo tài khoản, giá của nhà cung cấp, cơ sở hạ tầng và Giá token. Các nhóm nên đánh giá khối lượng công việc của riêng họ thay vì suy diễn một chi phí đảm bảo từ bảng này.

Để lựa chọn giữa các dịch vụ được quản lý và các trình chuyển tiếp tùy chỉnh dựa trên chi phí và các yếu tố vận hành, hãy xem phần phương pháp tiếp cận phù hợp.

Cân nhắc về bảo mật: Những điều nhà phát triển cần biết về rủi ro của trình chuyển tiếp

Việc triển khai các giao dịch không tốn phí gas đặt ra các trách nhiệm bảo mật cho các nhà phát triển, nhà vận hành cơ sở hạ tầng và người dùng. Chữ ký của người dùng ủy quyền cho các chỉ lệnh giao dịch do ví đưa ra; việc tài trợ phí không làm cho các chỉ lệnh có hại hoặc gây hiểu lầm trở nên an toàn.

An toàn cho người dùng: một quy trình tài trợ phí hợp pháp không được yêu cầu chia sẻ Private Key, nhưng người dùng vẫn cần xác minh tên miền, lời nhắc của ví, ID chương trình, phê duyệt token, tài khoản và số tiền. Một dApp độc hại có thể yêu cầu người dùng ký các chỉ lệnh có hại ngay cả khi một tài khoản khác trả phí mạng lưới.

Các rủi ro dưới đây ảnh hưởng đến các nhà phát triển và nhà vận hành, trong khi các rủi ro về ký giao dịch, lừa đảo (phishing), ví và ủy quyền tài sản cũng ảnh hưởng đến người dùng cuối.

Rủi ro 1: Thao túng nội dung giao dịch. Một máy khách độc hại có thể tạo ra một giao dịch chứa các chỉ lệnh có hại và gửi nó đến trình chuyển tiếp, hy vọng trình chuyển tiếp sẽ ký mà không kiểm tra nội dung. Giảm thiểu: trình chuyển tiếp phải giải tuần tự (deserialize) và xác thực giao dịch trước khi ký. Kiểm tra ID chương trình, dữ liệu chỉ lệnh và danh sách tài khoản đối với một danh sách cho phép gồm các giá trị mong đợi. Chỉ ký các giao dịch khớp với cấu trúc mong đợi cho ứng dụng của bạn.

Rủi ro 2: Tấn công phát lại (Replay attacks). Cơ chế recentBlockhash của Solana ngăn chặn các cuộc tấn công phát lại một cách tự nhiên. Một blockhash sẽ hết hạn sau khoảng 150 slot (tầm 60 đến 90 giây) và bất kỳ giao dịch nào được gửi sau khi blockhash hết hạn sẽ bị mạng lưới từ chối. Các trình chuyển tiếp không nên ký lại các giao dịch có blockhash đã hết hạn. Đối với các quy trình mà sự chậm trễ khi gửi là không thể tránh khỏi, hãy triển khai các nonce bền vững bằng tính năng nonceAccount của Solana; xem tài liệu nonce bền vững của Solana.

Rủi ro 3: Từ chối dịch vụ trình chuyển tiếp. Nếu một trình chuyển tiếp do Bên thứ ba quản lý gặp sự cố ngừng hoạt động, người dùng không thể gửi các giao dịch được tài trợ ngay cả khi họ sẵn lòng tự trả phí. Giảm thiểu: triển khai một đường dẫn dự phòng ở frontend để xây dựng một giao dịch tiêu chuẩn (người dùng trả phí) khi điểm cuối của trình chuyển tiếp không khả dụng. Điều này giúp bảo toàn chức năng trong thời gian xảy ra sự cố.

Rủi ro 4: Rút cạn ví tài trợ. Nếu không có giới hạn tốc độ (rate limiting), kẻ tấn công có thể tạo ra khối lượng lớn các giao dịch có vẻ hợp lệ để rút cạn Số dư SOL của bên tài trợ. Giảm thiểu: thực thi giới hạn tốc độ trên mỗi địa chỉ ví, mỗi địa chỉ IP và mỗi khoảng thời gian. Thiết lập hạn mức chi tiêu hàng ngày. Triển khai một bộ ngắt mạch tự động tạm dừng tài trợ khi khối lượng vượt quá ngưỡng. Theo dõi số dư ví tài trợ bằng các cảnh báo tự động và các trình kích hoạt Top-up.

Rủi ro 5: Chạy trước (Front-running) và MEV. Trình chuyển tiếp phát sóng giao dịch và có khả năng hiển thị nội dung của nó trước khi xác nhận Trên chuỗi. Đối với các ứng dụng DeFi liên quan đến hoán đổi hoặc Chênh lệch giá, một trình chuyển tiếp thù địch có thể chạy trước giao dịch đó. Giảm thiểu: sử dụng trình chuyển tiếp tự vận hành cho các ứng dụng DeFi xử lý các giao dịch tài chính nhạy cảm. Đánh giá uy tín và tính minh bạch vận hành của bất kỳ nhà cung cấp Bên thứ ba nào trước khi tích hợp vào sản phẩm DeFi.

Về bối cảnh quy định: ở một số khu vực pháp lý nhất định, việc tài trợ các giao dịch của người dùng có thể có tác động đến vị thế pháp lý của dApp, đặc biệt nếu các khoản phí được tài trợ được coi là chuyển giao giá trị. Đây không phải là lời khuyên pháp lý; hãy tham vấn luật sư để được phân tích cụ thể theo từng khu vực pháp lý.

Lớp xác thực trong hướng dẫn triển khai mô tả nơi các biện pháp giảm thiểu này được áp dụng trong kiến trúc trình chuyển tiếp.

Danh sách kiểm tra bảo mật cho việc triển khai trình chuyển tiếp

• Xác thực và giải tuần tự nội dung giao dịch trước khi ký
• Không bao giờ ký lại các giao dịch có blockhash đã hết hạn
• Triển khai phương án dự phòng người dùng tự trả phí khi trình chuyển tiếp ngừng hoạt động
• Thực thi giới hạn tốc độ trên mỗi ví, mỗi IP và mỗi khoảng thời gian với hạn mức chi tiêu hàng ngày
• Sử dụng trình chuyển tiếp tự vận hành hoặc đáng tin cậy cho các ứng dụng DeFi xử lý các giao dịch nhạy cảm

Chọn phương pháp tiếp cận phù hợp: Triển khai gốc so với Dịch vụ quản lý

Việc lựa chọn giữa triển khai feePayer gốc, dịch vụ trình chuyển tiếp được quản lý và trình chuyển tiếp tự xây dựng phụ thuộc vào bốn yếu tố: thời gian phát triển, khối lượng giao dịch, yêu cầu bảo mật và ngân sách cho chi phí vận hành liên tục.

Không có ngưỡng khối lượng giao dịch phổ quát để chọn dịch vụ quản lý. Hãy so sánh việc lưu ký khóa, kiểm soát xác thực, tính khả dụng, quyền riêng tư, tuân thủ, lưu trú dữ liệu, giá cả, khả năng di động và ứng phó sự cố trước khi chọn một phương pháp tiếp cận.

Hãy xây dựng một trình chuyển tiếp tùy chỉnh khi ứng dụng của bạn yêu cầu logic điều kiện tùy chỉnh (ví dụ: chỉ tài trợ cho năm giao dịch đầu tiên của mỗi người dùng hoặc hạn chế tài trợ cho các loại chỉ lệnh cụ thể), khi khối lượng giao dịch và yêu cầu bảo mật xứng đáng với khoản đầu tư vận hành, hoặc khi các yêu cầu về lưu trú dữ liệu ngăn cản việc sử dụng nhà cung cấp Bên thứ ba.

Cách tiếp cận feePayer gốc mà không có máy chủ trình chuyển tiếp riêng biệt phù hợp với các ứng dụng đơn giản có backend đáng tin cậy và khối lượng giao dịch thấp, có thể dự đoán được.

Các nhóm sử dụng dịch vụ quản lý nên duy trì khả năng di chuyển sang trình chuyển tiếp tự vận hành nếu nhà cung cấp thay đổi giá cả hoặc ngừng dịch vụ. Hãy lập tài liệu các điểm tích hợp để việc di chuyển chỉ là một thay đổi về cấu hình chứ không phải là viết lại từ đầu.

Để biết mô hình chi phí của từng tùy chọn, hãy xem phần phân tích chi phí.

Các câu hỏi thường gặp về giao dịch không tốn phí gas trên Solana

Giao dịch không tốn phí gas trong Tiền điện tử là gì?

Các giao dịch gasless trong Tiền điện tử là các giao dịch Blockchain mà người dùng cuối không phải trả phí mạng. Một bên thứ ba, chẳng hạn như nhà phát triển dApp, giao thức hoặc dịch vụ relayer, sẽ đài thọ phí thay cho người dùng. Thuật ngữ này bắt nguồn từ hệ sinh thái Ethereum, nơi phí giao dịch được gọi là "gas", và kể từ đó đã lan sang các chuỗi bao gồm cả Solana như một thuật ngữ chung cho các trải nghiệm người dùng được tài trợ phí.

Solana có tính phí gas không?

Solana sử dụng phí giao dịch thay vì thuật ngữ "gas". Nguồn tin trích dẫn Phí cơ sở là 5.000 lamport cho mỗi chữ ký, nhưng các tham số hiện tại nên được xác minh và tổng chi phí có thể bao gồm nhiều chữ ký và phí ưu tiên tùy chọn. Gasless có nghĩa là một tài khoản khác trả phí mạng hiện hành.

Tài khoản trả phí (fee payer) hoạt động như thế nào trên Solana?

Tài khoản trả phí trên Solana là tài khoản được chỉ định để trả phí giao dịch. Mỗi giao dịch đều có một trường feePayer trong đối tượng giao dịch. Trong một giao dịch tiêu chuẩn, người trả phí và người ký giao dịch là cùng một tài khoản. Trong một giao dịch gasless, họ là các tài khoản khác nhau: ví của người dùng ký để ủy quyền hướng dẫn, và một tài khoản trả phí riêng biệt (do dApp kiểm soát) ký để ủy quyền và trả phí. Chỉ có Số dư SOL của người trả phí bị trừ.

Ai trả tiền cho các giao dịch gasless trên Solana?

Nhà phát triển dApp, kho bạc giao thức hoặc dịch vụ chuyển tiếp (relayer) được quản lý sẽ trả tiền cho các giao dịch gasless trên Solana. Các thực thể này nạp SOL vào một tài khoản trả phí và vận hành một relayer để cùng ký các giao dịch thay mặt cho người dùng. Từ góc độ kinh doanh, đây là hoạt động tài trợ giao dịch: dApp coi phí này là chi phí thu hút người dùng. Hãy xem bảng ai trả phí trong phần quan niệm sai lầm để biết chi tiết.

Không có giao dịch nào trên Solana có thể xảy ra mà không có phí được trả cho các validator. Phí là một yêu cầu của giao thức. Điều có thể xảy ra là một bên khác không phải người gửi sẽ trả phí. Một giao dịch gasless vẫn có phí; chỉ đơn giản là người dùng không phải là người trả phí đó. Phép so sánh: một nhà hàng có thể miễn phí bữa ăn cho bạn, nhưng thực phẩm vẫn có chi phí.

Tài trợ phí giao dịch là gì?

Tài trợ phí giao dịch là việc nhà phát triển dApp, giao thức hoặc dịch vụ đài thọ phí giao dịch mạng thay cho người dùng cuối, cho phép người dùng tương tác với Solana mà không cần giữ SOL để thanh toán phí. Đây là cơ chế giúp trải nghiệm người dùng gasless trở nên khả thi. Từ góc độ sản phẩm, tài trợ phí thường được coi là chi phí thu hút người dùng, tương tự như một sản phẩm freemium hoặc miễn phí phí gia nhập.

Làm cách nào để xây dựng một dApp gasless trên Solana?

Để xây dựng một dApp gasless trên Solana: (1) tạo một cặp khóa (keypair) cho người trả phí được lưu trữ ở phía máy chủ, được nạp sẵn SOL; (2) cấu trúc các giao dịch với transaction.feePayer được đặt thành Public Key của người trả phí; (3) yêu cầu người dùng ký giao dịch thông qua ví của họ; (4) gửi giao dịch đã ký một phần đến máy chủ relayer của bạn; (5) yêu cầu relayer xác thực nội dung giao dịch, thêm chữ ký của người trả phí và gửi lên mạng. Xem hướng dẫn triển khai để biết chi tiết kỹ thuật đầy đủ về cả ba phương pháp triển khai.

Sự khác biệt giữa phí Solana và gas Ethereum là gì?

Ethereum và Solana sử dụng các cấu trúc phí và tài trợ khác nhau. Solana hiển thị một trường người trả phí gốc và cũng có thể sử dụng phí ưu tiên; Ethereum hỗ trợ các thiết kế trừu tượng hóa tài khoản (account-abstraction) và giao dịch meta (meta-transaction) với các thành phần khác nhau. Hãy so sánh khối lượng công việc tương đương, chính sách xác nhận, chi phí nhà cung cấp và các kiểm soát bảo mật thay vì dựa vào một con số phí cố định duy nhất.

Tôi có thể đúc một NFT trên Solana miễn phí không?

Có, nhiều nền tảng NFT trên Solana tài trợ phí giao dịch đúc tiền, nghĩa là người dùng không phải trả phí mạng. Tuy nhiên, "đúc miễn phí" (free mint) và "đúc gasless" (gasless mint) không giống hệt nhau. Một đợt đúc miễn phí có nghĩa là không có phí giao dịch và không có giá đúc. Một đợt đúc gasless có nghĩa là phí giao dịch được tài trợ, nhưng giá đúc vẫn có thể được áp dụng. Nhãn gasless đề cập cụ thể đến việc tài trợ phí mạng, chứ không phải việc bản thân NFT đó có giá mua hay không.

Những ví nào hỗ trợ giao dịch gasless trên Solana?

Hành vi gasless chủ yếu được thực hiện bởi dApp và relayer, nhưng khả năng tương thích của ví và hỗ trợ định dạng giao dịch vẫn cần được kiểm tra. Nhà tài trợ có thể đài thọ phí mạng ngay cả khi các hướng dẫn đã ký có thể di chuyển tài sản của người dùng hoặc tạo ra các chi phí khác.

Các giao dịch gasless trên Solana có an toàn không?

Chúng có thể được triển khai một cách an toàn, nhưng việc tài trợ không phải là một sự đảm bảo an toàn. Người dùng phải xác minh dApp và các hướng dẫn đã ký, trong khi các nhà phát triển phải xác thực giao dịch, bảo vệ các khóa của nhà tài trợ, hạn chế lạm dụng, giám sát relayer và cung cấp xử lý lỗi. Một dịch vụ hợp pháp không bao giờ được yêu cầu Private Key của người dùng.

Nếu một dịch vụ relayer được quản lý bị ngừng hoạt động, các giao dịch được tài trợ sẽ không thể được gửi đi cho đến khi dịch vụ phục hồi. Những người dùng sẵn sàng tự trả phí cũng không thể làm điều đó trừ khi dApp đã triển khai một lộ trình dự phòng. Một dApp gasless được xây dựng tốt sẽ phát hiện tính khả dụng của relayer và quay lại cấu trúc giao dịch tiêu chuẩn nơi người dùng trả phí khi relayer không khả dụng. Đây là một trong những rủi ro vận hành chính khi sử dụng dịch vụ relayer được quản lý thay vì dịch vụ tự vận hành.

Hướng dẫn liên quan về Kinh tế mạng Solana

• cách Solana tạo doanh thu
• sự tăng trưởng thị trường Stablecoin trên Solana

Khám phá SOL trên Bybit

Độc giả có thể xem thông tin thị trường SOL hiện tại hoặc thị trường Giao ngay SOL/USDT.. Tính khả dụng không xác thực một giao thức, Stablecoin, relayer, chương trình mua lại hoặc luận điểm đầu tư nào.

Tóm tắt: Những điều bạn cần biết về Giao dịch gasless trên Solana

Các giao dịch gasless trên Solana mang lại cho người dùng cuối trải nghiệm miễn phí bằng cách chuyển việc thanh toán phí sang một tài khoản trả phí được chỉ định, một trường dữ liệu quan trọng trong mô hình giao dịch gốc của Solana.

Các điểm chính:

• Trường feePayer được tích hợp vào cấu trúc giao dịch cơ sở của Solana. Không yêu cầu các chương trình hoặc hợp đồng bổ sung để tài trợ phí.
• Phí luôn tồn tại và luôn chuyển đến các validator. Gasless có nghĩa là người dùng không phải là người trả phí, chứ không phải là không có phí tồn tại.
• Ba lộ trình triển khai được thảo luận: luồng người trả phí gốc bằng SDK đã được phê duyệt, dịch vụ relayer được quản lý và relayer tự xây dựng. Mỗi lộ trình đều có những đánh đổi khác nhau về bảo mật, tính khả dụng, chi phí và quyền kiểm soát.
• Trách nhiệm bảo mật được chia sẻ: người dùng xem xét những gì họ ký, trong khi nhà phát triển xác thực nội dung giao dịch, bảo vệ khóa nhà tài trợ, hạn chế lạm dụng và giám sát tính khả dụng của relayer.
• Minh họa phí cơ sở của nguồn tin cho thấy việc tài trợ có thể không tốn kém, nhưng kinh tế sản xuất đòi hỏi phải kiểm tra các loại phí hiện tại, cài đặt ưu tiên, tỷ lệ thất bại, phí nhà cung cấp và khối lượng công việc tương đương.

Các bước tiếp theo theo đối tượng:

Đối với người dùng: Hãy tìm xác nhận rõ ràng rằng dApp đang tài trợ phí trước khi giả định rằng Số dư SOL của bạn sẽ không bị ảnh hưởng. Bạn có thể tham gia mà không cần mua SOL trước khi hoạt động tài trợ đang diễn ra, nhưng hãy luôn xác minh chính sách hiện tại của từng nền tảng.

Đối với nhà phát triển: So sánh mô hình người trả phí gốc, nhiều nhà cung cấp được quản lý và relayer tự vận hành. Xác minh tài liệu hiện tại, các giả định bảo mật, điều khoản dịch vụ và chi phí trước khi chọn phương án triển khai.

Đối với các nhà chiến lược sản phẩm: Mô hình hóa chi phí tài trợ của bạn bằng công thức trong phần phân tích chi phí và đánh giá các phương pháp triển khai bằng bảng quyết định trong phần phương pháp tiếp cận đúng đắn.

Khi các dApp hướng tới người tiêu dùng trên Solana trưởng thành, việc tài trợ phí đang trở thành một mô hình làm quen (onboarding) tiêu chuẩn. Kiến trúc để hỗ trợ nó đã là một phần của giao thức Solana ngay từ ngày đầu.