Mint Deku-native Tickets on Tezos

GanttStart: 2022-10-25
GanttDue: 2022-11-01

We want to be able to create new tickets on Deku and withdraw them to L1. The consensus contract will have to mint them itself in this case.

There is much to decide on how to format said tickets. However, here's my suggestion for an MVP:

A Deku-compatible ticket has type ticketer * amount * bytes, where ticketer is an address.

For tickets coming from L1, the ticketer is a KT1 address. However on Deku we should allow any address to mint tickets, since for Deku-P there may not be a concept of smart contracts.

I suggest that Deku-native tickets have the same type ticketer * amount * bytes but with the following constraint: the first bytes of the 3rd field are the address of the tickter. On Deku this data is redundant, but on L1 we can use this as metadata to know which Deku address created the ticket.

So a Deku-native ticket on L2 would have the form <bob_address>, 7, "<bob_address>hello world", while on L1 it would have the form <deku kt1 address>, 7, "<bob_address>hello world". When withdrawing a Deku-native ticket, the consensus contract will have to know irrefutably that it is a Deku-native ticket so it doesn't mint duplicates. One way would be to include a tag in the data that is hashed to form the merkle proof.

When you mint a ticket on Deku, withdraw to L1, then deposit again, there should be no changes. So when we deposit, we'll have to check the ticketer. If it's our own address, then we know it's a Deku-native ticket being deposited to L2 again, and we'll have to read the first few bytes to know who the Deku ticketer should be.

No files or tests are named. Start by locating the consensus contract and the ticket withdrawal and deposit paths; clarify the ticket format, native-ticket identification, and round-trip behavior before defining what done means.