This is a post about tokens and decentralized applications and how they can work well together. We’ll explore decentralized apps, decentralized app protocols, and how tokens can enable new possibilities for these protocols.
Decentralized Apps as Public Internet Utilities
I like to think of decentralized apps or decentralized app protocols as public internet utilities.
We have lots of centralized applications on the internet today like Facebook, Google and Twitter, but we also have certain applications that are protocols or collections of applications, like e-mail.
Email has an underlying protocol called SMTP. And it has many different pieces of software that operate on this same protocol. There are email clients, servers and various pieces of software that provide additional services.
Email is not a private application. It is a system, network and protocol that many different applications can operate on top of. Thus it is essentially a public internet utility.
In a system like email, one can build it out as a protocol where users simply communicate with one another using the pieces of software that they choose.
Compared to some other decentralized protocols like Bitcoin, email is very simple. It’s just a way for two computers to talk to one another.
With Bitcoin, however, we have global state. We have some piece of information that needs to be globally shared between all computers. Thus Bitcoin and other blockchains are not just protocols — they’re also networks that maintain a concept of digital ownership.
With any protocol network that has this property, there needs to be a way to allow all of the computers to coordinate and produce a collective view that they can all agree upon.
Further, to create a collective view, we need mechanisms for allowing the computers to communicate and collaborate in a trust-free environment, all the while combatting spam and efficiently allocating resources.
Resource Allocation in Blockchain Networks
Blockchain networks like Bitcoin and Ethereum require a series nodes to process a series of changes to a globally shared database or ledger. Let’s look at Bitcoin first.
Bitcoin is a fixed bandwidth transaction network that can only allow 1MB of transactions every 10 minutes (approximately 3000 transactions).
The resource here is transaction throughput, which translates to three resources that all Bitcoin nodes are expected to handle:
- bandwidth
- storage
- signature computations
Signature computations often get overlooked but they can often be a bottleneck depending on the situation. It is a core expensive computation that Bitcoin nodes are expected to handle.
The signature computations are somewhat consistent across different applications but what Bitcoin does generally is put a cap on the signatures that can be processed and validated in a given block so as not to overwhelm all of the nodes in the network.
Further, a mechanism is being developed where transactions will cost more when they require the validation of more signatures.
Resource Allocation in Ethereum
When we move over to Ethereum, we have a system that has more richness in it’s programmability. We have the ability for transactions to be a lot more complex. You can put any kind of blockchain-state-manipulating code you want in a transaction, and every node is expected to process the code, and is expected to run through all the same computations.
What we have here is a system where one person can write a contract and put in code and instructions, and then all the other nodes have to process that and have to execute the set of instructions.
In the case of Bitcoin the transactions all come down to a certain amount of data that needs to be stored and a certain amount of signatures that need to be validated.
In the case of Ethereum, there are signatures that need to be validated, there are additions that need to be calculated, there are lists that need to be appended to, and all of these operations require computation.
What Ethereum does is create a mechanism by which one can assign a resource to be consumed for every single computation in the system. That resource is called gas and can be purchased with Ethereum itself. Certain contracts will require many more computations and so will cost more.
Thus there’s a conversion rate between Ethereum and gas and a conversion rate between gas and computation cycles.
So we’ve identified three scarce resources here in Ethereum:
- bandwidth
- storage
- computations
All nodes on this peer-to-peer network need to handle the bandwidth of all of the transactions, need to store all of their data, and need to run all the computational instructions inside of all of them.
A Fourth Scarce Resource
As it turns out there are very few network resources that are inherently scarce. The list is long for resources that could be made to be artificially scarce, but inherent scarcity is, well, scarce.
This in turn means that there’s a very limited number of things that tokens are absolutely, fundamentally required for.
Beyond the first three scarce resources that are shared by both Bitcoin and Ethereum (bandwidth, storage and computation), there’s a fourth inherently scarce resource that’s actually been around since the beginning of the blockchain universe — naming.
Desirable, human-meaningful names are inherently scarce on a global network. That’s because names are only useful when they are canonical — when there is one and only one possible entity or concept they could refer to — and there’s a limited supply of desirable names.
For example, with single letter alphabetic names, there are exactly 26 of them in the English language. So if you want a one letter name, that is extremely scarce. And that needs to be allocated in some way.
In the case of names it is scarce because every single node that the maintains the naming system is aware of the same state.
Naming for Discovery
Naming forms the basis of discovery for everything on the internet. When you want to visit a website from your address bar, you type in the domain name. When you search for something in Google or in the Apple app store, you type in some search term that translates to a unique record with a unique name.
From search engines to app stores to social networks, if you want to find something, you’ll have to know how to refer to it. And the unique name lets you or your software know you’ve found exactly the right app, person, or other record you were looking for.
The Key Question
The key thing to ask yourself when determining whether something is conducive to scarce resource allocation is the following:
“Are the operations consuming a resource of every single node on a decentralized network?”
And if that is the case, then scarce resource allocation applies.
For example, let’s say you have a system like Bitcoin and you have 10,000 nodes, then sending a transaction requires all 10,000 nodes to process the bandwidth of the transactions as well as store the transaction data and verify the signatures. These are resources that are consumed across 100 percent of the nodes on the system.
Similarly, if you have a system like Blockstack that hypothetically has 10,000 nodes, you have a situation where all 10,000 nodes need to process the name registration instructions.
In all of these cases, there are real scarce resources that are consumed across all nodes on a network.
Artificial Resource Allocation
There are some systems for which resource allocation can be artificially imposed but where there is no inherently scarce resource.
Email, for example, is a communication protocol where two parties can use the protocol without needing any awareness whatsoever of any other party in the system.
Put another way, email is a multi-player protocol instead of a massively multiplayer protocol. There is no global state whatsoever.
Bitcoin and Ethereum and Blockstack, however, are massively multiplayer protocols with massively multiplayer state.
Thus, email can have a token for resource allocation but it will be “bolted on” rather than being inherent to the system. That means an email token would not be required but it could still add some interesting functionality (e.g. rate limiting and spam protection).
Building Network Effects
Beyond efficiently allocating scarce resources, protocol tokens are extremely powerful for enabling network effects.
The key is figuring out a way to distribute tokens to anyone who contributes resources to the network.
This token distribution process becomes a powerful incentive mechanism that draws in more and more parties to contribute resources and strengthen the ecosystem.
For example, with Blockstack we have a three-part mining system that incentivizes three core actions:
- Rewards are given when you sign up and verify your identity as that increases the userbase
- Rewards are given when you build a highly rated app as that strengthens the app ecosystem
- Rewards are given when you burn bitcoin as that increases the economic cost of creating a new competing chain (and in turn enables light clients)
When to Use Protocol Tokens
Protocol tokens are powerful tools for decentralized app networks.
The two key questions to ask yourself are:
- Are the operations consuming a resource of every node on a decentralized network?
- Is there a key action on the network that can be incentivized by token distribution?
If your network fits one of these criteria, then it’s a great candidate for a protocol token.
Comments? Tweet them @ryaneshea.
Enjoyed this article? Please take a moment to “clap” it 1+ times (up to 50).
