Draft: Proto/Michelson: Linear operations

Context

The operation type is currently duplicable because it existed before the introduction of the duplicable type attribute in Edo. Duplicating an operation using DUP is hence possible until now but this duplication can only be local because:

• internal operations have a nonce that prevents two copies of the same operation to be emitted in the output of a contract call,
• the operation type is very constrained, in particular it is not possible to leak a duplicate of an operation by storing it, sending it to a contract, or serializing it.

When DUP is called on an operation, sooner or later one of the copies will be dropped.

Operations can however contain tickets so it is possible to wrap a ticket inside an operation (for instance using the TRANSFER_TOKENS instruction) and duplicate the resulting operation. This should be harmless because there is no way to extract the ticket from the operation without emitting it but this complicates significantly reasoning on the ticket invariants at the level of the Michelson interpreter.

This MR changes the duplicable type attribute of the operation type to forbid calling DUP on a value of type operation. Legacy contracts are still allowed to duplicate operations so the runtime checks in apply.ml (based on the internal operation nonces stored inside internal operations and handled in raw_context.ml) are still needed but could be removed in a future amendment (the patch removing them is already ready, see nomadic-labs/tezos@dc22b157)

Manually testing the MR

Try typechecking a Michelson script using DUP on an operation (or some data type containing operations).

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• [ ] Document any change to the user interface, including configuration parameters (see node configuration) (Type attributes are not documented on this repository at the moment. See also !3135.)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, the Development Version section of CHANGES.md for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR