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