🚧 Challenges and How They Were Solved

1. ZKPassport Only Works with NFC Enabled IDs

This is a limitation of the dependency that impacts the user experience and testing accessibility.

• The Hurdle: The core identity verification step relies on ZkPassport, which requires users to have an NFC-enabled ID (like a modern passport or driver's license) to generate the initial zero-knowledge proof. This excludes users with older IDs and makes development/demo testing difficult for anyone without the required ID or hardware.

• How I Mitigated It: I explicitly addressed this in the project documentation:

  Use the "Skip (dev/demo)" button to bypass verification for testing.

  • Solution: I implemented a development/demo bypass feature in the frontend (e.g., in

    app/src/hooks/useZkPassport.ts

    ). This allows testers to test the entire complex payment flow (commitment generation, nullifier hashing, proof creation, and contract withdrawal) without needing a physical, NFC-enabled ID, making the project viable for demonstration and local development.

2. Sepolia was Upgraded Earlier Today, Forcing a Class Hash Mismatch

This is a common deployment-related hurdle when working with rapidly evolving Layer 2 solutions like Starknet.

• The Hurdle: Starknet (running on the Sepolia testnet) was upgraded. This change means the underlying Cairo compiler or runtime environment changed, which invalidates the previously calculated

  class_hash

  for your deployed contracts (

  verifier

  and

  payment

  ). When you try to interact with the old deployed contracts, the network throws a mismatch error.

• How I Solved It: I documented the standard operational fix for this issue:

  If I modified contracts, update the class hashes in

  Makefile

  after

  declare-*

  commands.

  • Solution: When a breaking change or upgrade occurs, I have to re-declare and re-deploy the contracts. Specifically, after running

    make declare-verifier

    and

    make declare-payment

    , you had to manually update the new class hashes generated in the project's configuration (in the

    Makefile

    and tools file

    .tool-versions

    to use rc dev tools) to point to the freshly declared code. This ensures the subsequent deployment or interaction calls use the correct, current class hash.

3. Using the Nullifiers to Protect State

This is a cryptographic and contract logic challenge inherent in building ZK-based anonymous systems.

• The Hurdle: In a zero-knowledge payment system, the patient's identity is hidden. To prevent a patient from claiming the same deposited funds twice (a "double spend"), a nullifier must be used. The challenge is ensuring the

  nullifier

  is calculated correctly within the ZK circuit (in Noir), and then efficiently tracked and secured within the payment contract (Cairo/Starknet state) to guarantee it's unique.
• How I Solved It: I relied on the integrity of the ZK system and contract logic:
  • Noir Circuit Logic: I ensured the

    nullifier

    is generated by hashing the secret and a unique salt (

    nullifier = hash(secret, salt)

    ). Since the

    secret

    and

    salt

    are unique to the transaction, the

    nullifier

    derived from them is also unique.
  • Contract Logic: The

    therapy_payment.cairo

    contract has logic to store and check all used nullifiers before releasing funds. This ensures that the first time a valid proof (which contains the

    nullifier

    ) is submitted, the funds are released and the

    nullifier

    is marked as spent, making subsequent attempts fail. This protects the contract state from double-spending.