Weekly Dev Update #17

THORChain

2019-11-18 — 6 min read

Recent Changes

Some recent updates to the protocol:

Update to Emission

The first iteration of the block reward scheme was announced in the previous weekly update:

An immediate concern raised from the community was that the emission was too aggressive in the initial year and rewards dropped off fast beyond the 5 year mark. Taking Bitcoin’s emission as an example, the emission curve has been updated to target 2% emission after 10 years.

The Block Reward equation is given by the following recurrence equation:

g(n+2) = ((R - (g(n+1) + g(n))) / x) / y

Which evaluates to:

where:

R = Reserve, x = 6 (Arbitrary Emission Factor)

y = (seconds per day / seconds per block) / days per year

y = (86400 / 5) * 365.2425

The final curve thus has a Day 0 emission of 25%, Year 1 emission of 20% and Year 10 emission of 2%.

ChaosNet

The original plan for BEPSwap (prior to the Yggdrasil liquidity breakthrough) was to have it as a separate mainnet before launching the real THORChain in 2020 with cross-chain support. Now THORChain has in-built cross-chain support and a clear roadmap to 99 nodes. This means the mainnet launch will have public, community-run nodes at the start. The community has been fielding many questions about how to run a node, and the mechanics in doing so. Since the THORChain team will not be running any nodes, it is necessary to have a full-rehearsal with the community at launch.

As such, the plan is for a public ChaosNet on 03 January 2020. ChaosNet will have the following key differences:

Minimum bond of 100k RUNE.
Maximum of 12 Nodes.
Churn cycle of 1 day.
Maximum stake amount of 600k RUNE total.
2.7m RUNE Protocol Reserve to emit Bond and Stake rewards.
Hard-coded Ragnorök at 6 weeks.

Any member who wishes to join ChaosNet to get accustomed to running a node can do so, and will receive Block Rewards roughly equivalent to mainnet (25%). They will be setting up nodes, churning in, servicing the network and earning rewards. The system will hold up to 600k Rune, at which point it will refund any additional staked amount. The community can stake small amounts of real assets, prepare arbitrage bots, set up telegram alert bots and more. In short, it is a public rehearsal with the entire community across all facets (nodes, stakers, traders) so that everyone will have access to the same information and not unfairly benefit when the real mainnet launches.

Additionally, the system will be hard-coded to perform a Ragnorök 6 weeks later, which will refund all the remaining reserve as well as bonded and staked assets. This will go a long way in re-assuring the community that the system can tolerate all levels of risk, including black-swan events, and that funds are safe at all times.

Internal Arbitrage

A new feature will be launched that will allow users to use internal arbitrage. This is an asymmetrical withdrawal to Rune, then immediately followed by a asymmetrical stake of Rune in another pool. A trader may want to do this instead of doing transactional arbitrage in order to exploit price differences between two pools the fastest way possible. Instead of an outgoing transaction being processed, followed by another incoming transaction, Rune balances and stakeUnits are swapped internally, being completed inside of a few seconds.

Fee-based Transaction Prioritisation

Currently there is no prioritisation to the order of transactions, all transactions are simply processed in order of time received. In moments of high demand of network resources (such as when there are large arbitrage opportunities and users are racing to exploit them), transactions will queue in the mempool.

If the system cannot respond fast enough, then the reason for high demand will persist (the large arbitrage opportunity). The solution is to remove the reason for high demand in the first place, which is the large arbitrage opportunity, at the same time as collecting the maximum revenue for the system.

As such, in the checkTx method (which can triage the mempool), transactions will be sorted and ordered in the value of the fee of the swap transaction. Assuming rational actors, the following transactions will then be prioritised over all others:

A transaction from an impatient swapper who is willing to pay a large fee.
A transaction from a trader who is able to arbitrage out a price discrepancy (and still make a gain).

This then means the system can collect as much income as possible (good for the stakers) at the same time as prioritising transactions that can arbitrage out large price discrepancies quickly. This then means swaps from transient swappers will experience a market price that accurately matches the reference price at all times.

BEPSwap Development

The team are working on 4 parallel streams of effort. Cross-chain infrastructure has now been merged into a single repo called “THORNode”.

THORChain

Midgard Public API

Threshold Signature Scheme implementation

Front-end Integration for BEPSwap

THORChain

Bug fixes, refactoring, as well as more logic around Yggdrasil funding. Additionally, node churn and the first part of block rewards PR was merged.

Midgard Public API

Database ported from influxdb to timescaledb (more maturity, better developer tooling). Endpoints built out include /pools and /stakers.

The OpenApi Schema can be reviewed here:

ReDoc documentationEdit description

Threshold Signature Scheme

TSS was successfully implemented into the Genesis ceremony, with the focus now being on the key-gen and key-sign ceremonies. Multi-cast DNS was switched out for a distributed hash table to facilitate node discovery.

A proof-of-concept is being prepared using BinanceChain TSS library, which was recently launched in order to make a decision whether to switch libraries. A go-based implementation is better for THORNode, since it is also written in Go: