Hive’s future as a 2nd layer blockchain network

in #hive2 years ago (edited)

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:

  1. Publicly available rules for the cryptocurrency, that aren’t controlled by a single entity.
  2. 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

  1. 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.

  2. 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 and Splinterlands. Whenever you “follow” a user on 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,, 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

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:

  • Theoretically speaking, if some form of standards for specifying a 2-layer framework can be widely accepted, then projects can compete for 1st layer solutions that those 2nd layer apps can migrate to another chain without too much cost. Then a more efficient system can be built.
  • If this 2-layer Hive structure wishes to thrive, then the 1st layer's decentralization properties will be scrutinized - my immature impression is that there is still much room for improvement for Hive governance like increasing the number of top witnesses, decreasing witness votes and etc.
  • Again, if this 2-layer Hive structure wishes to thrive, my opinion is that the 1st layer should not handle the 'content & post-voting" and eventually should move it to a 2nd layer (maybe a special 2nd layer). But it really sounds like a SMT and I am not sure how SMT (if this is still on the roadmap) fit into this 2-layer framework.

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 & 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.

I came to you from ...
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:
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

This isn't a hard task, it's already done on For example, you can check your voting strength with . But it would be much nicer to directly show it on directly, so we'll do that.

Thank you very much for the information! I'll watch there for now!

2nd-layer apps where the additional functionality runs outside the core blockchain process.

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.

What would you suggest that Hive Engine change to be run in a more decentralized manner?

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 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 / 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" 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, 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.


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!

Hey @blocktrades, here is a little bit of BEER from @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 received more than 75000 upvotes. Your next target is to reach 80000 upvotes.

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 STOP

To support your work, I also upvoted your post!

Do not miss the last post from @hivebuzz:

Introducing the HiveBuzz API for applications and websites

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.

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.

Siga adelante.
Me Impresiona ver la cantidad y calidad de interacciones que ha logrado con su propuesta.

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!





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:

Anyone can write their only 2nd layer Hive application…

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.

  1. The second layer solution is an excellent approach and would add versatility without adding bloat to the blockchain. On the other hand, it may not inspire as much confidence with external investors as an on-chain solution would.
  2. The second layer solution must be enterprise level from the start. It cannot be a Hivemind which has various format issues and was for some reason unknow to me written in Python (and now requires optimization). The new layer should be written in C++ for ultimate scaling and if it is written in Python it must be structured in a professional and scalable manner. Everything we do going forward must be aimed at being accepted as enterprise level and not be reminiscent of some half-baked startup. We are building Hive to last the test of time.
  3. We do need a flexible approach to smart contracts, NFTs and FTs. We're not married to the "SMTs" and we don't need to be. We're all aware that Steemit Inc was ran in a way that stifled the creativity and capability of the development team. We have use cases for all of the above. Smart contracts: structured payment systems. NFTs: collectibles. FTs: community tokens.
  4. A layered approach in general makes for a friendlier ecosystem towards development and onboarding of partially completed or unstarted projects. It allows for a phased set of milestones among the developers; ie. incorporate with select on-chain functions, then separate a side function to let's say create and utilize a token, then separate another server for a Hivemind node if needed. Your reference to Arcange's microservice is spot on.

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.

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 Mandarin Blockchain knowledge.



🎁 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!

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.

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!

Nice information 👍

You guys are doing great overall, thanks.

My issue is with attracting new authors.
Does the payout on this post better serve the chain by paying you, or could that 280htu be better spent allowing 2800 accounts come closer to getting .1htu in payout?

Fully 1.5 million people have come here and left because of this issue.
Would you like to give some feedback on that?

First, as much as I would like to think otherwise, I don't think 1.5 million people have come here and left. It's hard to know just how many accounts have been created by the same people (some for legitimate reasons and some not), but I'm sure the figure is quite large.

Second, you've made what I believe is an unwarranted assumption:

have come here and left because of this issue.

I'm quite certain that it is not simply rewards that cause people to come and go, because I did experiments on this issue several years ago.

I invited several friends to the platform, and while some have stayed, several have not, despite being rewarded pretty well, as I was more than happy to vote up some of their posts to see what impact it had on retention rate.

What I found was that the rewards just didn't matter much to them. The ones that stayed, stayed because they found something appealing about the philosophy of the site. The ones that left, generally left because their friends weren't here, so they returned to sites where they could easily share their posts with their friends. This network effect is the primary strength of sites like facebook, which is where my friends usually posted before, and where they returned.

I'm not saying the social media component of Hive isn't important: I think it's very important. And I think the posting rewards system is a great way to create a useful faucet for spreading the currency to new users.

But, I think it's very easy to overestimate its power, which is surprising to me, since given how much currency actually has been distributed over time via Hive and previously via Steem, it should be obvious that the rewards aren't enough.

Without the data I collected via my experiments, I can see how you could have assumed it was some "unfair distribution" of the rewards that was primarily responsible for people leaving the platform, because they felt insufficiently rewarded. I've seen that argument before elsewhere. But this theory was directly contradicted by the results of my experiments, so much so that even my "over-rewarded" friends didn't stay. As a side note, I did this experiment with people of various economic levels in the US, with the "richest" being a doctor.


How can I get in touch with you guys?

If it's related to Hive development, either Hive's slack, mattermost, or discord services. If it's about Blocktrades the business, then [email protected]

It is more a business request related to Graphene development.

My only different view point is about the custom_json. IMHO, we should not use the feature so much. Rather, we should be keeping it elsewhere or just on few nodes with special storage. A minimal hash needs to be on the chain. With applications storing more and more JSON we are increasing the chain size.

I don't think on-disk chain size is likely to become a serious issue in the near term, as disk storage is one of our cheapest resources. It also impacts network bandwidth too, of course, but again, I don't see these as the most critical resources. Relatively speaking, I think cpu and memory usage are the big things to worry about now.

At the same time, I do like to optimize things where possible, and I have been considering a new custom_binary operation, as an alternative for apps that want to lower the RC requirements for their users. But this might already be implementable via the current extensions feature, even. I haven't had time to discuss it yet with the other devs here.

IIRC custom_binary operations already exist, though not really used.

Could I translate this post into my mother language, Bahasa Indonesia? It is better for me to read carefully through translation activity also spread it through my post.

Thank you!

this is good concept on dapps and blockchain.
its have 2nd layer of a platform of security itself and decentralization to per transaction and scalability,
which the technology keeps us moving to become more active in blockchain apps and dapps.

My issue with layer 2 systems is that there generally doesn't seem to be a clear consensus or schelling point/mechanism for how to proceed when there is a breakdown in consensus.

In Bitcoin and most PoW crypto networks the 'longest PoW' is a widely agreed upon metric for what gets to be called 'Bitcoin' and what needs to find its own brand after a split. In Steem, DPoS, there are voting mechanism which decide what is the 'valid' continuity when there is a split. Even when Hive was more popular than the "original" Steem, the chain which the top witnesses decided to continue with, still got to continue as "Steem".

On the other hand with Layer 2 systems, we don't have clear mechanisms for what is valid when the rules need to change or there is a major split in the community. You used Omni as an example, in November 2017 Omni released a 'mandatory fork'. There was no consensus mechanism, all users had to change their software or it would not be valid for Tether. They had the power to do this because if Tether only respects a particular version, then everyone else doesn't really have an option (they will not redeem tokens on other versions). Other 2nd layer systems have similar dynamics - if an online card game changes the software that decides which card tokens are valid, most likely you will have no option but to go along with their change. Even if the change is unpopular, there is no clear way to determine what is the 'valid' continuity beyond "it's this version because we say it is".

Layer 2 systems could establish some set of rules ahead of time for deciding valid continuity, but I have not seen clear examples of this being done and followed through with, and establishing consensus is not really a core part of layer 2 projects in general, layer 1 projects tend to have such by default.

I recognize that this doesn't decide what is valid or more valuable, people and particularly exchanges do. But it does help people quickly decide valid continuity without defaulting to the developers having special authority each time.

There's two separate forms of consensus in blockchains: 1) consensus about the order in which transactions have occurred and 2) condensus about what rules are valid for the blockchain. But only the first of these forms of consensus needs to be enforced by code. 2nd layer systems rely on the 1st layer to enforce transaction ordering consensus, but they make it simpler and less contentious to fork in the case of disagreement about the rules.

Perhaps you're arguing that there should be more work involved and that the code should try to choose a winner and loser in such discussions by adding extra pressure to the majority side in such disagreements. If so, I disagree with that. I think minority groups should be able to easily select an alternative set of rules if they don't like the rules that the majority is going with. In the end, there's literally little difference though: if a minority doesn't agree with the majority, they can just fork the coin. This happens all the time.

And it doesn't require skilled devs to do so: you can hire super cheap devs who are capable of forking coins. There was actually a program you could download at one point to generate your own "shit coins" based off bitcoin.

I think your tether argument is flawed, because it misses the key detail about tether: Tether is not really a decentralized coin in most senses of the word, because it's value comes from fiat backing, and a central entity,, controls that backing. So there's no way to fork tether, unless you're willing to also assume a huge debt to do so.

In case my point in the last paragraph wasn't clear, the problems you mention are problems with centralized backing. They have nothing to do with 1st layer blockchains, 2nd layer applications, or smart contracts. The same centralization problem that prevents forking exists for tether coins stored on 1st layer blockchains such as Ethereum.

On the contrary I think it should be as easy as possible to fork, and for such forks to be as non-disruptive as possible in the case of a contentious change. When there is a split, not only do individuals need to decide what they see as valid or more worthwhile going forward, but exchanges and ecosystem infrastructure need to decide what gets to be considered to be the same token, with the same brand.

In a truly contentious fork, eg. if Bitcoin XT, Bitcoin Classic or Bitcoin Segwit2x had forked as originally planned, both camps may be claiming to be the 'true' Bitcoin at the time of fork, rather than ceding with a fork rebrand as in Bitcoin Cash or Hive. In this case the ecosystem of exchanges etc. need to make a decision fairly quickly as to which network gets to be 'Bitcoin'. Regardless of which side of the debate they actually lie on - exchanges need to go along with everyone else, or we end up with a situation where Binance is selling tokens on one chain as "Bitcoin" and Kraken is selling "Bitcoin" on another. Formalizing the consensus rules as happens in layer 1 allows for easy schelling points upon which people can make these decisions, generally avoiding the undesirable situation.

Layer 2 applications could formalize rules to decide what is 'valid' in the event where a change to the rules is necessary, but they generally don't. In the absence of it, the default is for the developers (or even just the person who owns the website or code repository) to be the deciders, which gives them special control and authority on the network. That is what makes me uncomfortable with layer 2 applications. While I can decide if I like the rules of a layer 2 system as is, I have no way of knowing what the rules will be in a year, and no way to be confident that there is a way for the community to come to consensus on it.

I agree that Tether is centralized but I disagree that it doesn't show the point. It wasn't just Tether that forked, it was the entire Omni protocol. At the time of the fork there were over 300 different asset definitions on Omni and they ALL had to fork to the new version. Tether simply had so much weight that it forced the issue for everyone. In the absence of any other way to make the decision, everyone had to go along with the developers choice of what was now the valid rules for Omni, which included the possibility of tokens being frozen by asset definers.

I have yet to see a layer 2 system where the developers don't have the weight/clout to change the rules on their own, where their application is used so much that it will be the default accepted by exchanges in every change that happens, regardless of what the community wants. I'm not saying it's unsolvable, but it's how L2 systems typically are today and there's no pressure for that to change.

Very very comprehensive post on Dapp. I had no idea about first layer and second layer of transaction in blocks before. It's really a learning post for me. Thanks @blocktrades for explaining such a simple way all the critical things.

My Vision for Hive:

Downvotes for Selfvotes like yours. You do not see, what you do with it!

A lot of Bla Bla about features, but no understand about the ground prinziples of sozial media with a reward system.

Think about it.

I've literally spent years thinking about ground principles of social media with a reward system. And observing how it works in practice on Steem, Hive, and other sites. I've yet to see a system that pleases everyone.

I do have some ideas for how to create such a system, but that's the answer to the vision question that I said I don't want to address in this post, because it's a long and involved answer, and the whole system is purely in the conceptual stage.

But to address your immediate complaint, I can say with certainty that removing self votes isn't some simple way to "fix Hive". There's no possible mechanism where people can't simply create multiple accounts, then vote for themselves by voting from their large staked account to their small account(s). This used to happen all the time, as some people wanted to hide their self-voting. I suppose it still goes on today, as well.

So unless you're proposing that people should just resort to such hiding of self votes, and believe that somehow helps the platform, I think this is not a useful discussion.

This current post is about other uses of the platform, beyond it's social media roots, but leveraging that core strength. I think this is the best way to grow this platform and it is a much better strategy than just tinkering with the social media rules. I'm not saying we should simply stop the tinkering altogether, but I don't think we should place all our hopes for the platform's success on this one area.

You and me, we both get in a system like this. Code gives a lot of potential actings with it. It is the acting with it, who is the law, not the code itself.

No code or system will be "perfect". So you as a big stakeholder and me too, as a little one, get the potential for a "good" looking forward using of the system we wrote and be in.

You are way to much deep in the rabbit hole for me, most peoples in the world can not understand you, if the would. THIS people, mass adapting things, mostly trash, but they do.

If we do not get hope, for using this system (Hive), rather knowledge about sozial interacting and all the "little" things round about, it looks like to be easy as hell to make this baby big.

A new user mostly here for the greed, see you first, becouse you have a big wallet and so your post are in the toppics first. If they see your selfvote, some of the real good people, we look for though sure: What a greedy stupid actor.

I was and be one of these people. I worked based on all your acting mistakes here on the chain. And let us see, who goes longer or better in the geminification game of live. It is everybodys acting who let things grow or die.

Nice to get a answer from the untuchables.

See you

Bookmarking this for future reference. QUite pregnant with information that you can hardly get anywhere on the web. Thanks for sharing this with us.

Amazing information! :)

Looking forward for your next technical post to understand how the smart contracts can be coded and deployed on hive second layer. I am more interested to see how defi smart contract like maker, compound, balance, instadapp, aave can be developed here.

As an unavoidable part-timer, I am only now getting to reading this post @blocktrades. Given how extensive an effort has to have gone in to the writing of it, I first want to say how much I appreciate it. One might imagine your questioning the value of making this effort, as how many will either take the time to read it or, if they do, understand what you have to say?

As a +2-year "veteran," I think I can recall reading about the promise of SMTs from almost day one. We have yet to realize the long-awaited promise of what they might represent, for the benefit of us all. For me, this post gives me a much better understanding of why the "gap" between the reality and the promise of SMTs is likely to be much smaller than feared.

Now ... How to get the benefits you cite, of basing future apps on the foundation of the Hive blockchain, into the hands of the global network of developers feverishly working on "the next big thing?" 😉

Fully supported and reblogged. Looking forward to more great content like this!

I am new in Hive blog. Can you explain how to earn money in hive???
please explain the process. Another one doubt bro, how will increase HP???
Please reply my comment. How much salary can be bought in this. How do we transfer that amount to the account?

Unless you're an exceptionally good writer, I wouldn't expect to make a living by posting on Hive. Most Hivers are here for reasons other than just making money.

I like the 2nd-layer concept to build all sorts of DApps on top of Hive, makes absolutely sense, has interesting trade-offs and advantages over "smart contract" platforms. Looking forward to the first vision update about computationally-enhanced information sharing on Hive :)

Good day @blocktrades, pls I'm wondering why you downvoted my last post. I want to know where i got it wrong, or if its a mistake, can you correct that?

I believe I've have been using block trades to do all exchanges. I don't deserve this please.

I have a bot setup that counters some of ranchorelaxo's randomized upvote, so that rewards are distributed more evenly among all posters. It's nothing personal about your post.

Okay...I get it now.

Thank you for the very clear explanation.

@blocktrades, thanks for the encouragement here on hive community. I'm so glad to be back and be part of this great cool progressing cryptocurrency platform. Im following you too already.

  • Cheers
happy New Month ❣️💞

I shared your wonderful work and your thoughts! Really important thoughts and this post should be seen by as many platform users as possible !

Very informative post, still not fully sure if a 2nd layer solutions is what I need for the project I have in mind instead of a smart contact but etiehr way want to look into learning more about programming a service on the 2nd layer.