I have been thinking and working on this for a while. I want to share it with you and get some feedback.
All the things I talk about here are not definite. They can change based on the feedback.
Second-layer or side chain
A side chain has its own rules and block production like the base blockchain. The owners or maintainers of the side chain have the power to stop you from accessing the network.
A second layer network on the other hand only relies on the main chain. Its rules are the rules of the main blockchain. Just like the hivemind. You can run your own hivemind and have access to its data.
This is my understanding of how both work. Some people or some apps use these two terms in place of each other. But I don't agree with that because there are huge differences between the two.
Which one to choose
The easier option is probably the second-layer network. It can be as decentralized as the main blockchain. And doesn't require the complexity of having another chain.
You don't need to connect to the other nodes of this network to sync or update your data. You just rely on the main blockchain.
But there are limitations here. You can't manipulate it like a side chain so easily. I think this is a fair price to pay.
So I decided to make it a second-layer network.
How it works
We have the main token for our second layer network. We call this TOKEN for now.
- TOKEN is used for paying the fee of the transactions on the second layer.
- TOKEN can be staked to generate more TOKEN.
- TOKEN is being generated by staking HIVE i.e. powering up (not so sure about this one).
- TOKEN makes it possible to have an internal exchange for the possible SMTs.
These are some ideas that I could think of. There are some things that need addressing in regards to these ideas. Like where the fees should go? We can burn the fees or send them to a DAO for future developments. But burning seems a better idea considering the constant printing of the TOKEN by holding HP.
The purpose of the fee is to stop bad actors. We have RC on the main blockchain but that wouldn't help in the second layer network because the main chain has no idea about the second layer usage.
The generation of TOKEN is also something important to discuss. We know there are some big stakeholders on HIVE. I'm not sure how we can make it a more fair distribution along with making use of the HIVE coin. Maybe we can print it only to the TOKEN holders and skip the HP holders. This is not decided yet.
Governance
I want to make this network like the hivemind. So there is no need for block producers or anything like that. However, there might be a need for a set of witnesses to decide the fate of the network. I'm still not sure about this idea.
Smart contracts or SMTs
My first idea was to run an ETH VM in the second layer to have support for smart contracts. But I think that makes it too complicated and opens up room for more bugs.
But, we can make SMTs in this layer. Tokens with as much customization as possible. Making it possible to create complex social media tokens or just simple ERC20 tokens.
I know having a working network with support for smart contracts is necessary for having more apps. So maybe we can work on that later.
Development plan
My personal idea is to work in this order:
- Make the main token and its necessary functions
- Prepare the necessary interfaces to interact with the network like a web wallet and a block explorer
- Make a browser extension wallet in the quality of MetaMask
- Make the token creation system for simple tokens
- Implement more complex social media tokens in a way to at least be capable of handling the main social aspects of the HIVE token
- Explore the possible idea of smart contracts
Development language
I like to make it possible with the help of TypeScript. It's JavaScript with types. An easier language to work with but also powerful enough.
This makes it possible for a wider range of developers within the Hive community to make contributions.
TypeScript along with MySQL or maybe PostgreSQL for the backend storage. I have experience working with MySQL and it's fast enough but I'm not sure about its powers in handling a much larger amount of data. That's why I'm open to the idea of PostgreSQL just like the hivemind.
Why
This is not by any means a full explanation of a complex network. This is just me throwing around my ideas to get feedback from you.
I'm not sure if there are already some networks like this in the work or if anyone has anything planned to make. That is why I'm sharing this right now.
I have done some developments and the main token seems to be working. But I'm not so sure about continuing my work. Is there really a need for this? How can we make it better? Or just give this up and work on something else?
We might be late in this area but I'm sure everything is possible.
My idea was to make it as decentralized as possible and have a fair launch. I don't want to create another steemit inc. that can take over this second layer network. There are some concerns about this too. Like how to make it sustainable and beneficial to the main blockchain at the same time?
I'm not going to make it more complicated than this for now. We can discuss more things if we ever decided to go forward.
Please share your ideas in the comments.
Thanks for your time.
Hi mahdi.im from iran.a photographer and director.nice to meet you.
;)
This sounds like the first thoughts into the (dlux_open_token)[https://github.com/dluxio/dlux_open_token] architecture. If you want to help us generalize the token architecture further as we turn it into "honeycomb" we'd welcome your support.
There are several things you're likely to run into with your current roadmap. One is the databases you mention don't have transnational handlers so you'll likely need to make some custom handlers to ensure order. You might find a p2p layer is overly complicated and unnecessary unless you want to allow transactions that aren't signed/ordered on hive. You'll need to build an exchange because there is no substitute 0x or swap protocols on Hive.
As far as the why and how will this benefit Hive: Having smart contracts in Hive/HBD denominations is a major boon to our ecosystem. With our decentralized wallet those things are possible, and well as a DEX.
This is a little beyond my understanding, but sounds interesting. Would this be similar to hive-engine?
My 2cents? Leave eth out of it. Find another option... All erc20 tokens are worthless.
Witnesses? The representative republic type set-up here is what hinders decentralizing the platform. This is a huge bottleneck and we need to widen it. If the blockchain is perfect for voting, let's use it to do so...
.
I have to think about this to really answer with the depth of feedback that this idea requires, but for now as its 1am on New Years: I agree that a layer vs side chain is the way to go. A side chain is more centralized and requires more oversight efforts in order to ensure its quality (of its infrastructure) is up to acceptable standards. It requires a lot of coordination if attempts to decentralize are made. A layer is by default expected to take on the quality of the core protocol, meaning its infrastructure is expected to be of due quality and no extra running around is needed. I don't know about Typescript. That wouldn't have been my choice. I also don't agree in regards to the priority of work. I would have had all the backend work, testing and functionality completed first and then have worried about interacting through frontend tools.
I think this is a good thing to sketch out on Visio. Just thinking, I'm wondering if HIVE stakeholders will have any incentive to also hold large sums of the token if said token will be generated by their HIVE. Meaning, they'd hold it through generating it but not through investment in it directly (they're already invested in HIVE). It would kind of play out like the account credits where they become stacked and used as needed but not optimally distributed to maximum utility. I have to think about this some more in order to do this idea justice.