A state change of tickets and other tracked assets in the GET Protocol results in a state change receipt. A single receipt contains 4 data points about a state change of a digital asset tracked by the GET Protocol. Receipts are aggregated in Receipt Batches. These files are periodically stored on the public IPFS network. By blockchain developer Kasper Keunen.

This blog will provide details on the concept of Receipt Batches in the GET Protocol.

A single state change defined: If a ticket is scanned it changes state. The ticket changes from being valid to being invalid.

In Statebox/petri-net jargon we refer to a different state as a ‘place’. By scanning a ticket moves from the ‘valid’ place to the ‘activated’ (or invalid) place. In its new place the ticket has different properties. To read more about the different properties per place read this blog.

This change of a ticket state means that its new state (or new place) the ticket asset has different properties. In order to spread to other actors in the GET Protocol that a certain state change has occurred, state change receipts are used. More information about the structure of state change receipts is disclosed in this blog: (NOT YET PUBLISHED).

Screenshot of 8 state change receipts in the form they are currently stored on the IPFS network.

Receipt batches

Stoolbox stores the ticket mutation data it collects periodically on IPFS. IPFS is essentially a distributed and public Google-drive (IPFS has a lot of similarities with the torrent file network). After a file is stored, anybody with an internet connection and knowledge of the location of the file can access the file. Example of an IPFS batch as stored by the GET Protocol.

The fact that IPFS has no centralized controller is a feature. As it is impossible to censor or manipulate. However, because of this feature, there isn’t any guarantee data stored to IPFS will remain available. In addition, there is no reliable way of knowing how long a file to IPFS has been stored there.

In order to make the data published to IPFS immutable, blockchain anchoring of the IPFS file location is used. This means that the file location on IPFS is stored in a smart contract(currently deployed on Ethereum). We call this contract the ‘IPFS anchoring smart contract’.

Batch anchoring smart contract

The current implementation of this contract has two main functions:

Making the IPFS batch locations public (like this). The contract acts as a single source of truth for the ticket explorer nodes (decentral API endpoint) Timestamping and sorting the batches in an immutable manner.

The smart contract code that is currently used to anchor tickets can be found on Etherscan.

Immutable timestamping

The role of the IPFS anchoring smart contract is to store and timestamp the IPFS hashes containing the state change batches in an immutable and public manner.

By crawling this public smart contract, a ticket explorer can collect the complete transaction history of the GET Protocol.

Figure A. Diagram showing the storage and ordering function of the IPFS anchoring contract.

Note for developers: The address and exact coding of the IPFS anchoring smart contract is expected to change in the future. For example we are working on adding a GET proof of burn check part of the contract logic. If you have ideas or suggestions on how to go about this in a decentral manner we would love to hear them!

More details on the API-endpoint approach of the burn-address is explained in the blog linked below.