Tuven Chain: Neue Lösungen für das Problem der Gasgebührenzahlung und Analyse der damit verbundenen Sicherheitsrisiken

Fast jeder, der schon einmal eine On-Chain-Wallet verwendet hat, ist auf dieses Problem gestoßen: Ein Konto mit vielen Token, aber aufgrund unzureichender Gasgebühren schlägt die Transaktion fehl, wenn man eine Überweisung tätigen oder mit einem Smart Contract interagieren möchte. In den gängigen EVM-kompatiblen Public Chains ist es zwingend erforderlich, die Gasgebühren mit dem nativen Token der Chain zu bezahlen. Neue Benutzer müssen zusätzliche native Tokens erwerben, um Interaktionen zu initiieren, und die Gasgebühren schwanken dynamisch je nach Auslastung des Blockchain-Netzwerks. Vor der Bestätigung der Transaktion können Benutzer die tatsächlichen Transaktionskosten nicht genau vorhersagen, was eines der Haupthemmnisse für die breite Akzeptanz von Web3 darstellt.

Dieser Artikel analysiert die bestehenden gängigen Lösungen für Gasgebühren im Web3-Sektor und bietet eine Analyse des neuen Ansatzes der RWA Public Chain Tuven Chain aus den Perspektiven der technischen Implementierungslogik, architektonischen Innovationen und potenziellen Risiken, um Entwicklern von Public Chains und Sicherheitsprüfern als Referenz zu dienen.

1. Gängige Lösungen für Gasgebühren

1.1 ERC-4337 (Account Abstraction) Paymaster-Zahlungsmechanismus

Der Paymaster ist ein spezieller Vertrag, der im ERC-4337-Rahmen definiert ist und es ermöglicht, die Gasgebühren im Namen des Benutzers zu bezahlen, wenn eine UserOperation ausgeführt wird. Dadurch müssen Benutzer beim Senden von Transaktionen keine nativen Coins der Chain halten, was die Einstiegshürde für neue Benutzer senkt. Der Kernprozess der Gaszahlung ist wie folgt:

(1) Benutzer initiiert die Operation: Der Benutzer signiert und reicht eine UserOperation in der Smart Wallet ein.

(2) Verpacken und Verifizieren: Der Bundler sammelt mehrere Operationen und sendet sie an den Paymaster-Vertrag und den Entrypoint-Vertrag.

(3) Paymaster greift ein: Der Paymaster-Vertrag überprüft, ob er bereit ist, die Gasgebühren für diese Operation zu bezahlen.

(4) Gebührenabrechnung: Die Transaktion wird on-chain ausgeführt, der Entrypoint zieht native Tokens (z.B. ETH) vom Depotkonto des Paymasters als Gasgebühren ab.

(5) Nachträgliche Entschädigung: Gängige Modelle für die Kostenübernahme umfassen die vollständige Finanzierung, bei der das Projektteam die Gasgebühren vollständig für neue Benutzer oder bestimmte Aktivitäten übernimmt; Token-Zahlungen, bei denen Benutzer keine nativen Tokens (z.B. ETH) haben, aber mit USDT oder USDC aus ihrer Wallet Gas bezahlen können, wobei der Paymaster im Hintergrund automatisch umtauscht; und bedingte Zahlungen, bei denen das Projektteam Regeln festlegt, die nur für Benutzer gelten, die bestimmte NFTs besitzen, bestimmte Aufgaben abgeschlossen haben oder bestimmte In-App-Token verwenden.

Die Einschränkung dieses Ansatzes besteht darin, dass normale externe Konten (EOA) ihn nicht direkt nutzen können; Benutzer müssen auf eine Account-Abstraction-Wallet umsteigen oder diese aufrüsten.

1.2 Meta-Transaktionen und Relayer-Modell

Dies ist eine weitere Lösung in der Blockchain, um die Einstiegshürde für Benutzer zu senken und "Gasgebührenfrei" oder die Übernahme der Miner-Gebühren zu ermöglichen. Bei Meta-Transaktionen sendet der Benutzer die Transaktion nicht direkt an die Blockchain, sondern signiert offline mit seinem privaten Schlüssel eine "Meta-Daten"-Nachricht, die die beabsichtigte Operation und Daten enthält. Der Relayer ist dafür verantwortlich, die off-chain Signaturen der Benutzer zu sammeln, selbst als tatsächlicher Initiator der on-chain Transaktion aufzutreten und die Gasgebühren zu bezahlen, um die Transaktion an die Blockchain zu übermitteln. Der Kernprozess ist wie folgt:

(1) Benutzer signiert: Der Benutzer signiert lokal die Absicht (z.B. Überweisung, Vertragsaufruf), ohne Gas on-chain zu verbrauchen.

(2) Einreichung an den Off-Chain-Service: Der Benutzer sendet die Signatur und Daten an den Relayer (dies kann der offizielle Server der DApp oder ein Drittanbieterdienst sein).

(3) Relayer verpackt: Der Relayer verpackt diese Signatur zu einer echten on-chain Transaktion, signiert sie mit seinem Wallet-Konto und bezahlt die Gasgebühren.

(4) Smart Contract verifiziert: Der Ziel-Smart Contract empfängt die Transaktion, analysiert und verifiziert die ursprüngliche Signatur des Benutzers und führt die entsprechende Logik aus, wenn alles korrekt ist.

Dieser Ansatz birgt jedoch Risiken der Zentralisierung und Replay-Angriffe: Wenn der Relayer ausfällt oder absichtlich Anfragen bestimmter Benutzer ablehnt, können Benutzer keine Transaktionen senden; außerdem kann der Relayer die Absicht der Benutzer sehen und diese Informationen möglicherweise für Front-Running-Transaktionen nutzen. Wenn die Signatur des Benutzers von einem Angreifer erlangt wird und der Vertrag keine Überprüfung von Nonce und ChainID durchführt, kann dies zu Replay-Angriffen führen.

Die oben genannten Lösungen haben die Abrechnungslogik nicht direkt auf der Konsens-Ebene der Chain modifiziert. Tuven Chain versucht, durch Änderungen an der zugrunde liegenden Ausführungslogik eine benutzerdefinierte Token-Zahlung für feste Gasgebühren zu ermöglichen, ohne die normalen Wallets oder Anwendungen zu ändern, d.h. die Ersetzung der Gebührenwährung und die Preisbindung zu erreichen.

2. Kernimplementierungslogik von Tuven Chain

Tuven Chain ist ein Fork der Arc-Chain von Circle und erbt die grundlegende Fähigkeit zur Gaszahlung mit Stablecoins von Arc. Die Kerninnovation besteht darin, den bestehenden Blacklist-Überprüfungsmechanismus umzukehren. Es wird ein SponsorRegistry-Register erstellt, das zusammen mit SBT-Identitätsnachweisen die Benutzerzugangssteuerung ermöglicht und die Abrechnung und den Zugang zu Transaktionen verwaltet. 2.1 Kernkomponenten SponsorRegistry.sol / sponsor_registry.rs

SponsorRegistry ist der vorab bereitgestellte Kernvertrag, der als globale "Gasgebühren-Paketliste" fungiert und mehrere Gasabrechnungskonfigurationen speichert. Die Datenablage ist streng fixiert, und der Ausführungsschicht-Rust-Code liest die Daten direkt über den Speicher-Slot.

// SponsorRegistry.sol —— Layout ist "eingefroren", handler liest direkt nach Slot, die Reihenfolge darf nicht verändert werden
struct GasPlan { address token; uint256 feePerTx; address feeBeneficiary; }
address public multisig;                        // slot 0
mapping(uint256 => GasPlan) public plans;       // slot 1: planId → Paket
mapping(address => uint256) public sourcePlan;  // slot 2: SBT → zugewiesene planId
mapping(address => uint256) public userPlan;    // slot 3: Inhaber → planId (0=nicht im Paket )
// Einziger Schreibzugang: autorisierte SBT für eine Adresse auf die Liste setzen / entfernen
function setSponsored(address who, bool on) external {    uint256 plan = sourcePlan[msg.sender];      // Der Aufrufer muss ein autorisierter SBT sein    if (plan == 0) revert NotAuthorizedSource();    userPlan[who] = on ? plan : 0;              // on=auf die Liste setzen; off=löschen 0}
// Rust: sponsor_registry.rs —— Ausführungsschicht liest nach【genau demselben】Layout, beide Seiten testen sich gegenseitig
const PLANS_MAPPING_SLOT=1;
const USER_PLAN_MAPPING_SLOT=3; // Adresse: keccak256(key . slot)

Dabei ist plans[planId] = { token, mit welcher Währung , feePerTx, wie viel pro Transaktion , feeBeneficiary, wer erhält }. Bei der Abrechnung prüft Tuven Chain zunächst, welcher Pakettyp der Benutzer hat. Wenn er nicht im Paket ist (userPlan[du]==0), wird wie gewohnt mit dem nativen Stablecoin USDX bezahlt; wenn er im Paket ist, wird mit dem im Paket angegebenen Token bezahlt. Es ist zu beachten, dass USDX ein Stablecoin-Vertrag von Circle ist, aber die Prägung / Einfrierung / Aussetzung der Kontrolle durch den Betreiber erfolgt und von echtem USDC isoliert ist. Seine "Stabilität" stammt von der Strategie des Betreibers und nicht von einer Reserveunterstützung.

2.2 Modifikation der Abrechnungslogik der Ausführungsschicht

(handler.rs)// Nachahmung der "Blacklist": Durchführung eines "nicht messbaren SLOAD" auf der Paketliste, um zu entscheiden, welche Währung pro Transaktion verwendet wird
fn charge_sponsored_gas(&self, evm, caller) -> Result<bool> {      journal.load_account(SPONSOR_REGISTRY_ADDRESS)?;  // Zuerst vorheizen, sonst kaltes Lesen SLOAD wird panic      let plan_id = sload(REG, compute_user_plan_slot(caller))?;      if plan_id.is_zero() { return Ok(false); }      // Nicht im Paket → wie gewohnt USDX bezahlen      let token = sload(REG, compute_plan_slot(plan_id, PLAN_TOKEN_OFFSET))?;      if token.is_zero() { return Err(GAS_PLAN_UNCONFIGURED); }  // Paket nicht konfiguriert → ablehnen, keine Rückendeckung      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); }      // Mitgliedswährung nicht ausreichend → ablehnen      sstore(token, caller_slot, bal - fee)?;           // Feste Gebühr abziehen: Mitglied selbst trägt die Kosten      sstore(token, benef_slot,  benef_bal + fee)?;      // Gebühr an feeBeneficiary (unabhängig von Gas) buchen      Ok(true)                                          // true = mit Mitgliedswährung bezahlt, USDX vollständig erlassen  }
// pre_execution erstellt eine USDX-Vorauszahlung, damit die native Überprüfung erfolgreich ist; reward_beneficiary wird dann zurückgebucht, // und es wird dem beneficiary nicht USDX gutgeschrieben — andernfalls würde es bedeuten, dass Geld ohne Grund gedruckt wird.

Hier wird von jedem Benutzer pro Transaktion ein fester Betrag in einer bestimmten Währung abgezogen, unabhängig davon, wie viel Rechenleistung tatsächlich verbraucht wurde. Diese Einstellung erhöht die Grundgebühren der gesamten Chain, wobei die gestiegenen Gasgebühren von normalen USDX (nicht Paket) Benutzern getragen werden, was die Kosten tatsächlich auf diese Benutzer abwälzt.

2.3 Identitätsabzeichen SoulboundToken.sol / DeployUserland.s.sol

// SoulboundToken.sol —— Nicht übertragbares "Identitätsabzeichen" (ERC-5192)
function issue(address to, uint256 id, string uri) external onlyIssuer {      _safeMint(to, id);  registry.setSponsored(to, true);   // Bei der Ausgabe sofort auf die Paketliste setzen}
function revoke(uint256 id) external onlyIssuer {      address owner = ownerOf(id);  _burn(id);      registry.setSponsored(owner, false);                     // Bei der Rücknahme sofort von der Liste entfernen}
// Nur Mint(from=0)/burn(to=0) erlaubt, alle anderen Übertragungen werden blockiert → nicht übertragbar, nicht verkäuflich
function _update(...) internal override returns (address) {      if (from != address(0) && to != address(0)) revert Soulbound(); ...}
// DeployUserland.s.sol —— Verwaltung an Multisig übergeben (1-von-2 ist Schlüsselredundanz, nicht Machtbalance)
registry.setSourcePlan(address(sbt), PLAN_ID);   // SBT 1 zuweisen
registry.setMultisig(address(multisig));         // Admin an Multisig übergeben
// Risiko: feeSigner ist nicht explizit gesetzt, standardmäßig = Admin-Signer (Tresor und Verwaltung sind dasselbe Schlüsselpaar)

Tuven Chain hat den bestehenden Blacklist-Mechanismus von Arc wiederverwendet und kombiniert ihn mit SBT-Identitätsnachweisen zur Benutzerzugangssteuerung. Die Merkmale des Ansatzes lassen sich zusammenfassen als:

(1) Native Multi-Token-Gas-Zahlungsfähigkeit der Chain, die sich von den oben genannten Vertragszahlungsansätzen unterscheidet, indem die Abrechnungslogik in die Konsens-Ausführungsschicht integriert wird, mehrere Pakete parallel unterstützt und verschiedene Benutzer mit unterschiedlichen benutzerdefinierten Tokens zur Zahlung von Gebühren befähigt;

(2) Festes Gebührenmodell pro Transaktion, das sich von dem traditionellen Preismodell "Gas-Preis × Rechenverbrauch" löst und die Transaktionsgebühren im Voraus bekannt macht;

(3) Hohe Kompatibilität mit bestehenden Infrastrukturen, keine Smart Accounts oder DApp-Änderungen erforderlich, normale EOA-Wallets wie MetaMask können direkt interagieren;

(4) Mechanismuswiederverwendung, der die Ausführungspfade der bestehenden Blacklist-Speicherlesung wiederverwendet und umkehrt, um eine positive Identitätskontrolle zu schaffen, wobei der vorhandene Code-Rahmen so weit wie möglich wiederverwendet wird.

Die oben genannten Annehmlichkeiten basieren jedoch auf einer Vielzahl neuer Vertrauensannahmen. Änderungen am zugrunde liegenden Kern, an der Berechtigungsstruktur, am Wirtschaftsmodell und an den Cross-Chain-Komponenten können Risiken bergen. Die ursprüngliche Bedeutung der Blacklist wurde geändert, und die ursprünglich nur für Überweisungsszenarien geltende Abfanglogik wurde auf normale Vertragsaufrufe ausgeweitet, wodurch sich die logischen Grenzen geändert haben. Die spezifische Gebührenabwicklung mit Paket-Token ist eine neu entwickelte Geschäftslogik, die einer unabhängigen Sicherheitsprüfung bedarf, um sicherzustellen, dass es keine Schwachstellen bei der Speicherung, dem Lesen und Schreiben sowie der Berechnung von Salden gibt, um schwerwiegende Folgen wie Transaktionsanomalien, Blockchain-Konsensgabeln und unerwartete Vermögensabzüge zu vermeiden.

Dieser Inhalt wird nur zu allgemeinen Informationszwecken bereitgestellt und stellt keine finanzielle, Anlage-, Rechts- oder Steuerberatung dar. Alle erwähnten Ereignisse, Prämien, Online-Aktionen oder zugehörige Informationen sollten nicht als Empfehlung, Aufforderung oder Einladung zum Kauf, Verkauf, Handel oder anderweitigem Umgang mit Krypto-Assets betrachtet werden. Krypto-Assets sind sehr volatil und können zu Verlusten führen. Die Verfügbarkeit von WEEX Services, Produkten und zugehörigen Aktionen kann je nach Region unterschiedlich sein. Sie sind dafür verantwortlich sicherzustellen, dass Ihre Teilnahme mit geltenden lokalen Gesetzen und Vorschriften übereinstimmt.