На протяжении пяти лет сообщение «недостаточно SOL для транзакции» было самой дорогой ошибкой в Solana. Каждое потребительское приложение, пытавшееся привлечь пользователей, не знакомых с криптой, теряло часть из них именно на этом этапе — на шаге оплаты, когда человеку приходится приобретать второй токен только для того, чтобы потратить первый. В апреле 2026 года Solana Foundation наконец представила решение: Kora, ретранслятор комиссий и узел подписания, который позволяет dApps нативно спонсировать транзакции, оплачивать комиссии в любых токенах SPL и передавать подписание на аутсорс в TEE или хранилища на базе KMS. Это не громкий запуск. Это обновление инфраструктуры. И именно такие обновления позволили Base и Abstract незаметно доминировать в привлечении массовых пользователей за последние двенадцать месяцев.
Вопрос больше не в том, сможет ли Solana сравниться с UX без комиссий (gasless UX) в потребительских EVM-сетях. Благодаря Kora эта часть становится тривиальной. Вопрос в том, достаточно ли устранения этого разрыва «последней мили», чтобы вернуть разработчиков, которые уже построили свои решения в других местах.
Что на самом деле представляет собой Kora
Если отбросить маркетинг, Kora — это три объединенных компонента: ретранслятор транзакций, удаленный подписант и механизм политик. dApp создает транзакцию, устанавливает узел Kora в качестве плательщика комиссии (fee payer), пользователь подписывает данные из встроенного кошелька, а оператор Kora ставит вторую подпись и транслирует транзакцию в сеть. Валидаторы по-прежнему получают оплату в SOL. Пользователь же никогда не держит их на счету.
Что делает это решение интересным, так это уровень вал идации. Узел Kora не ретранслирует слепо всё, что передают пользователи. Перед подписанием он выполняет три проверки:
- Валидация инструкций на соответствие связанным программам Solana, чтобы некорректные или вредоносные инструкции отклонялись до того, как они попадут к лидеру.
- Проверка достаточности комиссий на основе оракула, сравнивающая предложенную сумму токенов SPL с текущей ценой SOL плюс маржа оператора, чтобы ретранслятор никогда не работал в убыток.
- Применение белых и черных списков на уровне программ и токенов, чтобы оператор, запустивший узел Kora для конкретного dApp, случайно не проспонсировал транзакцию, направленную на какой-то сторонний непроверенный контракт.
Архитектура пути подписания выглядит амбициозно. Kora «из коробки» поддерживает удаленное подписание через Turnkey и AWS KMS, что означает, что закрытый ключ, оплачивающий комиссии, никогда не хранится на диске ретранслятора. Для финтех-компании, строящейся на Solana, это разница между «мы создали собственный пеймастер на свой страх и риск» и «наша система хранения ключей проходит аудит SOC 2».
Вся система была проверена и прошла дифференциальное фаззинг-тестирование от Runtime Verification — деталь, которую упоминают только тогда, когда ожидают, что институциональные игроки будут изучать каждый пункт отчета.
Почему здесь «нативное» решение лучше «смарт-контрактного»
Велик соблазн сравнить Kora с ERC-4337 и предположить, что Solana просто догоняет остальных. Но эти архитектуры работают по-разному, и эта разница имеет значение.
ERC-4337 — это абстракция аккаунта, реализованная как параллельная система поверх Ethereum. Она вводит отдельный мемпул, объект UserOperation, роль бандлера (bundler) и контракт EntryPoint — ничего из этого базовый протокол нативно не понимает. Бандлеры упаковывают операции пользователей, пеймастеры спонсируют комиссии, а ончейн-контракт обеспечивает валидацию. Это работает, и это было развернуто в основной сети Ethereum и крупных L2-сетях, но это шестилетний проект по модернизации UX-функции, которую протокол изначально не предусматривал.
Дизайн Solana поглотил эту сложность на уровне протокола еще много лет назад. В каждой транзакции уже есть поле feePayer. Частичные подписи являются нативными. Программы могут валидировать произвольные инструкции. Kora — это не конструкция из бандлера и пеймастера; это оператор узла, который заполняет поле feePayer и подписывает транзакцию одной из частичных подписей, которые протокол уже принимает.
Практическим последствием является задержка (latency) и объем работы для разработчика. Транзакции ERC-4337 проходят через отдельный мемпул со своими правилами очередности и задержками распространения. Транзакции Kora проходят тот же путь, что и любая другая транзакция в Solana, с той же финальностью менее 400 мс. Здесь нет рынка арбитража бандлеров, за которым нужно следить, нет версий контракта EntryPoint и нет необходимости отлаживать оценку газа для UserOperation.
Это дает разработчикам на Solana нечто близкое к принципу «установи поле плательщика комиссии и выпускай dApp». При этом теряется некоторая гибкость, которую смарт-аккаунты EVM получают по умолчанию — мультиключевая авторизация, пакетные вызовы, ончейн-политики сессий — хотя многое из этого сейчас создается в Solana отдельно через PDA и аккаунты под управлением программ.
Разрыв «последней мили», который действительно был у Solana
Несмотря на все разговоры о темпах развития Solana в 2025 и 2026 годах, уровень потребительских кошельков оставался отстающим звеном. Инфраструктурный стек созрел быстро: объем DEX на Pump.fun превысил 2 миллиарда долларов в первом квартале 2026 года, Jito и Marinade доминируют в ликвидном стейкинге, Tensor превратил торговлю NFT в профессиональный терминал. Но каждому из этих продуктов приходилось внедрять собственное решение проблемы «у пользова теля нет SOL».
Обходные пути были изобретательными. Pump.fun направлял первоначальную покупку токенов через встроенные онрампы. Jito предварительно пополнял аккаунты пользователей микро-суммами. Tensor полагался на Phantom и Backpack, чтобы те обрабатывали покупку SOL до того, как пользователи доберутся до книги заявок. Каждое из этих решений работало по отдельности, но они не были совместимы. Пользователь, пришедший через Pump.fun, не оказывался на Tensor с балансом для оплаты комиссий.
Тем временем Base представила Smart Wallet от Coinbase с использованием пасски (passkeys), бесплатное спонсирование газа через платформу разработчиков Coinbase и SDK, который скрывает саму концепцию закрытого ключа за входом через электронную почту. Abstract пошла еще дальше с встроенными кошельками, которые ощущаются как обычные Web2-приложения. Совокупное предложение для разработчика потребительских приложений в 2025 году звучало так: «Стройте на Base, ваши пользователи не поймут, что они в блокчейне, а мы оплатим комиссии, пока вы масштабируетесь».
Kora не копирует это предложение слово в слово. Она устраняет архитектурную причину, по которой dApp на Solana не могли предложить то же самое. С Kora команда разработчиков на Solana теперь может предложить:
- Регистрацию через email или пасски через Privy, Turnkey или встроенные кошельки Coinbase.
- Нулевой баланс SOL, необходимый для совершения транзакций.
- Оплату комиссий в USDC, BONK или нативном токене dApp, если он есть.
- Субсекундную финальность без бандлеров на пути.
Компоненты существовали и раньше. Octane был предком с открытым исходным кодом. Circle Gas Station, Openfort, Portal, Gelato, Biconomy и еще полдюжины вендоров предлагали ретрансляцию комиссий как услугу. Kora меняет ситуацию тем, что сам Solana Foundation теперь поставляет стандартную, проверенную и совместимую с KMS эталонную реализацию. Это исключает вопрос «какому стороннему пеймастеру нам доверять» из процесса принятия решений для каждой команды, которая раньше создавала свое решение или платила стороннему поставщику.
Слой вендоров над Kora
Интереснее всего то, что происходит с поставщиками встроенных кошельков, которые уже выстроили свои решения вокруг того пробела, который только что закрыла Kora.
Privy, приобретенная Stripe в июне 2025 года, была основным выбором в качестве кошелька для потребительских приложений на Solana, которым нужен вход через email. Официально Solana является вторичной сетью для Privy — основной фокус направлен на EVM — но процесс работы со встроенными кошельками распространяется и на Solana, а Privy уже поддерживает настройку кошелька для оплаты комиссий (fee payer), которым управляет приложение. Kora не заменяет Privy; она предоставляет Privy стандартизированный бэкенд для подключения, вместо того чтобы каждый клиент запускал собственный пеймастер-сервис.
Turnkey — это ориентированный на безопасность инструмент для встроенной подписи (embedded signer), который естественно сочетается с API удаленной подписи Kora. Turnkey намеренно не включает инфраструктуру пеймастера, поэтому командам на Solana, которым нужны изолированные на аппаратном уровне ключи и UX без газа, приходилось объединять двух разных вендоров. Kora упрощает эту интеграцию.
Dynamic, приобретенная Fireblocks в 2025 году, предлагает мультичейн-аутентификацию для институциональных команд. Позиционирование при поддержке Fireblocks делает Dynamic естественным выбором для финтех-компаний, которым нужно покрытие Solana и EVM с соблюдением корпоративных стандартов соответствия (compliance). Kora дает Dynamic чистое решение для абстракции комиссий в Solana, которое не требует от Fireblocks выпуска конкурирующего пеймастера.
Coinbase Developer Platform находится в неудобном положении. Coinbase вложила значительные средства в то, чтобы сделать Base основной сетью для массового пользователя через Coinbase Smart Wallet, бесплатный газ в Base и SDK для встроенных кошельков. Kora сокращает то преимущество, которое продвигала Base, особенно для приложений, ориентированных на нативные потоки USDC, где у Solana уже есть преимущества в масштабе.
Вероятный исход заключается в том, что Kora станет стандартным бэкендом Solana для каждого поставщика встроенных кошельков, который не хочет самостоятельно управлять пеймастер-сервисом. Вендоры конкурируют в UX аутентификации, управлении ключами и контроле политик. Kora обрабатывает реле комиссий на нижнем уровне. Это более здоровая ситуация для экосистемы, чем прежнее состояние, когда каждое потребительское dApp на Solana принимало независимое решение о выборе вендора и должно было оценивать безопасность самописного ретранслятора (relayer) каждого кандидата.
Что это решает, а что — нет
Kora окончательно закрывает один пробел и оставляет открытыми несколько других. Стоит точно определить, что к чему относится.
Что решает Kora:
- Проблему «пользователь должен иметь SOL» — барьер в UX для любого dApp, готового субсидировать комиссии в другом токене.
- Дилемму «создать или купить пеймастер» для команд, которым раньше приходилось выбирать между операционной нагругой и привязкой к конкретному вендору.
- Разрыв в институциональном признании, поскольку аудит и поддержка KMS позволяют регулируемым организациям запускать узлы Kora, не создавая собственные решения.
Что Kora не решает:
- Сам о привлечение пользователей в кошельки — пользователям все равно нужен встроенный кошелек от кого-то, будь то Phantom, Privy, Turnkey или Coinbase.
- Примитивы абстракции аккаунта, такие как пакетные вызовы (batched calls) и сессионные ключи, которые все еще собираются на Solana отдельно через PDA и другие паттерны на уровне программ.
- Экономический вопрос о том, кто платит за SOL, который авансируют операторы Kora. Для dApp с выручкой в токенах или оборотом в стейблкоинах это нормально; для бесплатного продукта спонсирование газа — это просто стоимость привлечения клиента (CAC).
- Кроссчейн-UX, который по-прежнему требует от пользователя взаимодействия с мостом или слоем абстракции цепочек, таким как LayerZero, Wormhole или Across.
Тезис о «безгазовой инфраструктуре как примитиве протокола» работает в обе стороны. Теперь у Solana самая чистая история нативной абстракции комиссий среди всех крупных сетей. Это также означает, что дифференциация перемещается выше по стеку — к UX кошельков, процессам восстановления и функциям абстракции аккаунтов, где у EVM есть фора в несколько лет.
Стратегический взгляд для разработчиков
Для команды, выбирающей блокчейн в середине 2026 года, расклад сил изменился. Двенадцать месяцев назад ответом для привлечения массовых пользователей были Base, Abstract или одна из новых потребительских EVM-сетей, и точка. Solana пользовалась популярностью у разработчиков и имела инфраструктурный импульс, но теряла розничных пользователей на этапе необходимости приобретения SOL. Это больше не так.
Потребительское dApp, запускаемое сегодня на Solana с Privy или Turnkey на фронтенде и Kora на бэкенде, функционально имеет тот же UX, что и эквивалентный стек на Base. Вход через email, транзакции без газа, оплата комиссий в USDC, субсекундная финальность. Оставшиеся различия — это модель среды выполнения (runtime), экосистема инструментов и доступная ликвидность. Для приложения, которому важна пропускная способность Solana и глубина её DEX, аргумент в пользу UX при выборе EVM стал существенно слабее.
Для команд, уже работающих на Base, Kora не меняет немедленного решения. Она меняет долгосрочное конкурентное давление. Если потребительские dApp с самым чистым UX начнут появляться на Solana, потому что новая инфраструктура избавляет от лишней интеграции, гравитация вокруг защитного рва Base по привлечению пользователей начнет смещаться.
Честный вывод таков: Kora необходима, но недостаточна. Она устраняет конкретную причину, по которой разработчики не выбирали Solana для потребительских приложений. Сама по себе она не создает новую причину выбирать именно Solana. Следующие два квартала покажут, действительно ли поставщики встроенных кошельков перейдут на Kora по умолчанию, будут ли новые dApp указывать её в качестве причины выбора сети и ответят ли существующие потребительские EVM-сети улучшением собственных инфраструктурных решений.
В любом случае, проблема «пользователь должен приобрести SOL перед совершением транзакции» наконец-то стала пережитком прошлого, а не текущей трудностью. Одно это уже стоило реализации.
BlockEden.xyz управляет инфраструктурой Solana RPC промышленного уровня для команд, создающих потребительские dApp, платежные шлюзы и торговые системы. Если вы внедряете безгазовые процессы или масштабируете продукт на Solana, изучите наш маркетплейс API, где представлены эндпоинты с низкой задержкой, разработанные для следующего поколения потребительских криптопродуктов.
Источники
