High level differences between renBTC and tBTC

The quest to bring Bitcoin on Ethereum in a trustless manner is well underway. Through this, BTC holders could interact with the DeFi ecosystem and smart contracts in general, with minimal trade-offs on security and decentralization, unlike solutions like Wrapped Bitcoin which are custodial and censorship prone. Two projects are making interesting advances towards this goal: Ren Protocol and tBTC. 

At a high level, the idea in both cases is that a Bitcoin holder deposits 1 BTC on a wallet controlled by a peer-to-peer network or set of nodes acting as a bridge between Bitcoin and Ethereum with off-chain components. Once these nodes have proof that they have indeed received 1 BTC, they mint 1 ERC-20 token representing this BTC on the Ethereum blockchain, e.g. renBTC in the case of Ren, and TBTC in the case of tBTC. A few properties are desirable in this process and most importantly:

• There shouldn’t be more tokens minted than there are BTCs under the nodes’ custody to maintain a strict supply peg
• A group of nodes shouldn’t be able to steal users’ funds without getting punished

The nodes don’t do this for free: they provide work in exchange for a fee paid by the user. In this post, I only discuss succinctly some of the main differences between the Ren and tBTC designs

Nodes selection and network topology

tBTC and Ren nodes are members of the Keep and RenVM networks respectively. The way they are organized and selected to manage BTC deposits is different in both systems.

tBTC

To be able to become tBTC node or signer, nodes need to be part of the Keep Network by staking 100k KEEP tokens which are ERC-20 work tokens as well as a collateral in ETH. The Keep network implements a source of randomness called the random beacon and a secure multi-party computation (sMPC) protocol among other things. Each time a BTC deposit is requested by a user, the Keep network selects a group of N nodes to become signers. They then run a multi-party threshold signature algorithm. That is, they generate a Bitcoin address that no single member of the group will be able to use: instead, a subgroup of M out of N members needs to work together to be able to sign messages or generate transactions from this Bitcoin address. In the first version of tBTC, M = N = 3. More information can be found in the protocol’s technical specifications

Ren

Similarly, Ren nodes or Darknodes need to stake 100k REN tokens which are ERC-20 work tokens. Contrary to tBTC/Keep, this network is a separate peer-to-peer network with its own networking and consensus rules. Furthermore, the nodes are organized very differently: Ren nodes are put in groups of 200 nodes called shards. Each shard runs a sMPC algorithm to generate a Bitcoin address. Assuming there is only one shard at first, this single wallet will be used for users’ deposits. It cannot be used unless more than 2/3rd of the nodes in the shard work together. This is done by combining the sMPC algorithm with a Byzantine Fault Tolerant consensus algorithm together in a new process called RZL MPC. While the the code is not yet open source, some details can be found in the latest technical specifications draft and in the project's Wiki.

Economic guarantees

A user making a BTC deposit on the network wants to have some level of guarantee that the nodes will not collude to steal the funds. From a game theoretical point of view, this might be encouraged by the use of collateralization of the nodes such that they stand to lose money if they misbehave.

Ren

As discussed above, Ren darknodes are required to lock up 100k REN tokens in order to participate in the network. In the event that a shard misbehaves by stealing users funds or otherwise failing (more than 1/3rd byzantine nodes in the shard), the entirety of the shard’s stake is confiscated and used to buy and burn renBTC on the market to restore the peg, effectively compensating the users for lost funds. Assuming a shard of 200 nodes, attackers would need to control 67 nodes to steal the funds which is a capital requirement of 6.7M REN tokens to conduct the attack. If the total value of the Bitcoin guarded by the shard exceeds the total value of the REN tokens, this means that the attack can be profitable. In order to mitigate this threat, the protocol uses an algorithmically adjusted fee: if the value of the REN staked is too low, the fee earned by darknodes increases until the security threshold is reached. Assuming an efficient market, this makes the REN tokens more attractive, raising  their value by supply and demand. Note that in this system, users are not compensated for the lost funds.

tBTC

tBTC signers are part of the Keep network and as such have locked up 100k KEEP tokens to participate. However, in contrast with Ren, this is not the only bond required from them. To be able to guard a deposit of 1 BTC in the first place, signers need to put up a bond in ETH that is 150% the value of 1 BTC. For example if 1 BTC is worth $10k and 1 ETH is worth $200, signers need to provide a collateral of 75 ETH before they can generate any Bitcoin address to share with the deposit requester. The reason for the overcollateralization is to protect the system from price drops of ETH/BTC upwards to 33%. If the signers responsible for a deposit misbehave, the user is compensated for their BTC loss with the seized collateral by buying TBTC on the market.

In summary, Ren is more capital efficient and scalable but less economically secure a priori because it requires the market to efficiently follow the algorithmically adjusted fee to value REN. It mitigates this by trying to make sure the total REN capitalization is high enough to make attacks unprofitable. tBTC on the other hand is less capital efficient, less scalable but more economically secure a priori via overcollateralization. Note that this leaves both systems vulnerable to large price swings like the market collapse that occured in March 2020. Note that this discussion assumes a reliable price feed oracle for tBTC.

Deposit sizes

Using tBTC, a user may only deposit an amount of Bitcoin that corresponds to one of several available lot sizes. For example it might only be possible to deposit BTC in chunks of 0.01, 0.1 or 1 BTC. This makes it easier for miners to plan for the ETH bonds they need to put up in advance and also adds some anonymity at the cost of seamless user experience. Ren doesn’t have such restrictions and allows users to deposit any amount of BTC.

Closing word

This is only a brief, high level overview of some of the main differences between tBTC and Ren which I have noticed is a common request in both communities. There are many other differences in the cryptographic primitives used, the exact implementation of Bitcoin transaction proofs, etc. It is not yet possible to review every aspect in detail since important parts of the Ren protocol code are still not open source pending further developments. Of note however is that tBTC is using well known and peer reviewed algorithms, while Ren is attempting a breakthrough in consensus based sMPC, which would allow for more flexibility but is not without risk related to novelty. I see it as a net positive for the ecosystem that different approaches are competing to enable the use of Bitcoin on Ethereum in a trustless manner and it will be interesting to expand this comparison as development progresses.