New contract design for OpShin

[nielstron]

I have recently put a lot of though into the design of OpShin smart contracts - i.e. how to define validators, what would be the most intuitive design?

Without further ado, here is my proposal: a class interface that inherits from a validator base class that looks like this:

from opshin.prelude import *

@dataclass
class Validator:
   def spend(self, datum: Anything, redeemer: Anything, purpose: Spending, tx_info: TxInfo) -> None:
       raise NotImplementedError("Spending purpose not implemented")
   
   def mint(self, redeemer: Anything, purpose: Minting, tx_info: TxInfo) -> None:
        raise NotImplementedError("Spending purpose not implemented")
        
    ...

A validator would then be implemented by subclassing this. Every subclass defines a validator. In the style of dataclasses, contracts can have parameters that are accessible through the self object in each call. By overwriting one of these functions in the subclass, a validator for each purpose is implemented. The example parameterized gift contract would look like this:

from opshin.prelude import *


@dataclass
class GiftContract(Validator):

   admin: PubKeyHash

   def spend(self, datum: PubKeyHash, redeemer: None, purpose: Spending, tx_info: TxInfo):
        assert datum in tx_info.signatories or self.admin in tx_info.signatories, "Signature from owner or admin missing"
 

By default, every contract is then compiled such that it can be multi-purpose.
How to handle the previously allowed "any-number-of-parameters" remains to be seen, but maybe it should be disallowed altogether.

Reasoning

One part is that contracts should be parameterizable, so somehow users should have an intuitive understanding that their contract does receive some parameters on-chain and some during initialization.

Another part is that contracts can be multi-purpose, so there should be more than one route in which a contract can be invoked (minting, spending etc).

Moreover I am getting annoyed that a function called "validator" is getting so much special treatment and basically exposes developers to very low level implementation details. I was before considering introducing an @validator marker to denote the validator in a contract.

By introducing this subclassing, we clearly seperate off- and onchain parameters, make clear which function is invoked and remove the overhead of having to manually check what purpose one was invoked with. This removes a lot of low-level issues that the previous approach had.

What do you think?

Please feel free to leave comments on whether you like or dislike this design! Should the old design prevail and be an option for hard-core optimizers? Should the new style be adopted and become the only valid way to write contracts? Let me know!

[while0x1]

Opshins strength and its differentiation from competing validator languages is its ease of use. The concept seems fairly straight forward, a validator type that can be used to create contract specific validator sub classes but if the implementation reduces readability it may harm the very core of why Opshin is a preferable option for writing Smart Contracts.