Beitrag
Teile dein Wissen.
👀 SEAL- Ich denke, der Datenschutz bei Web3 wird sich bald ändern
👀 SEAL ist live auf Sui Testnet — ich denke, der Datenschutz bei Web3 wird sich bald ändern
Im Web3 hört man häufig Ausdrücke wie** „Die Nutzer besitzen ihre Daten“** oder** „von Natur aus dezentralisiert“**. Aber wenn Sie genau hinschauen, verlassen sich viele Anwendungen immer noch auf zentralisierte Infrastrukturen, um sensible Daten zu verarbeiten — und nutzen Dienste wie AWS oder Google Cloud für die Schlüsselverwaltung. Dies führt zu einem Widerspruch: Dezentralisierung an der Oberfläche, Zentralisierung unter der Oberfläche.
Aber was wäre, wenn es eine Möglichkeit gäbe, Geheimnisse sicher zu verwalten, ohne die Dezentralisierung aufzugeben? Wir stellen vor: SEAL — Decentralized Secrets Management (DSM), das jetzt live im Sui Testnet verfügbar ist. SEAL hat sich zum Ziel gesetzt, eine der größten Heucheleien von Web3 zu beheben: die Zurufe nach Dezentralisierung und der heimlichen Nutzung von AWS
Du fragst mich vielleicht: Was ist SEAL?
SEAL ist ein Protokoll, mit dem Sie sensible Daten sicher unddezentralverwalten können — speziell für die Web3-Welt entwickelt. Stellen Sie sich das als eine Zugriffskontrollschicht vor, bei der der Datenschutz an erster Stelle steht und in Ihre DApp integriert wird.
Du kannst dir SEAL als eine Art programmierbares Schloss für deine Daten vorstellen. Sie sperren und entsperren Dinge nicht einfach manuell — Sieschreiben mithilfe von Move on Sui Richtlinien direkt in Ihre Smart Contracts.
Nehmen wir an, Sie erstellen eine dApp, bei der:
- Nur NFT-Inhaber können ein Premium-Tutorial freischalten
- Oder vielleicht muss ein DAO abstimmen, bevor sensible Dateien aufgedeckt werden
- Oder Sie möchten, dass Metadaten zeitgebunden sind und erst nach einem bestimmten Datum zugänglich sind
SEAL macht all das möglich. Die Zugriffskontrolle erfolgt onchain, vollständig automatisiert, sodass kein Administrator sie verwalten muss. Nur Logik, direkt in die Blockchain integriert.
SEAL macht all das möglich. Die Zugriffskontrolle erfolgt onchain, vollständig automatisiert, sodass kein Administrator sie verwalten muss. Nur Logik, direkt in die Blockchain integriert.
Ein weiterer interessanter Artikel ist, wie SEAL mitVerschlüsselungumgeht. Es verwendet eine sogenannteSchwellenwertverschlüsselung, was bedeutet: Kein einzelner Knoten kann die Daten entschlüsseln. Es braucht eine Gruppe von Servern, um zusammenzuarbeiten — quasi wie Multi-Sig, nur um Geheimnisse zu entsperren. Das verteilt Vertrauen und vermeidet das übliche Single-Point-of-Failure-Problem.
Und um die Dinge wirklich geheim zu halten, verschlüsselt und entschlüsselt SEAL allesauf der Clientseite. Ihre Daten sind für kein Backend sichtbar. Sie bleiben — im wahrsten Sinne des Wortes — in Ihren Händen auf Ihrem Gerät.
und SEAL ist es egal, wo Sie Ihre Daten speichern. Ob es sich um IPFS, Arweave, Walrus oder eine andere Plattform handelt, SEAL versucht nicht, diesen Teil zu kontrollieren. Es konzentriert sich nur darauf,wer was sehen darf, nicht darauf, wo Dinge aufbewahrt werden.
Also ja, es ist nicht nur eine Bibliothek oder API — es ist eineonchain first, zugriffskontrollierte, standardmäßige Datenschutzebenefür deine dApp.
SEAL füllt eine ziemlich kritische Lücke. Lassen Sie uns das etwas genauer aufschlüsseln.
Wenn Sie eine dApp erstellen, die sich mitjeder Form vertraulicher Datenbefasst — geschützte Inhalte, Benutzerdokumente, verschlüsselte Nachrichten, sogar zeitgesperrte NFT-Metadaten —, werden Sie auf dasselbe Problem stoßen:
➡️ Wie verwalten Sie den Zugriff sicher, ohne sich auf einen zentralen Dienst verlassen zu müssen?
Ohne so etwas wie SEAL können die meisten Teams entweder:
- Verwenden Sie zentralisierte Tools wie AWS KMS oder Firebase, was eindeutig gegen die Dezentralisierung verstößt
- Oder versuchen Sie, eine unausgegorene Verschlüsselungslogik selbst zusammenzusetzen, was sich in der Regel als spröde herausstellt und schwer zu überprüfen ist
Keines davon skaliert gut. Vor allem nicht, wenn Sie versuchen, vertrauenswürdige Apps über mehrere Ketten oder Communities hinweg zu entwickeln.
SEAL macht den gesamten Prozess modular und programmierbar.
Sie definieren Ihre Zugriffsregeln in Move Smart Contracts, und SEAL kümmert sich um den Rest — Schlüsselgenerierung, Entschlüsselungsgenehmigungen und Zugriffsdurchsetzung — alles, ohne dass jemand manuell Schlüssel ausstellt oder Backend-Checks durchführt.
Und was noch besser ist: Diese Regeln sindüberprüfbar und unveränderlich— sobald sie online sind, folgen sie dem Vertrag, nicht einem menschlichen Administrator.
Anstatt also zu fragen, „wer sollte den Zugriff auf diese Daten verwalten?“ du fragst einfach:
„Welche Logik sollte den Zugriff definieren?“
... und lass die Kette das erledigen. Sauber und skalierbar.
Das macht SEAL für mehr als nur „Sicherheitstools“ relevant — es ist eine Basisebene fürjede dApp, die Wert auf Datenschutz, Compliance oder dynamische Zugriffslogik legt.
Es ist eine kleine Veränderung — aber sie ändert viel daran, wie wir Daten in Web3 betrachten. Anstatt nach der Bereitstellung zu verschlüsseln oder sich auf externe Dienste zu verlassen,beginnen Sie mit integriertem Datenschutz — und der Zugriff wird vollständig über eine intelligente Vertragslogik abgewickelt.
Und genau das braucht Web3 gerade.
Wie funktioniert SEAL eigentlich?
Wir haben behandelt, was SEAL istundwarum Web3 es braucht**. Schauen wir uns an, wie es tatsächlich unter der Haube aufgebaut ist. In diesem Teil werden die Dinge technischer — aber auf eine gute Art und Weise. Die Architektur ist elegant, wenn man sieht, wie alle Teile zusammenpassen.
Auf einer hohen Ebene kombiniert SEALOnchain-Access-LogikmitOff-Chain-Schlüsselmanagement. Dabei wird eine Technik namensIdentity-Based Encryption (IBE) verwendet. Auf diese Weise können Entwickler Daten zu einer Identität verschlüsseln und sich dann auf intelligente Verträge verlassen, um zu definieren, wer sie entschlüsseln dürft.
Schritt 1: Zugriffsregeln in Smart Contracts (auf Sui)
Alles beginnt mit dem Smart Contract. Wenn Sie SEAL verwenden, definieren Sie in Ihrem Move-Vertrag eine Funktion namens seal_approve — hier schreiben Sie Ihre Bedingungen für die Entschlüsselung.
Hier ist zum Beispiel eine einfache Time-Lock-Regel, die in Move geschrieben wurde:
entry fun seal_approve(id: vector<u8>, c: &clock::Clock) {
let mut prepared: BCS = bcs::new(id);
let t = prepared.peel_u64();
let leftovers = prepared.into_remainder_bytes();
assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess);
}
Einmal eingesetzt, fungiert dieser Vertrag als Gatekeeper. Immer wenn jemand Daten entschlüsseln möchte, wird seine Anfrage anhand dieser Logik überprüft. Wenn es erfolgreich ist, wird der Schlüssel freigegeben. Wenn nicht, sind sie blockiert. Niemand muss eingreifen.
##Schritt 2: Identitätsbasierte Verschlüsselung (IBE)
Hier passiert die Magie.
Anstatt Daten für eine bestimmte Wallet-Adresse zu verschlüsseln (wie bei PGP oder RSA), verwendet SEALIdentitätszeichenfolgen— das heißt, Sie verschlüsseln mit etwas wie:
- 0 x Wallet-Adresse
- dao_voted:proposal_xyz
- pkgID_2025_05_01 (eine auf Zeitstempeln basierende Regel)
- oder sogar game_user_nft_holder
Wenn die Daten verschlüsselt sind, sieht das so aus:
Encrypt(mpk, identity, message)
- mpk = öffentlicher Hauptschlüssel (allen bekannt)
- Identität = der durch die Logik definierte Empfänger
- Nachricht = die tatsächlichen Daten
Wenn später jemand entschlüsseln möchte, prüft der Schlüsselserver, ob sie der Richtlinie entsprechen (über den Aufruf seal_approve in der Kette). Wenn es genehmigt wird, gibt es einen abgeleiteten privaten Schlüssel für diese Identität zurück.
Derive(msk, identity) → sk
Decrypt(sk, encrypted_data)
Der Benutzer kann den Inhalt dann lokal entschlüsseln.
Die Verschlüsselung erfolgt also, ohne dass man im Voraus wissen muss, wer entschlüsselt. Sie definieren einfach die Bedingungen und SEAL findet den Rest später heraus. Es ist dynamisch.
##Schritt 3: Der Schlüsselserver — Offchain, aber nicht zentralisiert
Sie fragen sich vielleicht: Wer besitzt diese Hauptschlüssel?
An dieser Stelle kommt derKey Servervon SEAL ins Spiel. Stellen Sie sich das als ein Backend vor, das:
- Enthält den geheimen Hauptschlüssel (msk)
- Überwacht On-Chain-Verträge (wie deine seal_approve-Logik)
- Gibt abgeleitete Schlüssel nur aus, wenn die Bedingungen erfüllt sind
Aber — und das ist entscheidend — SEAL ist nicht nur auf einen Schlüsselserver angewiesen. Sie können ihn imSchwellenwertmodusausführen, in dem sich mehrere unabhängige Server einigen müssen, bevor ein Entschlüsselungsschlüssel ausgegeben wird.
Beispiel: 3 von 5 Schlüsselservern müssen die Anfrage genehmigen. Dadurch werden zentrale Fehlerquellen vermieden und eine Dezentralisierung auch auf der Schlüsselverwaltungsebene ermöglicht.
Und was noch besser ist: SEAL wird in ZukunftMPC (Multi-Party Computation) undEnklave-basierte Setups(wie TEE) unterstützen — so können Sie noch bessere Garantien erhalten, ohne die Benutzerfreundlichkeit zu beeinträchtigen.
##Schritt 4: Clientseitige Entschlüsselung
Sobald der Schlüssel an den Benutzer zurückgegeben wurde, erfolgt die eigentliche Entschlüsselungauf seinem Gerät. Das bedeutet:
- Der Server sieht niemals deine Daten
- Das Backend speichert niemals entschlüsselte Inhalte
- Nur der Benutzer kann auf die endgültige Nachricht zugreifen
Es ist ein solides Datenschutzmodell. Selbst wenn jemand die Speicherebene (IPFS, Arweave usw.) kompromittiert, kann er die Daten immer noch nicht lesen, ohne die Zugriffslogik zu übergeben.
Hier ist das schnelle mentale Modell:
Diese Struktur macht es einfach, DApps zu erstellen, bei denen die Zugriffsregeln nicht fest codiert sind — sie sind dynamisch, überprüfbar und vollständig in Ihre Kettenlogik integriert.
##Das Team hinter SEAL
SEAL wird vonSamczsungeleitet, einer bekannten Persönlichkeit in der Blockchain-Sicherheitsgemeinschaft. Ehemals Forschungspartner bei Paradigm hat er mehrere Ökosysteme geprüft und vor größeren Exploits bewahrt. Jetzt konzentriert er sich in Vollzeit darauf, SEAL zu einem Kernstück der Datenschutzinfrastruktur von Web3 zu machen.
Mit seinem Hintergrund und seiner Glaubwürdigkeit ist SEAL nicht nur ein weiteres experimentelles Tool — es ist ein ernsthafter Versuch, den dezentralen Datenschutz sowohl praktisch als auch skalierbar zu machen.
Da SEAL im Sui Testnet live geht, wird ein neuer Standard dafür eingeführt, wie Web3-Anwendungen Geheimnisse verwalten können. Durch die Kombination von On-Chain-Zugriffskontrolle, Schwellenwertverschlüsselung und clientseitigem Datenschutz bietet SEAL eine vertrauenswürdigere Grundlage für die dezentrale Datenverarbeitung.
Egal, ob Sie DApps, DAOs oder dezentrale Spiele entwickeln — SEAL bietet ein leistungsstarkes Toolkit, um die Zugriffskontrolle durchzusetzen und Benutzerdaten zu schützen, ohne Kompromisse bei der Dezentralisierung einzugehen.
Wenn Web3 voranschreiten soll, ist eine sichere Infrastruktur wie SEAL nicht optional — sie ist unerlässlich
- Sui
- Architecture
- SDKs and Developer Tools
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.