Wrapped Hive Update - Testnet ready

Wrapped Hive - Testnet

wHE-token.jpg
original image source


Hello, it's been some time since the last Wrapped Hive development update. I've been working hard behind the scenes, and now I have a few exciting news to share.

Private Testnet

On Friday, I announced the successful launch of the first private testnet

I had 3 validators running on this first testnet:

  • @gorbisan (0xaB8aDa86340b31c616Bf57007cfaF153F114e491)
  • @fbslo.pay (0x79fd2eC310457aE0137426526c05Fda2d3B02DAd)
  • @posh-bot (0x720Bc451363d5f9F5Cc03861760bff29A3a1083a)

Token contract: 0xedf8a74f4271c3ce1007e117187b102802c85a55
Multisig contract: 0xf072ee84895abeabbc4b47d2d713836c732883af

First transactions were sent from Hive to Ethereum and back. Here is a list of transactions required for the first trustless (well, all validators were controlled by me this time) cross-chain transfer.


HIVE to wHIVE.


wHIVE to HIVE

Wrapped Hive Network

tl;dr: Network of nodes must sign transactions and by using multi-signature wallets, tokens can be transferred only if a certain percentage of nodes approved it.

Governance

I spent a lot of time thinking about the governance issue for Wrapped Hive. There are a few different ways to elect validators into the network. The most popular governance models in crypto are PoW (not really suitable for this project), PoS, and DPoS.
I was thinking about using a similar way of voting for validators as Hive is using to vote for witnesses. But using Hive stake is not a very good way, since not every hive whale is doing what's best for the project, and in the case of attack, we can't just fork, since this is not a separate blockchain.

For now, I have decided to use a similar system as XRP or Diem/Libra: A limited number of trusted validators (like top witnesses, known community members...). While new validators can be added to the network, they have to be added and approved manually by the entire network first (limiting /preventing Sybil attacks). Misbehaving nodes will still get kicked automatically.

There is a high threshold (80%) required for consensus so in order to steal funds, an attacker would need to control at least 80% of all nodes. But with only 20%, the network can be paralyzed and funds would be frozen. While this is still better than a complete take-over, it's much easier to achieve and there are still financial incentives to attempt to paralyze the Wrapped Hive network (for example, shorting WHIVE token and crashing the price by blocking any cross-chain transfers).

Transfers

From HIVE to ERC20: When a new transaction is detected, one of the validators ("head validator"), selected every 5000 blocks (4.166 hours), will propose new transactions to the network. The remaining validators will check the proposed transaction, and if it's valid, they will sign it and broadcast their signatures in custom_json.

User (or more likely wHive helper app) will they collect all signatures and the user will have to call a multi-signature smart contract on Ethereum. The contract will verify enough signatures are valid and then mint new WHIVE tokens.
Compared to the current system where wHive oracle is paying for gas fees, this has several advantages. First, there is no need for validators to have ETH to pay for transactions. Users also have much more control over how much they want to pay in gas fees (since Ethereum signatures are not time-sensitive, users can choose to wait until the gas price is lower).

Of course, there are some drawbacks, multi-signature contract require quite some computational power, and it will have high gas cost. With 3 validators, around 170k gas was used. I did some testing with 40 signatures and over 600k gas was used (~$40 at the moment (50 gwei, $1.2k/ETH)). My goal is to have Wrapped Hive Network as a backbone of this system, but for smaller amounts, I expect different smaller centralized bridges (similar to Hive-Engine and LeoDex/BeeSwap) to be launched.

From ERC20 to HIVE: When the user wants to unwrap WHIVE, he must call the convertToken method on WHIVE token smart contract. This will allow adding Hive username to the token burn, and validators will know who should receive HIVE. Again, the head validator will propose a transaction, validators will check the proposed transaction, and if it's valid, they will sign it and broadcast their signatures in custom_json. Someone (head validator, but it doesn't matter if someone else is faster) will collect signatures and broadcasted the transaction to Hive.

Wrapped Hive Network Development History

I started working on decentralized Wrapped Hive almost immediately after the first centralized Wrapped Hive was released in late August. My first attempt to decentralize it was described in this post. Master/validators were using REST API to communicate. A similar system is used for my recently proposed system to decentralized HBD Potato.

slika.png
It should be validation, not verification

But it has some drawbacks. While it's much more secure than a centralized version, it's still pretty centralized.
2nd attempt was actually started by @ederaleng, but sadly he had to leave the project soon and I took over development. It was using WebSocket (actually socket.io, not pure WebSocket). After some time, I become concerned about some features (and the way I implemented them) and I also managed to turn code into spaghetti, and I was afraid that maintaining could turn into a nightmare.

So I just scrapped the entire codebase and started from scratch (keeping the only original p2p code from @ederaleng). This time, I followed the clean arhitecture as closely as I could. I tried to write parts of the code as separated as possible, so for example, 95% of the app has no idea what database is it using. If I decided that MySQL/MongoDB/MariaDB/PostgreSQL... is better, I could switch the entire app in only a few minutes (compared to having to modify much larger parts).

This was also pretty useful when I decided (pretty far into development) that socket.io is not the best way of communication between nodes and switched it for custom_json on Hive.

Roadmap

While the first testnet is an important milestone, we are still far from the final product.

  • 2-4 weeks: Completing some other core features (self-healing of the network, sync (for nodes entering network after launch), setup scripts)
  • 2 weeks: Public testnet & testing
  • 2-4 weeks: Security audit of both validator node and multi-sig smart contract
  • 2 weeks for any possible delays and to fix issues found during audits & on testnet.
  • Launch!

My goal is to launch the network on block 53,000,000 (April 13, 2021).

In case of delays, the launch will be delayed by 500k blocks (as many times as necesarry).

@fbslo

If you like my work, please support me by voting for my Hive Witness!
Witness announcement

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