[NIP] Allow some Output Lock Scripts to Validate

[phroi]

@xxuejie

To unlock a WUDT lock script(and to move the stored UDTs elsewhere), the WUDT lock script validates that the same amount of WUDTs have been burned.

This way each WUDT will have backing UDT(it does not matter how many WUDT cells there are, what matters is the underlying WUDT amount and UDT amount), and you can also build any validating lock on top of WUDT as you like, and the underlying UDT can use existing standards such as Simple UDTs. Compatibility is also preserved.

We got exactly the same understanding, also helps that this is exactly like the iCKB protocol, but applied to UDTs

Possible Solutions to the Proposed Problems

So let’s first solve the previously presented problem.

Busywork Attack

This protocol is so liquid that it can be exploited maliciously to DoS the protocol with state contention: wrap, unwrap, wrap, unwrap…

A simple solution would be to apply a minimal lockup period to the the conversion results, so the user cells resulting from wrapping or unwrapping are locked up for some time.

Alternatively, since OTX are still not available, we can assume that we can also develop an intention-based script to carry out wrappings and unwrappings. At that point user signs the intention cell and automated bots take care of getting his intention realized by signing transactions until one goes trough. (Depending on the design, the lock on these intention cells could face Confusion Attack.)

Are there any better alternatives?

Confusion Attack

In my opinion it doesn’t pose issues, cause the protocol know both type and amount of what it needs to unwrap. Say the front-end gets confused and include invalid attacker cells, the WUDT type script would just not validate at unwrapping time, cause it recognizes the unwrapping as invalid.

Ownership of CKB used in the Underlying UDTs

If we assume that everyone can claim the CKB used to store the Underlying UDTs, then we’ll always end up with exactly one cell holding all Underlying UDTs. Let’s assume for example that there are multiple cells storing the Underlying UDTs, then an attacker can merge those cells and keep for himself the difference of CKB.

The only solution that comes to mind is that the CKB used in the Underlying UDTs are exclusively property of the protocol, as such no-one is allowed to claim them.

This bring to the following rule: If N underlying UDT cells exist in input, then the output must have at least N underlying UDT cells. These Underlying UDTs cells can be drained to 0 UDT, but not consumed.

These N underlying output cells should be of similar values, this maximizes the utility of these cells in high concurrency environments, but enforcing this at the script level could become problematic later on when OTX becomes available(?).

Are there any better alternatives?

Wrapping Gated-access UDTs

This probably is not an issue: these UDTs are deployed by type, see USDI, so they can easily adopt this new standard, if so they choose.

Say they choose not to, then they get wrapped and that’s about it. They will handle the blocking of WUDT users in the same way they handle blocking of user funds inside protocol that use custom protocol locks.

WUDT Script design

@xxuejie

UDT can use existing standards such as Simple UDTs. Compatibility is also preserved.

Say we use sUDT as base then it gets complicated when we want to mint WUDT without an existing cell in input with our owner lock… This is the reason why iCKB design moved to xUDT.

I’d rather use xUDT, as xUDT with the appropriate args flag allows to have owner locks in form of a type script, both in input and output. So we can directly reference the wrapped UDT type in our custom xUDT args.

@xxuejie

Actually it’s possible to use a single script both acting as lock & type

This is exactly what I did in iCKB, so let’s assume we go with this design.

@xxuejie

A WUDT lock script holds in its script args the script hash of a particular UDT type script(one particular UDT to wrap)

In single script both acting as lock & type there is no strict need for any lock args:

• Underlying UDT Lock shares the logic by being the same script as WUDT, so it gets a nice 0x args.
• WUDT knows the Underlying UDT by its args.

@xxuejie

A WUDT lock script holds in its script args […] a pubkey hash identifying owners.

This is @xxuejie stance on non-signature based locks, which gives context to the previous statement:

I personally question the necessity of non-signature based locks at all. If I were doing the design, I would use types solely for non-signature based locks.

I’m not so sure about adding the pubkey hash of owners:

• Can you explain more your point of view?
• Including the pubkey hash which issue does it solve here?
• Also exactly owners of what?
• In your vision of a WUDT lock how is this pubkey hash used?

In my eyes keeping the pubkey of the original minters in the Underlying UDTs would put this protocol much closer to dCKB and that’s not a working model: dCKB failed due to breaking the redeemability of dCKB for their Underlying NervosDAO deposits.

Conversely, we have the iCKB model, where no pubkey of minters is stored in the Underlying NervosDAO deposits and it is designed for optimal redeemability. In my opinion, given the iCKB model, a particular WUDT instance should have no owners: anyone should be able to join or leave a WUDT, even without being one of the original minters.

From @janx:

a standard-compliant type script will always spawn those callback functions if they exist in the lock scripts in related cells

What if we spawn all the output locks? Not only those in related to our cells. What’s your take?

At this point I’d like to agree on the right fix for the Busywork Attack, then we can move to design the spawn call details.

Love & Peace, Phroi