Tuven Chain: Nowe rozwiązanie problemu płatności za opłaty Gas i analiza związanych z tym ryzyk bezpieczeństwa

Prawie każdy, kto korzystał z portfela na blockchainie, napotkał ten problem: w portfelu jest mnóstwo tokenów, chcesz dokonać przelewu lub interakcji z inteligentnym kontraktem, ale transakcja kończy się niepowodzeniem z powodu niewystarczających opłat Gas. W głównych publicznych łańcuchach kompatybilnych z EVM, opłaty za transakcje Gas są obowiązkowo płacone w natywnych tokenach łańcucha, co oznacza, że nowi użytkownicy muszą dodatkowo zdobyć natywne tokeny łańcucha, aby móc rozpocząć interakcję. Ponadto opłaty Gas dynamicznie zmieniają się w zależności od stopnia zatłoczenia sieci blockchain, co sprawia, że użytkownicy nie mogą dokładnie przewidzieć rzeczywistych kosztów transakcji przed jej potwierdzeniem. To jest jedna z głównych przeszkód w masowym przyjęciu Web3.

Artykuł ten analizuje istniejące główne rozwiązania dotyczące opłat Gas w branży Web3 oraz przedstawia nową propozycję łańcucha publicznego Tuven Chain z perspektywy logiki technicznej, innowacji architektonicznych i potencjalnych ryzyk, aby dostarczyć odniesienia dla programistów zajmujących się rozwojem łańcuchów publicznych oraz audytorów bezpieczeństwa.

1. Główne rozwiązania dotyczące opłat Gas

1.1 Mechanizm Paymaster w ERC-4337 (abstrakcja konta)

Paymaster to specjalny kontrakt zdefiniowany w ramach ERC-4337, który umożliwia płatność za opłaty Gas w imieniu użytkownika podczas wykonywania operacji użytkownika (UserOperation). Dzięki temu użytkownicy nie muszą posiadać natywnych tokenów łańcucha podczas wysyłania transakcji, co obniża próg wejścia dla nowych użytkowników. Kluczowy proces płatności Gas wygląda następująco:

1. Użytkownik inicjuje operację: Użytkownik podpisuje i przesyła operację użytkownika (UserOperation) w inteligentnym portfelu.
2. Pakowanie i weryfikacja: Bundler zbiera wiele operacji i przesyła je do kontraktu Paymaster oraz kontraktu wejściowego (Entrypoint).
3. Interwencja Paymastera: Kontrakt Paymaster weryfikuje, czy zgadza się na pokrycie opłat Gas za tę operację.
4. Rozliczenie opłat: Transakcja jest wykonywana na łańcuchu, a Entrypoint pobiera natywne tokeny (np. ETH) z konta depozytowego Paymastera jako opłatę Gas.
5. Rekompensata po fakcie: Typowe modele płatności obejmują pełne sponsorowanie, gdzie projekt całkowicie pokrywa 100% opłat Gas dla nowych użytkowników lub określonych wydarzeń; płatności tokenami, gdzie użytkownicy nie mają natywnych tokenów (np. ETH), ale mogą używać USDT lub USDC z portfela do opłacenia Gas, a Paymaster automatycznie dokonuje wymiany w tle; oraz płatności warunkowe, gdzie projekt ustala zasady, aby płatności były dostępne tylko dla użytkowników posiadających określone NFT, wykonujących określone zadania lub korzystających z określonych tokenów w aplikacji.

Ograniczeniem tego rozwiązania jest to, że zwykłe konta zewnętrzne (EOA) nie mogą go bezpośrednio używać, a użytkownicy muszą przejść na portfele z abstrakcją konta.

1.2 Meta-transakcje i model pośredników

To kolejne rozwiązanie w blockchainie, które ma na celu obniżenie progu wejścia dla użytkowników, umożliwiając "brak opłat Gas" lub pokrycie opłat górniczych. Meta-transakcje polegają na tym, że użytkownik nie wysyła transakcji bezpośrednio do blockchaina, lecz podpisuje "metadane" zawierające intencje operacyjne i dane poza łańcuchem za pomocą klucza prywatnego. Pośrednik zbiera podpisy użytkowników poza łańcuchem, samodzielnie inicjuje rzeczywiste transakcje na łańcuchu i płaci opłaty Gas, a następnie rozgłasza transakcje do blockchaina. Kluczowy proces wygląda następująco:

1. Użytkownik podpisuje: Użytkownik lokalnie podpisuje intencje (np. przelew, wywołanie kontraktu), nie zużywając żadnych opłat Gas na łańcuchu.
2. Przesyłanie usług poza łańcuchem: Użytkownik przesyła podpis i dane do pośrednika (może to być serwer DApp lub usługa zewnętrzna).
3. Pakowanie przez pośrednika: Pośrednik pakuje ten podpis w prawdziwą transakcję na łańcuchu, podpisuje ją swoim portfelem i płaci opłaty Gas.
4. Weryfikacja przez inteligentny kontrakt: Docelowy inteligentny kontrakt odbiera transakcję, analizuje i weryfikuje oryginalny podpis użytkownika, a po potwierdzeniu wykonuje odpowiednią logikę.

Jednak to rozwiązanie wiąże się z ryzykiem centralizacji i atakami powtórzeniowymi: jeśli pośrednik ulegnie awarii lub celowo odrzuci żądania niektórych użytkowników, użytkownicy nie będą mogli wysyłać transakcji; a pośrednik może zobaczyć intencje transakcyjne użytkowników, co może prowadzić do wyścigu transakcji. Jeśli podpis użytkownika zostanie przechwycony przez atakującego, a kontrakt nie ma weryfikacji Nonce i ChainID, może to prowadzić do ataków powtórzeniowych.

Powyższe rozwiązania nie wprowadziły bezpośrednich zmian w logice rozliczeń na poziomie konsensusu łańcucha. Tuven Chain stara się zmodyfikować logikę wykonawczą, aby umożliwić płatności stałymi kwotami opłat Gas w niestandardowych tokenach, bez konieczności zmiany zwykłych portfeli czy modyfikacji aplikacji.

2. Kluczowa logika realizacji Tuven Chain

Tuven Chain jest forkowany z łańcucha Arc firmy Circle, dziedzicząc podstawową zdolność płatności Gas w stabilnych tokenach, a kluczowa innowacja polega na odwrotnym wykorzystaniu istniejącego mechanizmu weryfikacji czarnej listy. Zbudowano rejestr SponsorRegistry, który w połączeniu z certyfikatem tożsamości SBT realizuje kontrolę dostępu użytkowników oraz logikę pobierania opłat i dostępu do transakcji.

2.1 Kluczowe komponenty SponsorRegistry.sol / sponsor_registry.rs

SponsorRegistry to wstępnie wdrożony kluczowy kontrakt, który działa jako globalny "cennik opłat Gas", przechowujący wiele zestawów konfiguracji opłat Gas. Układ przechowywania danych jest ściśle ustalony, a kod Rust na poziomie wykonawczym bezpośrednio odczytuje dane przez sloty przechowywania.

// SponsorRegistry.sol — Układ został "zamrożony", handler odczytuje bezpośrednio przez slot, kolejność nie może być zmieniana
struct GasPlan { address token; uint256 feePerTx; address feeBeneficiary; }
address public multisig;                        // slot 0
mapping(uint256 => GasPlan) public plans;       // slot 1: planId → zestaw
mapping(address => uint256) public sourcePlan;  // slot 2: SBT → przypisany planId
mapping(address => uint256) public userPlan;    // slot 3: posiadacz → planId (0=nie w zestawie)
// Jedyny punkt zapisu: autoryzowany SBT dodaje/usuwa adres z listy
function setSponsored(address who, bool on) external {    uint256 plan = sourcePlan[msg.sender];      // Wywołujący musi być autoryzowanym SBT    if (plan == 0) revert NotAuthorizedSource();    userPlan[who] = on ? plan : 0;              // on=na liście; off=czyszczenie 0}
// Rust: sponsor_registry.rs — Wykonanie odczytu według【dokładnie tego samego】układu, obie strony testują krzyżowo blokady
const PLANS_MAPPING_SLOT=1; const USER_PLAN_MAPPING_SLOT=3; // Adres: keccak256(key . slot)

Gdzie plans[planId] = { token, za który płacimy, feePerTx, ile płacimy, feeBeneficiary, kto otrzymuje płatność }. Podczas rozliczenia Tuven Chain najpierw sprawdza, do jakiego zestawu należy użytkownik; jeśli nie jest w zestawie (userPlan[ty]==0), płaci standardowo natywnym stabilnym tokenem USDX; jeśli jest w zestawie, płaci tokenem określonym w zestawie. Należy zauważyć, że USDX jest kontraktem stabilnym Circle, ale prawa do emisji/zatrzymania/wstrzymania są w rękach operatora, co jest oddzielone od rzeczywistego USDC. Jego "stabilność" wynika z polityki operatora, a nie z rezerw.

2.2 Modyfikacja logiki pobierania opłat na poziomie wykonawczym

// handler.rs
// Symulacja "czarnej listy": dla tabeli zestawów wykonujemy "niepomiarowy SLOAD", decydując, którą walutą płacić za każdą transakcję
fn charge_sponsored_gas(&self, evm, caller) -> Result<bool> { 
    journal.load_account(SPONSOR_REGISTRY_ADDRESS)?;  // Najpierw podgrzewamy, w przeciwnym razie zimny odczyt SLOAD spowoduje panikę
    let plan_id = sload(REG, compute_user_plan_slot(caller))?; 
    if plan_id.is_zero() { return Ok(false); }  // Nie w zestawie → płacimy standardowo USDX
    let token = sload(REG, compute_plan_slot(plan_id, PLAN_TOKEN_OFFSET))?; 
    if token.is_zero() { return Err(GAS_PLAN_UNCONFIGURED); }  // Zestaw nie skonfigurowany → odrzucamy, brak zabezpieczenia
    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); }  // Niewystarczająca ilość tokenów członkowskich → odrzucamy
    sstore(token, caller_slot, bal - fee)?;  // Pobieramy stałą opłatę: członek płaci sam
    sstore(token, benef_slot,  benef_bal + fee)?;  // Przekazujemy płatność feeBeneficiary (niezwiązane z gazem)
    Ok(true)  // true = płatność tokenem członkowskim, USDX całkowicie zwolnione
}
// pre_execution tworzy wstępną płatność USDX, aby oryginalna weryfikacja przeszła; reward_beneficiary jest następnie odejmowane,
// a beneficjentowi nie przypisuje się USDX — w przeciwnym razie oznaczałoby to, że każda transakcja generuje dodatkowe pieniądze.

Tutaj użytkownik płaci stałą kwotę w określonym tokenie za każdą transakcję, niezależnie od rzeczywistego zużycia mocy obliczeniowej. To ustawienie podnosi podstawową opłatę na całym łańcuchu, a wzrost opłat Gas jest przerzucany na użytkowników standardowych USDX (niezwiązanych z zestawem), co w rzeczywistości obciąża tych użytkowników.

2.3 Odznaka tożsamości SoulboundToken.sol / DeployUserland.s.sol

// SoulboundToken.sol — Nieprzenośna "odznaka tożsamości" (ERC-5192)
function issue(address to, uint256 id, string uri) external onlyIssuer {     _safeMint(to, id);  registry.setSponsored(to, true);   // Wydanie odznaki automatycznie dodaje do listy zestawów}
function revoke(uint256 id) external onlyIssuer {     address owner = ownerOf(id);  _burn(id);     registry.setSponsored(owner, false);  // Cofnięcie odznaki automatycznie usuwa z listy}
// Dozwolone tylko mint(from=0)/burn(to=0), wszelkie inne transfery są blokowane → nie można przenieść ani sprzedać
function _update(...) internal override returns (address) {      if (from != address(0) && to != address(0)) revert Soulbound(); ...}
// DeployUserland.s.sol — Przekazanie władzy zarządzającej do multisig (1-of-2 to redundancja klucza prywatnego, a nie równowaga)
registry.setSourcePlan(address(sbt), PLAN_ID);   // Autoryzacja SBT do powiązania z planem 1
registry.setMultisig(address(multisig));          // admin przekazuje zarządzanie multisig
// Ryzyko: feeSigner domyślnie ustawiony na admina (skarb i zarządzanie mają ten sam klucz prywatny)

Tuven Chain wykorzystuje istniejący mechanizm czarnej listy Arc, łącząc go z certyfikatem tożsamości SBT w celu realizacji kontroli dostępu użytkowników. Cechy tego rozwiązania można podsumować następująco:

1. Natywna wielowalutowa zdolność płatności Gas: w przeciwieństwie do górnych rozwiązań kontraktowych, logika rozliczeń jest przeniesiona na poziom konsensusu wykonawczego, wspierając równoległe zestawy, co pozwala różnym użytkownikom o różnych tożsamościach na płacenie opłat transakcyjnych różnymi niestandardowymi tokenami;
2. Model stałej opłaty transakcyjnej: oddzielony od tradycyjnego modelu wyceny "cena Gas × zużycie obliczeniowe", umożliwiający wcześniejsze poznanie opłat transakcyjnych;
3. Wysoka kompatybilność z istniejącą infrastrukturą: nie wymaga inteligentnych kont ani modyfikacji DApp, portfele EOA, takie jak MetaMask, mogą bezpośrednio interagować;
4. Wykorzystanie istniejących mechanizmów: wykorzystanie istniejącej ścieżki wykonawczej do odczytu czarnej listy, przekształcone w kontrolę dostępu tożsamości, maksymalnie wykorzystując istniejące ramy kodu.

Jednak powyższa wygoda opiera się na wielu nowych założeniach dotyczących zaufania, a zmiany w jądrze, projektowaniu uprawnień, modelu ekonomicznym i komponentach międzyłańcuchowych mogą wiązać się z ryzykiem. W szczególności pierwotna semantyka czarnej listy została zmieniona, a logika blokowania, która pierwotnie dotyczyła tylko scenariuszy przelewów, została rozszerzona na wywołania zwykłych kontraktów, co zmienia granice logiki. Specyficzne logiki pobierania opłat za tokeny w zestawie wymagają niezależnego audytu bezpieczeństwa, aby upewnić się, że odczyty i zapisy w pamięci, a także obliczenia sald są wolne od luk, aby uniknąć poważnych konsekwencji, takich jak anomalie transakcyjne, rozdzielenie konsensusu łańcucha czy nieprawidłowe pobieranie aktywów.