In the last development update, we talked about our first testnet deployment for the THORChain project, a high-performance liquidity and payment protocol for decentralized exchange use cases. We discussed our performance goals and the test setup. Unfortunately, we had also hit some stability issues that meant we had to slow down THORChain’s lightning fast protocols in our testnet.

In this current development update, we will further discuss these stability issues and our initial countermeasures. Progress has also been made in the implementation of the ASGARDEX exchange, and we will discuss how we plan to make THORChain interoperable with other blockchains.

Stability Testing

We talked extensively about our test setup and performance benchmarks in the last update. As you may recall, our Genesis testnet runs four nodes hosted on Amazon Web Services. After some very promising initial performance results, achieving 900 transactions per seconds (tps), we had to dial our transaction “spamming” down to around 100 tps because of stability issues. Nodes lost connection to the network and failed to reconnect until restarted.

We have a strong suspicion that the issue is down to a few lines of code.

Since then, the team has taken a number of steps to solve the issue. First of all, we updated the versions of Tendermint and the Cosmos SDK used by THORChain. The former is a consensus framework for running a pBFT consensus protocol between validator nodes. The latter is an SDK providing the primitives to implement delegated proof-of-stake blockchains on top of Tendermint.

As both projects are under active development, there have been advances since we first started working on THORChain. Thus, the team invested some time in migrating to the latest version, including handling many breaking changes due to significant restructuring in the Cosmos SDK.. Secondly, we narrowed the issue down to some specific Tendermint code segments and got into contact with the Tendermint team. We already mentioned this in the last update but there have been some updates on the GitHub issue, and we have also discussed the issue with the Tendermint team in person at the Web3 summit in Berlin. Summing up the result of various conversations and experiments, it seems the issue appears in Tendermint when very short block times are targeted. THORChain currently issues blocks every 750 ms, which seems to be too fast for the current Tendermint implementation to handle stably.

The THORChain team has therefore decided to adopt a dual testnet approach. We will reduce block generation frequency on the main testnet for stability reasons but will operate a separate testnet to continue to improve stability with low block generation times. That way, there always should be a reliable network for testing higher-level functionality, while at the same time giving our low-level system engineers a platform to push the limits of performance.

We will keep you updated on progress related to performance and stability in future articles.

ASGARDEX

As we have mentioned before, the Helheim milestone is all about decentralized trading on THORChain.

For this reason, a lot of recent development has focused on ASGARDEX, a decentralized exchange demonstrating the on-chain trading and built-in liquidity provided by THORChain.

As ASGARDEX is mainly a user interface for protocol-level features, most of the current development is, therefore, front-end work. One of the most complex features being developed at this level is authentication and transaction signing. These features equate to providing client-side wallet functionalities. No private key should ever leave a user’s machine, so any decentralized exchange must allow users to sign transactions locally (preferably in-browser). We explored a number of options before settling on a solution (the whole process justifies a blog post of its own, which we are planning to provide in the future). For now, it suffices to say that the solution involves compiling Tendermint transaction-signing code written in Go to WebAssembly (Wasm) and executing it within the Wasm environment available in modern browsers.

ASGARDEX will go live for testing very soon.

Blockchain Bridges

The Bifröst Protocol

One of the most important features of asset trading is interoperability between different blockchains. THORChain’s multi-chain approach already allows trading easily between different THORChain TokenChains. However, to be truly useful as a universal decentralized exchange or global payment network, assets held on different existing blockchains, such as Bitcoin and Ethereum, need to be supported.

THORChain defines its own protocol for building bridges to external blockchains. The Bifröst protocol facilitates moving assets between THORChain TokenChains and external chains, whether the external chain uses an account-based, an UTXO-based, or a smart contract-based model. Typically, an asset will be represented by its own TokenChain in the THORChain ecosystem. An asset can be moved onto its THORChain equivalent by “locking” an amount on the original chain and minting the equivalent token amount on THORChain. The reverse process involves burning the THORChain token and releasing the locked assets on the external chain. Of course, this process has to be atomic, meaning the corresponding minting and locking actions of fixed amounts either happen on both chains or none of these actions occur. Just performing one of these actions or getting the amount wrong would lead to inconsistencies, something the Bifröst protocol avoids.

The key to security and decentralization is controlling the atomic locking and minting process. Locking on the external chain is achieved through multi-sig accounts. These multi-sig accounts may require m of n, n-1 of n, or n of n signatures to move funds.

A subset of THORChain validators acts as signatories to the external multi-sig account. These signatories must run a full node of the external chain and report current block height. If they lag behind they risk losing their validator stake.

Of course, the most secure setting would be choosing the full set of validators as signatories but this would be expensive and slow. Therefore, in THORChain, bridges can be created with different numbers of validators acting as signatories. Users can decide which bridge to use, based on the trade-off between their cost and security preferences. A 3 out of 4 signatures bridge is likely to be much faster and cheaper than a 67 out of 100 signatures bridge. However, it may also be less secure.

In order to improve security, THORChain will be able to rotate signatories at certain intervals. This may require locked coins on the external chain to be relocated to different multi-sig accounts, depending on how multi-sig schemes are implemented on the external chain. On-chain verifiable random functions will eventually be used for this re-shuffling. Furthermore, schemes like BLS threshold signature can reduce the potential impact of re-shuffling.

In addition to the Bifröst whitepaper, we have developed a second paper describing the initial prototype of the first Bifröst to be implemented.

The Ethereum Biföst Prototype Specification

In order to make ASGARDEX (and THORChain in general) useful for inter-blockchain decentralized trading, we’ve made implementing Bifröst bridges a very high priority. The first bridge to be implemented will be the Ethereum blockchain bridge. While a Bitcoin bridge would probably be simpler to implement, an Ethereum bridge will give immediate access to thousands of assets implemented as ERC-20 tokens in Ethereum smart contracts.

In this current phase, leading up to the delivery of the Helheim milestone, our principal blockchain architects have reviewed the Bifröst protocol and defined an Ethereum bridge specification. This current specification outlines the development steps the team will take to implement an Ethereum Bifröst bridge prototype. It entails some simplifications compared to the eventual full protocol but is sufficiently advanced to allow moving assets between the two chains.

While we have borrowed concepts from the Cosmos pegzone specification, there is still a lot of work to be done to adapt the Cosmos per zone design to the Bifröst model. The Ethereum Bifröst bridge prototype will consist of four modules:

• An Ethereum multi-sig smart contract used to lock assets on the Ethereum chain.
• The expanded THORChain full node software, which will now include the Bifröst and an oracle module
• A signer process, responsible for signing requests sent to the Ethereum chain
• A transaction relayer, in charge of relaying transactions between the two chains

Each node participating in this prototype should run both the signer and relayer processes, in addition to their THORCahin node software.

The signer process uses secp256k1, the Elliptic Curve Digital Signature Algorithm (ECDSA) used by Ethereum, to sign Ethereum-bound transactions. Each of these processes has a corresponding Ethereum address. Initially, we are just planning to sign raw transactions and send them through the Infura public node gateway. However, in the very near future, our testnet nodes will run their own Ethereum nodes.

The specification document also discusses the implementation steps we can foresee, for readers interested in the more detailed planning process.

What’s Up Next?

From the above, you may be able to deduce that there are currently three ongoing lines of work that are being prioritized:

1. Performance and Stability Optimisation: Getting our testnet stable during high load and with low block times is, of course, essential for future THORChain scalability. As explained above, we are running a parallel high-performance testnet for this very purpose.

2. ASGARDEX Implementation and Testing: ASGARDEX will allow users to try out THORChains liquidity and trading features from a modern and easy to use interface. A lot of front-end work is being done to make this possible.

3. Ethereum Bifröst Development: ASGARDEX and THORChain will become fully useful once the platform can interact with assets on external blockchains. This is the reason why implementing a bridge to the Ethereum network will be our next big development step. Preparations for this are in full swing.

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 talk.