Weekly Dev Update #71

THORChain Weekly Dev Update for Week 71, 24–30Nov; Multiple outbounds, Finalisation Parameter, Node Improvements, Gauntlet Report, Community Tool Improvements.

THORChain

Published in

THORChain

5 min readDec 1, 2020

Summary

The team worked on multi-chain improvements. Chaosnet is stable, so all the changes are destined to the next net, but some changes may be cherry-picked into Chaosnet to improvement and validate assumptions. Gauntlet released the CLP report which was favourable to THORChain’s model and community developers continue to ship updates.

THORNode

Multiple Outbounds

A notable change to one aspect of THORNode this week is now the ability for the state machine to delegate one or more vaults to fulfil a member’s withdrawal. This is because funds can be scattered across multiple vaults and a single transaction cannot service the full amount (such as a large LP in a small pool doing a large withdrawal). The state machine will try to minimise the outbounds, but now there can be multiple. To date, there have been several LPs in some of the smaller pools who have not been able to withdraw (they would get error message “You cannot withdraw more than 10% of the pool”) — this should fix this.

Finalisation Parameter to Observations

For probabilistically final blockchains such as Bitcoin and Ethereum1.x, large transactions are not economically final until the chain has produced enough income to make it unfeasible to be re-orged. THORChain does not do “6 confs” (arbitrary threshold on whether or not a transaction is final, as opposed to economically final), instead it counts confirmations — (any Bitcoin transaction is safe to spend 1-conf as long as less than ~6.25 is received by THORChain in a block). To do this it measures the coinbase reward (subsidy + fees) and counts the total received block value against this. To date the logic has been in the Bifrost, so THORChain is never aware of large transactions. This change now adds a finalisation=uint so that the state machine (and thus Midgard) is immediately aware of an inbound transaction, AND it is told of how many confs are to be waited, like finalisation=3. Now clients can inform the user of the ETA of a swap. The Bifröst will then follow up 3 confs later and tell the state machine it is safe to process the transactions.

Note: Even if a user performed a small swap, like 0.1 BTC, but did it unknowingly in the same block as a user doing a large swap, like 20 BTC, both users will have to wait 4 confs, but this is still better than making all users wait 6 confs. 6 confs is not a magic limit that makes transactions safe — a 1000 BTC transaction is categorically unsafe at 6 confs, there can still be an actor with the financial resources to pull off a re-org at that level. Indeed, Binance considered a 100-block re-org of the Bitcoin chain to reverse a 7000 Bitcoin theft, but abandoned that when they realised they would enter a fee-race with the attacker. THORChain has no ability to stop or censor transactions and is completely permissionless, thus it must function purely on economic terms, and not rely on any altruism or social contracts.

Node Improvements

Two other notable improvements to THORNodes involve now (after much community discussion on possible chain bloat) emitting slash events to help THORNodes understand why they are getting slashed:

Missing an observation, 2 points, (is the chain-daemon running?)
Missing a key-sign, 2 points, (is Bifröst running?)
Missing a key-gen, 720 points, (is Bifröst running?)

As well as a better grace period to new nodes to stop them being churned out as soon as they enter. They now get a full churn cycle grace period, as well as a 100 slash point minimum, before being considered bad. New nodes are more likely to get churned out, because the “bad” metric is the inverse of blocksActive/slashPoints.