Tuven Chain: Новое решение проблемы оплаты Gas и анализ связанных рисков безопасности

Почти каждый, кто использовал кошелек на блокчейне, сталкивался с этой проблемой: в аккаунте много токенов, но из-за недостатка Gas-топлива транзакция не может быть выполнена. На основных публичных блокчейнах, совместимых с EVM, плата за Gas обязательно должна быть оплачена с использованием родного токена сети, и новым пользователям необходимо дополнительно получить родной токен, чтобы инициировать взаимодействие. Кроме того, плата за Gas динамически колеблется в зависимости от загруженности сети блокчейна, и пользователи не могут точно предсказать фактические затраты на комиссию до подтверждения транзакции. Это является одним из основных препятствий для массового внедрения Web3.

В данной статье будет проанализировано существующее решение проблемы платы за Gas в индустрии Web3, а также будет рассмотрено новое решение RWA публичной цепи Tuven Chain с точки зрения технической реализации, архитектурных инноваций и потенциальных рисков, чтобы предоставить справочную информацию для разработчиков публичных цепей и специалистов по безопасности.

1. Основные решения по оплате Gas

1.1 Механизм Paymaster в ERC-4337 (абстракция аккаунта)

Paymaster — это специальный контракт, определенный в рамках ERC-4337, который позволяет оплачивать Gas от имени пользователя во время выполнения UserOperation. Таким образом, пользователям не нужно держать родные токены сети при отправке транзакций, что снижает порог входа для новых пользователей. Основной рабочий процесс оплаты Gas:

(1) Пользователь инициирует операцию: пользователь подписывает и отправляет операцию (UserOperation) в умном кошельке.

(2) Упаковка и верификация: Bundler (упаковщик) собирает несколько операций и отправляет их в контракт Paymaster и контракт Entrypoint.

(3) Вмешательство Paymaster: контракт Paymaster проверяет, согласен ли он оплатить Gas за эту операцию.

(4) Расчет затрат: транзакция выполняется в сети, Entrypoint вычитает родные токены (например, ETH) из депозитного счета Paymaster в качестве платы за Gas.

(5) Возмещение: распространенные модели оплаты включают полное спонсирование, когда проект полностью покрывает 100% платы за Gas для новых пользователей или определенных мероприятий; оплата токенами, когда у пользователя нет родных токенов сети (например, ETH), но он может использовать USDT или USDC из своего кошелька для оплаты Gas, а Paymaster автоматически обменивает их в фоновом режиме; и условная оплата, когда проект устанавливает правила, позволяя оплачивать только пользователям, которые владеют определенными NFT, выполнили определенные задачи или используют определенные токены в приложении.

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

1.2 Модель мета-транзакций и релееров

Это еще одно решение, используемое в блокчейне для снижения порога входа для пользователей и реализации "без Gas" или оплаты комиссий для майнеров. Мета-транзакции означают, что пользователь не отправляет транзакцию напрямую в блокчейн, а подписывает "метаданные" сообщение, содержащее намерение и данные, вне сети с помощью своего приватного ключа. Релеер отвечает за сбор подписей пользователей вне сети, выступая в качестве инициатора фактической транзакции в блокчейне и оплачивая Gas, распространяя транзакцию в блокчейне. Основной рабочий процесс выглядит следующим образом:

(1) Подпись пользователя: пользователь локально подписывает намерение (например, перевод, вызов контракта), не расходуя никакого Gas.

(2) Отправка в службу вне сети: пользователь отправляет подпись и данные релееру (это может быть официальный сервер DApp или сторонний сервис).

(3) Упаковка релеером: релеер упаковывает эту подпись в настоящую транзакцию в блокчейне, подписывает ее своим кошельком и оплачивает Gas.

(4) Верификация умным контрактом: целевой умный контракт получает транзакцию, анализирует и проверяет оригинальную подпись пользователя, и, если все верно, выполняет соответствующую логику.

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

Вышеуказанные решения не изменяют логику расчета комиссий на уровне консенсуса блокчейна. Tuven Chain пытается изменить базовую логику выполнения, чтобы реализовать оплату фиксированной суммы Gas с использованием настраиваемых токенов, не меняя обычные кошельки и не модифицируя приложения, то есть завершить замену валюты комиссии и фиксирование цен.

2. Основная логика реализации Tuven Chain

Tuven Chain является форком цепи Arc компании Circle, унаследовав базовые возможности оплаты Gas с использованием стабильных монет Arc, а основная инновация заключается в обратном использовании существующего механизма проверки черного списка. Создание реестра SponsorRegistry, в сочетании с удостоверениями SBT, завершает контроль доступа пользователей и логику списания и допуска к транзакциям.

2.1 Основные компоненты SponsorRegistry.sol / sponsor_registry.rs

SponsorRegistry — это предустановленный основной контракт, который служит глобальной "таблицей тарифов на Gas", хранящей несколько конфигураций тарификации Gas. Структура хранения данных строго фиксирована, код на Rust на уровне выполнения напрямую считывает данные через хранилище Slot.

// SponsorRegistry.sol — структура "заморожена", обработчик считывает напрямую по slot, порядок не может быть изменен
struct GasPlan { address token; uint256 feePerTx; address feeBeneficiary; }
address public multisig;                        // slot 0
mapping(uint256 => GasPlan) public plans;       // slot 1: planId → тариф
mapping(address => uint256) public sourcePlan;  // slot 2: SBT → разрешенный planId
mapping(address => uint256) public userPlan;    // slot 3: владелец → planId (0=не в тарифе)
// Единственная точка записи: авторизованный SBT добавляет/удаляет адрес из списка
function setSponsored(address who, bool on) external {
    uint256 plan = sourcePlan[msg.sender];      // вызывающий должен быть авторизованным SBT
    if (plan == 0) revert NotAuthorizedSource();
    userPlan[who] = on ? plan : 0;              // on=добавить в список; off=очистить 0
}
// Rust: sponsor_registry.rs — уровень выполнения считывает по【полностью идентичной】структуре, обе стороны перекрестно тестируют
const PLANS_MAPPING_SLOT=1;
const USER_PLAN_MAPPING_SLOT=3; // адрес: keccak256(key . slot)

В этом случае plans[planId] = { token — какой токен использовать, feePerTx — сколько брать за каждую транзакцию, feeBeneficiary — кто получает }. При расчете Tuven Chain сначала проверяет, к какому тарифу принадлежит пользователь; если он не в тарифе (userPlan[вы]==0), то он платит родной стабильный токен USDX; если в тарифе, то платит токен, указанный в тарифе. Следует отметить, что USDX является контрактом стабильной монеты Circle, но права на эмиссию/заморозку/приостановку находятся у оператора и изолированы от реального USDC. Его "стабильность" зависит от стратегии оператора, а не от резервного обеспечения.

2.2 Изменение логики списания на уровне выполнения

(handler.rs)// Подобно "черному списку": для таблицы тарифов выполняется "неизмеряемый SLOAD", по каждой транзакции определяется, какой токен использовать для оплаты
fn charge_sponsored_gas(&self, evm, caller) -> Result<bool> {
    journal.load_account(SPONSOR_REGISTRY_ADDRESS)?;  // сначала прогреваем, иначе холодное чтение SLOAD вызовет панику
    let plan_id = sload(REG, compute_user_plan_slot(caller))?;
    if plan_id.is_zero() { return Ok(false); }  // не в тарифе → платим как обычно USDX
    let token = sload(REG, compute_plan_slot(plan_id, PLAN_TOKEN_OFFSET))?;
    if token.is_zero() { return Err(GAS_PLAN_UNCONFIGURED); }  // тариф не настроен → отказ, нет подстраховки
    let fee = sload(REG, compute_plan_slot(plan_id, PLAN_FEE_OFFSET))?;
    let bal = sload(token, compute_erc20_balance_slot(caller))?;
    if bal < fee { return Err(INSUFFICIENT_GAS_TOKEN); }  // недостаточно токенов для оплаты → отказ
    sstore(token, caller_slot, bal - fee)?;          // списываем фиксированную плату: платит сам член
    sstore(token, benef_slot,  benef_bal + fee)?;  // записываем для feeBeneficiary (не связано с gas)
    Ok(true)  // true = оплачено токенами члена, USDX полностью освобожден
}
// pre_execution формирует предоплату USDX, чтобы родная проверка прошла;
// reward_beneficiary затем возвращает, и не записывает USDX для beneficiary — иначе это будет равно печати денег.

Здесь пользователь платит фиксированную сумму определенным токеном за каждую транзакцию, что не зависит от фактической вычислительной нагрузки. Эта настройка повышает базовую плату по всей цепи, и увеличенные расходы на Gas оплачиваются обычными пользователями USDX (не в тарифе), фактически перекладывая затраты на этих пользователей.

2.3 Идентификационный значок SoulboundToken.sol / DeployUserland.s.sol

// SoulboundToken.sol — не подлежащий передаче "идентификационный значок" (ERC-5192)
function issue(address to, uint256 id, string uri) external onlyIssuer {
    _safeMint(to, id);
    registry.setSponsored(to, true);   // выдача значка сразу добавляет в тарифный список
}
function revoke(uint256 id) external onlyIssuer {
    address owner = ownerOf(id);
    _burn(id);
    registry.setSponsored(owner, false);             // отзыв значка сразу удаляет из списка
}
// Разрешены только mint(from=0)/burn(to=0), все остальные переводы блокируются → нельзя передать, продать
function _update(...) internal override returns (address) {
    if (from != address(0) && to != address(0)) revert Soulbound(); ...
}
// DeployUserland.s.sol — передача управления многофакторной подписи (1 из 2 — это избыточность ключа, а не сдерживание)
registry.setSourcePlan(address(sbt), PLAN_ID);   // авторизация SBT для привязки к тарифу 1
registry.setMultisig(address(multisig));          // администратор передает управление многофакторной подписи
// Риск: feeSigner по умолчанию не установлен, = администратор подписывает (казначейство и администратор — один и тот же ключ)

Tuven Chain повторно использует существующий механизм черного списка Arc, сочетая его с удостоверениями SBT для завершения контроля доступа пользователей. Характеристики их решения можно резюмировать следующим образом:

(1) Встроенная много-токеновая возможность оплаты Gas, в отличие от схемы оплаты на уровне контрактов, логика тарификации опускается до уровня консенсуса, поддерживая несколько тарифов одновременно, разные пользователи могут использовать разные настраиваемые токены для оплаты комиссий;

(2) Модель фиксированной комиссии за транзакцию, отделяющаяся от традиционной модели "цена Gas × вычислительная нагрузка", что позволяет заранее знать комиссию за транзакцию;

(3) Высокая совместимость с существующей инфраструктурой, не требующая умных аккаунтов и модификации DApp, обычные EOA кошельки, такие как MetaMask, могут взаимодействовать напрямую;

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

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