Confidential Transaction
Last updated
Last updated
Confidential transactions (CT) in blockchain are a cryptographic method used to enhance privacy by keeping the details of transactions hidden from the public while still allowing verification of the transaction's validity. Key Features of confidential transactions include:
Hidden Transaction Amounts: Confidential Transactions conceal the amounts being transferred in a transaction, ensuring that only the sender and receiver know the actual amounts. This is achieved through cryptographic techniques that obfuscate the amounts while still allowing network nodes to validate the transaction.
Verifiable Transactions: Despite hiding the transaction amounts, CTs allow network participants to verify the validity of transactions. This means that nodes can ensure no new money is created out of thin air (i.e., no double-spending) without knowing the exact amounts involved.
At the beginning, the confidential transaction dApp shall communicate with zkFHE network and require a subset of zkFHE nodes to create a shared public key PK. Note the account balances are encrypted as unsigned integers.
Minting tokens can be implemented by encrypting the mint amount with the shared public key, and added to the encrypted account balance. Note an account registration is also enabled by encrypting the first minted tokens as the account balance.
Note if the confidential transaction application is intended to handle an external plain token asset, i.e., wrapping the public asset into a private asset, we shall allow the private asset to be burned for a withdrawal on the plain asset. Furthermore, any obfuscation measure like a random mint/burn is meaningless because the functions performed on the plain asset will always disclose the amount.
The burnt amount shall be homomorphically subtracted from the encrypted account balance. Also, the burnt amount shall be threshold decrypted and revealed to reduce the value from the total supply.
Transferring tokens involves several steps to ensure security and confidentiality. Initially, the encrypted amount to be transferred is verified as a positive value. Then we shall confirm that the sender’s balance is sufficient to cover the amount, preventing overspending. Finally, the transfer is completed by homomorphically subtracting the amount from the sender’s balance and adding it to the recipient’s balance.
To enable a user to view his balance, the dApp instructs the zkFHE network to re-encrypt the balance from the network's shared public key to the user's public key. This is achieved directly through a simple view function. However, this view function requires authentication by having the user provide a signature when calling the contract method, ensuring the network can verify the user’s ownership of the balance.
