Several people have asked me recently what’s the “vision” for the Hive network. For me, that question has two answers.
Personally, I want to use it to launch Hive-based applications for computationally-enhanced information sharing, which is something I’ll talk about in more depth another time.
But, it’s the 2nd answer to that question that I want to talk about today: my vision is to make Hive the most attractive platform for the development of innovative, decentralized applications.
At this point, some people are probably thinking “What? Hive is a social media platform, not an application platform” while others are nodding their head and saying “That’s what I’ve been saying all along”. But please stick around and read this entire post, even if you’re in the latter group, because the more time I spent thinking about it, the more reasons I found why the Hive approach to creating decentralized apps is much better than competing smart contract technology as implemented via script interpreters (most notably in the Ethereum and EOS networks).
First, let’s define what a decentralized app is by specifying what it means for an application to be decentralized, and how that decentralization is implemented. The first decentralized apps were cryptocurrencies, so we’ll use them as an example.
The word decentralized is thrown around a LOT in the cryptocurrency space, and I think many people understand the word reasonably well at a philosophical level to mean a cryptocurrency should have at least the following properties:
But what many people don’t know is exactly how those two properties of philosophical decentralization are implemented at the technical level. Unfortunately, to understand the rest of this post, we’re going to have to delve briefly into how it’s done :-)
Implementing a set of public rules that aren’t controlled by a single entity, turns out to be quite easy: you write some software that implements the rules of your application (e.g your cryptocurrency software), then you publish it as open-source software under a license that lets other people freely run and alter the source code, so that anyone is allowed to validate that those rules are being followed, change the rules if they don't like them, and operate under a set of rules are voluntarily accepted.
It’s also not too difficult to provide trustworthy public data using a well-known set of tricks in the software world: you create a peer-to-peer network where the application’s data is constantly being shared and stored in multiple locations (decentralized storage) and you use fancy mathematical calculations called hashes that were originally designed to detect accidental corruption of data being transferred over computer networks as a means of detecting intentional data tampering by humans. These two features, multiple storage locations and tamper resistance, are what gives a blockchain a property that is often referred to as immutability.
It’s worthy of note that blockchain immutability isn’t really achievable without knowing the rules that define how a blockchain’s data is organized and what the transactions “mean”. In other words, to verify that a blockchain’s data hasn’t been tampered with, you either need to have the software that processes the blockchain data, or a really good protocol specification that describes how that software processes the blockchain data. Just having the blockchain data alone isn’t enough. This is another reason why at least a reference version of a blockchain’s software is usually released as open-source.
A typical 1-layer blockchain has only one process that evaluates transactions and builds blocks. Nodes in the blockchain network receive transactions from users, and compete via some consensus algorithm (proof-of-work, proof-of-stake, etc) to build the next block in the blockchain. To build that block, the block-producing node does three important things: 1) it decides in what order to add the transactions it has received into the block it makes, 2) it evaluates each transaction to determine if the transaction is valid under the blockchain’s rules, and 3) it builds up the “state information” (such as current account balances) based on the transactions that it has validated so that it can supply that state information via an API to any other process (such as a wallet) that wants to know it.
The first two steps above, transaction ordering and rule validation, are very important to the integrity of a blockchain’s “ledger”. One simple example of why this is important is the “double spend” problem. A potential double spend can happen when a user creates two transactions that pay two different accounts from the same source, spending most or all of the money in that source. Since there’s not enough money in the source to pay both destination accounts, only one account should get the money. By deciding the order of the transactions, the block-producing node determines who gets the money. And by applying the blockchain validation rules, it accepts the 1st transaction into its block and it rejects the 2nd transaction (and doesn’t include it in the block it creates).
In a 2nd layer blockchain application, the main function of the “1st-layer” block-producing node is simply to order the transactions into a block, and it doesn’t know all the rules that make a transaction valid or invalid.
In the most extreme case of a two-layer network, a 1st-layer node might know virtually no validation rules other than how many bytes it can fit into a block, and its only function is to order the transactions in the block until it runs out of transactions or the block gets filled up, without any understanding of the data inside the transactions. Also, because it doesn’t understand anything about the transactions, the only API methods supported by such a 1st layer node would be to allow blocks and transactions to be fetched. In this extreme case, there must be at least one 2nd layer process that validates the transactions that have been put into a block and builds state information, ignoring the transactions in the block that don’t meet the validation rules of the 2nd layer process.
In a more typical case of a two-layer network, the 1st-layer knows some rules (for example, it can validate simple money transfers in some base currency) and provides an API for state information about those rules (e.g. it can provide account balance information), but it can also add transactions with arbitrary data to its blocks, where the transaction data only has meaning to one or more 2nd layer applications.
Hive is a great example of this latter type of two-layer network: the 1st layer node of Hive can process most types of Hive transactions, but Hive also allows for arbitrary data to be added to a block using a “custom_json” transaction.
Anyone can write their own 2nd layer Hive application that gives meaning to these custom_json transactions, and they can do it without requiring any changes to the “core” Hive software.
Two well-known examples of such 2nd layer applications are Hivemind (which provides social media information to sites such as https://hive.blog) and Splinterlands. Whenever you “follow” a user on hive.blog or start a splinterlands battle, your wallet is publishing a custom_json transaction that the 1st layer node blindly adds to the blockchain without any kind of special processing. Such transactions require one of these 2nd layer applications to make the transaction information useful.
A 2nd layer application is not automatically a decentralized application. Remember, a decentralized app has to have two properties: publicly available immutable data and a public set of rules. All 2nd layer apps inherit immutable data from the blockchain built by the 1st layer network, but the application must still publish the rules it operates under. As mentioned previously for 1st layer blockchains, the easiest way to do this is to open-source the 2nd layer application.
Now that we’ve covered the differences between 1-layer and 2-layer transaction processing, let’s examine some of the advantages and disadvantages of adding new functionality to a blockchain using each processing method. We’ll also compare 2-layer transaction processing versus a somewhat famous type of 1-layer blockchain: the so-called “smart contract” blockchains.
The most straightforward way to add new functionality to a blockchain network is to add a new type of transaction that it can process. This is done by doing a so-called “hard fork” where all the network node operators update to a new version of the blockchain software with new or changed rules.
But there is one problem with this method of adding functionality to a network: you have to convince node operators to update to the new code. If the new functionality is something that most node operators think is useful, that’s not a big deal. But if it’s some feature that’s mainly interesting to a smaller group of the network’s users, then it may be difficult to convince node operators to update. Imagine, for example, if one hundred different proposals for small feature upgrades were made over the course of the year by different people. If the blockchain was going to be updated for each feature as soon as possible, node operators would need to upgrade every couple of days. Even Microsoft doesn’t force upgrades that often.
So if you want to allow anyone to be able to add functionality to a blockchain without convincing node operators to upgrade the software, you need another way of doing it. Currently, there’s two main ways to approach this: 1) adding a scripting engine to your 1st-layer process to execute the user-written scripts called smart-contracts “in-process” and 2) 2nd-layer apps where the additional functionality runs outside the core blockchain process.
You might wonder why you would ever want to do a hardfork, when you can directly add new functionality to a blockchain via a smart contract or a 2nd layer app. The answer is pretty simple: you can’t change blockchain functionality with these methods, you can only add more. So when you want to change the base behavior of your blockchain, hardforks are still required (and you still have to convince those node operators to update their software). Fortunately, for many blockchain applications, adding new functionality is all that is needed.
A careful reader may have already noticed one advantage of a 1-layer blockchain vs a 2-layer blockchain: only valid transactions are stored in the blockchain’s blocks. This means it potentially takes less storage to store the blocks since invalid transactions are discarded.
But this only tends to matter much if a lot of transactions that get broadcast to the network violate the validation rules. Practically speaking, this isn’t common, because the wallets that generate transactions usually pre-validate a user’s transaction before broadcasting it to the network and won’t broadcast the transaction if it fails the pre-validation step. So in practice, this isn’t much of an advantage.
Existing smart contract blockchains require you to code your new feature in the platform’s scripting language. In practice, this often severely limits the pool of programmers who are qualified to add features to such blockchains. And it also severely limits what libraries of existing functionality can be leveraged to rapidly create a new application.
By contrast, since 2nd layer apps run in a separate process and communicate with the 1st layer via network API calls, 2nd layer apps can be implemented in any language. In fact, it’s easy (and often useful) to build a 2nd layer app using more than one language, where the 2nd layer’s app is divided into separate microservices running in separate processes.
Theoretically, a smart contract platform is built in such a way that a buggy or malicious smart contract is not able to take down or corrupt the entire platform. But because the smart contract runs inside the platform’s process, there’s many ways that this safety guarantee can potentially fail. One of the most difficult things to do is to prevent the smart contract from consuming too many of the platform’s resources (e.g. cpu cores, memory, network bandwidth, and disk storage) and bringing the entire network to its knees.
Unlike a smart contract, 2nd layer apps run in a separate process, which means that the platform can rely on security and resource quota features of the base operating system to protect against such problems. For even higher security, the 2nd layer apps can be run on an entirely separate computer, effectively prevent any problems from the 2nd layer app other than network bandwidth and data storage usage for its transactions.
Another nice benefit besides safety of the fact that 2nd layer apps run in a separate process is that they run fully parallel to the 1-layer blockchain, so they can be horizontally scaled across multiple cpu cores and even across multiple computers without any complex coding required.
I’m even going to argue a final benefit for 2nd layer apps running out of process: it makes their support more voluntary (a principle that is deeply embedded in decentralized philosophy), in my opinion.
On a smart contract platform, every node operator is forced to run all the smart contracts on that platform, even if he has no interest in expending computing resources on that smart contract. With 2nd layer apps, only operators who want to support a 2nd layer app need to run it on their computers. In essence, support for each 2nd layer app on a blockchain is an “opt-in” behavior, similar to the opt-in behavior when a computer operator decides to run a 1st layer blockchain.
At this point, I hope I’ve convinced you that 2nd layer apps represent a better way than smart contracts to design decentralized apps. Next, let’s take a look at the kinds of features that a blockchain should have to be the ideal ecosystem for 2nd layer apps, and see what’s already done, and what can be done to make the Hive network into that ideal ecosystem.
Your choice of a 1st layer blockchain imposes inherent performance limits on what is possible to do in your 2nd layer apps. There are fewer limits than those imposed by a smart contract platform, since your processing doesn’t have to run inside the 1st layer process, but you’re still throughput-limited by a couple of factors: how many 2nd layer transactions can be included into blocks, how big those transactions can be, and the rate at which blocks can be created.
This means that for many 2nd layer apps which expect to see a rapid increase in transactions with a growing user base, the developers should choose a 1st layer blockchain like Hive, which has a high transaction throughput.
A related factor is that you should choose a 1st layer platform where transaction costs are not too burdensome to the app’s users. Hive also excels in this area, as there are no direct fees for transactions, although a user’s transaction throughput is still limited by the amount of Hive he has powered up.
Another benefit of choosing Hive for your 1st layer platform is that Hive has a large base of engaged users to which you can market your 2nd layer apps benefits. Hive users are naturally inclined to try 2nd layer apps that are hosted on Hive, and Hive’s social media features allow for easy marketing of 2nd layer Hive apps to that user base.
An available set of standardized, modular microservices can significantly ease the development of highly functional 2nd-layer apps. Such microservices allow apps to offer many useful features without having to “re-invent the wheel”.
Hive already has several such microservices, with the most well-known microservice being Hivemind. Hivemind allows apps to access Hive’s social media data and it’s how 2nd layer applications such as hive.blog, peakd.com, esteemapp, etc are able to display that data in a standardized way to their users.
Another well-known microservice running on Hive is Hive-Engine, which can be used to create and manage tokens for a 2nd layer app.
But we’ve really only begun to scratch surface of what’s possible with Hive microservices. In the upcoming development of the Hive ecosystem, I believe such microservices will play a key role in Hive’s future as a 2nd layer decentralized application platform.
If you’ve done any research into cryptocurrencies, you’re probably somewhat familiar with smart contract platforms such as Ethereum and EOS. But you’ve probably not heard as much about 2nd layer applications. So you might be surprised to learn that the 2nd layer applications I’ve been describing were actually implemented long before smart contract platforms.
The first 2nd-layer application was OmniLayer (originally called Mastercoin). OmniLayer was built as a 2nd-layer application protocol over the Bitcoin network. Just like any other 2nd-layer application, it works by storing data on its first layer platform (Bitcoin’s blockchain) that the first layer software doesn’t understand, but that the 2nd layer can process. OmniLayer has built-in functions for creating and managing tokens. One of the best known of such tokens is Tether USDT, a stablecoin backed by Tether.io.
Now arguably, OmniLayer never really took off: it’s only successful token was USDT, and now most of the transaction volume for USDT tokens has moved from Bitcoin to faster 1-layer networks such as Ethereum and TRON, where the tokens are implemented using smart contracts instead. So it’s worth briefly examining if OmniLayer’s failure is an indictment of 2nd layer apps.
In my opinion, OmniLayer failed for two reasons: 1) it operates on a 1st layer blockchain with low transaction throughput, high latency, and high transaction fees (the Bitcoin network) and 2) it was designed using a monolithic architecture where all 2nd layer apps run in the same process, which effectively defeated most of the advantages I’ve previously cited for 2nd layer apps.
2nd layer apps built on Hive, by contrast, operate on one of the fastest blockchain networks, and they are designed using an out-of-process microservice architecture. So while they are both theoretically a 2nd layer apps platform, it’s really an apples-to-oranges comparison when you look at things that matter to apps developers and users such as transaction latency and throughput, ease-of-development, security, and scalability.
