Weekly Dev Update #22

2019-12-23 — 5 min read

Changes

Churn Logic

Node churn is one of the cornerstone innovations of the network and must be implemented properly. Previously THORNode tracked a height and then set a window of time at which to begin churning prior to this, but this has now been replaced with simply a height. As soon as the network crosses this height (50,000 blocks), it will initiate a churn. If the churn fails, it will repeat this every 720 blocks (hour) until it is successful. There are a couple of reasons why it may fail:

TSS Timeout. TSS key-gen relies on multi-party computation with a number of communication rounds. As the committee size increases the time required to complete increases quadratically. If TSS key-gen takes too long, it will timeout and the network will attempt to shard into smaller committees. This means the network can keep sharding up until a point only limited by the number of nodes than can bond 1m RUNE. This is an economic limit, and not a hard-coded limit.

Malicous Node. A malicious node may not like the churn to take place, so they can deliberately abort the protocol. In this case, the key-gen will abort and all nodes will send a blame transaction nominating who they thought aborted the key-gen. The most-blamed node is then nominated to churn out, and not involved in the subsequent key-gen, in effect leaving them behind.

If the churn is successful then the nodes will now skip the challenge-response and proceed immediately with moving funds. The team have arrived at this simply because it is not possible to be successful at creating a new key and not being able to sign on it subsequently. The challenge-response was creating unnecessary gas-handling complexities.

THORChain

Work continues to refactor the codebase towards a much more testable interface. This is important to ensure the code can be properly audited and is easy to maintain post-mainnet. Some small features were added, such as bond reward events, so that the Midgard API can properly track what is happening on the network.

Churning

The team spent a lot of time to test, validate and improve node churn. The notion of “pools” has been removed and replaced with “vaults”, where assets are stored. Churn logic was simplified as discussed above. Work also began on refactoring the signer to be more redundant, especially around handling sequence numbers.

Audit

The codebase is significant, totalling over 30,000 lines of code. Efforts are being made to reduce this, but the team do have concerns over the scope of the attack surface. As such, they intend to conduct three different audits to ensure the system works as intended.

Code Review. This will ensure the THORNode binary is engineered to a high standard. This should ensure there are no issues with the binary itself.

TSS Audit. The team used the Binance lib-tss, but added several safety features to prevent known attacks. This should be audited.

Economic Review. THORChain is built to drive capital allocation in such as way that it can achieve certain security assumptions. This should be validated.

The team have finalised one audit partner and is confirming the other two. Details on this will be announced soon.

Liquidity Model

Much has been said about THORChain’s liquidity model. The swap logic is only 4 lines of code and is quite insignificant when considering THORChain’s primary goals of enabling cross-chain liquidity.

The CLP formula is shown here (from swap.go in the THORNode Repo):// Calculate the number of assets sent to the address (includes liquidity fee)
func calcAssetEmission(X, x, Y sdk.Uint) sdk.Uint {
// ( x * X * Y ) / ( x + X )^2
numerator := x.Mul(X).Mul(Y)
denominator := x.Add(X).Mul(x.Add(X))
return numerator.Quo(denominator)
}

The team have spent a considerable time in the prevailing week revisiting it and studying the merits of CLP v XYK, including with some members of the community. The team have concluded that CLP is still more appropriate when considering its value-capture and access-control mechanisms for accessing liquidity, and will still continue with the formula. The team have a drafted blog that is under review and will articulate this at length.

Milestones

The updated testnet is in the final stages of being deployed and will be available soon.

The audit will commence immediately. The Code Review and TSS Audit should be completed mostly prior to ChaosNet, but the Economic Review can happen alongside. More details on this will be announced soon, including the plan for RUNEVault, which is an integral part of RUNE’s distribution phase.