The utility of destruction

By blockchain developer Kasper Keunen.

First and foremost, this blog isn’t announcing or changing anything regarding token economics. It is merely providing a breakdown of why the burning of GET has utility in coordinating and propagating state changes of tickets. A feat that will become increasingly important as the protocol slowly becomes more open-sourced and decentralized. Hopefully, after reading this blog, you will have a better understanding of the purpose of the GET token

GET is the medium of exchange for scalable smart ticketing

This should be old news. But to reiterate; GET is the only accepted medium of exchange to use the scalability and transparency tools offered by the GET Protocol. ETH Gas is used to register data processed by the protocol paid for with the protocol’s fuel: GET.

GET isn’t used as fuel alongside ETH. The Ethereum blockchain is used to immutably register the state data that was produced and processed by the GET Protocol in its ticketing side-chain.

As GET is the only accepted means of payment in the side chain, GET is a so-called medium of exchange role within the protocol.

The GET burn address is like a black hole. Every token hitting its event horizon is trapped forever.

The case for burning

This medium of exchange argument only explains why GET needs to be used by ticketing companies when interacting with the protocol. The argument doesn’t clarify why GET needs to be burned. After all, other ‘forced’ mediums of exchange such as FIAT money aren’t destroyed when used. When using Euros for example they are transferred to a different person or company. So why do we burn coins? Is it because we want to pump the token‘s price? Read further to find out…

Who cares? Burning makes GET scarce

Sure it effectively doesn’t matter for the market price why GET is in demand. In the end, supply and demand determine a token’s current and future market price. Price discovery doesn’t care about intention, just about the market action.

In 2019 the market demand for these 2020-party-glasses was quite high. However, they didn’t make for a solid long term investment. For obvious reasons.

However, when looking at how sustainable the supply and demand for an asset will be, it makes sense to look at why there is demand. In this regard it is interesting to know what purpose burning has beyond that it is a coded requirement. In the remainder of this blog section, I will lay down the utility argument for why the burning of GET is needed for the GET Protocol to truly scale while at the same time open-sourcing the codebase.

Note: The features mentioned in the paragraphs below are still in development. The ticket explorer code with its documentation is expected to be open-sourced before the end of Q1 2020.

Introducing: ticket explorer nodes

The first step in decentralizing the GET Protocol will allow actors in the public to analyze the ticket state change data and serve it to whomever. This task will be done by ticket explorer nodes. Which have a similar role as ETH or Bitcoin light nodes.

The idea behind having any node system is that there is no single point of truth, thus allowing any actor to make up their own mind given a certain set of transactions/state changes. This is what makes it decentralized. However, such a set up comes at large coordination costs. After all, efficiency is why systems naturally move to centralization in the first place. In other blockchains, we see that the coordination problems are solved by introducing a complex system of incentives (rewards) and skin in the game (PoW, PoS) that combined ensure that nodes eventually come to a consensus.

Coordination

Surely GETs ticket explorers could take the approach of the layer 0 blockchain and incentivize explorer nodes to come to a consensus on the ticket states. However, this drastically increases the costs of running a node and thus the protocol as a whole. While high costs for consensus are acceptable for use cases as ‘hard money’ (like Bitcoin) it makes little sense for the ticketing use-case.

Propagation

In a decentralized network, there is no single source of input data for the nodes to ‘feed on’. To ensure consensus, nodes will need to communicate with each other about what they have observed. This is what to refer to as state propagation. As sharing data constantly costs resources, incentives are often provided in blockchain networks to ensure that nodes propagate.

Without any incentives in place for nodes to propagate their state to other nodes, there is no guarantee that nodes in a decentralized network will agree on a set of sequenced transactions. Due to this, we cannot trust the ledger to be in sync.

The GET Protocol is designed to make blockchain ticketing cost-effective & scalable. Ticketing isn’t broken because databases aren’t fast enough in telling if a ticket is validated or not. It’s broken because there is zero transparency and accountability. To prevent solving a problem at the expense of creating a new one, the protocol is better off using a ‘Layer 0’ blockchain to do the heavy consensus lifting, so that the GET Protocol can focus on features that drive adoption and distruption. #LYVQ

Burn address turned API endpoint

So with these considerations in mind, we can pose the question: How to ensure that all ticket explorer nodes come to a consensus, without centralizing the network or needlessly raising coordination cost?

Well, by making the action of burning GET required for new state changes to be picked up for validation by ticket explorer nodes. This essentially creates an on-chain API endpoint by using the burn address as an immutable data feed.

The burning address of GET will act as a feed for nodes to observe. Similar to a read-only API endpoint with all the past and most recent burns. Ticket explorer nodes will observe the burn feed of the burning address and build their local ticket state.

A big benefit of this approach is that the heavy lifting of the sequencing of the incoming transactions is conducted by layer 0 blockchain (Ethereum as of now, Klaytn possibly in the future :) ). It already works out of the box:

https://etherscan.io/token/0x8a854288a5976036a725879164ca3e91d30c6a1b?a=0x0000000000000000000000000000000000000000

Visualization of a GET token approaching the burn address / black hole.

Without opponents, no fights

The benefit of using burning over having a receiver when GET is paid, is that when burning there is no counterparty. Meaning nobody receives the GET. In that situation, there is no clear gainer besides everybody that holds GET. Without such conflicts, the code is less prone to be forked as there is no ‘middleman’ to cut out. As users of the protocol are required to hold GET to use the protocol so any change to this burning will be opposed by all other users.

In addition, if integrators decide not to burn or burn too little for the state changes they propose, their state changes will immediately be excluded from the ticket explorers. It’s quite simple actually — which is a good thing.