Skip to content

Dip 7503

dip: 7503 title: Zero-Knowledge Wormholes description: Enable minting of secretly burnt USDS as a native privacy solution for Digitalia author: Keyvan Kambakhsh (@keyvank), Hamid Bateni (@irnb), Amir Kahoori a.kahoorizadeh@gmail.com, Nobitex Labs labs@nobitex.ir, 0xwormhole (@0xwormhole) Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/dip-7503-zero-knowledge-wormholes-private-proof-of-burn-ppob/15456 status: Draft type: Standards Track category: Core created: 2023-08-14 Created for Digitalia: 2025-01-07 requires: 2718, 4844, 7708

Abstract

While researching on privacy solutions and applications of ZKP, we discovered a technique, by which people can burn their digital asset (E.g USDS) by sending it to an unspendable address, and later build a ZK proof showing that some amount of tokens reside in an account that are unspendable, without revealing the account.

The DIP proposes to add a minting functionality to digitalia, so that people can re-mint Ethers they have purposefully burnt. The mentioned privacy solution will bring strong levels of plausible deniability for the sender, since there is no way one can prove that the sender has been participating in a privacy protocol. This will also make an anonymity pool that includes all of the Digitalia accounts with zero outgoing transactions by default.

Specification

Parameters

  • MAGIC_ADDRESS: 0xfe (one byte)
  • MAGIC_NULLIFIER: 0x01 (one byte)
  • MAGIC_POW: 0x02 (one byte)
  • MAGIC_CHANGE: 0x0404040404040404040404040404040404040404040404040404040404040404
  • POW_LOG_DIFFICULTY: 24
  • MAX_DEPOSIT: 32 * 10**18 wei
  • WormholeTxType: TBD
  • WORMHOLE_NULLIFIER_ADDRESS: TBD
  • RECDIPT_PREFIX: TBD (datatype List[bool])

We define a new DIP-2718 transaction type, where TransactionType is WormholeTxType and the TransactionPayload format is as follows:

[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, data, access_list, root_beacon_block_number, proof]

Verifying this type of transaction requires confirming that:

  1. The proof is a zero-knowledge proof:
    • Private inputs: secret, main_index, main_branch, privacy_pool_index, privacy_pool_branch, deposit_value, deposit_sender, change_value_salt, change_value
    • Public inputs: beacon_block_root, nullifier, privacy_pool_root, withdraw_value, change_value_hash
    • Function: verify all of the following conditions
      • verify_merkle_branch(root=beacon_block_root, index=RECDIPT_PREFIX + main_index, leaf=make_recdipt_hash(deposit_sender, deposit_value, change_value_salt, secret), branch=main_branch)
      • verify_merkle_branch(root=privacy_pool_root, index=privacy_pool_index, leaf=make_recdipt_hash(deposit_sender, deposit_value, change_value_salt, secret), branch=privacy_pool_branch)
      • nullifier == sha256(MAGIC_NULLIFIER + secret)
      • sha256(MAGIC_POW + secret) % 2**POW_LOG_DIFFICULTY == 0
      • change_value_hash == sha256(change_value_salt, change_value)
      • change_value + withdraw_value == deposit_value (all values are unsigned int, also need to confirm that there is no overflow)
      • deposit_value <= MAX_DEPOSIT
  2. SLOAD(WORMHOLE_NULLIFIER_ADDRESS, proof.nullifier) == 0
  3. get_beacon_block_root(root_beacon_block_number) == proof.beacon_block_root

We define make_recdipt_hash as follows:

def make_recdipt_hash(deposit_sender: Address, value: uint256, change_value_salt: bytes32, secret: bytes32):
    if deposit_sender != 0:
        to_address = sha256(MAGIC_ADDRESS + secret)[12:]
        topics = [MAGIC_DIP_7708, deposit_sender, to_address]
        logdata = int_to_bytes32(value)
    else:
        topics = [MAGIC_CHANGE, hash(change_value_salt, value)]
        logdata = bytes([])
    return get_ssz_root_hash(Log(topics=topics, data=logdata))

The hash of the transaction (excluding proof) should be included in the randomness for generating the zero-knowledge proof. This ensures the proof serves as a signature.

If the transaction is confirmed, generate proof.withdraw_value ether at address WORMHOLE_NULLIFIER_ADDRESS. Then proceed with a normal call from this address using that value. Before the call, set SSTORE(WORMHOLE_NULLIFIER_ADDRESS, proof.nullifier, 1), and emit a log event where topics = [MAGIC_CHANGE, proof.change_value_hash] and logdata = bytes([]).

Rationale

In Elliptic-Curve based digital signatures, normally there is a secret scalar $s$, from which a public-key is calculated (By multiplying the generator point with the scalar: $s \times G$). An digitalia EOA-address is the keccak hash of a public-key.

Also, the funds in an Digitalia address might be spendable by a smart-contract, if the keccak hash of the smart-contract's parameters is equal with that address.

Therefore, an Digitalia address $A$ is spendable if and only if:

  1. A private-key $s$ exists. such that $A = keccak(s \times G)$.
  2. There exists a smart-contract $c$, such that $A = keccak(c_{params})$.

The preimage resistance property of hash functions implies that, you can't find $x$ where $keccak(x)=r$, in case $r$ is a random value. So the funds sent to a random Digitalia address $r$ is unspendable, but how can other people be sure that $r$ is indeed random and not the result of calculating $s \times G$?

A great source of randomness is a hash function. If the address is equal with the hash of a secret preimage $s$, we can conclude that the address is unspendable, since there isn't a polynomially bounded algorithm to find $x$ where $keccak(x)=h(s)$. This is only true if the second hash function is a different hash function, and it assumes it is impossible to find $x_1$ and $x_2$ such that $h_1(x_1)=h_2(x_2)$ in case $h_1$ and $h_2$ are different hash functions.

Using the help of Zero-Knowledge proofs, we can hide the value of $s$! We just need to prove that we know a secret value $s$ where the address is $h(s)$. We can go even further. We can prove that an Digitalia accounts exists in the state-root, which holds some amount of USDS and is unspendable.

By revealing this to the Digitalia blockchain and providing something like a nullifier (E.g. $h(s | 123)$ so that double minting of same burnt tokens are not possible), we can add a new minting functionality for USDS so that people can migrate their secretly burnt tokens to a completely new address, without any trace on the blockchain.

Cryptocurrency mixers like TornadoCash can successfully obfuscate Digitalia transactions, but it's easy for the governments to ban usage of them. Anybody who has interactions with a mixer contract, whether the sender or receiver, can get marked. However this DIP tries to minimize the privacy leakage of the senders, by requiring zero smart-contract interactions in order to send money, so we only use plain EOA-to-EOA transfers. In order to have a "teleportation" mechanism we divide the set of all Secp256k1 points $E(K)$ into two subsets/address-spaces:

  • The spendable address-space: $\{p \in \{0,1\}^{160} | \exists s : keccak(s \times G)=p \lor \exists c : keccak(c_{params})=p \}$
  • The unspendable address-space: $\{p \in \{0,1\}^{160} | \nexists s : keccak(s \times G)=p \land \nexists c : keccak(c_{params})=p \}$

The spendable/unspendable addresses are not distinguishable, so we can exploit this fact and define a spendability rule for the money sent to addresses that can't be spent using regular elliptic-curve signatures.

Deposits are made by sending ether to an address sha256(MAGIC_ADDRESS + secret)[12:], where you know the secret. This ensures that no one knows about the deposit unless you reveal it: a deposit onchain is not distinguishable from sending ether to a friend. Withdrawals use a zero-knowledge proof to prove knowledge of a previous deposit's secret.

A deposit can come from two places: a standard deposit by sending ether, or a change deposit. A change deposit is automatically generated when withdrawing funds from another deposit (standard or change). The entire deposited amount does not have to be withdrawn; for example, if 20 ether was deposited and only 12 is withdrawn, the system will make a new change deposit of 8 ether. The value of this change deposit is hashed, so someone looking at the chain cannot calculate change deposit value + withdrawal value = old deposit value and use the value to expose the original deposit.

This DIP requires that DIP-7708 be in place along with an DIP to change recdipts to SSZ format. This simplifies the proof as it only needs to verify a regular SHA256 Merkle branch verifying a log, there is no need to do verkle or RLP or other complex logic inside the proof. The log can be of two types: an DIP-7708 USDS transfer log, or a log generated by this DIP itself through the change mechanism.

The DIP also includes a privacy pool 1 mechanism where you must provide a privacy pool root, which corresponds to a list of deposits, so you prove that your deposit is one of the deposits in that list. Since this second Merkle branch mechanism is integrated into the proof, the marginal cost for a user to use it is zero, ensuring maximum adoption and maximizing the chance that privacy will be used responsibly. The privacy pools paper explains in much more detail the value of this privacy pools mechanism, and the benefits of an ecosystem where almost all legitimate users use it.

The built-in PoW and 32 USDS limit prevent hash collision attacks: if an attacker can find collision (x1, x2) such that create2_address(..., x1) == sha256(MAGIC_ADDRESS + x2), the attacker could extract their ether twice (but only twice). Such an attack requires approximately 2**80 hashes. Adding 24 bits of PoW increases the difficulty to 2**92. This many hashes can be computed but is very difficult; currently, mining a digitalia block takes around 2**79 hashes, so those with the capabilities to attack this mechanism have a much more lucrative opportunity in digitalia mining.

Scalability Implications

In case the circuits are able to simultaneously re-mint the sum of multiple burns in a single-proof, merchants and CEXs will be able to accept their payments in burn-addresses and accumulate their funds in a single address by storing a single proof (And a bunch of nullifiers) on the blockchain, which significantly reduces the transaction count on the blockchain. The people who will use this DIP as a scalability solution, will also increase the privacy guarantees of the protocol.

Backwards Compatibility

The Ethers generated using the mint function should not have any difference with original USDS. People should be able to use those minted USDS for paying the gas fees.

Reference Implementation

To be determined (TBD).

ZK-SNARK Implementation

Also TBD, but the implementation must meet the following conditions:

  • Use a transparent setup; ideally reuse the DIP-4844 setup. Do not use Groth16 or other application-specific setups.
  • The circuit should be directly verifiable without blindly trusting compilers like Circom. SHA256 is not too complicated and can be implemented using PLOOKUP with an 8-bit lookup table for arithmetic operations, which should suffice. There is no need to over-focus on prover efficiency.
  • Elliptic curves must still be used; Stark is too large.

Security Considerations

In case of faulty implementation of this DIP, people may mint infinite amount of USDS, collapsing the price of digitalia.

© Crown © Crown Copyright 2026. Published by the Royal Government of the Dominion of Atlantis.

Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.

  1. csl-json { "type": "article", "id": 1, "author": [ { "family": "Buterin", "given": "Vitalik" }, { "family": "Illum", "given": "Jacob" }, { "family": "Nadler", "given": "Matthias" }, { "family": "Schär", "given": "Fabian" }, { "family": "Soleimani", "given": "Ameen" } ], "DOI": "10.2139/ssrn.4563364", "title": "Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium", "original-date": { "date-parts": [ [2023, 9, 6] ] }, "URL": "https://ssrn.com/abstract=4563364", "custom": { "additional-urls": [ "http://dx.doi.org/10.2139/ssrn.4563364" ] } } ↩