Two weeks have passed since our last development update, and the THORChain team has made much progress. In the previous article, we discussed our work on test network stability and performance and focused on the ongoing front-end development for building the ASGARDEX exchange. In this current article, we will expand on this, provide an update on stability and performance, and discuss some issues related to wallets, authentication, and fairness in trading on permissionless decentralized exchanges.

Testnet Re-deployment and Performance Update

Dual Testnet Approach

As discussed in our last update, nodes on the initial genesis test network had developed a habit of freezing up and requiring a restart. We addressed the issue with the team behind the Tendermint consensus framework, who advised us that our low block times may be the cause for the instability, given the configuration of the current Tendermint implementation. After some investigative work, and following the advice from the Tendermint team, we carried out the following plan of action:

Firstly, we updated our code to use the latest release of the Cosmos SDK. This required some refactoring, as there had been a few breaking changes since we first started building on Cosmos.

Once the refactoring was complete, we deployed two test networks; one more conservative network with a 5-second block time, and a high-performance network, which produces blocks with sub-second frequency. The former allows us to test our higher-level developments in a stable setting while the latter will enable us to push the boundaries of performance and work on stability improvements.

Observations

We are pleased to report that both networks now run relatively stable without any nodes freezing up. Our transaction generation bots send transactions on both networks at a constant rate of 100 TPS. The following screenshots show a summary of the parameters measured:

Figure 1: Stable Testnet Results

Figure 2: High-Performance Testnet Results

As can be observed, the stable network runs more or less as expected. Block time averages at the targeted 5 seconds, and all four nodes are working correctly as validators. In the high-performance testnet, the average block time is 762 ms. We are also measuring 87 TPS in the slower network and 96 TPS in the faster network. These numbers have fluctuated over several days, so it seems they are in no relation to the block times.

As transactions are submitted to the network at a stable 100 TPS, it seems the network is dropping a percentage of the transactions. We have investigated the issue, and it appears that transactions are rejected because of incorrect ordering numbers. For some reason, that might be related to our test setup, transactions sometimes arrive out of sequence at the gateway node. The team is currently looking deeper into the issue to improve the test setup.

In addition, one of the nodes seems to insist on not acting as a validator. Although all four nodes are configured to operate as validators, the network consistently reports three validators.

Some investigative work is required to analyze these issues, but it seems that the Tendermint team was spot on in their feedback on this situation: targeting very short block times makes things difficult.

On the other hand, the stable test network with 5 second block time now provides a reliable platform for the team to test the higher level protocols and to build out the ASGARDEX exchange.

Key Management and Exchange Wallets

Decentralized exchanges return power to the user as they are not custodial in nature. This means that users trade with each other directly, rather than through a centralized trusted third party that holds funds on their behalf. This also means that users must manage their private keys, and doing this in a user-friendly way through a web interface requires some ingenuity.

Decentralized exchanges return power to the user as they are not custodial in nature.

A user’s private key should never leave their local system. Therefore, user authentication through keys and transaction signing needs to happen locally on the user's device. In the interest of user-friendliness, this should happen as transparently as possible, preferably in the browser. For our current UI prototype, users should be able to import their existing keys or wallets into the browser and use this to sign messages. Of course, it must also be possible to de-authenticate an account; essentially, removing the key.

Our message signing and sending procedure is build on the Cosmos SDK and requires the following flow:

1. Encode the message using the Amino Encoding protocol, which is an efficient binary object encoding format built on top of Google’s Protobufs.
2. Calculate a hash of the message.
3. Sign the message using the ECDSA Secp256k1 algorithm.
4. Send the message to the network using RPC over HTTP.

After exploring different options for implementing these steps, we were left with two options: developing a pure JavaScript implementation or using WebAssembly. The team eventually chose the latter, given that there is currently no Amino implementation in JavaScript and WebAssembly support is very complete in modern browsers.

The result of these development efforts is the THORChain-Wasm bridge, which allows building, encoding and signing Tendermint messages in the web browser. The front-end team is currently integrating this bridge into the ASGARDEX UI.

Fairness in Decentralized Trading

Blockchains are transparent, meaning all transactions, confirmed or unconfirmed, are publicly visible. This introduces an issue known as front-running. Someone watching the blockchain can observe a transaction that is waiting for confirmation and overtake it in the queue, by setting a higher gas price and thus creating a higher-priority transaction for validators to confirm. Front-running can be an issue in trading, as a user who observes a pending trade could submit another order with a slightly better transaction fee, in order to gain an unfair advantage. Centralized exchanges are not as affected by public front-running, as only “insider front-running” is possible. However, in decentralized exchanges, any user can take this advantage. The THORChain team, therefore, has spent some time researching ways to reduce the front-running risk. THORChain’s design already minimizes the attack surface for front-running considerably through swift block times, giving potential attackers a very short time frame for transaction re-ordering.

Blockchains are transparent, meaning all transactions, confirmed or unconfirmed, are publicly visible. This introduces an issue known as front-running.

A further measure that has been investigated is defining a maximum gas price limit for trade-specific transactions. This gives users the option to protect their trades from front-running by paying the maximum gas price allowed for trades when they place their orders, meaning no other traders can pay more to overtake transactions.

This maximum gas price limit solution only leaves validator nodes with the capacity for potential front-running activities. The THORChain team has been researching a novel protocol for blinded trading based on a commit-reveal scheme in order to reduce the risk even further. We will publish a separate article on this very soon, explaining this in detail.

Ethereum Bridge

We have already commented on the Bifröst protocol, which enables building bridges to existing blockchains. This is essential for being able to trade assets represented on these chains on THORChain and thus on ASGARDEX. TokenChains are created in the THORChain ecosystem representing the external blockchains and several bridges are created per TokenChain to move assets to and from their original chain to the THORChain equivalent. Development on the first such chain, the Ethereum Bifröst, has now started in earnest.

The initial prototype’s specification is heavily influenced by the Cosmos Ethereum peg zone concept. Currently, a smart contract security auditing team is undertaking a security audit of the Cosmos Ethereum. This is an essential step in our preliminary analysis of how much of the Cosmos peg zone code can be re-used. We are planning to publish the results of this audit very soon.

What’s Up Next?

As always, we will end this development update with a note on what the future steps are for the THORChain team.

There are currently a number of parallel activities focusing on getting THORChain open for test trading:

Performance and Stability Optimisation: The team has made much progress getting the testnet running in a stable manner under load. Further work is required to push the envelope of performance to ensure THORChain will provide a smooth user experience, particularly once the number of users increases.

ASGARDEX Development: The current state of ASGARDEX is pending integration of the already developed key and wallet management modules. Once this integration is complete, test trading on ASGARDEX should be possible with existing THORChain accounts. Also in progress is enabling token swaps that use trades against CLPs to provide fast, seamless swaps between a variety of available token pairs.

Rune Faucet: Test users require a test version of Rune, THORChain’s native token, to operate on the platform. A faucet will be developed to make it easy to obtain test Rune, allowing users to request a reasonable amount of Rune to be sent to their account. Ethereum Bifröst: The Ethereum Bifröst protocol will be built as the first example of a cross-blockchain bridge, allowing Ether and ERC-20 tokens to be moved between THORChain and Ethereum.

Research: Besides these development activities, part of the THORChain team is continuously carrying out research activities that should lead to future developments. Issues currently being looked into include the front-running risk mentioned above, sharding, and the economics of validator slashing.

This update was brought to you by the Blockchain team at Swish. We build Blockchain products and apply them to business.

Interested to learn about the potential of Blockchain for your business? Let's chat