Contract signatures

I’ve been conversing with @galfour about the topic and wanted to do a mini writeup.

There are two ways to authenticate a party in a smart-contract.

One way is to rely on a digital signature: if the party is known by its public key (or by a public key hash), then a contract may check that a message it receives has been signed by that party using the CHECK_SIGNATURE Michelson.

Another way is to authenticate parties is via the SENDER opcode which identifies the contract on the chain which sent the message. If SENDER is a tz[1…3] account, this is largely equivalent to verifying a signature. However, this method generalizes to more complex authentication method, allowing the party to be a multisig contract, a DAO, etc. This is the preferred method on Tezos.

The second method does suffer from a drawback, it ends after one contract call. If the contract being called itself calls another contract, it becomes a SENDER, and the authentication is lost.

To address this, we could allow contracts to explicitly “sign” a message by attaching their address to it during the execution of a transaction. There would be of course no actual cryptographic signature happening at all. This is merely a programming convenience that lets contracts pass between themselves messages which have been “stamped” or “signed” by some contract during the transaction.

5 Likes

Couldn’t there be cases in which i want the “effect” of the second method?
The part:

“it becomes a SENDER,”