24 Beiträge getaggt mit „Sui“

Als Mysten Labs bekannt gab, dass sein Walrus-Protokoll im März 2025 140 Millionen $von Standard Crypto, a16z und Franklin Templeton gesichert hat, sandte dies eine klare Botschaft: Die Kriege um dezentralen Speicher treten in eine neue Phase ein. Doch was macht Walrus in einer Landschaft, die bereits von Filecoins Unternehmensambitionen und Arweaves Versprechen für permanenten Speicher bevölkert ist, so anders, dass eine Bewertung von 2 Milliarden$ vor dem ersten Betriebstag gerechtfertigt ist?

Die Antwort liegt in einer grundlegenden Neugestaltung der Funktionsweise von dezentralem Speicher.

Das Speicherproblem, das niemand gelöst hat​

Dezentraler Speicher war das ständig ungelöste Problem von Web3. Benutzer wünschen sich die Zuverlässigkeit von AWS gepaart mit der Zensurresistenz der Blockchain, aber bestehende Lösungen haben schmerzhafte Kompromisse erzwungen.

Filecoin, der größte Akteur mit einer Marktkapitalisierung, die bis 2025 stark schwankte, erfordert, dass Benutzer Speicher-Deals mit Anbietern aushandeln. Wenn diese Verträge auslaufen, könnten Ihre Daten verschwinden. Die Netzwerkauslastung im dritten Quartal 2025 erreichte 36 % – eine Verbesserung gegenüber 32 % im Vorquartal –, lässt jedoch weiterhin Fragen zur Effizienz im großen Maßstab offen.

Arweave bietet permanenten Speicher mit seinem „Pay once, store forever“-Modell an, aber diese Permanenz hat ihren Preis. Das Speichern von Daten auf Arweave kann 20-mal teurer sein als auf Filecoin bei gleicher Kapazität. Für Anwendungen, die Terabytes an Benutzerdaten verarbeiten, geht die wirtschaftliche Rechnung einfach nicht auf.

IPFS wiederum ist eigentlich gar kein Speicher – es ist ein Protokoll. Ohne „Pinning“-Dienste, die Ihre Daten am Leben erhalten, verschwinden Inhalte, sobald Knoten sie aus ihrem Cache löschen. Es ist, als würde man ein Haus auf einem Fundament bauen, das jederzeit umziehen könnte.

In diese fragmentierte Landschaft tritt Walrus, und seine Geheimwaffe ist die Mathematik.

RedStuff: Der technische Durchbruch​

Im Kern von Walrus steht RedStuff, ein zweidimensionales Erasure-Coding-Protokoll, das eine echte Innovation in der Entwicklung verteilter Systeme darstellt. Um zu verstehen, warum dies wichtig ist, muss man betrachten, wie herkömmlicher dezentraler Speicher mit Redundanz umgeht.

Vollständige Replikation – das Speichern mehrerer kompletter Kopien auf verschiedenen Knoten – ist einfach, aber ineffizient. Um sich gegen byzantinische Fehler zu schützen, bei denen bis zu ein Drittel der Knoten bösartig sein könnte, ist eine umfangreiche Duplizierung erforderlich, was die Kosten in die Höhe treibt.

Eindimensionales Erasure Coding, wie die Reed-Solomon-Kodierung, teilt Dateien in Fragmente mit Paritätsdaten zur Rekonstruktion auf. Das ist effizienter, hat aber eine kritische Schwäche: Die Wiederherstellung eines einzigen verlorenen Fragments erfordert das Herunterladen von Datenmengen, die der gesamten Originaldatei entsprechen. In dynamischen Netzwerken mit häufigem Knotenwechsel (Churn) führt dies zu Bandbreitenengpässen, welche die Leistung massiv beeinträchtigen.

RedStuff löst dies durch matrixbasierte Kodierung, die sowohl primäre als auch sekundäre „Slivers“ (Splitter) erzeugt. Wenn ein Knoten ausfällt, können die verbleibenden Knoten fehlende Daten rekonstruieren, indem sie nur das herunterladen, was tatsächlich verloren gegangen ist – nicht das gesamte Blob. Die Wiederherstellungsbandbreite skaliert mit O(|blob|/n) anstatt mit O(|blob|), ein Unterschied, der bei großen Datenmengen enorm ins Gewicht fällt.

Das Protokoll erreicht Sicherheit mit einer nur 4,5-fachen Replikation, verglichen mit der 10- bis 30-fachen Replikation, die bei simpleren Ansätzen erforderlich ist. Laut der eigenen Analyse des Walrus-Teams führt dies zu Speicherkosten, die etwa 80 % niedriger als bei Filecoin und bis zu 99 % niedriger als bei Arweave für eine gleichwertige Datenverfügbarkeit sind.

Vielleicht am wichtigsten ist, dass RedStuff das erste Protokoll ist, das Speicherherausforderungen (Storage Challenges) in asynchronen Netzwerken unterstützt. Dies verhindert, dass Angreifer Netzwerkverzögerungen ausnutzen, um Verifizierungen zu bestehen, ohne die Daten tatsächlich zu speichern – eine Sicherheitslücke, die frühere Systeme plagte.

Das 140-Millionen-$-Vertrauensvotum​

Die Finanzierungsrunde, die im März 2025 abgeschlossen wurde, spricht für sich. Standard Crypto führte die Runde an, unter Beteiligung des Krypto-Arms von a16z, Electric Capital und Franklin Templeton Digital Assets. Besonders bemerkenswert ist das Engagement von Franklin Templeton – wenn einer der weltweit größten Vermögensverwalter Blockchain-Infrastruktur unterstützt, signalisiert dies eine institutionelle Überzeugung, die über typische Krypto-Venture-Deals hinausgeht.

Der Token-Verkauf bewertete den WAL-Token-Vorrat bei vollständiger Verwässerung mit 2 Milliarden $. Zum Vergleich: Filecoin – mit jahrelangem Betrieb und einem etablierten Ökosystem – handelt mit einer Marktkapitalisierung, die erhebliche Volatilität aufwies und im Oktober 2025 dramatisch einbrach, bevor sie sich erholte. Der Markt wettet darauf, dass sich die technischen Vorteile von Walrus in eine bedeutende Akzeptanz verwandeln werden.

Die WAL-Tokenomics spiegeln die Lehren aus früheren Projekten wider. Der Gesamtvorrat von 5 Milliarden Token umfasst eine Zuteilung von 10 % für Benutzeranreize, mit einem anfänglichen Airdrop von 4 % und weiteren 6 %, die für zukünftige Verteilungen reserviert sind. Deflationäre Mechanismen bestrafen kurzfristige Stake-Verschiebungen mit teilweisen Burns, während Slashing-Strafen für leistungsschwache Speicherknoten die Netzwerkintegrität schützen.

Die Token-Freischaltungen (Unlocks) sind strategisch gestaffelt: Die Zuteilungen für Investoren beginnen erst im März 2026 mit der Freischaltung, ein volles Jahr nach dem Mainnet-Start. Dies reduziert den Verkaufsdruck während der kritischen Phase der frühen Akzeptanz.

Reale Akzeptanz​

Seit dem Start des Mainnets am 27. März 2025 hat Walrus über 120 Projekte angezogen und beherbergt 11 Websites, die vollständig auf dezentraler Infrastruktur laufen. Dies ist keine Vaporware – es ist der produktive Einsatz.

Decrypt, das bekannte Web3-Medienunternehmen, hat damit begonnen, Inhalte auf Walrus zu speichern. TradePort, der größte NFT-Marktplatz auf Sui, nutzt das Protokoll für dynamische NFT-Metadaten und ermöglicht so komponierbare, erweiterbare digitale Assets, die mit statischen Speicherlösungen nicht möglich waren.

Die Anwendungsfälle gehen über die einfache Dateispeicherung hinaus. Walrus kann als kostengünstiger Data Availability Layer für Rollups dienen, bei denen Sequenzer Transaktionen hochladen und Executoren diese nur vorübergehend zur Verarbeitung rekonstruieren müssen. Dies positioniert Walrus als Infrastruktur für das modulare Blockchain-Konzept, das die jüngste Entwicklung dominiert hat.

KI-Anwendungen stellen eine weitere Grenze dar. Saubere Trainingsdatensätze, Modellgewichte und Nachweise für korrektes Training können alle mit verifizierter Herkunft gespeichert werden – entscheidend für eine Branche, die sich mit Fragen der Datenauthentizität und Modellauditierung auseinandersetzt.

Die Landschaft der „Storage Wars“​

Walrus tritt in einen Markt ein, der laut Fundamental Business Insights bis 2034 voraussichtlich 6,53 Milliarden $ erreichen wird, mit einem jährlichen Wachstum von über 21 %. Dieses Wachstum wird durch zunehmende Bedenken hinsichtlich des Datenschutzes, steigende Cyberbedrohungen und regulatorischen Druck getrieben, der Unternehmen zu Alternativen zum zentralisierten Cloud-Speicher drängt.

Die Wettbewerbspositionierung sieht günstig aus. Filecoin zielt mit seinem Deal-basierten Modell auf Enterprise-Workloads ab. Arweave besitzt den Bereich der permanenten Speicherung für Archive, rechtliche Dokumente und die Bewahrung von Kulturgut. Storj bietet S3-kompatiblen Objektspeicher mit Festpreisen an (0,004 $ pro GB monatlich, Stand Anfang 2025).

Walrus besetzt die Nische für hochverfügbaren, kosteneffizienten Speicher, der die On-Chain- und Off-Chain-Welten verbindet. Die Integration in Sui bietet einen natürlichen Entwicklerfluss, aber die Speicherschicht ist technisch chain-agnostisch – Anwendungen, die auf Ethereum, Solana oder anderswo aufgebaut sind, können für Off-Chain-Speicherung angedockt werden.

Der gesamte adressierbare Markt für dezentrale Speicherung bleibt ein Bruchteil der breiteren Cloud-Speicherindustrie, die im Jahr 2025 mit 255 Milliarden $bewertet wurde und bis 2032 voraussichtlich 774 Milliarden$ erreichen wird. Selbst die Erfassung eines kleinen Prozentsatzes dieser Migration würde ein massives Wachstum bedeuten.

Technischer Deep Dive in die Architektur​

Die Architektur von Walrus trennt Steuerung und Metadaten (die auf Sui laufen) von der eigentlichen Speicherschicht. Diese Aufteilung ermöglicht es dem Protokoll, die Fast Finality von Sui für die Koordination zu nutzen, während die Speicheragnostik gewahrt bleibt.

Wenn ein Benutzer einen Blob speichert, werden die Daten einer RedStuff-Kodierung unterzogen und in Slivers aufgeteilt, die über die Speicher-Nodes für diese Epoche verteilt werden. Jeder Node verpflichtet sich, die zugewiesenen Slivers zu speichern und bereitzustellen. Die wirtschaftlichen Anreize werden durch Staking abgestimmt – Nodes müssen Sicherheiten hinterlegen, die bei schlechter Leistung oder Datenunverfügbarkeit gekürzt (Slashing) werden können.

Die Datenresilienz ist außergewöhnlich: Walrus kann Informationen selbst dann wiederherstellen, wenn zwei Drittel der Speicher-Nodes ausfallen oder feindselig agieren. Diese byzantinische Fehlertoleranz übertrifft die Anforderungen der meisten Produktionssysteme.

Das Protokoll enthält authentifizierte Datenstrukturen zur Abwehr böswilliger Clients, die versuchen, das Netzwerk zu korrumpieren. In Kombination mit dem asynchronen Storage-Challenge-System entsteht ein Sicherheitsmodell, das robust gegen die Angriffsvektoren ist, die frühere dezentrale Speichersysteme gefährdet haben.

Was schiefgehen könnte​

Keine Technologieanalyse ist vollständig ohne die Untersuchung von Risiken. Walrus steht vor mehreren Herausforderungen:

Konkurrenz durch etablierte Akteure: Filecoin verfügt über jahrelange Ökosystementwicklung und Geschäftsbeziehungen zu Unternehmen. Arweave besitzt Markenbekanntheit in der Nische der permanenten Speicherung. Die Verdrängung etablierter Akteure erfordert nicht nur bessere Technologie, sondern auch einen besseren Vertrieb.

Sui-Abhängigkeit: Obwohl die Speicherschicht technisch chain-agnostisch ist, bedeutet die enge Integration mit Sui, dass das Schicksal von Walrus teilweise an den Erfolg dieses Ökosystems gebunden ist. Wenn Sui keine Mainstream-Adoption erreicht, verliert Walrus seinen primären Entwickler-Funnel.

Tokenomics in der Praxis: Die deflationären Mechanismen und Staking-Strafen sehen auf dem Papier gut aus, aber das reale Verhalten weicht oft von theoretischen Modellen ab. Der Investor-Unlock im März 2026 wird der erste große Test für die Preisstabilität von WAL sein.

Regulatorische Unsicherheit: Dezentrale Speicherung befindet sich in verschiedenen Gerichtsbarkeiten in regulatorischen Grauzonen. Wie Behörden Data Availability Layer behandeln – insbesondere solche, die potenziell sensible Inhalte speichern – bleibt unklar.

Das Fazit​

Walrus stellt eine echte technische Innovation in einem Bereich dar, der sie dringend nötig hatte. Die zweidimensionale Erasure-Coding-Technologie von RedStuff ist keine Marketing-Differenzierung – es ist ein bedeutender architektonischer Fortschritt, der durch veröffentlichte Forschungsergebnisse untermauert wird.

Die Finanzierung in Höhe von 140 Millionen $ durch glaubwürdige Investoren, die schnelle Akzeptanz im Ökosystem und die durchdachte Tokenomics deuten darauf hin, dass dieses Projekt über den typischen Krypto-Hype-Zyklus hinaus Bestand hat. Ob es bedeutende Marktanteile von etablierten Wettbewerbern gewinnen kann, bleibt abzuwarten, aber die Voraussetzungen für eine ernsthafte Herausforderung sind gegeben.

Für Entwickler, die Anwendungen erstellen, die eine zuverlässige, erschwingliche und dezentrale Datenspeicherung benötigen, verdient Walrus eine ernsthafte Evaluierung. Die „Storage Wars“ haben einen neuen Mitstreiter, und dieser ist mit besserer Mathematik bewaffnet.

Bauen Sie auf Sui oder erkunden Sie dezentrale Speicherlösungen für Ihre Web3-Anwendung? BlockEden.xyz bietet RPC-Infrastruktur der Enterprise-Klasse und API-Dienste an, die sich nahtlos in aufstrebende Ökosysteme integrieren lassen. Erkunden Sie unseren API-Marktplatz, um Ihr nächstes Projekt mit einer Infrastruktur voranzutreiben, die für die dezentrale Zukunft entwickelt wurde.

Datenschutz wird zur öffentlichen Infrastruktur. Im Jahr 2025 benötigen Entwickler Tools, die Verschlüsselung so einfach machen wie Datenspeicherung. Mysten Labs' Seal bietet genau das – dezentrales Geheimnismanagement mit On-Chain-Zugriffskontrolle. Dieses Tutorial zeigt Ihnen, wie Sie sichere Web3-Anwendungen mithilfe von identitätsbasierter Verschlüsselung, Schwellenwertsicherheit und programmierbaren Zugriffsrichtlinien erstellen.

Einführung: Warum Seal für Web3 wichtig ist​

Traditionelle Cloud-Anwendungen verlassen sich auf zentralisierte Schlüsselverwaltungssysteme, bei denen ein einziger Anbieter den Zugriff auf verschlüsselte Daten kontrolliert. Obwohl dies bequem ist, schafft es gefährliche Single Points of Failure. Wenn der Anbieter kompromittiert wird, offline geht oder den Zugriff einschränkt, werden Ihre Daten unzugänglich oder anfällig.

Seal ändert dieses Paradigma vollständig. Von Mysten Labs für die Sui Blockchain entwickelt, ist Seal ein dezentraler Geheimnismanagement-Dienst (DSM), der Folgendes ermöglicht:

• Identitätsbasierte Verschlüsselung, bei der Inhalte geschützt werden, bevor sie Ihre Umgebung verlassen
• Schwellenwertverschlüsselung, die den Schlüsselzugriff auf mehrere unabhängige Nodes verteilt
• On-Chain-Zugriffskontrolle mit Zeitsperren, Token-Gating und benutzerdefinierter Autorisierungslogik
• Speicherunabhängiges Design, das mit Walrus, IPFS oder jeder anderen Speicherlösung funktioniert

Egal, ob Sie sichere Messaging-Apps, zugangsgeschützte Inhaltsplattformen oder zeitgesperrte Asset-Transfers erstellen, Seal bietet die kryptografischen Primitive und die Infrastruktur zur Zugriffskontrolle, die Sie benötigen.

Erste Schritte​

Voraussetzungen​

Bevor Sie eintauchen, stellen Sie sicher, dass Sie Folgendes haben:

• Node.js 18+ installiert
• Grundkenntnisse in TypeScript/JavaScript
• Eine Sui Wallet zum Testen (z. B. Sui Wallet)
• Verständnis von Blockchain-Konzepten

Installation​

Installieren Sie das Seal SDK via npm:

npm install @mysten/seal

Sie benötigen auch das Sui SDK für Blockchain-Interaktionen:

npm install @mysten/sui

Projekteinrichtung​

Erstellen Sie ein neues Projekt und initialisieren Sie es:

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

Erstellen Sie eine einfache TypeScript-Konfiguration:

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

Kernkonzepte: Wie Seal funktioniert​

Bevor wir Code schreiben, lassen Sie uns die Architektur von Seal verstehen:

1. Identitätsbasierte Verschlüsselung (IBE)​

Im Gegensatz zur traditionellen Verschlüsselung, bei der Sie auf einen öffentlichen Schlüssel verschlüsseln, ermöglicht Ihnen IBE die Verschlüsselung auf eine Identität (wie eine E-Mail-Adresse oder Sui-Adresse). Der Empfänger kann nur entschlüsseln, wenn er nachweisen kann, dass er diese Identität kontrolliert.

2. Schwellenwertverschlüsselung​

Anstatt einem einzelnen Schlüsselserver zu vertrauen, verwendet Seal t-von-n Schwellenwertschemata. Sie könnten 3 von 5 Schlüsselservern konfigurieren, was bedeutet, dass beliebige 3 Server zusammenarbeiten können, um Entschlüsselungsschlüssel bereitzustellen, aber 2 oder weniger dies nicht können.

3. On-Chain-Zugriffskontrolle​

Zugriffsrichtlinien werden durch Sui Smart Contracts durchgesetzt. Bevor ein Schlüsselserver Entschlüsselungsschlüssel bereitstellt, überprüft er, ob der Anfragende die On-Chain-Richtlinienanforderungen (Token-Besitz, Zeitbeschränkungen usw.) erfüllt.

4. Schlüsselserver-Netzwerk​

Verteilte Schlüsselserver validieren Zugriffsrichtlinien und generieren Entschlüsselungsschlüssel. Diese Server werden von verschiedenen Parteien betrieben, um keinen Single Point of Control zu gewährleisten.

Grundlegende Implementierung: Ihre erste Seal-Anwendung​

Erstellen wir eine einfache Anwendung, die sensible Daten verschlüsselt und den Zugriff über Sui Blockchain-Richtlinien steuert.

Schritt 1: Seal Client initialisieren​

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
  // Initialize Sui client for testnet
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // Configure Seal client with testnet key servers
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // 2-of-3 threshold
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

Schritt 2: Einfache Verschlüsselung/Entschlüsselung​

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
  const { sealClient } = await createSealClient();

  // Data to encrypt
  const sensitiveData = "This is my secret message!";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // Encrypt data for a specific Sui address
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // Optional: add metadata
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('Encrypted data:', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // Later, decrypt the data (requires proper authorization)
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('Decrypted data:', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('Encryption/decryption failed:', error);
  }
}

basicExample();

Zugriffskontrolle mit Sui Smart Contracts​

Die wahre Stärke von Seal liegt in der programmierbaren Zugriffskontrolle. Erstellen wir ein Beispiel für eine zeitgesperrte Verschlüsselung, bei der Daten erst nach einer bestimmten Zeit entschlüsselt werden können.

Schritt 1: Zugriffssteuerungs-Vertrag bereitstellen​

Zuerst benötigen wir einen Move Smart Contract, der unsere Zugriffsrichtlinie definiert:

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

Schritt 2: Mit Seal integrieren​

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // Create access policy on Sui
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // Unlock in 1 minute
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: 'time_lock::policy::create_time_lock',
    arguments: [
      txb.pure(unlockTime),
      txb.pure(authorizedUser)
    ]
  });

  // Execute transaction to create policy
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // Your Sui keypair
  });

  const policyId = result.objectChanges?.find(
    change => change.type === 'created'
  )?.objectId;

  // Now encrypt with this policy
  const sensitiveData = "This will unlock in 1 minute!";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, 'utf-8'),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: 'time_lock'
    }
  });

  console.log('Time-locked data created. Try decrypting after 1 minute.');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

Praktische Beispiele​

Beispiel 1: Sichere Messaging-Anwendung​

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID()
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
      recipientId: recipientAddress,
      metadata: {
        type: 'secure_message',
        sender: senderKeypair.toSuiAddress()
      }
    });

    // Store encrypted message on decentralized storage (Walrus)
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // Retrieve from storage
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Decrypt with Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    return JSON.parse(decryptedData.toString('utf-8'));
  }

  private async storeOnWalrus(data: any) {
    // Integration with Walrus storage
    // This would upload the encrypted data to Walrus
    // and return the blob ID for retrieval
  }

  private async retrieveFromWalrus(blobId: string) {
    // Retrieve encrypted data from Walrus using blob ID
  }
}

Beispiel 2: Token-Gated Content-Plattform​

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any
  ) {
    // Create NFT ownership policy
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // Encrypt content with NFT access requirement
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // Special recipient for NFT holders
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // Verify NFT ownership first
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('Access denied: Required NFT not found');
    }

    // Decrypt content
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

    return decryptedContent.toString('utf-8');
  }

  private async createNftPolicy(collection: string, creator: any) {
    // Create Move contract that checks NFT ownership
    // Returns policy object ID
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // Check if user owns required NFT
    // Query Sui for NFT ownership
  }
}

Beispiel 3: Zeitgesperrter Asset-Transfer​

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any
) {
  const { sealClient, suiClient } = await createSealClient();

  // Create time-lock policy on Sui
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // Encrypt asset transfer data
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID()
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: 'time_lock'
    }
  });

  console.log(`Asset locked until ${new Date(unlockTimestamp)}`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    const transferData = JSON.parse(decryptedData.toString('utf-8'));

    // Process the asset transfer
    console.log('Asset transfer unlocked:', transferData);

    return transferData;
  } catch (error) {
    console.error('Transfer not yet unlocked or access denied:', error);
    throw error;
  }
}

Integration mit Walrus Dezentralem Speicher​

Seal funktioniert nahtlos mit Walrus, Suis dezentraler Speicherlösung. So integrieren Sie beide:

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any
  ) {
    // Encrypt with Seal
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy
    });

    // Store encrypted data on Walrus
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // Return reference that includes both Seal and Walrus info
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any
  ) {
    // Retrieve from Walrus
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // Decrypt with Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });

    return decryptedData;
  }
}

// Usage example
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from('Important document content');
  const recipientAddress = '0x...';

  // Store encrypted
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('Stored with Blob ID:', result.blobId);

  // Later, retrieve and decrypt
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('Retrieved data:', decrypted.toString());
}

Schwellenwertverschlüsselung: Erweiterte Konfiguration​

Für Produktionsanwendungen möchten Sie eine benutzerdefinierte Schwellenwertverschlüsselung mit mehreren Schlüsselservern konfigurieren:

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
  // Configure with multiple independent key servers
  const keyServers = [
    'https://keyserver-1.your-org.com',
    'https://keyserver-2.partner-org.com',
    'https://keyserver-3.third-party.com',
    'https://keyserver-4.backup-provider.com',
    'https://keyserver-5.fallback.com'
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // 3-of-5 threshold
    network: 'mainnet',
    // Advanced options
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      'https://backup-1.emergency.com',
      'https://backup-2.emergency.com'
    ]
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "Mission critical encrypted data";

  // Encrypt with high security guarantees
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // Require all 5 servers for maximum security
    customThreshold: 5,
    // Add redundancy
    redundancy: 2,
    accessPolicy: {
      // Multi-factor requirements
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

Best Practices für Sicherheit​

1. Schlüsselmanagement​

// src/security-practices.ts

// GOOD: Use secure key derivation
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// GOOD: Store keys securely (example with environment variables)
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// BAD: Never hardcode keys
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // Don't do this!
);

2. Validierung der Zugriffsrichtlinie​

// Always validate access policies before encryption
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // Validate recipient address
  if (!isValidSuiAddress(recipient)) {
    throw new Error('Invalid recipient address');
  }

  // Check policy exists and is valid
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('Invalid access policy');
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy
  });
}

3. Fehlerbehandlung und Fallbacks​

// Robust error handling
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });
  } catch (error) {
    if (error.code === 'ACCESS_DENIED') {
      throw new Error('Access denied: Check your permissions');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // Try with backup configuration
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('Insufficient key servers available');
    } else {
      throw new Error(`Decryption failed: ${error.message}`);
    }
  }
}

4. Datenvalidierung​

// Validate data before encryption
function validateDataForEncryption(data: Buffer): boolean {
  // Check size limits
  if (data.length > 1024 * 1024) { // 1MB limit
    throw new Error('Data too large for encryption');
  }

  // Check for sensitive patterns (optional)
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('Warning: Data contains potentially sensitive patterns');
  }

  return true;
}

Leistungsoptimierung​

1. Batch-Operationen​

// Batch multiple encryptions for efficiency
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index]
    })
  );

  return Promise.all(promises);
}

2. Caching von Schlüsselserver-Antworten​

// Cache key server sessions to reduce latency
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

Testen Ihrer Seal-Integration​

Unit-Tests​

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Seal Integration', () => {
  it('should encrypt and decrypt data successfully', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('test message');
    const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient
    });

    expect(decrypted.toString()).toBe('test message');
  });

  it('should enforce access control policies', async () => {
    // Test that unauthorized users cannot decrypt
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from('secret'),
      recipientId: 'authorized-user'
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('Access denied');
  });
});

Bereitstellung für die Produktion​

Umgebungskonfiguration​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5
  ],
  threshold: 3,
  network: 'mainnet',
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // Security settings
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1 hour
  retryAttempts: 3
};

Überwachung und Protokollierung​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] Encrypted data ${encryptionId} for ${recipient}`);
    // Send to your monitoring service
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] Decryption ${encryptionId}: ${success ? 'SUCCESS' : 'FAILED'}`);
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] Key server ${serverUrl}: ${status}`);
  }
}

Ressourcen und nächste Schritte​

Offizielle Dokumentation​

• Seal Documentation: https://seal-docs.wal.app/
• GitHub Repository: https://github.com/MystenLabs/seal
• Sui Documentation: https://docs.sui.io/
• Walrus Documentation: https://docs.wal.app/

Community und Support​

• Sui Discord: Treten Sie dem #seal-Kanal für Community-Support bei
• GitHub Issues: Melden Sie Fehler und fordern Sie Funktionen an
• Developer Forums: Sui Community-Foren für Diskussionen

Erweiterte Themen zum Erkunden​

1. Benutzerdefinierte Zugriffsrichtlinien: Erstellen Sie komplexe Autorisierungslogik mit Move-Verträgen
2. Cross-Chain-Integration: Verwenden Sie Seal mit anderen Blockchain-Netzwerken
3. Enterprise-Schlüsselmanagement: Richten Sie Ihre eigene Schlüsselserver-Infrastruktur ein
4. Audit und Compliance: Implementieren Sie Protokollierung und Überwachung für regulierte Umgebungen

Beispielanwendungen​

• Sichere Chat-App: Ende-zu-Ende-verschlüsseltes Messaging mit Seal
• Dokumentenmanagement: Unternehmensweite Dokumentenfreigabe mit Zugriffskontrollen
• Digital Rights Management: Inhaltsverteilung mit Nutzungsrichtlinien
• Datenschutzfreundliche Analysen: Verschlüsselte Datenverarbeitungsworkflows

Fazit​

Seal stellt einen fundamentalen Wandel dar, um Datenschutz und Verschlüsselung zu Infrastruktur-Anliegen in Web3 zu machen. Durch die Kombination von identitätsbasierter Verschlüsselung, Schwellenwertsicherheit und programmierbarer Zugriffskontrolle bietet es Entwicklern leistungsstarke Tools zum Aufbau wirklich sicherer und dezentraler Anwendungen.

Die Hauptvorteile der Entwicklung mit Seal umfassen:

• Kein Single Point of Failure: Verteilte Schlüsselserver eliminieren zentrale Autoritäten
• Programmierbare Sicherheit: Smart-Contract-basierte Zugriffsrichtlinien bieten flexible Autorisierung
• Entwicklerfreundlich: Das TypeScript SDK lässt sich nahtlos in bestehende Web3-Tools integrieren
• Speicherunabhängig: Funktioniert mit Walrus, IPFS oder jeder Speicherlösung
• Produktionsreif: Von Mysten Labs mit Unternehmenssicherheitsstandards entwickelt

Egal, ob Sie Benutzerdaten sichern, Abonnementmodelle implementieren oder komplexe Mehrparteienanwendungen erstellen, Seal bietet die kryptografischen Primitive und die Infrastruktur zur Zugriffskontrolle, die Sie benötigen, um mit Vertrauen zu entwickeln.

Beginnen Sie noch heute mit der Entwicklung und treten Sie dem wachsenden Ökosystem von Entwicklern bei, die Datenschutz zu einem fundamentalen Bestandteil der öffentlichen Infrastruktur machen.

Bereit, mit der Entwicklung zu beginnen? Installieren Sie @mysten/seal und experimentieren Sie mit den Beispielen in diesem Tutorial. Das dezentrale Web wartet auf Anwendungen, die Datenschutz und Sicherheit an erste Stelle setzen.

TL;DR​

• Talus liefert Nexus aus, ein Move-basiertes Framework, das On-Chain- und Off-Chain-Tools zu verifizierbaren Directed Acyclic Graph (DAG)-Workflows zusammensetzt, die heute von einem vertrauenswürdigen „Leader“-Dienst vermittelt werden und im Laufe der Zeit auf sichere Enklaven und Dezentralisierung abzielen.
• Der Stack zielt auf eine aufstrebende Agentenökonomie ab, indem er Tool-Registrierungen, Zahlungsschienen, Gas-Budgetierung und Marktplätze integriert, damit Tool-Entwickler und Agentenbetreiber die Nutzung mit Auditierbarkeit monetarisieren können.
• Eine Roadmap hin zu einer dedizierten Protochain (Cosmos SDK + Move VM) ist öffentlich, aber Sui bleibt die aktive Koordinationsschicht; die Sui + Walrus Speicherintegration bietet das aktuelle Produktionssubstrat.
• Token-Pläne entwickeln sich: Materialien verweisen auf historische $TAI-Konzepte und ein Litepaper von 2025, das einen$US-Ökosystem-Token für Zahlungen, Staking und Priorisierungsmechanismen einführt.
• Das Ausführungsrisiko konzentriert sich auf die Dezentralisierung des Leaders, die Finalisierung der Token-Ökonomie und die Demonstration der Protochain-Leistung, während die Entwickler-UX über Sui, Walrus und Off-Chain-Dienste hinweg aufrechterhalten wird.

Was Talus baut – und was nicht​

Talus positioniert sich als Koordinations- und Monetarisierungsschicht für autonome KI-Agenten und nicht als reiner KI-Inferenzmarkt. Das Kernprodukt, Nexus, ermöglicht Entwicklern, Tool-Aufrufe, externe API-Aufrufe und On-Chain-Logik in Workflow-DAGs zu verpacken, die in Sui Move ausgedrückt werden. Das Design betont Verifizierbarkeit, kapazitätsbasierten Zugriff und schemagesteuerten Datenfluss, sodass jeder Tool-Aufruf On-Chain geprüft werden kann. Talus kombiniert dies mit Marktplätzen – Tool-Marktplatz, Agenten-Marktplatz und Agent-as-a-Service –, um Betreibern zu helfen, Agentenfunktionalität zu entdecken und zu monetarisieren.

Im Gegensatz dazu betreibt Talus keine eigenen großen Sprachmodelle oder GPU-Netzwerke. Stattdessen erwartet es von Tool-Entwicklern, bestehende APIs oder Dienste (OpenAI, Vektorsuche, Handelssysteme, Datenanbieter) zu umschließen und bei Nexus zu registrieren. Dies macht Talus komplementär zu Computenetzwerken wie Ritual oder Bittensor, die als Tools innerhalb von Nexus-Workflows erscheinen könnten.

Architektur: On-Chain-Kontrollebene, Off-Chain-Ausführung​

On-Chain (Sui Move)​

Die On-Chain-Komponenten leben auf Sui und stellen die Koordinationsschicht bereit:

• Workflow-Engine – DAG-Semantik umfasst Eingabegruppen, Verzweigungsvarianten und Parallelitätsprüfungen. Statische Validierung versucht, Race Conditions vor der Ausführung zu verhindern.
• Primitive – ProofOfUID ermöglicht authentifizierte paketübergreifende Nachrichtenübermittlung ohne enge Kopplung; OwnerCap/CloneableOwnerCap legen kapazitätsbasierte Berechtigungen offen; ProvenValue und NexusData-Strukturen definieren, wie Daten inline oder über Remote-Speicherreferenzen übergeben werden.
• Standard-TAP (Talus Agent Package) – Ein Referenzagent, der demonstriert, wie Arbeitsblätter (Proof-Objekte) erstellt, die Workflow-Evaluierung ausgelöst und Tool-Ergebnisse bestätigt werden, während er der Nexus-Schnittstelle v1 entspricht.
• Tool-Registrierung & Anti-Spam – Tool-Ersteller müssen zeitlich gesperrte Sicherheiten hinterlegen, um eine Tool-Definition zu veröffentlichen, was Spam abschreckt und die Registrierung erlaubnisfrei hält.
• Gas-Service – Geteilte Objekte speichern die Preisgestaltung pro Tool, Benutzer-Gasbudgets und Gas-Tickets mit Ablauf- oder Nutzungsobergrenzen. Ereignisse zeichnen jede Forderung auf, sodass Betreiber die Abrechnung für Tool-Besitzer und den Leader prüfen können.

Off-Chain-Leader​

Ein von Talus betriebener Leader-Dienst lauscht auf Sui-Ereignisse, ruft Tool-Schemas ab, orchestriert die Off-Chain-Ausführung (LLMs, APIs, Compute-Jobs), validiert Eingaben/Ausgaben anhand deklarierter Schemas und schreibt Ergebnisse On-Chain zurück. Leader-Fähigkeiten werden als Sui-Objekte dargestellt; eine fehlgeschlagene Sui-Transaktion kann eine Fähigkeit „beschädigen“, was eine sofortige Wiederverwendung verhindert, bis die Epoche wechselt. Talus plant, den Leader-Pfad durch Trusted Execution Environments (TEEs), mehrere Betreiber und eine eventuelle erlaubnisfreie Teilnahme zu härten.

Speicher & Verifizierbarkeit​

Walrus, die dezentrale Speicherschicht von Mysten Labs, ist für Agenten-Speicher, Modellartefakte und große Datensätze integriert. Nexus behält Sui für die deterministische Kontrollebene bei, während größere Datenmengen an Walrus übertragen werden. Öffentliche Materialien weisen auf die Unterstützung mehrerer Verifizierungsmodi hin – optimistisch, Zero-Knowledge oder Trusted Execution – wählbar je nach Workflow-Anforderungen.

Entwicklererfahrung und frühe Produkte​

Talus pflegt ein Rust-basiertes SDK, CLI-Tools und Dokumentation mit Anleitungen (Erstellen von DAGs, Integration von LLMs, Absicherung von Tools). Ein Katalog von Standard-Tools – OpenAI Chat-Vervollständigungen, X (Twitter)-Operationen, Walrus-Speicheradapter, mathematische Dienstprogramme – reduziert die Reibung beim Prototyping. Auf der Konsumentenseite dienen Flaggschiff-Erlebnisse wie IDOL.fun (Agent-gegen-Agent-Vorhersagemärkte) und AI Bae (gamifizierte KI-Begleiter) als Proof Points und Vertriebskanäle für agenten-native Workflows. Talus Vision, ein No-Code-Builder, wird als kommende Marktplatz-Schnittstelle positioniert, die das Workflow-Design für Nicht-Entwickler abstrahiert.

Wirtschaftliches Design, Token-Pläne und Gas-Handhabung​

In der aktiven Sui-Bereitstellung finanzieren Benutzer Workflows in SUI. Der Gas-Service wandelt diese Budgets in Tool-spezifische Tickets um, erzwingt Ablauf- oder Umfangsbeschränkungen und protokolliert Forderungen, die On-Chain abgeglichen werden können. Tool-Besitzer definieren die Preisgestaltung, während der Leader über denselben Abrechnungsfluss bezahlt wird. Da der Leader Budgets derzeit beanspruchen kann, sobald die Ausführung erfolgreich ist, müssen Benutzer dem Betreiber vertrauen – aber emittierte Ereignisse bieten Auditierbarkeit.

Das Token-Design ist noch im Fluss. Erklärungen Dritter verweisen auf ein früheres $TAI**-Konzept, während Talus' Litepaper von 2025 einen Ökosystem-Token namens **$US mit einem Angebot von 10 Milliarden vorschlägt. Die genannten Rollen umfassen die Funktion als Medium für Tool- und Leader-Zahlungen, Staking für Servicegarantien und die Verleihung von Priorisierungsrechten. Materialien deuten darauf hin, dass überschüssiges SUI, das bei der Ausführung bezahlt wird, über Markttauschgeschäfte in $US umgewandelt werden könnte. Investoren sollten diese Details als vorläufig betrachten, bis die Tokenomics finalisiert sind.

Finanzierung, Team und Partnerschaften​

Talus kündigte eine strategische Runde von 6 Millionen US-Dollar (insgesamt 9 Millionen US-Dollar gesammelt) an, die von Polychain angeführt wurde, mit einer gemeldeten Bewertung von 150 Millionen US-Dollar Ende 2024. Die Erlöse sind für die Weiterentwicklung von Nexus, die Inkubation von Verbraucheranwendungen und den Bau von Protochain, der vorgeschlagenen dedizierten L1 für Agenten, vorgesehen. Öffentliche Quellen nennen Mike Hanono (CEO) und Ben Frigon (COO) als Schlüsselmanager. Integrationsankündigungen heben die Zusammenarbeit mit den Sui- und Walrus-Ökosystemen hervor und untermauern die Infrastruktur von Mysten Labs als aktuelle Ausführungsumgebung.

Wettbewerbsanalyse​

• Ritual konzentriert sich auf dezentrale KI-Berechnung (Infernet) und EVM-Integrationen, wobei der Schwerpunkt auf verifizierbarer Inferenz statt auf Workflow-Orchestrierung liegt.
• Autonolas (Olas) koordiniert Off-Chain-Agentendienste mit On-Chain-Anreizen; es teilt die Agentenökonomie-These, aber es fehlt die Move-basierte DAG-Ausführungsschicht von Nexus.
• Fetch.ai bietet Agentverse und uAgents zur Verbindung autonomer Dienste; Talus unterscheidet sich durch die On-Chain-Verifizierung jedes Workflow-Schritts und die integrierte Gas-Abrechnung.
• Bittensor belohnt den Beitrag von ML-Modellen über TAO-Subnetze – ein Compute-Marktplatz, der als Tool-Anbieter in Nexus integriert werden könnte, aber nicht die Monetarisierungsschienen bietet, die Talus anstrebt.

Insgesamt besetzt Talus die Koordinations- und Abrechnungsebene für Agenten-Workflows und überlässt die Rohberechnung und Inferenz spezialisierten Netzwerken, die als Tools angeschlossen werden können.

Hauptrisiken und offene Fragen​

1. Leader-Vertrauen – Bis TEEs und die Unterstützung mehrerer Betreiber verfügbar sind, müssen Entwickler dem Leader von Talus vertrauen, dass er treu ausführt und genaue Ergebnisse liefert.
2. Token-Unsicherheit – Branding und Mechaniken haben sich von $TAI zu$US verschoben; Angebotspläne, Verteilung und Staking-Ökonomie sind noch nicht finalisiert.
3. Protochain-Ausführung – Öffentliche Materialien beschreiben eine Cosmos SDK-Kette mit Move VM-Unterstützung, aber Code-Repositories, Benchmarks und Sicherheitsaudits sind noch nicht verfügbar.
4. Tool-Qualität und Spam – Sicherheitenanforderungen schrecken Spam ab, doch der langfristige Erfolg hängt von der Schema-Validierung, Verfügbarkeitsgarantien und der Streitbeilegung bei Off-Chain-Ausgaben ab.
5. UX-Komplexität – Die Koordination von Sui, Walrus und verschiedenen Off-Chain-APIs führt zu operativem Mehraufwand; das SDK und die No-Code-Tools müssen dies abstrahieren, um die Akzeptanz bei Entwicklern aufrechtzuerhalten.

Meilensteine für 2025–2026​

• Veröffentlichung einer Leader-Roadmap mit TEE-Härtung, Slashing-Regeln und öffentlichem Onboarding für zusätzliche Betreiber.
• Erweiterung des Tool-Marktplatzes: Anzahl der registrierten Tools, Preismodelle und Qualitätsmetriken (Verfügbarkeit, SLA-Transparenz).
• Adoptionsmetriken für IDOL.fun, AI Bae und Talus Vision als Indikatoren für die Benutzernachfrage nach agenten-nativen Erlebnissen.
• Leistungsdaten aus der Ausführung umfangreicher Workflows auf Sui + Walrus: Latenz, Durchsatz und Gasverbrauch.
• Veröffentlichung der finalen Tokenomics, einschließlich Zeitplan für die Token-Freigabe, Staking-Belohnungen und den SUI→$US-Konvertierungspfad.
• Veröffentlichung von Protochain-Repositories, Testnetzen und Interoperabilitätsplänen (z. B. IBC-Unterstützung) zur Validierung der These der dedizierten Kette.

Wie Builder und Betreiber sich engagieren können​

• Schnell Prototypen erstellen – Kombinieren Sie das Standard-TAP mit Standard-Tools (OpenAI, X, Walrus) in einem Drei-Knoten-DAG, um Datenerfassung, Zusammenfassung und On-Chain-Aktionen zu automatisieren.
• Spezialisierte Tools monetarisieren – Umschließen Sie proprietäre APIs (Finanzdaten, Compliance-Prüfungen, maßgeschneiderte LLMs) als Nexus-Tools, definieren Sie Preise und geben Sie Gas-Tickets mit Ablauf- oder Nutzungsobergrenzen aus, um die Nachfrage zu steuern.
• Vorbereitung auf die Leader-Teilnahme – Überwachen Sie die Dokumentation bezüglich Staking-Anforderungen, Slashing-Logik und Fehlerbehandlungsmechanismen, damit Infrastrukturanbieter als zusätzliche Leader einsteigen können, wenn das Netzwerk geöffnet wird.
• Konsumenten-Flywheels bewerten – Analysieren Sie die Bindung und Ausgaben in IDOL.fun und AI Bae, um zu beurteilen, ob agenten-zentrierte Konsumentenprodukte eine breitere Tool-Nachfrage ankurbeln können.

Fazit​

Talus liefert einen glaubwürdigen Entwurf für eine On-Chain-Agentenökonomie, indem es verifizierbare Move-basierte Workflows, kapazitätsgesteuerte Tool-Komposition und explizite Monetarisierungsschienen kombiniert. Der Erfolg hängt nun davon ab, zu beweisen, dass das Modell über einen vertrauenswürdigen Leader hinaus skaliert, nachhaltige Token-Anreize zu finalisieren und zu demonstrieren, dass Protochain die Lehren aus der Sui-Ära in eine dedizierte Ausführungsumgebung übertragen kann. Builder, die eine transparente Abrechnung und zusammensetzbare Agenten-Workflows benötigen, sollten Nexus auf ihrer Due-Diligence-Shortlist behalten und gleichzeitig verfolgen, wie schnell Talus diese offenen Fragen entschärfen kann.

Öffentliche Blockchains bieten jedem Teilnehmer ein synchronisiertes, auditierbares Ledger – doch sie legen standardmäßig auch jedes Datenelement offen. Seal, seit dem 3. September 2025 live im Sui Mainnet, begegnet diesem Problem, indem es On-Chain-Richtlinienlogik mit dezentraler Schlüsselverwaltung kombiniert, sodass Web3-Entwickler genau entscheiden können, wer welche Payloads entschlüsseln darf.

TL;DR​

• Was es ist: Seal ist ein Netzwerk zur Geheimnisverwaltung, das Sui-Smart Contracts ermöglicht, Entschlüsselungsrichtlinien On-Chain durchzusetzen, während Clients Daten mit identitätsbasierter Verschlüsselung (IBE) verschlüsseln und sich für die Schlüsselableitung auf Schwellenwert-Schlüsselserver verlassen.
• Warum es wichtig ist: Anstelle von benutzerdefinierten Backends oder undurchsichtigen Off-Chain-Skripten werden Datenschutz und Zugriffskontrolle zu erstklassigen Move-Primitiven. Entwickler können Chiffriertexte überall speichern – Walrus ist der natürliche Begleiter – aber dennoch steuern, wer lesen darf.
• Wer profitiert: Teams, die Token-gesteuerte Medien, zeitgesteuerte Offenlegungen, private Nachrichten oder richtlinienbewusste KI-Agenten bereitstellen, können das SDK von Seal nutzen und sich auf die Produktlogik konzentrieren, anstatt auf maßgeschneiderte Krypto-Infrastruktur.

Richtlinienlogik lebt in Move​

Seal-Pakete enthalten seal_approve* Move-Funktionen, die definieren, wer Schlüssel für eine bestimmte Identitätszeichenfolge und unter welchen Bedingungen anfordern kann. Richtlinien können NFT-Besitz, Whitelists, Zeit-Sperren oder benutzerdefinierte Rollensysteme mischen. Wenn ein Benutzer oder Agent die Entschlüsselung anfordert, bewerten die Schlüsselserver diese Richtlinien über den Sui-Full-Node-Status und genehmigen nur, wenn die Kette zustimmt.

Da die Zugriffsregeln Teil Ihres On-Chain-Pakets sind, sind sie transparent, auditierbar und versionierbar, zusammen mit dem Rest Ihres Smart-Contract-Codes. Governance-Updates können wie jedes andere Move-Upgrade ausgerollt werden, mit Community-Überprüfung und On-Chain-Historie.

Schwellenwert-Kryptographie verwaltet die Schlüssel​

Seal verschlüsselt Daten für anwendungsdefinierte Identitäten. Ein Komitee unabhängiger Schlüsselserver – vom Entwickler ausgewählt – teilt das IBE-Master-Geheimnis. Wenn eine Richtlinienprüfung erfolgreich ist, leitet jeder Server einen Schlüsselanteil für die angeforderte Identität ab. Sobald ein Quorum von t Servern antwortet, kombiniert der Client die Anteile zu einem nutzbaren Entschlüsselungsschlüssel.

Sie können den Kompromiss zwischen Lebendigkeit und Vertraulichkeit festlegen, indem Sie Komiteemitglieder (Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One oder Mystens Enoki-Dienst) auswählen und den Schwellenwert bestimmen. Benötigen Sie eine stärkere Verfügbarkeit? Wählen Sie ein größeres Komitee mit einem niedrigeren Schwellenwert. Wünschen Sie höhere Datenschutzgarantien? Ziehen Sie das Quorum enger und verlassen Sie sich auf zugelassene Anbieter.

Entwicklererfahrung: SDKs und Sitzungsschlüssel​

Seal liefert ein TypeScript SDK (npm i @mysten/seal), das Verschlüsselungs-/Entschlüsselungsabläufe, Identitätsformatierung und Batching handhabt. Es gibt auch Sitzungsschlüssel aus, damit Wallets nicht ständig mit Aufforderungen bombardiert werden, wenn eine App wiederholten Zugriff benötigt. Für fortgeschrittene Workflows können Move-Kontrakte On-Chain-Entschlüsselung über spezialisierte Modi anfordern, wodurch Logik wie Treuhand-Offenlegungen oder MEV-resistente Auktionen direkt im Smart-Contract-Code ausgeführt werden können.

Da Seal speicherunabhängig ist, können Teams es mit Walrus für überprüfbaren Blob-Speicher, mit IPFS oder sogar mit zentralisierten Speichern kombinieren, wenn dies den operativen Realitäten entspricht. Die Verschlüsselungsgrenze – und ihre Richtliniendurchsetzung – wandert mit den Daten, unabhängig davon, wo der Chiffriertext gespeichert ist.

Design mit Seal: Best Practices​

• Verfügbarkeitsrisiko modellieren: Schwellenwerte wie 2-von-3 oder 3-von-5 entsprechen direkt den Verfügbarkeitsgarantien. Produktionsbereitstellungen sollten Anbieter mischen, Telemetrie überwachen und SLAs aushandeln, bevor kritische Workflows anvertraut werden.
• Auf Zustandsvarianz achten: Die Richtlinienbewertung hängt davon ab, dass Full Nodes dry_run-Aufrufe durchführen. Vermeiden Sie Regeln, die von sich schnell ändernden Zählern oder der Reihenfolge innerhalb von Checkpoints abhängen, um inkonsistente Genehmigungen über Server hinweg zu verhindern.
• Schlüsselhygiene planen: Abgeleitete Schlüssel befinden sich auf dem Client. Instrumentieren Sie die Protokollierung, rotieren Sie Sitzungsschlüssel und erwägen Sie die Umschlagverschlüsselung – verwenden Sie Seal, um einen symmetrischen Schlüssel zu schützen, der die größere Payload verschlüsselt –, um den Schadensradius zu begrenzen, falls ein Gerät kompromittiert wird.
• Rotation architektonisch planen: Das Komitee eines Chiffriertextes ist zum Zeitpunkt der Verschlüsselung festgelegt. Erstellen Sie Upgrade-Pfade, die Daten durch neue Komitees neu verschlüsseln, wenn Sie Anbieter wechseln oder Vertrauensannahmen anpassen müssen.

Was als Nächstes kommt​

Die Roadmap von Seal weist auf von Validatoren betriebene MPC-Server, DRM-ähnliche Client-Tools und Post-Quanten-KEM-Optionen hin. Für Entwickler, die KI-Agenten, Premium-Inhalte oder regulierte Datenflüsse erforschen, bietet die heutige Veröffentlichung bereits einen klaren Bauplan: Kodieren Sie Ihre Richtlinie in Move, stellen Sie ein vielfältiges Schlüsselkomitee zusammen und liefern Sie verschlüsselte Erlebnisse, die die Privatsphäre der Benutzer respektieren, ohne die Vertrauensgrenze von Sui zu verlassen.

Wenn Sie Seal für Ihren nächsten Start in Betracht ziehen, beginnen Sie mit dem Prototyping einer einfachen NFT-gesteuerten Richtlinie mit einem offenen 2-von-3-Komitee und iterieren Sie dann zu der Anbieterkombination und den operativen Kontrollen, die dem Risikoprofil Ihrer App entsprechen.

Stellen Sie sich eine Welt vor, in der Benutzer nahtlos mit Ihrer dApp interagieren können, ohne native Token (SUI) besitzen zu müssen. Dies ist kein ferner Traum mehr. Mit Suis Gas Station (auch bekannt als Paymaster) können Entwickler die Gasgebühren im Namen ihrer Benutzer übernehmen, wodurch eine der größten Hürden für Neueinsteiger in Web3 vollständig beseitigt und ein wirklich reibungsloses On-Chain-Erlebnis ermöglicht wird.

Dieser Artikel bietet einen vollständigen Leitfaden zur Umstellung Ihrer dApp auf Gas-los. Wir werden tief in die Kernkonzepte des Sui Paymasters, seine Architektur, Implementierungsmuster und Best Practices eintauchen.

1. Hintergrund und Kernkonzepte: Was ist eine gesponserte Transaktion?​

In der Welt der Blockchain erfordert jede Transaktion eine Netzwerkgebühr oder „Gas“. Für Benutzer, die an die nahtlosen Erfahrungen von Web2 gewöhnt sind, stellt dies eine erhebliche kognitive und operative Hürde dar. Sui begegnet dieser Herausforderung auf Protokollebene mit gesponserten Transaktionen.

Die Kernidee ist einfach: einer Partei (dem Sponsor) zu erlauben, die SUI-Gasgebühren für die Transaktion einer anderen Partei (des Benutzers) zu bezahlen. Auf diese Weise können Benutzer, selbst wenn sie kein SUI in ihrer Wallet haben, dennoch erfolgreich On-Chain-Aktionen initiieren.

Paymaster ≈ Tankstelle​

Im Sui-Ökosystem wird die Logik für das Sponsern von Transaktionen typischerweise von einem Off-Chain- oder On-Chain-Dienst namens Gas Station oder Paymaster gehandhabt. Zu seinen Hauptaufgaben gehören:

1. Bewertung der Transaktion: Er empfängt die gas-losen Transaktionsdaten eines Benutzers (GasLessTransactionData).
2. Bereitstellung von Gas: Er sperrt und weist die notwendige Gasgebühr für die Transaktion zu. Dies wird normalerweise über einen Gas-Pool verwaltet, der aus vielen SUI-Coin-Objekten besteht.
3. Erzeugung einer Sponsor-Signatur: Nach Genehmigung des Sponsorings signiert die Gas Station die Transaktion mit ihrem privaten Schlüssel (SponsorSig), wodurch ihre Bereitschaft zur Zahlung der Gebühr bestätigt wird.
4. Rückgabe der signierten Transaktion: Er sendet die TransactionData zurück, die nun die Gasdaten und die Signatur des Sponsors enthält, um die endgültige Signatur des Benutzers abzuwarten.

Kurz gesagt, eine Gas Station fungiert als Tankservice für die Benutzer Ihrer dApp und stellt sicher, dass ihre „Fahrzeuge“ (Transaktionen) reibungslos im Sui-Netzwerk fahren können.

2. Hochrangige Architektur und Interaktionsfluss​

Eine typische gas-lose Transaktion erfordert die Koordination zwischen dem Benutzer, dem dApp-Frontend, der Gas Station und einem Sui Full Node. Die Interaktionssequenz ist wie folgt:

Ablaufbeschreibung:

1. Der Benutzer führt eine Aktion in der dApp-Benutzeroberfläche aus, die ein Transaktionsdatenpaket ohne Gasinformationen erstellt.
2. Die dApp sendet diese Daten an ihre zugewiesene Gas Station, um ein Sponsoring anzufordern.
3. Die Gas Station überprüft die Gültigkeit der Anfrage (z. B. ob der Benutzer für ein Sponsoring berechtigt ist), füllt die Transaktion dann mit einem Gas Coin und ihrer Signatur auf und gibt die halbfertige Transaktion an die dApp zurück.
4. Der Benutzer sieht die vollständigen Transaktionsdetails in seiner Wallet (z. B. „Ein NFT kaufen“) und gibt die endgültige Signatur. Dies ist ein entscheidender Schritt, der sicherstellt, dass der Benutzer die Zustimmung und Kontrolle über seine Aktionen behält.
5. Die dApp sendet die vollständige Transaktion, die sowohl die Signaturen des Benutzers als auch des Sponsors enthält, an einen Sui Full Node.
6. Nachdem die Transaktion On-Chain abgeschlossen ist, kann die Gas Station dies durch Abhören von On-Chain-Ereignissen oder -Belegen bestätigen und dann das dApp-Backend über einen Webhook benachrichtigen, um den Geschäftsprozess abzuschließen.

3. Drei Kern-Interaktionsmodelle​

Sie können die folgenden drei Interaktionsmodelle einzeln oder in Kombination verwenden, um Ihren Geschäftsanforderungen gerecht zu werden.

Modell 1: Benutzer-initiiert → Sponsor-genehmigt (Am häufigsten)​

Dies ist das Standardmodell, das für die überwiegende Mehrheit der In-dApp-Interaktionen geeignet ist.

1. Benutzer erstellt GasLessTransactionData: Der Benutzer führt eine Aktion innerhalb der dApp aus.
2. Sponsor fügt GasData hinzu und signiert: Das dApp-Backend sendet die Transaktion an die Gas Station, die sie genehmigt, einen Gas Coin anhängt und ihre Signatur hinzufügt.
3. Benutzer überprüft und gibt endgültige Signatur: Der Benutzer bestätigt die endgültigen Transaktionsdetails in seiner Wallet und signiert sie. Die dApp übermittelt sie dann an das Netzwerk.

Dieses Modell bietet eine hervorragende Balance zwischen Sicherheit und Benutzererfahrung.

Modell 2: Sponsor-initiierte Airdrops/Anreize​

Dieses Modell ist perfekt für Airdrops, Benutzeranreize oder die Verteilung von Vermögenswerten in Batches.

1. Sponsor füllt TransactionData vorab aus + signiert: Der Sponsor (typischerweise das Projektteam) konstruiert den Großteil der Transaktion vorab (z. B. das Airdroppen eines NFT an eine bestimmte Adresse) und fügt seine Sponsoring-Signatur hinzu.
2. Die zweite Signatur des Benutzers macht sie wirksam: Der Benutzer muss diese „vorab genehmigte“ Transaktion nur einmal signieren, damit sie ausgeführt wird.

Dies schafft ein extrem reibungsloses Benutzererlebnis. Mit nur einem Klick zur Bestätigung können Benutzer Belohnungen beanspruchen oder Aufgaben erledigen, was die Konversionsraten von Marketingkampagnen drastisch erhöht.

Modell 3: Wildcard GasData (Kreditlinienmodell)​

Dies ist ein flexibleres und berechtigungsbasiertes Modell.

1. Sponsor überträgt ein GasData-Objekt: Der Sponsor erstellt zunächst ein oder mehrere Gas-Coin-Objekte mit einem bestimmten Budget und überträgt das Eigentum direkt an den Benutzer.
2. Benutzer gibt innerhalb des Budgets frei aus: Der Benutzer kann diese Gas Coins dann frei verwenden, um beliebige Transaktionen zu bezahlen, die er innerhalb der Budgetgrenzen und des Gültigkeitszeitraums initiiert.
3. Gas Coin wird zurückgegeben: Sobald der Gas Coin aufgebraucht oder abgelaufen ist, kann das Gas-Coin-Objekt so konzipiert werden, dass es automatisch zerstört oder an den Sponsor zurückgegeben wird.

Dieses Modell entspricht der Vergabe einer „Gasgebühren-Kreditkarte“ mit begrenzter Laufzeit und begrenztem Budget an den Benutzer, geeignet für Szenarien, die ein hohes Maß an Benutzerautonomie erfordern, wie z. B. das Anbieten eines Free-to-Play-Erlebnisses während einer Spielsaison.

4. Typische Anwendungsszenarien​

Die Stärke des Sui Paymasters liegt nicht nur in der Lösung des Gasgebührenproblems, sondern auch in seiner Fähigkeit, sich tief in die Geschäftslogik zu integrieren, um neue Möglichkeiten zu schaffen.

Szenario 1: Paywalls​

Viele Content-Plattformen oder dApp-Dienste erfordern, dass Benutzer bestimmte Kriterien erfüllen (z. B. ein VIP-NFT besitzen, ein bestimmtes Mitgliedschaftsniveau erreichen), um auf Funktionen zugreifen zu können. Der Paymaster kann diese Logik perfekt implementieren.

• Ablauf: Ein Benutzer fordert eine Aktion an → das dApp-Backend überprüft die Qualifikationen des Benutzers (z. B. NFT-Besitz) → wenn berechtigt, ruft es den Paymaster auf, um die Gasgebühr zu sponsern; wenn nicht, lehnt es die Signaturanfrage einfach ab.
• Vorteil: Dieses Modell ist von Natur aus resistent gegen Bots und Missbrauch. Da die Sponsoring-Entscheidung im Backend getroffen wird, können böswillige Benutzer die Qualifikationsprüfung nicht umgehen, um Gasgelder abzuschöpfen.

Szenario 2: Ein-Klick-Kaufabwicklung​

In E-Commerce- oder In-Game-Kaufszenarien ist die Vereinfachung des Zahlungsprozesses entscheidend.

• Ablauf: Der Benutzer klickt auf einer Checkout-Seite auf „Jetzt kaufen“. Die dApp erstellt eine Transaktion, die die Geschäftslogik (z. B. transfer_nft_to_user) enthält. Der Benutzer muss nur signieren, um die Geschäftstransaktion in seiner Wallet zu genehmigen, ohne sich um Gas kümmern zu müssen. Die Gasgebühr wird vom Sponsor der dApp übernommen.
• Vorteil: Sie können Geschäftsparameter wie eine order_id direkt in den ProgrammableTransactionBlock kodieren, was eine präzise On-Chain-Zuordnung für Backend-Bestellungen ermöglicht.

Szenario 3: Datenzuordnung​

Eine genaue Datenverfolgung ist grundlegend für die Geschäftsoptimierung.

• Ablauf: Beim Erstellen der Transaktion schreiben Sie einen eindeutigen Bezeichner (wie einen order_hash) in die Parameter der Transaktion oder in ein Ereignis, das bei der Ausführung ausgegeben wird.
• Vorteil: Wenn die Gas Station den On-Chain-Beleg für eine erfolgreiche Transaktion erhält, kann sie diesen order_hash leicht extrahieren, indem sie die Ereignis- oder Transaktionsdaten parst. Dies ermöglicht eine präzise Zuordnung zwischen On-Chain-Statusänderungen und spezifischen Backend-Bestellungen oder Benutzeraktionen.

5. Code-Grundgerüst (Basierend auf dem Rust SDK)​

Hier ist ein vereinfachtes Code-Snippet, das die Kerninteraktionsschritte demonstriert.

// 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)?;

Für eine vollständige Implementierung verweisen wir auf das Gas Station Tutorial in der offiziellen Sui-Dokumentation, das sofort einsatzbereite Codebeispiele bietet.

6. Risiken und Schutz​

Obwohl leistungsstark, erfordert der Einsatz einer Gas Station in einer Produktionsumgebung eine sorgfältige Abwägung der folgenden Risiken:

• Äquivokation (Double-Spending): Ein böswilliger Benutzer könnte versuchen, denselben Gas Coin für mehrere Transaktionen parallel zu verwenden, was dazu führen würde, dass der Gas Coin vom Sui-Netzwerk gesperrt wird. Dies kann effektiv gemildert werden, indem jedem Benutzer oder jeder Transaktion ein eindeutiger Gas Coin zugewiesen, eine Blacklist geführt und Signaturanfragen ratenbegrenzt werden.
• Gas-Pool-Management: In Szenarien mit hoher Parallelität kann ein einzelner Gas Coin mit hohem Wert zu einem Leistungsengpass werden. Der Gas Station-Dienst muss in der Lage sein, große SUI-Coins automatisch in viele kleinere Gas Coins aufzuteilen und diese nach Gebrauch effizient zurückzugewinnen. Professionelle Gas Station-Anbieter wie Shinami bieten ausgereifte, verwaltete Lösungen hierfür an.
• Autorisierung und Ratenbegrenzung: Sie müssen strenge Autorisierungs- und Ratenbegrenzungsrichtlinien festlegen. Verwalten Sie beispielsweise Sponsoring-Limits und -Häufigkeiten basierend auf Benutzer-IP, Wallet-Adresse oder API-Tokens, um zu verhindern, dass der Dienst von böswilligen Akteuren geleert wird.

7. Ökosystem-Tools​

Das Sui-Ökosystem bietet bereits eine Vielzahl von Tools, um die Entwicklung und Bereitstellung von Paymastern zu vereinfachen:

• Offizielle SDKs (Rust/TypeScript): Enthalten High-Level-APIs wie sponsor_transaction_block(), was die Integrationskomplexität erheblich reduziert.
• Shinami Gas Station: Bietet einen All-in-One-Managed-Service, einschließlich automatischer Gas-Coin-Aufteilung/-Rückgewinnung, detaillierter Metriküberwachung und Webhook-Benachrichtigungen, sodass sich Entwickler auf die Geschäftslogik konzentrieren können.
• Enoki / Mysten Demos: Die Community und Mysten Labs stellen auch Open-Source-Paymaster-Implementierungen bereit, die als Referenz für den Aufbau Ihres eigenen Dienstes verwendet werden können.

8. Implementierungs-Checkliste​

Bereit, Ihre dApp in die gas-lose Ära zu bringen? Gehen Sie diese Checkliste durch, bevor Sie beginnen:

• Planen Sie Ihren Finanzierungsfluss: Definieren Sie die Finanzierungsquelle, das Budget und die Nachschubstrategie des Sponsors. Richten Sie Überwachung und Warnmeldungen für Schlüsselmetriken (z. B. Gas-Pool-Guthaben, Verbrauchsrate) ein.
• Reservieren Sie Attributionsfelder: Achten Sie bei der Gestaltung Ihrer Transaktionsparameter darauf, Felder für Geschäftsbezeichner wie order_id oder user_id zu reservieren.
• Implementieren Sie Anti-Missbrauchsrichtlinien: Sie müssen strenge Autorisierungs-, Ratenbegrenzungs- und Protokollierungsmechanismen implementieren, bevor Sie live gehen.
• Proben auf dem Testnet: Egal, ob Sie Ihren eigenen Dienst aufbauen oder eine Drittanbieter-Gas Station integrieren, führen Sie immer zuerst gründliche Parallelitäts- und Stresstests auf einem Testnet oder Devnet durch.
• Kontinuierlich optimieren: Verfolgen Sie nach dem Start kontinuierlich die Transaktionserfolgsraten, Fehlerursachen und Gaskosten. Passen Sie Ihr Budget und Ihre Strategien basierend auf den Daten an.

Fazit​

Der Sui Paymaster (Gas Station) ist mehr als nur ein Tool zur Deckung der Gasgebühren von Benutzern. Es ist ein leistungsstarkes Paradigma, das ein „Zero SUI On-Chain“-Benutzererlebnis elegant mit dem geschäftlichen Bedürfnis nach „On-Chain-Attribution auf Bestellebene“ innerhalb einer einzigen, atomaren Transaktion kombiniert. Es ebnet Web2-Benutzern den Weg in Web3 und bietet Entwicklern eine beispiellose Flexibilität für die Geschäftsanpassung.

Mit einem zunehmend ausgereiften Ökosystem von Tools und den derzeit niedrigen Gaskosten im Sui-Netzwerk war es noch nie eine bessere Zeit, die Zahlungs- und Interaktionsflüsse Ihrer dApp in die gas-lose Ära zu bringen.

Wir freuen uns, die Einführung des SUI-Token-Stakings auf BlockEden.xyz bekannt zu geben! Ab heute können Sie Ihre SUI-Token direkt über unsere Plattform staken und einen APY von 2,08 % verdienen, während Sie die Sicherheit und Dezentralisierung des SUI-Netzwerks unterstützen.

Was ist neu: Ein nahtloses SUI-Staking-Erlebnis​

Unsere neue Staking-Funktion macht institutionelles Staking für jedermann zugänglich, mit einer einfachen, intuitiven Benutzeroberfläche, die das Verdienen von Belohnungen mühelos macht.

Hauptmerkmale​

Ein-Klick-Staking SUI zu staken war noch nie so einfach. Verbinden Sie einfach Ihre Suisplash-Wallet, geben Sie den gewünschten SUI-Betrag ein und bestätigen Sie die Transaktion. Sie beginnen fast sofort, Belohnungen zu verdienen, ohne komplexe Prozeduren.

Wettbewerbsfähige Belohnungen Verdienen Sie einen wettbewerbsfähigen APY von 2,08 % auf Ihre gestakten SUI. Unsere 8 % Kommission ist transparent, sodass Sie genau wissen, was Sie erwartet. Belohnungen werden täglich nach Abschluss jeder Epoche ausgeschüttet.

Vertrauenswürdiger Validator Werden Sie Teil einer wachsenden Community, die bereits über 22 Millionen SUI mit dem BlockEden.xyz-Validator gestaket hat. Wir verfügen über eine nachweisliche Erfolgsbilanz zuverlässiger Validierungsdienste, unterstützt durch eine Infrastruktur auf Unternehmensniveau, die eine 99,9 %ige Verfügbarkeit gewährleistet.

Flexibles Management Ihre Assets bleiben flexibel. Staking ist sofortig, was bedeutet, dass Ihre Belohnungen sofort zu akkumulieren beginnen. Sollten Sie auf Ihre Gelder zugreifen müssen, können Sie den Unstaking-Prozess jederzeit einleiten. Ihre SUI werden nach der standardmäßigen SUI-Netzwerk-Unbonding-Periode von 24-48 Stunden verfügbar sein. Sie können Ihre Stakes und Belohnungen in Echtzeit über unser Dashboard verfolgen.

Warum SUI mit BlockEden.xyz staken?​

Die Wahl eines Validators ist eine entscheidende Entscheidung. Hier erfahren Sie, warum BlockEden.xyz eine gute Wahl für Ihre Staking-Bedürfnisse ist.

Zuverlässigkeit, der Sie vertrauen können​

BlockEden.xyz ist seit unserer Gründung ein Eckpfeiler der Blockchain-Infrastruktur. Unsere Validator-Infrastruktur versorgt Unternehmensanwendungen und hat eine außergewöhnliche Verfügbarkeit über mehrere Netzwerke hinweg aufrechterhalten, wodurch eine konsistente Belohnungsgenerierung gewährleistet ist.

Transparent & Fair​

Wir glauben an vollständige Transparenz. Es gibt keine versteckten Gebühren – nur eine klare 8 % Kommission auf die Belohnungen, die Sie verdienen. Sie können Ihre Staking-Performance mit Echtzeit-Berichten überwachen und die Aktivität unseres Validators On-Chain überprüfen.

• Offene Validator-Adresse: 0x3b5664bb0f8bb4a8be77f108180a9603e154711ab866de83c8344ae1f3ed4695

Nahtlose Integration​

Unsere Plattform ist auf Einfachheit ausgelegt. Es ist keine Kontoerstellung erforderlich; Sie können direkt von Ihrer Wallet aus staken. Das Erlebnis ist für die Suisplash-Wallet optimiert, und unsere saubere, intuitive Benutzeroberfläche ist sowohl für Anfänger als auch für Experten konzipiert.

So fangen Sie an​

Der Einstieg ins SUI-Staking auf BlockEden.xyz dauert weniger als zwei Minuten.

Schritt 1: Besuchen Sie die Staking-Seite​

Navigieren Sie zu blockeden.xyz/dash/stake. Sie können den Prozess sofort ohne Registrierung eines Kontos beginnen.

Schritt 2: Verbinden Sie Ihre Wallet​

Falls Sie sie noch nicht haben, installieren Sie die Suisplash-Wallet. Klicken Sie auf der Staking-Seite auf die Schaltfläche "Wallet verbinden" und bestätigen Sie die Verbindung in der Wallet-Erweiterung. Ihr SUI-Guthaben wird automatisch angezeigt.

Schritt 3: Wählen Sie Ihren Stake-Betrag​

Geben Sie den Betrag an SUI ein, den Sie staken möchten (mindestens 1 SUI). Sie können die Schaltfläche "MAX" verwenden, um bequem Ihr gesamtes verfügbares Guthaben zu staken und einen kleinen Betrag für Gasgebühren zu belassen. Eine Zusammenfassung zeigt Ihren Stake-Betrag und die geschätzten jährlichen Belohnungen.

Schritt 4: Bestätigen & Verdienen Sie​

Klicken Sie auf "SUI staken" und bestätigen Sie die finale Transaktion in Ihrer Wallet. Ihr neuer Stake wird in Echtzeit auf dem Dashboard angezeigt, und Sie beginnen sofort, Belohnungen zu akkumulieren.

Staking-Ökonomie: Was Sie wissen müssen​

Das Verständnis der Staking-Mechanismen ist entscheidend für die effektive Verwaltung Ihrer Assets.

Belohnungsstruktur​

• Basis-APY: 2,08 % jährlich
• Belohnungsfrequenz: Jede Epoche (ca. 24 Stunden) ausgeschüttet
• Kommission: 8 % der verdienten Belohnungen
• Zinseszinseffekt: Belohnungen werden Ihrer Wallet hinzugefügt und können erneut gestaket werden, um einen Zinseszinseffekt zu erzielen.

Beispiel-Einnahmen​

Hier ist eine einfache Aufschlüsselung der potenziellen Einnahmen basierend auf einem APY von 2,08 %, nach Abzug der 8 % Kommission.

Hinweis: Dies sind Schätzungen. Die tatsächlichen Belohnungen können je nach Netzwerkbedingungen variieren.

Risikobetrachtungen​

Staking birgt bestimmte Risiken, derer Sie sich bewusst sein sollten:

• Unbonding-Periode: Wenn Sie unstaken, unterliegen Ihre SUI einer 24-48-stündigen Unbonding-Periode, in der sie unzugänglich sind und keine Belohnungen verdienen.
• Validator-Risiko: Obwohl wir hohe Standards aufrechterhalten, birgt jeder Validator operationelle Risiken. Die Wahl eines seriösen Validators wie BlockEden.xyz ist wichtig.
• Netzwerkrisiko: Staking ist eine Form der Netzwerkbeteiligung und unterliegt den inhärenten Risiken des zugrunde liegenden Blockchain-Protokolls.
• Marktrisiko: Der Marktwert des SUI-Tokens kann schwanken, was den Gesamtwert Ihrer gestakten Assets beeinflusst.

Technische Exzellenz​

Unternehmensinfrastruktur​

Unsere Validator-Nodes basieren auf einem Fundament technischer Exzellenz. Wir nutzen redundante Systeme, die über mehrere geografische Regionen verteilt sind, um eine hohe Verfügbarkeit zu gewährleisten. Unsere Infrastruktur wird rund um die Uhr überwacht, verfügt über automatisierte Failover-Funktionen und wird von einem professionellen Betriebsteam Tag und Nacht verwaltet. Wir führen außerdem regelmäßige Sicherheitsaudits und Compliance-Prüfungen durch.

Open Source & Transparenz​

Wir bekennen uns zu den Prinzipien von Open Source. Unsere Staking-Integration ist transparent aufgebaut, sodass Benutzer die zugrunde liegenden Prozesse überprüfen können. Echtzeit-Metriken sind auf SUI-Netzwerk-Explorern öffentlich verfügbar, und unsere Gebührenstruktur ist vollständig offen, ohne versteckte Kosten. Wir beteiligen uns auch aktiv an der Community-Governance, um das SUI-Ökosystem zu unterstützen.

Unterstützung des SUI-Ökosystems​

Indem Sie mit BlockEden.xyz staken, tun Sie mehr als nur Belohnungen zu verdienen. Sie tragen aktiv zur Gesundheit und zum Wachstum des gesamten SUI-Netzwerks bei.

• Netzwerksicherheit: Ihr Stake erhöht den Gesamtbetrag, der das SUI-Netzwerk sichert, und macht es robuster gegen potenzielle Angriffe.
• Dezentralisierung: Die Unterstützung unabhängiger Validatoren wie BlockEden.xyz erhöht die Widerstandsfähigkeit des Netzwerks und verhindert Zentralisierung.
• Ökosystem-Wachstum: Die von uns verdienten Provisionsgebühren werden in die Wartung und Entwicklung kritischer Infrastruktur reinvestiert.
• Innovation: Einnahmen unterstützen unsere Forschung und Entwicklung neuer Tools und Dienste für die Blockchain-Community.

Sicherheit & Best Practices​

Bitte priorisieren Sie die Sicherheit Ihrer Assets.

Wallet-Sicherheit​

• Teilen Sie niemals Ihre privaten Schlüssel oder Seed-Phrase mit jemandem.
• Verwenden Sie eine Hardware-Wallet zum Speichern und Staken großer Beträge.
• Überprüfen Sie immer die Transaktionsdetails in Ihrer Wallet, bevor Sie unterschreiben.
• Halten Sie Ihre Wallet-Software auf dem neuesten Stand.

Staking-Sicherheit​

• Wenn Sie neu im Staking sind, beginnen Sie mit einem kleinen Betrag, um sich mit dem Prozess vertraut zu machen.
• Erwägen Sie, Ihren Stake auf mehrere seriöse Validatoren zu diversifizieren, um das Risiko zu reduzieren.
• Überwachen Sie regelmäßig Ihre gestakten Assets und Belohnungen.
• Stellen Sie sicher, dass Sie die Unbonding-Periode verstehen, bevor Sie Ihre Gelder festlegen.

Werden Sie Teil der Zukunft des SUI-Stakings​

Die Einführung des SUI-Stakings auf BlockEden.xyz ist mehr als nur eine neue Funktion; es ist ein Tor zur aktiven Teilnahme an der dezentralen Wirtschaft. Egal, ob Sie ein erfahrener DeFi-Benutzer sind oder gerade erst Ihre Reise beginnen, unsere Plattform bietet eine einfache und sichere Möglichkeit, Belohnungen zu verdienen und gleichzeitig zur Zukunft des SUI-Netzwerks beizutragen.

Bereit, mit dem Verdienen zu beginnen?

Besuchen Sie blockeden.xyz/dash/stake und staken Sie noch heute Ihre ersten SUI-Token!

Über BlockEden.xyz​

BlockEden.xyz ist ein führender Anbieter von Blockchain-Infrastruktur, der Entwicklern, Unternehmen und der gesamten Web3-Community zuverlässige, skalierbare und sichere Dienste anbietet. Von API-Diensten bis hin zu Validator-Operationen setzen wir uns dafür ein, das Fundament für eine dezentrale Zukunft zu legen.

• Gegründet: 2021
• Unterstützte Netzwerke: Über 15 Blockchain-Netzwerke
• Unternehmenskunden: Über 500 Unternehmen weltweit
• Gesamtwert gesichert: Über 100 Mio. USD über alle Netzwerke hinweg

Folgen Sie uns auf Twitter, treten Sie unserem Discord bei und entdecken Sie unser gesamtes Dienstleistungsangebot auf BlockEden.xyz.

Haftungsausschluss: Dieser Blogbeitrag dient ausschließlich zu Informationszwecken und stellt keine Finanzberatung dar. Das Staking von Kryptowährungen birgt Risiken, einschließlich des potenziellen Verlusts des Kapitals. Bitte führen Sie Ihre eigene Recherche durch und berücksichtigen Sie Ihre Risikobereitschaft, bevor Sie staken.

Einleitung​

Die Sui-Blockchain, die nach einem umfangreichen dreistufigen Testnet am 3. Mai 2023 öffentlich gestartet wurde, führte ein innovatives Gaspreissystem ein, das sowohl Benutzern als auch Validatoren zugutekommen soll. Im Mittelpunkt steht der Referenz-Gaspreis (RGP), eine netzwerkweite Basis-Gasgebühr, auf die sich die Validatoren zu Beginn jeder Epoche (ca. 24 Stunden) einigen.

Dieses System zielt darauf ab, ein für SUI-Token-Inhaber, Validatoren und Endbenutzer gleichermaßen vorteilhaftes Ökosystem zu schaffen, indem es niedrige, vorhersehbare Transaktionskosten bietet und gleichzeitig Validatoren für leistungsstarkes und zuverlässiges Verhalten belohnt. Dieser Bericht bietet einen tiefen Einblick in die Bestimmung des RGP, die Berechnungen der Validatoren, seine Auswirkungen auf die Netzwerkökonomie, seine Entwicklung durch Governance und seinen Vergleich mit anderen Blockchain-Gasmodellen.

Der Referenz-Gaspreis (RGP) Mechanismus​

Sui’s RGP ist kein statischer Wert, sondern wird in jeder Epoche durch einen dynamischen, von Validatoren gesteuerten Prozess neu festgelegt.

• Die Gaspreis-Umfrage: Zu Beginn jeder Epoche übermittelt jeder Validator seinen „Reservierungspreis“ – den Mindestgaspreis, den er für die Verarbeitung von Transaktionen zu akzeptieren bereit ist. Das Protokoll ordnet diese Einreichungen dann nach Stake und legt den RGP für diese Epoche auf das Stake-gewichtete 2/3 Perzentil fest. Dieses Design stellt sicher, dass Validatoren, die eine Supermajorität (mindestens zwei Drittel) des gesamten Stakes repräsentieren, bereit sind, Transaktionen zu diesem Preis zu verarbeiten, wodurch ein zuverlässiges Serviceniveau gewährleistet wird.

• Update-Kadenz und Anforderungen: Obwohl der RGP jede Epoche festgelegt wird, müssen Validatoren ihre Angebote aktiv verwalten. Gemäß den offiziellen Richtlinien müssen Validatoren ihr Gaspreisangebot mindestens einmal pro Woche aktualisieren. Wenn es außerdem eine signifikante Änderung des Wertes des SUI-Tokens gibt, wie z. B. eine Schwankung von 20% oder mehr, müssen Validatoren ihr Angebot sofort aktualisieren, um sicherzustellen, dass der RGP die aktuellen Marktbedingungen genau widerspiegelt.

• Die Zählregel und Belohnungsverteilung: Um sicherzustellen, dass Validatoren den vereinbarten RGP einhalten, verwendet Sui eine „Zählregel“. Während einer Epoche überwachen Validatoren die Leistung der anderen und verfolgen, ob ihre Peers RGP-bepreiste Transaktionen umgehend verarbeiten. Diese Überwachung führt zu einer Leistungsbewertung für jeden Validator. Am Ende der Epoche werden diese Bewertungen verwendet, um einen Belohnungsmultiplikator zu berechnen, der den Anteil jedes Validators an den Stake-Belohnungen anpasst.

  • Validatoren, die gut abgeschnitten haben, erhalten einen Multiplikator von ≥1, was ihre Belohnungen erhöht.
  • Validatoren, die Transaktionen zum RGP verzögert, blockiert oder nicht verarbeitet haben, erhalten einen Multiplikator von <1, wodurch ein Teil ihrer Einnahmen effektiv gekürzt wird (Slashing).

Dieses zweiteilige System schafft eine leistungsstarke Anreizstruktur. Es hält Validatoren davon ab, einen unrealistisch niedrigen Preis anzubieten, den sie nicht unterstützen können, da die finanzielle Strafe für Minderleistung schwerwiegend wäre. Stattdessen sind Validatoren motiviert, den niedrigsten Preis anzubieten, den sie nachhaltig und effizient handhaben können.

Validatoren-Operationen: Berechnung des Gaspreis-Angebots​

Aus Sicht eines Validators ist die Festlegung des RGP-Angebots eine kritische operative Aufgabe, die sich direkt auf die Rentabilität auswirkt. Sie erfordert den Aufbau von Datenpipelines und Automatisierungsebenen, um eine Reihe von Eingaben aus On-Chain- und Off-Chain-Quellen zu verarbeiten. Zu den wichtigsten Eingaben gehören:

• Ausgeführte Gaseinheiten pro Epoche
• Staking-Belohnungen und Subventionen pro Epoche
• Beiträge zum Speicherfonds
• Der Marktpreis des SUI-Tokens
• Betriebskosten (Hardware, Cloud-Hosting, Wartung)

Das Ziel ist es, ein Angebot zu berechnen, das positive Nettobelohnungen gewährleistet. Der Prozess umfasst mehrere Schlüsselformeln:

1. Gesamtbetriebskosten berechnen: Dies bestimmt die Ausgaben des Validators in Fiat-Währung für eine bestimmte Epoche.

   $$\text{Kosten}_{\text{Epoche}} = (\text{Gesamte ausgeführte Gaseinheiten}_{\text{Epoche}}) \times (\text{Kosten in \$ pro Gaseinheit}_{\text{Epoche}})$$

2. Gesamtbelohnungen berechnen: Dies bestimmt die Gesamteinnahmen des Validators in Fiat-Währung, die sowohl aus Protokollsubventionen als auch aus Transaktionsgebühren stammen.

   $$\text{\$Belohnungen}_{\text{Epoche}} = (\text{Gesamte Stake-Belohnungen in SUI}_{\text{Epoche}}) \times (\text{SUI Token-Preis})$$

   Wobei Gesamte Stake-Belohnungen die Summe aller vom Protokoll bereitgestellten Stake-Subventionen und der aus Transaktionen gesammelten Gasgebühren ist.

3. Nettobelohnungen berechnen: Dies ist das ultimative Maß für die Rentabilität eines Validators.

   $$\text{\$Nettobelohnungen}_{\text{Epoche}} = \text{\$Belohnungen}_{\text{Epoche}} - \text{\$Kosten}_{\text{Epoche}}$$

   Durch die Modellierung ihrer erwarteten Kosten und Belohnungen bei verschiedenen RGP-Niveaus können Validatoren ein optimales Angebot bestimmen, das sie der Gaspreis-Umfrage unterbreiten.

Beim Mainnet-Start legte Sui den anfänglichen RGP für die ersten ein bis zwei Wochen auf feste 1.000 MIST (1 SUI = 10⁹ MIST) fest. Dies bot den Validatoren eine stabile Betriebsphase, um ausreichende Netzwerkaktivitätsdaten zu sammeln und ihre Berechnungsprozesse zu etablieren, bevor der dynamische Umfragemechanismus voll wirksam wurde.

Auswirkungen auf das Sui-Ökosystem​

Der RGP-Mechanismus prägt die Wirtschaftlichkeit und das Benutzererlebnis des gesamten Netzwerks maßgeblich.

• Für Benutzer: Vorhersehbare und stabile Gebühren: Der RGP dient als glaubwürdiger Anker für Benutzer. Die Gasgebühr für eine Transaktion folgt einer einfachen Formel: Benutzer-Gaspreis = RGP + Trinkgeld. Unter normalen Bedingungen ist kein Trinkgeld erforderlich. Bei Netzwerküberlastung können Benutzer ein Trinkgeld hinzufügen, um Priorität zu erhalten, wodurch ein Gebührenmarkt entsteht, ohne den stabilen Basispreis innerhalb der Epoche zu ändern. Dieses Modell bietet eine deutlich höhere Gebührenstabilität als Systeme, bei denen sich die Basisgebühr mit jedem Block ändert.

• Für Validatoren: Ein Wettlauf um Effizienz: Das System fördert einen gesunden Wettbewerb. Validatoren werden dazu angeregt, ihre Betriebskosten (durch Hardware- und Softwareoptimierung) zu senken, um einen niedrigeren RGP profitabel anbieten zu können. Dieser „Wettlauf um Effizienz“ kommt dem gesamten Netzwerk zugute, indem er die Transaktionskosten senkt. Der Mechanismus drängt Validatoren auch zu ausgewogenen Gewinnmargen; ein zu hohes Angebot birgt das Risiko, aus der RGP-Berechnung herausgepreist zu werden, während ein zu niedriges Angebot zu Betriebsverlusten und Leistungsstrafen führt.

• Für das Netzwerk: Dezentralisierung und Nachhaltigkeit: Der RGP-Mechanismus trägt zur langfristigen Gesundheit des Netzwerks bei. Die „Eintrittsbedrohung“ durch neue, effizientere Validatoren verhindert, dass bestehende Validatoren kolludieren, um die Preise hoch zu halten. Darüber hinaus stellen Validatoren durch die Anpassung ihrer Angebote an den Marktpreis des SUI-Tokens gemeinsam sicher, dass ihre Operationen in realwirtschaftlicher Hinsicht nachhaltig bleiben, wodurch die Gebührenökonomie des Netzwerks vor Token-Preisvolatilität geschützt wird.

Governance und Systementwicklung: SIP-45​

Sui’s Gasmechanismus ist nicht statisch und entwickelt sich durch Governance weiter. Ein prominentes Beispiel ist SIP-45 (Priorisierte Transaktionsübermittlung), das vorgeschlagen wurde, um die gebührenbasierte Priorisierung zu verfeinern.

• Behandeltes Problem: Analysen zeigten, dass die einfache Zahlung eines hohen Gaspreises nicht immer eine schnellere Transaktionsaufnahme garantierte.
• Vorgeschlagene Änderungen: Der Vorschlag umfasste die Erhöhung des maximal zulässigen Gaspreises und die Einführung einer „verstärkten Übertragung“ für Transaktionen, die deutlich über dem RGP liegen (z. B. ≥5x RGP), um deren schnelle Verbreitung im Netzwerk für eine prioritäre Aufnahme zu gewährleisten.

Dies zeigt das Engagement, das Gasmodell auf der Grundlage empirischer Daten zu iterieren, um seine Wirksamkeit zu verbessern.

Vergleich mit anderen Blockchain-Gasmodellen​

Sui’s RGP-Modell ist einzigartig, insbesondere im Vergleich zu Ethereums EIP-1559.

Potenzielle Kritikpunkte und Herausforderungen​

Trotz seines innovativen Designs steht der RGP-Mechanismus vor potenziellen Herausforderungen:

• Komplexität: Das System aus Umfragen, Zählregeln und Off-Chain-Berechnungen ist komplex und kann für neue Validatoren eine Lernkurve darstellen.
• Langsame Reaktion auf Spitzen: Der RGP ist für eine Epoche festgelegt und kann nicht auf plötzliche Nachfragespitzen mitten in der Epoche reagieren, was zu vorübergehender Überlastung führen könnte, bis Benutzer beginnen, Trinkgelder hinzuzufügen.
• Potenzial für Kollusion: Theoretisch könnten Validatoren kolludieren, um einen hohen RGP festzulegen. Dieses Risiko wird hauptsächlich durch die Wettbewerbsnatur des permissionless Validatoren-Sets gemindert.
• Kein Gebühren-Burn: Im Gegensatz zu Ethereum recycelt Sui alle Gasgebühren an Validatoren und den Speicherfonds. Dies belohnt Netzwerkbetreiber, erzeugt aber keinen deflationären Druck auf den SUI-Token, ein Merkmal, das einige Token-Inhaber schätzen.

Häufig gestellte Fragen (FAQ)​

Warum SUI staken? Das Staking von SUI sichert das Netzwerk und bringt Belohnungen ein. Anfangs werden diese Belohnungen von der Sui Foundation stark subventioniert, um die geringe Netzwerkaktivität auszugleichen. Diese Subventionen sinken alle 90 Tage um 10%, wobei erwartet wird, dass die Belohnungen aus Transaktionsgebühren zur primären Ertragsquelle werden. Gestaktes SUI gewährt auch Stimmrechte in der On-Chain-Governance.

Kann mein gestaktes SUI geslasht werden? Ja. Während die Parameter noch finalisiert werden, gilt das „Tally Rule Slashing“. Ein Validator, der von 2/3 seiner Peers eine Null-Leistungsbewertung erhält (aufgrund geringer Leistung, böswilligen Verhaltens usw.), wird seine Belohnungen um einen noch festzulegenden Betrag gekürzt sehen. Staker können auch Belohnungen verpassen, wenn ihr gewählter Validator Ausfallzeiten hat oder einen suboptimalen RGP anbietet.

Werden Staking-Belohnungen automatisch zusammengesetzt? Ja, Staking-Belohnungen auf Sui werden jede Epoche automatisch verteilt und erneut gestaked (zusammengesetzt). Um auf Belohnungen zuzugreifen, müssen Sie diese explizit entstaken.

Was ist die Sui Unbonding-Periode? Anfangs können Staker ihre Token sofort entstaken. Es wird erwartet, dass eine Unbonding-Periode, in der Token nach dem Entstaken für eine festgelegte Zeit gesperrt sind, implementiert wird und der Governance unterliegen wird.

Behalte ich die Verwahrung meiner SUI-Token beim Staking? Ja. Wenn Sie SUI staken, delegieren Sie Ihren Stake, behalten aber die volle Kontrolle über Ihre Token. Sie übertragen niemals die Verwahrung an den Validator.

Wie man Wallet-Reibung reduziert, den Benutzerfluss aufrechterhält und das Potenzial prognostiziert

Was wäre, wenn Ihre Web3-App den gleichen nahtlosen Anmeldevorgang hätte wie ein moderner Web2-Dienst? Das ist das Kernversprechen von zkLogin auf der Sui-Blockchain. Es funktioniert wie OAuth für Sui und ermöglicht es Benutzern, sich mit vertrauten Konten von Google, Apple, X und weiteren anzumelden. Ein Zero-Knowledge-Proof verknüpft dann diese Web2-Identität sicher mit einer On-Chain-Sui-Adresse – keine Wallet-Pop-ups, keine Seed-Phrasen, kein Benutzerabgang.

Die Auswirkungen sind real und unmittelbar. Mit Hunderttausenden von bereits aktiven zkLogin-Konten berichten Fallstudien von massiven Zuwächsen bei der Benutzerkonversion, die nach der Beseitigung traditioneller Wallet-Barrieren von mageren 17 % auf gesunde 42 % anstieg. Lassen Sie uns aufschlüsseln, wie es funktioniert und was es für Ihr Projekt tun kann.

Warum Wallets die Erstkonversion töten​

Sie haben eine bahnbrechende dApp entwickelt, aber Ihr Benutzerakquisitions-Funnel leckt. Der Schuldige ist fast immer derselbe: der "Connect Wallet"-Button. Das standardmäßige Web3-Onboarding ist ein Labyrinth aus Erweiterungsinstallationen, Seed-Phrasen-Warnungen und Krypto-Jargon-Quizzen.

Es ist eine massive Barriere für Neulinge. UX-Forscher beobachteten einen erstaunlichen 87 %igen Rückgang in dem Moment, in dem eine Wallet-Aufforderung erschien. In einem aufschlussreichen Experiment führte die einfache Umleitung dieser Aufforderung auf eine spätere Phase des Checkout-Prozesses dazu, dass die Abschlussrate auf 94 % stieg. Selbst für krypto-interessierte Benutzer ist die Hauptangst: „Ich könnte meine Gelder verlieren, wenn ich auf den falschen Button klicke.“ Das Entfernen dieses einen, einschüchternden Schritts ist der Schlüssel zur Erschließung exponentiellen Wachstums.

Wie zkLogin funktioniert (einfach erklärt)​

zkLogin umgeht das Wallet-Problem elegant, indem es Technologien verwendet, denen jeder Internetnutzer bereits vertraut. Die Magie geschieht hinter den Kulissen in wenigen schnellen Schritten:

1. Ephemeres Schlüsselpaar: Wenn ein Benutzer sich anmelden möchte, wird ein temporäres, sitzungsbezogenes Schlüsselpaar lokal in seinem Browser generiert. Stellen Sie es sich wie einen temporären Passkey vor, der nur für diese Sitzung gültig ist.
2. OAuth-Prozess: Der Benutzer meldet sich mit seinem Google-, Apple- oder einem anderen Social-Konto an. Ihre App bettet geschickt einen eindeutigen Wert (Nonce) in diese Anmeldeanfrage ein.
3. ZKP-Dienst: Nach einer erfolgreichen Anmeldung generiert ein ZKP (Zero-Knowledge Proof)-Dienst einen kryptografischen Beweis. Dieser Beweis bestätigt: „Dieses OAuth-Token autorisiert den Besitzer des temporären Passkeys,“ ohne jemals die persönliche Identität des Benutzers On-Chain preiszugeben.
4. Adresse ableiten: Das JWT (JSON Web Token) des Benutzers vom OAuth-Anbieter wird mit einem eindeutigen Salt kombiniert, um seine permanente Sui-Adresse deterministisch zu generieren. Der Salt wird privat gehalten, entweder Client-seitig oder in einem sicheren Backend.
5. Transaktion übermitteln: Ihre App signiert Transaktionen mit dem temporären Schlüssel und fügt den ZK-Proof bei. Sui-Validatoren überprüfen den Proof On-Chain und bestätigen die Legitimität der Transaktion, ohne dass der Benutzer jemals eine traditionelle Wallet benötigt.

Schritt-für-Schritt-Integrationsanleitung​

Bereit zur Implementierung? Hier ist eine Kurzanleitung mit dem TypeScript SDK. Die Prinzipien sind für Rust oder Python identisch.

1. SDK installieren​

Das @mysten/sui-Paket enthält alle zklogin-Helfer, die Sie benötigen.

pnpm add @mysten/sui

2. Schlüssel und Nonce generieren​

Erstellen Sie zunächst ein ephemeres Schlüsselpaar und eine Nonce, die an die aktuelle Epoche im Sui-Netzwerk gebunden ist.

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

3. Weiterleitung zu OAuth​

Erstellen Sie die entsprechende OAuth-Anmelde-URL für den von Ihnen verwendeten Anbieter (z. B. Google, Facebook, Apple) und leiten Sie den Benutzer weiter.

4. JWT dekodieren & Benutzer-Salt abrufen​

Nachdem sich der Benutzer angemeldet und zurückgeleitet wurde, rufen Sie das id_token aus der URL ab. Verwenden Sie es, um den benutzerspezifischen Salt von Ihrem Backend abzurufen, und leiten Sie dann seine Sui-Adresse ab.

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-Proof anfordern​

Senden Sie das JWT an einen Prover-Dienst, um den ZK-Proof zu erhalten. Für die Entwicklung können Sie den öffentlichen Prover von Mysten verwenden. In der Produktion sollten Sie Ihren eigenen hosten oder einen Dienst wie Enoki nutzen.

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

6. Signieren & Senden​

Erstellen Sie nun Ihre Transaktion, legen Sie den Absender auf die zkLogin-Adresse des Benutzers fest und führen Sie sie aus. Das SDK übernimmt das automatische Anhängen der zkLoginInputs (des Proofs). ✨

const tx = new TransactionBlock();
tx.moveCall({ target:'0x2::example::touch_grass' }); // Beliebiger Move-Aufruf
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof // Die Magie geschieht hier
});

7. Sitzung beibehalten​

Für eine reibungslosere Benutzererfahrung verschlüsseln und speichern Sie das Schlüsselpaar und den Salt in IndexedDB oder im lokalen Speicher. Denken Sie daran, diese alle paar Epochen zu rotieren, um die Sicherheit zu erhöhen.

KPI-Prognosevorlage​

Der Unterschied, den zkLogin macht, ist nicht nur qualitativ, sondern auch quantifizierbar. Vergleichen Sie einen typischen Onboarding-Funnel mit einem zkLogin-gestützten:

👉 Was das bedeutet: Für eine Kampagne, die 10.000 einzelne Besucher anzieht, ist das der Unterschied zwischen 300 On-Chain-Aktionen am ersten Tag und über 2.500.

Best Practices & Fallstricke​

Um ein noch nahtloseres Erlebnis zu schaffen, beachten Sie diese Profi-Tipps:

• Gesponserte Transaktionen nutzen: Bezahlen Sie die ersten Transaktionsgebühren Ihrer Benutzer. Dies beseitigt jegliche Reibung und sorgt für einen unglaublichen "Aha"-Moment.
• Salts sorgfältig behandeln: Das Ändern des Salts eines Benutzers generiert eine neue Adresse. Tun Sie dies nur, wenn Sie einen zuverlässigen Wiederherstellungspfad für sie kontrollieren.
• Sui-Adresse offenlegen: Zeigen Sie den Benutzern nach der Anmeldung ihre On-Chain-Adresse. Dies ermöglicht fortgeschrittenen Benutzern, diese später bei Bedarf in eine traditionelle Wallet zu importieren.
• Refresh-Loops verhindern: Cachen Sie das JWT und das ephemere Schlüsselpaar, bis sie ablaufen, um zu vermeiden, dass der Benutzer wiederholt zur Anmeldung aufgefordert wird.
• Prover-Latenz überwachen: Behalten Sie die Roundtrip-Zeit der Proof-Generierung im Auge. Wenn sie 2 Sekunden überschreitet, sollten Sie die Bereitstellung eines regionalen Provers in Betracht ziehen, um die Geschwindigkeit zu gewährleisten.

Wo BlockEden.xyz Mehrwert schafft​

Während zkLogin den benutzerseitigen Ablauf perfektioniert, bringt die Skalierung neue Backend-Herausforderungen mit sich. Hier kommt BlockEden.xyz ins Spiel.

• API-Schicht: Unsere hochdurchsatzstarken, geo-gerouteten RPC-Knoten stellen sicher, dass Ihre zkLogin-Transaktionen mit minimaler Latenz verarbeitet werden, unabhängig vom Standort des Benutzers.
• Observability: Erhalten Sie sofort einsatzbereite Dashboards, um wichtige Metriken wie Proof-Latenz, Erfolgs-/Fehlerraten und die Gesundheit Ihres Konversions-Funnels zu verfolgen.
• Compliance: Für Apps, die in Fiat-Währungen überbrücken, bietet unser optionales KYC-Modul einen konformen On-Ramp direkt von der verifizierten Identität des Benutzers.

Bereit zum Start?​

Die Ära der klobigen, einschüchternden Wallet-Abläufe ist vorbei. Starten Sie eine zkLogin-Sandbox, schließen Sie BlockEdens Full-Node-Endpunkt an und beobachten Sie, wie Ihre Anmeldekurve nach oben zeigt – während Ihre Benutzer das Wort „Wallet“ nie hören müssen. 😉

1. Liquidität und Wachstum von Sui DeFi​

Abbildung: Suis DeFi TVL (blaue Linie) und DEX-Volumen (grüne Balken) wuchsen im 2. Quartal 2025 dramatisch.

Anstieg des Total Value Locked (TVL): Die DeFi-Liquidität des Sui-Netzwerks ist im vergangenen Jahr explosionsartig gewachsen. Von etwa 600 Millionen US-Dollar TVL Ende 2024 stieg Suis TVL bis Mitte 2025 auf über 2 Milliarden US-Dollar an. Tatsächlich erreichte Sui am 21. Mai 2025 einen Höchststand von etwa 2,55 Milliarden US-Dollar TVL und hielt sich im gesamten 2. Quartal deutlich über 2 Milliarden US-Dollar. Dieser Anstieg von ca. 300 % (ein Anstieg von 480 % im Jahresvergleich seit Mai 2023) positioniert Sui fest unter den Top 10 Blockchains nach DeFi TVL und übertrifft das Wachstum von Netzwerken wie Solana. Wichtige Katalysatoren waren die institutionelle Akzeptanz und die Integration der nativen USDC Stablecoin-Unterstützung, die zusammen große Kapitalzuflüsse anzogen. Insbesondere sind Suis monatliche DEX-Handelsvolumina in die Spitzengruppe aller Chains aufgestiegen – bis Mitte 2025 überstiegen sie 7–8 Milliarden US-Dollar pro Monat (branchenweit auf Platz 8). Die umlaufende Stablecoin-Liquidität auf Sui überstieg Mitte 2025 1 Milliarde US-Dollar, nachdem sie seit Jahresbeginn um 180 % gewachsen war, was auf eine Vertiefung der On-Chain-Liquidität hindeutet. Auch Cross-Chain-Kapital fließt ein; rund 2,7 Milliarden US-Dollar an Vermögenswerten wurden in Suis Ökosystem überbrückt, einschließlich Bitcoin-Liquidität (Details siehe unten). Dieser schnelle Wachstumstrend unterstreicht ein Jahr der Nettozuflüsse und Nutzererweiterung für Sui DeFi.

Wichtige DEXs und Liquiditätsanbieter: Dezentrale Börsen bilden das Rückgrat der Sui DeFi-Liquidität. Das Cetus-Protokoll – ein Automated Market Maker (AMM) und Aggregator – war eine Flaggschiff-DEX, die Stablecoin-Swaps und konzentrierte Liquiditätspools anbot. Cetus führt konstant im Volumen (allein im 2. Quartal 2025 wurden über 12,8 Milliarden US-Dollar an Trades abgewickelt) und hält dabei rund 80 Millionen US-Dollar TVL. Ein weiterer wichtiger Akteur ist Bluefin, eine vielseitige DEX, die sowohl einen Spot-AMM als auch eine Perpetual Futures Exchange betreibt. Bluefin erweiterte sein Angebot im Jahr 2025 mit innovativen Funktionen: Es führte BluefinX ein, Suis erstes RFQ-System (Request-for-Quote) für eine verbesserte Preisausführung, und integrierte sogar Optimierungen für den Hochfrequenzhandel, um die Lücke zwischen DEX- und CEX-Performance zu schließen. Bis zum 2. Quartal hielt Bluefins AMM etwa 91 Millionen US-Dollar TVL und verzeichnete über 7,1 Milliarden US-Dollar an vierteljährlichem Spot-Volumen. Momentum ist eine weitere aufstrebende DEX – sie startete einen Concentrated Liquidity Market Maker (CLMM), der kurz nach dem Start schnell 107 Millionen US-Dollar an Liquidität ansammelte und rund 4,6 Milliarden US-Dollar an Handelsvolumen generierte. Der Sui DEX-Sektor umfasst auch MovEX (eine hybride AMM + Orderbuch-Börse) und Turbos (ein früher CLMM-Anwender) und andere, die jeweils zur vielfältigen Liquiditätslandschaft beitragen. Bemerkenswert ist, dass Sui ein natives On-Chain Central Limit Order Book namens DeepBook unterstützt, das gemeinsam mit MovEX entwickelt wurde und jeder Sui dApp eine gemeinsame Orderbuch-Liquidität bietet. Diese Kombination aus AMMs, Aggregatoren und einem On-Chain-CLOB verleiht Sui eines der robustesten DEX-Ökosysteme im DeFi-Bereich.

Kreditmärkte und Yield-Protokolle: Suis Kredit- und Leihplattformen haben erhebliches Kapital angezogen und machen einen großen Anteil des TVL aus. Das Suilend-Protokoll sticht als Suis größte DeFi-Plattform hervor, mit rund über 700 Millionen US-Dollar TVL bis zum 2. Quartal 2025 (nachdem es Anfang 2025 die 1-Milliarde-US-Dollar-Marke überschritten hatte). Suilend ist eine Erweiterung von Solanas Solend, die auf Suis Move-Laufzeitumgebung gebracht wurde, und entwickelte sich schnell zum Flaggschiff-Geldmarkt auf Sui. Es bietet Einzahlungs- und besicherte Kreditdienste für Vermögenswerte wie SUI und USDC und hat durch die Einführung von Begleitprodukten Innovationen hervorgebracht – zum Beispiel SpringSui (ein Liquid Staking Modul) und STEAMM, ein AMM, der die „superfluide“ Nutzung von Liquidität innerhalb der Plattform ermöglicht. Durch die Gamifizierung der Nutzerbindung (durch Punktkampagnen und NFTs) und die Ausgabe eines Governance-Tokens $SEND mit Umsatzbeteiligung trieb Suilend eine schnelle Akzeptanz voran – bis Mitte 2025 wurden über 50.000 monatlich aktive Wallets gemeldet. Dicht hinter Suilend folgt das Navi Protocol (auch als Astros bezeichnet), das in seinen Kreditpools ebenfalls etwa 600–700 Millionen US-Dollar TVL erreichte. Navi hebt sich ab, indem es Kreditmärkte mit Yield-Strategien und sogar Bitcoin DeFi-Integration verbindet: Zum Beispiel ermöglichte Navi eine Kampagne für Nutzer, xBTC (einen BTC-Proxy auf Sui) über die OKX Wallet zu staken, um Bitcoin-Inhaber zur Teilnahme an Sui-Yield-Möglichkeiten zu motivieren. Andere bemerkenswerte Kreditplattformen sind Scallop (ca. 146 Millionen US-Dollar TVL) und AlphaLend (ca. 137 Millionen US-Dollar), die zusammen einen wettbewerbsintensiven Markt für Kreditaufnahme und -vergabe auf Sui anzeigen. Auch die Yield-Aggregation hat begonnen, sich durchzusetzen – Protokolle wie AlphaFi und Kai Finance verwalten jeweils zig Millionen an Vermögenswerten (z.B. ca. 40 Millionen US-Dollar TVL), um den Ertrag über Sui-Farms hinweg zu optimieren. Obwohl kleiner im Umfang, verleihen diese Yield-Optimierer und strukturierten Produkte (z.B. MovEXs strukturierte Yield-Vaults) Suis DeFi-Angeboten Tiefe, indem sie Nutzern helfen, die Renditen aus der wachsenden Liquiditätsbasis zu maximieren.

Liquid Staking und Derivate: Parallel dazu stellen Suis Liquid Staking Derivatives (LSDs) und Derivate-Handelsplattformen einen wichtigen Teil der Liquidität des Ökosystems dar. Da Sui eine Proof-of-Stake-Chain ist, haben Protokolle wie SpringSui, Haedal und Volo Token eingeführt, die gestakte SUI umschließen und es Stakern ermöglichen, liquide zu bleiben. SpringSui – vom Suilend-Team gestartet – wurde schnell zum dominierenden LSD und hielt bis Ende des 2. Quartals etwa 189 Millionen US-Dollar an gestakter SUI. Zusammen mit Haedal (150 Millionen US-Dollar) und anderen ermöglichen Suis LSD-Plattformen Nutzern, Validator-Belohnungen zu verdienen, während sie Staking-Token wieder in DeFi einsetzen (zum Beispiel gestakte SUI als Kreditsicherheit oder in Yield-Farms verwenden). Im Derivatebereich beherbergt Sui nun mehrere On-Chain Perpetual Futures Exchanges. Wir haben bereits Bluefins Perp DEX (Bluefin Perps) erwähnt, der Milliarden an vierteljährlichem Volumen abwickelte. Zusätzlich startete Typus Finance im 2. Quartal 2025 Typus Perp (TLP) und trat mit einem beeindruckenden Debüt in Suis Perps-Markt ein. Sudo (mit seiner ZO-Protokollintegration) führte gamifizierte Perpetual Swaps und „intelligente“ gehebelte Produkte ein, wodurch seine Nutzerbasis und Liquidität im letzten Quartal um über 100 % wuchsen. Das Magma-Protokoll entwickelte sogar ein neues AMM-Modell – einen Adaptive Liquidity Market Maker (ALMM) – mit dem Ziel, Trades ohne Slippage und eine höhere Kapitaleffizienz bei Swaps zu erreichen. Diese innovativen DEX- und Derivate-Designs ziehen eigene Liquidität an (z.B. verdoppelte sich Magmas TVL im 2. Quartal) und stärken Suis Ruf als Testumgebung für DeFi-Primitive der nächsten Generation.

Trends bei Kapitalzuflüssen und Nutzern: Der allgemeine Liquiditätstrend auf Sui war stark positiv, angetrieben sowohl von Privat- als auch von institutionellen Zuflüssen. Suis wachsende Glaubwürdigkeit (z.B. HSBC und DBS Bank als Netzwerk-Validatoren) und hohe Leistung haben neues Kapital angezogen. Ein signifikanter Teil der in Sui überbrückten Vermögenswerte sind Blue-Chip-Token und Stablecoins – zum Beispiel wurde Circles USDC nativ auf Sui eingeführt, und Tethers USDT wurde über Bridges verfügbar, was zu einer robusten Stablecoin-Mischung führte (USDC ca. 775 Millionen US-Dollar, USDT ca. 100 Millionen US-Dollar im Umlauf bis zum 2. Quartal). Am bemerkenswertesten ist vielleicht, dass Bitcoin-Liquidität in großem Umfang in Sui eingetreten ist (über Wrapped oder gestakte BTC – detailliert in Abschnitt 3), was über 10 % des TVL ausmacht. Auf der Nutzerseite haben verbesserte Wallet-Unterstützung und Abstraktion (siehe Abschnitt 2) die Akzeptanz gefördert. Die beliebte Phantom Wallet (mit ca. 7 Millionen Nutzern) erweiterte die Unterstützung auf Sui, was es der breiten Krypto-Community erleichtert, auf Sui dApps zuzugreifen. Ähnlich integrierten zentralisierte Börsen-Wallets wie OKX und Binance Sui DeFi-Funktionen (z.B. fügte Binances Chrome-Wallet eine Simple Yield-Integration mit Suis Scallop-Protokoll hinzu). Diese On-Ramps trugen zum Nutzerwachstum von Sui bei: Anfang 2025 hatte Sui Hunderttausende aktiver Adressen, und Top-dApps wie Suilend melden Zehntausende monatlicher Nutzer. Insgesamt tendierte die Liquidität auf Sui im Jahr 2025 nach oben, unterstützt durch konstante Zuflüsse und eine wachsende Nutzerbeteiligung – ein starker Kontrast zur Stagnation, die auf einigen anderen Chains im gleichen Zeitraum zu beobachten war.

2. Abstraktion: Vereinfachung der Benutzererfahrung auf Sui​

Funktionen der Kontoabstraktion: Ein Eckpfeiler von Suis Design ist die Kontoabstraktion, die die Benutzerfreundlichkeit erheblich verbessert, indem sie Endnutzern die Komplexität der Blockchain verbirgt. Im Gegensatz zu traditionellen Layer-1s, bei denen Benutzer für jede Transaktion Schlüssel und Gas verwalten müssen, ermöglicht Sui eine reibungslosere Erfahrung durch native Funktionen. Insbesondere unterstützt Sui Anmeldungen mit Drittanbieter-Anmeldeinformationen und Gas-Sponsoring auf Protokollebene. Entwickler können zkLogin integrieren – wodurch Benutzer eine Sui-Wallet erstellen und sich mit vertrauten Web2-Anmeldeinformationen (Google, Facebook, Twitch usw.) anstelle von Seed-Phrasen anmelden können. Gleichzeitig bietet Sui gesponserte Transaktionen an, was bedeutet, dass dApp-Entwickler Gasgebühren im Namen der Benutzer über einen On-Chain-„Tankstellen“-Mechanismus bezahlen können. Zusammen beseitigen zkLogin und Gas-Sponsoring zwei große Probleme (Verwaltung von Seed-Phrasen und Erwerb nativer Token) für neue Benutzer. Ein Sui-Benutzer kann sich zum Beispiel mit einer E-Mail/einem Passwort (über OAuth) anmelden und sofort eine DeFi-App nutzen, ohne dass SUI-Token im Voraus benötigt werden. Dieses Maß an Abstraktion spiegelt die Web2-Benutzerfreundlichkeit wider und war entscheidend für die Aufnahme der „nächsten Welle“ von Benutzern, die eine reibungslose Anmeldung und kostenlose Testphasen erwarten. Viele Sui-Apps und sogar Web3-Spiele nutzen diese Funktionen jetzt – eine kürzlich gestartete NFT-Spielveröffentlichung prahlte mit einem „Zero-Wallet-Login“-Flow für Spieler, angetrieben durch Suis Kontoabstraktion und Social-Login-Fähigkeiten. Insgesamt senkt Sui durch die Automatisierung der Schlüsselverwaltung und Gas-Handhabung die Eintrittsbarriere für DeFi erheblich, was wiederum zu einer höheren Benutzerbindung und -aktivität führt.

Smart Contract Abstraktion und Move: Über Login und Transaktionen hinaus bietet Suis objektorientiertes Programmiermodell Abstraktion auf Smart-Contract-Ebene. Suis native Move-Sprache behandelt Objekte (nicht extern besessene Konten) als grundlegende Speichereinheit, mit reichhaltigen Metadaten und flexiblen Eigentümerstrukturen. Das bedeutet, Entwickler können Smart-Contract-Objekte erstellen, die als Proxys für Benutzerkonten fungieren und Aufgaben automatisieren, die traditionell Benutzerunterschriften erfordern würden. Zum Beispiel kann eine App auf Sui ein programmierbares Objekt bereitstellen, um wiederkehrende Zahlungen oder komplexe mehrstufige Trades im Namen eines Benutzers abzuwickeln, ohne dass dieser Benutzer jeden Schritt manuell initiiert. Diese Objekte können Berechtigungen und Logik enthalten, wodurch wiederholende Aktionen für den Endbenutzer effektiv abstrahiert werden. Zusätzlich führte Sui Programmierbare Transaktionsblöcke (PTBs) ein, um mehrere Operationen in einer einzigen Transaktionsnutzlast zu bündeln. Anstatt von einem Benutzer zu verlangen, 3–4 separate Transaktionen zu signieren und zu senden (z.B. Token genehmigen, dann tauschen, dann staken), kann ein Sui PTB diese Schritte zusammenfassen und alle auf einmal ausführen. Dies reduziert nicht nur Reibung und Bestätigungsaufforderungen für den Benutzer, sondern verbessert auch die Leistung (weniger On-Chain-Transaktionen bedeuten geringere Gesamtgasgebühren und schnellere Ausführung). Aus der Sicht des Benutzers kann sich eine komplexe Reihe von Aktionen wie eine reibungslose Interaktion anfühlen – eine entscheidende Verbesserung der UX. Suis Move wurde mit dieser Komponierbarkeit und Abstraktion im Hinterkopf entwickelt und ermöglicht es Entwicklern, dApps zu erstellen, die sich viel mehr wie traditionelle Fintech-Apps anfühlen. Als zusätzlichen Bonus unterstützt Suis kryptografische Agilität mehrere Signaturschemata (Ed25519, secp256k1 usw.), was es Wallets ermöglicht, verschiedene Schlüsseltypen (einschließlich derer, die auf Ethereum oder Bitcoin verwendet werden) zu verwenden. Diese Flexibilität erleichtert die Integration von Sui-Funktionalität in Multi-Chain-Wallets und bereitet sogar den Boden für quantenresistente Kryptografie in der Zukunft.

Cross-Chain Abstraktion – Intents und Integration: Sui leistet auch Pionierarbeit bei der Cross-Chain-Benutzererfahrung durch Abstraktion. Ein Paradebeispiel ist die Integration von NEAR Intents, einem neuartigen Cross-Chain-Koordinationssystem, in Suis Ökosystem im Juli 2025. Mit dieser Integration können Sui-Benutzer nahtlos Vermögenswerte über 20+ andere Chains (einschließlich Ethereum, Bitcoin, Solana, Avalanche usw.) in einem einzigen Schritt tauschen, ohne manuelles Bridging. Das zugrunde liegende „Intent“-Modell bedeutet, dass der Benutzer einfach ausdrückt, was er möchte (z.B. „1 ETH auf Ethereum gegen SUI auf Sui tauschen“), und ein Netzwerk von automatisierten Solvern findet den effizientesten Weg, diese Anfrage über Chains hinweg zu erfüllen. Der Benutzer muss nicht mehr mehrere Wallets oder Gasgebühren auf verschiedenen Netzwerken jonglieren – das System abstrahiert all das. Das Tauschen von Vermögenswerten in Sui wird so einfach wie eine Ein-Klick-Transaktion, ohne dass Gas-Token auf der Quell-Chain gehalten werden müssen. Dies ist ein signifikanter UX-Sprung für Cross-Chain DeFi. Bis Mitte 2025 war NEAR Intents live, und Sui-Benutzer konnten externe Liquidität innerhalb von Sekunden einbringen, was Anwendungsfälle wie Cross-Chain-Arbitrage und die Aufnahme von Vermögenswerten von Nicht-Sui-Inhabern mit praktisch keiner Reibung oder Verwahrungsrisiko ermöglichte. Vertreter der Sui Foundation betonten, dass „das Tauschen nativer Vermögenswerte mit einem Klick… die Komplexität abstrahiert, während alles On-Chain, sicher und komponierbar bleibt“. Parallel dazu profitierte Sui von wichtigen Wallet-Integrationen, die die Komplexität für Benutzer verbergen. Wie bereits erwähnt, unterstützt Phantoms Multi-Chain-Wallet jetzt Sui, und andere beliebte Wallets wie OKX und Binance Wallet haben eine integrierte Unterstützung für Sui dApps. Zum Beispiel ermöglicht Binances Wallet Benutzern den direkten Zugriff auf Yield-Farms auf Sui (über Scallop) über eine einfache Benutzeroberfläche, und OKXs Wallet integrierte Suis BTC-Staking-Flows (Navis xBTC) nativ. Diese Integrationen bedeuten, dass Benutzer mit Sui DeFi interagieren können, ohne Apps wechseln oder sich um technische Details kümmern zu müssen – ihre vertraute Wallet abstrahiert es für sie. All diese Bemühungen, von Intents-basierten Swaps bis hin zu Wallet-UIs, dienen dem Ziel, Cross-Chain- und On-Chain-DeFi auf Sui mühelos erscheinen zu lassen. Das Ergebnis ist, dass Sui nicht nur für Krypto-Natives, sondern auch für Mainstream-Benutzer, die Einfachheit fordern, zunehmend zugänglich ist.