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.
