2.3 Principle 3

Principle 3. Blockchain has its disadvantages (at least for now).

Large concerts and festivals have multiple entrances and 30+ scanning devices can be in use simultaneously. At this rate, a constant stream of Codes must be scanned and the validity of the tickets verified. After validation, each ticket must be instantly marked as used, to prevent others from sharing the same Code within moments of each other.

Currently, blockchain technology is too slow to accommodate a robust, competitive, and user-friendly instant verification ticketing system at times of such peak capacity. This disadvantage would prevent adoption of a blockchain based solution by the current stakeholders in the market. Until blockchain can accommodate all of the needs of stakeholders—and we believe it will, in time—the GET API fills in the blanks. With this approach, the GET Foundation will bring a competitive ticketing service to the market that will gradually introduce more on-chain solutions over the course of the GET Protocol roll out.

Implementations of this principle

  • Instant(under 1 second) validation of ticket ownership and validity is now done off-chain with the GET API.

  • Critical and sensitive user data is stored on a Postgress database of GET Foundation.

  • A theatre seating selection algorithm and interface will run on a GET Foundation server and shall not yet be computed in the blockchain.

  • A waiting list application avoids blockchain congestion and acts as a load balancer for surges in API-calls. This makes the GET Protocol ticketing application a hybrid blockchain protocol. Utilizing the established and scalable functionality of AWS with the transparent backbone of the Ethereum blockchain.

  • Sale and change of ownership of the smart tickets are registered on the blockchain as soon as the network allows it.