Decentralization of Wrapped Hive [discussion]

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.

logo_fbslo2.png

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.

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

H2
H3
H4
3 columns
2 columns
1 column
20 Comments
Ecency