Haven Protocol Public Testnet with Decentralized Oracle Announcement
Round 2 of private testing has gone swiftly — Time for the Haven Protocol Public Testnet
Initially our aim was October for the Public Testnet. However the most significant piece of feedback the team have given us is to ensure that a decentralized oracle is to be included in the Public Test. In previous tests we were just focusing on the offshore storage specific code.
The main reason for this is to avoid the perception that the mainnet oracle will function the same way. As the decentralized oracle wasn’t ready, we have had to work on it which wasn’t the initial plan for this test.
We don’t want to have to make everyone wait more than we need to and are going to push out the estimated release time to mid November.
Haven Decentralized Oracle:
What is the Haven Oracle?
For those who don’t know, an oracle is how a blockchain interacts with the wider internet i.e. an API. The Haven Oracle is what is used to determine the current price of Haven so we know the USD value of any Offshore (XHV -> XUSD) and Onshore (XUSD -> XHV) transaction.
Design
Who runs nodes?
Anyone can run their daemon as a validator and run the open source oracle code locally. As new blocks are detected, your daemon references the reported price in the new block and compares it to the prices you have determined independently.
Everyone is encouraged to run a remote node but all exchanges, pools, remote nodes and seed nodes will be required to run an oracle node.
Oracle nodes can be run independently from the Haven daemon. Anyone not running a validator node will accept the chain with the most work as usual.
How is the price determined?
The price is determined based on a weighted average and will be calculated over all exchange values, primarily based on volume, and normalized over previous 20 previous prices. Each oracle reaches out to the exchange APIs and gets the recent market history.
This will disincentivize someone attempting to manipulate mint and burn for profit through pushing up the price/dumping the price. To have any significant impact they would need to maintain the value over all exchanges for over 20 blocks (40 minutes). The cost of doing this would far out weigh any rewards.
FAQ: What would would happen in a 51% attack situation? Couldn’t they force everyone to accept a tampered price?
No. If the price in the block doesn’t match what is expected by your oracle, even if it is the longest chain with the most work, it will be rejected.
Your oracles reported price isn’t determined based on what the majority of oracles report; they don’t reference each other in any way.
There seems to be some misconceptions around how a 51% attack works. You can’t rewrite any consensus rules — otherwise all 51% attacks would involve minting billions of coins. A 51% attack can only force a roll back if their chain is the longest with the most PoW. An attack would work like this: An attacker would start mining with over 50% of the nethash and not expose the chain to the wider network.
The attacker sends all their coins to an exchange. After the deposit has enough confirmations, they sell and withdraw the btc. Once the btc is in their wallet; they expose their chain to the wider network. As that chain has the most work, it will become the “correct” chain and all nodes will roll back and sync with it. On the hacked chain, the attacker never sent their coin the the exchange address and will still have the coins in their wallet. The exchange loses out in this scenario.
If someone was to input a fake prices, all other nodes would reject the transaction as this price wouldn’t match what their trusted oracle data reports. They would have created a chain split and all validator nodes will eventually stop attempting to sync with the incorrect chain and ban them.
Most significantly all exchanges will stay on the original chain and any transactions attempting to send hacked coins to the exchange will be doing so on a completely different chain and never reach them.
