You are viewing a single comment's thread from:

RE: Hive’s future as a 2nd layer blockchain network

in #hive4 years ago (edited)

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 :-)

Sort:  

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.