Weekly Dev Update #17
THORChain Weekly Dev Update for Week 12–18 Nov 2019
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:
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%.
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.
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.
The team are working on 4 parallel streams of effort. Cross-chain infrastructure has now been merged into a single repo called “THORNode”.
- Midgard Public API
- Threshold Signature Scheme implementation
- Front-end Integration for BEPSwap
Bug fixes, refactoring, as well as more logic around Yggdrasil funding. Additionally, node churn and the first part of block rewards PR was merged.
- Add admin config event, fix tx out events
- Resolve “Select a satellite pool to swap out”
- Include the thorcli volume for the signer.
- Rune Reserves, block rewards, bond units, oh my!
- Add mechanism to slash a node account bond or rewards
- Add add event
- Issue198 node churn
- Issue199 — fix signer doesn’t process multiple txout item
- issue194: only rune get refund for invalid memo
- Outbound — mark txout item out hash based on the coin as well
Midgard Public API
Database ported from influxdb to timescaledb (more maturity, better developer tooling). Endpoints built out include
- Feature/new endpoint format, refactors and general clean ups
- Updated new events api schema
- Removed deadcode that is breaking the build.
- Moved to one influxdb table/measurement as you need flux to make cross table calculations.
The OpenApi Schema can be reviewed here:
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:
Permissively MIT Licensed. Note! This is a library for developers. You may find a TSS tool that you can use with the…
Bug-fixes and tweaks from community feedback. The frontend is now ready for implementation with the latest Midgard API.
The team are working for these milestones:
- Feature Freeze: 20 November 2019
- Audit: 20 December 2019
- ChaosNet: 03 January 2020
To keep up to date, please monitor community channels, particularly Telegram and Twitter: