Contract ownership about plutus

[j-mueller]

Looking at the diagram I just had another idea that could make it easier to construct the validator script.

If we think of the validator script as returning Bool instead of () and error then the four inputs to t2 together form a conjunction val_A ∧ val_B ∧ val_C ∧ val_D. Meaning that the transaction is only valid if the entire formula is true. Now, if we can manage to write the invariants of the contract as a proposition using a boolean algebra (with some uninterpreted "Theory" primitives like in an SMT solver) then we can convert that proposition to CNF, and each clause of the CNF corresponds to one of the addresses. So we could generate a validator script that knows which clause corresponds to which address, and only checks that its own clause is true (+ makes sure that all the other addresses are present in the transaction).

That should make it possible to describe the contract as a set of rules, and then generate the validator script and the contract endpoints from those rules using Template Haskell. Also we could feed the rules directly to Z3 and prove some properties about it.

[michaelpj]

I'm not sure if this works, but I think if we could make it work it would be useful in a number of contexts:

What if we could define a unique "token" to represent "being the floating party" as an asset. The idea would be that to perform an operation as the floating party you need to provide the token to prove that you have that role, and it is passed through the transaction unchanged. Selling your stake is then just a case of selling the asset.

However, this has a number of problems:

• You need to create an asset that can't be cloned, including by someone who can see the whole blockchain state.
  • I think this means it can't be data, it has to be something like ADA where linearity is ensured by the ledger rules.
• The token needs to be easily tradeable.

[michaelpj]

I think we might actually need a new token for my idea, i.e. multi-currency support of some kind.

[j-mueller]

I think we might actually need a new token for my idea, i.e. multi-currency support of some kind.

yes that could work, issuing a new token for each contract.

(On the other hand, if we find a solution that doesn't require multi-currency support from the ledger then we can implement multi-currency with the existing system)

[j-mueller]

Another approach would be to assume that the initial owners of the contract are known to each other at the beginning, and we encode their identities in the validator script. In the data script we keep track of the changes of ownership that have happened, and whenever somebody does ChangeOwnership we add that to the list with a signature of the current owner. So at any point we can verify that the entire chain of transfers is legitimate. (A bit like a miniature blockchain inside the contract)

The only problem with this is that in order to verify the signature we'd need to be able to serialise a value inside Plutus (similar to solution (1) in #426 )

[michaelpj]

A bit like a miniature blockchain inside the contract

Nice idea (also, vile). We'd essentially make a virtual asset for each role, and the contract would additionally function as a ledger tracking ownership of the asset.

Where do we need to serialize a value in this approach?

[j-mueller]

Where do we need to serialize a value in this approach?

I was thinking of something like this (in Haskell):

data Signed a = Signed { signature :: ByteString, value :: a }
data OwnershipChain = InitialOwner PubKey | TransferTo PubKey (Signed OwnershipChain)
    deriving Serialise

signedBy :: Serialise a => PubKey -> Signed a -> Bool
signedBy pk (Signed sig vl) = checkSig pk sig (serialise vl)
-- assuming checkSig :: PubKey -> ByteString -> ByteString -> Bool

currentOwner :: OwnershipChain -> PubKey
currentOwner = \case
    InitialOwner pk -> pk
    TransferTo pk _ -> pk

isLegit :: Serialise a => PubKey -> OwnershipChain -> Bool
isLegit initPk = \case
    InitialOwner pk -> pk == initPk
    TransferTo newOwner sg = signedBy (currentOwner (value sg)) sg && isLegit initPk (value sg)

[michaelpj]

Sure, but you can write that serialization function yourself in Plutus Tx, I think. We don't need to serialize arbitrary other PLC programs, which was the issue before.

[j-mueller]

True... I'm going to try that out now

[j-mueller]

You need to create an asset that can't be cloned, including by someone who can see the whole blockchain state.

That's really the fundamental problem, and I'm a bit stuck at the moment, because every solution that I come up with has the problem that you could simply copy the output and modify the data script in your favour. For example, for the "mini blockchain" approach you could also put in a fake blockchain with bogus keys and matching signatures, and the script has no way of knowing that these are the actual keys of the past owners of the tokens.

I also thought about something you mentioned a while ago @michaelpj , namely a "master transaction" that sets up a pool of tx outputs, and each interaction with the contract consumes one of those outputs. But even that can be manipulated by producing a bad output to the address!

[j-mueller]

This looks similar to what I'm trying to build: https://eips.ethereum.org/EIPS/eip-721

[j-mueller]

Multi-currency is implemented on the mockchain (#866), and with that we can write NFTs which can be used to encode the ownership of contracts.