Based on the recent posts, I thought I’d start this thread listing the common design patterns we have seen in ErgoScript use-cases.
- Singleton Token: Essentially a token which exists as a singleton (i.e., when token was issued in quantity one). The box in which token is stored can have other sophisticated scripts (see below).
- Perpetual Token: This is a singleton token that cannot be destroyed (i.e., the box in which it is stored has a script that requires the spending transaction to output a box with identical contents). This is described in the post “A perpetual token”.
- One-use-per-block Token: This is a perpetual token that can be spent at most once per block. In other words, the box containing this token must have at least one confirmation to be spent. This is described by @jasondavies in this blog post.
- Cyclic References: This is when ScriptA requires an output box to be protected by some guard ScriptB, and ScriptB requires an output box to be protected by ScriptA. The solution is discussed in this forum post.
- Prove that a certain unspent box exists: This is done by including that box as data-input to a transaction.
- Prove that out of two boxes, the other one has been spent. This is a special type of non-existence proof that can be done via tokens as explained in the paragraph “Identifying the second spender” in Section 4.4 of the ZeroJoin paper.
- Requiring that the tx can only be mined by a particular user (Alice): This is done by adding the condition
minerPubKey == alice, as discussed in this post. The credit for discovering the attack (for which this pattern was created) goes to one of the core Ergo developers (unfortunately, I cannot remember who and those logs are lost in #Slack somewhere).
- Requiring that the transaction cannot be mined after a certain deadline has passed. The script contains the additional clause that
HEIGHT < getVar[Int](1).get, which ensures that the transaction cannot be mined if the block height crosses the value in the first context variable (provided by the spender). This is quite a simple pattern but quite useful, and first appeared in the Advanced ErgoScript Tutorial, Section 2.1.
- Generalizing above pattern, instead of hard-wiring the condition
HEIGHT < getVar[Int](1).get, we could specify this (and any other) script at run-time, as described in this thread.
In case I have missed crediting anyone, please mention and I’ll update the post.
I have definitely missed many other interesting patterns currently known, and surely there are many more to be discovered. Hopefully others will add to the list (and I’ll update the OP).