Howdy, everyone.Today, I’m happy to update information related with our research process. Due to very pressure days, we couldn’t pay full time on RnD direction, so date of result publishing has been moved slighly. Unfortunately, for today, we’ve got results, which showing, that making decentralized gateway (according to vote results) seems inexpedient. You can see (and comment) full explanation below.
The conception.This one is based on creating multisig wallets (for example, 8 signs required from 19 current witness) on Bitshares and destination blockchain (ETH and BTC, as reviewed ones), where signers are witnesses with their own private keys. After wallets setting up, witness node software will be updated, what will make possible, to monitor outside blockchain also (BTC, as example). In case of noticing income transaction on dedicated address from wallet (every user in BitShares will get own address and will be attached to it – this way OL gateway is working already), the witness independently of others, checks transaction and broadcast own verdict, if this tx is real and confirmed by network. When 8 same verdicts will be accepted, the witness, who has noticed tx first will create transfer of OPEN.BTC to customer, and broadcast tx to the rest of witnesses – they should finalize tx with their signs. In case of withdrawal, each witness should check, if funds have come from user to gateway account and necessary BTC address is pointed, then they initiate BTC transfer in its blockchain, with getting required number of signs by the rest of witnesses.
The problems.We have discovered possibilities of realization in ETH and BTC blockchain and faced some problems.
There are 2 in BTC:
1) In case of changing set of signers, very expensive tx should be executed (affect every single address with funds for changing access condition) and fees for that tx will be paid from funds of customers. It means, that if anything will threaten to possibility of signing by initial list of involved witnesses (key losts, voting out, leaving bitshares, own disagreement) we will have to pay quite much fees, for initiating new set of signers. We’re still looking for solutions, allowing to set up flexible key management and will be appreciate for any useful info in this area.
2) Every transaction from multisig wallet costs more than from single sign wallet. Tx will require 2-3 times more fees on average. These payments will be also charged to customers. For instance, current gateway is 0.0003 BTC, what is around 3$; with making multisig wallet fees will be around 10$, what makes transactions with amount less than 30-50$ senseless.
The problem in ETH is only one:
1) It’s not possible to generate thousands of address in multisig smart contract. That makes gateway realization impossible. We could, actually, use meta details in every payment for separating payments, but access to optional fields in transfer exists only in full-functional wallets. People from exchanges will be not able to send funds directly.
The alternatives.For now, the best alternative, for trustless gateway is Atomic Swap technology.
But there are two conceptual problems of solution:
1) AS is slow. It’s quite slow. You should wait confirmation of 2nd blockchain (actually, require confirmation of both blockchains, but mostly, any of BC is slower than BTS). So, it doesn’t present market as it.
2) Actually AS tx doesn’t affect the BitShares growth/cap/development, cause BTC coins don’t somehow come to BitShares DEX (in contrast with Open.BTC, where income BTC create new market). Simply, BTS holder leaving BitShares, while BTC holder comes to BTS and doesn’t bring anything valuable. It’s swap as it, but not trading. We follow updates on altcoin.io, where guys promise to implement fully working DEX, based on AS, but until now, viability of enterprise solution is doubtful.
Some kind of similar conception was described by Fav and discussed there:
https://github.com/bitshares/bitshares-ui/issues/657 and we’re thinking, how to use that in max convenient way.
Due to low potential of clear Atomic Swaps conception (in other words - until it isn’t found yet), our RnD team has decided to look attentively into EVM for BitShares.
We already playing with EVM in EOS testnet and comparing to ETH. We can say already now, that implementing EVM will not affect network speed in cases of current transaction (smart contract instances will be presented as separated transaction and VM will be involved only when it needed, but not with every block). The questions we’re working with now are economical. BitShares concept is quite good in many questions, especially in economical, so it require much attention, to keep everything strong as it now.
Thanks everybody, who has taken part with comments and messages (some people connected in private) – we appreciate very much. Going to continue researching. I’m quite sure, that some useful mechanisms will be presented very soon (but only after full understanding of possibility worker will be presented). Will keep everybody updated about progress and result.