Skip to main content

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.

Comments

Post a Comment

Popular posts from this blog

What is iDice?

iDice is a dice betting Dapp fueled by the use of the Ethereum organize. eg. iDice lets in players do several things and having such an innovative new token on the ETHEREUM Platform, we had to write an article about this new project. Guess on the space by the use of keeping up iDice tokens and best of all 100% of all benefit iDice acquires is dispersed among token holders, related to the amount of tokens they dangle. iDice amusement code is decentralized and changeless. Such gigantic building fees highlight a rising requirement for experienced, fair and cast Dapps. iDice iDice is an control which gives a provably affordable and simple, virtual Ethereum dice betting Dapp. The house edge will be set intensely and token holders have an atypical esteem that is dependably equiva- loaned to the house edge. iDice has a fully simple provide code accessible at etherscan.io. The payout of recreations is many times speedy. Provably Fair iDice uses open provide blockchain...
Post a Comment
Read more

Spanish Banks Form New Blockchain Consortium

A group of Spanish banks has formed the country's first blockchain consortium. Wholesale bank Cecabank announced the effort today, partnering with professional services firm Grant Thornton. Who's involved: In its announcement, Cecabank doesn't say which other institutions are taking part, stating that it "comprises 33% of the Spanish banking sector". However, according to Spanish newspaper El Pais, the group's membership includes Abanca, Bankia, CaixaBank, Kutxabank, Ibercaja, Liberbank and Unicaja. It represents the first major foray into blockchain for these companies, as other Spanish banks, including Banco Santander and BBVA, have been working with the tech for some time. What they're saying: Thus far, only Cecabank has commented publicly on the consortium effort, describing it as a way for its employees to get a top-down understanding of the tech – as well as possible insight into how the bank might actually go about using it. "Employees of all o...
Post a Comment
Read more

Ethereum Smart Contract Issues Frustrate Developers with Fatal Bugs

Only weeks after the execution of a hard fork to mitigate various DoS (denial-of-service) attacks, the Ethereum network and its developers are struggling to deal with yet another major flaw. This time, major issues in regards to smart contracts have emerged, which have rendered the efforts of decentralized applications in the Ethereum network purposeless. On November 1, the Ethereum development team and the founder of Solidity warned users and developers against a bug that allowed variables to be overwritten in storage. Variables in a smart contract are agreements made between two or more parties. Thus, if an attacker can gain access to the storage and alters the variables, crucial agreements in decentralized applications can be affected and funds may be extracted, which may pressure developers to discard previous smart contract-based projects to recompile contracts. Ethereum developers including Ansel Lindner stated that the development of an Ethereum application is failing to opera...
Post a Comment
Read more