<p>I think there are two approaches to this, the classical and the cryptographic way of doing this.</p>
<p><strong>The classical method</strong>: In this method, you do the same as you would do on any computer. You store the list of minted names (in a UTxO). Given a new mint, the stateful minting policy would check that the new name is not in the list and makes sure the new state has it in its list. The problem with this design is that a blockchain is bound in transaction size. Currently, any transaction cannot exceed 16kb (more or less). So theoretically, the database cannot exceed this limit (note that this is the absolute upper bound, in practice it will be much lower).</p>
<p>Now you can also decide to shard the database captured by multiple UTxO's. For example, store all names that start with the letter &quot;a&quot; in one UTxO and the letters &quot;b&quot; in another. This method might work, since upon minting a new name, only the database of that letter is needed in a transaction. Now this is again limited since it might be the case that names that start with the letter &quot;c&quot; get minted a lot, rendering the database full at some point. So choosing a method how to shard is the key here, and this depends totally on your constraints on the name. But remember that this subdivision has to be deterministic, a validator should be able to decide if the appropriate database is used given a name!</p>
<p><strong>The cryptographic method</strong>: Since space and time are bound on a blockchain, there are some clever ways to create bound algorithms that proof a statement. For example, using Merkle tree's you can prove that something <strong>is</strong> a member of a database in a relatively low-impact way. But these are involved from a dev perspective. Similarly, I found this <a href="https://eprint.iacr.org/2015/072.pdf" rel="nofollow noreferrer">paper</a> that lets you prove that you correctly failed to prove membership of an element, effectively proving that it is <strong>not</strong> a member. The paper also has a nice non-interactive algorithm where a minting policy could probably act as the verifier. Note, however, that this paper leverage pairing curves, which won't be available until next HF (if we are optimistic!).</p>
<p>So to conclude, there are ways, but it depends on your specific application.</p>

CC BY-SA 4.0
2023-03-29T13:55:52.333Z
Thanx for the very detailed answer, Fermat! At first glance Zero-Knowledge Proofs of Non-Membership looks like exactly what I'm looking for. Well, it looks like I have to wait for the next (or for the next after next) HF :)
dmitry_stas
CC BY-SA 4.0
2023-03-29T08:01:45.200Z
2023-03-29T08:01:45.200Z
Fermat
<p>is there any way to limit number for each tokens within one minting policy, in Plutus validator?</p>
<p>For example for policy <code>ab12</code> I want to allow users minting tokens, in different transactions. Сan the validator reject minting if the user try to mint the Token <code>ab12.A_1</code> but the token with name 'A_1' has already been minted (i.e. max number is 1)? It is assumed that the number in the name means the maximum possible number of tokens with this name. The names of the tokens are not known in advance, i.e. unfortunately it is impossible to determine the list of tokens and send it in datum or something like that. But I hope that maybe there is another way?</p>

CC BY-SA 4.0
2023-03-27T08:46:09.663Z
Is the space of names that you allow bounded? And if so, how large is this space?
Fermat
CC BY-SA 4.0
2023-03-27T18:48:04.860Z
It can be very large, 10K or even more
dmitry_stas
<plutus><smart-contract><native-assets><minting><validator>
Limit the number for each Token (AssetName) within one Currency Symbol (Policy ID)
# Limit the number for each Token (AssetName) within one Currency Symbol (Policy ID)

(Asked by: username_0 on 2023-03-26)

is there any way to limit number for each tokens within one minting policy, in Plutus validator?

For example for policy `ab12` I want to allow users minting tokens, in different transactions. Сan the validator reject minting if the user try to mint the Token `ab12.A_1` but the token with name 'A\_1' has already been minted (i.e. max number is 1)? It is assumed that the number in the name means the maximum possible number of tokens with this name. The names of the tokens are not known in advance, i.e. unfortunately it is impossible to determine the list of tokens and send it in datum or something like that. But I hope that maybe there is another way?

**Tags:** plutus, smart-contract, native-assets, minting, validator
> **Comments:**
> **username_1**: Is the space of names that you allow bounded? And if so, how large is this space?  
> **username_0**: It can be very large, 10K or even more  

---

## 1 answers

### Answer by username_1 on 2023-03-29. Score: 1 | Accepted answer

I think there are two approaches to this, the classical and the cryptographic way of doing this.

**The classical method**: In this method, you do the same as you would do on any computer. You store the list of minted names (in a UTxO). Given a new mint, the stateful minting policy would check that the new name is not in the list and makes sure the new state has it in its list. The problem with this design is that a blockchain is bound in transaction size. Currently, any transaction cannot exceed 16kb (more or less). So theoretically, the database cannot exceed this limit (note that this is the absolute upper bound, in practice it will be much lower).

Now you can also decide to shard the database captured by multiple UTxO's. For example, store all names that start with the letter "a" in one UTxO and the letters "b" in another. This method might work, since upon minting a new name, only the database of that letter is needed in a transaction. Now this is again limited since it might be the case that names that start with the letter "c" get minted a lot, rendering the database full at some point. So choosing a method how to shard is the key here, and this depends totally on your constraints on the name. But remember that this subdivision has to be deterministic, a validator should be able to decide if the appropriate database is used given a name!

**The cryptographic method**: Since space and time are bound on a blockchain, there are some clever ways to create bound algorithms that proof a statement. For example, using Merkle tree's you can prove that something **is** a member of a database in a relatively low-impact way. But these are involved from a dev perspective. Similarly, I found this [paper](https://eprint.iacr.org/2015/072.pdf) that lets you prove that you correctly failed to prove membership of an element, effectively proving that it is **not** a member. The paper also has a nice non-interactive algorithm where a minting policy could probably act as the verifier. Note, however, that this paper leverage pairing curves, which won't be available until next HF (if we are optimistic!).

So to conclude, there are ways, but it depends on your specific application.

> **Comments:**
> **username_0**: Thanx for the very detailed answer, Fermat! At first glance Zero-Knowledge Proofs of Non-Membership looks like exactly what I'm looking for. Well, it looks like I have to wait for the next (or for the next after next) HF :)  

---

