Leitfaden für Aussteller von Confidential Transfer

Ausgabe von Confidential Transfer Tokens auf Solana

Dieser Leitfaden richtet sich an Aussteller: Teams, die einen Token-2022-Mint erstellen und betreiben, der die Confidential Transfer-Erweiterung verwendet. Er behandelt die Entscheidungen, die Sie bei der Mint-Erstellung treffen, sowie die Vorgänge, die Sie während der Lebensdauer des Mints durchführen. Informationen zum Ablauf auf Halterseite (Einzahlung, Anwenden, Übertragung, Auszahlung) finden Sie in den Schritt-für-Schritt-Seiten, und zur Unterstützung dieser Tokens in einem Produkt lesen Sie den Integration Guide.

Vertrauliche Übertragungen halten Übertragungs­beträge und Konten­salden verschlüsselt, während Kontenadressen, der Mint und die Eigentümer öffentlich bleiben. Sie basieren auf dem ZK ElGamal Proof Program zur Onchain-Proof-Verifizierung, sodass der Mint auf Clustern verwendet werden kann, auf denen dieses Programm aktiviert ist.

Verfügbarkeit

Vertrauliche Übertragungen erfordern das Token-2022 program@v11.0.0 oder höher. Sie sind heute im Devnet verfügbar und sollen im Juni 2026 im Mainnet aktiviert werden. Das Token Extensions Program wird separat auf jedem Cluster deployed, daher sollten Sie das Deployment auf dem von Ihnen verwendeten Cluster bestätigen.

Entscheidungen bei der Erstellung

Die Confidential Transfer-Erweiterung muss vor der Initialisierung des Mints initialisiert werden und kann nicht nachträglich hinzugefügt werden. Bei der Erstellung entscheiden Sie:

  • Genehmigungsrichtlinie: ob Konten sich ohne Genehmigung in vertrauliche Übertragungen einwählen dürfen (auto) oder durch die Confidential Transfer-Autorität des Mints genehmigt werden müssen (manual).
  • Prüfer: ob ein globaler ElGamal-pubkey für einen Prüfer festgelegt werden soll, damit eine bestimmte Partei jeden Übertragungsbetrag für den Mint entschlüsseln kann. Optional und kann später geändert werden.
  • Optionale Begleiterweiterungen: vertrauliche Übertragungs-Fee (kombiniert mit der Übertragungs-Fee-Erweiterung) und vertrauliche Prägung/Verbrennung, beide werden unten behandelt. Diese müssen ebenfalls bei der Erstellung initialisiert werden.

Eine vertrauliche Mint erstellen

Die CLI legt die Genehmigungsrichtlinie mit --enable-confidential-transfers auto oder manual fest; auto erlaubt jedem Inhaber, sein eigenes Konten selbst zu konfigurieren, während manual dies hinter der Genehmigung durch die Confidential-Transfer-Autorität absichert (die standardmäßig der Mint-Autorität entspricht). Die Client-Pfade verwenden dieselben Einstellungen über die ConfidentialTransferMint-Parameter: eine Autorität, das Auto-Approve-Flag und einen optionalen Auditor-Schlüssel. Sowohl die Genehmigungsrichtlinie als auch der Auditor können später geändert werden (siehe Einen Auditor konfigurieren); nur das Vorhandensein der Erweiterung selbst ist bei der Erstellung festgelegt.

$ spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-confidential-transfers auto

Einen Auditor konfigurieren

Ein globaler Auditor ist ein ElGamal-pubkey, der auf der Mint gespeichert ist. Wenn er gesetzt ist, verschlüsselt jeder vertrauliche Transfer seinen Betrag zusätzlich unter diesem Schlüssel, sodass derjenige, der den entsprechenden geheimen Schlüssel besitzt, alle Transferbeträge für die Mint entschlüsseln kann. So bleiben vertrauliche Transfers mit Prüf- und Compliance-Anforderungen kompatibel: Die Öffentlichkeit sieht nichts, der Auditor sieht alles.

Die Confidential-Transfer-Autorität kann den Auditor jederzeit festlegen, rotieren oder entfernen. Dieselbe Operation aktualisiert auch die Genehmigungsrichtlinie. In der CLI ist der Auditor-Schlüssel eine Base64-Kodierung eines ElGamal-pubkey; übergeben Sie --auditor-pubkey none, um ihn zu entfernen, und --approve-policy auto|manual, um die Richtlinie zu ändern.

Die Rotation betrifft nur zukünftige Transfers. Beträge in bereits auf der Chain befindlichen Transaktionen bleiben mit dem Auditor-Schlüssel verschlüsselt, der zum Zeitpunkt ihrer Ausführung aktiv war. Bewahren Sie daher alte Auditor-Schlüssel auf, wenn Sie historische Aktivitäten entschlüsseln müssen.

$ spl-token update-confidential-transfer-settings <MINT_PUBKEY> --auditor-pubkey <AUDITOR_ELGAMAL_PUBKEY>

Der geheime Auditor-Schlüssel kann jeden Transferbetrag für die Mint entschlüsseln. Verwahren Sie ihn mit derselben Sorgfalt wie einen Signaturschlüssel, und planen Sie eine Rotation ein. Den Auditor auf None zu setzen deaktiviert die Betragstransparenz für alle außer den Konten- Inhabern selbst.

Konten genehmigen (manuelle Richtlinie)

Bei einer manuellen Genehmigungsrichtlinie kann ein Konto, das für vertrauliche Überweisungen konfiguriert ist, erst dann vertraulich Transaktionen durchführen, wenn die Autorität für vertrauliche Überweisungen es genehmigt. Dies gibt Ausstellern eine Kontrollmöglichkeit für Allowlist- oder KYC-geprüfte Teilnehmer. Die CLI stellt keinen Genehmigungsbefehl bereit, daher erfolgt die Genehmigung über einen Client.

token
.confidential_transfer_approve_account(
&token_account,
&authority,
&[&authority_keypair],
)
.await?;

Fee für vertrauliche Überweisungen

Wenn Ihr Mint eine Überweisungsgebühr erhebt und Überweisungen vertraulich sind, muss die Fee ebenfalls vertraulich einbehalten werden. Die Erweiterung ConfidentialTransferFeeConfig übernimmt dies und wird bei der Mint-Erstellung zusammen mit der Überweisungsgebühr- und der Vertrauliche-Überweisungen-Erweiterung initialisiert.

Einbehaltene Fee akkumulieren verschlüsselt auf Empfänger-Konten, werden zum Mint übertragen und anschließend von der Autorität zum Abheben einbehaltener Beträge ausgezahlt. Jeder Fee-Betrag bleibt dabei durchgehend verschlüsselt. All dies ist über die CLI nicht zugänglich. Der ElGamal-Geheimschlüssel der Autorität zum Abheben einbehaltener Beträge kann einbehaltene Fee-Beträge entschlüsseln, was in Kombination mit den öffentlichen Fee-Parametern Rückschlüsse auf Überweisungsbeträge ermöglichen kann – behandeln Sie diesen Schlüssel daher als vertraulich.

Fee-Konfiguration initialisieren

Fügen Sie dies zusammen mit ConfidentialTransferMint und der Überweisungsgebühren-Konfiguration in derselben Mint-Erstellung ein.

use spl_token_client::token::ExtensionInitializationParams;
ExtensionInitializationParams::ConfidentialTransferFeeConfig {
authority: Some(authority.pubkey().into()),
withdraw_withheld_authority_elgamal_pubkey: withdraw_withheld_elgamal_pubkey,
};

Einbehaltene Fee einsammeln und abheben

Das Einsammeln verschiebt die verschlüsselten einbehaltenen Fee von Konten in den Mint; das Abheben verschiebt sie aus dem Mint auf ein gewähltes Konto. Zwei Autoritäten sind beteiligt, von denen jede von der Mint-Autorität abweichen kann:

  • Die Autorität für vertrauliche Überweisungsgebühren (das authority, das auf ConfidentialTransferFeeConfig gesetzt ist) aktiviert oder deaktiviert das Einsammeln.
  • Die Autorität zum Abheben einbehaltener Beträge (aus dem TransferFeeConfig der Überweisungsgebührenerweiterung) hebt die eingesammelten Fee aus dem Mint ab.

Abhebungen erfordern einen Gleichheits- und einen Bereichsnachweis, der inline bereitgestellt oder in Kontextzustands-Konten verifiziert wird.

// Permissionless: move withheld fees from accounts into the mint.
token
.confidential_transfer_harvest_withheld_tokens_to_mint(&[&source_account])
.await?;
// Withdraw withheld fees from the mint (requires the withdraw withheld authority).
token
.confidential_transfer_withdraw_withheld_tokens_from_mint(
&destination_account,
&withdraw_withheld_authority,
None, // proof context state account, supplied inline if None
None, // withheld tokens info, fetched if None
&withdraw_withheld_elgamal_keypair,
&destination_elgamal_pubkey,
&new_decryptable_available_balance,
&[&withdraw_withheld_authority_keypair],
)
.await?;

Im JS-Client erfordert das Abheben der geernteten Fee aus dem Mint (getWithdrawWithheldTokensFromMintForConfidentialTransferFeeInstruction) zusätzlich einen Gleichheits- und einen Bereichsnachweis, der in Kontextzustands-Konten verifiziert wird. Daher folgt es demselben Nachweis-Konten-Muster wie eine vertrauliche Übertragung.

Vertrauliches Prägen und Verbrennen

Die Erweiterung ConfidentialMintBurn ermöglicht es der Mint-Autorität, Angebot direkt gegen vertrauliche Salden auszugeben und zu verbrennen, wobei das Gesamtangebot verschlüsselt bleibt. Ein Mint mit dieser Erweiterung deaktiviert den öffentlichen Einzahlungs- und Abhebungspfad, da Token ausschließlich vertraulich existieren. Siehe die Protokolldokumentation für das vollständige Modell.

Vertrauliches Prägen/Verbrennen ist am einfachsten über den Rust spl-token-client, der die erforderlichen Nachweise generiert und die Transaktionen für Sie sequenziert. Der @solana-program/token-2022 JS-Client liefert die Low-Level-Anweisungen-Builder (getConfidentialMintInstruction, getConfidentialBurnInstruction und weitere), aber keinen High-Level-Helfer zum Erstellen der Nachweise, und es gibt keine CLI-Befehle, daher sind die folgenden Beispiele nur in Rust.

Initialisieren Sie die Erweiterung bei der Mint-Erstellung, und prägen, verbrennen und gleichen Sie das Angebot dann im Laufe der Zeit ab. Beim Prägen wird ein verschlüsselter Betrag in das vertrauliche Guthaben eines Empfängers ausgegeben; beim Verbrennen wird ein verschlüsselter Betrag in ein ausstehendes Verbrennen überführt, das später in das Angebot eingerechnet wird. Beide Vorgänge erzeugen Nachweise wie bei einer vertraulichen Übertragung.

confidential-mint-burn.rs
use spl_token_client::token::ExtensionInitializationParams;
// 1. Initialize at creation (alongside ConfidentialTransferMint).
ExtensionInitializationParams::ConfidentialMintBurn {
supply_elgamal_pubkey, // encrypts the confidential supply
decryptable_supply, // AES ciphertext of the initial supply (zero)
};
// 2. Mint an encrypted amount into a recipient's confidential balance.
token
.confidential_transfer_mint(
&mint_authority,
&destination_account,
None, // equality proof account
None, // ciphertext validity proof account
None, // range proof account
mint_amount,
&supply_elgamal_keypair,
&destination_elgamal_pubkey,
auditor_elgamal_pubkey, // Option
&supply_aes_key,
None, // supply account info, fetched if None
&[&mint_authority_keypair],
)
.await?;
// 3. Burn an encrypted amount from a holder's confidential balance into the
// mint's pending burn. Generates proofs like a confidential transfer.
token
.confidential_transfer_burn(
&owner,
&source_account,
None, // equality proof account
None, // ciphertext validity proof account
None, // range proof account
burn_amount,
&source_elgamal_keypair,
&supply_elgamal_pubkey,
auditor_elgamal_pubkey, // Option
&source_aes_key,
None, // burn account info, fetched if None
&[&owner_keypair],
)
.await?;
// 4. Fold the accumulated pending burn into the confidential supply.
token
.confidential_transfer_apply_pending_burn(&mint_authority, &[&mint_authority_keypair])
.await?;

Rotieren Sie den Angebots-Verschlüsselungsschlüssel mit confidential_transfer_rotate_supply_elgamal_pubkey (das ausstehende Verbrennen muss zuvor null sein), und aktualisieren Sie den lesbaren Angebots-Chiffretext mit confidential_transfer_update_decrypt_supply.

Betriebs- und Compliance-Überlegungen

  • Verwahrung des Prüfer-Schlüssels. Wenn Sie einen Prüfer festlegen, ist der geheime Prüfer-Schlüssel ein hochwertiger Entschlüsselungsschlüssel. Verwahren und rotieren Sie ihn sorgfältig, und legen Sie fest, wer in Ihrer Organisation (oder welche Regulierungsbehörde) ihn besitzt.
  • Compliance-Haltung. Adressen-Screening und die Analyse des Gegenpartei-Graphen funktionieren weiterhin, da Adressen öffentlich bleiben. Die betragsbasierte Überwachung hängt vom Prüfer-Schlüssel oder von der selektiven Offenlegung durch Konten-Inhaber ab. Legen Sie Ihren Ansatz vor dem Launch fest.
  • Onboarding von Inhabern. Die Konfiguration eines vertraulichen Konten erfordert die Unterschrift des Eigentümers. Um Konten für Benutzer reibungslos bereitzustellen, lassen Sie diese einmalig einen ElGamal-Schlüssel registrieren und verwenden Sie den Registry-Pfad, der im Integrationsleitfaden beschrieben ist.
  • Transaktionsanzahl. Eine vertrauliche Übertragung umfasst derzeit mehrere abhängige Transaktionen, da die Nachweise das aktuelle Transaktionsgrößenlimit überschreiten. Das Transaktionsformat v1 (wird mit Agave v4.2 eingeführt) erhöht dieses Limit und soll eine einzelne Onchain-Transaktion ermöglichen.

Is this page helpful?

© 2026 Solana Foundation. Alle Rechte vorbehalten.