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

Практично кожен, хто користувався гаманцем на блокчейні, стикався з цією проблемою: на рахунку є безліч токенів, але через недостатню кількість Gas транзакція не може бути виконана. На основних EVM-сумісних публічних блокчейнах плата за Gas обов'язково має сплачуватися рідним токеном блокчейну, новим користувачам потрібно додатково отримати рідний токен, щоб ініціювати взаємодію, а плата за Gas динамічно коливається в залежності від завантаженості мережі блокчейну, що ускладнює користувачам точне прогнозування фактичних витрат на комісії до підтвердження транзакції. Це є однією з основних перешкод для широкомасштабного впровадження Web3.

У цій статті буде проаналізовано існуючі основні рішення для плати за Gas у галузі Web3, а також буде розглянуто нове рішення публічного блокчейну 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) Компенсація після: звичайні моделі оплати включають повне спонсорство, коли проект повністю покриває витрати на 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, успадковуючи базову здатність Arc до оплати Gas стабільними монетами, основна інновація полягає в зворотному використанні існуючого механізму перевірки чорного списку. Створено реєстр SponsorRegistry, який у поєднанні з ідентифікаційними сертифікатами SBT завершує контроль доступу користувачів, реалізуючи логіку стягнення та допуску до транзакцій.

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

SponsorRegistry є попередньо розгорнутим основним контрактом, що слугує глобальним "меню тарифів на Gas", зберігаючи кілька конфігурацій для обліку Gas. Розташування даних зберігання суворо закріплене, код виконання на Rust безпосередньо читає дані через слот зберігання.

// SponsorRegistry.sol —— Розташування "заморожене", обробник читає безпосередньо за слотом, порядок не можна змінювати
struct GasPlan {
    address token;
    uint256 feePerTx;
    address feeBeneficiary;
}
address public multisig;                        // слот 0
mapping(uint256 => GasPlan) public plans;       // слот 1: planId → пакет
mapping(address => uint256) public sourcePlan;  // слот 2: SBT → планId, що може бути наданий
mapping(address => uint256) public userPlan;    // слот 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 викличе panic
    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 — інакше це означатиме, що кожна транзакція друкує гроші.

Тут користувач сплачує фіксовану суму конкретним токеном, що не залежить від фактичних витрат на обчислення. Це налаштування підвищує базову плату по всьому ланцюгу, при цьому зростаюча плата за 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) Повторне використання механізму, повторне використання шляху виконання зберігання чорного списку, зворотне перетворення в контроль доступу за ідентичністю, максимально можливе повторне використання існуючої базової кодової структури.

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

Цей контент надано лише для загальних інформаційних цілей і не є фінансовою, інвестиційною, юридичною чи податковою консультацією. Події, нагороди, онлайн-акцій або пов’язану інформацію, згадана тут, не слід розглядати як рекомендацію, прохання чи запрошення до купівлі, продажу, торгівлі чи інших операцій з криптоактивами. Криптоактиви є дуже волатильними та можуть призвести до збитків. Доступність послуг, продуктів WEEX та пов’язаних із ними подій може відрізнятися залежно від регіону. Ви несете відповідальність за забезпечення відповідності вашої участі чинному місцевому законодавству та нормативним актам.