Delphi Digital: Comprehensive interpretation of THORChain architecture design, transaction mechanism and cross-chain, etc.
Editor's Note: This article comes fromChain News ChainNews (ID: chainnewscom)Editor's Note: This article comes from
Chain News ChainNews (ID: chainnewscom)
Chain News ChainNews (ID: chainnewscom)
This article is part of the "THORChain Research Report" released by the cryptocurrency research organization Delphi Digital. The original report was released in December 2019. The relevant data and information status is as of the release time, but it does not affect the understanding of the core content of the project. Lianwen is authorized to reprint by Delphi Digital.
Example
THORChain is an interoperable, application-specific blockchain that enables cross-chain liquidity pools (or “capital pools”). Its first mainnet iteration, BEPSwap, is scheduled to go live in the first half of 2020, allowing BEP2 assets to be pooled on Binance Chain. After that, ASGARDEX, a complete cross-chain implementation program, will be released. Through the seed round financing in 2018, IDO in Binance in July 2019 and private placement, THORChain raised a total of 2.1 million US dollars.
Value Proposition and Token Economics
Example
Pledge non-productive assets to obtain income: Owners of non-productive assets (such as BTC) can pledge these assets to the liquidity pool, collect transaction fees and newly issued RUNE to obtain income. THORChain's liquidity pool design can better protect pledgers from arbitrage losses than other models (such as UniSwap), so it can further incentivize pledge behavior.
main benefit
Run a node to obtain income: Anyone can bind the minimum required amount of RUNE (currently 1 million RUNE) to operate a node and participate in network operation. In return, they can earn revenue by charging transaction fees and newly issued RUNE.
Arbitrage opportunities: Arbitrageurs can profit, and they also help the asset ratio in the liquidity pool return to balance.
main benefit
Permissionless & Privacy: Anyone in the world can exchange assets directly across chains without permission or revealing their identity. In addition, node operators are anonymous, and no one can identify which node signed a specific transaction.
Pledged liquid assets are non-custodial: assets are pooled on-chain rather than entrusted to third-party custodians, and are secured by a decentralized network.
Security is related to liquidity: the value of RUNE bonded to ensure network security must be twice the value of external assets (such as BTC) pledged as liquidity. This means that as the value of the pledged liquidity rises, so does the value backing its security.
Unique Fee Model: The Continuous Liquidity Pool (CLP) adopts a slippage-based fee model, which provides a unique way to incentivize liquidity providers (supply side) to actively seek ) on a pool of funds with greater demand.
Cold Start: Through early rewards, RUNE can initiate liquidity and security. This reward tends to fall, but still outperforms a buy and hold strategy.
RUNE has two main purposes: 1) It needs to be pledged in the liquidity pool, and the asset pair in the pool is used as the basis; 2) For security reasons, network node operators need to bind RUNE assets as collateral.
Each node must bind RUNE equivalent to 2 times the pledged external assets. For every $1 of BTC put in, nodes must bind $2 of RUNE to keep it safe. Node operators are responsible for operating the blockchain network and earn 2/3 of the "system revenue". If the ratio is out of balance and the value of pledged assets is higher than the RUNE value bound by the node operator, the node operator will get more system income until the ratio is restored to balance. Although this situation will no longer motivate people to pledge liquidity for the time being, it will prompt nodes to bind more RUNE, which will eventually bring the ratio back to balance.
key points
THORChain overview
If successfully launched, THORChain's permissionless cross-chain liquidity pool will have strong product-market fit (like BTC and USDT). In fact, it's hard to find any other use cases that generate so much interest in the short term. As the first project that can achieve this goal, this will trigger a paradigm shift in digital asset trading, from centralized exchanges to a truly decentralized future. This will increase the resilience of the entire cryptocurrency space. Considering the network effect that the liquidity of the capital pool can generate, the project may have a winner-take-all situation. Our team usually focuses research on applications and networks that are already live, because there are so many empty promises in the crypto space. While it had been expected that THORChain would be fully implemented in the first quarter of 2020, it is safer to assume that will not happen. Therefore, in the first half of this report, we focus on exploring the only thing that really matters right now: Can THORChain actually work?
key points
The project development team cleverly utilized the code bases of other projects and combined them in a novel way to build THORChain. Doing so is both ambitious and helps reduce execution risk. Key components of its architecture are built using the Cosmos SDK, Tendermint, and Binance Chain’s TSS codebase.
As an application-specific blockchain, THORChain is optimized to most effectively serve its specific use case, liquidity pool. Its economic model design has an incentive mechanism to ensure that the financial risk of the application is always proportional to the security of the network. If successfully launched, we may see similar cross-chain designs sweeping the DeFi field.
Because of the use of Tendermint, THORChain has fork resistance and near-instant finality, although the PoW blockchain it is connected to does not have these characteristics. Therefore, some measures have been taken to reduce the negative impact that forks and double spends may have on liquidity pools.
Except for the transaction mechanism, THORChain operates like a centralized exchange, but with one important difference - its control over the exchange wallet is decentralized. The validator nodes of THORChain control the liquidity pool on the chain and transfer funds only by reaching a consensus. Once 12 nodes are active, the network will start accepting liquidity and nodes will gradually increase to 99+.
The pledged liquidity is pooled into some addresses on the original THORChain chain, namely "vaults". There are two treasuries - Asgard and Yggdrasil. Asgard accepts incoming funds (new liquidity) and Yggdrasil processes outgoing funds (executes trades). Asset pools maintain a separate balance sheet for each type of asset, and liquidity is allocated and moved between different "vaults" on a regular basis.
A Threshold Signature Scheme (TSS) is used to unlock the vault and send outbound transactions (i.e. perform an exchange). This has significant advantages over multisig, such as increased privacy and reduced transaction costs. Nodes never hold a private key, but gather together to generate a private key and sign transactions through off-chain trustless computation. TSS can work with multiple blockchains (support for new chains can be easily added), and is already compatible with most major blockchains, including Bitcoin and Ethereum.
The project has a strong focus on privacy, with an off-chain, minimalist governance approach. To briefly recap: 1) on-chain vaults are difficult to identify and funds are often moved, 2) nodes are anonymous and their collaboration intentionally limited, 3) transactions have no identifiable characteristics, 4) teams are anonymous.
Compared with other projects that use interoperability as a selling point, THORChain does not use "anchor tokens" for cross-chain asset transfers, which is a distinctive feature of it. Real BTC can be swapped for real ETH in a permissionless manner and settled on-chain. It also has an excellent security model, which ensures that the value of RUNE bonded to the node is always 2 times the value of non-RUNE assets pledged in the liquidity pool. This is an improvement on Ren's approach, where theoretically only $20 million in REN can secure $100 million in pegged assets in Ren's system. Competitors will need to change their design and overall strategy if they want to copy THORChain's approach, so THORChain has a first-mover advantage over its closest competitors.
BEPSwap was originally scheduled to launch on January 3, 2020, but the launch was eventually delayed due to 3 external audits of the code and economy that were pending.
Interoperable, application-specific blockchains
Since its inception, THORChain has gone through several design iterations, leading to confusion in the wider community about how its current approach actually works. For example, the 2018 white paper available on Github is outdated and its information is outdated. As such, we have been in contact with the development team to verify the accuracy of the information referenced in this report.
Blockchain interoperability has been a goal that many high-profile projects have spent years pursuing. With this in mind, how did the relatively unknown team at THORChain develop a new solution to this long-standing technically challenging problem? The short answer is that they didn't. Instead, they took codebases developed by other projects and combined them in novel ways. This is a validation of the open source development movement.
Let's start with how to develop the core of THORChain infrastructure. The team leveraged the Cosmos SDK for its intended purpose and built application-specific blockchains. In this case, the application refers to the "liquidity pool". Until recently, applications were typically deployed on top of blockchains (such as Ethereum) with general-purpose virtual machines. There are several reasons for this. It is impractical for developers to need to build a new custom blockchain from scratch every time they want to launch a new application. Even if they did, those blockchains would likely be silos, unable to interoperate with other networks. The Cosmos SDK changes that by giving developers a framework to easily create custom, interoperable blockchains. However, ATOM holders, sorry, as shown, the economic value it brings may not flow to you.
As an application-specific blockchain, THORChain can be optimized to best serve its use case. It doesn't suffer from the limitations of building on a common platform. Although using this method may present security challenges, THORChain has a viable path to ensure security. Incentives are designed in such a way that the financial risk of an application is always proportional to the security of its network. Would it be safer to build on Ethereum? Yes, but does it actually need to be more secure? Time will tell, but if successful, we may see similar cross-chain designs sweeping the DeFi space.
By adopting the Cosmos SDK, THORChain is built from composable modules (represented by the hexagons in the figure below), allowing development teams to plug and play different functions that others have already built. The consensus engine (green hexagon) is such a module.
Consensus, Finality, and Forks
THORChain uses Tendermint, the default consensus engine of the Cosmos SDK. Originally designed by Cosmos founder Jae Kwon in 2014, the engine has since become a leading consensus engine in the field of proof-of-stake (PoS) consensus mechanisms. As an aside, an old Reddit post asking why Ethereum doesn't use Tendermint, both Vitalik and Jae commented. Tendermint has certain key advantages over proof-of-work (PoW) consensus, including fork resistance and near real-time finality. Although THORChain will benefit from these characteristics, it must be emphasized that the PoW chain it is connected to will not benefit, so other vectors of attack need to be considered. There's a lot more to decipher here, so let's walk through it slowly with some examples to make sure you understand the concepts. We will start by explaining how THORChain enhances support for new external chains. We will then elaborate on the challenges we just mentioned about PoW blockchains, and the steps THORChain has taken to mitigate the associated risks.
Let's take an example, how THORChain's developers implemented support for the Bitcoin blockchain. In order for a new external chain to take effect, more than 2/3 of THORChain nodes need to start observing it. Once the nodes have done this consensus has been reached and the external chain is now activated. Liquidity providers can start staking their BTC, and traders can start trading BTC. Staked assets (BTC in this case) are always stored in vaults (addresses) on their own native blockchain, monitored and controlled by nodes. For a certain period of time, the Bitcoin world was at peace and everything was running smoothly. Then, out of nowhere, the problem of large blocks popped up, and members of the Bitcoin community decided that something had to change, and it had to happen immediately. What followed was a contentious hard fork that split the Bitcoin blockchain. For THORChain nodes, this will lead to a confusing situation. Nodes are supposed to monitor bitcoins in liquidity pools, but right now they don't know which chain is the correct one to track.
If this happens, then the safest course of action is for nodes to either stop watching one or both chains. When more than 2/3 of the verification nodes stop observing the external chain, "Ragnarok" will be automatically launched, and the BTC assets pledged in the liquidity pool will be safely returned to the owner (we explain in more detail on page 13 Ragnarok). In the future, support for the chain can be restarted if more than 2/3 of the nodes start observing the chain again. It's a simple and efficient process that hands control over to the community while protecting staked assets.
We said earlier that Tendermint provides "near-instant finality". what does that mean?
Finality is to ensure that, once a transaction is completed, it cannot be undone. Unfortunately, with blockchains using the PoW consensus mechanism, even though a transaction may have been confirmed in a block, it can still be revoked. Although difficult to implement, a 51% attack could occur, resulting in a double spend. However, as more and more blocks are added to the chain, it becomes increasingly difficult for an attacker to reverse old transactions. This is why PoW chains are described as having probabilistic finality. That old deal "could" be final. Reducing the risk of double spending affects stakers and traders in THORChain. Stakers withdrawing liquidity from the PoW chain will need to wait 24 hours to unlock funds.
However, for traders, it is unlikely that they will wait that long, and for small transactions, this wait is completely unnecessary. Therefore, the developers have created an excellent framework that counts the number of confirmations a trader needs to wait for. In a nutshell, the basis is how large a transaction is relative to the security of the network. For example, based on the security strength of Bitcoin, a $25,000 BTC transaction using this method only needs to wait for 1 confirmation. Also, since THORChain's liquidity pool uses the Automated Market Maker Model (AMM), smaller transactions are generally fairer than larger transactions in terms of slippage. In terms of security goals, this is also fine, since no rational actor would attempt such an expensive and difficult attack just to be able to double spend a small amount.
The bound validator node
We briefly touched on nodes in the previous slide, and this topic deserves a more in-depth discussion. Before diving in, though, let's take a step back and consider how THORChain's approach compares to existing practices on centralized exchanges (CEXs). Using CEX, the trader sends an on-chain transaction to the wallet of the exchange, and CEX manages the wallet of the exchange on the chain, and performs accounting of the transaction internally. Then, when the trader wants to withdraw money, CEX will withdraw from the exchange’s wallet The wallet sends an outgoing transaction, paying the trader. THORChain's design is similar, with some key differences, notably who controls the "exchange wallet".
First, traders in THORChain always maintain custody of their assets, and transactions are settled on-chain (this is a decentralized exchange, after all). Only Liquidity Providers (LPs) need to transfer and pledge their assets. However, instead of trusting a centralized third party to host these assets, liquidity providers trust a decentralized network of staked nodes that are economically incentivized to protect the security of their staked assets. fluidity. Essentially, the difference is really that simple. THORChain just decentralizes the power to control liquidity. In the future, THORChain may also have dedicated verification nodes, enabling people to stake liquidity in a non-pooled, autonomous manner. We believe that, if successfully launched, it will have significant appeal to the Bitcoin community.
Anyone can run a THORNode node as long as they bind the minimum required amount of RUNE. The current minimum threshold is 1 million RUNE. THORNode must run a node for each external chain it "observes" in order to directly monitor pool liquidity on those chains. These nodes are managed by THORNode. When considering the storage and bandwidth required to run nodes such as Bitcoin, Ethereum, etc., it is obvious that this may increase the operational cost of running THORNode, requiring additional expenses beyond the bonded funds.
This can be mitigated though by quickly syncing external nodes that have old (and in this case unnecessary) data that needs to be pruned. As we will see in the following slides, there are other limitations of the consensus engine Tendermint and the signature scheme TSS that may limit the total number of nodes to less than 100 in the short term. Based on the current RUNE staked in RuneVault, 25 out of 781 stakers would have enough RUNE to run a node if the network was launched today.
Once 12 public nodes are active, the first deployed version of the mainnet, BEPSwap (ChaosNet), will start accepting liquidity (we will discuss this more on page 15). If ChaosNet runs successfully, the full mainnet will go live, and it is expected to gradually increase the number of nodes from 12 to 33 within a month. Since then, the goal is to reach 99 nodes in the short term. Are these nodes "decentralized" enough? In any case, it will end up being more decentralized and more secure than trusting a single exchange. That's what really matters.
Pledged liquidity pool
Anyone can stake liquidity without permission, though the network must reach consensus to sign and approve liquidity withdrawals. The latter point is synonymous with Ethereum's need for consensus before releasing funds pooled in Uniswap. Assets pledged as liquidity are pooled in addresses called "vaults" on their native chains. The addresses of these vaults are indistinguishable from regular addresses for reasons discussed on the next page. It is important to understand that each external chain has two types of vaults that serve different purposes: Asgard and Yggdrasil - Asgard receives all incoming funds (new liquidity), while Yggdrasil handles all outgoing funds (execute each transaction). We will now explain each type in more depth.
Each chain has at least 1 Asgard vault that receives liquidity staked on that chain. Asgard vaults are managed by a set of validating nodes that can move funds out of the vault upon consensus. Ideally, in the future the network's entire set of active validators (over 99) will be part of the only Asgard on each chain. However, due to limitations of the current signature scheme (TSS) and consensus mechanism (Tendermint), the network may have Multi-realm Asgard on each chain in the near term. The condition for reaching consensus is not the participation of the only Asgard treasury out of 66 out of 99 nodes, but the participation of 3 Asgard out of 22 out of 33 nodes.
Once Asgard has access to new liquidity funds, assets will be split and transferred to smaller Yggdrasil vaults, each with a different on-chain address. To calculate the number of Yggdrasil vaults, consider the size of the Asgard validator set and divide it by 3. For example, an Asgard vault with 33 validators will have 11 Yggdrasil vaults associated with it. Each of these Yggdrasil vaults will have 3 validators, requiring 2 of the 3 validators to reach consensus in order to sign transactions. A smaller validator set allows the network to execute outgoing activities (transactions) faster. For example, Asgard's signature requires 22 out of 33 nodes to reach a consensus, which can take several minutes, while the Yggdrasil vault only needs 2 out of 3 nodes to reach a consensus, and the signing speed can be less than a second. Although the validator set is small, the existence of transaction-based delegation and incentive structure makes it very difficult to attack.
Conceptually, since Yggdrasil is less secure but more performant, it can be thought of as an insured hot wallet. Asgard is like a cold wallet with higher security but lower performance. THORChain maintains a single balance for each asset, and its pledged liquidity is distributed among different treasuries and moved between different treasuries on a regular basis. On each external chain, each validator is part of 1 Asgard and 1 Yggdrasil. As we discuss this topic, it is important to emphasize that RUNE will be focused on Binance Chain (on which the token is launched). Due to the centralization of Binance Chain, there may be a risk of censorship and other attacks, as the success of THORChain could pose an existential threat to Binance itself. There is currently no precedent to draw upon, however, the team is watching closely for a future transfer of RUNE to another chain, possibly even THORChain itself.
Limited Signature Mechanism vs Multi-Signature
Now that we have outlined the general architecture of THORChain, it is possible to delve into one technical component that plays a key role in all these combinations. Let's start with a quick refresher on blockchain basics. In order to move assets out of an address (or spend a UTXO), you need to have the private key associated with that address (or UTXO) in order to sign a valid transaction. At the base layer, THORChain does what it does when performing a swap: 1) reaching consensus off-chain for the swap, and 2) signing a transaction to move assets out of the treasury. The transaction will pay the trader for the asset they just purchased, on its native chain. .
The concept of multiple parties jointly signing a transaction might remind you of how multisig MultiSig addresses work. This seems to make sense intuitively, however, THORChain actually uses a new type of Threshold Signature Scheme (TSS), which has some core advantages. While both TSS and MultiSig require multiple parties (M out of N) to sign a transaction, the similarities end there. Using MultiSig means that each of the parties has its own key, each responding to a different lock.
For example, if there are 5 parties (N=5), there will also be a lock for each key, for a total of 5. It may require at least 3 parties (M=3) to sign an outgoing transaction with their keys. These private keys are static and stored locally by each party, and the signing process is entirely on-chain. It is also very simple to identify MultiSig addresses and observe signers on-chain. Let's use Bitcoin MultiSig to explain it. In the table on the right, you can clearly see how many BTC are held in each type of MultiSig*. MultiSig transactions also have higher fees (more data generated per signature).
When using TSS, multiple parties (THORNode nodes in this case) are still required to jointly sign the transaction (to unlock the treasury), but they only use one private key. How is this done? First, each node has a piece of information that is stored locally and kept private, and is never revealed to other nodes. Through trustless, interactive, and off-chain computations, nodes combine their secrets to generate a single private key and sign transactions. The private key was never revealed throughout the process. Not only is the vault address difficult to identify because it looks like any other address with a single key, but the identities of the signers (nodes) are also kept private. Outside observers cannot determine who was involved in the key generation and signing process. This method provides better privacy and lower transaction fees (less data produced using 1 signature) compared to MultiSig. In addition, TSS is chain-agnostic, enabling THORChain to support new external chains with less development effort.
Key generation and validator replacement
Basically, THORChain uses TSS for cross-chain communication instead of relying on the IBC protocol (although it may be used in the future). THORChain is implementing Binance Chain’s TSS codebase, which is based on a 2018 paper by Rosario Gennaro and Steven Goldfeder. Their method improves on the previous ECDSA limit design, further speeds it up, and ultimately eliminates the need for a trusted intermediary to distribute secret information for key generation. The title of their paper is "Fast Multiparty Threshold ECDSA with Fast Trustless Setup". Binance open-sourced its TSS library in November 2019.
TSS is a game changer in some ways, but THORChain will not benefit from it if it is not compatible with important external blockchains. Fortunately, because it generates ECDSA signatures, which are compatible with the encryption curves used by most of the current mainstream blockchain networks, especially secp256k1. This is critical because Bitcoin and Ethereum use secp256k1, which means that TSS is now compatible with both blockchains.
Therefore, THORChain does not rely on completely new technologies that have not yet been invented, nor does it wait for external blockchains to make updates beyond its control. We should stress though, that using a new encryption protocol carries a higher risk, as the code is less tested in a live adversarial environment. To help mitigate this risk, Binance Chain’s TSS codebase underwent a third-party audit by Kudelski Security in October 2019. The audit found 10 security issues, all of which were moderate and low-level issues, which were patched. Furthermore, the auditors noted that "any issues identified in the audit framework could not, by themselves, be exploited to completely compromise the security of the program, or to recover secret data". The THORChain team itself is also undergoing a third-party TSS audit.
Earlier in this report, we discussed THORNode nodes without explaining how they rotate in and out of the active validator set. Every 3 days (50,000 blocks), THORChain will automatically replace the 2 oldest and least reliable validators with 2 new validators. The selection criterion for new validators is the number of RUNEs they are bound to. The regular rotation of validators is to help defend against network capture and stagnation, but it goes beyond that.
In effect, every time a validator replacement occurs, it means a "reset". The new validator set is combined to generate new keys for the new treasury address. Once complete, all bound assets held in the old treasury will be moved to the new treasury. In some cases, however, this may not work well, negatively impacting liquidity providers. If in this event 1/3 of the validators leave before being churned out and they delete the necessary information they have stored forever, it could lead to a situation where assets in the treasury are locked forever. The good news is that validators also lose their collateral. Therefore, this type of "attack" may not be done intentionally by rational, profit-seeking nodes. Irrational actors, of course, are a risk, but the same is true for any other cryptoeconomic system.
As we mentioned on page 9, the more active validators there are, the harder it becomes to have only one Asgard library per chain. As more validators are added to the key generation effort, the time it takes to complete the process grows exponentially. If this takes longer than 10 minutes, validators are automatically sharded into smaller subsets, resulting in "multi-domain Asgard". This speeds up the process considerably. While we're putting this all together, it's important to realize that TSS puts an upper limit on what Asgard can achieve (22/33), while Tendermint sets an upper limit on how many active nodes can reach (currently no more than 100) .
Anonymity and Governance
THORChain's primary value proposition is permissionless, private cross-chain exchanges - it's important to understand that. Despite the recent rise of decentralized exchanges (DEXs), due to the lack of interoperability between blockchains, cross-chain trading of assets has been (and still is) done through centralized exchanges (CEXs). Not surprisingly, on top of the global regulatory environment, CEXs are tightening know-your-customer (KYC) procedures, blacklisting certain assets for trading, and blocking users from certain countries with increasing frequency. This may reduce the profitability of the CEX, but may increase its lifespan. THORChain can well fill the gap left by CEX. Our team certainly does not support the use of THORChain to circumvent the law, just like Bitcoin should not be used for this purpose. Individuals should comply with all laws that apply to them, and potential node operators in particular should exercise extreme caution.
Previously, we explained why it is difficult for outside observers to identify vaults on-chain, and how vaults frequently move assets. Even if a vault could be segregated, it would be impossible to know which validators signed which transactions. Remember, a TSS transaction looks like any other transaction signed by a single key. It is not possible to determine which nodes participated in the signing. Not even the nodes themselves can be tracked. There are also many technical details that reflect the concern for privacy. Nodes are anonymous, and the network governance model also intentionally limits the ability to coordinate between nodes. Even the project’s development team puts effort into remaining anonymous, which makes sense in the broader context of reference (who is Satoshi Nakamoto?). In summary, an anonymous team is launching a decentralized network of anonymous nodes to facilitate permissionless, non-custodial cross-chain transactions. If ever the spirit of the crypto world could be distilled, this is it.
THORChain will take an off-chain, minimalist approach to governance. Initially, the team plans to implement on-chain governance through a mechanism they are developing called the AEsir protocol. However, they were later disappointed with the idea due to low participation on other blockchains, the potential for social gestures by voters, and the risk of vote manipulation or regulatory interference. These are valid concerns. Only when the running software is fully compatible with the vast majority of nodes can these nodes generate valid blocks. On the previous page, we mentioned how validator replacement can achieve a network reset. This also has to do with when a node can change the software it runs. Once a node has joined the current validator set, there is no way to make any changes to that node without prior "churn".
This means churning events are also times when new software upgrades are available. In order to make changes to the system, off-chain Improvement Proposals (TIPs) need to be submitted for testing, validation, and discussion by the developer community. Updates must be backward compatible. If an update proves to be beneficial, it can be incorporated into the node software, allowing new nodes to run the update and express support. Once the vast majority of people are running the same software, the system automatically upgrades.
Risk to Security and Funds
If THORChain is not safe for asset pledgers, what does it matter if the yield is high or low. No one will provide liquidity if they think their assets will be lost or stolen. This is where THORChain's economic model design really excels. The value of the capital bound by the node must always be equal to or greater than the value of the mortgage capital provided by the liquidity provider. If the ratio falls, and the value of the pledged assets is greater than the value of the bonded collateral assets, then the node operator will not be able to obtain "system benefits" until the ratio is fixed. This temporarily removes the incentive to increase liquidity while enhancing the incentive for nodes to bond more RUNE. This self-stabilizing mechanism should bring the ratios back into balance. In fact, the network's backed asset value should always grow in tandem with liquidity. As we'll discuss on the next page, this is an important feature that other similar blockchain networks lack.
Competitive Advantage
According to the rules of its consensus mechanism Tendermint, if more than 1/3 of the nodes conduct malicious operations, the network will stop operating, but the mortgage assets will still remain safe. In fact, the funds bound by malicious nodes are still locked, at risk of being fined. However, if more than 2/3 of the nodes act maliciously, they can steal staked assets from the vault, and their collateralized capital may not be fined, because at this point they become the network's "source of truth" . As shown below, THORChain's economic design acts as a powerful deterrent to rational, profit-oriented participants. Although we show two different cases, the rightmost column is the only realistic result.
Of course, malicious nodes won't have their bound RUNEs slashed, but that doesn't have to be the case either. Such an attack would likely drive the price of RUNE down to $0 by itself. As shown in the first row below, nodes are faced with a situation where they can only steal at most $50 of non-RUNE assets in the pool for every $66 capital invested. Let's say their bound RUNE is now worthless and they lost $16 due to the attack. However, it is important to note that this assumes that the internal (pool) price of the collateral asset matches the external price. In some extreme cases, the external price will be different, and this dynamic mechanism will fail.
Competitive Advantage
Being able to provide permissionless cross-chain liquidity is clearly an important use case today with clear market fit. Having said that, it's also logical that there are multiple competing projects working to deliver it in some form. A few projects worth mentioning are Ren, Cosmos, and Bancor. Let's look first at Ren, the project our team first reported on in February 2019, though the project's focus has since changed.
Ren and THORChain share some aspects of their designs. For example, both use the Tendermint consensus mechanism and require validators to stake their tokens to secure their respective networks. Even stranger, they both named the test Chaosnet. Speaking of Ren's Chaosnet, they currently have an active decentralized exchange deployed on it, the DEX supports the exchange between DAI, BTC, BCH and ZEC. Personally, we've never been able to execute a transaction through it, but we want to make it clear now that it's really just a proof of concept, not a product the team is actually working on. Ren does not want to start his own cross-chain exchange.
Instead, it hopes that existing DeFi applications can integrate its infrastructure RenVM to bring cross-chain assets into its applications. They don't want to compete with Uniswap, but want to be the vehicle for bringing BTC into their liquidity pools (yes, we know there is already a wBTC pool). This is where the nuances of their design come into play. THORChain describes itself as a “one-way state anchor,” while Ren, Cosmos, and Bancor are “two-way state anchors.”
We will use BTC and ETH to explain the difference between the two. Ren's "two-way state anchor" is to lock BTC on its native chain and mint an equivalent amount of anchor tokens on Ethereum. Ren calls this anchor token “renBTC,” which is the ERC-20 form of BTC. These anchor tokens must then be destroyed to unlock the BTC backing them. In contrast, THORChain does not use pegged tokens, but only determines how to move assets on its own chain. As a trader, I can trade real BTC for real ETH without any asset "leaving" its chain of origin.
This is not to dismiss the potential uses of pegged tokens, but they do have unique risks. For example, although renBTC is pegged 1:1 to BTC, its price may vary. Why? In short, holding renBTC is riskier than holding BTC. If I were a trader, in exchange for renBTC to use in DeFi. As long as I hold this asset, if Ren's cross-chain bridge becomes insecure, once the risk of anchor decoupling comes true, the renBTC I own may be worthless.
This begs the question, how does Ren's security compare to THORChain once it is fully live? Frankly, Ren has some drawbacks. First, it doesn't have the economic model we outlined on the previous page. It can theoretically protect $100 million in pegged assets, but only requires $20 million in REN to attack. And THORChain fundamentally does not have this type of imbalance. If Ren wants to replicate the security mechanism of THORChain, Ren needs to redo some parts of the design (that is, the Oracle on the chain) and reconsider its overall strategy.
The high issuance rate of THORChain in the short term is also a strong driving force, which can help achieve a cold start of liquidity and bring positive feedback for growth. Ren doesn't have this trait. Also, since Ren is the infrastructure to be used by other projects, its adoption is dependent on external parties. It may be difficult for Ren to generate enough cross-chain transaction fees to maintain the security of its network. Ren’s team is already considering a proposal that would add an annual fee of 1% of the pegged asset on top of transaction fees. Although pegged tokens can be used in some way, according to Ren from November 2019, interacting with these tokens seems to be too abstract for traders. This sounds good, but at least for now, people should prefer to directly trade assets in a permissionless cross-chain way instead of using anchor tokens. Liquidity has powerful network effects, and the first project to achieve qualitative change may find itself in a winner-take-all position.
RuneVault, BEPSwap, and ASGARDEX
For THORChain to be successfully launched, it needs its technology to be sound, with the right incentive mechanism to achieve a liquidity cold start and spark interest in the wider community. I hope that after reading this article, you have a good understanding of how THORChain works on a technical level. Before analyzing the economic incentives in the next section, let’s discuss how THORChain uses its token to generate interest and how the token fits into its launch strategy.
