Comparative Analysis of wanBTC with tBTC
With the release of Wanchain 5.0, a new decentralized crosschain solution has been implemented already! In the last article, I analyzed the renBTC crosschain solution, and I also mentioned that wanBTC will have a significant improvements over Ren’s solution in terms of decentralization and security mechanism. At the same time, many readers asked me about another project tBTC, which is aother project that wraps BTC on Ethereum. This article will analyze some designing and implementations of the similarities and differences between tBTC with wanBTC. And I wish to give readers a different perspective to view these BTC-wrapped solutions.
Let’s take a look at the designing mechanisms of tBTC and wanBTC. Firstly, both projects are trying to use more decentralized ideas to achieve interoperability/crosschain. Objectively speaking, neither can fulfill the ‘perfect’ state of 100% ‘absolute decentralization’ due to the bottleneck of the existing technologies. In addition to the core cryptographic technology that ensures the security of crosschain locked accounts, wanBTC and tBTC both use ‘extra’ economic measure to ensure the security of users’ native BTC assets, even if the extreme technical ‘black swan’ incident happens! This economic measure is the ‘collateral’ mechanism.
In tBTC’s design, the node that manages native BTC assets is called ‘Signer’, while in wanBTC, the node that also manages asset is called ‘Storeman Group’. Both tBTC and wanBTC require collateral deposits for the ‘signature’. The difference is that the Signer of tBTC uses 150% Ether for the ‘over-collateral’ and the Storeman of wanBTC uses a 200% WAN coins as ‘over-collateral’.
Such mechanism of over-collateralization is a very good protection for locking the original assets in addition to technical guarantee. It can be regarded as ‘Double Security’. One more thing to add, since it is over-collateralized, for the price spot and liquidation settlement of the collaterals against BTC, tBTC uses MakerDAO’s single price feed while wanBTC uses the ‘BIO’ multi-oracle to acquire the price from different sources.
After talking about the similarities, let’s look at the differences between the two projects. The first is the different design of the TSS Threshold Signature in cryptography. wanBTC and tBTC are both based on the latest TSS program research results “Fast Multiparty Threshold ECDSA with Fast Trustless Setup”. In terms of parameter settings, the threshold used by tBTC is a setting of 3–3, which means that each crosschain transaction has 3 “signatures” to manage the accounts that lock the original BTC assets, and these 3 signers need to participate in sending a legal signature. If any signer goes offline or refuses to sign, the two steps of a crosschain transaction: “locking” and “minting” cannot be completed. This is regarded as a kind of “No Fault Tolerable”.
The threshold adopted by wanBTC is a 15–21 design, that is, each crosschain transaction is managed by 21 anonymous nodes, and each transaction requires the participation of 15 Storeman nodes to complete the crosschain locking and minting. In other words, every time when a crosschain transaction occurs, it is allowing no more than 6 nodes of the 21 Storeman to be offline or refuse to sign. Thus this design can be considered as a kind of ‘Fault Tolerable’. When a large number of crosschain transactions happen, “allowable fault tolerance” is more practical than “no fault tolerable”.
In addition to the TSS threshold setting, the second difference between the two mechanisms is that the ‘split’ setting of the native Bitcoin. Because tBTC uses a small group of three ‘signers’ to sign mentioned above, it is more likely these three signers to conspire and ‘steal’the native Bitcoin, so tBTC uses ‘discrete values’ to prevent such behavior. For example, if a user operate one crosschain transaction of 1.63 BTC, tBTC may discretize the number 1.63 into 1 piece of 1BTC, 1 piece of 0.5BTC, 1 piece of 0.1 BTC, and 3 pieces of 0.01 BTC, so it is handed over to (1+1+1+3) 6 ‘three signers’ groups for processing. Although the security has been improved to a certain extent, from a practical point of view, it also means that the user’s transaction of 1.63 BTC needs to wait for 6 times of the Bitcoin network finality confirmation, and it also needs to pay 6 times gas fee for the Bitcoin network as well as 6 times ‘minting’gas fees on Ethereum. Looking at the very expensive gas fee on Bitcoin and Ethereum networks nowadays, I doubt whether this discrete setting like tBTC can be implemented. In other words, if you stick to the discrete value setting, basically users who want to transfer a small amount of BTC to Ethereum will need to pay a big amount of gas fees in total. Meanwhile, wanBTC adopts the design of 21 “Storeman” nodes and as long as the collateral is greater than the crosschain transaction amount, the transaction of 1.63 BTC in this example will need only one time waiting time as well as gas fee for Bitcoin network, and only one ‘minting’ fee on Ethereum. Of course, when the collateral of the ‘Storeman’ group is not enough for the BTC crosschain transaction, the mechanism setting will not allow such transaction to be implemented to ensure the security of the original BTC asset.
Another difference between these two is the logic of contract interaction. As we know, the contract interaction logic determines the waiting time and gas fee consumed for crosschain transactions, so we take a 1BTC transaction for example: when user requests to transfer 1 BTC to 1 tBTC on Ethereum, the process is that the user needs to send 1 time 1BTC ‘lock’ transaction and 1 time of contract interactions on Ethereum for ‘Request (request for coin ) ‘and 1 time of ‘Proof (the original BTC is locked and the evidence is submitted to the contract)’; in addition, tBTC has to ‘select’ different groups of ‘3 signers’ for such transaction; and wait until the selection of the groups of ‘signers’ is completed that they can send the generated BTC locked address to the user to ‘stake’their Bitcoin. It will take a longer time with a user poor experience.
In the Wanchain crosschain mechanism, when users request to send BTC to Ethereum to mint wanBTC, since Wanchain’s “Storeman” group selection is not completed based on each transaction, but the selection is finished in advance, so the selected “Storeman’ group will send the address of the locked BTC address directly to the user, and there is no need for the user to send any transactions to Ethereum. According to the settings of these contract interaction logic for wanBTC, it is predicted that the transfer time of tBTC will be about 1–3 times longer than that of wanBTC (tBTC: discrete setting plus two Ethereum transactions), and the gas fee payment will be 3–10 times higher (tBTC: Ethereum transaction fee) 2 + Bitcoin transaction fee 1 + 0.005 BTC / Wanchain: Bitcoin transaction fee *1).
The last point of the differences is that tBTC requires users MUST to ‘redeem’ their tBTC after 6 months, while wanBTC does not have such a deadline, and users can hold wanBTC as long as they want. Such a “strange” requirement is because in tBTC mechanism, the minted tBTC is managed by a separately selected group of ‘3 signers’, and if the user does not redeem the tBTC to original BTC, these ‘ 3 signers’s node cannot exit the network but have to wait there. Therefore tBTC forces users to “redeem” after maximumly of 6 months; while wanBTC’s “Storeman” group is not served only for a single transaction, and with every calendar month ‘Storeman selection’ is finished, the old group will hand over the ‘balances, debts and rewards’ to the new group so any single Storeman group node can exit. Thus users are not required to “redeem” the minted wanBTC assets within a certain period of time.
In general, from the comparative analysis stated above, we can say that both tBTC and Wanchain’s wanBTC followed the professional and serious ‘trustless’design logic and made quite technical and engineering breakthroughs in the implementation of ‘decentralization’ and ‘security’.
Both parties have adopted TSS’s latest threshold cryptography research results, but because of the different thresholds obtained, a series of different settings have been used in engineering and coding, which has caused some similarities and differences. Going back to what I said at the beginning of this article, no crosschain mechanism is absolute ‘100% technically safe’ at the moment so when crosschain node collateral, economic slashing and incentive rules are introduced, they greatly improved the crosschain technology. We advocate here any further efforts from different projects and teams to promote the crosschain technology and the application wrapped tokens rather than only telling the crypto industry something only exist in their whitepapers without any adoptions at all!