The Fully Trustless Oracle For BTC Hash Rate Futures
About SynFutures
SynFutures is an upcoming derivatives protocol, currently in V1 Closed Alpha phase. The team is a combination of crypto natives and Wall Street top guns, with the idea to build a solid infrastructure for future DeFi derivatives on Ethereum and other L2/side chains. In June 2021, SynFutures announced $14mn Series A funding led by Polychain Capital with participation from Framework, Pantera Capital, Bybit, Wintermute, CMS, Kronos, and IOSG Ventures. Earlier in 2021, it announced a seed round backed by Dragonfly Capital and Standard Crypto.
You can visit the website to register for V1 Closed Alpha early access. or join discussions on Medium / Twitter / Telegram / Discord.
BTC hash rate futures (BTCHASH), introduced by the SynFutures team, represents the expected BTC block mining reward for a difficulty resetting period (roughly 14 days) per PH/s hash rate at a set difficulty level. Miners can use BTCHASH to hedge the fluctuation of Bitcoin mining difficulty in order to lock in future mining rewards. For more information about the BTCHASH product, please refer to our introduction blog (link) and the FAQ (link) page.
One can easily compute the expected mining reward of 1PH/s hash rate given the current mining difficulty specified in every BTC block header, based on the incentive model of the Bitcoin network. The mining difficulty only resets at block heights of multiples of 2016 and stays constant for the blocks in between.
Such an inactive spot index is not useful to an on-chain derivative product — BTCHASH prefers a continuous and near real-time spot index. The naïve way to achieve this is for the SynFutures team to upload the spot index calculated off-chain at regular intervals. However, if this were to be done, the team would wield centralized control in the ecosystem, backfiring on the trustless feature of BTCHASH.
After conducting deep research on Bitcoin’s blockchain structure and the complete rules of the Nakamoto Consensus, we’re convinced that it’s feasible to build an on-chain oracle providing all the necessary information for BTCHASH while reserving its trustless component. It’s imperative that it’s designed in such a manner that no one can manipulate the spot index.
The idea is simple — all the information needed can be deduced from the 80-byte Bitcoin block header. Only the headers satisfying the Nakamoto consensus will be taken into consideration. By implementing the validation logic with smart contracts, we present a fully transparent and trustless Bitcoin mining difficulty oracle where anyone can submit newly generated Bitcoin headers to update the BTCHASH spot index .
Although the idea is simple, the engineering can be quite complex due to the potential reorganization of the Bitcoin blockchain, as well as the huge timestamp drifting allowed by the Nakamoto consensus. To deal with reorganization, we built the oracle under the security assumption that confirmation of 10 blocks is considered final. Thus, the oracle always keeps track of the 12 most recent block headers.
When submitting new headers, the oracle requires that the hashPrevBlock of the first header in the transaction must point to one of the latest 10 blocks known to the oracle. Additionally, the block height of the last header in the transaction must be greater than that of the latest one. Other checks are performed to validate the headers against the Nakamoto consensus, including hash chain validation, block header validation against mining difficulty targets, and accumulated work processing for chain reorganization.
To fully understand the timestamp drifting problem, let’s recap the structure of the Bitcoin block header. The 80-byte Bitcoin header is composed of 6 fields listed in the table.
Note that the Version field was initially used to indicate the block version, but the block validation process does not enforce strict rules against this field. Nowadays, miners tend to iterate through both the Version and the Nonce fields when doing the heavy mining work. The hashPrevBlock forms the Bitcoin blockchain , and hashMerkleRoot is the digital fingerprint of the transactions in this block.
The nBits field is the current difficulty target expressed in compact format and will remain constant during a difficulty resetting period. The Timestamp field is used to record the block creation time, thus it’s naturally expected to increase monotonically as the block height grows. Yet, due to the lack of a global network clock and possible time drifting between nodes, Nakamoto consensus enforces only a loose rule in this field.
This loose rule leads to the huge Timestamp gap (thousands of seconds), even between two adjacent blocks. Such unreliability of the Timestamp field poses a significant challenge to the construction of the oracle. But we believe that it can be solved in an efficient and elegant way.
The mining difficulty target represented by the nBits field only resets at block heights of multiples of 2016, according to the Timestamp difference of the beginning and ending blocks of the last period (the previous 2016 blocks). To obtain a real-time mining difficulty target, we can easily follow the same difficulty target resetting rule at each block height. That is, we use a moving window of past 2016 blocks to calculate a block-weighted difficulty target as the spot difficulty index.
Note that, past 2016 blocks could belong to 2 periods. Suppose the difficulty targets are denoted by Target0 and Target1–288 blocks belong to the previous period, and 1728 blocks belong to the current periods. If this is the case, then the current difficulty target is calculated as:
currTarget = Target0 * 288/2016 + Target1 * 1728/2016.
If the Timestamp difference is the actualTimespan, then the newTarget for the next block is calculated as:
newTarget = currTarget * actualTimespan / targetTimespan
The beauty of this approach is that such a block-weighted difficulty target converges to the actual difficulty target at resetting blocks with certainty.
The spot difficulty index directly relates to the BTCHASH spot index price , which in turn influences the mark price of BTCHASH. As mark price is used to determine whether an account has sufficient margin, it is vital that we do our best to eliminate the abnormal price jumps to protect our users.
Looking closely into the way newTarget is calculated, one will notice that actualTimespan is calculated based on the aforementioned unreliable Timestamp field in the Bitcoin block header. This implies that a miner might be able to abuse the loose rule regarding the Timestamp field to manipulate the spot difficulty index.
The loose rule about Timestamp states that: A Timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. “Network-adjusted time” is the median of the timestamps returned by all connected nodes. As a result, block timestamps are not exactly accurate, and don’t need to be. Block times are accurate only to within an hour or two. (Note that it is infeasible to express the part of network-adjusted time restriction with a contract because there is no consensus about the network-adjusted time at the whole network level.)
As mentioned before, we adopt the moving window method to deduce real-time difficulty targets using only the block headers. Intuitively, we would expect the timestamps of the beginning and ending blocks to increase monotonically with regard to block height growth. Yet, from the loose rules about Timestamp fields, there is no such guarantee on either end.
How can we mitigate the timestamp drifting risk in such a situation? On the other side, computing actualTimespan would require the contract to store and maintain the most recent 2016 blocks’ Timestamp, which would consume considerable gas when initializing the oracle as well as submitting headers.
To tackle all of the problems we discussed, SynFutures has built different solutions to the two sides of the moving window. On the ending side, we just follow the median timestamp — that is, the spot difficulty target is not calculated regarding the latest header, but the header with a median timestamp. This is feasible since the oracle always stores the most recent 12 block headers. In this way, we are guaranteed by the Nakamoto Consensus that the ending side of the moving window will never become obsolete. On the beginning side, instead of storing all the 2016 blocks’ Timestamp, we only store one Timestamp of the block every 144 blocks. Other headers are considered to be distributed evenly in between.
As no timestamp drifting would be greater than 24*60*60 in seconds, we are guaranteed that the left side of the moving window will always extend to the future. Even better, the Timestamp drifting of individual headers is amortized by 144 blocks in this way.
We managed to implement this complete logic with around 300 lines of Solidity code. The resulting gas consumption of submitting 12 block headers is around 270k gas. The spot difficulty target moves smoothly and will always converge to the value specified by the Nakamoto Consensus, as expected.
We’ve also have an FAQ Section on Hash Rate Futures if you’d like to learn more. Still got questions? Reach out to our admins here on Telegram or Discord
Join our community!👪
Please visit our website at www.synfutures.com or join discussions on Medium / Twitter / Telegram & Discord.
