A hot topic in DeFi and crypto at the moment is bringing Bitcoin to Ethereum DeFi ecosystem. How are we approaching this at Vega?
1 Like
I’ve been reading this Defiant artcile by guest Andrew Kang which helps break down the different approaches to enabling people to use bitcoin in DeFi.
In our whitepaper we show how our protocol is designed to accept collateral for trading on Vega from Bitcoin and other major collateral chains. Since Ethereum (and any ERC20s) are our first collateral integration, any of the alternatives that effectively create a token representation on Ethereum will work on Vega soon.
But I know that we’ve also been spiking some ideas around a more direct Bitcoin integration - @danny I know it’s early days but I’d love to hear the different approaches you’ve been considering and how they compare in terms of decentralisation and scalability.
2 Likes
Eventually Vega will have a direct integration with the Bitcoin blockchain, given its importance in the ecosystem. @danny and others in the team are working on this, but due to the dominance of ERC20 tokens and the Ethereum blockchain in general for “DeFi” applications, as well as the fact it’s a little easier to build the integration, Vega will be connected to Ethereum first.
It’s cool that people are wrapping BTC on Ethereum and I think that’ll be great to test demand, but still very much see Vega connecting directly to what is still the most robust chain and largest store of value in crypto.
2 Likes
Our bridge solution that we are kicking around at the moment is a bit different from the rest of DeFi since we don’t run solely on Ethereum. Currently the idea is we will use BTC multisig scripting along with the Event Queue system that we use for the Ethereum bridges. This means that we will be referencing Bitcoins network directly, rather than through some wrapped token (which is just centralization with more steps). We will be leaning on BTC’s stack-based scripting language to create/manage multisig wallets. BTC’s multisig wallets function very similar to the solution we have developed for user-submitted aggregated signatures, the difference being that the transaction fees in BTC are paid out of the wallet itself, rather than a separate “gas” parameter on the transaction, so this should be very little work on the Vega node side to implement.
So far, everything is coming along smoothly, but we’re still working on a solution for adding and removing Vega validator nodes, and how this will necessitate a migration of bridge funds. We’ve got some ideas, but there’s quite a bit of research to do before we can start testing those ideas. I am confident that there’s a path here without relying on some centralized token wrapping mechanism, and that this will set us apart from most of the bridge solutions currently in development in the DeFi space.
2 Likes
Isn’t the approach Ren takes interesting though, where you can decentralize the custody of assets using a threshold ECDSA signature scheme, so key management can be done by a decentralized network of nodes instead of some centralized custodian like BitGo for WBTC. That method generalizes to all ECDSA blockchains, which is most of them, so you could in a rapid fashion unlock many different assets for Vega that come from many different blockchains like Ethereum, Cosmos, Polkadot etc., and, of course, Bitcoin.
3 Likes
Hi @maximilian, welcome to the forums!
I think Ren’s approach is pretty interesting. @danny can elaborate further, but in fact, in some ways it’s not unlike the method the Vega blockchain uses to take custody of assets such as Ether, ERC20s, BTC, etc.
Because we’ve built the framework into Vega though, there’s one less chain and consequently less risk to do this directly on Vega than going via another chain. It also gives us faster finality for deposits and much more flexibility for deeper integrations with the Vega protocol, like to manage a position on Vega directly from the Bitcoin or Ethereum blockchain.
1 Like
Thanks! I’ve been following Vega from a distance, I think having a bespoke trading platform can solve many of the issues we have with trading on Ethereum today like front-running, scalability issues etc., so very interested in your work!
Cool that you are building it right into Vega, the MPC protocol that Ren developed is built for a Tendermint-based consensus, and since you seem to have a Tendermint core blockchain if I’m not mistaken, you might have use of some of that work maybe? https://github.com/renproject/rzl-mpc-specification/blob/master/z0_spec.pdf
3 Likes
Good question, thanks for asking it. The first thing we looked at for key generation and management was threshold signature scheme (TSS). This looked promising and, as you pointed out, would work with all ECDSA blockchains. As we got further into researching TSS, @klaus pointed out that since it’s A) expensive to setup and B) requires multiple back and forth interactions per each step, that it would only take one bad actor to drop out of the process to force the entire cycle to start again. Since TSS is a 1 on 1 interaction, you can’t prove which party dropped out, so you cannot penalize the guilty party with certainty. All of this makes for a potentially cheap denial of service attack.
The solution we are using for ETH/ERC20 until we can come up with (or find) a TSS that isn’t interactive, is aggregating validator signatures. We ask validators to sign a withdrawal order and send us that signature. The user then takes an above-threshold number of those signatures and concatenates them together before submitting the signature bundle to the bridge smart contract, which verifies the signatures, then pays out.
For bitcoin we’re currently looking at a solution that uses Bitcoin scripts and multisig wallets to manage the deposited BTC in a decentralized way. It’s as close as possible to the ETH version, including the aggregated signatures, only using the not turing complete, stack-based op codes that BTC uses. These limitations of BTC make for some interesting problems that I’m sure I’ll write in a blog post once it’s fully solved.
Eventually I would hope that we find an appropriate TSS, but for now we are not letting that stop us.
2 Likes
Thanks for that paper, I’ll read through it and pass it around.
Also, welcome to the community!
2 Likes