If an ownerless contract wants to work with any type script, the only viable option is to implement it as a lock script. This is possible because an ownerless contract does not require the lock script to represent ownership rights.
Implementing an app via a lock script in CKB presents a challenge - if the lock script is only present in the output, it will not be executed.
Consider the following transaction as an example. It is essential for the lock script L2 to guarantee the uniqueness of its args for any cell locked by L2. Since L2 will not be executed, there are two obvious solutions: either we include the validation logic in L1 or T.
inputs:
- lock: L1
type: T
outputs:
- lock: L2 args
type: T
- Adding validation to T contracts with the goal to work with any type script. It’s possible for some type scripts such as XUDT which allows inject custom logic via extensions.
- In order to add validation to L1, the use of any lock script for asset T is prohibited. For the same reason, I propose a solution outlined in the post 1-on-1 Binding Between Bitcoin UTXO and CKB SUDT Cell. This solution involves requiring a wrapper lock script to facilitate the transfer of assets from BTC to CKB.
A clever workaround is available to address this issue. We can delay the validation until we are going to unlock L2. The lock script L2 mandates the inclusion of the previous CKB transaction as a witness to verify the presence of L2 locked cells in the inputs of that transaction. The drawback of this workaround is the overhead it adds to the transaction size.
The last option is to add a feature that enforces running lock scripts, either through soft or hard fork. For instance, the script can set a flag in the script code elf structure.