In our post Don’t Wait for SMTs to Build Your Steem DApp we referenced the idea that Steem is similar in design to an ASIC miner. In today’s post we want to explore what that means a bit further, and why it was a critical design decision that lies at the foundation of the protocol. It’s this application-specificity that enables Steem to scale faster, and provide more utility to developers than general-purpose protocols.
For those who aren’t aware, an ASIC Miner is a piece of computer hardware that is designed entirely around serving a single function: mining Proof-of-Work cryptocurrencies. Understanding the history of ASIC miners sheds some light on the benefits of Application-Specificity.
As most readers are probably aware, the original cryptocurrencies (and many new ones) were secured by an algorithm called “Proof-of-Work”. This algorithm effectively mandated that in order to win a cryptocurrency token you had to allow a peer-to-peer protocol to make your computer perform work that gets progressively more difficult over time. In short, the more computing power you have, the more tokens you earn.
At first people earned (or “mined”) these tokens using the Central Processing Unit (CPU) of their computer. The CPU is like the “brain” of your computer. CPUs are designed to be flexible‒to process information in all kinds of ways‒so it was easy to use them to run this brand new software. This is the benefit of general-purpose platforms; they can be adapted to solve a greater number of problems. But the downside is that they can never be especially good at any one thing.
GPUs (Graphics Processing Units), on the other hand, are processing units that are not very flexible at all. They’re designed to only process one type of information: graphical information. Instead of having a few big cores that can do all kinds of computations, GPUs can have over a thousand small cores that do one thing really well. It wasn’t long before people figured out how to adapt those cores to solve Proof-of-Work hashes. Once they did, those GPUs could outperform CPUs by orders of magnitude, making CPU mining obsolete.
This is what a general-purpose platform looks like:
[Source: ASIC Resistance is Nothing but a Blockchain Buzzword by StopAndDecrypt]
This is what an application-specific platform looks like:
[Source: ASIC Resistance is Nothing but a Blockchain Buzzword by StopAndDecrypt]
In the move from CPUs to GPUs we see an example of how more specialized hardware can dramatically outperform general-purpose hardware. However, innovation in the space did not stop there. Instead it continued to its natural conclusion; the ASIC miner. We say “natural conclusion” because effectively what ASIC means is: hardware designed from the ground up to solve a specific problem. The only thing that can beat an ASIC miner is a better ASIC.
While GPUs gave miners access to many more cores that could be leveraged to mine, those cores were not designed from the beginning to mine. That’s what changed with the release of ASICs which went on to make GPU mining as ineffective as CPU mining. Once specialized equipment exists, it becomes nearly impossible for a more general solution to beat it for many reasons, but essentially this is because whatever innovations are integrated into that general solution to improve performance can just be integrated into the application-specific solution, making it even better.
Technically, there are many ASICs in the world. For example, the chips that are inside digital voice recorders. As long as a machine is only performing one type of computation, and the value of performing that computation is sufficiently high, hardware that is designed and built from the ground up to solve that problem is going to outperform hardware that is not.
ASICs are so powerful that they have led to a problem in the blockchain space which is that Proof-of-Work blockchains have become highly centralized in the hands of those who have the most ASIC miners. Not only that, but in all likelihood, this is a problem that has no solution (aside from abandoning Proof-of-Work as we chose to do with Steem). While there are those who claim to have “ASIC resistant algorithms,” the truth is that something can only be ASIC resistant to the extent that it is not valuable. If having a computer solve a specific type of problem is sufficiently valuable it becomes inevitable that someone will develop a device designed specifically to solve that problem and that this device will outperform anything else that is more “general-purpose” (i.e. not designed to solve the problem).
Of course, whether this is a good thing or bad depends entirely on your position. For Proof-of-Work blockchains it is a battle they have committed to fighting for all eternity. But for the manufacturers of ASIC miners, who were small upstarts lacking the economies of scale afforded to massive GPU manufacturers like Nvidia, application-specificity was like wind in their sails, propelling them past their larger and better funded competition. This is the very same dynamic we sought to leverage when designing Steem, and now seek to maximize as development continues.
As you can see, application-specificity is incredibly powerful. The best runners will always be better at running than the best triathletes. Race cars will always go around a racetrack better than sedans. This is because, in effect, application-specificity is just another way of saying "focused". A product (and the team behind it) that is focused on solving a particular problem is always going to outperform a product that is focused on solving a larger suite of problems.
The real challenge is in determining what particular problem should be solved. Just solving a random problem isn’t going to serve as a strong foundation on which to build an entire ecosystem. Instead, the goal should be to solve the specific problems‒and create the specific solutions‒that are going to deliver the most value to those who utilize them. While it is all well and good to theorize what these may be, we took two courses of action which ensured that the solutions we generated were tightly aligned with the needs of real application developers.
First, we insisted on building something that could power real applications in the here-and-now. Second, we built one of those applications ourselves (steemit.com). Our theory was that this technology could power next-generation social applications, but it was these decisions that enabled us to validate that theory, and then ensure that development proceeded in the right direction by exposing us firsthand to all of the problems developers would face when building on Steem.
The result of this approach was to build Steem so that it could store content in a decentralized content management system and then autonomously distribute tokens to the creators of that content based on crowdsourced stake-weighted voting. While the code that enables this functionality (the “tactics”) is complex, the approach (the “strategy”) is that simple. On the other hand, a protocol aimed at enabling this capability and any other capability a developer can imagine is necessarily going to be more complex at every level leading to inefficiency and difficulty scaling.
As Steem has demonstrated, when you pick the right features and focus on doing those really well the result can be explosive growth. Developers are incredibly resourceful, so if you give them a great solution to a specific problem, they will figure out ways to add the functionalities they require to that solution.
Steem offers developers a decentralized content management system and a decentralized token reward system that are fast, free and capable of operating at far greater scale than any other solution in the space. Because it solved those problems far better than any other blockchain protocol, it has provided a ton of value to developers looking to build applications that were especially well suited for those solutions. But what these developers also found was that you could still get much of the functionality (if not all) of Smart Contracts on Steem through Custom JSON operations.
It should have come as no surprise that developers were able to find ways to “hack” Steem to solve additional problems beyond those targeted by the application-specific features that it was built to address. That is what happens when you focus on solving only the most important problems that developers and entrepreneurs are facing. When you offer a solution to those problems‒and only those problems‒it becomes easier to scale, and scale with the most successful enterprises that are leveraging your software. If you can deliver that, then those enterprises and developers will figure out how to add any other functionalities they need using second layer solutions. The key is facilitating those second layer solutions in a scalable manner, which where Steem's treatment of Custom JSON operations comes into play.
This is exactly what you want: the most valuable database structures in the base layer where everyone can make use of them, thereby maximizing the network effect and interoperability, while less universal structures are built on secondary layers. This makes the ecosystem even more healthy by ensuring that only critical information is included in the base layer, thereby preserving its ability to scale.
Unfortunately for general-purpose platforms, they do not get to take advantage of this dynamic. Instead, application-specific solutions implemented at the base level are more likely to create problems than benefits. Vitalik Buterin (the creator of Ethereum) explained in a recent article how Ethereum’s decision to include operations that were specific to facilitating elliptic curve operations were already outdated and Ethereum would need to fork in order to catch up. This is due to the fact that Ethereum was not conceptualized and executed with the intent of solving clearly stated, and limited, problems. Because of that, no matter how valuable a specific solution might be, integrating it at the base level will always conflict with the fundamental value proposition of that protocol: to provide non-specific (i.e. general) solutions.
The opposite is the case with Steem. Because the protocol was constructed from the ground up to solve specific and widely understood problems, it is far easier for the community to come to a consensus over what “belongs” in the base layer, and what does not. The second layer databases that inevitably emerge from such a process aren’t just “where they belong,” they even present financial opportunities for developers and entrepreneurs who can identify and implement them thereby creating additional value for Steem’s built-in developer-base. UserAuthority is an example of one such database.
These databases can even be a supplementary revenue-source for developers who build them for use in their application, only to discover that their need is not unique. At the same time, these supplemental databases provide valuable insights with respect to what should be added to the base layer by serving as a more safe and dynamic environment for experimentation. As you can see, application-specific solutions are so powerful because, when they are properly executed, a solution that is discovered at any layer of the stack feeds back into every other layer leading to exponential returns.
When the concept of Smart Contracts was first proposed, the primary claim was that they would enable developers to build decentralized applications. It’s been 3 years since Ethereum was launched and yet Steem‒a protocol that does not have “Smart Contracts”‒now has far more decentralized applications that ordinary people use every day. In fact, Steem is the only protocol that has any applications with real usage and we believe that this is due to its application-specific design. While all of this began with a theory, over the course of developing Steem (and developing on Steem), the power and potential of an application-specific blockchain became even more apparent and enabled us to see how this potential could be multiplied by 10x through the addition of Smart Media Tokens.
What makes an application-specific protocol like Steem ideally suited for SMTs will be the focus of a future article in this series. If you’d like to learn more about the Steem blockchain and how its application-specific solutions can be leveraged to improve any web interface, go to https://developers.steem.io.
Steemit Team
