Some of you might know I'm working on a new project called Wrapped Hive that will allow anyone to "wrap" HIVE coins for WHIVE on Ethereum.
Thanks to @doze for this amazing logo.
The current way how the app operates is by having central authority responsible for storing HIVE and minting new WHIVE. While this is a simple & effective approach, there is a problem: Trust. A person who controls the central accounts can exit scam, be hacked, servers can be hacked, the owner can be forced to give away the user's funds ($5 wrench attack)... Not to mention it's not in the spirit of Hive to be centralized!
To solve this problem, my idea is to use a multy-authority Hive account and multi-signature Ethereum smart contract. Since there is a limit on how many accounts can be added to the multi-authority account (40) it's not completely decentralized, but having to collect 20 signatures is still much better than one.
Don't worry if you don't understand everything in the next part.
How could this app work?
The main objective is not keeping wrapping service running at all times, but to protect user's funds.
This is why I think most of the operations should still be processed by a "master" node that would monitor Ethereum & Hive in real-time and process any conversion requests. But to actually transfer any funds, "master" would need to send a request to the validator nodes that would need to sign every transaction.
I think using a master node and validators instead of a just network of nodes would be better (at least for now) since nodes must work together to sign transactions, and trying to have a fully decentralized sidechain would take quite a lot of work, but I would like to have decentralized WHIVE oracle ready in 2-4 weeks.
Even is the master node is compromised, other validators could just decide to "follow" new one (code will be opensource). Due to the small size of the network, I think it would be best that validator nodes are operated by community "leaders": top witnesses, whales, etc...
Example of converting HIVE to WHIVE: User sends 1000 HIVE to @wrapped-hive. The master node is scanning the chain and detects this transfer. After it makes sure that the memo is valid Ethereum address, it creates an Ethereum transaction and sends it to the first validator together with Hive tx hash. Validator than uses the tx hash to verify the transaction happened, signs the Ethereum transaction, and sends it back. After 50% of validators signed the transaction, it's broadcasted by the master node, and new WHIVE is minted.
Example of converting WHIVE to HIVE: To withdraw funds from WHIVE, users would need to register their Ethereum address (maybe by sending 0.001 HIVE to a central account, or by custom_json). The master node would then store this information (together with tx hash from Hive transaction) into some database.
When WHIVE transfer to either 0x0000... or custom smart contract is detected, the master node will check is an address that sent the WHIVE is registered, and if it is, it would create new Hive transaction and send it to validators (together with tx hash from registration), so validators could check if the registered address matches. If everything is ok, a validator would sign the transaction and send it back to the master node. After 50% of validators signed the transaction, it's broadcasted by the master node, and HIVE is transferred to the user.
It should be validation, not verification
If you have any ideas please leave a comment. I'm trying to start a public discussion about the centralization issue with wrapped assets and possible solutions.
Yep, in my opinion you're exactly on the right track with this one - currently there's no other way to decentralize a hive service like this.
The cool part is that this method can also be used for other defi services on hive :)
@fbslo ... spot on ! looking forward on this happening
Hey man that is not my field, so I will be honest I don't understand everything your wrote, but knowing you are cooking something, I am sure it will be good so here is little extra support from me...
@tipu curate
Thanks :)
Upvoted 👌 (Mana: 22/60)
I'm not 100% sure if I understand all the potential of this project (I'm almost a zero in crypto lol) but sounds me great! :)
Nice to see people working on this idea, great initiative.
Curious if you're familiar with REN VM? (I would guess that you are)
Most of this is way over my head but it might be useful to understand how it functions. It might provide an alternative to a wrapped version while also being a trustless solution.
This video may be relevant to the discussion and breaks down RENVM for laymen like myself.
Thanks :) I heard about REN in the past, but never got to learn more about it. It seems they currently support only BTC, BCH, and ZEC, but hopefully, they will add more tokens soon.
Congratulations @fbslo! 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
STOPDo not miss the last post from @hivebuzz:
Your specification makes sense. Using a set of validators makes it hard enough to steal any funds. What happens when the masternode goes offline? How does a backup masternode get chosen? There has to be a process to pick them. How about potential nodes registering themselves on Hive as candidates and the validator nodes voting on which one to follow?
Can it has more than one masternode or more than one with same role to make more balance network?
The use of Ethereum was expensive these days. Won't it be a problem?
What is whive, a new token? I don't understand it clearly what were you talking. What in mind is a new app with its own token, am I right?
It's ERC20 token on Ethereum network that would allow users to use HIVE on DeFi platforms.
a that's nice..
I think that any node on hive blockchain should have the potential to work as a master node. No specifically the witnesses, whale, or whoever.
But for work as master node should have a portion of HIVE stacked. So it opens an away for those that just want to support the blockchain with this function. It's open a way for those that want to invest in the HIVE blockchain specifically for that function. So If someone that wants to have HIVE blockchain master nodes could have it. And I guess that it makes more decentralized.
I agree. There is also an option discussed to include cross-chain swaps directly to core Hive witness nodes as a plugin, so Sidechain Operating Nodes (SON) would be voted like witnesses. It was done before on PeerPlays (which is also graphene based blockchain)
Yo my man, i think we should roll it out and then you can make a prop for your further development. Would be glad to cast a vote.
What is the drawback of having it running on multiple nodes, one for each validator?
All validators must work together in order to sign transactions, so having one central node that would collect signatures from validators would make development easier.