Cara membuat token account dengan ekstensi Confidential Transfer
Ekstensi Confidential Transfer memungkinkan transfer token secara privat dengan menambahkan state tambahan pada token account. Bagian ini menjelaskan cara membuat token account dengan ekstensi ini diaktifkan.
Diagram berikut menunjukkan langkah-langkah yang terlibat dalam membuat token account dengan ekstensi Confidential Transfer:
State Token Account Confidential Transfer
Ekstensi ini menambahkan state ConfidentialTransferAccount pada token account:
#[repr(C)]#[derive(Clone, Copy, Debug, Default, PartialEq, Pod, Zeroable)]pub struct ConfidentialTransferAccount {/// `true` if this account has been approved for use. All confidential/// transfer operations for the account will fail until approval is/// granted.pub approved: PodBool,/// The public key associated with ElGamal encryptionpub elgamal_pubkey: PodElGamalPubkey,/// The low 16 bits of the pending balance (encrypted by `elgamal_pubkey`)pub pending_balance_lo: EncryptedBalance,/// The high 48 bits of the pending balance (encrypted by `elgamal_pubkey`)pub pending_balance_hi: EncryptedBalance,/// The available balance (encrypted by `encryption_pubkey`)pub available_balance: EncryptedBalance,/// The decryptable available balancepub decryptable_available_balance: DecryptableBalance,/// If `false`, the extended account rejects any incoming confidential/// transferspub allow_confidential_credits: PodBool,/// If `false`, the base account rejects any incoming transferspub allow_non_confidential_credits: PodBool,/// The total number of `Deposit` and `Transfer` instructions that have/// credited `pending_balance`pub pending_balance_credit_counter: PodU64,/// The maximum number of `Deposit` and `Transfer` instructions that can/// credit `pending_balance` before the `ApplyPendingBalance`/// instruction is executedpub maximum_pending_balance_credit_counter: PodU64,/// The `expected_pending_balance_credit_counter` value that was included in/// the last `ApplyPendingBalance` instructionpub expected_pending_balance_credit_counter: PodU64,/// The actual `pending_balance_credit_counter` when the last/// `ApplyPendingBalance` instruction was executedpub actual_pending_balance_credit_counter: PodU64,}
ConfidentialTransferAccount berisi beberapa field untuk mengelola transfer
rahasia:
-
approved: Status persetujuan akun untuk transfer rahasia. Jika konfigurasi
auto_approve_new_accountspada mint account diatur sebagaitrue, semua token account disetujui secara otomatis untuk transfer rahasia. -
elgamal_pubkey: Kunci publik ElGamal yang digunakan untuk mengenkripsi saldo dan jumlah transfer.
-
pending_balance_lo: 16 bit bawah terenkripsi dari saldo yang tertunda. Saldo dibagi menjadi bagian tinggi dan rendah untuk dekripsi yang efisien.
-
pending_balance_hi: 48 bit atas terenkripsi dari saldo yang tertunda. Saldo dibagi menjadi bagian tinggi dan rendah untuk dekripsi yang efisien.
-
available_balance: Saldo terenkripsi yang tersedia untuk transfer.
-
decryptable_available_balance: Saldo yang tersedia yang dienkripsi dengan kunci Advanced Encryption Standard (AES) untuk dekripsi yang efisien oleh pemilik akun.
-
allow_confidential_credits: Jika bernilai true, mengizinkan transfer rahasia masuk.
-
allow_non_confidential_credits: Jika bernilai true, mengizinkan transfer non-rahasia masuk.
-
pending_balance_credit_counter: Menghitung kredit saldo tertunda yang masuk dari instruksi deposit dan transfer.
-
maximum_pending_balance_credit_counter: Batas jumlah kredit tertunda sebelum memerlukan instruksi
ApplyPendingBalanceuntuk mengonversi saldo tertunda menjadi saldo yang tersedia. -
expected_pending_balance_credit_counter: Nilai
pending_balance_credit_counteryang diberikan oleh klien melalui instruction data terakhir kali instruksiApplyPendingBalancediproses. -
actual_pending_balance_credit_counter: Nilai
pending_balance_credit_counterpada token account pada saat instruksiApplyPendingBalanceterakhir diproses.
Saldo Tertunda vs Saldo Tersedia
Saldo rahasia dipisahkan menjadi saldo tertunda dan saldo tersedia untuk mencegah serangan DoS. Tanpa pemisahan ini, penyerang dapat berulang kali mengirim token ke token account, menghalangi kemampuan pemilik token account untuk memindahkan token. Pemilik token account tidak akan dapat memindahkan token karena saldo terenkripsi akan berubah antara saat transaksi dikirimkan dan saat diproses, yang mengakibatkan transaksi gagal.
Semua deposit dan jumlah transfer awalnya ditambahkan ke saldo tertunda. Pemilik
token account harus menggunakan instruksi ApplyPendingBalance untuk
mengonversi saldo tertunda menjadi saldo tersedia. Transfer atau deposit masuk
tidak memengaruhi saldo tersedia pada token account.
Pemisahan Saldo Tertunda Tinggi/Rendah
Saldo tertunda rahasia dibagi menjadi pending_balance_lo dan
pending_balance_hi karena dekripsi ElGamal memerlukan lebih banyak komputasi
untuk angka yang lebih besar. Anda dapat menemukan implementasi aritmetika
ciphertext
di sini,
yang digunakan dalam instruksi ApplyPendingBalance
di sini.
Penghitung Kredit Saldo Tertunda
Saat memanggil instruksi ApplyPendingBalance untuk mengonversi saldo
tertunda menjadi saldo tersedia:
-
Klien mencari saldo tertunda dan tersedia saat ini, mengenkripsi jumlahnya, dan menyediakan
decryptable_available_balanceyang dienkripsi menggunakan kunci AES pemilik token account. -
Penghitung kredit tertunda yang diharapkan dan aktual melacak perubahan pada nilai penghitung antara saat instruksi
ApplyPendingBalancedibuat dan diproses:expected_pending_balance_credit_counter: Nilaipending_balance_credit_countersaat klien membuat instruksiApplyPendingBalanceactual_pending_balance_credit_counter: Nilaipending_balance_credit_counterpada token account pada saat instruksiApplyPendingBalancediproses
Pencocokan antara counter expected/actual menunjukkan bahwa
decryptable_available_balance sesuai dengan available_balance.
Saat mengambil status token account untuk membaca
decryptable_available_balance, perbedaan nilai counter expected/actual
mengharuskan klien untuk mencari instruksi deposit/transfer terbaru yang sesuai
dengan selisih counter tersebut guna menghitung saldo yang benar.
Proses Rekonsiliasi Saldo
Ketika counter pending balance expected dan actual berbeda, ikuti
langkah-langkah berikut untuk merekonsiliasi decryptable_available_balance:
- Mulai dengan
decryptable_available_balancedari token account - Ambil transaksi terbaru termasuk instruksi deposit dan transfer hingga
selisih counter (actual - expected):
- Tambahkan jumlah publik dari instruksi deposit
- Dekripsi dan tambahkan jumlah ciphertext tujuan dari instruksi transfer
Instruksi yang Diperlukan
Membuat dan mengonfigurasi token account untuk transfer rahasia menggunakan instruksi-instruksi berikut, yang semuanya dapat dimuat dalam satu transaksi:
-
Buat Token Account: Panggil instruksi
AssociatedTokenAccountInstruction::Createmilik Associated Token Program untuk membuat token account pada alamat deterministiknya. -
Realokasi Ruang Akun: Panggil instruksi
TokenInstruction::Reallocatemilik Token Extension Program untuk menambahkan ruang bagi statusConfidentialTransferAccount. -
Verifikasi Bukti Validitas Pubkey: Buat akun yang dimiliki oleh program ZK ElGamal Proof, lalu panggil instruksi
VerifyPubkeyValidity-nya untuk memverifikasi bukti dan menyimpan hasil terverifikasi di akun status konteks tersebut. -
Konfigurasi Transfer Rahasia: Panggil instruksi ConfidentialTransferInstruction::ConfigureAccount milik Token Extension Program, dengan mereferensikan akun status konteks bukti melalui
ProofLocation::ContextStateAccount, untuk menginisialisasi statusConfidentialTransferAccount.
Hanya pemilik token account yang dapat mengkonfigurasi token account untuk confidential transfers.
Instruksi ConfigureAccount memerlukan pembuatan kunci enkripsi dan bukti
di sisi klien yang hanya dapat dibuat oleh pemilik token account.
Bukti validitas pubkey memverifikasi bahwa kunci publik ElGamal akun tersebut
valid. Bukti ini dibuat dengan build_pubkey_validity_proof_data,
diverifikasi di dalam rantai oleh program ZK ElGamal Proof ke dalam akun status
konteks, kemudian direferensikan dari ConfigureAccount melalui
ProofLocation::ContextStateAccount, sehingga tidak ada byte bukti yang
melewati instruksi token itu sendiri. Untuk detail implementasi, lihat:
Contoh Kode
Kode berikut membuat associated token account dan mengonfigurasinya untuk transfer rahasia terhadap mint rahasia yang sudah ada.
Transfer rahasia bergantung pada program ZK ElGamal Proof, yang diaktifkan di
mainnet dan devnet. solana-test-validator standar tidak mengaktifkannya,
tetapi validator lokal yang mem-fork mainnet seperti
Surfpool mengaktifkannya. Jalankan contoh ini terhadap
salah satunya (kode menggunakan devnet) dengan payer yang memiliki saldo, dan
ganti placeholder mint dengan mint yang dibuat sesuai
Buat Mint.
Rust
// The native ZK ElGamal Proof program verifies the proof on chain.const ZK_PROOF_PROGRAM_ID: Pubkey =solana_pubkey::pubkey!("ZkE1Gama1Proof11111111111111111111111111111");fn main() -> Result<()> {// Use a cluster whose ZK ElGamal Proof program is enabled (mainnet, devnet).let rpc_client = RpcClient::new_with_commitment(String::from("https://api.devnet.solana.com"),CommitmentConfig::confirmed(),);// The Solana CLI default keypair, used as fee payer, mint authority, and// token account owner.let payer = load_keypair()?;let decimals: u8 = 2;// Setup: create a confidential mint for the token account.let mint = create_confidential_mint(&rpc_client, &payer, decimals)?;let token_account = get_associated_token_address_with_program_id(&payer.pubkey(),&mint,&spl_token_2022::id(),);// 1. Create the associated token account.let create_ata_ix = create_associated_token_account(&payer.pubkey(), // funding account&payer.pubkey(), // token account owner&mint,&spl_token_2022::id(),);// 2. Add space for the ConfidentialTransferAccount extension.let realloc_ix = reallocate(&spl_token_2022::id(),&token_account,&payer.pubkey(), // payer&payer.pubkey(), // owner&[&payer.pubkey()],&[ExtensionType::ConfidentialTransferAccount],)?;// 3. Derive the owner's ElGamal keypair and AES key from a signature over// the token account address. The same signer and address always derive// the same keys, so the owner can recover them from their wallet.let (elgamal_keypair, aes_key) = derive_confidential_keys(&payer, &token_account.to_bytes()).map_err(|e| anyhow::anyhow!("derive confidential keys: {e}"))?;// Initial decryptable available balance of 0, encrypted with the AES key.let decryptable_balance: PodAeCiphertext = aes_key.encrypt(0).into();let maximum_pending_balance_credit_counter: u64 = 65_536;// 4. Generate the pubkey-validity proof, then pre-verify it into a context// state account owned by the ZK ElGamal Proof program. configure_account// references the verified proof by account, so no proof bytes travel in// the token instruction itself.let proof_data = build_pubkey_validity_proof_data(&elgamal_keypair).map_err(|e| anyhow::anyhow!("generate pubkey validity proof: {e}"))?;let proof_account = Keypair::new();let context_state_size = size_of::<ProofContextState<PubkeyValidityProofContext>>();let context_state_rent =rpc_client.get_minimum_balance_for_rent_exemption(context_state_size)?;let create_proof_account_ix = system_instruction::create_account(&payer.pubkey(),&proof_account.pubkey(),context_state_rent,context_state_size as u64,&ZK_PROOF_PROGRAM_ID,);let proof_account_address: Address = proof_account.pubkey().to_bytes().into();let owner_address: Address = payer.pubkey().to_bytes().into();let verify_proof_ix = ProofInstruction::VerifyPubkeyValidity.encode_verify_proof(Some(ContextStateInfo {context_state_account: &proof_account_address,context_state_authority: &owner_address,}),&proof_data,);// 5. Configure the account, pointing at the pre-verified proof account.let proof_location: ProofLocation<PubkeyValidityProofData> =ProofLocation::ContextStateAccount(&proof_account.pubkey());let configure_account_ixs = configure_account(&spl_token_2022::id(),&token_account,&mint,&decryptable_balance,maximum_pending_balance_credit_counter,&payer.pubkey(), // owner&[],proof_location,)?;// Everything fits in a single transaction.let mut instructions = vec![create_ata_ix,realloc_ix,create_proof_account_ix,verify_proof_ix,];instructions.extend(configure_account_ixs);let blockhash = rpc_client.get_latest_blockhash()?;let transaction = Transaction::new_signed_with_payer(&instructions,Some(&payer.pubkey()),&[&payer, &proof_account],blockhash,);let signature = rpc_client.send_and_confirm_transaction(&transaction)?;println!("Configured token account {token_account} for confidential transfers: {signature}");Ok(())}
Typescript
const client = await createClient().use(signerFromFile(join(homedir(), ".config/solana/id.json"))).use(solanaRpc({rpcUrl: "https://api.devnet.solana.com"}));// The Solana CLI default keypair, used as fee payer, mint authority, and// token account owner.const owner = client.payer;const decimals = 2;// Setup: create a confidential mint for the token account.const mint = await createConfidentialMint(client, owner, decimals);const [tokenAccount] = await findAssociatedTokenPda({owner: owner.address,tokenProgram: TOKEN_2022_PROGRAM_ADDRESS,mint});// Derive recoverable ElGamal and AES keys bound to (owner, mint). Re-deriving// from the same wallet always yields the same keys, so the owner can recover// them rather than having to back up a separate secret.const derivedElGamal = await deriveElGamalKeypairForOwnerMint({signer: owner,owner: owner.address,mint});const elgamalKeypair = ElGamalKeypair.fromSecretKey(ElGamalSecretKey.fromBytes(derivedElGamal.secretKey));const aesKey = AeKey.fromBytes(await deriveAeKeyForOwnerMint({ signer: owner, owner: owner.address, mint }));// Build the create-ATA + reallocate + verify-proof + configure plan, then send.// The helper returns an instruction plan because the steps may span more than// one transaction.const plan = await getCreateConfidentialTransferAccountInstructionPlan({rpc: client.rpc,payer: owner,owner,mint,elgamalKeypair,aesKey});const result = await client.sendTransaction(plan);console.log(`Configured token account ${tokenAccount} for confidential transfers: ${result.context.signature}`);
Helper TypeScript tersedia di subpath
@solana-program/token-2022/confidential dan dibangun di atas
@solana/zk-sdk untuk primitif enkripsi. owner dan client berasal dari
pengaturan @solana/kit Anda; rencana instruksi yang dikembalikan dikirim
dengan dukungan rencana instruksi milik @solana/kit, yang membagi pekerjaan
ke dalam beberapa transaksi ketika bukti terlalu besar untuk satu transaksi.
Is this page helpful?