GET Protocol — The ticket NFT production line

getNFTs are rolling off the production belt!
After a full year of focusing on testing locally the first getNFT mints have finally hit the public ledger over the last weeks. Over the last 72 hours more than 35 000+ getNFTs have been minted by GETs 'playground' runner.
This runner is only the mocking the back-filling of 120 000 backlogged tickets in our system. The actual back-filling of the tickets will be done if the mocked back-filling is completed.
Isn't minting easy?
It is. However it isn't the mint that we are testing here. The process of minting and back-filling involves far more complex actions as only the minting transaction. Before a mint transaction is sent to the getNFT contract on-chain a lot has happend in the backend of both the ticketeer as well in GETs servers running the getEngine and getCustody. It is these processes that require attention and monitoring. The diagram below gives a rough overview of what is going on behind the scenes.

Diagram showing all the processes that occur for a blockchain transaction to occur. Every new ticket owner is assigned a fresh wallet address on the fly, this address will be the owner of the NFT. After a successful mint the ticketeers backend is provided the location of the NFT. This will allow ticket holders to view their smart ticket 'on chain' in the near future!

Better safe than sorry
The minting process requires several database writes and callbacks to databases of our ticketeer integrators. As the production databases serve thousands of people on a daily basis we need to be certain flusher doesn't disturb stability of these systems. Due to this we need to be very certain that our back-log mints and data-writes do not slow down or cause unexpected errors. So for no issues have been observed — steady as she goes!

Next week we'll start the back-filling the backlogged tickets using the live systems. This will cause the registration of more than 120 000 tickets and 200+ events!

getNFT blockchain privacy
When observing the getNFT ownership one might notice that each wallet at most owns 1 getNFT. This isn't because all the ticket holders don't have any friends or because they are overly compliant to covid laws. In the getNFT system each ticket lives on its own fresh wallet.

1 wallet, 1 NFT — it is only fair.
To ensure privacy getNFT does not recycle wallet addresses — ever. Meaning: 1 ticket — 1 owner — 1 wallet. Always.
If a user buys 5 tickets, these will be registered to 5 wallet addresses with 1 getNFTs each . Even though these wallets 'belong to each other' as they are seeded from a HD wallet — for an outsider observing the blockchain this connection can't be made (mathematically impossible to do so).
This means that for an outsider it is impossible to identify a user based on the amount of tickets owned — as this can be an identifying factor (one of many). No data is leaked — at all, at any times. There is no way a person can be DOXed — even if external data is included (like Facebook attendance data).

Privacy first
Privacy is a serious matter. The fact that with a blockchain all records are public domain and cannot be deleted on request makes it even more persistent. For example we would be technically unable to comply with a GDPR right to be forgotten request without lobbying for an Ethereum hardfork.

Transparency as a service — getScanner API
In the previous blog I shared some details on how anybody (with knowledge of blockchain explorers) is able to query the getNFT smart contract to get to know more about a certain event or particular tickets. Surely copying hashes in a clunky smart contract interfaces isn't how we envision the future of ticketing to be experienced.
Our growing blockchain team is working on a kick-ass ticket explorer. However, we do not want us to be the only ones serving up the blockchain data. One of the reasons the blockchain space is so vibrant and innovation is so fast paces — is due to the fact that all data and tools are accessible for anyone, anywhere without consent. Allowing anybody to build on the GET Protocol is one of our key objectives. Open sourcing the code base is only part of the solution. Ensuring that the ticket/NFT data is easily queried is maybe even more pressing.

Those wanting to use our getNFT assets or registered event data in their own app or site should not have to study the Solidity ABIs. Requesting data about a ticket should be as easy as doing an API call. This is why we are offering an (open sourced) node repo called getScan. The diagram shows the pivotal role these nodes will play in tying everything together.
Some example queries:
Fetching event data
Fetching ticket owner data.
Fetching ticketeer data.

We expect to publish the full documentation for using the getScan API next week!

V4 of getNFT contracts
A key point of using a blockchain as data-storage mechanism is that the data is immutably registered. No do-overs, no edits, no censorship. This 'blockchain feat' is pivotal in solving the inefficiencies in the ticketing sector — as these are caused fundamentally by distrust. This immutability does pose challenges from the continues development side of things.

Upgrading the immutable

With blockchain data written is immutably stored. Data can technically be deleted, but it will remain possible to lookup what its previous state was. The code writing the data is also persistent(by default). As GET is constantly improving and adding new features this immutability poses a challenge if one wants to incrementally improvement and add features.
When using the default smart contract deployment process, every change to smart contract code would result in a completely new smart contract address for getNFTs. Causing a wild growth in getNFT contracts. Surely this isn't viable — luckily there are several Solidity design patterns that allow developers to upgrade contracts while keeping persistent storage.
After a long period of research and testing we completed a up-gradable version of our getNFT Factory contract as well as the event metadata contracts. A diagram showing the architecture of our approach is shown below.