Remove support for tickets with zero amount

By Tezos Protocol amendments team

‍

Today we would like to announce an important change coming in your way. As part of our next protocol proposal, we will remove support for tickets of zero amount.

Tickets of zero amount was previously allowed at the introduction of tickets initially. However, as Tezos protocol developers work on transaction and smart contract rollups, tickets of this kind has become the source of inconvenience and potential security issues. To simplify and provide more safeguards to the ticket system, a more systematic accounting method for tickets is being introduced and, along with it, tickets of zero amount will be phased out of support.

Tickets of zero amount will be rejected while there are safeguards and assertions in several places. They will not be accepted as a valid value of any given ticket type, when parsing a Micheline node into a Michelson value. They will not be able to get instantiated using TICKET or SPLIT_TICKET instructions. Therefore, during execution of smart contracts, those instructions will return NONE when tickets of zero amount may be created.

This will potentially impact the existing originated contract on the Tezos blockchain. However, after gathering recent Tezos mainnet data, we come to a conclusion that there is a rather low risk in carrying out this migration. Here is how.

Scanning mainnet for tickets of zero amount

We try to identify contracts that has recently created, stored or read tickets of zero amount. Specifically, we fixed a date, 10th of August, 2022, and replay those Tezos mainnet blocks baked after the level 2608372. First, we took the snapshot and imported it into a tezos-node.

    ./tezos-node snapshot import \
         \
        --data-dir data-tezos \
        --in-memory

At this point, we instrumented the Tezos Jakarta protocol to write logs from this protocol to the standard output and inserted logging statement in the interpreters for TICKET, READ_TICKET, JOIN_TICKETS, SPLIT_TICKET instructions to print out warnings about use of tickets of zero amount.

We then ran the node in history mode.

    ./tezos-node run \
        --history-mode full:10 \
        --rpc-addr 127.0.0.1:8732 \
        --data-dir data-tezos

We waited for the node to catch up to the latest block on the mainnet. Once we thought it was ready, we shut the node down and started replay. The actual starting block was 2608373 and, as of writing, the last block to replay was 2635441.

Replaying Tezos blocks with tezos-node is a bit tricky and slow, unfortunately. Even though it does not mutate the data-dir state, it does acquire a lock on that directory and the replay is executed sequentially. With abundance of patience, we executed the replay and waited for the warning logs.

    ./tezos-node replay \
        --rpc-addr 127.0.0.1:8732 \
        --singleprocess \
        --data-dir data-tezos \
        {2608373..2635441} \
        -vv

This run gave us no warning for any ticket of zero amount spotted on the mainnet.

But I am using tickets with zero amount for …

… access control

In this use case, tickets are issued as a proof of granting access to resources with amount zero. A contract that wants to access the resources will split the ticket into two tickets of zero amount, keeping one in the storage and sending the other along as part of a call on the target contract. The target contract can read the ticket to establish authorization facts.

The remedy in view of this change is to replace these tickets with sufficiently large values of amount. If it is definitely necessary to make the authorization permanent, the migrated permission managing contract should provide mechanism to re-issue tickets to allow the user to trade-in the tickets for more of them.

… passing along data with proof of genuine source

In the survey, there is a use case of tickets of zero amount to facilitate trusted transfer of data. Tickets in this use case is a proof that a piece of data is genuinely generated by the “ticketer” contract. This proof will be passing along a chain of transactions to smart contract. This ticket will most likely not end up in storage and instead get dropped in the end.

The remedy will still be replace the amount to be a finite amount, preferably just 1. This use case will continue to be supported and the choice of the amount will be inconsequential any way.

Next steps

We would like to take this opportunity to inform you of this change. Currently, there are several mitigations and upgrade paths available. If you are using upgradable contract pattern, upgrade the code now to include a new operation which is to assign a definite positive value to each ticket in the storage. Otherwise, originating a new contract to re-issue the tickets with definite positive amount is another possible way.

If you have any feedback or concerns to raise, please feel free to reply or contact us.

‍

If you want to know more about Marigold, please follow us on social media (Twitter, Reddit, Linkedin)!