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).
What is a decentralized application (Dapp)?
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.
Philosophical decentralization
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:
- Publicly available rules for the cryptocurrency, that aren’t controlled by a single entity.
- You don’t have to trust some particular entity to be telling you the “truth” about the cryptocurrency’s transaction history and account balances.
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 philosophical decentralization in software
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.
How do 1-layer blockchains process transactions?
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).
2-layer transaction validation
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 2-layer network
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.
Open-source your 2nd layer application to decentralize it
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.
Comparing 1-layer, 2-layer, and smart-contract blockchain networks
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.
Adding new functionality to a blockchain
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.
1-layer validation potentially saves storage space (but in practice, not much)
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.
2nd layer apps can be written in any programming language (or even several using microservices)
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.
2nd layer apps are safer because they don’t run inside the core consensus process
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.
2nd layer apps scale better since they don’t add computational loading to the core consensus process
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.
2nd layer apps are inherently more “voluntary” than script-based smart contracts
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.
Hive: creating the ideal ecosystem for 2nd layer decentralized apps
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.
Hive: A fast, scalable 1st layer process
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.
An engaged customer base looking for new 2nd layer apps
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.
Modular microservices that can be leveraged by 2nd layer apps
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.
@arcange has long provided a generic microservice for performing SQL queries on the blockchain’s data. And as of yesterday, he also announced a microservice for accessing the gamification features of HiveBuzz.
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.
A brief history of 2nd layer applications
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.
Hive vs OmniLayer: why Omni failed, and why Hive won’t
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.
Learn a lot from this post. Thanks. A few things that comes to my mind some in the form of questions:
All your above points are valid, in my opinion.
I wholeheartedly agree that properly constructed 2nd layer apps are much easier to migrate than smart contracts, and this will likely mean that 1st layer blockchains will need to compete to host those 2nd layer apps, and that, in turn, will also drive innovation in 1st layer design.
I agree that Hive's consensus model isn't perfect. But when I look at existing consensus models on other blockchains, I haven't seen one that looks better yet (otherwise I'd just be arguing for changing to that model).
But I'm quite certain we will all be looking for ways to improve it further. One such improvement we've already made in HF24 is delayed voting to prevent attacks using custodial stake on an exchange. And I expect we'll implement a requirement for some kind of occasional re-voting to eliminate votes from "dead" and/or inactive stake in HF25. But I think that changes to the governance model should be made carefully and incrementally, unless the proposed changes are clearly better.
I've also considered moving the entire social layer out of the 1st layer. Technically speaking, it's probably the logical thing to do, but because it's already implemented there, there's a cost associated with moving it, so practical considerations may argue for work to be focused on more fruitful improvements.
We've already moved the most resource-intensive portions of the social media application out of the 1st layer code as a big part of our work in HF24. This allowed us to dramatically lower the memory requirements to operate a 1st layer node (or even an entire API node, because the new implementation in the 2nd layer is much more memory-efficient).
As far as SMTs themselves go, I haven't formed any firm opinion yet, as I need to study their current implementation more to weigh the various tradeoffs of implementing token management in different ways. This requires looking at the functionalities offered, the performance characteristics, etc.
Thanks for your reply. Logical and reasonable.
If the social layer moves out of Layer 1. Will there be a way to earn rewards for 2nd layer Apps other than the current "BLOG POST" reward system?
After having given it more thought late yesterday and today, I don't think it makes sense to move the reward part of the social media application out of the 1st layer. I'll go into more detail on the reasons for this in my next post.
Thank you for the reply. I look forward to your next article.
We run the dapp Holybread.io & have 3 other games in the works.
We are assigning resources to a new layer 2 concept that will be open-sourced once we get it completed and tested on our games/dapp's.
So your thoughts / views / posts are very exciting and interesting.
@blocktrades
I came to you from golos.id ...
On the main page on the right and at the top there is a Strength of the voice ...
The user can always see how strong his power is at the moment ...
So I had a question, why not make the same function here?
It's convenient and comfortable!
Is such a function possible here?
I want to control my power!
Yes, it can definitely be added, and it seems like a good idea to me. I checked just now and there's an open issue for this: https://gitlab.syncad.com/hive/condenser/-/issues/50
If one of the current devs doesn't tackle it in the next few weeks, I'll see if I can't find someone here to do it.
Great news! Can you call someone for help with golos.id?
This isn't a hard task, it's already done on hiveblocks.com. For example, you can check your voting strength with https://hiveblocks.com/@slon1980 . But it would be much nicer to directly show it on hive.blog directly, so we'll do that.
@blocktrades
Thank you very much for the information! I'll watch there for now!
Will app developers be able to update their original deployed code on the 2nd layer? In other words, will the app developers be able to change the rules of the game at any time and have users follow them automatically?
Yes. An upgrade to the rules of a decentralized 2nd layer app is exactly analogous to a hardfork in a 1st layer chain. If the users are ok with your rule changes, they will just continue to rely on your upgraded 2nd layer API servers, and they will all operate under the new rules.
On the other other hand, if they don't like your changes, they can launch their own 2nd layer API servers based off the old rules and rely on those servers. So you can potentially have a split fork, where some users use the new servers and other users use the old servers. The biggest difference to forking on a 1st layer blockchain is that these two 2nd layer forks can both operate seamlessly on the same 1st layer blockchain (so split forking is a little "cheaper" in some sense).
The way I have seen Hive has been a lot simpler but do agree with the 1st and 2nd layers - obviously, you're one of the main developers and going in to a bit of technical background with your understanding of the underlying technology.
For me, HIVE is the base layer of code/software/tech/currency that chugs along in the background, making sure all transactions are recorded.
It's the apps that are built ON TOP of this base layer (i.e. 2nd layer) which is where non-tech folk like me hang out. Apps like peakd, travelfeed, 3speak splinterlands etc all have their own target audience and should have their own marketing campaigns and strategies to bring more users to their dapps that are built on the Hive blockchain.
I'm probably guilty of this as well but in my (non-marketing expert opinion) we shouldn't be marketing Hive as a place for users, rather Hive should be advertised as a place for developers/software engineers etc as a place to build their applications on. Then those applications have their own target audience and marketing depending on the niche they are trying to fill.
If I was any good at graphic design, then I'd be able to draw it better but alas, here is a Paint job to try and depict what I mean haha
So with this, HIVE is the blockchain (layer 1), the apps built on top of it (layer 2) and the red circle around all of them is the community that are involved at all layers.
Yes, your infographic is correct. I probably should have included one, but I got too distracted thinking about the text, and I was hoping the 1 layer/2 layer description was sufficient in this case.
I agree on your point regarding the need to market to developers more, but I think it's also important to market to users, as users themselves make the blockchain more attractive to developers. The two groups are synergistic.
Yeah definitely, both go hand in hand. I'll be working with a professional graphics designer to convert that horrendous paint job in to something that is a bit more appealing to the eye!
I am also hoping the @haveysguides series can drum up (pardon the pun) some interest in bringing more users and musicians/music fans over. Explaining things in non-technical terms is what I'm going for and I can see Hive already being in a prime position to address a big issue in the music industry. Gradual does it.
Wow, narrative and Vital information
I'm extremely glad to see you championing Hive as a layer 2 solution. I've thought that Hive could serve well in this role for a while, and I think the power of this blockchain could easily be compounded by existing L1 protocols like Ethereum.
If you could have any existing dApps from the Ethereum community use Hive as an L2 solution, which would it be?
That's a great question, and I wish I had a correspondingly great answer, but I only have a "press release"-level acquaintance with dapps on ethereum other than some of the token dapps used for ICOs. I haven't even had time yet to research in depth all the apps and dapps on Hive.
Great to see you guys looking at Hive at much wider perspective because being just a social platform is probably a dead end in the long term.
It's like the reward pool is just a way to distribute the tokens and next we have to give them some value.
That's why I would still love to have a decentralized Hive side-engine for smart contracts. For example - as far as I know we can't build any DeFi service on Hive, as it would have to be operated by single entity. Customs jsons are great for gaming and other entertainment stuff, but when it comes to finances, having a trustless way to deposit and manage your tokens is probably a must. And it seems that finance services (and maybe ads) is the best way to bring value to the ecosystem. Cheers!
I think that's a common misconception of Hive devs, in part because the current 2nd layer DeFi services on Hive (Hive-engine and DLease) are currently implemented as centralized services. I had this same argument with several of the devs here at BlockTrades, who felt the same way as you do.
I tried to briefly layout in this post how you can simply achieve decentralization of your 2nd-level app by opensourcing it, but I didn't go into depth on why this works.
Given the length and complexity of this post, I decided to leave those arguments to a separate post, so as to avoid cluttering the overall theme of this post. But just to be clear on my central thesis, I think smart contracts bring almost no benefit over 2nd layer apps in terms of decentralization (in fact, I think it's the other way around in terms of which is more decentralized). More to follow in that later post :-)
The Hive Engine code is fully open sourced, so the only thing that I'm aware of that is run in a centralized way there is transferring between HIVE tokens and the pegged version which I don't see a way around.
Just to be clear, I'm no longer involved in the Hive Engine project so I'm not trying to advocate for it or anything, I'm just asking out of curiosity and personal interest.
What would you suggest that Hive Engine change to be run in a more decentralized manner?
First, I'm really glad to hear that it's open-sourced. As I mentioned in another comment, I haven't had a chance to research even Hive's apps much, so I made an unwarranted assumption. Right now, I mostly only know about the Hivemind dApp, as I'm managing one of our two teams that works on it.
So, from what you've described, there's three things that could potentially be done to decentralize it more: one is easy, one is mildy challenging, and one is hard.
The easy one is make sure there are several API nodes operated by different people (and maybe this is already the case, for all I know).
As a mildly challenging task, it would also be nice to provide some way to allow users to verify that the different nodes are supplying the same data. This is actually going above-and-beyond what API nodes normally offer on 1-st layer blockchains, but I think it would go a long ways towards increasing trust in dApps.
And for the hard task, it's a problem specifically related to the Hive-Engine application, which is in some cases handling tokens on multiple blockchains. However, it should also be emphasized that this problem doesn't apply to tokens which only "exist" on the dApps 1st layer blockchain. Such "single blockchain" tokens should be safe to trust, because they don't require a trusted gateway operator.
BitShares, a decentralized exchange that many people here will be familiar with, suffers from the same problem, where individual API operators have to run the gateways between the blockchains. Such gateways between blockchains have to be implicitly trusted, and this is a big weak point, which has led to user losses in several cases that I know of, when a gateway operator didn't properly fulfill their obligations.
The only potential solution I know of to this problem would be to put code into both blockchains that allow movement of the token between the blockchains in a trustless manner. This can theoretically be done using proofs based off the same types of hashes that allow a blockchain to verify its blocks. But this is something of a "holy grail" for blockchains, and it gets particularly difficult when trying to bridge tokens between blockchains that are implemented differently in terms of their consensus mechanisms.
As a final note on this subject, it's also worth pointing out that smart contracts don't offer any advantages over 2nd layer apps in terms of decentralized apps that manage tokens that can move between blockchains. A trusted gateway is still required, unless you can solve that hard problem above to allow trustless interblockchain transfer.
Thanks for this reply. As far as I know there were a few people who ran their own API nodes, but I'm not sure if that's still happening. There's really no incentive to doing that at the moment which is a problem.
Regarding verifying that different nodes are supplying the same data, I believe this is already possible since Hive Engine actually makes its own blocks that include the transactions in a single Hive block that are related to Hive Engine and their result. The Hive Engine blocks have a hash which includes the hash of the previous block, so you should be able to compare the hashes of the same block number between Hive Engine nodes to easily and quickly verify that they are the same. I'm not 100% certain about that, but pretty sure that's how it works.
Finally, about moving tokens between chains in a trustless manner, I agree that this is a "holy grail" and I know of projects like Cosmos that are implementing that across a number of chains that support custom smart contracts on the base layer. I don't know too much about the details of that, but I think it would be amazing for Hive if we could add something to the base layer that would allow the trustless transfer of HIVE to external chains. I would be open to supporting that type of project via the DHF or otherwise assuming it's feasible and there was someone who could actually build it.
I'm very curious to hear an answer to this question, too.
I answered in a sibling comment.
Aye, waiting for the 2nd post then :)
Interesting, in addition to decentralization, can immutable token ownership be achieved on the 2nd layer?
Looking forward to that post.
Yes, that's pretty much what OmniLayer did for USDT and other OmniLayer tokens. Unless you mean something different than what I'm thinking by immutable.
Currently, the availability of microservices and a community help hive as a first layer but is it enough to justify the existence of a currency long term? Why not bring hivemind somewhere else with fast transactions and no fees?
Should each Dapp run its own servers, or should node providers be rewarded proportionally to the amount of RAM/memory/computational power they provide? Currently, node providers rely on the price of HIVE being high enough to pay off bills while the price mostly moves because of random speculation. Doesn't appease me.
How can eyeballs be monetized to benefit the blockchain itself and the price of the token? Not using the userbase is like sitting on a goldmine and doing nothing about it. Can the "burn to promote" feature on PeakD be incorporated in the blockchain code (or simply open-source code) so that all frontends automatically display it? Can this be then extended to SMTs similarly to how PALnet did to allow communities with their own currencies to thrive and have a sustainably appreciating currency based on the number of eyeballs they attract?
Where do RCs fit in all that? Since tps is limited and RCs are scarce, demand for RCs should push the price up. In that case, isn't there an incentive to build a blockchain that doesn't scale in order to make RCs even more scarce? Is that a problem?
In short, why moon?
We had a "promoted" in condenser a while back. It's already on chain (send some amount to null with permlink as memo). That could be extended to include either of null or Hive Fund and then featured on the frontend.
Thanks for going into detail about the benefits of a 2 layer system @blocktrades. These are all good reasons for secondary development on top of the Hive Blockchain.
From a non-technical point of view... in terms of engaged, active users having robust 1st layer systems supporting development on a 2nd layer makes complete sense to me.
Around specific projects theirs going to be plenty of active and engaged users with each project. As well there is a higher likelihood that developers building secondary layers will genuinely care about those respective communities.
To scale a meaningful social media network this is vital and will differentiate us from more centralized social media platforms.
We want to scale healthy communities around each project built upon a flexible robust Hive and this is likely the best way to go about that.
Lot of really great info in here, thank you for sharing. My question is, what is the best way to get developers to actually show up and build cool stuff here once we have the ideal and most attractive fabric in place? As you know, "if you build it, they will come" doesn't always hold true in the tech world...
Also, what do you think about implementing ads on the hive.blog front end and then using that ad revenue to purchase HIVE on the open markets, putting a little demand on the markets?
Other than that, thanks again for sharing your ideas on this. I had just recently been wondering what the roadmap for HIVE might be as well, so this was very nice timing! :)
I was already complaining a lot about traditional ads flying around.
It's risky (find a flaw, inject code in ad, deploy to all Hive holders as a service, harvest).
It's annoying (well, like most of the ads)
And it's not that common on the Internet these days.
The only case I know where attention is paid to classic ads is when my ad blocker does it to get rid of them ;-)
A way better approach is to show people that instead of paying for classic ads, they can brag about their products or services directly on the platform. They can engage with the community, gain influence; power up their HIVE. That could be mutually beneficial.
IMHO few bucks from some random scammers being able to advertise their scheme on the Hive frontends isn't worth it.
Applying more visibility to those who set @null / @hive.fund as a beneficiary is a far better approach.
Those are all excellent points against monetizing ads, I think.
I agree that just having the best tech isn't always enough, but it's an important first step when trying to attract developers. Unlike investors, it's hard to lure developers with promises of future functionality, they usually want something they can use now.
We'll definitely have to market our platform too, and there's many ways we can do that: publish white papers, press releases, post about the benefits on developer sites, and directly approach promising projects. Anyone on Hive can contribute to our marketing efforts in some of these different ways.
But perhaps the simplest thing is to enable our existing dev base. We actually have many developers on Hive now, so I'm focusing my own team's efforts towards easing the development process for those devs.
Regarding the "ads on hive.blog" idea, it's a theoretically attractive idea, but I don't think it makes sense to pursue it now. We already have a good idea how much revenue it will likely generate, as Steemit already tried it, and when I weighed that revenue stream versus the opportunity costs of developing and maintaining an ad platform on hive.blog, I decided that the opportunity cost was too high right now. But if there's another team that wants to take up the task and is willing to do any wheeling-and-dealing to find and keep advertisers, I wouldn't be opposed to hosting the ads on a trial basis.
Extremely well written and presented at the layman level.
The best part is addressing the benefits and not the features, looks like the beginning of a repeatable story about the value of Hive and what it is and who it is geared towards.
Exciting.
Thanks! I tried as much as I could to keep technical details to a bare minimum in this post, so that I could keep the focus on the benefits of a 2nd layer apps approach at the highest level possible.
My next post, which will go deeper into a technical examination of why 2nd level apps are just as decentralized (and therefore trustless) as smart contracts, will probably be more of a nerdfest, however :-)
Sometimes you have to.
Really Great! So, we look forward to the next answer.
Hive needs more dapps
A huge hug 🤗 and a little bit of !BEER 🍻 from @amico!
Un caro abbraccio 🤗 e un po' di BEER 🍻 da @amico!
View or trade
BEER.Hey @blocktrades, here is a little bit of
BEERfrom @amico for you. Enjoy it!Learn how to earn FREE BEER each day by staking your
BEER.Great idea bro.
blockchains are here to stay. Hive is simply my favorite of all and I love the idea that they continue to expand their functionality.
When I discovered Hive, it made me more interested in this world and in updating my knowledge of new technologies.
So I have a question: what is the most practical programming language to create a second layer application according to @blocktrades?
2nd layer application design isn't greatly different from design of a regular application, so there's no special language recommendation for it. The best choice will generally depend on two factors: which languages your devs know well and what's the nature of your application. For many common applications, you'll want to choose a language that has many libraries that can provide pre-written functionality for your application. For small applications, a rapid-prototyping language like Python is a good choice. But for large and complex applications, with many developers, you may want to consider a strongly typed language such as C++, especially if computational performance is paramount. And as I mentioned in the post, the best solution may be to use multiple languages, where your application's functionality is divided across several micro services.
Thanks for the reply! Knowing that will help me in my future projects and in my career.❤
Jeez I thought it was JavaScript
Congratulations @blocktrades! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
You can view your badges on your board And compare to others on the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPTo support your work, I also upvoted your post!
Do not miss the last post from @hivebuzz:
Hive is my favorite blockchain it's a good idea to keep growing in this world of technology, good information
Very meaningful idea congratulations
Interesting stuff. I still struggle to get my head round all this stuff despite being a developer for other types of apps. I think I need get more into blockchain stuff and see what value I can add to Hive.
Es complejo el tema.
El boom de HIVE está basado, en mi opinión, en lo que representa como plataforma social.
Quienes nos dedicamos a escribir y publicar, disfrutamos mucho el poder hacerlo.
Si la evolución que Ud. plantea, permite que siga desarrollando la plataforma social, a la par del enfoque desarrollador de nuevas aplicaiones, me parece una propuesta excelente.
Ud ha demostrado ser conocedor del tema y un defensor de la vida de HIVE.
Es seguro que sus propuestas llevan el objetivo de mejorar. Adelante.
aliriera
The improvements I'm suggesting definitely have no negative impact on the existing social media application.
Actually I think it will have a very positive impact on it, since it will allow the social media users to interact in new ways beyond what traditional social media tends to offer.
Excelente.
Siga adelante.
Me Impresiona ver la cantidad y calidad de interacciones que ha logrado con su propuesta.
aliriera
This was a great read Dan, thank you. I am one of the people who fall into the latter category of this being familiar, but having the explanations and examples clarified it a lot for me.
The microservices are indeed going to be vital in the upcoming growth of the platform and it is exciting to see what will arrive to support the developers.
Thanks again and I will push this out to Twitter also.
First thank very much for this education in the nuts and bolts of how all this come together. Often when people really know their stuff it is difficult to communicate it simple people like me. But I now feel I have a better understanding on why laying all the good foundations for Hive are so important before we move on to the bells and whistles which seem more important to the normal user.
It really feels that Hive in it's current iteration is like a motorway being built before the cities have been thought of. And like in that film, 'If you build it, they will come'
In Hive's case, I think many devs are here already, but they could use some assistance in building their apps on our network.
Very exciting times ahead!
HIVE.D!!
THAT'S WHAT I'VE BEEN SAYIN ALL ALONG!
THANK YOU!
This was a really informative post, and your breakdown made it accessible for the non-techie folk. Looking forward to that part two post.
A great read, even if a good bit of it went over my head. 😅
One minor nitpick:
Should this instead be …their own 2nd layer…?
Yes, you're right, I meant "own", not "only".
When I started studying Mandarin a few years ago, I think my brain got rewired to process words more by sound than spelling. Previously, words had a strong visual association, rather than a sound association for me, maybe because I used to read a lot.
But now, words seems to be tied more to the auditory processing section of my brain, and I often find myself writing a word that sounds something like the word I mean to write. I used to take a lot of pride in my ability to write with relatively few mistakes, so I find it annoying how often I make such mistakes now. When I instant message now, I often find myself making mistakes like that every couple of sentences.
Anyways, I appreciate the heads-up, and I've fixed it now!
switching ideas between languages seems to be more difficult than moving tokens between blockchains? lol.
中文是很靈活多變的，但也因此有不夠嚴謹的缺點。^_^
Moving tokens between blockchains is easy. Moving them trustlessly is very hard. I guess switching ideas between languages is probably easier than either, based on the number of competent translators out there, but in my own case, I'm pretty sure moving tokens is easier...
As far as Mandarin goes, I think it's structurally much more logical than English, but I think the lack of a truly phonetic alphabet makes it difficult to learn the written language. But I'm by no means fluent enough to even begin to comment on how good it is at expressing new concepts with clarity.
I do love the infinite shades of meaning that can be expressed with various word choices in English (because of the sheer number of English words), but that's more of an art consideration than a practical one. It makes for good literature, but it probably makes English harder to learn. There's probably an analog there to Mandarin, where the Chinese appreciate the artistic beauty of handwritten characters, and non-native speakers fear them.
I mentioned some of this in our discussion but will relay here for others reading:
TDTL: I am only concerned about all solutions being enterprise level.
There's a few conflicting points here but these are generally my thoughts.
:thinking emoji:
I Kike this, wow
The biggest problem right now limiting Hive from being a more widely used and accepted place to build dApps is lack of smart contracts. As many of us know, you can build some great applications on Hive and it's so easy to build them as well. However, for some use-cases, it would be nice if developers could publish smart contracts without the need to run their own API's and manage resource credits.
And I think one of the biggest differentiators that could make Hive standout is allowing contracts to be written using Javascript. The software behind Hive Engine supports writing contracts using Javascript, but it only works for the main Hive Engine node itself, which means you cannot do transfers or anything involving token balances.
We already have the developer ease-of-use, let's reduce the barrier to entry even more. Every other major blockchain has smart contracts, but they're all custom languages like Solidity which don't necessarily map 1:1 to developers who already know languages like Javascript.
I mostly disagree, as I see little need for smart contracts as opposed to 2nd layer apps for this. However, there are some advantages for smart contracts, and I'll discuss those in my next post on this subject.
I see your point about smart contracts not requiring that there be additional API servers to support the 2nd level apps, but I see this as doing no one any real favors.
This forces 1st layer nodes to support apps that they shouldn't be forced to support and it forces those apps to be supported in a less secure and less performant way. It also destroys scalability, since all the apps have to fit into a "one size fits all" node architecture. And don't even get me started on the increased difficulties of paralellizing the workload of the smart contracts.
And it's not like the smart contract developers really get a free ride either: the blockchain has to somehow pass on those extra costs to the smart contract's developor or users, or else the whole platform will just be taken down when smart contracts abuse those scarce resources. While the smart contractor developer doesn't necessarily pay those costs (depending on the smart contract platform), their users do, and this can have real impacts on the adoption rate for the developer's smart contract.
I am not a techie guy and I have no idea on majority of what you're saying but what I wanted most is that when you say that you wanted Hive to be the most attractive platform.
these new and contemporary ideas are positive for the hive platform, users have to propose integration projects with applications that are in the current technological line, that will give hive more positive momentum
After reading this post i learned lots of thing about our hive. Now it will be helpful for me when i will tell about hive to someone else face2face.
I would like to imagine the HIVE blockchain as a type of port of call and where Dapps facilitate decentralized transactions. The network serves as a reliable foundation and Dapps make the ecosystem shine.
That's a very apt description.
Testing
really a very useful science and a very good presentation
Wow! Educational! You are a real crypto enthusiast and investor businessman! I have no question for all that you said... I can't reach your knowledge! I'm in your 1% only or maybe less. I'm just a user who wants to learn and to earn and to help others. I admire you @blocktrades from STEEMIT to HIVE! (^_^)
that's a whopping post with a load of information to digest. I'm piqued though.
True and this makes Hive more flexible then most other Block chains.
A great read to see what is really going on, but, found much of it in unfamiliar territory. Time to brush up on my
MandarinBlockchain knowledge.Thanks!!!
!tip
🎁 Hi @blocktrades! You have received 0.1 HIVE tip from @dswigle!
Check out @dswigle blog here and follow if you like the content :)
Sending tips with @tipU - how to guide.
I think this is the right decision.
Instead of the main development Hive team developing SMTs here (we now know that there is still a long way to go in relation to Steem), it's better to prepare the best conditions for dApps developers who can operate and build apps independently of the basic Hive core.
Hay muchos aspectos positivos en esta publicación, los mismos cambian la perspectiva de la blockchain HIVE. Hay que tomar con pinzas esta data porque tiene material muy importante para el navegador y lector de Hive. Gracias por compartir.
This is great. This is something I feel like I an share to many of my non-blockchain friends who do understand he basic ideas around development. I was recently trying to convince a friend who wants to develop an app for tracking sports stats to share data with users, and gameify, and monetize, to look at Hive. I think this explains some of the benefits he needs to know to help him see Hive's potential! Thanks for this!
It's good to hear that we have people promoting Hive as a development platform, thanks for that!
@warriorpaducah, take a look here.
Indeed Hive is the social media of our future. Hive is the best social media platform. I learnt lot of things from this article. You described your point very well. I think you are right actually.
#hiveon
Cheers!
Greetings @blocktrades, this information you are giving us is very interesting, since many of these platforms only remain as social networks and do not admit other options. You propose Hive as a blockchain network that attracts developers and thus an expansion of the platform, I am not an expert on the subject, but I am interested in being aware of what is happening on the platform.
Hola @blocktrades… He elegido tu post para mi iniciativa diaria de reblogear. Este es mi aporte para Hive…
Sigamos trabajando y aportando ideas para crecer en Hive!...
Hello @blocktrades... I have chosen your post for my daily reblogging initiative. This is my contribution to Hive...
Let's keep working and giving ideas to grow in Hive!
No wonder why you become who you are right now because you seem to know everything. Thank you for this explanation and more power!