5 постов с тегом "Account Abstraction"

AllScale.io — это легитимная платежная платформа на базе стейблкоинов с венчурной поддержкой — это не токен-проект — ориентированная на фрилансеров и малый бизнес на развивающихся рынках. Основанная в феврале 2025 года и получившая поддержку в размере $ 6,5 млн от авторитетных крипто-венчурных фондов, включая YZi Labs, Draper Dragon и KuCoin Ventures, компания подает положительные сигналы: публичная команда (doxxed) с проверяемым опытом работы в Kraken, Capital One и Block, а также институциональная поддержка от гонконгского инкубатора Cyberport. Однако отсутствие публичных аудитов безопасности и крайняя новизна платформы (менее одного года) требуют тщательной проверки (due diligence) перед серьезным взаимодействием.

Что делает AllScale и какую проблему решает​

AllScale позиционирует себя как «первый в мире некастодиальный необанк на базе стейблкоинов», специально разработанный для более чем 600 миллионов микропредприятий по всему миру — фрилансеров, создателей контента, малого и среднего бизнеса и удаленных подрядчиков — которые испытывают трудности с традиционными трансграничными платежами. Основная проблема: международные фрилансеры сталкиваются с барьерами при открытии банковских счетов, высокими комиссиями за переводы, потерями при конвертации валют и задержками расчетов, часто превышающими 5 рабочих дней.

Платформа позволяет компаниям выставлять счета, получать платежи в USDT или USDC независимо от того, как платят клиенты (кредитная карта, банковский перевод или криптовалюта), и мгновенно получать доступ к средствам через некастодиальный кошелек. Ключевые продукты включают AllScale Invoice (запущен в сентябре 2025 года), AllScale Pay (социальная коммерция через Telegram, WhatsApp, Line) и AllScale Payroll (трансграничные выплаты подрядчикам). Компания делает акцент на «невидимой крипте» — клиенты могут даже не знать, что они используют блокчейн-рельсы, в то время как мерчанты получают стейблкоины.

Текущая стадия разработки: Платформа находится в стадии публичного бета-тестирования с работающим продуктом в основной сети (mainnet) BNB Chain. Пользователи могут получить доступ к панели управления по адресу dashboard.allscale.io, хотя может применяться список ожидания.

Техническая архитектура опирается на BNB Chain и абстракцию аккаунта​

AllScale строится на существующей блокчейн-инфраструктуре, а не управляет собственной цепочкой. Основной технологический стек включает:

Подход на основе Passkey устраняет печально известное трение в пользовательском опыте (UX), связанное с управлением сид-фразами, снижая барьер для массового внедрения. Мультичейн-архитектура спонсирования через пеймастеры берет на себя расходы на транзакции за кулисами.

Чего не хватает: AllScale не имеет публичных репозиториев на GitHub — инфраструктура является проприетарной и закрытой. Адреса смарт-контрактов не опубликованы, публичные API или SDK недоступны, а техническая документация на docs.allscale.io ориентирована на руководства для пользователей, а не на спецификации архитектуры. Эта непрозрачность препятствует независимой технической проверке их заявлений.

Отсутствие нативного токена — платформа использует USDT и USDC​

У AllScale нет собственной криптовалюты (токена). Это критическое отличие от многих Web3-проектов: здесь нет ICO, IDO, продажи токенов или спекулятивных активов. Компания работает как традиционная корпорация типа Delaware C-corp, привлекающая акционерное финансирование.

Платформа использует сторонние стейблкоины — в основном USDT и USDC — в качестве средства платежа. Пользователи получают платежи в стейблкойнах с автоматической конвертацией из фиатных или карточных платежей. Интеграция с BNB Chain также обеспечивает доступ к USD1 (стейблкоину, аффилированному с Binance).

Модель дохода (оценочная, официально не раскрыта):

• Комиссии за транзакции при обработке счетов/платежей
• Спреды при конвертации валют при обмене фиата на стейблкоины
• Услуги по управлению расчетами с персоналом (B2B payroll)
• Комиссии за интеграцию шлюзов ввода/вывода средств (on/off-ramp)

Отсутствие токена устраняет определенные риски (спекулятивная волатильность, манипуляции с токеномикой, регуляторные вопросы касательно ценных бумаг), но также означает, что для инвесторов нет возможности вложений через токены, помимо участия в капитале.

Четыре публичных основателя с проверяемым бэкграундом​

Команда AllScale демонстрирует высокую прозрачность — все основатели публично идентифицированы и имеют проверяемую профессиональную историю:

Шон Панг (Shawn Pang, CEO и сооснователь): Образование в области компьютерных наук и бизнеса в Западном университете (Western University). Бывший менеджер по продукту (PM) по борьбе с платежным мошенничеством в Capital One; первый PM TikTok в Канаде; сооснователь HashMatrix, маркетингового агентства для роста ИИ-продуктов.

Жуоян «Лео» Ванг (Ruoyang "Leo" Wang, COO и сооснователь): Компьютерная инженерия в Университете Торонто. Опыт работы в PingCAP (распределенные базы данных), IBM, AMD и Scotiabank. Предыдущий опыт в стартапе CP Clickme.

Джун Ли и Халил Лин (Jun Li & Khalil Lin, сооснователи): Дополнительные сооснователи с опытом в юридической сфере и комплаенсе, по имеющимся данным, имеющие опыт работы в OKX. Профили в LinkedIn доступны.

Аврилин Ли (Avrilyn Li, ведущий менеджер по продукту): Предприниматель в сфере AI-to-Web3 из бизнес-школы Ivey, возглавляющая продукт для расчета заработной платы (payroll).

Команда заявляет о коллективном опыте работы в Binance, OKX, Kraken, Block (Square), Amazon, Dell и HP. Общая численность команды составляет примерно 7–11 сотрудников.

Финансирование и инвесторы​

Среди известных участников инвестиций — KuCoin Ventures, Oak Grove Ventures, BlockBooster, Aptos, GSR Ventures и V3V Ventures. Бизнес-ангелами выступили Грейси Чен (Gracy Chen) и Джеди Лу (Jedi Lu). Компания является участником программы инкубации Hong Kong Cyberport Incubation Program, технологического акселератора, поддерживаемого правительством.

Серьезная проблема безопасности: отсутствие публичных аудитов и программы bug bounty​

Это самый значительный тревожный сигнал в данном исследовании. Несмотря на управление средствами пользователей через смарт-контракт кошельки:

• Нет публичных аудитов смарт-контрактов от признанных фирм (CertiK, Hacken, Trail of Bits, OpenZeppelin, SlowMist)
• Проект не указан в CertiK Skynet или аналогичных базах данных безопасности
• Нет программы bug bounty на Immunefi, HackerOne или Bugcrowd
• Не раскрыты механизмы страхования или покрытия рисков
• Нет публично доступной политики раскрытия уязвимостей

AllScale заявляет о таких функциях безопасности, как архитектура самостоятельного хранения (self-custody), автоматизированное соблюдение требований KYC / KYB / KYT, интеграция аппаратных модулей безопасности (HSM) для ключей доступа (passkeys) и поддержка 2FA. Модель самостоятельного хранения снижает риск контрагента платформы — в случае компрометации AllScale средства пользователей в их собственных кошельках теоретически будут в большей безопасности, чем в кастодиальном сервисе.

С положительной стороны: для AllScale не было зарегистрировано никаких инцидентов безопасности, взломов или эксплойтов. Однако, учитывая молодость платформы, отсутствие инцидентов может просто отражать ограниченную известность, а не надежную безопасность.

Конкурентная среда и позиционирование на рынке​

AllScale конкурирует в быстро развивающемся сегменте платежей в стейблкоинах:

Факторы дифференциации AllScale:

• Модель самостоятельного хранения (self-custody) (пользователи контролируют средства)
• Аутентификация с помощью ключей доступа (passkeys), устраняющая сложности UX с сид-фразами
• Нулевые комиссии за газ (zero gas fees) благодаря абстракции аккаунта (account abstraction)
• Ориентация на развивающиеся рынки (Африка, Латинская Америка, Юго-Восточная Азия)
• Таргетинг на малый и средний бизнес (SMB) "последней мили" в противовес корпоративному фокусу

Недостатки: крайняя молодость проекта, небольшая команда, ограниченный послужной список, конкуренция с хорошо финансируемыми игроками, имеющими налаженные каналы дистрибуции.

Присутствие в сообществе находится на ранней стадии и ориентировано на B2B​

AllScale поддерживает стандартные социальные каналы Web3:

• X (Twitter): @allscaleio (активен с апреля 2025 года)
• Telegram: Группа сообщества AllScaleHQ
• Discord: Активный сервер с видимым ID сообщества
• LinkedIn: Страница компании AllScale Inc
• Информационный бюллетень: "The Stablecoin Scoop" на Substack

Сообщество находится на ранней стадии развития, взаимодействие происходит в основном через сессии AMA, X Spaces и объявления о партнерстве. AllScale провела саммит Scale Stablecoin Summit в Гонконге (июнь 2025 г.) совместно с HashKey Group и Amber Group.

Традиционные метрики DeFi не применимы: AllScale — это платежная платформа, а не протокол DeFi, поэтому метрики TVL (Total Value Locked) здесь не подходят. Платформа не представлена на DeFiLlama или Dune Analytics. Количество пользователей и показатели удержания упоминаются инвесторами, но публично не раскрываются.

Среди заметных партнерств: BNB Chain (официальный партнер экосистемы), Skill Afrika (сообщества африканских фрилансеров), Ethscriptions (L1 permanence) и Asseto (токенизация RWA для доходных продуктов).

Оценка рисков выявляет венчурный проект ранней стадии с умеренным риском​

Положительные сигналы легитимности​

• Публично раскрытая команда (doxxed) с проверяемым профессиональным опытом
• Авторитетные крипто-венчурные фонды (YZi Labs, Draper Dragon, Amber Group, KuCoin Ventures)
• Институциональная поддержка Hong Kong Cyberport
• Юридическая структура C-corp (Делавэр)
• Работающий продукт в основной сети BNB Chain
• Не обнаружено обвинений в мошенничестве, жалоб в BBB или предупреждений сообщества
• Нет опасений по поводу анонимности команды
• Отсутствие нереалистичных обещаний доходности или спекуляций токенами
• Позиционирование, ориентированное на комплаенс (GENIUS Act, Постановление о стейблкоинах Гонконга)

Области, требующие осторожности​

• Крайняя молодость: основана в феврале 2025 года, проекту меньше года
• Отсутствие публичных аудитов безопасности, несмотря на управление средствами
• Нет программы bug bounty
• Нет независимых отзывов пользователей или обратной связи от сообщества
• Закрытая инфраструктура — невозможно независимо проверить заявления
• Освещение в прессе в основном через агрегаторы пресс-релизов, а не независимую журналистику
• Риски централизации: платформа, управляемая компанией, зависимость от BNB Chain
• Малая команда (~ 7-11 человек), реализующая амбициозный глобальный охват

Не найдено (потенциальные «тревожные звоночки» ввиду отсутствия)​

• Публичные метрики пользователей не раскрыты
• Показатели выручки отсутствуют
• Нет официального консультативного совета
• Нет конкретных регуляторных лицензий (нормативная база Гонконга еще не вступила в силу)

Последние разработки и дорожная карта​

Последние вехи (2025):

• 8 декабря: Объявлено о посевном раунде в размере $5 млн (под руководством YZi Labs)
• Ноябрь: Запуск AllScale Pay в сети BNB Chain; партнерство со Skill Afrika
• Октябрь: Партнерство с Ethscriptions для обеспечения неизменяемости на L1
• Сентябрь: Запуск продукта AllScale Invoice
• Август: Интеграция с BNB Chain и поддержка USD1
• Июнь: Саммит Scale Stablecoin в Гонконге; пре-посевное финансирование в размере $1,5 млн

Предстоящие события:

• 1 квартал 2026: Расширение на рынок Латинской Америки
• Будущее: Опции доходности DeFi, расширенные кроссчейн-возможности, B2B-решения для предприятий

Заключение​

AllScale.io позиционирует себя как законный стартап на ранней стадии, а не мошеннический проект, опираясь на поддержку надежных инвесторов и прозрачную, проверяемую команду. Проект решает реальную рыночную проблему — сложности трансграничных платежей для фрилансеров на развивающихся рынках — с использованием продуманного технического подхода на базе абстракции аккаунта (account abstraction) и стейблкоинов.

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

Общий рейтинг риска: умеренный. Венчурный проект демонстрирует сильные сигналы легитимности, но несет в себе риски, присущие ранним стадиям. Потенциальным пользователям следует начинать с небольших сумм до публикации аудитов безопасности. Потенциальным партнерам стоит запросить прямой доступ к техническим спецификациям и отчетам об аудитах. За проектом стоит следить по мере его развития, особенно в ожидании анонсов аудитов безопасности в первом квартале 2026 года.

Представьте себе мир, где пользователи могут беспрепятственно взаимодействовать с вашим dApp, не имея нативных токенов (SUI). Это больше не далёкая мечта. С помощью Gas Station Sui (также известного как Paymaster) разработчики могут покрывать комиссии за газ от имени своих пользователей, полностью устраняя один из самых больших барьеров для новичков в Web3 и обеспечивая по-настоящему беспрепятственный ончейн-опыт.

Эта статья представляет собой полное руководство по обновлению вашего dApp до безгазового состояния. Мы подробно рассмотрим основные концепции Sui Paymaster, его архитектуру, шаблоны реализации и лучшие практики.

1. Предыстория и основные концепции: Что такое спонсируемая транзакция?​

В мире блокчейна каждая транзакция требует сетевой комиссии, или «газа». Для пользователей, привыкших к бесшовному опыту Web2, это является значительным когнитивным и операционным препятствием. Sui решает эту проблему на уровне протокола с помощью спонсируемых транзакций.

Основная идея проста: позволить одной стороне (Спонсору) оплачивать комиссии за газ SUI для транзакции другой стороны (Пользователя). Таким образом, даже если у пользователя нет SUI в кошельке, он всё равно может успешно инициировать ончейн-действия.

Paymaster ≈ Газовая станция​

В экосистеме Sui логика спонсирования транзакций обычно обрабатывается офчейн- или ончейн-сервисом, называемым Gas Station или Paymaster. Его основные обязанности включают:

1. Оценка транзакции: Он получает данные безгазовой транзакции пользователя (GasLessTransactionData).
2. Предоставление газа: Он блокирует и выделяет необходимую комиссию за газ для транзакции. Обычно это управляется через газовый пул, состоящий из множества объектов SUI Coin.
3. Генерация подписи спонсора: После одобрения спонсорства Gas Station подписывает транзакцию своим приватным ключом (SponsorSig), подтверждая свою готовность оплатить комиссию.
4. Возврат подписанной транзакции: Он отправляет обратно TransactionData, которая теперь включает данные о газе и подпись спонсора, чтобы дождаться окончательной подписи пользователя.

Короче говоря, Gas Station действует как служба заправки для пользователей вашего dApp, гарантируя, что их «транспортные средства» (транзакции) могут беспрепятственно перемещаться по сети Sui.

2. Высокоуровневая архитектура и поток взаимодействия​

Типичная безгазовая транзакция включает координацию между пользователем, фронтендом dApp, Gas Station и полной нодой Sui. Последовательность взаимодействия следующая:

Разбор потока:

1. Пользователь выполняет действие в пользовательском интерфейсе dApp, которое формирует пакет данных транзакции без какой-либо информации о газе.
2. dApp отправляет эти данные в свою назначенную Gas Station для запроса спонсорства.
3. Gas Station проверяет действительность запроса (например, проверяет, имеет ли пользователь право на спонсорство), затем заполняет транзакцию Gas Coin и своей подписью, возвращая полузавершенную транзакцию dApp.
4. Пользователь видит полные детали транзакции в своём кошельке (например, «Купить один NFT») и предоставляет окончательную подпись. Это важный шаг, который гарантирует, что пользователь сохраняет согласие и контроль над своими действиями.
5. dApp транслирует полную транзакцию, содержащую подписи как пользователя, так и спонсора, в полную ноду Sui.
6. После завершения транзакции в сети Gas Station может подтвердить это, прослушивая ончейн-события или квитанции, а затем уведомить бэкенд dApp через вебхук, чтобы завершить бизнес-процесс.

3. Три основные модели взаимодействия​

Вы можете использовать следующие три модели взаимодействия по отдельности или в комбинации, чтобы соответствовать вашим бизнес-потребностям.

Модель 1: Инициировано пользователем → Одобрено спонсором (наиболее распространённая)​

Это стандартная модель, подходящая для подавляющего большинства взаимодействий внутри dApp.

1. Пользователь формирует GasLessTransactionData: Пользователь выполняет действие внутри dApp.
2. Спонсор добавляет GasData и подписывает: Бэкенд dApp отправляет транзакцию в Gas Station, которая одобряет её, прикрепляет Gas Coin и добавляет свою подпись.
3. Пользователь просматривает и даёт окончательную подпись: Пользователь подтверждает окончательные детали транзакции в своём кошельке и подписывает её. Затем dApp отправляет её в сеть.

Эта модель обеспечивает отличный баланс между безопасностью и пользовательским опытом.

Модель 2: Аирдропы/стимулы, инициированные спонсором​

Эта модель идеально подходит для аирдропов, пользовательских стимулов или пакетного распределения активов.

1. Спонсор предварительно заполняет TransactionData + подписывает: Спонсор (обычно команда проекта) предварительно формирует большую часть транзакции (например, аирдроп NFT на определённый адрес) и прикрепляет свою спонсорскую подпись.
2. Вторая подпись пользователя делает её действительной: Пользователю достаточно подписать эту «предварительно одобренную» транзакцию один раз, чтобы она была выполнена.

Это создаёт чрезвычайно плавный пользовательский опыт. Всего одним щелчком для подтверждения пользователи могут получать награды или выполнять задания, что значительно увеличивает коэффициенты конверсии маркетинговых кампаний.

Модель 3: Wildcard GasData (модель кредитной линии)​

Это более гибкая модель, основанная на разрешениях.

1. Спонсор передаёт объект GasData: Спонсор сначала создаёт один или несколько объектов Gas Coin с определённым бюджетом и передаёт право собственности непосредственно пользователю.
2. Пользователь свободно тратит в пределах бюджета: Затем пользователь может свободно использовать эти Gas Coins для оплаты любых транзакций, которые он инициирует, в пределах лимитов бюджета и срока действия.
3. Gas Coin возвращается: После исчерпания или истечения срока действия объект Gas Coin может быть разработан таким образом, чтобы автоматически уничтожаться или возвращаться Спонсору.

Эта модель эквивалентна предоставлению пользователю «кредитной карты для оплаты газа» с ограниченным сроком действия и бюджетом, подходящей для сценариев, требующих высокой степени автономии пользователя, например, для предложения бесплатного игрового опыта во время игрового сезона.

4. Типичные сценарии применения​

Сила Sui Paymaster заключается не только в решении проблемы комиссий за газ, но и в его способности глубоко интегрироваться с бизнес-логикой для создания новых возможностей.

Сценарий 1: Платные стены (Paywalls)​

Многие контентные платформы или dApp-сервисы требуют от пользователей соответствия определённым критериям (например, владение VIP NFT, достижение определённого уровня членства) для доступа к функциям. Paymaster может идеально реализовать эту логику.

• Поток: Пользователь запрашивает действие → бэкенд dApp проверяет квалификацию пользователя (например, владение NFT) → если пользователь соответствует требованиям, он вызывает Paymaster для спонсирования комиссии за газ; в противном случае он просто отклоняет запрос на подписание.
• Преимущество: Эта модель по своей природе устойчива к ботам и злоупотреблениям. Поскольку решение о спонсорстве принимается на бэкенде, злоумышленники не могут обойти проверку квалификации, чтобы истощить газовые средства.

Сценарий 2: Оформление заказа в один клик​

В сценариях электронной коммерции или внутриигровых покупок упрощение процесса оплаты имеет решающее значение.

• Поток: Пользователь нажимает «Купить сейчас» на странице оформления заказа. dApp формирует транзакцию, которая включает бизнес-логику (например, transfer_nft_to_user). Пользователю нужно только подписать, чтобы одобрить бизнес-транзакцию в своём кошельке, не беспокоясь о газе. Комиссия за газ покрывается Спонсором dApp.
• Преимущество: Вы можете закодировать бизнес-параметры, такие как order_id, непосредственно в ProgrammableTransactionBlock, что позволяет точно атрибутировать ончейн-данные для бэкенд-заказов.

Сценарий 3: Атрибуция данных​

Точное отслеживание данных является основополагающим для оптимизации бизнеса.

• Поток: При формировании транзакции запишите уникальный идентификатор (например, order_hash) в параметры транзакции или в событие, которое будет сгенерировано при выполнении.
• Преимущество: Когда Gas Station получает ончейн-квитанцию об успешной транзакции, она может легко извлечь этот order_hash, анализируя данные события или транзакции. Это позволяет точно сопоставлять изменения ончейн-состояния с конкретными бэкенд-заказами или действиями пользователя.

5. Скелет кода (на основе Rust SDK)​

Вот упрощённый фрагмент кода, демонстрирующий основные шаги взаимодействия.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

Для полной реализации обратитесь к официальному Руководству по Gas Station в документации Sui, которое предлагает готовые примеры кода.

6. Риски и защита​

Хотя Gas Station является мощным инструментом, развёртывание его в производственной среде требует тщательного рассмотрения следующих рисков:

• Двусмысленность (двойная трата): Злоумышленник может попытаться использовать один и тот же Gas Coin для нескольких транзакций параллельно, что приведёт к блокировке Gas Coin сетью Sui. Это можно эффективно смягчить, назначая уникальный Gas Coin для каждого пользователя или транзакции, ведя чёрный список и ограничивая частоту запросов на подписание.
• Управление газовым пулом: В сценариях с высокой конкуренцией один Gas Coin большой стоимости может стать узким местом производительности. Сервис Gas Station должен быть способен автоматически разделять крупные SUI Coin на множество Gas Coin меньшей стоимости и эффективно возвращать их после использования. Профессиональные поставщики Gas Station, такие как Shinami, предлагают зрелые, управляемые решения для этого.
• Авторизация и ограничение скорости: Вы должны установить строгие политики авторизации и ограничения скорости. Например, управлять лимитами и частотой спонсорства на основе IP-адреса пользователя, адреса кошелька или токенов API, чтобы предотвратить истощение сервиса злоумышленниками.

7. Инструменты экосистемы​

Экосистема Sui уже предлагает богатый набор инструментов для упрощения разработки и развёртывания Paymaster:

• Официальные SDK (Rust/TypeScript): Включают высокоуровневые API, такие как sponsor_transaction_block(), значительно снижая сложность интеграции.
• Shinami Gas Station: Предоставляет комплексный управляемый сервис, включающий автоматическое разделение/возврат Gas Coin, детальный мониторинг метрик и уведомления через вебхуки, что позволяет разработчикам сосредоточиться на бизнес-логике.
• Enoki / Mysten Demos: Сообщество и Mysten Labs также предоставляют реализации Paymaster с открытым исходным кодом, которые можно использовать в качестве эталона для создания собственного сервиса.

8. Контрольный список реализации​

Готовы обновить свой dApp до безгазовой эры? Пройдите по этому контрольному списку, прежде чем начать:

• Спланируйте поток финансирования: Определите источник финансирования Спонсора, бюджет и стратегию пополнения. Настройте мониторинг и оповещения для ключевых метрик (например, баланс газового пула, скорость потребления).
• Зарезервируйте поля атрибуции: При разработке параметров транзакции обязательно зарезервируйте поля для бизнес-идентификаторов, таких как order_id или user_id.
• Разверните политики борьбы со злоупотреблениями: Вы должны внедрить строгие механизмы авторизации, ограничения скорости и логирования перед запуском.
• Отрепетируйте в Testnet: Независимо от того, создаёте ли вы свой собственный сервис или интегрируете сторонний Gas Station, всегда сначала проводите тщательное тестирование параллелизма и стресс-тестирование в тестовой сети (testnet) или сети разработки (devnet).
• Постоянно оптимизируйте: После запуска постоянно отслеживайте показатели успешности транзакций, причины сбоев и затраты на газ. Корректируйте свой бюджет и стратегии на основе данных.

Заключение​

Sui Paymaster (Gas Station) — это больше, чем просто инструмент для покрытия комиссий за газ для пользователей. Это мощная парадигма, которая элегантно сочетает пользовательский опыт «ноль SUI в сети» с бизнес-потребностью в «атрибуции на уровне заказа в сети» в рамках одной атомарной транзакции. Он открывает путь пользователям Web2 в Web3 и предоставляет разработчикам беспрецедентную гибкость для настройки бизнеса.

С постоянно развивающейся экосистемой инструментов и текущими низкими затратами на газ в сети Sui, сейчас самое подходящее время для обновления платёжных и интерактивных потоков вашего dApp до безгазовой эры.

Как устранить сложности с кошельками, сохранить поток пользователей и спрогнозировать рост

Что, если бы ваше Web3-приложение имело такой же простой процесс регистрации, как и современный Web2-сервис? В этом и заключается основное обещание zkLogin на блокчейне Sui. Он работает как OAuth для Sui, позволяя пользователям входить в систему с помощью знакомых учетных записей Google, Apple, X и других. Доказательство с нулевым разглашением затем надежно связывает эту Web2-личность с ончейн-адресом Sui — без всплывающих окон кошелька, сид-фраз и оттока пользователей.

Эффект реален и ощутим. Учитывая сотни тысяч уже существующих аккаунтов zkLogin, тематические исследования сообщают о значительном росте конверсии пользователей: она подскочила с печальных 17 % до здоровых 42 % после устранения традиционных барьеров в виде кошельков. Давайте разберем, как это работает и что это может дать вашему проекту.

Почему кошельки убивают конверсию новых пользователей​

Вы создали инновационное dApp, но воронка привлечения пользователей дает течь. Виновник почти всегда один и тот же: кнопка «Connect Wallet». Стандартный онбординг в Web3 — это лабиринт из установки расширений, предупреждений о сид-фразах и викторин по крипто-терминологии.

Для новичков это огромный барьер. UX-исследователи зафиксировали ошеломляющий отток в 87 % в тот момент, когда появлялся запрос на подключение кошелька. В показательном эксперименте простое перемещение этого запроса на более поздний этап процесса оформления заказа увеличило процент завершения до 94 %. Даже у пользователей, интересующихся криптовалютой, основной страх заключается в следующем: «Я могу потерять свои средства, если нажму не ту кнопку». Устранение этого единственного пугающего шага является ключом к экспоненциальному росту.

Как работает zkLogin (простыми словами)​

zkLogin изящно обходит проблему кошелька, используя технологии, которым уже доверяет каждый пользователь интернета. Магия происходит за кулисами в несколько быстрых шагов:

1. Эфемерная пара ключей: Когда пользователь хочет войти в систему, в его браузере локально генерируется временная пара ключей для одной сессии. Представьте это как временный ключ доступа, действительный только для этого сеанса.
2. Процесс OAuth: Пользователь входит в систему с помощью своего аккаунта Google, Apple или другой социальной сети. Ваше приложение встраивает уникальное значение (nonce) в этот запрос на вход.
3. ZKP-сервис: После успешного входа сервис ZKP (Zero-Knowledge Proof) генерирует криптографическое доказательство. Это доказательство подтверждает: «Этот токен OAuth авторизует владельца временного ключа», не раскрывая личные данные пользователя в блокчейне.
4. Вычисление адреса: JWT-токен пользователя (JSON Web Token) от OAuth-провайдера объединяется с уникальной солью (salt) для детерминированной генерации их постоянного адреса Sui. Соль хранится в секрете либо на стороне клиента, либо в защищенном бэкенде.
5. Отправка транзакции: Ваше приложение подписывает транзакции временным ключом и прикрепляет ZK-доказательство. Валидаторы Sui проверяют доказательство ончейн, подтверждая легитимность транзакции без необходимости использования традиционного кошелька со стороны пользователя.

Пошаговое руководство по интеграции​

Готовы внедрить это? Вот краткое руководство с использованием TypeScript SDK. Принципы идентичны для Rust или Python.

1. Установите SDK​

Пакет @mysten/sui включает все необходимые вспомогательные функции для zklogin.

pnpm add @mysten/sui

2. Сгенерируйте ключи и Nonce​

Сначала создайте эфемерную пару ключей и nonce, привязанный к текущей эпохе в сети Sui.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. Перенаправление на OAuth​

Сформируйте соответствующий URL-адрес для входа через OAuth для используемого вами провайдера (например, Google, Facebook, Apple) и перенаправьте пользователя.

4. Декодирование JWT и получение соли пользователя​

После того как пользователь войдет в систему и будет перенаправлен обратно, получите id_token из URL. Используйте его для получения специфической для пользователя соли из вашего бэкенда, а затем вычислите его адрес Sui.

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. Запрос ZK-доказательства​

Отправьте JWT сервису-пруверу (prover), чтобы получить ZK-доказательство. Для разработки вы можете использовать публичный прувер от Mysten. В продакшене вам следует развернуть собственный или использовать сервис вроде Enoki.

const proof = await fetch('/api/prove', {
  method:'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. Подписание и отправка​

Теперь создайте транзакцию, установите отправителем zkLogin-адрес пользователя и выполните её. SDK автоматически берет на себя прикрепление zkLoginInputs (доказательства). ✨

const tx = new TransactionBlock();
tx.moveCall({ target:'0x2::example::touch_grass' }); // Любой вызов Move
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof // Магия происходит здесь
});

7. Сохранение сессии​

Для более удобного взаимодействия с пользователем зашифруйте и сохраните пару ключей и соль в IndexedDB или локальном хранилище. Не забывайте менять их каждые несколько эпох для повышения безопасности.

Шаблон прогнозирования KPI​

Разница, которую привносит zkLogin, не просто качественная; она поддается количественной оценке. Сравните типичную воронку адаптации с воронкой на базе zkLogin:

👉 Что это значит: Для кампании, привлекающей 10 000 уникальных посетителей, это разница между 300 ончейн-действиями в первый день и более чем 2 500.

Лучшие практики и нюансы​

Чтобы сделать процесс еще более плавным, примите во внимание эти советы для профессионалов:

• Используйте спонсируемые транзакции (Sponsored Transactions): Оплачивайте комиссии за первые несколько транзакций ваших пользователей. Это устраняет любые трения и создает невероятный вау-эффект.
• Осторожно обращайтесь с солью (Salts): Изменение соли пользователя приведет к генерации нового адреса. Делайте это только в том случае, если у вас есть надежный путь восстановления доступа для них.
• Показывайте адрес Sui: После регистрации покажите пользователям их ончейн-адрес. Это позволит продвинутым пользователям позже импортировать его в традиционный кошелек, если они того пожелают.
• Предотвращайте циклы перезагрузки: Кэшируйте JWT и эфемерную пару ключей до истечения срока их действия, чтобы пользователю не приходилось повторно входить в систему.
• Мониторьте задержку прувера (Prover Latency): Следите за временем цикла генерации доказательства. Если оно превышает 2 секунды, рассмотрите возможность размещения регионального прувера для поддержания высокой скорости работы.

В чем ценность BlockEden.xyz​

В то время как zkLogin совершенствует пользовательский интерфейс, его масштабирование создает новые задачи для бэкенда. Именно здесь на помощь приходит BlockEden.xyz.

• Уровень API: Наши высокопроизводительные RPC-узлы с гео-маршрутизацией гарантируют, что ваши транзакции zkLogin будут обрабатываться с минимальной задержкой, независимо от местоположения пользователя.
• Наблюдаемость: Получите готовые дашборды для отслеживания ключевых показателей, таких как задержка доказательства (proof latency), соотношение успешных и неудачных операций, а также состояние вашей воронки конверсии.
• Комплаенс: Для приложений, работающих с фиатом, наш опциональный модуль KYC обеспечивает легальный он-рамп (on-ramp) напрямую через подтвержденную личность пользователя.

Готовы к запуску?​

Эра неуклюжих и пугающих процессов работы с кошельками закончилась. Запустите песочницу zkLogin, подключите эндпоинт полной ноды от BlockEden и наблюдайте, как график регистраций ползет вверх — при этом вашим пользователям даже не придется слышать слово «кошелек». 😉

На протяжении многих лет криптомир сталкивался с критической проблемой удобства использования: кошельком. Традиционные кошельки, известные как внешние учетные записи (EOA), не прощают ошибок. Одна потерянная сид-фраза означает, что ваши средства исчезнут навсегда. Каждое действие требует подписи, а комиссии за газ должны быть оплачены в нативном токене сети. Этот неуклюжий и рискованный опыт является серьезным препятствием для массового внедрения.

На сцену выходит абстракция учетных записей (AA) — парадигма, призванная переопределить наше взаимодействие с блокчейном. По своей сути, AA превращает учетную запись пользователя в программируемый смарт-контракт, открывая такие функции, как социальное восстановление, транзакции в один клик и гибкие платежи за газ.

Путь к этому более умному будущему разворачивается по трем различным направлениям: проверенный в боях ERC-4337, эффективная нативная AA и долгожданный EIP-7702. Давайте разберем, что каждый подход означает для разработчиков и пользователей.

💡 Путь 1: Пионер — ERC-4337​

ERC-4337 стал прорывом, который принес абстракцию учетных записей в Ethereum и EVM-сети без изменения основного протокола. Думайте об этом как о добавлении интеллектуального слоя поверх существующей системы.

Он вводит новый поток транзакций, включающий:

• UserOperations: новый объект, который представляет намерение пользователя (например, «обменять 100 USDC на ETH»).
• Бандлеры: внесетевые участники, которые собирают UserOperations, объединяют их и отправляют в сеть.
• EntryPoint: глобальный смарт-контракт, который проверяет и выполняет объединенные операции.

Преимущества:

• Универсальная совместимость: может быть развернут в любой EVM-сети.
• Гибкость: позволяет использовать богатые функции, такие как сеансовые ключи для игр, мультиподписная безопасность и спонсирование газа через Paymasters.

Компромисс:

• Сложность и стоимость: он вводит значительные накладные расходы на инфраструктуру (запуск бандлеров) и имеет самые высокие затраты на газ из трех подходов, поскольку каждая операция проходит через дополнительную логику EntryPoint. Из-за этого его внедрение процветало в основном в L2-сетях с низкими комиссиями за газ, таких как Base и Polygon.

ERC-4337 проложил путь для других решений AA. Он доказал спрос и заложил основу для более интуитивного опыта Web3.

🚀 Путь 2: Интегрированный идеал — нативная абстракция учетных записей​

Если ERC-4337 является дополнением, то нативная AA встраивает интеллектуальные функции непосредственно в основу блокчейна. Такие сети, как zkSync Era и Starknet, были разработаны с нуля с AA в качестве основного принципа. В этих сетях каждая учетная запись является смарт-контрактом.

Преимущества:

• Эффективность: интегрируя логику AA в протокол, она устраняет дополнительные слои, что приводит к значительно более низким затратам на газ по сравнению с ERC-4337.
• Простота для разработчиков: разработчикам не нужно управлять бандлерами или отдельным мемпулом. Поток транзакций ощущается гораздо более стандартным.

Компромисс:

• Фрагментация экосистемы: нативная AA специфична для каждой сети. Учетная запись в zkSync отличается от учетной записи в Starknet, и ни одна из них не является нативной для основной сети Ethereum. Это создает фрагментированный опыт для пользователей и разработчиков, работающих в нескольких сетях.

Нативная AA показывает нам «конечную цель» для эффективности, но ее внедрение связано с ростом ее хост-экосистем.

🌉 Путь 3: Прагматичный мост — EIP-7702​

EIP-7702, который должен быть включен в обновление Ethereum «Pectra» в 2025 году, является революционным изменением, призванным предоставить функции AA массам существующих пользователей EOA. Он использует гибридный подход: он позволяет EOA временно делегировать свои полномочия смарт-контракту для одной транзакции.

Думайте об этом как о предоставлении вашему EOA временных сверхспособностей. Вам не нужно переносить свои средства или менять адрес. Ваш кошелек может просто добавить авторизацию к транзакции, позволяя ей выполнять пакетные операции (например, одобрить + обменять в один клик) или спонсировать свой газ.

Преимущества:

• Обратная совместимость: работает с миллиардами долларов, защищенных существующими EOA. Миграция не требуется.
• Низкая сложность: использует стандартный пул транзакций, устраняя необходимость в бандлерах и значительно упрощая инфраструктуру.
• Катализатор массового внедрения: сделав интеллектуальные функции доступными для каждого пользователя Ethereum в одночасье, он может быстро ускорить внедрение лучших шаблонов UX.

Компромисс:

• Не «полная» AA: EIP-7702 не решает проблему управления ключами для самого EOA. Если вы потеряете свой приватный ключ, вам все равно не повезет. Речь идет скорее об улучшении возможностей транзакций, чем о капитальном ремонте безопасности учетных записей.

Сравнение: четкое сопоставление​

Будущее конвергентно и ориентировано на пользователя​

Эти три пути не исключают друг друга; они сходятся к будущему, где кошелек больше не является источником трений.

1. Социальное восстановление становится стандартом 🛡️: Эпоха «потерянных ключей, потерянных средств» заканчивается. AA позволяет восстанавливать данные на основе хранителей, делая самостоятельное хранение таким же безопасным и прощающим, как традиционный банковский счет.
2. Переосмысление UX в играх 🎮: Сеансовые ключи позволят беспрепятственно играть без постоянных всплывающих окон «подтвердить транзакцию», наконец-то сделав игры Web3 похожими на игры Web2.
3. Кошельки как программируемые платформы: Кошельки станут модульными. Пользователи могут добавить «модуль DeFi» для автоматического фарминга доходности или «модуль безопасности», который требует двухфакторной аутентификации (2FA) для крупных переводов.

Для разработчиков и поставщиков инфраструктуры, таких как Blockeden.xyz, эта эволюция невероятно увлекательна. Сложность бандлеров, Paymasters и различных стандартов AA создает огромную возможность для предоставления надежной, стабильной и абстрагированной инфраструктуры. Цель состоит в унифицированном опыте, когда разработчик может легко интегрировать функции AA, а кошелек интеллектуально использует ERC-4337, нативную AA или EIP-7702 под капотом, в зависимости от того, что поддерживает сеть.

Кошелек наконец-то получает заслуженное обновление. Переход от статических EOA к динамическим, программируемым смарт-аккаунтам — это не просто улучшение, это революция, которая сделает Web3 доступным и безопасным для следующего миллиарда пользователей.

Приветствуем вас снова в нашем блокчейн-блоге! Сегодня мы погрузимся в захватывающее новое предложение под названием ERC-4337, которое внедряет абстракцию аккаунтов в Ethereum, не требуя никаких изменений протокола на уровне консенсуса. Вместо этого, это предложение опирается на инфраструктуру более высокого уровня для достижения своих целей. Давайте рассмотрим, что предлагает ERC-4337 и как оно устраняет ограничения текущей экосистемы Ethereum.

Что такое ERC-4337?​

ERC-4337 — это предложение, которое внедряет абстракцию аккаунтов в Ethereum посредством использования отдельного мемпула и нового типа псевдотранзакционного объекта, называемого UserOperation. Пользователи отправляют объекты UserOperation в альтернативный мемпул, где специальный класс участников, называемых бандлерами (bundlers), упаковывает их в транзакцию, вызывающую handleOps для выделенного контракта. Затем эти транзакции включаются в блок.

Предложение направлено на достижение нескольких целей:

1. Предоставить пользователям возможность использовать кошельки смарт-контрактов с произвольной логикой верификации в качестве своих основных аккаунтов.
2. Полностью устранить необходимость для пользователей иметь внешне принадлежащие аккаунты (EOA).
3. Обеспечить децентрализацию, позволяя любому бандлеру участвовать в процессе включения абстрагированных аккаунтов пользовательских операций.
4. Позволить всей активности происходить через публичный мемпул, устраняя необходимость для пользователей знать прямые адреса связи конкретных участников.
5. Избежать предположений о доверии к бандлерам.
6. Избежать необходимости каких-либо изменений консенсуса Ethereum для более быстрого внедрения.
7. Поддерживать другие варианты использования, такие как приложения, сохраняющие конфиденциальность, атомарные мульти-операции, оплата комиссий за транзакции токенами ERC-20 и транзакции, спонсируемые разработчиками.

Обратная совместимость​

Поскольку ERC-4337 не изменяет уровень консенсуса, прямых проблем с обратной совместимостью для Ethereum нет. Однако аккаунты, созданные до ERC-4337, нелегко совместимы с новой системой, поскольку им не хватает необходимой функции validateUserOp. Это можно решить, создав совместимый с ERC-4337 аккаунт, который повторно реализует логику верификации в качестве обертки и устанавливает его как доверенного отправителя операций исходного аккаунта.

Эталонная реализация​

Для тех, кто заинтересован в более глубоком изучении технических деталей ERC-4337, эталонная реализация доступна по адресу https://github.com/eth-infinitism/account-abstraction/tree/main/contracts.

Соображения безопасности​

Контракт точки входа для ERC-4337 должен быть тщательно проверен аудитом и формально верифицирован, поскольку он служит центральной точкой доверия для всей системы. Хотя такой подход снижает нагрузку на аудит и формальную верификацию для отдельных аккаунтов, он концентрирует риски безопасности в контракте точки входа, который должен быть надежно верифицирован.

Верификация должна охватывать два основных утверждения:

1. Безопасность от произвольного захвата: Точка входа вызывает аккаунт обобщенно только в том случае, если validateUserOp для этого конкретного аккаунта был успешно выполнен.
2. Безопасность от истощения комиссий: Если точка входа вызывает validateUserOp и он проходит, она также должна выполнить обобщенный вызов с calldata, равным op.calldata.

Заключение​

ERC-4337 — это захватывающее предложение, которое направлено на внедрение абстракции аккаунтов в Ethereum, не требуя изменений протокола на уровне консенсуса. Используя инфраструктуру более высокого уровня, оно открывает новые возможности для децентрализации, гибкости и различных вариантов использования. Хотя существуют соображения безопасности, которые необходимо учесть, это предложение имеет потенциал значительно улучшить экосистему Ethereum и пользовательский опыт.