Faster Pallas Curve Mapping for Blinded Account Balances

This system allows us to use fast Plonkish ZKSnarks to do range checks for compliance flagging and also decode the account transactions if compelled to do so from a compliance standpoint.

There are 3 actors in this scenario

1. Prover - Account Holder
2. Verifier - ZKSnark via C++ or Solidity rollup contract (Rollup using Nova Folding)
3. Revealer - Secure storage of a set of Private/Public keys to be used to encrypt/decrypt the KDF secret
   • The revealer at any given time is trusted and can use it's private key to decrypt the KDF generated by the prover and decrypt the private parameters.
   • Suggested 16 private/public key pairs for Revealer, Prover picks based on prover's public key:

     revealer_public_keys[prover_public_key & 0xf];
     

Breakdown of Steps

1. KDF Creation by Prover:
   • Prover: Creates an AES KDF using one of the Revealer's public key(s) as a source of randomness, and signs it. This signature acts as a guarantee of the integrity and origin of the KDF.
2. Encrypt KDF Secret:
   • Prover: Encrypts the AES KDF secret (derived key) using the Revealer's public key. This ensures that only the Revealer, who possesses the corresponding private key, can decrypt and access this KDF secret.
3. Proof Creation:
   • Prover: Creates a zk-SNARK proof with a private parameter from the KDF creation step. This proof demonstrates certain assertions about the data or process without revealing the underlying data.
4. Mapping to Pallas Curve:
   • Prover: Uses the AES KDF as a random factor to map an account balance to a Pallas curve. This mapping is part of the public parameter set for the zk-SNARK proof, enabling certain verifications without revealing the actual account balance.
5. Verifier Circuit:
   • Verifier: The verification circuit in the zk-SNARK setup verifies that the signature was correctly used to sign the Revealer’s public key, ensuring the authenticity of the KDF creation process.
6. Additional Verification:
   • Verifier: Uses the private parameter (from step 1) within the zk-SNARK to map the account balance off the Pallas curve and verify its range. This step checks for the correctness of the mapped values within certain expected ranges.
   • Verifier: Other Parameters are passed as public parameters like min: 0, max 99, or min: 100 max: 1000
     • This is to verify the range of transaction, if doing a transfer or deposit.
   • Verifier: Public Parameter -> destination starting balance, destination ending balance, mapped on pallas curve
     • Pallas addition is Homomorphic, so need to possibly use PCBF described in Pedersen Commitments or if we can use a zero blinding factor on the additions
7. Revealer’s Role:
   • Revealer: At any point, the Revealer can use their private key to decrypt the KDF generated in step 1 and access the private parameters. This could be used for auditing, verification, or other purposes where the Revealer needs to access the concealed information.

Implications and Considerations

• Security and Privacy: This setup uses asymmetric encryption for secure communication with the Revealer, zk-SNARKs for privacy-preserving proofs, and a KDF for generating cryptographic material, making the process secure and private.
• Trust in Revealer: The Revealer is a trusted entity in this setup, as they have the ability to decrypt and access sensitive information. Their role and the security of their private key are crucial.
• zk-SNARKs Complexity: The use of zk-SNARKs adds complexity but offers strong privacy guarantees, as they enable the verification of encrypted computations without revealing the inputs.
• Cryptographic Integrity: The process ensures the cryptographic integrity of the data and the operations performed on it, as each step involves cryptographic proofs or encryption.
• The Provers KDF public key can now be used as an internal address in a mapping in solidity to store the account balance

Conclusion

This scenario represents a complex but robust cryptographic system combining elements of asymmetric encryption, zk-SNARKs, and KDFs to ensure privacy, security, and verifiability. It leverages the strengths of each cryptographic primitive to achieve a setup where sensitive data can be verified without being directly exposed, except to a trusted Revealer.