Membuat token account

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:

Create Token Account with Confidential Transfer Extension

State Token Account Confidential Transfer

Ekstensi ini menambahkan state ConfidentialTransferAccount pada token account:

Confidential Token Account State
#[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 encryption
pub 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 balance
pub decryptable_available_balance: DecryptableBalance,
/// If `false`, the extended account rejects any incoming confidential
/// transfers
pub allow_confidential_credits: PodBool,
/// If `false`, the base account rejects any incoming transfers
pub 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 executed
pub maximum_pending_balance_credit_counter: PodU64,
/// The `expected_pending_balance_credit_counter` value that was included in
/// the last `ApplyPendingBalance` instruction
pub expected_pending_balance_credit_counter: PodU64,
/// The actual `pending_balance_credit_counter` when the last
/// `ApplyPendingBalance` instruction was executed
pub 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_accounts pada mint account diatur sebagai true, 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 ApplyPendingBalance untuk mengonversi saldo tertunda menjadi saldo yang tersedia.

  • expected_pending_balance_credit_counter: Nilai pending_balance_credit_counter yang diberikan oleh klien melalui instruction data terakhir kali instruksi ApplyPendingBalance diproses.

  • actual_pending_balance_credit_counter: Nilai pending_balance_credit_counter pada token account pada saat instruksi ApplyPendingBalance terakhir 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:

  1. Klien mencari saldo tertunda dan tersedia saat ini, mengenkripsi jumlahnya, dan menyediakan decryptable_available_balance yang dienkripsi menggunakan kunci AES pemilik token account.

  2. Penghitung kredit tertunda yang diharapkan dan aktual melacak perubahan pada nilai penghitung antara saat instruksi ApplyPendingBalance dibuat dan diproses:

    • expected_pending_balance_credit_counter: Nilai pending_balance_credit_counter saat klien membuat instruksi ApplyPendingBalance
    • actual_pending_balance_credit_counter: Nilai pending_balance_credit_counter pada token account pada saat instruksi ApplyPendingBalance diproses

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:

  1. Mulai dengan decryptable_available_balance dari token account
  2. 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:

  1. Buat Token Account: Panggil instruksi AssociatedTokenAccountInstruction::Create milik Associated Token Program untuk membuat token account pada alamat deterministiknya.

  2. Realokasi Ruang Akun: Panggil instruksi TokenInstruction::Reallocate milik Token Extension Program untuk menambahkan ruang bagi status ConfidentialTransferAccount.

  3. 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.

  4. Konfigurasi Transfer Rahasia: Panggil instruksi ConfidentialTransferInstruction::ConfigureAccount milik Token Extension Program, dengan mereferensikan akun status konteks bukti melalui ProofLocation::ContextStateAccount, untuk menginisialisasi status ConfidentialTransferAccount.

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?

Daftar Isi

Edit Halaman
© 2026 Yayasan Solana. Semua hak dilindungi.