How long should we store Nullifiers

[Dominik1999]

We will only store Nullifiers of the last two epochs

Nullifiers provide information on whether a specific note has been consumed yet. Nullifiers are stored in a Sparse Merkle Tree, which maps nullifiers to block heights at which they were created. Using this, one can check and prove that a given nullifier is not in the database. There will be one tree per epoch, and Miden nodes store always at least the last two trees. However, the roots of the old trees are still stored. We can't store all Nullifiers because the storage size grows linearly with the number of transactions.

For the user, that means if she wants to execute a transaction consuming a note that is older than two epochs, she needs to provide the Merkle Path together with the transaction data (or proof).

The question now is: How long should an epoch be?

It is unclear yet, how long an epoch will be. We have three months, six months, or it could be even longer.

[At least I haven't found the definition of an epoch yet]

If a Nullifier has 33 bytes and we have epochs of six months, we need 1TB to store 2^35 nullifiers. Bobbin's calc:

• 1K TPS.
• 1 nullifier per TX.
• 33 bytes per nullifier.
• 6 months per epoch

The second question is: Can we change the epoch lengths after one year?

Having 1K TPS constantly in the first year doesn't seem realistic to me. So we could, in the beginning, try to store every Nullifier and then prune the Sparse Merkle Tree and introduce epochs of shorter length when we are above 1TB?

[bobbinth]

Nullifiers are stored in a Sparse Merkle Tree, which maps nullifiers to block heights at which they were created.

I think it could be just a map of nullifier to 0 or 1 with 1 meaning that a note with this nullifier has already been consumed.

The second question is: Can we change the epoch lengths after one year?

Yes, we can - though this would require an upgrade (a "soft-fork"?). It will probably take several years (at the very least) to get anywhere near 1K TPS - so, we could probably start with a relatively long epoch (e.g., 2 years) and then once this starts being a problem, shorten it.

[Dominik1999]

Makes sense to me.

I think it could be just a map of nullifier to 0 or 1 with 1 meaning that a note with this nullifier has already been consumed.

Does every note have a nullifier, then? Can we use add a nullifier to the note's metadata?

miden-base/objects/src/notes/metadata.rs

Lines 8 to 12 in 63549f0

	pub struct NoteMetadata {
	sender: AccountId,
	tag: Felt,
	num_assets: Felt,
	}

Yes, we can - though this would require an upgrade (a "soft-fork"?). It will probably take several years (at the very least) to get anywhere near 1K TPS - so, we could probably start with a relatively long epoch (e.g., 2 years) and then once this starts being a problem, shorten it.

Then maybe let's not introduce storage limitation for now (testnet and ~first year of mainnet). And then soft-fork when necessary.

[bobbinth]

Does every note have a nullifier, then? Can we use add a nullifier to the note's metadata?

Yes, every note has exactly one nullifier. We don't need to add it to the metadata because it is implicit in the note itself (see here for how it is computed).

[Dominik1999]

Does every note have a nullifier, then? Can we use add a nullifier to the note's metadata?

Yes, every note has exactly one nullifier. We don't need to add it to the metadata because it is implicit in the note itself (see here for how it is computed).

Ah nice, let me add this to the docs then.