Транзакції без газу на Solana: Повний посібник

Транзакції без газу на Solana дозволяють спонсору сплачувати мережеву комісію за користувача. Вони не скасовують комісію, не роблять кожну транзакцію безкоштовною та не гарантують, що підписання спонсорованої транзакції не зможе перемістити активи користувача.

Останнє оновлення: січень 2025 р.

Транзакції без газу на Solana — це блокчейн-транзакції, де кінцевий користувач не сплачує мережеву комісію, оскільки призначена стороння сторона, звана спонсором комісії, покриває витрати від його імені. Слово «безгазовий» (gasless) запозичено з термінології комісій Ethereum, де комісії називаються «газом». Сама Solana використовує термін «комісії за транзакції», а не газ. Але розмовно «безгазовий» став означати те саме у різних мережах: користувач нічого не платить, а хтось інший оплачує рахунок.

Solana не є безгазовою за замовчуванням. Кожна транзакція в мережі потребує комісії, що сплачується в SOL. Багато dApps (децентралізованих застосунків) спонсорують ці комісії від вашого імені, дозволяючи вам почати роботу без наявності SOL. Чи потрібен вам SOL, залежить від конкретного dApp: dApps з підтримкою транзакцій без газу покривають комісію за вас, тоді як інші вимагають, щоб ви сплачували її самі. Цей посібник охоплює архітектуру платника комісії, хто платить і чому, реальні випадки використання, шляхи впровадження, аналіз витрат і питання безпеки.

Зміст

1. Основна концепція: як працює архітектура платника комісії Solana
2. Транзакції без газу проти безкоштовних: роз'яснення найпоширенішої помилки
3. Solana проти Ethereum: чим транзакції без газу відрізняються від абстракції акаунта
4. Як впровадити транзакції без газу на Solana
5. Реальні сценарії використання: де транзакції без газу вже розгорнуті на Solana
6. Вартість спонсорування транзакцій: скільки насправді коштують транзакції без газу розробникам?
7. Питання безпеки: що розробникам потрібно знати про ризики релеєрів
8. Вибір правильного підходу: власна реалізація проти керованого сервісу
9. Поширені запитання про транзакції без газу на Solana
10. Підсумок: що вам потрібно знати про транзакції без газу на Solana

Основна концепція: як працює архітектура платника комісії Solana

Кожна транзакція в Solana містить поле feePayer, яке вказує, з якого балансу SOL акаунта списується мережева комісія, і цей акаунт не обов'язково має належати особі, яка ініціює транзакцію.

Модель комісій за транзакції Solana

Solana стягує базову комісію за підпис, а також може стягувати комісії за пріоритет. Параметр базової комісії та її суму в SOL слід звіряти з поточною документацією; загальна вартість транзакції може варіюватися залежно від підписів, налаштувань обчислень, комісій за пріоритет та стану мережі. Валідатори, вузли мережі, які обробляють і перевіряють транзакції, збирають ці комісії як винагороду за свою обчислювальну роботу. Proof of History — це часовий компонент, що використовується разом із Proof of Stake та Tower BFT. Часто цитований показник у 65 000 TPS є скоріше теоретичним тестом, ніж гарантованою пропускною здатністю застосунків.

Для отримання повної структури комісій див. документацію щодо комісій за транзакції Solana.

Що таке платник комісії на Solana?

Платник комісії на Solana — це акаунт, призначений для оплати комісії за транзакцію. У стандартній транзакції платник комісії та той, хто підписує транзакцію, — це один і той самий акаунт (гаманець користувача). У транзакції без газу це навмисно різні акаунти. Обидва акаунти повинні підписати транзакцію, але тільки з балансу SOL платника комісії списується мережева комісія.

Цей поділ вбудовано в базову структуру транзакцій Solana через поле feePayer. Це не обхідний шлях, не окрема ончейн-програма і не додаток прикладного рівня. Будь-яка транзакція Solana може призначити іншого платника комісії, встановивши це поле. Технічні характеристики див. у документації Solana щодо платника комісії.

Як транзакція без газу проходить через мережу, крок за кроком:

1. Користувач ініціює дію в dApp (мінтинг NFT, обмін токенів або будь-яка інша ончейн-дія).
2. dApp створює об'єкт транзакції та встановлює в полі feePayer окремий акаунт спонсора, а не гаманець користувача.
3. Користувач підписує транзакцію за допомогою свого гаманця, санкціонуючи інструкцію (дію). Підпис не призводить до списання коштів з його балансу.
4. Частково підписана транзакція надсилається на сервер-релеєр, який зберігає пару ключів спонсора.
5. Релеєр перевіряє вміст транзакції, щоб підтвердити відповідність очікуваній програмі та даним інструкції.
6. Релеєр додає підпис платника комісії, використовуючи пару ключів спонсора.
7. Релеєр відправляє повністю підписану транзакцію в мережу Solana, яка списує комісію з балансу платника комісії, а не користувача.

Уявіть це як рахунок у ресторані. Користувач робить замовлення (підписує інструкцію), але застосунок оплачує рахунок (сплачує комісію).

Що таке релеєр транзакцій?

Релеєр транзакцій — це бекенд-сервіс, який забезпечує роботу транзакцій без газу. Релеєр отримує частково підписану транзакцію від користувача (який підписав її для авторизації інструкції, але не сплатив комісію), додає підпис платника комісії та відправляє повністю підписану транзакцію в мережу Solana. Існує дві моделі: власний релеєр, де розробник dApp запускає власний сервер, і керований сервіс релеєра, де інфраструктурою займається сторонній провайдер, наприклад Helius.

У стандартній транзакції ваш гаманець виконує дві функції: авторизує дію та сплачує комісію. У транзакції без газу ваш гаманець виконує лише першу. Коли ви використовуєте dApp з підтримкою транзакцій без газу, ваш гаманець Phantom (або Solflare, Backpack чи будь-який інший гаманець Solana) пропонує вам підписати транзакцію, як зазвичай. Ви схвалюєте її. Підпис авторизує інструкцію: замінтити цей NFT, виконати цей обмін, оновити цей запис. Баланс SOL вашого гаманця не змінюється після цього підтвердження. Комісія сплачується акаунтом платника комісії dApp, який контролюється релеєром. Сумісний гаманець не повинен розкривати свій приватний ключ, а спонсор сплачує мережеву комісію. Проте інструкції, які підписує користувач, все одно можуть дозволяти передачу токенів або інші зміни стану, тому повну транзакцію необхідно перевіряти.

Для повної технічної реалізації кожного підходу до релеєра див. посібник із впровадження.

Ключові терміни

• Платник комісії: Акаунт, з балансу SOL якого покривається комісія за транзакцію. У схемі без газу він контролюється dApp, а не користувачем.
• Релеєр транзакцій: Бекенд-сервіс, який отримує частково підписану транзакцію, додає підпис платника комісії та відправляє її в мережу.
• Спонсор комісії: Організація (розробник dApp, протокол або керований сервіс), яка фінансує акаунт платника комісії та бере на себе витрати на транзакцію.

[DIAGRAM: Тривузловий блок-схема, що показує "Гаманець користувача підписує інструкцію" зі стрілкою "Частково підписана транзакція", що вказує на "Релейщик / Платник комісії підписує + сплачує комісію", зі стрілкою "Повністю підписана транзакція", що вказує на "Мережа Solana підтверджує", і фінальною стрілкою до "Дія завершується в гаманці користувача". Дизайн-команда: вузли зліва направо з позначеними напрямними стрілками.]

Безкоштовні транзакції проти Справді безкоштовних: Роз'яснення найпоширенішої помилки

Безкоштовні транзакції (Gasless) — це скорочення для спонсорованих комісій: мережева комісія існує і завжди сплачується, але кінцевий користувач не є стороною, яка її сплачує.

На Solana існує три сценарії сплати комісії, і лише один з них є справді безкоштовним (gasless):

• Стандартна транзакція: Користувач сплачує комісію зі свого балансу SOL. Комісія становить 0,000005 SOL за підпис.
• Безкоштовна (спонсорована) транзакція: dApp, протокол або керована служба релейщика сплачує комісію від імені користувача. Баланс SOL користувача залишається недоторканим.
• Транзакція з низькою комісією: Користувач сплачує настільки малу комісію, що майже її не помічає. Це не безкоштовно (gasless); користувачеві все одно потрібен SOL.

Спонсорування транзакцій — це термін, спрямований на бізнес, який пояснює, чому безкоштовні транзакції працюють. З точки зору продукту, покриття комісій за транзакції є витратами на залучення користувачів, подібно до пропозиції безкоштовної пробної версії або оплати за покази реклами.

Логічне запитання: якщо я не плачу, в чому підступ? Відповідь прозора. Витрати для спонсора незначні за рівнями комісій Solana. Спонсорування 100 000 транзакцій коштує 0,5 SOL у вигляді базових комісій. Платформа, що виконує безкоштовний карбування NFT, багаторазово відшкодовує ці витрати за рахунок комісій маркетплейсу, доходу від первинних продажів або утримання користувачів. Деякі платформи відшкодовують витрати через передплатні рівні або токеноміку протоколу.

Комісія завжди кудись йде. Вона йде до валідаторів Solana. Питання лише в тому, хто її надсилає.

Повний опис ризиків, пов'язаних зі спонсоруванням комісій, див. у розділі Міркування безпеки.

Solana проти Ethereum: Як безкоштовні транзакції відрізняються від Абстракції облікових записів

Модель комісій Ethereum є джерелом концепції «безкоштовних транзакцій» (gasless), і порівняння нативної архітектури платіжника комісій Solana з абстракцією облікових записів EIP-4337 Ethereum показує, чому два підходи досягають подібного користувацького досвіду за допомогою різних технічних засобів.

Ethereum стягує «газ» за обчислення. Комісії за газ є змінними, керованими ринком і сплачуються в ETH (в одиницях gwei). Під час пікового завантаження мережі комісії за транзакції Ethereum історично досягали 50 доларів США або більше за транзакцію. Ця волатильність є саме тією причиною, чому безкоштовний UX став значущою метою дизайну. Порівнюючи комісії Solana з комісіями Ethereum, розрив у базових комісіях пояснює, чому спонсорування комісій є економічно незначним на Solana і дійсно дорогим на Ethereum. Комісії за газ Ethereum порівняно з комісіями за транзакції Solana представляють різницю в кілька порядків величини типової вартості.

Рішення Ethereum для безкоштовного UX — це EIP-4337, стандарт рівня додатків (не зміна рівня протоколу), який запроваджує спонсорів (paymasters). Спонсори — це смарт-контракти, які спонсорують комісії за газ від імені користувачів. Розгортання спонсора вимагає бандлера UserOperation, контракту EntryPoint та самого контракту спонсора. Це значна інвестиція в інфраструктуру, перш ніж будь-який користувач зможе отримати вигоду. Повну специфікацію див. у специфікації EIP-4337.)

До EIP-4337 Ethereum використовував мета-транзакції (стандартизовані згідно з ERC-2771) як обхідний шлях. Користувач підписував повідомлення, що виражає намір, а релейщик перетворював це повідомлення на повну транзакцію і сплачував комісію за газ. Підхід Solana є архітектурно чистішим, оскільки відокремлення платника комісії є нативною функцією протоколу, а не шаблоном обгортання повідомлень рівня додатків.

Слово «безкоштовні» (gasless), застосоване до Solana, є запозиченою термінологією. Документація Solana використовує термін «комісії за транзакції» (transaction fees), а не «газ». Коліквальне використання терміну «gasless» відображає те, як Ethereum сформував лексикон цього шаблону UX у різних мережах.

Рішення Ethereum Рівня 2 (Layer 2) знизили витрати на газ основної мережі (mainnet), і це зауваження належить до будь-якого порівняння. Таблиця вище відображає історичні діапазони основної мережі Ethereum. Структурна різниця залишається: платник комісій Solana є функцією протоколу, що не вимагає додаткового розгортання контракту, тоді як EIP-4337 є стандартом рівня додатків, що вимагає розгорнутого стеку спонсора.

Як реалізувати безкоштовні транзакції на Solana

Існує три підходи до реалізації спонсорування комісій у додатку Solana. Правильний вибір залежить від обсягу транзакцій, ресурсів розробки, вимог безпеки та толерантності до сторонніх залежностей. Усі три підходи використовують нативне поле feePayer Solana як базовий механізм протоколу.

Підхід 1: Встановлення платника комісій у підтримуваному SDK

Нативний підхід встановлює поле платника комісій у об'єкт транзакції та використовує безпечно керований спонсорський обліковий запис, фінансований SOL. Команди повинні використовувати підтримуваний SDK, який відповідає їх затвердженому інженерному середовищу, та перевіряти поведінку відповідно до поточної специфікації транзакцій Solana.

Передумови: фінансований спонсорський обліковий запис, що зберігається у затвердженій системі керування секретами або підпису, з'єднання RPC, правила валідації транзакцій, моніторинг та підтримувана клієнтська бібліотека.

Кроки:

1. Створіть новий об'єкт Transaction.
2. Додайте відповідну інструкцію (карбування, обмін, переказ або інший виклик програми).
3. Встановіть transaction.feePayer = sponsorKeypair.publicKey, щоб призначити спонсорський обліковий запис.
4. Отримайте recentBlockhash та призначте його транзакції. Blockhash стає недійсним приблизно через 150 слотів (приблизно 60-90 секунд); надсилайте негайно або впроваджуйте стійкі нонси (durable nonces) для потоків із неминучими затримками. Див. документацію Solana щодо стійких нонсів) для цього шаблону.
5. Попросіть гаманець користувача підписати інструкції транзакції. Спонсор сплачує мережеву комісію, але інструкції все одно можуть переміщати активи користувача або створювати інші зміни стану.
6. Надішліть частково підписану, серіалізовану транзакцію до кінцевої точки сервера релейщика.
7. Релейщик валідує вміст транзакції, додає підпис спонсорського ключа та надсилає повністю підписану транзакцію через RPC.

Точні API SDK та типи транзакцій з часом змінюються. Реалізація повинна конструювати передбачені інструкції, встановлювати спонсора як платника комісій, отримувати поточний хеш блоку або підтримуваний нонс, збирати необхідні підписи без зміни підписаного вмісту, валідувати серіалізовану транзакцію на релейщику та надсилати її через затвердженого постачальника RPC. Перевіряйте кожен крок відповідно до поточної документації SDK та протоколу.

Пара ключів спонсора повинна завжди зберігатися на стороні сервера. Розкриття її на стороні клієнта дозволяє будь-якому користувачу вичерпати Баланс SOL спонсора. Для повного аналізу ризиків див. повне обговорення безпеки.

Для отримання офіційної специфікації полів див. документацію Solana щодо платника комісії.

Підхід 2: Використання керованого сервісу-релеєра

Керовані сервіси-релеєри беруть на себе керування інфраструктурою платника комісії від імені розробника, дозволяючи інтегрувати спонсорство комісії через виклик API без створення або обслуговування власного сервера-релеєра.

Пропозиції від керованих провайдерів можуть включати функції спонсорованих транзакцій або релеєрів. Helius, QuickNode та Alchemy — це приклади, згадані в джерелі; поточну підтримку Solana та умови продуктів необхідно перевіряти безпосередньо. Типовий шаблон інтеграції такий:

1. Отримайте облікові дані від обраного провайдера, використовуючи схвалений процес управління секретами.
2. Створіть транзакцію на стороні клієнта, додавши інструкції та встановивши transaction.feePayer як призначений Відкритий ключ провайдера.
3. Нехай гаманець користувача частково підпише транзакцію.
4. Серіалізуйте та надішліть транзакцію на кінцеву точку провайдера для безгазових транзакцій через HTTP POST.
5. Провайдер перевіряє, підписує як співавтор (платник комісії) та надсилає транзакцію в Блокчейн Solana.

Керований сервіс може зменшити обсяг прямої оперативної роботи, але він вносить залежність від постачальника, облікових даних, доступності, політик, конфіденційності та ціноутворення. Обов'язки щодо зберігання ключів залежать від архітектури та контракту провайдера. Документація провайдера є відправною точкою, а не заміною перевірки безпеки.

Компромісом є залежність від постачальника. Якщо у керованого сервісу стається збій, спонсоровані транзакції не проходять. Користувачі не можуть повернутися до самостійної оплати комісій без додаткової логіки інтерфейсу для виявлення доступності релеєра та створення стандартної транзакції замість спонсорованої. Оцініть це з огляду на толерантність вашого продукту до ризику доступності Сторонніх сервісів. Фреймворк «build-vs-buy» у розділі про вибір правильного підходу повністю охоплює це рішення.

QuickNode та Alchemy пропонують інфраструктуру Solana з функціями спонсорства комісій або релеєрів. Перевіряйте поточну наявність функцій у документації кожного провайдера, оскільки пропозиції керованих сервісів розвиваються.

Підхід 3: Створення власного релеєра транзакцій

Власний релеєр транзакцій доцільний, коли програма вимагає індивідуальної логіки надання спонсорства, працює в масштабі з суворими вимогами до резидентності даних або потребує повного контролю над парою ключів платника комісії.

Архітектура власного релеєра складається з п'яти компонентів:

1. API endpoint: приймає частково підписані серіалізовані транзакції від фронтенду dApp через HTTP.
2. Шар валідації: десеріалізує транзакцію та перевіряє ID програм, дані інструкцій та списки акаунтів на відповідність дозволеному списку. Це найбільш критичний для безпеки компонент. Релеєр підписує все, що отримує; тому він повинен перевіряти отримане перед підписанням.
3. Підписання платником комісії: використовує пару ключів, що зберігається в змінній середовища або менеджері секретів. Ніколи не зберігайте пару ключів у вихідному коді та не фіксуйте її в репозиторії.
4. Надсилання через RPC: надсилає повністю підписану транзакцію в Solana через RPC з логікою повторних спроб для випадків невдалого підтвердження та обробкою відповідей про ліміт запитів.
5. Моніторинг балансу: гаманець спонсора повинен підтримувати достатній Баланс SOL для очікуваного обсягу транзакцій. Впровадьте автоматизовані сповіщення та механізми поповнення, щоб запобігти простою релеєра через вичерпаний Баланс.

Для середовища розробки лише на Python використовуйте підтримуваний Python-клієнт Solana тільки після підтвердження того, що він підтримує необхідний формат транзакцій та потік підписання. Власний релеєр все одно потребує моніторингу, обробки лімітів запитів, черг повторних спроб, контролю балансу, тестування та реагування на інциденти.

Реальні приклади використання: де безгазові транзакції вже впроваджені на Solana

Безгазові транзакції працюють у кількох категоріях dApps (децентралізованих застосунків) на Solana, кожна з яких має власне бізнес-обґрунтування для покриття витрат на транзакційні комісії користувачів.

Платформи для мінтингу NFT — це один із варіантів використання безгазових транзакцій. Коли Платформа спонсорує мережеву комісію, сумісний гаманець може підписати транзакцію мінтингу без оплати цієї комісії в SOL. Безгазовий мінт все одно може включати ціну мінту, політику пріоритетної комісії, збір платформи, роялті або подальші витрати, пов'язані з акаунтом, тому користувачі повинні перевіряти повну транзакцію та ціну.

Протоколи DeFi стикаються зі структурною проблемою онбордингу, яку спонсорство комісій вирішує безпосередньо. Користувачі, які приходять із USDC або іншим токеном, відмінним від SOL, не можуть ініціювати обмін, вносити в стейкінг або робити Депозит без попереднього придбання SOL для оплати комісії за транзакцію. Це створює кругову залежність: вам потрібен SOL для взаємодії з протоколом, який міг би дати вам SOL, але ви не можете взаємодіяти, не маючи SOL спочатку. Спонсорування перших однієї-трьох транзакцій для нових користувачів усуває цей бар'єр. DEX, потоки міжмережевих мостів та платформи кредитування застосовують цей патерн. Після спонсорованого періоду користувачі, які отримали SOL через обмін, можуть самостійно оплачувати комісії за наступні транзакції.

Web3-ігри генерують високу частоту транзакцій, що робить спонсорство комісій економічно привабливим для студій. Кожна ігрова дія, яка стосується блокчейну (купівля предмета, мінт досягнення, оновлення таблиці лідерів), без спонсорства викликала б запит гаманця та списання комісії. При Базових комісіях Solana спонсорство 1000 ігрових транзакцій коштує приблизно 0,005 SOL. Ігрова студія бере це на себе як операційні витрати, подібно до витрат на серверну інфраструктуру, і в результаті гравець отримує досвід, який нагадує стандартну гру Web2, а не блокчейн-застосунок.

Онбординг у споживчі dApps поширює цю модель на будь-який застосунок. Solana dApp може спонсорувати перші N транзакцій користувача, щоб знизити бар'єр для першої дії Ончейн, а потім перевести користувачів на самостійну оплату після того, як вони придбають SOL. Solana Pay (відкритий платіжний протокол Solana) пропонує подібну модель для мерчантів: мерчант може виступати як платник комісії, дозволяючи клієнтам ініціювати платежі без наявності SOL для комісій.

Чи потрібен мені SOL для використання цих програм? Ні, доки Платформа активно спонсорує комісії за транзакції. Безгазові транзакції — це продуктове рішення кожного dApp, а не гарантія мережі. Завжди перевіряйте поточну політику комісій платформи, перш ніж припускати, що комісії спонсоруються. Програми спонсорства можуть бути обмежені в часі, мати ліміти за обсягом або поширюватися лише на певні дії.

Безгазова робота — це насамперед функція dApp та релеєра, але сумісність гаманців та підтримка формату транзакцій все одно потребують тестування. Phantom, Solflare та Backpack — це приклади з джерела, а не рекомендації. Користувач підписує інструкції транзакції, тоді як спонсор авторизує оплату комісії.

Вартість спонсорування транзакцій: скільки насправді коштує «безгазовість» для розробників?

Джерело моделює Базову комісію у 5000 лампортів за підпис, використовуючи документацію Solana щодо комісій. Розглядайте це як вхідні дані для перевірки, а не як постійну ціну. Загальна вартість спонсорства також залежить від кількості підписів, пріоритетних комісій, повторних спроб, створення акаунтів, зборів провайдера, інфраструктури та ціни SOL.

Наведені нижче оцінки витрат є ілюстративними та базуються на загальнодоступних даних про комісії. Цей вміст не є фінансовою порадою. Ціна SOL волатильна; фактичні витрати в USD будуть відрізнятися.

Один SOL дорівнює 1 000 000 000 лампортів. Базова комісія у 5000 лампортів за підпис є мінімумом мережі. Пріоритетні комісії є необов'язковими та контролюються спонсором.

Пріоритетні комісії — це необов'язкова інструкція computeUnitPrice, яка переміщує транзакцію на початок черги під час періодів мережевого навантаження. Додавання пріоритетних комісій збільшує вартість транзакції та вносить варіативність. Плануйте бюджет із запасом, якщо ваш додаток спонсорує транзакції в періоди перевантаження.

Витрати на керовані сервіси додають рівень понад мережеву комісію Solana. При використанні Helius або іншого керованого ретранслятора розробник оплачує як Базову комісію Solana, так і абонентську плату за API провайдера або комісію за обслуговування кожної транзакції. Зверніться до актуальної документації з ціноутворення кожного провайдера для отримання детальної інформації.

Таблиця є ілюстрацією з використанням припущеної базової комісії та ціни SOL. Фактична вартість залежить від підписів, пріоритетних комісій, невдалих або повторних транзакцій, створення акаунтів, ціноутворення провайдера, інфраструктури та Ціни токена. Командам слід оцінювати власне робоче навантаження, а не екстраполювати гарантовану вартість із таблиці.

Для вибору між керованими сервісами та власними ретрансляторами на основі вартості та операційних факторів див. розділ про правильний підхід.

Міркування щодо безпеки: що розробники мають знати про ризики ретрансляторів

Впровадження транзакцій без комісії (gasless) покладає на розробників, операторів інфраструктури та користувачів обов'язки щодо забезпечення безпеки. Підпис користувача авторизує інструкції транзакції, представлені гаманцем; спонсорство комісії не робить шкідливі або оманливі інструкції безпечними.

Безпека користувачів: легітимний процес спонсорування комісії не повинен вимагати надання Приватного ключа, але користувачам все одно потрібно перевіряти домен, запити гаманця, ID програм, дозволи на токени, акаунти та суми. Шкідливий dApp може попросити користувача підписати небезпечні інструкції, навіть якщо інший акаунт оплачує мережеву комісію.

Ризики, наведені нижче, стосуються розробників та операторів, тоді як ризики підписання транзакцій, фішингу, гаманців та авторизації активів також впливають на кінцевих користувачів.

Ризик 1: Маніпуляція вмістом транзакції. Шкідливий клієнт може створити транзакцію, що містить небезпечні інструкції, і надіслати її ретранслятору, сподіваючись, що той підпише її без перевірки вмісту. Заходи захисту: ретранслятор повинен десеріалізувати та валідувати транзакцію перед підписанням. Перевіряйте ID програм, дані інструкцій та списки акаунтів за білим списком очікуваних значень. Підписуйте лише ті транзакції, які відповідають очікуваній структурі вашого додатка.

Ризик 2: Атаки повторного відтворення (Replay attacks). Механізм recentBlockhash у Solana нативно запобігає атакам повторного відтворення. Blockhash втрачає силу приблизно через 150 слотів (від 60 до 90 секунд), і будь-яка транзакція, подана після закінчення терміну дії її blockhash, відхиляється мережею. Ретранслятори не повинні повторно підписувати транзакції з простроченими blockhash. Для процесів, де затримки подання неминучі, впроваджуйте стійкі нонси (durable nonces), використовуючи функцію nonceAccount від Solana; див. документацію Solana щодо стійких нонсів.

Ризик 3: Відмова в обслуговуванні (DoS) ретранслятора. Якщо Сторонній керований ретранслятор виходить з ладу, користувачі не можуть надсилати спонсоровані транзакції, навіть якщо вони готові оплатити комісію самостійно. Заходи захисту: впровадьте в інтерфейсі (frontend) резервний шлях, який створює стандартну транзакцію (з оплатою користувачем), коли кінцева точка ретранслятора недоступна. Це зберігає функціональність під час збоїв.

Ризик 4: Спустошення гаманця спонсора. Без обмеження частоти запитів зловмисник може генерувати великі обсяги транзакцій, що виглядають валідними, щоб спустошити Баланс SOL спонсора. Заходи захисту: встановіть ліміти на кількість запитів на адресу гаманця, IP-адресу та часовий проміжок. Встановіть щоденний ліміт витрат. Впровадьте автоматичний вимикач, який призупиняє спонсорство, коли обсяг перевищує поріг. Моніторте Баланс гаманця спонсора за допомогою автоматичних сповіщень та тригерів поповнення.

Ризик 5: Front-running та MEV. Ретранслятор транслює транзакцію та бачить її вміст до Ончейн підтвердження. Для DeFi додатків, що передбачають свопи або Арбітраж, ворожий ретранслятор може випередити транзакцію (front-run). Заходи захисту: використовуйте власний ретранслятор для DeFi додатків, які обробляють чутливі фінансові транзакції. Оцінюйте репутацію та оперативну прозорість будь-якого Стороннього провайдера перед інтеграцією його в DeFi продукт.

Щодо нормативного контексту: у деяких юрисдикціях спонсорування транзакцій користувачів може мати наслідки для регуляторного статусу dApp, особливо якщо спонсоровані комісії характеризуються як передача цінності. Це не юридична консультація; зверніться до юриста для аналізу залежно від конкретної юрисдикції.

У розділі посібника з впровадження щодо рівня валідації описано, де саме в архітектурі ретранслятора застосовуються ці заходи захисту.

Чек-лист безпеки для впровадження ретранслятора

• Валідуйте та десеріалізуйте вміст транзакції перед підписанням
• Ніколи не підписуйте повторно транзакції з простроченими blockhash
• Впровадьте резервний варіант з оплатою користувачем на випадок збою ретранслятора
• Встановіть ліміти частоти запитів на гаманець, IP та часовий проміжок із щоденним лімітом витрат
• Використовуйте власний або довірений ретранслятор для DeFi додатків, що обробляють чутливі транзакції

Вибір правильного підходу: Нативне впровадження vs Керований сервіс

Вибір між нативним впровадженням feePayer, керованим сервісом ретрансляції та власним ретранслятором залежить від чотирьох факторів: термінів розробки, обсягу транзакцій, вимог до безпеки та бюджету на поточні операційні витрати.

Не існує універсального порогу обсягу транзакцій для вибору керованого сервісу. Перед вибором підходу порівняйте умови зберігання ключів, засоби валідації, доступність, приватність, відповідність нормативам, резидентність даних, ціноутворення, переносність та реагування на інциденти.

Створюйте власний ретранслятор, якщо ваш додаток потребує спеціальної логіки відповідності (наприклад, спонсорування лише перших п'яти транзакцій на користувача або обмеження спонсорства конкретними типами інструкцій), коли обсяг транзакцій та вимоги до безпеки виправдовують операційні інвестиції, або коли вимоги до резидентності даних виключають використання Стороннього провайдера.

Нативний підхід feePayer без виділеного сервера ретрансляції підходить для простих додатків із довіреним бекендом і передбачуваним низьким обсягом транзакцій.

Команди, які використовують керований сервіс, повинні зберігати можливість міграції на власний ретранслятор у разі, якщо провайдер змінить ціноутворення або припинить надання послуг. Документуйте точки інтеграції так, щоб міграція була зміною конфігурації, а не переписуванням коду.

Для моделювання вартості кожного варіанту див. розділ аналізу витрат.

Часті запитання про транзакції без комісії (Gasless) на Solana

Що таке транзакції без комісії (gasless) у Криптовалюті?

Безкоштовні (газлес) транзакції в криптовалюті – це блокчейн-транзакції, в яких кінцевий користувач не сплачує мережеву комісію. Третя сторона, така як розробник dApp, протокол або ретрансляторний сервіс, покриває комісію від імені користувача. Термін виник в екосистемі Ethereum, де комісії за транзакції називаються "газом", і згодом поширився на такі блокчейни, як Solana, як загальний термін для спонсорованих досвідів користувача.

Чи стягує Solana плату за газ?

Solana використовує комісії за транзакції замість терміну "газ". Джерело посилається на базову комісію у 5 000 лампортів за підпис, але поточні параметри слід перевіряти, а загальна вартість може включати кілька підписів та необов'язкові пріоритетні комісії. Безкоштовний (газлес) означає, що інший обліковий запис сплачує відповідну мережеву комісію.

Як працює платник комісії в Solana?

Платник комісії в Solana – це обліковий запис, призначений для сплати комісії за транзакцію. Кожна транзакція має поле feePayer в об'єкті транзакції. У стандартній транзакції платник комісії та підписувач транзакції – це один і той самий обліковий запис. У безкоштовній (газлес) транзакції вони є різними обліковими записами: гаманець користувача підписує для авторизації інструкції, а окремий обліковий запис платника комісії (контрольований dApp) підписує для авторизації та сплати комісії. Списання відбувається лише з балансу SOL платника комісії.

Хто сплачує за безкоштовні (газлес) транзакції в Solana?

Розробник dApp, протокольна скарбниця або керований ретрансляторний сервіс сплачують за безкоштовні (газлес) транзакції в Solana. Ці суб'єкти фінансують обліковий запис платника комісії за допомогою SOL і запускають ретранслятор, який спільно підписує транзакції від імені користувачів. З точки зору бізнесу, це спонсорство транзакцій: dApp розглядає комісію як витрати на залучення користувачів. Дивіться таблицю "Хто платить" у розділі про помилкові уявлення для детального розбиття.

Неможливо здійснити жодну транзакцію в Solana без сплати комісії валідаторам. Комісія є вимогою протоколу. Можливо, щоб комісію сплатила сторона, відмінна від відправника. Безкоштовна (газлес) транзакція все одно має комісію; користувач просто не є тим, хто її сплачує. Аналогія: ресторан може безкоштовно надати вам страву, але їжа все одно мала свою вартість.

Спонсорство комісій за транзакції – це практика, коли розробник dApp, протокол або сервіс покриває мережеву комісію за транзакцію від імені кінцевого користувача, дозволяючи користувачеві взаємодіяти з Solana, не маючи SOL для сплати комісій. Це механізм, який уможливлює безкоштовний (газлес) досвід користувача. З точки зору продукту, спонсорство комісій зазвичай розглядається як витрати на залучення користувачів, подібно до безкоштовної (freemium) пропозиції або відмови від плати за онбординг.

Щоб створити безкоштовний (газлес) dApp на Solana: (1) створіть ключ (keypair) платника комісії, який зберігається на сервері та фінансується SOL; (2) конструюйте транзакції, встановивши transaction.feePayer на відкритий ключ платника комісії; (3) попросіть користувачів підписати транзакції через їхні гаманці; (4) надішліть частково підписану транзакцію на ваш сервер-ретранслятор; (5) змусьте ретранслятор перевірити вміст транзакції, додати підпис платника комісії та надіслати її в мережу. Дивіться посібник з впровадження для повних технічних деталей щодо всіх трьох підходів до реалізації.

Ethereum та Solana використовують різні архітектури комісій та спонсорства. Solana має вбудоване поле платника комісії і може також використовувати пріоритетні комісії; Ethereum підтримує адаптацію облікових записів (account-abstraction) та дизайни мета-транзакцій з різними компонентами. Порівнюйте еквівалентні обсяги роботи, політики підтвердження, витрати постачальників та засоби контролю безпеки, а не покладайтеся на одну фіксовану суму комісії.

Так, багато платформ OTK_0 на Solana спонсорують комісію за транзакцію карбування, що означає, що користувачі нічого не платять за мережеву комісію. Однак "безкоштовне карбування" (free mint) і "безкоштовне карбування з точки зору газу" (gasless mint) – це не одне й те саме. Безкоштовне карбування означає відсутність комісії за транзакцію та відсутність ціни за карбування. Безкоштовне карбування з точки зору газу означає, що комісія за транзакцію спонсорується, але ціна за карбування все ще може застосовуватися. Термін "безкоштовний" (gasless) стосується виключно спонсорства мережевої комісії, а не того, чи має сам NFT ціну покупки.

Поведінка безкоштовних (газлес) транзакцій в основному реалізується dApp та ретранслятором, але сумісність гаманців та підтримка формату транзакцій все ще потребують тестування. Спонсор може покрити мережеву комісію, навіть якщо підписані інструкції можуть переміщувати активи користувача або створювати інші витрати.

Їх можна реалізувати безпечно, але спонсорство не є гарантією безпеки. Користувачі повинні перевіряти dApp та підписані інструкції, тоді як розробники повинні перевіряти транзакції, захищати ключі спонсора, обмежувати зловживання, відстежувати ретранслятори та забезпечувати обробку помилок. Легітимний сервіс ніколи не повинен запитувати приватний ключ користувача.

Якщо керований ретрансляторний сервіс виходить з ладу, спонсоровані транзакції не можуть бути надіслані, доки сервіс не відновиться. Користувачі, які готові сплатити власні комісії, не зможуть цього зробити, якщо dApp не реалізував резервний шлях. Добре побудований безкоштовний (газлес) dApp виявляє доступність ретранслятора та переходить до побудови стандартної транзакції, де користувач сплачує комісію, коли ретранслятор недоступний. Це один з ключових операційних ризиків використання керованого ретрансляторного сервісу замість власного.

Пов'язані посібники з економіки мережі Solana

• Як Solana генерує дохід
• Зростання ринку стейблкоїнів Solana

Читачі можуть переглянути актуальну інформацію про ринок SOL або спот-ринок SOL/USDT). Доступність не підтверджує протокол, стейблкоїн, ретранслятор, програму зворотного викупу або інвестиційну тезу.

Безкоштовні (газлес) транзакції на Solana надають кінцевим користувачам досвід без сплати комісій, перекладаючи сплату комісій на призначений обліковий запис платника комісії – поле першого класу в рідній моделі транзакцій Solana.

Ключові моменти:

• Поле feePayer вбудоване в базову структуру транзакцій Solana. Додаткові програми чи контракти для спонсорства комісій не потрібні.
• Комісія завжди існує і завжди надходить валідаторам. "Безкоштовний" (газлес) означає, що користувач не є платником, а не те, що комісії не існує.
• Розглядаються три шляхи реалізації: рідний потік платника комісій за допомогою затвердженого SDK, керований ретрансляторний сервіс та власноруч створений ретранслятор. Кожен несе різні компроміси щодо безпеки, доступності, витрат та контролю.
• Відповідальність за безпеку розділена: користувачі перевіряють те, що вони підписують, тоді як розробники перевіряють вміст транзакцій, захищають ключі спонсора, обмежують зловживання та відстежують доступність ретранслятора.
• Ілюстрація базової комісії з джерела свідчить про те, що спонсорство може бути недорогим, але виробнича економіка вимагає актуальних комісій, налаштувань пріоритету, показників збоїв, зборів постачальників та тестування еквівалентних робочих навантажень.

Наступні кроки за аудиторією:

Для користувачів: Шукайте явне підтвердження того, що dApp спонсорує комісії, перш ніж вважати, що ваш баланс SOL не буде задіяний. Ви можете брати участь, не купуючи SOL заздалегідь, коли спонсорство активне, але завжди перевіряйте актуальну політику кожної платформи.

Для розробників: Порівняйте рідну модель платника комісії, кілька керованих постачальників та власноруч керований ретранслятор. Перевірте актуальну документацію, припущення щодо безпеки, умови обслуговування та витрати перед вибором реалізації.

Для стратегів продуктів: Моделюйте свої витрати на спонсорство за допомогою формули в розділі аналізу витрат та оцінюйте підходи до реалізації за допомогою таблиці рішень у розділі правильного підходу.

У міру розвитку споживчих dApp на Solana спонсорство комісій стає стандартним шаблоном для онбордингу. Архітектура для його підтримки була частиною протоколу Solana з першого дня.